Хранение больших объемов данных: БД или файловая система?

Question

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

Записи создаются и редактируются (скорее всего, путем добавления, а не переписывания) произвольно.

Имеет ли смысл хранить записи как отдельные файлы в файловой системе при сохранении необходимых наборов индексов в БД по сравнению с сохранением всего в БД?

Answer 1

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

Хорошо, достаточно обобщений. Учитывая, что база данных в конечном итоге сводится к «файлам на диске», я бы не стал слишком беспокоиться о том, что «правильно делать». Если основная цель базы данных - просто эффективно извлекать эти файлы, я думаю, что было бы прекрасно держать небольшие записи в БД и искать пути к файлам вместо фактических данных - тем более что ваша файловая система должна быть довольно эффективной при извлечении данных учитывая конкретное местоположение.

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

Answer 2

Я бы определенно сохранил данные в файловой системе и хеш путь в БД.

Answer 3

Я буду использовать HDFS (распределенную файловую систему Hadoop) для хранения данных. Основная идея заключается в том, что вы получите высокую доступность, масштабируемость и репликацию. Любые запросы к вашему приложению могут быть сделаны картами, уменьшающими запросы. А основные поля могут храниться в виде распределенного индекса поверх Hadoop с помощью Katta.

Попробуйте поискать в Google эти технологии.

Answer 4

Пара соображений:

• управление транзакциями;
• Резервное копирование и восстановление.

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

Из вашего вопроса следует, что вы не собираетесь использовать обычные функции базы данных (целостность отношений, объединение). В этом случае вам следует тщательно рассмотреть третий вариант: сохранить ваши данные в файловой системе и вместо базы данных использовать механизм поиска текста на основе файлов, например Solr (или Lucene), Sphinx, Autonomy и т. Д. *

Answer 5

На работе мне часто приходится собирать большие наборы XML-документов для последующего анализа.Обычно это делается путем помещения их в каталог, а анализ выполняется с помощью grep (или программы Java на заказ со всеми ее атрибутами XML factory / builder / wrapper / API).

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

• Автоматическое сжатие больших данных при необходимости (TOAST).
• Индексирование с использованием выражения.

Что касается первой функции, размер БД составлял менее половины размера необработанных файлов.Выполнение полнотекстового поиска, сканирование таблицы с использованием WHERE data::TEXT LIKE '%pattern%', было на самом деле быстрее, чем запускать grep для файлов.Когда вы имеете дело с несколькими ГБ XML, это само по себе делает БД стоящей.

Вторая функция, индексация, требует немного больше работы.Было несколько конкретных элементов, которые, как я догадался, было бы неплохо проиндексировать.Индекс на xpath('//tradeHeader/tradeId/text()', data) работает, но дублировать его в каждом запросе может быть затруднительно.Я обнаружил, что проще добавлять обычные столбцы для некоторых полей и использовать триггеры вставки / обновления для их синхронизации.

Answer 6

Ну, в зависимости от ваших затрат, MS SQL Server имеет так называемый «Первичный XML-индекс», который можно создавать даже на неструктурированных данных. Это позволяет вам написать XQuery для поиска по столбцам, и база данных поможет вам.

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

Могу ли я порекомендовать, если у вас есть большие объемы двоичных данных, таких как изображения и т. Д., Чтобы вы удалили их и поместили в другое место, например в файловую систему. Или, если вы используете 2008, есть тип, называемый «Файловый поток» (cheers @Marc_s), который позволяет индексировать, хранить и защищать все записываемые вами файлы и использовать API-интерфейсы NTFS для их извлечения (т. Е. Быстрой передачи блоков), но при этом иметь их. хранятся в виде столбцов в базе данных.

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

Просто мой 2с.

Answer 7

Это зависит от того, как вы собираетесь использовать данные, как говорится в предыдущем ответе.

Данные в базе данных могут использоваться для поддержки множества различных типов запросов и передачи результатов в отчеты, формы, механизмы OLAP и множество других видов инструментов. Соответствующая индексация может значительно ускорить поиск.

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

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

Если вы решили использовать базу данных, будьте готовы сделать значительные инвестиции. И убедитесь, что вы получите выгоду от этих инвестиций.