NoSQL *

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. Изучив Протокол, вы можете реализоать нативный клиент на любимом Вам языке. Надеюсь, данная статья в этом Вам пригодится.

В экспериментальной версии (5.6.2) Oracle mysql появился плагин, позволяющий обращаться к innodb или ndb (mysql cluster) данным через memcached интерфейс. Оставляя возможность доступа к тем же данным через sql интерфейс.

Описание здесь:
Сообщение Оракла
http://blogs.innodb.com/wp/2011/04/nosql-to-innodb-with-memcached/

Код:
http://labs.mysql.com/

В своем проекте на PHP пришлось столкнуться с необходимостью хранения в базе 64-битных целых данных. Нашел только одну статью по теме, зато очень подробную (местами даже слишком) и объясняющую все тонкости. Решил опубликовать перевод на Хабре, на случай, если кто-нибудь столкнется с аналогичной проблемой.

В продолжение статьи Первый опыт работы с Handler Socket & php_handlersocket некоторые особенности Update & Insert

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

В последнее время стал активно изучать и использовать NoSQL-решение RavenDB. И вот я решился написать вводный пост про то, как начать использовать RavenDB. По сути эта статья не сильно отличается от «Hello world» инструкции на сайте проекта (да и примеры я взял оттуда же), но я постараюсь дать некоторые дополнения к тому, что там написано. Сразу хочу сказать, что я не являюсь экспертом в RavenDB, и использую его для своих проектов и задач достаточно недавно.

P.S. Почему не MongoDB или CouchDB? Не знаю, просто захотелось попробовать именно это решение. Да и на хабре это решение не было еще освещено.

Немного вскружилла голову статья Использование MySQL как NoSQL — История о том, как достичь 750,000 запросов в секунду (Перевод моего друга Вадима). Есть и другие материалы по этой теме. И вот дошли руки до экспериментов.

Под PHP разработано три разных клиента:
extension code.google.com/p/php-handlersocket
PEAR openpear.org/package/Net_HandlerSocket
PHP native github.com/tz-lom/HSPHP

Ниже приведены мои впечатления о первых экспериментах.

Примечание переводчика: хоть статья довольно старая (опубликована 2 года назад) и носит громкое название, в ней все же дается хорошее представление о различиях реляционных БД и NoSQL БД, их преимуществах и недостатках, а также приводится краткий обзор нереляционных хранилищ.

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

Если это правда, значит ли это, что могучие реляционные БД стали уязвимы? Значит ли это, что дни реляционных БД проходят и скоро совсем пройдут? В этой статье мы рассмотрим популярное течение нереляционных баз данных применительно к различным ситуациям и посмотрим, повлияет ли это на будущее реляционных БД.

Недавно, чисто случайно, попался на глаза продукт от FAL Labs — Kyoto Tycoon, легкий сервер данных. В основе данного продукта — QDBM (Quick Database Manager) — хранилище данных типа ключ-значение. Зацепило меня то, что с этим «Магнатом из Киото» можно общаться по memcached-like протоколу.
Поскольку уже некоторое время использую MemcacheDB, захотелось сравнить их характеристики (протокол общения один, и там и там NoSQL-хранилище ключ-значение). Недавно подвернулся удобный случай — экспортировал некоторый объем данных из одного самопального хранилища в MemcacheDB. Для тестирования осталось только развернуть на том-же сервере Kyoto Tycoon.
Вот что у меня получилось:

Когда-то давно, когда я практиковался в написании хранимых процедур, триггеров, курсоров под MSSQL, мне не давала покоя мысль о приложении, где вся бизнес-логика крутится на уровне БД, а presentation tier просто дергает базу и отвечает за отрисовку полученных результатов. С тех пор прошло много моих девелоперских лет, но возможности для реализации данной идеи так и не встретилось… до тех пор, пока я не наткнулся на CouchDB.

Я думаю, что многие уже слышали о NoSQL базах данных и в том числе о Couch DB. Здесь я хочу рассказать о замечательной возможности встраивать JavaScript-приложения в CouchDB, название которым CouchApp.

Прекрасная тридцатиминутная история (на английском) от Джеймса Голика — CTO американской бдсм-соцсети выдерживающей 180 000 000 реквестов в месяц, при среднем времени отдачи ~200 мс, имея шесть серверов. В двух словах — смотрите тэги.

MemBase — открытое, распределенное персистентное хранилище ключ-значение оптимизированное для хранения данных веб-приложений.

• персистентен
• имеет квази-постоянное (quasi-deterministic) малое время отклика
• высокая скорость работы
• линейно масштабируется с одного сервера до тысяч
• не имеет схемы данных (только ключ-значение)
• совместим по протоколу с memcached

3 сентября 2010 незаметно вышел Redis 2.0. Появилось много интересных возможностей. Некоторые из них расширяют границы продвинутого key-value хранилища до организации очередей и не только. Перевод списка новых возможностей с сайта Redis:

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

Стоит упомянуть, что Redis 2.0 только достиг своего первого стабильного релиза, Redis 2.2 близок к замораживанию новых возможностей, поэтому будьте готовы к новым восхитительным штукам уже скоро!

MULTI/EXEC

Семейство MULTI/EXEC команд было добавлено, чтобы заполнить необходимость выполнять несколько команд, как один атомарный блок (от переводчика: в общем-то это аналог транзакций в обычных базах данных). Потому что все команды внутри блока MULTI/EXEC сериализуются и выполняются последовательно, то невозможно, чтобы другой клиентский запрос был выполнен в середине выполнения этого блока. Все команды выполняются одна за другой, когда вызывается EXEC. Это гарантирует, что либо выполняются все команды, либо ни одна, независимо от состояния соединения с клиентом.

Приветствую!

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

Хабраюзеров, писавших на эту тему, я прошу переносить свои топики. Блог понемногу наполняется и ждет ваших новых интересных статей — MongoDB, CouchDB, Cassandra, Redis, Cache — все, что угодно.

Добро пожаловать!

Что такое CouchDB для вас? Вероятно любой, кто хоть немного интересуется популярной нынче темой NoSQL, прекрасно знает общие детали: это такая симпатичная игрушка с map/reduce-запросами, которые пишутся на JavaScript, с которой можно работать, гоняя JSON по HTTP-протоколу, а также не исключено, что слышали, что она fault-tolerant, тобишь не ломается вообще. Дальше этого обычно дело не идёт, в результате CouchDB отправляется в delicious в общую кучу со всякими MongoDB, Cassandra, Hadoop и т.п.

Примерно такого мнения придерживался и я вплоть до недавнего времени, пока не возникла острая необходимость переосмыслить архитектуру текущего проекта (упёршегося лбом в свою реляционную БД) и пересесть на документную базу данных, которая бы умела map/reduce. После того, как более пристально взгялнул на CouchDB, я понял, что он уникален в своём классе, его не следует ставить в один ряд с упомянутыми продуктами. Идеи, которые заложены в CouchDB настолько концептуальны, что способны в корне перевернуть представление о разработке веб-приложений.

О том, что же меня так впечатлило, постараюсь рассказать под катом.

Почти в срок, команда 10gen выпустила новый стабильный релиз NoSQL базы данных MongoDB.

Из новинок хочу отметить такие заявленные возможности:

* Авто шардинг — теперь можно создавать кластеры для большого количества данных с «размазыванием» данных по серверам кластера
* Replica Sets — позволит создавать кластеры с быстрой репликацией и отказоустойчивостью
* Оператор $or — если раньше приходилось писать запрос с использованием JavaScript, то сейчас операции OR работают как стандартный запрос
* До 64 индексов на коллекцию
* Оператор $slice — очень удобная штука, можно выбирать первые 5 штук записей или 5 последних, например.
* Поддержка UNIX сокетов и IPv6
* Улучшена поддержка сервиса для Windows

Скачать можно на странице загрузок

Release Notes

Это перевод статьи, датированной 1м сентября 2009 года, следует это учесть при прочтении. — прим. пер.

В последний месяц или два команда инженеров Digg потратила совсем немного времени на изучение, тестирование и окончательное внедрение Cassandra в продакшен. Это был очень веcёлый проект, но до того, как веселье началось, нам пришлось потратить какое-то время на выяснение того, что же представляет собой модель данных Cassandra… фраза «WTF is a «super column»» («что за фигня этот суперстолбец?») была произнесена не один раз.

Если вы работали ранее с РСУБД (это касается почти всех), вы вероятно будете немного обескуражены некоторыми названиями при изучении модели данных Cassandra. Мне и моей команде в Digg потребовалось несколько дней обсуждений, прежде чем мы «врубились». Пару недель назад в списке рассылки разработчиков шёл процесс bikeshed-а на тему полностью новой схемы именования для разрешения неразберихи. На всём протяжении дискуссии я думал: «может, если будет несколько нормальных примеров, люди не будут так смущены названиями». Так, это моя попытка объяснения модели данных Cassandra; она предназначена для того, чтобы вы ознакомились, но не уходили в дебри, и, надеюсь, это поможет прояснить некоторые вещи.