Используется в одном из наших проектов такая штучка как Project Voldemort.
Если вкратце, то это весьма любопытная реализация key-value storage aka NoSQL database, реализованная в недрах Linkedin. То есть даешь ему ключик и значение, и оно быстро в памяти это хранит/отдает и на диске тоже сохраняет. Интересна она, в принципе, не этим, а своей реализацией кластеризации, неплохой скоростью, ну тем что часто используется в проектах на Java. В принципе, подробного обзора этой БД на Хабре не было, и можно как нибудь сделать. Но рассказать я тут хочу пока о одних граблях, с которыми пришлось столкнуться.

The Little Redis Book — это бесплатная книга про Redis.

Книга была написана Karl Seguin, при поддержке Perry Neal. Karl Seguin является также автором книги The Little MongoDB Book, которую часто рекомендуют для быстрого старта с MongoDB. Первая версия повилась около недели назад.

Сегодня я сделал первую версию перевода этой книги. Исходные тексты доступны в репозитории на GitHub. Там же можно найти и готовый PDF.

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

Я благодарен следующим людям за помощь в переводе оригинального текста и вычитке результата:

• Dmitry Scriptin
• Денис Веселов
• polinom

Я прошу все неточности и опечатки отправлять для коррекции перевода.

Вчера Karl Seguin – автор книги The Little MongoDB Book, которую часто рекомендуют для быстрого старта с MongoDB, опубликовал аналогичное руководство для Redis под названием The Little Redis Book (при участии Perry Neal). Книга состоит из 29 страниц, написанных за 2 коротких дня с использованием Markdown. Исходная разметка книги находится на GitHub. Сама книга распространяется свободно под лицензией Attribution-NonCommercial 3.0 Unported license.

Содержание книги

• About This Book
• Introduction
• Chapter 1 — The Basics
• Chapter 2 — The Data Structures
• Chapter 3 — Leveraging Data Structures
• Chapter 4 — Beyond The Data Structures
• Chapter 5 — Administration
• Conclusion

Скачать

The Little Redis Book (PDF)

Статья "Недопонимание CAP-теоремы" и комментарии к ней свидетельствуют, что непонимание действительно есть. И связано оно не только с неправильным толкованием термина «partitioning», но и с ментальными ошибками на других уровнях. Попробую внести ясность.

В последнее время я довольно часто натыкаюсь на данную теорему. Она довольно давно доказана и про нее много чего написано. Однако каждый раз когда я натыкаюсь на распределенную систему, претендующую в описании на CA в терминах данной теоремы, т.е. систему в которой жертвуют Partition Tolerance в угоду Consistency и Avalability, я зависаю, так как хоть убейте не могу себе представить такого зверя. После долгих раздумий я все же пришел к выводу, что такая система бессмысленна, о чем и хочу порассуждать в данном топике.

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

Каково будущее CouchDB? Это Couchbase.

Удивлены? Спросите, как же Apache CouchDB? Что ж, это отличный проект. Я основал его, написал первые версии почти полностью самостоятельно, потратил огромное количество нервов, пота и крови на него. Я очень им горжусь и тем влиянием, которое у него было. А сейчас я и команда Couchbase готовы двигаться дальше. Конечно, CouchDB — отличная система, но мы делаем его наследника: Couchbase Server. Продукт и проект с похожими возможностями и задачами, но более быстрый, более масштабируемый, более подходящий и для пользователей, и для разработчиков. И, определённо, не часть Apache.

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

Внимание! Исследования проводились не для понимания, зачем мне это нужно, а для понимания как оно работает!

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

В данной статье речь пойдет о том, как подготовить Redis, phpredis (С модуль для php) и phpRedisAdmin для работы на боевом сервере.

Для того, чтобы собрать все полноценно, нам нужно иметь на сервере:

• gcc 4.5.2 (Я компилировал под этой версией, но думаю, что с другими проблем не возникнет)
• Make 3.81 (Опять же, версия не принципиальна)
• php5-dev (Версия должна совпадать с версией php)

После того, как мы убедимся, что все зависимости удовлетворены, начинаем собирать все компоненты.
Нам потребуются:

• Redis 2.4.4 Stable
• phpredis 2.1.3
• phpRedisAdmin

Tarantool — это крайне интересная база данных.
Представление о ней можно получить из доклада Константина Осипова Tarantool: как обрабатывать 
1,5 млрд запросов в сутки?

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

Как часть своей платформы для веб разработки Microsoft предоставляет и NoSQL решение для кэширования — AppFabric Cache. Одним из интересных режимов AppFabric Cache является High Availability — возможность создать кластер из кэш-серверов где в случае падения любого из них работа вашей службы не прерывается и все данные остаются доступными приложению. Когда вы создаете .NET веб-приложение без единой точки сбоя (single point of failure), использование такого кэш сервера кажется легким и естественным решением. Особенно здесь может радовать цена, так как AppFabric предоставляется компанией Microsoft бесплатно как часть своей операционной системы. Однако выбирая решение для кэширования полезно видеть не только то что на поверхности.

Sterling NoSQL OODB — это легковесная объектная NoSQL БД, предназначенная для использования в проектах на .NET 4.0, Silverlight 4/5 и Windows Phone 7.

Появилась задача: имеется большой поток данных от множества клиентов, который нужно обработать очень быстро (желательно в реалтайме), сложить в БД и разослать другому множеству клиентов, при этом данные не структурируются ни в таблицы, ни в документы. Выбор технологий для реализации пал на Redis + C++.

Этот текст является вольным переводом замечательного поста Kaushik Sathupadi на тему распределённых систем и существующих ограничений при их создании.

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

Часть №1: Идея нового сервиса — «Позвони, напомню!»

Вчера, когда ваша супруга в очередной раз оценила тот факт, что вы вспомнили о её дне рождения и подарили шикарный подарок, в голове всплыла забавная идея. «Хм, а ведь люди вечно всё забывают». А у вас просто блестящая память! Почему бы не сделать новый сервис, который позволит полностью раскрыться вашему таланту? С каждой мыслью об этой идее вам всё больше и больше она нравится. Вы уже даже придумали рекламу, которую можно было бы напечатать в газете:

«Позвони, напомню» — Никогда не забывайте, даже если вы не помните, что забыли!
Плохо себя чувствуете из-за того, что вы что-то забыли? Не переживайте. Помощь на расстоянии одного телефонного звонка!
Если вам нужно что-то запомнить, просто позвоните и сообщите нам об этом! Допустим, позвоните нам и сообщите телефон вашего босса. Забудьте про него. Когда вам нужно будет вспомнить его, перезвоните, и мы вам обязательно напомним.
Всего 3 рубля за звонок.

Типичное обращение в ваш сервис выглядело бы вот так:

Статья Dynamo: Amazon’s Highly Available Key-value Store была опубликована в блоге технического директора Amazon Вернер Фогельса /Werner Vogels/ четыре года назад. Эта публикация послужила толчком для развития таких широко известных проектов, как Cassandra, Riak, Voldemort. Концепции, описанные в этой статье, и сейчас не потеряли актуальности.

Первый раз я ее прочитал по диагонали где-то пару лет назад. А сейчас решил перечитать более внимательно, и это вдумчивое чтение как-то само собой вылилось в перевод.

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

На рынок NoSQL подтягиваются большие игроки. На сайте Oracle Corp. появилось описание нового продукта — Oracle NoSQL database. Пока документации нет, самого сервера (по крайней мере community edition) нет, но должно появиться «к середине октября».

Но по тому, что уже выложено, можно составить определенное впечатление:

Несколько часов назад ко мне в почту упало письмо с уведомлением о новом сервисе от компании 10gen, спонсоров MongoDB. Этот облачный сервис позволяет мониторить ваши сервера и слать алерты, если что-то пойдет не так.

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

Краткое описание базы

База данных Eloquera с самого начала была написана для хранения объектов  на основе .Net Framework, что сделало возможным попытаться вобрать в себя все лучшее от объектных и реляционных баз данных одновременно, преодолев многие их различия. Теоретически Eloquera может работать с любыми языками из семейства .Net Framework, однако на практике работа проверялась пока только с C#. Главная ориентированность разработчиков на enterprise сегмент (100+ ГБ), а не на embedded решения, хотя последние тоже не обделены вниманием.

Отличительные особенности Eloquera весьма внушительны и постоянно пополняются, вот их очень краткий список:

• Сохраняет C# объекты (любые объекты любого языка на .Net платформе) без необходимости реализации специальных интерфейсов и адаптеров.
• Сохраняет Dynamic объекты с любыми полями\свойствами и может сопоставить их объектам любого типа.
• Язык запросов максимально приближен к SQL, при этом не требуется наличие какой либо реляционной SQL базы. Плюс поддержка LINQ.
• Возвращает объекты в том виде, в котором они были сохранены (включая перечислимые типы)
• Поддержка параметров в виде списков и массивов
• Регулярные выражения в запросах.
• Поддержка шаблонных объектов.
• Восстановление Read-only полей и свойств.
• Поддерживается частичный возврат объектов. Например, если вам требуется класс ForumTopic, тогда можно не подтягивать все ссылки на ForumMessages.
• Можно указать глубину объекта для возврата в запросе.
• Хранимые процедуры.

Агентство национальной безопасности США предоставило на рассмотрение фонда Apache Software Foundation свой проект Accumulo. Это распределённая СУБД, созданная на основе дизайна Google BigTable с использованием кода Hadoop, Zookeeper и Thrift. Дизайн BigTable обнародован в 2006 году, работа над Accumulo началась в 2008-м, причём он изначально задумывался как свободный проект с использованием открытых библиотек.

Главным улучшением Accumulo по сравнению с BigTable является продвинутая система разграничения прав доступа на уровне отдельных ячеек (cell-level access labels). Различные пользователи могут получать доступ только к определённым полям базы данных, которым присвоен соответствующий уровень доступа (labels).

Riak это NoSQL решение, честная DHT (key/value storage) с дополнительными возможностями для разруливания конфликтов.

У распределенной хеш таблицы есть как плюсы, так и минусы. DHT хорошо масштабируется, но возможны потери данных из-за конфликтов конкурентного доступа, рассмотрим следующий пример:

client a: def o-value = DHT.get("some-key");
client a: def a-value = changeValue(o-value);
client b: def o-value = DHT.get("some-key");
client a: DHT.put("some-key", a-value);
client b: def b-value = changeValue(o-value);
client b: DHT.put("some-key", b-value);

Получилось, что клиент b переписал данные клиента a и никто об этом не знает (ни a, ни b, ни тот, кто прочтет данные по этому ключу позже).

Так как многие NoSQL базы данных в своей основе имеют DHT, интересно смотреть как они пытаются решить проблему конкурентного доступа.

Например, MongoDB использует compare-and-swap стратегию: с каждым документом (значением) храниться его версия, при обновлении указывается версия «предка» измененного документа, если в базе в момент обновления храниться предок, то обновление проходит, если нет, то нет: обновляющая сторона получает сообщение, и пытается провести обновление снова — аналог STM. Такой подход хорошо работает с шардами, но плохо с репликацией.

Riak решает проблему конкурентного доступа подобно системам контроля версий, он, как бы, сохраняет конфликтные версии в разных бранчах, предоставляя программе при следующей выборке провести merge. Такой подход позволяет разрешать конфликты, связанные не только с конкурентным доступом, но и с времянной изолированостью части кластера (partition tolerance: кластер машин может распаться на две части, обе части будут работать и смогут без проблем объединиться в будущем).

Riak накладыват больше условий на разработку, но обеспечивает масштабируемость и надежность данных при работе с большим объемом информации. Статья опишет, как «обойти» ограничения Riak при разработке типичных web приложений.