Подтвердить что ты не робот

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

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

  • CouchDB
  • MongoDB
  • Riak
  • Redis
  • Токийский кабинет
  • Berkeley DB
  • Cassandra
  • MemcacheDB

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

  • (наиболее важно) Что вы рекомендуете и почему?
  • Какой из них самый быстрый?
  • Какой из них наиболее стабильный?
  • Какой из них проще всего настроить и установить?
  • У кого есть привязки для Python и/или Ruby?

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

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

4b9b3361

Ответ 1

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

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

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

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

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

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

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

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

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

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

Redis имеет отличный Ruby и поддержка Python.

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

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

Ответ 9

Существует также зодб.

Ответ 10

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

Магазин 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, известного своими высокими показателями concurrency (для стабильности).

Ответ 11

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

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

Python имеет python-memcached.

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

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

Ответ 12

Cassandra кажется популярным.

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

Ответ 13

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

Ответ 14

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

Сначала я использовал memcached для быстрого доступа к чтению/записи. Как API Java, я использовал SpyMemcached, что поставляется с очень простым интерфейсом, который вы можете использовать для записи и чтения данных. Из-за утечек памяти (не больше ОЗУ) мне требовалось искать другое решение, также я не мог масштабировать вправо, просто увеличение памяти для одного процесса, казалось, не было хорошим достижением.

После некоторого обзора я увидел couchbase, он поставляется с репликацией, кластеризацией, автоматическим откатом и публикацией сообщества (MS Windows, MacOs, Linux). И самое лучшее для меня было, клиент Java из него реализует также SpyMemcached, поэтому мне больше нечего было делать, как настроить сервер, и использовать couchbase вместо memcached как хранилище данных. Преимущество? Конечно, мои данные теперь постоянны, реплицируются и индексируются. Он поставляется с веб-консолью для записи функций сокращения карты для просмотра документов в erlang.

Он поддерживает Python, Ruby,.Net и многое другое, упрощает настройку с помощью веб-консоли и клиентских инструментов. Он работает стабильно. С некоторыми тестами я смог записать около 10 тыс. В секунду для записей размером 200-400 байт. Показатели чтения были выше, хотя (оба тестировались локально). Примите много удовольствия, приняв ваше решение.

Ответ 15

Только опыт работы с mongoDB, memchache и redis. Здесь сравнение между ними и couchDB.

Кажется, mongoDB является самым популярным. Он поддерживает очертание и репликацию, в конечном итоге последовательную, имеет хорошую поддержку в рубине (мангоиде). Он также имеет более богатый набор функций, чем два других. Все mongo, redis и memchache могут хранить значение ключа в памяти, но redis, кажется, намного быстрее, согласно этому сообщению, redis - 2x write, 3x read быстрее, чем монго. Он имеет более совершенные структуры данных и более "легкий".

Я бы сказал, что у них разные способы использования, mongoDB, вероятно, хорош для большого набора данных и хранения документов, а memchache и redis лучше хранить кеши или журналы.