NoSQL *

disclaimer Так получилось, что последний месяц я разбираюсь с ZooKeeper, и у меня возникло желание систематизировать то, что я узнал, собственно пост об этом, а не о сервисе блокировок, как можно было подумать исходя из названия. Поехали!

При переходе от многопоточного программирования к программированию распределенных систем многие стандартные техники перестают работать. Одной из таких техник являются блокировки (synchronized), так как область их действия ограничена одним процессом, следовательно, они не только не работают на разных узлах распределенной системы, но так же не между разными экземплярами приложения на одной машине; получается, что нужен отдельный механизм для блокировок.

От распределенного сервиса блокировок разумно требовать:

1. работоспособность в условиях моргания сети (первое правило распределенных систем — никому не говорить о распределенных системах сеть ненадежна)
2. отсутствие единой точки отказа

Создать подобный сервис нам поможет ZooKeeper

В википедии написано, что ZooKeeper — распределенный сервис конфигурирования и синхронизации, не знаю как вам, но мне данное определение мало что раскрывает. Оглядываясь на свой опыт, могу дать альтернативное определение ZooKeeper, это распределенное key/value хранилище со следующими свойствами:

• пространство ключей образует дерево (иерархию подобную файловой системе)
• значения могут содержаться в любом узле иерархии, а не только в листьях (как если бы файлы одновременно были бы и каталогами), узел иерархии называется znode
• между клиентом и сервером двунаправленная связь, следовательно, клиент может подписываться как изменение конкретного значения или части иерархии
• возможно создать временную пару ключ/значение, которая существует, пока клиент её создавший подключен к кластеру
• все данные должны помещаться в память
• устойчивость к смерти некритического кол-ва узлов кластера

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

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

Задача которую нужно было решать — каким образом хранить, искать, модифицировать информацию о последовательности событий при следующих условиях:

• события могут происходить на разных серверах и в разных датацентрах (восточный и западный берег США, Европа)
• интервал между событиями — от долей секунды до нескольких дней
• к моменту получения завершающего события (например конверсия) информация обо всей цепочке должна быть на руках
• время жизни информации — примерно десять дней, после чего она должна быть удалена, желательно автоматически, через TTL
• темп чтения/записи событий — сотни или тысячи в секунду
• Время ответа: желательное — до 10мс, допустимое — в пределах 50мс, максимальное — до 100мс
• информация должна быть доступна «всегда» — независимо от аварий железа, сети, апгрейдов
• система должна легко масштабироваться: добавление новых серверов, датацентров должно происходить прозрачно для остальных сервисов (допустима деградация времени ответа в заданных пределах).

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

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

Настало время пощупать базу данных следующего поколения MemSQL!



От создателя проекта, Никиты Шамнугова:
«MemSQL — это база данных следующего поколения, решающая проблемы наиболее ограничивающего для большинства нынешних приложений компонента— диска. Предлагая всем знакомый SQL интерфейс к данным хранящимся в памяти, MemSQL дает возможность при разработке масштабных веб-приложений иметь дело с большим трафиком и быстрым ростом. MemSQL на порядки улучшает производительность чтения и записи и заметно упрощает разработку и поддержку приложений. Разрабатывается MemSQL в далекой Калифорнии, Сан Франциско, частной компанией при частичной поддержке First RoundCapital и NEA.»

ObjectDB является объектно-ориентированной, написанной на Java СУБД, которая при всех своих впечатляющих тестах на скорость и используемая (как следует из рекламы на официальном сайте) такими организациями как HP и Novell малознакома для многих программистов (Сам я об этой базе узнал буквально месяц назад, и использовал ее только один раз в рамках учебного проекта, да и мой препод узнал о ней как раз из моего проекта). За продолжением прошу под кат.

Если не успели все разобрать (интересно глянуть на тех, кто успел), текст можно посмотреть здесь.

15 мая вышла новая версия бесплатной NoSQL СУБД GlobalsDB 2012.2.

Что нового?
Добавлен ожидаемый многими Node.JS API интерфейс для Windows, и сразу же для Windows 64-bit.
Реализованы небольшие дополнения и устранены некоторые ошибки.
Об этом и остальном

Автор рассказывает о перипетиях пивоваров, производителей СУБД, себя и кратко о том как правильно проектировать приложения. Мне показалась полезной поучительная часть статьи.

Одна из самых разрекламированных фич MongoDB — это гибкость. Я сам не раз подчеркивал это в бесчисленных разговорах о MongoDB. Однако, гибкость — это палка о двух концах: большая гибкость подразумевает более широкий выбор решений для моделирования данных. Тем не менее, мне нравится гибкость, которую предоставляет MongoDB, просто нужно иметь ввиду некоторые рекомендации, прежде чем начать разрабатывать модель данных.

В этой статье мы рассмотрим, как смоделировать структуру, содержащую списки рассылок и данные о людях, которые входят в эти списки.

На Хабре часто встречается комментарий о том, что документацию разработчики не дочитывают до конца. Столкнулся с этим сам, когда открыл для себя List-функции в CouchDB.

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

List-функции в design-документах CouchDB нужны для того, чтобы иметь возможность обработать всю базу данных одной функцией. Т.е. это некий аналог Full Table Scan в реляционных базах.

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

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

Но поскольку вы спросили, вот внутренние реализации каждой структуры данных Redis:

• Строки реализованы с использованием библиотеки динамических строк C, так что мы не платим (говоря асимптотически) за выделение памяти в операциях добавления. Таким образом мы получаем сложность добавления O(N), вместо, например, квадратичной.
• Списки реализованы как связные списки.
• Множества и Хэши реализованы как хэш-таблицы.
• Упорядоченные множества реализованы как списки с пропусками (особый тип сбалансированных деревьев)

Всем привет! Рад представить вам уже пятую статью из цикла «Внутреннее устройство и архитектура сервиса AtContent.com». В ней я расскажу о том как сделать работу с Azure Table Storage более функциональной и удобной.



Платформа Windows Azure дает очень мощный набор инструментов для реализации своих идей. И среди них – Azure Table Storage – нереляционная база данных с неограниченным объемом. Большим плюсом этого хранилища является то, что можно делать к нему достаточно сложные запросы. Но помимо этого есть и некоторые неудобства. Так, например, с помощью LINQ нельзя выполнить запросы, в которых есть логика Or или Contains без дополнительных модификаций.

Хочу поделиться историей, как наш проект слёг на полтора часа, и опытом выяснения причин.

В один прекрасный момент мы понимаем, что часть сайта грузится с 15-минутной задержкой, а другая часть попросту не работает, выдавая 504 ошибку.

Внимание! Поскольку люди любят умничать, и не любят читать — пишу тут. Цель поста — подсказать, как выйти из аварийной ситуации, всё остальное просто лирика, на которой почему-то все заостряют внимание.

Наконец-то вместо уговоров подождать еще немного, на вопрос “Есть ли InterSystems GlobalsDB/Caché Extreme под Microsoft .Net?” можно ответить утвердительно. В новой версии Caché 2012.2 (Field Test) и GlobalsDB v2012.296 появилась поддержка этой платформы.
Попытаюсь в любимом для многих разработчиков на одной шестой суши стиле, то есть без чтения install notes и прочего, исследовать, что, собственно говоря, представляет дистрибутив GlobalsDB под Windows.

Хотелось бы рассказать о некоторых особенностях Redis при использовании на боевом сервере. Будут рассмотрены альтернативы при сохранении данных на диск, позволяющие достичь различной степени надёжности при сбоях. Так же будут приведены примеры конфигурации для резервного копирования и мониторинга. Используется Redis 2.2.11 на Amazon EC2 с установленной Ubuntu 10.10.

12 марта анонсирован выход очередной версии  бесплатной NoSQL InterSystems СУБД — GlobalsDB v2012.296.

В новой версии появился интерфейс .NET API, внесены незначительные изменения и исправлен ряд ошибок.
Полная версия документа на английском языке доступна на сайте GlobalsDB.org.
Загрузить GlobalsDB.
Подробности под катом.

29 марта в 18-00 по восточному времени (30 марта 3 часа ночи по Москве) начнется очередной турнир программистов GlobalsDB, бесплатной NoSQL СУБД от InterSystems.

Формат мероприятия: 1 неделя на выполнение задания, с выкладкой его на github ресурс.

Приз победителю — $3500 и специальный пресс-релиз InterSystems в его честь.

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

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

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

Вот о такой проблеме в Apache CouchDB мы и поговорим далее.
Картинка в тему:

В релизе 2.1 было заявлена реализация такой функциональности, как новый фреймворк агрегирования данных. Хотелось бы рассказать о первых впечатлениях от этой весьма интересной штуки. Данный функционал должен позволить в некоторых местах отказаться от Map/Reduce и написания кода на JavaScript в пользу достаточно простых конструкций, предназначенных для группировки полей почти как в SQL.

Авторы позиционируют HyperDex как распределённое, отказоустойчивое, легко-маштабируемое, заточенное на очень быстрый поиск NoSQL key-value хранилище.

Главная фича — новый принцип хранения объектов в многомерном эвклидовом пространстве (рис. слева), используя гиперпространственное хэширование (hyperspace hashing) (на который, кстати, авторы сейчас получают патент), которое позволяет выполнять большинство типичных задач от 2 до 13 раз быстрее, чем в MongoDB, Redis, Cassandra.