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

В данной статье речь пойдет о том, как подготовить 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 приложений.

Компания Google открыла исходные коды LevelDB — это созданный в Google быстрый движок (библиотека) для работы с хранилищем пар ключ-значение.

Библиотеку LevelDB на C++ можно использовать для разных целей. Например, веб-браузер может обрабатывать с помощью LevelDB кэш недавно посещённых страниц. Операционная система — список установленных пакетов и зависимостей между ними, а любое приложение может использовать LevelDB для хранения пользовательских настроек.

HandlerSocket — это noSQL-плагин для mySQL, позволяющий обращаться к базам данных в обход уровня SQL.

Данная статья предназначена для тех, кто успешно поставил HandlerSocket и php-handlersocket, а также столкнулся со скудным мануалом и странным поведением этого плагина для php.

Где-то год назад при разработке нашего проекта мы дошли до некой точки развития, когда или начинается кропотливая настройка и оптимизация MySQL-сервера, или начинается опять же кропотливое изучение запросов, которые идут в БД. Так получилось, что именно тогда был бум статей про MongoDB, CouchDB и прочие NoSQL базы данных и соблазн попробовать их на живом проекте был крайне велик.

При выборе главную роль сыграла фраза «CouchDB предназначен именно для веба», а также то, что для доступа не требовались никакие прослойки — доступ осуществляется по любимому мной REST, а API выглядит очень простым и изящным. Вдобавок к этому CouchDB имеет крайне удобный веб-интерфейс для администрирования Futon, чего на тот момент не было у MongoDB, а также железную устойчивость к падениям.

Забегая вперед скажу, что выбор полностью себя оправдал — мы избавились от огромного количества проблем при разработке и проектировании БД, код проекта сильно упростился и стал гораздо лучше структурирован, но самое главное — тот самый поворот в сознании, который нам дал CouchDB. За это время я лично набил множество шишек при разработке и хотел бы поделиться опытом с Хабрасообществом. Эти советы не для начинающих — это советы по использованию CouchDB на живом production.

Tarantool это разработка компании Mail.ru. Представляет высокопроизводительное key/value no-Sql решение.Отсутствие портов для популярных языков программирования сдерживает популярность данной БД. Попытался восполнить данный пробел.
Ветка экспериментальная. Исходники
Далее примеры.

Посмотрел видеозаписи с конференции Mongo Moscow.
Вот тезисы о возможностях, оставшиеся от просмотренного.
Перевод был не ахти, смотрел на английском, мог что-нибудь напутать.
Старался быть объективным, если не получилось — пишите :)

Добрый день!



Я хотел бы рассказать о грядущей конференции Mongo DB у нас на Цифрябре. Так как официальные объявления вряд ли кого-то интересуют, я напишу несколько вещей, которых нет на офсайте, но которые могут быть интересны публике.

Tarantool это замечательное высокопроизводительное no-Sql решение, разработка компании Mail.Ru. Исходники

Данное решение позволяет использовать как режим key/value, так и выборку множества записей в рекордсет по одному или нескольким критериям (полям поиска). Аналогов в рунете и не только, я пока не встречал. С натяжкой можно сравнить редис. Но в редисе — списковые данные и их нельзя выбирать по ключу. Судя до утверждениям разработчиков, скорость доступа по ключу превосходит memcache, при этом еще в бэдграунде осуществляется постоянное сохранение данных на диск. Но к сожалению, данная разработка имеет единственный perl клиент для доступа к данным, из-за чего не имеет такой популярности, как например у redis или memcache.

В doc/box-protocol источников есть описание Протокола, которое я в настоящее время переработал для написания клиента на Си и PHP. Изучив Протокол, вы можете реализоать нативный клиент на любимом Вам языке. Надеюсь, данная статья в этом Вам пригодится.