Производительность памяти Linq to DataSets / Objects с большими наборами данных - PullRequest
Новая
       8

Производительность памяти Linq to DataSets / Objects с большими наборами данных

1 голос
/ 20 июля 2009

Короткий вопрос : есть ли у кого-нибудь информация о производительности памяти Linq с большими объемами данных? В частности, Linq для наборов данных или Linq для объектов.

Какое наибольшее количество записей / объектов может обрабатываться? Что такое накладные расходы памяти? Кто-нибудь может опубликовать приблизительные цифры использования памяти?

Фон

Моя компания взаимодействует с внешней базой данных (которая останется неназванной из-за чрезмерной хрени) с очень низкой производительностью. Он имеет интерфейс ODBC, который хорошо работает для базовых SELECTS, но с несколькими соединениями производительность падает с обрыва (и горе всем, кто пытается использовать OUTER JOINS!).

Ранее мы решили эту проблему, скопировав данные с помощью операторов SELECT * FROM Table в базу данных SQL и выполнив наши запросы из SQL. Однако мы хотели бы удалить сервер SQL из уравнения (удалив внешние зависимости).

Решение, которое я имею в виду, состоит в том, чтобы выполнить SELECT * FROM Table в некоторых наборах данных (или, возможно, пользовательских объектах) и использовать Linq для выполнения всех запросов в памяти.

Размер данных, с которыми мы взаимодействуем, ограничен 2 ГБ (и нам не нужно загружать все сразу, возможно, максимум несколько сотен МБ). Тем не менее, я беспокоюсь о том, чтобы увидеть страшную OutOfMemoryException для больших объемов данных. Отсюда и мой вопрос.

Драйвер ODBC является 32-битным, поэтому я не могу использовать 64-битный процесс (не без передачи данных между двумя процессами, и я бы предпочел свести сложность к минимуму). Драйвер ODBC доступен только для чтения.

Также приветствуются другие комментарии или предложения по этому поводу (за исключением использования встроенной базы данных, такой как SQL Compact, это наш план Б, если запросы к памяти не осуществимы).

PS: я делаю некоторые доказательства концептуальных тестов в течение следующих нескольких дней (и я знаю, что для моего случая будут специфические особенности, которые будут известны только с этими тестами), но я бы хотел, чтобы кто-то уже имел опыт работы с этим.

Редактировать: это будет развернуто с использованием ClickOnce в качестве приложения Windows Forms.

Ответы [ 2 ]

1 голос
/ 20 июля 2009

См. Следующий пост StackOverflow; Он содержит несколько полезных советов по управлению памятью с помощью Linq to SQL:

Как избежать утечки памяти с помощью LINQ-To-SQL?
Как избежать утечки памяти с помощью LINQ-To-SQL?

0 голосов
/ 20 июля 2009

Не зная вашего приложения, можете давать только общие комментарии.

  1. Если это веб-приложение, если вы не собираетесь создавать решение БД в памяти, которое может использоваться совместно для разных запросов и т. Д. (Какой SQL Server и другие уже делают это для вас), я ' настоятельно рекомендую против этого, поскольку он не будет слишком масштабируемым.

  2. Я бы все же советовал против этого, поскольку я не думаю, что механизм индексации встроен в LINQ. Использование LINQ для этого в основном похоже на TABLE SCAN в разговоре по SQL, где вы просматриваете всю таблицу в поисках нужных данных, а не используете более эффективную индексацию, которую SQL может предоставить для вас.

  3. Да, вы будете подвергаться зависимости и времени передачи по сети при использовании SQL Server, но я думаю, что при правильном запросе и возврате правильного набора результатов SQL все равно превзойдет то, что вы пытаетесь сделать.

Итак, рекомендация ... не изобретайте велосипед :) Кто-то уже создал более эффективный механизм для этого.

Если вы все еще хотите это сделать, я настоятельно рекомендую вам провести расширенный тест ваших собственных реальных данных . Поскольку, по моему опыту, тестирование с фиктивными данными, которые не отражают фактических данных (по размеру и по содержанию), никогда не будет достаточным, если ваша цель - производительность.

...