Ключевое значение хранилища по имени папки

Question

У нас есть в домах noSQL db, которые в основном хранят все в компактном двоичном файле. Теперь мне нужна структура данных, похожая на хранилище ключей или B + Tree. Проблема в том, что «значение» в моем случае может быть разных типов, а размер очень изменчивый, может составлять от 1 Кб до 1-2 ГБ. Обычно ключ является строкой, а значение представляет собой поток данных, может быть потоком int, string или нестандартного типа.

Я думал о внедрении дерева B +, но это непросто, потому что B + Tree нуждается в «значении» того же типа, а размер «значения» должен быть достаточно малым, чтобы его можно было хранить в относительном маленький блок. Там может быть вариант, но я не нашел учебника о том, как реализовать дерево B + с примерами, показывающими, как хранить на диске. Большая часть учебника, который я вижу, - это только B + Tree в памяти.

У меня тогда есть идея использования имени папки/файла в качестве ключа. И тогда значение может быть чем угодно внутри файла. Значения тогда могут быть произвольного размера, это действительно то, что я хочу. Так что мой вопрос здесь, в крайнем случае,

• данные для разных дней хранить в отделенных папках
• я могу иметь 1M-50M ключи (на самом деле файлы/папки), чтобы сохранить на диске в течение дня
• Работа с данными в файлах обычно будет «только для чтения» и «добавляется к» в течение дня. Исторические данные никогда не будут изменены.

Я видел, что у меня может быть ~ 4 миллиарда файлов на современной ОС, поэтому я доволен этим подходом для хранения ~ 2YR на одной машине. Я просто беспокоюсь, если этот способ внедрения хранилища ключей очень плох? Зачем? Какую проблему я могу иметь при работе с файловой системой? (Например, диск Framented на окнах?)

Все они реализованы на C++ в Windows/Linux.

Answer 1

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

Вещи необходимо учитывать

1. OS/Filesystem должна поддерживать требуемую длину папки (ключ) и имя (как вы выбираете)
2. Это фрагмент диска и может задержать доступ к диску для огромные структуры каталогов. Это может повлиять на общий системный процесс.
3. Производительность приложения может ухудшиться, поскольку операция чтения/записи зависит от работы файла - возможно, вы можете добавить кеш в свою программу, если это необходимо.
4. Не подходит для многопоточного применения, блокировка файлов должна быть соблюдена.
5. Безопасность следует соблюдать.

Answer 2

Почему вы обеспокоены величиной w.r.t. Вы можете использовать существующий db. Значение может быть строкой следующего формата: «type | value_data», где «|» является разделителем.

Здесь value_data может быть «фактическое значение» или «путь файла, который содержит значение»

• тип = LOCAL (в данном случае value_data будет фактическое значение, если она может поместиться в дБ)
• type = REMOTE (в этом случае value_data будет путь к файлу)

Answer 3

«Данные для разных дней хранятся в разных папках» - это не удобно, если вы хотите искать один через несколько дней.

Кроме того, у вас могут возникнуть проблемы, когда количество файлов в папке превышает ограничение файловой системы. 4 миллиарда файлов на диске не проблема, 50M в одной папке. Конечно, вам не нужно хранить все в одной папке. Ключ может быть разделен на часть папки и часть имени файла.

Вещи действительно сложны, если вам нужно полагаться на свойство B-Tree найти диапазон ключей. Это означает, что вам нужен заказ, и он не может использовать функцию хеширования для сопоставления ключа с парой/парой файлов. В этом случае у вас есть проблема. Хуже всего то, что ваши ключи только «1» до «999999999» непрерывно, плюс случайный набор гораздо больших ключей. Это означает, что вы не можете использовать последние 4 цифры в качестве имени файла (слишком много папок) или последних 8 цифр (слишком много файлов).