FILESYSTEM против SQLITE, сохраняя до 10 миллионов файлов

Question

Я хотел бы хранить до 10M файлов, 2 ТБ.Единственные свойства, которые мне нужны, ограничены именами файлов и их содержимым (данными).

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

Я думал о NTFS, но большинство его функцийне требуется, хотя не может быть отключен и считается чрезмерной проблемой, некоторые из них: дата создания, дата изменения, атрибуты, журнал и, конечно, права доступа.

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

(SQLITE будет через C api)

Моя цель - использовать более подходящее решение для повышения производительности.Заранее благодарен - Doori Bar

Answer 1

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

Чтобы повысить производительность NTFS (или любой другой файловой системы, которую вы выберете), не помещайте все файлы в одну папку, а группируйте файлы по первым N символам в именах файлов или также по расширению.

Также на рынке существуют некоторые другие файловые системы, и, возможно, некоторые из них предлагают возможность отключить некоторые из используемых функций.Вы можете проверить сравнение в Википедии и проверить их.

Исправление: Я провел несколько тестов (хотя и не очень обширных), которые не дают никакого преимущества в производительности при группированиифайлы в подкаталоги для большинства типов операций, и NTFS довольно эффективно обрабатывает 26 ^ 4 пустых файла с именами от AAAA до ZZZZ в одном каталоге.Поэтому вам необходимо проверить эффективность вашей конкретной файловой системы.

Answer 2

Официальный сайт SQLite на самом деле содержит страницу , которая документирует преимущества производительности при использовании базы данных над собственной файловой системой в различных операционных системах. При хранении файлов ~ 10 КиБ sqlite примерно на 35% быстрее.

SQLite читает и записывает небольшие капли (например, миниатюры изображений) На 35% быстрее, чем те же самые двоичные объекты могут быть прочитаны или записаны отдельные файлы на диске с использованием fread () или fwrite ().

Кроме того, в одной базе данных SQLite, содержащей 10-килобайтные двоичные объекты, используются примерно на 20% меньше места на диске, чем для хранения больших двоичных объектов в отдельных файлах.

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

Измерения в этой статье были сделаны в течение недели 2017-06-05 использует версию SQLite между 3.19.2 и 3.20.0. Вы может ожидать, что будущие версии SQLite будут работать еще лучше.

При использовании файлов большего размера могут возникнуть разные результаты, и на сайте SQLite есть ссылка на kvtest , которую вы можете использовать для воспроизведения этих результатов на своем собственном оборудовании / операционной системе.