NoSQL *

Пишем драйвер поддержки графовой базы данных Neo4j для Meteor

В Meteor любая работа с даными связана с двусторонней реактивностью. На данный момент 100% реактивностью обладают встроенная в Meteor MongoDB и Redis (оба драйвера разработаны в стенах Meteor), частично реактивность реализована для MySQL и MSSQL (сторонними разработчиками).

Для вышеуказанных баз данных реактивность реализована посредством observer'ов, которые сообщают где, как, когда и какие данные изменились, для того чтобы драйвер, обслуживающий связь [данные <-> представление], знал какие данные и у каких Клиентов обновить. Neo4j лишен каких-либо watcher'ов и observer'ов, но это нас не остановило. Как мы вышли из данной ситуации и зачем нам нужен Neo4j читайте под катом.

Всем привет!

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

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

В 2013 году я с удовольствием смотрел онлайн-трансляцию вечером из офиса Тамтэка, обсуждая с коллегами преимущества Rabbit MQ, дубльгисовские попытки запихать все в Neo4j, а также доклад нашего коллеги Дениса Нелюбина о сравнении производительности NoSQL баз данных (Aerospike, Couchbase, Mongo, Cassandra) на нашем тестовом фреймворке, в разработке которого я сам принимал участие годом ранее.

В 2014, 14 марта, в свой день рождения, я отправил заявку с описанием доклада на Highload и стал ждать. После полугода мне пришло подтверждение и я отправился в путь, надеясь не только познакомиться с коллегами, работающими в смежных областях, но и поднять свое Big Data сознание на новой уровень.

В данной статье вы найдете ответ на поставленный вопрос, а также в ней будут объяснены базовые понятия по технологии распределенных вычислений в Oracle Coherence. Это вводная статья, главной задачей которой является объяснение “словаря” терминов, которым пользуются разработчики Coherence. Я приведу термины в том числе и на английском языке, для облегчения поиска информации для тех, кто захочет узнать больше в этом направлении.
Для тех, кому эта тема интересна, прошу под кат

Недавно появилась информация о том, что Google приобрел облачный сервис Firebase. На хабре информации о Firebase не особо много, а сервис выглядит очень интересно, как минимум для быстрого прототипирования или использования в качестве буфера для активных данных.

FireBase — это облачная NoSQL БД для real-time приложений. То есть, ваши данные хранятся в облаке, которое готово почти к любым нагрузкам. Ваши данные моментально обновляются на всех клиентах, которые подключены к FireBase и подписаны на информацию об обновлениях. Совершенно отпадает необходимость строить сложную систему с использованием веб-сокетов для обмена данными между сервером и клиентами в реальном времени. Вы просто подключаете JS-файл на страницу и настраиваете CallBack на события изменения данных. Все – дальше FireBase будет самостоятельно следить за данными и отдавать их пользователям. Причем, происходит это почти мгновенно! А еще с FireBase можно создавать веб-приложения, для которых вообще не потребуется собственный сервер. При этом для небольших сервисов использование FireBase совершенно бесплатно. Кроме этого, Firebase предоставляет установку прав доступа к частям данных на базе JS-выражений, транзакции (в отличие от MongoDB) и имеет встроенный функционал авторизации пользователей по электронной почте и паролю, а также авторизации с помощью сторонних поставщиков (OAuth), таких как Facebook, Twitter, GitHub, и Google.




Взглянув, как это работает, появилось желание переписать тьюториал на Dart.

Про результативность, качество и КПД сайтов знакомств можно спорить, можно искать 101 повод чем лучше в клубе/баре/_дополнить_варианты_/парке искать знакомства. То что еще лет десять-пятнадцать назад вызывало смех — теперь мейнстрим. Так не проще ли попытаться использовать еще одну возможность для поиска и общения в интернет с переходом к знакомству в жизни…



Гиковский вариант технологии поиска, скринкаст приложения под катом. В конце статьи ссылка на архив с работающим приложением под Apache License v2.0 и небольшим набором данных для примера.

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

Эта моя публикация чуть более чем полностью является ответом на перевод статьи «Почему вы никогда не должны использовать MongoDB». Статья, которая, по сути, рекомендует держаться подальше от MongoDB, является самой заплюсованной в хабе. И это звучит как приговор. Поэтому логично либо хаб закрыть и больше никогда не читать, либо написать ещё более рейтинговое опровержение. Конечно же, я выбрал второй вариант, рискуя своим рейтингом и кармой (ввиду крайней холиварности в комментах).

Картинка самоиронии

Какие key-value хранилища вы используете в бою?

Позаимствовал список с сайта db-engines.com (кстати, очень любопытный сайт, рекомендую), включил все базы с ненулевой «популярностью» оттуда. Не отмечайте базы которые просто пробовали/интересно, а только те, что крутятся и приносят деньги вашей компании прямо сейчас.

Обратите внимание: MongoDB это НЕ key-value хранилище, однако за нее можно проголосовать, см. пункт «Хранилище документов в качестве key-value».

Пишите, если забыл какую-то популярную базу (т. е. забыли авторы сайта db-engines.com), добавлю в опрос.

Какие свойства key-value хранилища вам важны?

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

Мой рассказ будет о том, как я, превозмогая трудности, решал задачу формирования новостной ленты. А также я расскажу о подходах, которые наработали ребята из проекта Socialite, и которыми они поделились на MongoDB World.

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

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

Эта публикация предполагает, что у вас есть некоторый опыт работы с Python и Redis и, в меньшей степени — с Lua, но и тем, у кого такого опыта нет, тоже будет интересно.

Зачем ограничивать число запросов?

Например, Twitter ограничивает количество запросов к своему API, а Reddit и StackOverflow используют ограничения на количество сообщений и комментариев.

Возможно Вы помните пост по этой книге


Прототип: Hadoop: The Definitive Guide
Publisher: O'Reilly Media; Third Edition edition (May 26, 2012)

Мы снизили цену на бумажную версию до 450 руб, PDF и EPUB — 199 руб

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

Первое, SQL и RDBMS
1.1. Необходимо знать язык SQL и основные принципы RDBMS как транзакции, foreign key, таблицы.
Допустим вы разработчик Java, и от вас еще требуют знать какой-то SQL и особенности RDBMS. Естественно вы ленитесь, пытаетесь как-то отвильнуть.
Да и к тому-же принцип ООП очень не похож на модель данных в RDBMS.
1.2. Если у вас большой проект, то вам нужен профессиональный БД разработчик, а это лишний балласт если не будет проектов в будущем.
Java программистам так и хочется сделать всю бизнес логику на Java в обход SQL и RDBMS.

Второе, Цена

Пусть и с некоторым опозданием по сравнению с остальными компаниями, но Microsoft сделала необходимое и выпустила собственную нереляционную базу данных: она называется DocumentDB. И пусть это проприетарная система, которая привязана к сервису Azure, это не делает новость менее значимой.

DocumentDB автоматически индексирует содержимое всех документов, допускает обработку запросов в реальном времени, полностью поддерживает требования ACID к транзакциям (атомарность, согласованность, изолированность, надёжность). Система очень похожа на MongoDB как эффективное хранилище JSON-документов с богатыми API для запросов, в то же время выгодно отличается от MongoDB по масштабируемости и надёжности работы, глубокой интеграции JavaScript, поддержке RESTful API, асинхронных запросов и др.



Как и MongoDB, DocumentDB представляет собой иерархию баз данных, коллекций и документов.

RocksDB – постоянное хранилище «ключ-значение» для быстрых накопителей. Основное ее предназначение — хранение данных на flash дисках.

Узким местом в производительности часто является обращение к БД.
Эта проблема может решаться по разному.
Использование кэша решает проблему производительности, но существенно усложняет архитектуру программы. Графовые базы данных выходят из ситуации за счет оптимальных для данной задачи алгоритмов. Другим типом решений являются хранилища, достигающие высокой производительности за счет использования быстрого носителя.
В последнее время появилось много NoSQL хранилищ полностью хранящих данные в памяти. Но память все еще стоит дорого и ее объем ограничен. Увеличение памяти за счет шардинга опять таки упирается в стоимость.
Логичным выходом из ситуации было бы использование SSD дисков. Они имеют относительно невысокую стоимость и при этом вполне небольшое время отклика.

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

Эта статья появилась на свет после прочтения материала «Почему вы никогда не должны использовать MongoDB». Ниже — история о том, как мы постепенно отказались от MySQL и пришли к использованию MongoDB в качестве основного хранилища данных.



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

Первым делом были сформулированы:

В любом обнаружении NoSQL баз данных кто-нибудь обязательно вспомнит о CAP-«теореме». Я не случайно пишу слово «теорема» в кавычках. CAP-«теорема» вовсе не теорема в математическом понимании этого слова. Это неформальное утверждение, сделанное Эриком Брюером в докладе на конференции Principles of Distributed Computing (PODC) в 2000 году. Эрик утверждал, что невозможно создать распределенное (состоящие из нескольких равноценных экземпляров — звеньев) веб-приложение, которое будет одновременно обладать тремя свойствами: согласованность (consistency), доступность(availability) и устойчивость к разделению(partition tolerance), сокращенно CAP. Неформальность утверждения заключается в том, что Брюер не дал определения этим трем понятиям.

Спустя два года Сет Гилберт и Ненси Линч опубликовали исследование, где дали определения понятиям CAP а также формализовали "отложенную согласованность" (Delayed Consistency), которую потом прозвали "согласованность в конечном счете" (Eventual Consistency) и доказали CAP-«теорему» в терминах указанных определений. Если вы еще не читали исследование, то это обязательно стоит сделать — lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

Эта «теорема» так бы и не была никому нужна, если бы её не взяли на вооружение маркетологи NoSQL.

Дисклеймер от автора (автор — девушка): Я не разрабатываю движки баз данных. Я создаю веб-приложения. Я участвую в 4-6 разных проектах каждый год, то есть создаю много веб-приложений. Я вижу много приложений с различными требованиями и различными потребностями хранения данных. Я разворачивала большинство хранилищ, о которых вы слышали, и несколько, о которых даже не подозреваете.

Несколько раз я делала неправильный выбор СУБД. Эта история об одном таком выборе — почему мы сделали такой выбор, как бы узнали что выбор был неверен и как мы с этим боролись.Это все произошло на проекте с открытым исходным кодом, называемым Diaspora.

В следующую субботу, 19 июля, проведем в офисе Badoo встречу пользователей Tarantool.

СТРАНИЦА МЕРОПРИЯТИЯ НА MEETUP.COM

Константин Осипов (Mail.ru) расскажет о Tarantool 1.6, новой версии сервера, в которой были пересмотрены многие технические решения и сделана удобная, безопасная и по-прежнему высокопроизводительная СУБД.
Tarantool — это, в первую очередь, lock-free база данных, обрабатывающая все транзакции последовательно в одном потоке. Tarantool 1.6 — это и ещё полноценный Lua Application Server с поддержкой кооперативной многозадачности, неблокирующего ввода-вывода, стандартных пакетов Lua и пакетов, созданных специально для Tarantool.

Антон Поваров (Badoo) выступит с докладом«Tarantool в Badoo: хранение истории посещений».
Каждый день на badoo.com пользователи просматривают порядка 100 миллионов профилей других юзеров. Мы храним счетчики и полную историю посещений за последние 90 дней, с некоторой агрегацией — это около 5 миллиардов ивентов.