NoSQL *

24 февраля IBM объявила о поглощении частной компании из Бостона Cloudant.
Cloudant призвана расширить собственные возможности IBM в сфере Big Data, аналитики, облачных вычислений и средств для разработки под мобильные устройства.
Также это даст новый толчок развитию открытой базы данных Apache CouchDB и собственного форка Cloudant — BigCouch.

Финансовые условия сделки не разглашаются.

По заверениям представителей Cloudant, для клиентов ничего не изменится

Пресс релиз

— How do I authenticate?
— You don't!

это цитата из FAQ memcached.

Да, в memcached по умолчанию не предусмотрено системы аутентификации, и администратор сам должен сделать маленький шажок, чтобы закрыть свой сервер от свободного доступа. Например, запустить его на 127.0.0.1, или воспользоваться фаерволом. Сколько же сайтов рунета это сделали?

Продолжая и углубляясь в администрирование Redis встала задача — развернуть второй кластер на машине с уже имеющимся. Например, для кросс-репликации, когда на одном физическом сервере у вас мастер1 и слейв2, а на другом — мастер2 и слейв1.
Или же просто для некоторого логического распределения информации на одной машине по нескольким кластерам.
Русскоязычной информации на поверхности не лежало, английская нашлась только для Linux.

Поэтому хочу представить вам небольшую заметку-помощницу о создании поликластера Redis во FreeBSD.

Не секрет, что для защиты от HTTP-DDoS зачастую используют связку nginx в качестве фронтенда и некий другой web-сервер в качестве бакенда. При этом ввиду большой нагрузки возникает проблема хранения логов для дальнейшего их анализа. Можно хранить в текстовом файле, но, естественно, анализировать/ротировать его весьма неудобно. Можно гнать данные напрямую в, например, mysql через пайп, но выигрывая в удобстве анализа мы проигрываем в производительности, особенно это заметно при фрагментации. Золотой серединой, пожалуй, будет no-sql решение.
Для себя я выбрал redis.

Spanner – географически распределенная высокомасштабируемая мультиверсионная база данных с поддержкой распределенных транзакций. Хранилище было разработана инженерами Google для внутренних сервисов корпорации. Research paper [8], описывающий базовые принципы и архитектуру Spanner, был представлен на научной конференции 10th USENIX Symposium on Operating Systems Design and Implementation в 2012 году.

Spanner является эволюционным развитием NoSQL-предшественника – Google Bigtable. Сам же c Spanner относят к семейству NewSQL-решений. В research paper [8] заявляется, что дизайн Spanner позволяет системе масштабироваться на миллионы вычислительных узлов через сотни дата-центров и работать с триллионами строк данных.

9 декабря в Екатеринбурге прошла первая в России конференция, посвященная NoSQL-системе Cassandra. Организаторами конференции выступили компании IT-People, СКБ Контур и DataStax. Поддержку мероприятию оказало Министерство транспорта и связи Свердловской области.

О конференции

Расписание и тезисы докладов готовы и доступны на сайте CassandraConf.ru. Итак, что нас ждет 9 декабря:

Внимание: тег «юмор».

И в заключение. Мы пришли к выводу, что MySQL — это прекрасная база данных для нашего сайта. Вопросы?

Да, у меня есть вопрос. Почему вы не использовали MongoDB? MongoDB — это горизонтально масштабируемая база данных, она не использует SQL или JOINы, поэтому обладает высокой производительностью.

Это прекрасный вопрос. Мы изучили несколько NoSQL баз данных и поняли, что все варианты пока ещё незрелы для применения на работающих проектах. MySQL — это проверенная база данных, которая используется во всём мире и имеет все необходимые нам функции.

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

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

Я поставил перед собой цель показать возможности Redis с помощью примеров кода. После публикации приму любые предложения по улучшению материала.

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

Ключи

Redis — хранилище данных в формате «ключ-значение». Факты о ключах:

• Ключи в Redis — бинарно-безопасные (binary safe) строки.
• Слишком длинные ключи — плохая идея, не только из-за занимаемой памяти, но так же и в связи с увеличением времени поиска определенного ключа в множестве в связи с дорогостоящим сравнением.
• Хорошая идея — придерживаться схемы при построении ключей: «object-type:id:field».

Типы данных Redis

• Строки (strings). Базовый тип данных Redis. Строки в Redis бинарно-безопасны, могут использоваться так же как числа, ограничены размером 512 Мб.
• Списки (lists). Классические списки строк, упорядоченные в порядке вставки, которая возможна как со стороны головы, так и со стороны хвоста списка. Максимальное количество элементов — 2³² — 1.
• Множества (sets). Множества строк в математическом понимании: не упорядочены, поддерживают операции вставки, проверки вхождения элемента, пересечения и разницы множеств. Максимальное количество элементов — 2³² — 1.
• Хеш-таблицы (hashes). Классические хеш-таблицы или ассоциативные массивы. Максимальное количество пар «ключ-значение» — 2³² — 1.
• Упорядоченные множества (sorted sets). Упорядоченное множество отличается от обычного тем, что его элементы упорядочены по особому параметру «score».

Про типы данных Redis есть отдельная хорошая статья: «Структуры данных, используемые в Redis».

9 декабря в Екатеринбурге пройдет первая в России конференция, посвященная NoSQL-хранилищу Cassandra. Мы уже сформировали программу CassandraConf.ru и приглашаем присоединиться как опытных разработчиков, так и тех, кто хочет познакомиться с Cassandra впервые!

Участие в конференции бесплатное — приезжайте!

Под катом — программа мероприятия и подробности

Вы, возможно, помните как несколько лет назад стремительно стали набирать популярность NoSQL-базы данных (MongoDB, DynamoDB и другие). Многие пророчили смерть классических реляционных баз данных, торжество новых парадигм и всеобщее счастье в мире. И вы, возможно, в курсе того, как в последний год (или около того) наблюдается откат этой эйфории — выходят статьи типа «Broken by Design: MongoDB Fault Tolerance» и Why You Should Never Use MongoDB. Народ на Хабре на Тостере интересуется — «А почему же Монгу критикуют?», на что получает ответы «перерекламировали», «серебрянной пули нет», «надо выбирать базу данных по задачам».

Все 3 очевидных варианта — «Использовать реляционную БД», «Использовать NoSQL-БД», «Выбирать БД по задачам проекта» мне не нравятся по причине, высказанной в заголовке статьи.

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

1. Возможность расширения (триггеры, хранимые процедуры);
2. Полнотекстовый поиск;
3. Наличие провайдера для .NET;
4. Поддержка POCO;
5. Возможность развернуть на Windows платформе;
6. Желательно поддержка lucene.net;
7. Желательно поддержка транзакций;
8. Желательно поддержка асинхронных запросов;
9. Желательно map reduce;
10. Желательно наличие документации и сообщества разработчиков.

После долгих поисков и сравнений выбор пал на RavenDb. Меня немного удивило, что данному продукту посвящено не так много публикаций. После года общения с данным NoSQL решением решил поделиться впечатлениями. Переписывать документацию не вижу смысла, все очень хорошо описано на сайте проекта и в официальных группах. А также блоге разработчика Ayende blog.

Далеко-далеко, где-то на краю Галактики, я обнаружил весьма впечатляющее NoSQL решение…

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

Маркетинговая затравка от авторов звучит примерно так:

BaseX является очень легковесной, высокопроизводительной и масштабируемой XML базой данных с XPath/XQuery 3.0 процессором, который имеет полную поддержку W3C Update и Full Text спецификаций. Интерактивный и дружественный графический интерфейс позволяет легко изучать ваши XML документы

Звучит весьма вкусно, но реальность, как всегда, больно-больно ударяет по самым незащищенным местам

За последние несколько лет в мире IT появилась модная тенденция – использование всего «облачного» для разработки новых продуктов. Публичных облачных провайдеров не так много, самый популярных среди них – Amazon. Однако многие компании не готовы доверять приватные данные кому-либо, при этом хотят хранить их надежно, и поэтому поднимают частные небольшие облачка.

Любое облако состоит из двух основных компонентов: Единой Точки Входа (ЕТВ) и Облачной Магии (ОМ). Рассмотрим облачное хранилище Amazon S3: в роли ЕТВ используется довольно удобный REST API, а Облачную Магию обеспечивают эльфы, работающие на долларах. Компании, желающие разместить в S3 небольшие видеофайлы или базу данных, предварительно считают на калькуляторе сумму, которую они будут платить в месяц при планируемой нагрузке.

Эта статья про другое облачное хранилище, в котором эльфы питаются Духом Свободы, электричеством и еще им нужно немножечко «кокаина».

Называется это хранилище Elliptics.

Здравствуй, Хабр!

В этой открытой лекции я попытался сжато рассказать и показать полный цикл (full stack) разработки веб-приложений на JavaScript.

Начнем мы с короткого введения в язык, потом в двух словах поговорим о клиентской части, в частности, об MVC фреймворках вроде Angular.js, после чего перейдем на серверную часть: Node.js и MongoDB. В конце обсудим возможность автоматизации разработки и сборки проектов с помощью Grunt.js.



Скачать слайды и исходные коды.

Лекция была записана в офисе компании Chocolife, зрители – разработчики этой компании.

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



В своей прошлой статье я описал базовые понятия и средства для начала работы с тарантулом. В этой статье попробую уделить больше внимания использованию хранимых процедур в Тарантуле на примере одной игровой задачи.

MarkLogic является сервером приложений и любая программа написанная на XQuery для него может получить доступ не только к объектам хранящимся в самой базе данных, но и к файлам находящимся непосредственно на файловой системе.
API предоставляющий доступ к файловой системе в MarkLogic Server не так уж и богат, но имеющихся средств вполне достаточно чтобы зачитывать данные с файловой системы напрямую из XQuery кода и выполнять сохранения файлов на неё.

Еще немного о том как MarkLogic Server хранит данные.

Современные высоконагруженные приложения изменили требования к СУБД — сегодня необходимы эффективные технологии создания cпециализированных решений с гарантированным временем реакции при обработке больших массивов данных. Вместе с тем, несмотря на появление таких относительно новых технологий как NoSQL, потенциал давно существующих подходов реализован еще не полностью.

Интернет проекты с высокой нагрузкой и приложения класса XTP (extreme transaction processing) изменили требования к технологиям СУБД. Приоритетными требованиями стали простота разработки, возможность cпециализации технологии хранимых данных для конкретного проекта, поддержка постоянного времени реакции системы при увеличении нагрузки, обеспечение низкой стоимости масштабирования и стоимости обработки больших объемов данных.

В качестве ответа на новые потребности возникло движение NoSQL — новый класс баз данных, который обещает разработчикам высокую скорость внесения изменений в приложения, низкие затраты на масштабирование и обработку/хранение больших объемов данных, высокую скорость работы на относительно недорогом железе — ценности, которые всегда были важны и для технологий компании InterSystems. Практически всегда NoSQL базы реализуют отличную от привычной парадигму работы приложений с базами данных — переход от концепции интегрирующей СУБД для нескольких приложений к концепции СУБД для одного приложения или одного проекта и больше — отдельной специфичной задачи в рамках проекта.

MarkLogic Server – это документо-ориентированная native XML база данных. Как и в любой документо-ориентированной DB в MarkLogic Server данные можно представить как файлово-фолдерную структуру. Кстати, при доступе к хранилищу через WebDAV данные именно так и представляются. Помимо собственно XML в MarkLogic Server можно хранить и любые бинарные данные в виде файлов.

Внутренне представление XML данных в MarkLogic Server довольно сложное и будет рассмотрено позже. Сейчас же стоит сказать о том, что поместить в MarkLogic Server можно только well formed XML так как хранится он не в виде простого текста, а как объект данных типа XML. Кодировкой внутреннего представления XML данных является Unicode, что избавляет от множества проблем с разными языками. Все Entity в XML данных разворачиваются в цифровые еntity. Если в документе используются только они, то это не доставит никаких проблем, в противном случае MarkLogic Server должен «знать» о всех используемых entity.