SQLite против сериализации на диск
Я провожу сравнение производительности, что лучше - сериализация данных или хранение их в БД. Приложение получает чертовски много данных (x GB), которые необходимо сохранять с минимальной скоростью 18mb/s (пока что)
Хранение в БД предлагает более простую функциональность в плане поиска и доступа к данным в более позднее время, снимков данных, миграции данных и т.д., но мои тесты на данный момент показывают огромную разницу во времени производительности.
Тест сохраняет 1000 объектов (размером около 7 сотен с небольшим кб каждый). Либо в соответствующие колонки в таблице, либо на диск, сохраняя их как общий List. (SQLite в итоге содержит немного больше данных)
- Сохранение в SQLite v3, общий размер 745мб: 30,7 секунды (~скорость: 24,3 мб/с)
- Сериализация на диск, общий размер 741мб: 0,33 секунды (~скорость: 2245 мб/с)
Я не делал никаких настроек производительности SQLite, просто использую его из коробки с Fluent nHibernate и адаптером SQLite.Data (без транзакций), но на первый взгляд это огромная разница.
Конечно, я знаю, что прохождение через ORM mapper и DB для записи на диск дает накладные расходы по сравнению с сериализацией, но это было очень много.
Также необходимо учитывать необходимость сохранять данные сразу после их получения. Если произойдет сбой питания, мне нужны последние полученные данные.
Есть мысли?
----- Updates (as I continue to investigate solutions) ------
- Wrapping the 1000 inserts in a transaction the time was now ~14s = 53mb/s, however if I throw an exception halfway I lost all my data.
- Использование IStatelessSession, кажется, улучшает время на 0.5-1с
- Не заметил никакого прироста производительности, если присвоить ID сущности вместо того, чтобы он автоматически присваивался в таблице и таким образом избавиться от (select row_generatedid()) для каждой вставки sql. -> Id(x => x.Id).GeneratedBy.Assigned();
- альтернатива nosync() в SQLite не является альтернативой, так как БД может быть повреждена в случае сбоя питания.