Bitcask хорошо для простого и высокопроизводительного хранилища файлов? - PullRequest
Новая
       7

Bitcask хорошо для простого и высокопроизводительного хранилища файлов?

6 голосов
/ 15 мая 2011

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

Наши требования:

  1. Возможность хранить миллионы xml-файлов в пакетном процессе.XML-файлы могут иметь размер до нескольких мегабайт, большинство из которых находятся в диапазоне 100 КБ.
  2. Очень быстрый случайный поиск по идентификатору (например, URL документа)
  3. Доступен как для Java, так и для Perl
  4. Доступно на самых важных Linux-дистрибутивах и Windows

Я взглянул на несколько платформ NoSQL (например, CouchDB, Riak и другие), и в то время как тесистемы выглядят великолепно, они кажутся почти лишними:

  1. Не требуется кластеризация
  2. Не требуется демон ("служба")
  3. Не требуется интеллектуальная функция поиска

Погрузившись глубже в Риак, я нашел Bitcask (см. intro ), который, похоже, именно то, что я хочу.Основы, описанные во введении, действительно интригуют.Но, к сожалению, нет средств для доступа к репозиторию Bitcask через Java (или есть?)

Так что мой вопрос сводится к

  • , верно ли следующее предположение: модель Bitcask (записи только для добавления, управление ключами в памяти) - это верный способ хранения / извлечения миллионов документов
  • Существуют ли какие-либо жизнеспособные альтернативы Bitcask, доступные через Java?(На ум приходит BerkleyDB ...)
  • (для специалистов по riak). Является ли Riak более затратным в плане внедрения / управления / ресурсов по сравнению с "голым" Bitcask?

Ответы [ 2 ]

5 голосов
/ 15 мая 2011

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

Проблема в процессе слияния файлов данных Bitcask. Это включает в себя копирование всех текущих значений из ряда «старых файлов данных» в «объединенный файл данных». Если у вас есть миллионы значений в области 100 Кбайт каждый, это безумное количество копирования данных.

4 голосов
/ 17 мая 2011

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

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

Я не уверен в состоянии версии / оболочки Java.

...