Linq to SQL против сериализации

Question

Скажем, у меня есть несколько таблиц в базе данных MSSQL, каждая из которых имеет около 5-10 атрибутов. Между таблицами есть несколько простых ассоциаций, но каждая таблица содержит от 500 000 до 1 000 000 строк.

Существует алгоритм, который работает с этими данными (все из них), поэтому перед запуском алгоритма мне нужно извлечь все данные из базы данных. Алгоритм не изменяет данные, а только читает их, поэтому мне просто нужно получить данные.

Я использую LINQ to SQL. Для извлечения всех данных требуется около двух минут. Я хочу знать, действительно ли сериализация в файл, а затем десериализация (при необходимости) будет загружать данные быстрее.

Объем данных составляет около 200 МБ, и я не против сохранить их на диск. Итак, было бы быстрее, если бы объекты были десериализованы из файла или с помощью LINQ 2 SQL DataContext?

Есть ли у вас опыт?

Answer 1

Я бы сказал, что LINQtoSQL может быть не лучшим выбором для такого рода приложений. Когда вы говорите о стольких объектах, вы сталкиваетесь с большими издержками при создании экземпляров объектов (ваших постоянных классов).

Я бы выбрал решение, в котором хранимая процедура извлекает только необходимые данные через ADO.NET, приложение хранит их в памяти (в настоящее время память дешевая, 200 МБ не должно быть проблемой), а алгоритм анализа запускается на входе. данные памяти.

Не думаю, что вы должны хранить данные в файле. В конце концов, ваша база данных - это просто один или несколько файлов, которые считываются ядром базы данных. Таким образом, вы либо

• пусть ядро ​​базы данных прочитает ваши данные и вы проанализируете их, или
• пусть ядро ​​базы данных читает ваши данные, вы записываете их в файл, читаете файл (снова читаете те же данные, но теперь вы делаете это сами) и анализируете данные

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

РЕДАКТИРОВАТЬ: Если ваши данные изменяются очень редко, вы можете рассмотреть возможность предварительной обработки данных перед анализом и кэшированием предварительно обработанных данных где-либо (в базе данных или в файловой системе). Это имеет смысл, только если ваши предварительно обработанные данные могут быть проанализированы (намного) быстрее, чем необработанные данные. Может быть, некоторая предварительная обработка может быть выполнена в самой базе данных.

Answer 2

Вы должны попытаться использовать ADO.NET напрямую, без слоя LINQ to SQL поверх него, то есть, используя SqlDataReader для чтения данных.

Если вы работаете с данными последовательно, вы можете получать записи из считывателя, когда они вам нужны, без необходимости сначала считывать их в память.

Answer 3

Поскольку вы делаете это в C # и ваша база данных MsSql (поскольку вы используете Linq to Sql), не могли бы вы запустить свой код в управляемой хранимой процедуре? Это позволит вам сохранить текущий код таким, какой он есть, но загрузка данных будет намного быстрее, так как код работает на сервере SQL.

Answer 4

Если у вас есть процесс, который работает с большинством данных в базе данных ... тогда это звучит как работа для хранимой процедуры. Он не будет объектно-ориентированным, но будет намного быстрее и менее хрупким.