Что такое 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; она предназначена для того, чтобы вы ознакомились, но не уходили в дебри, и, надеюсь, это поможет прояснить некоторые вещи.

На Linux.org.Ru сказывают, что проект Apache Cassandra получит коммерческую поддержку, целью которой является повышение привлекательности и востребованности проекта в enterprise-сегменте рынка.

(Полагаю, многие вполне представляют себе, что это будет значить и для «Кассандры», и для всей сцены NoSQL.)

Это продолжение статьи «Как быстро установить и начать эксперементировать с Cassandra», опубликованной на хабре

Cassandra — распределенная база данных, в основу которой положены идеи Dynamo и Google Big Table

Обзор основных особенноестей:

• Проверена в работе (используется в Facebook, Twitter, Digg и в др.)
• Отказоустойчива (каждая запись дублируется на нескольких узлах в кластере)
• Децентрализована (все узлы в кластере эквивалентны)
• Гибкая модель данных
• Пропускная способность чтения и записи увеличиваются линейно с добавлением новых узлов
• Безразмерна (нет ограничений на объем, поиск всегда O(1))

Про MongoDb было рассказано не так много, но относительно полно, например здесь. Хочу поделиться еще с одним практическим использованием этой БД — это построение цепочек друзей. Построение цепочек и концепцию кругов было использовано в Мойм Круге. Вот пример: Я — Иван Петров — Петр-Иванов — Киририлл Лавров — Вася Пупкин.

MongoDb было выбрано как высокопроизводительное хранилище данных, позволяющее быстро извлекать массивы структур данных. Традиционные key/value DB для этого не подходят, почему — поймете по ходу изложения статьи.

В данной статье рассмотрен опыт использования noSQL DB при построение «цепочек друзей» в небольшой соц-сети 300 тыс пользователей.

Ссылка на эту статью уже мелькала на Хабре и я столкнулся с интересом к ней. Многие испытали проблемы с освоением оригинала на английском и я решил перевести ее.

Заметки об использовании MongoDB в продакшене

Год назад в июле я писал о том, что мы перешли с MySQL на MongoDB.
Мы запустили MongoDB в продакшене для сервиса мониторинга Server Density. С тех пор прошло 8 месяцев и мы столкнулись с некоторыми вещами.

Здесь несколько раз в обсуждениях альтернативных, не реляционных СУБД уже упоминалась такая СУБД, как InterSystems Caché. Это промышленная высокопроизводительная постреляционная СУБД, которая позволяет разработчикам использовать объектный, реляционный и прямой доступ к данным, хранение которых обеспечивается ориентированным на транзакции многомерным ядром СУБД. Данный топик поможет тем, кто захочет попробовать его в действии.

Наверное, не многие знают о существовании такого типа баз данных, как базы данных на основе графов (graph db). Ранее в NOSQL среде была распространена всего одна система такого плана — Neo4j. Сегодня же к нам прибыло еще 2 — Infogrid и HyperGraphDB. О последнем и пойдет речь.

Как описывают сами создатели свою систему:

«HyperGraphDB — это расширяемая, портативная, распределенная, встраиваемая система общего назначения со свободным (open-source) механизмом хранения данных. Эта система разработана специально для проектов использующих возможности искусственного интеллекта и семантического вэба и может использоваться как встраиваемая, объектно-ориентированная база данных для проектов любого масштаба.»

Беспрецедентные объемы данных заставляют разработчиков и бизнес приглядываться к альтернативам реляционных баз данных, используемым вот уже более тридцати лет. В совокупности все эти технологии известны как «NoSQL базы данных».


Основной проблемой является то, что реляционные базы данных не могут справляться с нагрузками актуальными в наше время (мы говорим о high-load проектах). Есть три конкретные проблемных области:

• горизонтальное масштабирование при больших объемах данных, например как в случае Digg (3 терабайта для зеленых значков, отображаемых, если ваш друг сделал dugg на статье) или Facebook (50 терабайт для поиска по входящим сообщениям) или eBay (2 петабайта в целом)
• производительность каждого отдельного сервера
• не гибкий дизайн логической структуры.

Немного статей на хабре посвящены новому движению в IT индустрии — NoSQL. Я решил изменить это и написал статью-перевод-обзор об одном из докладов с конференции NoSQL прошедшей 5 октября в Нью-Йорке. В этой статье будет говорится о системе Riak, с которой мне довелось иметь счастье работать последнее время.

Что такое Riak? Многие модные слова популярные сейчас, можно отнести к Riak. Riak — это документно-ориентированная база данных. Riak — это децентрализованное key-value хранилище данных, с поддержкой стандартных операций — get, put и delete. Riak — это распределенное, масштабируемое, отказоустойчивое решение для хранения информации. А так же Riak — это система с открытым исходным кодом и поддержкой обращений с помощью HTTP, JSON и REST. Ну и конечно RIAK — это NoSQL.

Введение

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

Сегодня мы поставим MongoDB, ниже рассмотрим свежеиспеченный ХабраЛоггер и пошпионим за главной страницей Хабра в реальном времени.

Введение

Коллеги, при разработке приложений, мы каждый день сталкиваемся с потребностью в гибком хранении информации (обновлении, поиске по ней, и т.д.). Класс продуктов, которые решают этот круг задач, как все мы знаем — Базы данных. Но что это такое в нашем понимании? У многих «база данных» твердо ассоциируется с MySQL, таблицами и SQL-запросами. И это устраивает до определенного момента. Действительно, реляционные базы данных дают массу преимуществ в работе: поскольку данные имеют сильную связанность, не нужно контролировать целостность базы данных. Используя простой под-запрос можно выбрать количество комментариев к каждому посту в блоге. Используя JOIN нетрудно делать сложные связанные выборки и получать данные сразу о нескольких сущностях.