Какой магазин ключей / значений наиболее перспективен / стабилен?

Question

Я рассчитываю начать использовать хранилище ключей / значений для некоторых побочных проектов (в основном для обучения), но в недавнем прошлом появилось так много, что я понятия не имею, с чего начать. Просто перечисляя по памяти, я могу думать о:

1. CouchDB
2. MongoDB
3. Riak
4. Redis
5. Токийский кабинет
6. Berkeley DB
7. Cassandra
8. MemcacheDB

И я уверен, что есть еще что-то, что ускользнуло от моих поисков. Имея всю информацию, трудно найти надежные сравнения между всеми конкурентами. Мои критерии и вопросы:

1. (самое важное) Что вы рекомендуете и почему ?
2. Какой из них самый быстрый?
3. Какой из них наиболее стабилен?
4. Какой из них проще всего установить и установить?
5. Какие из них имеют привязки для Python и / или Ruby?

Edit:
Пока что Redis кажется лучшим решением, но это только потому, что я получил один солидный ответ (от ardsrk). Я ищу больше ответов, таких как его, потому что они указывают мне на полезную количественную информацию. Какой магазин ключей-значений вы используете и почему ?

Редактировать 2:
Если у кого-то есть опыт работы с CouchDB, Riak или MongoDB, я хотел бы услышать ваш опыт общения с ними (и тем более, если вы можете предложить сравнительный анализ нескольких из них)

Answer 1

Что вы рекомендуете и почему?

Я рекомендую Redis. Зачем? Продолжить чтение !!

Какой из них самый быстрый?

Я не могу сказать, самый ли это быстрый. Но Redis быстрый . Это быстро, потому что он содержит все данные в оперативной памяти. Недавно была добавлена ​​функция виртуальной памяти, но все же все ключи остаются в основной памяти, и только редко используемые значения записываются на диск.

Какой из них наиболее стабилен?

Опять же, поскольку у меня нет прямого опыта работы с другими магазинами значений ключей, я не могу сравнивать. Однако Redis используется в производстве многими веб-приложениями, такими как GitHub и Instagram и многими другими.

Какой из них проще всего установить и установить?

Redis довольно прост в настройке. Возьмите source и на Linux-компьютере запустите make install. Это дает redis-server двоичный файл, который вы могли бы положить на свой путь и запустить его.

redis-server по умолчанию привязывается к порту 6379. Взгляните на redis.conf, который поставляется с источником, чтобы получить больше настроек и параметров настройки.

Какие из них имеют привязки для Python и / или Ruby?

Redis имеет отличную поддержку Ruby и Python .

В ответ на комментарий Xorlev ниже: Memcached - это просто хранилище значений ключей. Redis поддерживает сложные типы данных , такие как списки, наборы и отсортированные наборы, и в то же время предоставляет простой интерфейс для этих типов данных.

Существует также make 32bit, который делает все указатели только 32-битными по размеру даже на 64-битных машинах. Это значительно экономит память на машинах с объемом оперативной памяти менее 4 ГБ.

Answer 2

Вы должны понимать, что такое современный феномен NoSQL.
Это не о хранилищах ключей-значений. Они были доступны в течение десятилетий (например, BerkeleyDB). Почему вся эта суета сейчас?

Речь идет не о причудливых документах или объектно-ориентированных схемах, а о преодолении "несоответствия импеданса". Сторонники этих функций рекламировали их годами, и они ни к чему не привели.

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

В противном случае вы потеряете все хорошее, что дает вам sql (специальные запросы, Crystal Reports для вашего босса, сторонние инструменты и библиотеки), и ничего не получите взамен.

Answer 3

В этом году на PyCon Джереми Эдберг из Reddit выступил с докладом:

http://pycon.blip.tv/file/3257303/

Он сказал, что Reddit использует PostGres в качестве хранилища значений ключей, предположительно с простой таблицей из 2 столбцов; согласно его разговору, тестирование проводилось быстрее, чем в любом другом хранилище ключей-значений, которое они пробовали. И, конечно же, он очень зрелый.

В конечном счете, OverClocked - это правильно; Ваш вариант использования определяет лучший магазин. Но RDMBS давно (ab) используются в качестве хранилищ значений ключей, и они тоже могут быть очень быстрыми.

Answer 4

Я играл с MongoDB, и у него есть одна вещь, которая делает его идеальным для моего приложения, возможность напрямую хранить сложные Карты / Списки в базе данных. У меня есть большая карта, где каждое значение является списком, и мне не нужно делать ничего особенного, только чтобы написать и получить это, не зная всех различных ключей и значений списка. Я не знаю много о других вариантах, но скорость и эта способность делают Mongo идеальным для моего приложения. Кроме того, драйвер Java очень прост в использовании.

Answer 5

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

Сложно сравнивать. Вы должны спросить себя, что вам нужно: например, ты хочешь разметить? если так, то некоторые из них, такие как CouchDB, не будут поддерживать его. Вы хотите стереть кодирование? Тогда у большинства из них этого нет. И т.д.

Berkeley DB - это базовый механизм хранения низкого уровня, который, возможно, можно извинить из этого обсуждения. На его основе построено несколько систем ключ-значение для предоставления дополнительных функций, таких как репликация, управление версиями, кодирование и т. Д.

Кроме того, что нужно вашему приложению? Некоторые из решений содержат сложность, которая не может быть необходимой. Например. если вы просто храните статические данные, которые не будут меняться, вы можете хранить их под хешем содержимого SHA-1 (т. е. использовать хеш контента в качестве ключа). В этом случае вам не нужно беспокоиться о свежести, синхронизации, управлении версиями и множестве сложностей, которые можно устранить.

Answer 6

Я замечаю, как все путают memcached с memcachedb. Это две разные системы. Оператор спросил о memcachedb.

memcached - это память. memcachedb использует Berkeley DB в качестве хранилища данных.

Answer 7

Одно различие, которое вы должны сделать, это то, для чего вы будете использовать БД? Не прыгайте на борт только потому, что это модно. Вам нужно хранилище значений ключей? или вам нужен магазин на основе документов? Каковы ваши требования к памяти? запустить его на маленькой виртуальной машине или на отдельной?

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

С учетом сказанного я использовал CouchDB / MongoDB и предпочитаю использовать MongoDB для простоты настройки и лучшего перехода от запросов в стиле mysql. Я выбрал mongodb вместо sql из-за динамических схем (без файлов миграции!) И лучшего моделирования данных (массивы, хэши). Я не оценивал на основе масштабируемости.

MongoMapper - отличный инструмент отображения MongoDB для Ruby, и уже есть работающий форк Rails 3.

Я перечислил некоторые подробности о том, почему я предпочел mongodb в моих слайдах scribd. http://tommy.chheng.com/index.php/2010/02/mongodb-for-natural-development/

Answer 8

У меня есть опыт работы только с Berkeley DB, поэтому я упомяну, что мне в нем нравится.

• Это быстро
• Очень зрелый и стабильный
• Имеет выдающуюся документацию
• Он имеет привязки C, C ++, Java & C # из коробки. Другие языковые привязки доступны. Я полагаю, что Python поставляется с привязками как часть "батарей".

Единственный недостаток, с которым я столкнулся, это то, что привязки C # являются новыми и, кажется, не поддерживают все функции.

Answer 9

Какое хранилище значений ключей является наиболее перспективным / стабильным?

Магазин G-WAN KV выглядит довольно многообещающе :

DB engine            Traversal
-----------          ----------------------------
SQLite               0.261 ms  (b-tree)
Tokyo-Cabinet (TC)   4.188 ms  (hash table)
TC-FIXED             0.103 ms  (fixed-size array)
G-WAN KV             0.010 ms  (unamed)

Кроме того, он используется внутренне веб-сервером G-WAN, известным своими высокими показателями параллелизма (это вопрос стабильность ).

Answer 10

Есть также зодб.