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

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

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

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

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

Я не думаю, что есть решение этого:)

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

Храните публичное объявление в файле заголовка. Переместите реализации в файл cpp. Пометить ранее частные методы как статические . Это сделает их недоступными из других объектов компоновщика (единиц компиляции) и будет эффективно скрывать их.

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

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

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

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

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

В зависимости от ваших затрат, MS SQL Server имеет так называемый "Primary XML Index", который может быть создан даже на неструктурированных данных. Это позволяет записывать XQuery для поиска по столбцам, и база данных поможет вам.

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

Могу ли я порекомендовать, если у вас есть большое количество двоичных данных, таких как изображения и т.д., удалить их и поместить в другое место, например, в файловую систему. Или, если вы используете 2008, есть тип под названием "Filestream" (cheers @Marc_s), который позволяет вам индексировать, хранить и обезопасить все записываемые файлы, а также использовать NTFS API для их извлечения (т.е. быстрой блочной передачи), но при этом хранить их в базе данных в виде столбцов.

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

Только мои 2c.

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

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

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

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

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

Попробуйте Googling для этих технологий.

На работе я часто должен накапливать большие наборы документов XML для более позднего анализа. Обычно это делается, придерживая их в каталог, и анализ сделан GreeP (или программой java на заказ со всеми его XML-фабрикой / Builder / Partper / API).

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

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

Что касается первой функции, размер БД был менее половины размера необработанных файлов. Делая полный текстовый поиск, табличное сканирование с использованием , где данные :: текст, как «% Pattern%» , был фактически быстрее, чем запустить GREP на файлах. Когда вы имеете дело с несколькими ГБ XML, это только делает DB стоимостью.

Вторая функция, индексирование, немного больше работы для обслуживания. Было несколько конкретных элементов, которые я догадался, было бы хорошо для индекса. Индекс на XPath ('// Tradeheader / TradeDID / Text ()', данные) работает, но это может быть боль для дублирования в каждом запросе. Мне было легче добавить обычные столбцы для некоторых полей, и используйте триггеры вставки / обновления, чтобы они сохраняли их в синхронизации.