Записывать объемное, реплицированное хранилище значений ключей размером больше памяти

Я ищу хранилище значений ключей, которое можно использовать из экземпляра EC2.

  • элемент - это просто неструктурированная строка, индексация не требуется
  • размер элемента до ~ 5 МБ, но обычно меньше 10 КБ
  • много пишет
  • чтение не должно быть быстрым, кэш памяти можно поставить впереди, чтобы кешировать часто необходимые чтения
  • данные слишком велики, чтобы поместиться в памяти
  • Конечная согласованность в порядке
  • требуется демон, к которому можно получить доступ с нескольких машин

В идеале что-то, что размещено на AWS, было бы идеальным, но:

  • S3 не подходит из-за слишком большого количества операций записи
  • SimpleDB / DynamoDb не подходят из-за ограничений по размеру элементов, и индексация не требуется

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


amazon-web-services nosql key-value-store
person Niko Sams    schedule 18.11.2012    source источник
comment
@ caius.howcroft: что ты имеешь в виду?   -  person Niko Sams    schedule 27.11.2012

Ответы (4)


arrow_upward
6
arrow_downward

Я нашел идеальное решение для своего варианта использования: memcachedb

Он не выполняет причудливых документов / индексирования, это просто простое хранилище значений ключей.

Однако я еще не тестировал производительность.

Изменить:

Мы сбросили memcachedb из-за проблем с репликацией. Вместо этого мы запускаем mongodb. Mongodb требует гораздо больше дискового пространства и ресурсов в целом. Но наборы реплик работают очень надежно и легко настраиваются.

person Niko Sams    schedule 21.11.2012
comment
Вы можете использовать Couchbase, который позволяет очень быстро получить доступ к ключу с использованием протокола memcached. Couchbase позволяет хранить любой тип контента, связанный с ключом. Couchbase 2.0 - это БД, ориентированная на документы, но вы можете хранить любой тип двоичного содержимого в. Ознакомьтесь с этим документом, который поможет вам увидеть некоторые из основных преимуществ: couchbase.com/memcached - person Tug Grall; 24.11.2012
comment
@TugGrall: Я думаю, что это не сработает для моего варианта использования, поскольку данные слишком велики, чтобы поместиться в памяти. - person Niko Sams; 24.11.2012
comment
Если вы выберете Couchbase Bucket, он при необходимости автоматически сохранит контент на диске: couchbase.com/docs/couchbase-manual-1.8/ - person Tug Grall; 24.11.2012
comment
@TugGrall: звучит интересно и соответствует моему сценарию использования. Не могли бы вы создать для этого ответ? - person Niko Sams; 27.11.2012

arrow_upward
2
arrow_downward

Возможно, вам стоит попробовать mongodb:
http://www.mongodb.org/display/DOCS/Amazon+EC2

Быстрый старт:
http://www.mongodb.org/display/DOCS/Amazon+EC2+Quickstart

Бесплатные курсы на 10gen и видеопрезентации:
http://www.10gen.com/presentations/nyc-meetup-group/mongodb-and-ec2-a-love-story

Другие хранилища ключей и значений:
http://google-opensource.blogspot.com/2011/07/leveldb-fast-persistent-key-value-store.html

Комментарии о Riak и их хранилищах, особенно bitcask и innostore:
http://basho.com/blog/technical/2011/07/01/Leveling-the-Field/

RaptorDB: чрезвычайно маленькая и быстрая встроенная база данных устойчивых словарей noSql, использующая b + tree или хеш-индексирование MurMur. Он был в первую очередь предназначен для хранения данных JSON (см. Мою реализацию fastJSON), но может хранить любой тип данных, которые вы ему предоставляете.

HamsterDB: восхитительный движок, написанный на C ++, который произвел на меня сильное впечатление своей скоростью, пока я использовал для индексации код Аарона Уоттерса. (RaptorDB сейчас ест его живьем ... кхм!) Он довольно большой - 600 КБ для 64-битной версии.

Esent PersistentDictionary: проект на CodePlex, который является частью другого проекта, который реализует управляемую оболочку над встроенным механизмом хранения данных Windows esent. Производительность словаря экспоненциально снижается после того, как проиндексировано 40 000 элементов, а индексный файл просто растет с помощью ключей guid. Судя по разговорам с владельцами проекта, на данный момент это известная проблема.

Кабинет Токио / Киото: очень быстрая реализация хранилища ключей на C ++. Tokyo cabin - это индексатор дерева b +, а Kyoto cabin - индексатор хэша MurMur2.

Словарь 4aTech: это еще одна статья о CodeProject, которая делает то же самое, коммерческая версия на веб-сайте огромна (450 КБ) и дает ужасную производительность по ключам guid после 50 000 проиндексированных элементов.

BerkeleyDB: прародитель всех баз данных, принадлежащих Oracle и предлагающих 3 вида: хранилище ключей C ++, хранилище ключей Java и базу данных XML.

(Источник цитаты: http://www.codeproject.com/Articles/190504/RaptorDB )

person 42n4    schedule 20.11.2012
comment
Я рассматривал mongodb, но мне он кажется чрезмерно продуманным: мне не нужно хранить документы, индексировать, уменьшать карту и т. Д. - person Niko Sams; 21.11.2012
comment
Возможно, здесь упоминается Redis или что-то еще: stackoverflow.com/questions/ 1733619 / writing-a-key-value-store - person 42n4; 21.11.2012
comment
Мне нужен сервер. Redis не работает, поскольку мои данные слишком велики для хранения в памяти. - person Niko Sams; 21.11.2012
comment
Некоторые комментарии о leveldb и других хранилищах (riak использует его как хранилище для каждого узла): google-opensource.blogspot.com/2011/07/ - person 42n4; 21.11.2012
comment
MongoDB не предназначен для тяжелых операций записи - больше для тяжелых операций чтения и расширенных запросов json. - person mrówa; 27.11.2012

arrow_upward
2
arrow_downward

Похоже, идеальный вариант использования HBase. Это дает большую пропускную способность записи, особенно если ваши ключи вставки несколько случайны. HBase обычно не рекламируется как магазин K / V, но он должен работать нормально. В документации AWS представлены некоторые варианты использования, которые могут потребоваться посмотрим поближе. Обратной стороной является то, что HBase может намного больше, чем просто K / V, поэтому он может быть более сложным (и сложным), чем то, что вам нужно.

person michaelku    schedule 27.11.2012

arrow_upward
1
arrow_downward

Couchbase кажется подходящим вариантом для ваших нужд. Это очень похоже на memcached с дисковым хранилищем.

Плюсы:

  • Это база данных ключ / значение. Вы можете хранить любой двоичный объект, который хотите. Начиная с версии 2.0 он поддерживает хранение ваших данных в формате json и выполнение некоторых запросов и отображение / сокращение на нем. Но, если вам это не нужно, можно использовать его как ключ / значение.

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

  • По моему опыту, это было надежно. Если узел выходит из строя, кластер продолжает работать, и выполнить аварийное переключение очень просто. Добавить новые узлы тоже довольно просто.

  • Данные не обязательно помещаются в памяти. Он сохраняется на диске и выгружается и выгружается по мере необходимости.

  • Интерфейс администратора очень и очень приятный. Он имеет отличные живые графики для мониторинга кластера.

  • Он обратно совместим с протоколом memcached. Если у вас уже есть код, использующий memcached, было бы довольно просто использовать вместо этого Couchbase.

Минусы:

  • Продукт еще молод, поэтому документации и инструментов поддержки не хватает. Иногда это может немного раздражать.
person Ari    schedule 27.11.2012