NoSQL для организации хранения и репликации файловой системы? - PullRequest
1 голос
/ 05 мая 2010

Мы обсуждали разработку стратегии хранилища данных в нашей группе для удовлетворения требований тестирования, воспроизводимости и синхронизации данных. Одна из предложенных идей - адаптировать подход NoSQL с использованием существующего инструмента , а не пытаться повторно реализовать то же самое в файловой системе. Я не знаю, является ли подход NoSQL даже лучшим подходом к тому, чего мы пытаемся достичь, но, возможно, если я опишу то, что нам нужно / нужно, вы все можете помочь.

  1. Большинство наших файлов имеют размер более 50 ГБ и хранятся в собственном стороннем формате. Нам нужно иметь доступ к каждому файлу по комбинации имя / дата / источник / время / артефакт. По сути, поиск стиля пары ключ-значение.
  2. Когда мы запрашиваем файл, нам не нужно загружать все это в память. Они действительно слишком велики и могут затопить наш сервер. Мы хотим иметь возможность каким-то образом получить ссылку на файл, а затем использовать собственный сторонний API-интерфейс для получения его частей.
  3. Мы хотим легко добавлять, удалять и экспортировать файлы из хранилища.
  4. Мы бы хотели настроить автоматическую репликацию файлов между двумя серверами (для этого мы можем написать скрипт). То есть синхронизировать содержимое одного сервера с другим. Нам не нужна распределенная система, в которой она выглядит так, как будто у нас один сервер. Мы хотели бы полную репликацию.
  5. У нас также есть другие файлы меньшего размера, которые связаны с типом дерева с большими файлами. Содержимое одного файла будет указывать на следующий и так далее, и так далее. Это не «спицевое колесо», это полноценное дерево.

Мы бы предпочли, чтобы Python, C или C ++ API работали с такой системой, но большинство из нас имеет опыт работы с различными языками. Мы не против, пока это работает, выполняет работу и экономит наше время. Что ты думаешь? Есть ли что-то подобное?

Ответы [ 3 ]

5 голосов
/ 06 мая 2010

Вы смотрели на GridFS MongoDB.http://www.mongodb.org/display/DOCS/GridFS+Specification

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

3 голосов
/ 05 мая 2010

Что не так с проверенной кластерной файловой системой? Блеск и ceph являются хорошими кандидатами.

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

0 голосов
/ 23 марта 2012

Для меня и у Luster, и у Ceph есть некоторые проблемы, которых нет у таких баз данных, как Cassandra.Я думаю, что основной вопрос здесь заключается в том, какой недостаток у Cassandra и других баз данных, подобных тем, что он имеет в качестве бэкэнда FS.Как насчет использования пространства?Консистенция

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...