Хранение больших двоичных объектов - более 100 ГБ, MySQL, SQLite или PostgreSQL + Python

Question

У меня есть идея для простого приложения, которое будет контролировать группу папок, индексировать любые найденные файлы. Графический интерфейс позволит мне быстро пометить новые файлы и переместить их в одну базу данных для хранения, а также предоставит простой механизм для запроса базы данных по тегу, имени, типу файла и дате. На данный момент у меня есть более 100 ГБ файлов на пару съемных жестких дисков, база данных будет как минимум такой большой. Если возможно, я бы хотел поддерживать полнотекстовый поиск встроенных двоичных и текстовых документов. Это будет однопользовательское приложение.

Не пытаюсь начать войну с БД, но какая БД с открытым исходным кодом будет работать для меня лучше всего? Я почти уверен, что SQLLite не на столе, но я могу ошибаться.

Answer 1

Я все еще исследую эту опцию для одного из моих собственных проектов, но CouchDB , возможно, стоит посмотреть.

Answer 2

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

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

Answer 3

Я бы предпочел хранить документ с метаданными. Одна из причин, это целостность отношений. Вы не можете легко перемещать файлы или изменять файлы без посредничества БД. Я уверен, что смогу справиться с этими проблемами, но это не так чисто, как хотелось бы, и мой опыт показывает, что большинство поставщиков в настоящее время могут обрабатывать огромные объемы двоичных данных в базе данных. Я думаю, мне было интересно, есть ли у PostgreSQL или MySQL какие-либо очевидные преимущества в этих областях, я в основном знаком с Oracle. В любом случае, спасибо за ответ, если БД знает, где находится внешний файл, также будет легко перенести файл в более позднее время, если я захочу. Другой аспект вопроса заключался в том, легче ли работать с любой базой данных при использовании Python. Я предполагаю, что это стирка.

Answer 4

почему вы тратите время на эмуляцию того, что файловая система должна уметь обрабатывать? больше памяти + grep - ваш ответ.

Answer 5

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

Единственным ограничивающим фактором является максимальный размер "пакета" для данной БД (под пакетом я имею в виду запрос / ответ). Обычно эти ограничения составляют около 2 МБ, что означает, что ваши файлы должны быть меньше 2 МБ. Конечно, вы можете увеличить этот лимит, но весь процесс довольно неэффективен, поскольку, например, для вставки файла вам потребуется:

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

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

Answer 6

Мне всегда неприятно отвечать «нет», но вам лучше индексировать что-то вроде Lucene ( PyLucene ). Это и хранение путей в базе данных, а не содержимого файла почти всегда рекомендуется.

Кроме того, ни один из этих механизмов баз данных не будет хранить большие объекты в отдельном пространстве данных (они будут встроены в пространство данных таблицы), поэтому любой из этих механизмов должен работать почти одинаково (ну, кроме sqllite). Вам нужно перейти на Informix, DB2, SQLServer или другие, чтобы получить такую ​​обработку двоичных объектов.