Масштабное хранилище для постепенно добавляемых документов?

Question

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

Доступ для чтения - это некоторое подмножество документа, которое почти всегда начинается на полпути в некотором проиндексированном месте (например, «документ № 4324319, сохранение # 53 до конца»).

Эти документы начинаются с малого, с нескольких килобайт. Обычно они достигают конечного размера около 500 КБ, но многие достигают 10 МБ или более.

В настоящее время я использую MySQL (InnoDB) для хранения этих документов. Каждое из добавочных сохранений просто сбрасывается в одну большую таблицу с идентификатором документа, которому он принадлежит, поэтому чтение части документа выглядит как «выбрать * из сохранений, где document_id = 14 и save_id> 53 упорядочить по save_id», а затем объединить его все вместе в коде.

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

Я рассматривал CouchDB и MongoDB как возможные замены для MySQL, но я не уверен, что любой из них имеет большой смысл для этого конкретного приложения, хотя я открыт для убеждения.

Какой-нибудь вклад в хорошее решение для хранения?

Answer 1

Звучит как идеальная проблема, которую нужно решить HBase (через HDFS).

Недостатком является, среди прочего, несколько крутая кривая обучения.

Answer 2

Проверьте нашу SolFS виртуальную файловую систему. Это будет хорошо работать в ваших условиях.

Answer 3

ОК, сначала предостережение, MongoDB имеет ограничение на размер документа.Тем не менее, самая новая версия будет охватывать ваш размер 10 МБ.

Так что некоторые полезные моменты для MongoDB .

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

Для репликации MongoDB поддерживает наборы реплик .Наборы реплик - это реплики с одним мастером.Если мастер отключается, система автоматически выбирает нового мастера (простое восстановление).Добавление нового узла так же просто, как запуск нового сервера и указание на существующий набор.

Для горизонтальной масштабируемости MongoDB поддерживает sharding .Sharding немного сложнее, но работает так, как вы ожидаете, разделяя записи на несколько машин (или несколько наборов реплик).

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

В нескольких компаниях Mongo запущено миллиарды документов.

Mongo предлагает серию модификаторов обновления , которые очень полезны в случае , добавленного к .В частности, проверьте оператор $ push, который добавляет в конец массива.Должно быть именно то, что вам нужно.

Доступ к чтению является некоторым подмножеством документа, который почти всегда начинается на полпути в некотором проиндексированном месте (например, «документ № 4324319, сохранить № 53 до конца»).

MongoDB позволяет вам возвращать только выбранные поля (как и ожидалось).В зависимости от вашего макета вы можете использовать точечную нотацию для получения только определенных поддокументов.Если ваши обновления реализованы в виде массивов, вы также можете использовать команду $ slice , которая хорошо подходит для запроса, который вы перечислили выше.

Так что я думаю, что MongoDB отвечает всем вашим основным потребностямВот.Легко добавлять, легко запрашивать эти добавления, и встроенная репликация. Вы получаете горизонтальное масштабирование с помощью шардинга (попробуйте сначала начать с реплики)

Answer 4

Моя непосредственная мысль - зачем хранить их в базе данных? Сохраняет ли их хранение в базе данных лучшую производительность при поиске, чем в файловой системе при работе с таким количеством файлов?

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

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

Если узел недоступен или файл не существует, балансировка нагрузки может «переключиться» на следующую строку. Корневые каталоги также могут быть помечены как отключенные для запланированных отключений, если код чтения / записи соблюдает это. То же самое можно также использовать для разбиения, когда x число корневых каталогов служит нечетным идентификатором, а x number служит четным идентификатором в качестве простого примера.

Обеспечение синхронизации узлов может быть также закодировано с использованием метаданных.

Только мои 2 цента, поскольку я никогда не имел дело с таким объемом файлов.

Answer 5

Есть ли какая-то причина, по которой вам вообще нужна база данных?

Вы описываете «систему хранения документов с уникальными именами», поэтому я начал думать, что «файловая система».Может быть, что-то вроде файлового сервера (ов) корпоративного класса (я оценил максимум 200 ТБ данных), где уникальный идентификатор - это каталог и имя файла в сети.