Использование файловой системы (не базы данных!) Для данных без схемы - передовой опыт

Question

Прочитав мой второй вопрос, Использование реляционной базы данных для данных без схемы , я начал задумываться, подходит ли файловая система более подходящей, чем реляционная база данных для хранения и запросов данные без схемы.

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

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

Где я могу найти больше ресурсов о том, как реализовать бессхемовую (или «ориентированную на документы») базу данных в качестве слоя поверх файловой системы? Кто-нибудь использует современную файловую систему в качестве базы данных без схемы?

Answer 1

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

плюсы: - - простой, интуитивно понятный.

• использует многолетние алгоритмы настройки и кэширования
• легкое резервное копирование, потенциально простая кластеризация

о чем подумать:

• богатство метаданных - какие типы данные хранят, как позволяют вы запрашиваете их, вы можете иметь иерархические или многозначные атрибуты

• скорость запроса метаданных - не все фс особенно хорошо оптимизированы с любым, кроме размера, даты.

• невозможность присоединения к запросам (хотя это довольно часто встречается в NoSQL)

• неэффективное использование хранилища (кроме файла система выполняет перераспределение блоков, вы обычно дуете 4-16 КБ за единицу хранится независимо от размера)

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

Answer 2

Вы можете ознакомиться с нашей Solid File System , которая представляет собой продукт виртуальной файловой системы со встроенной поддержкой метаданных файлов и механизм поиска, подобный SQL, который осуществляет поиск по этим данным. Также, пожалуйста, прочитайте статью , которая описывает преимущества хранения разных типов данных в разных видах хранилищ.

Answer 3

На Amazon S3 есть большой пример реализации.

http://aws.amazon.com/s3/

К такому внедрению стремятся многие компании, потому что он существенно масштабируется лучше, чем реляционная база данных. Подход прост и работает, а для некоторых проблем это отличное решение. В случае Amazon S3 это особенно хорошо для облачного хранилища, если вы не хотите беспокоиться о хлопотах по хранению данных самостоятельно.

Answer 4

Одной вещью, которую вы можете принять во внимание, является тип данных Oracle BFILE, который является указателем на файл на диске.Возможно, это может быть лучшим из обоих миров?Сервер Microsoft SQL, по-видимому, не предоставляет такую ​​возможность.