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

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

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

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

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

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

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

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

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

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

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

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

Чтобы сделать список полным: есть еще Dreamcache. Он совместим с Memcached (в плане протокола, так что вы можете использовать любую клиентскую библиотеку, написанную для Memcached), просто он быстрее.

Мне лично очень нравится memcached .

Я использую его на нескольких своих сайтах, и это просто, быстро и легко. Это действительно было просто невероятно просто, API прост в использовании. Он ничего не хранит на диске, отсюда и имя memcached, поэтому его нет, если вы ищете механизм постоянного хранения.

Python имеет python-memcached .

Я не использовал клиент Ruby, но быстрый поиск в Google показывает RMemCache

Если вам просто нужен механизм кэширования, то вам подойдет memcached. Он развит, стабилен и быстро истекает кровью. Есть причина, по которой LiveJournal сделал это, а Facebook развивает. Он очень эффективно используется на некоторых из крупнейших сайтов. Он очень хорошо масштабируется.

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

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

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

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

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

Существует также zodb.

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

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

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

Кассандра кажется популярной.

Cassandra используется в Digg, Facebook, Twitter, Reddit, Rackspace, Cloudkick, Cisco, SimpleGeo, Ooyala, OpenX и других компаниях, которые имеют большие активные наборы данных. Самый большой производственный кластер содержит более 100 ТБ данных на более чем 150 машинах.

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

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

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

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