NoSQL - коротко о главном / Сергей Туленцев (TextMaster)Ontico
В последнее время сайты и веб-приложения растут всё быстрее, а задачи, стоящие перед БД, эволюционируют. Поэтому для (успешных) проектов традиционная реляционная СУБД часто не может удовлетворить все нужды. В ответ на эту проблему возникло большое количество разнообразных решений, очень различающихся по функциональности и характеристикам. При этом они все заносятся под один большой зонтик "NoSQL", что не способствует пониманию вещей. Запутанные веб-разработчики пытаются взять текущую модную и обсуждаемую NoSQL БД и приспособить её под свои нужды, не всегда понимая, нужную ли технологию они выбрали (референс к MongoDB is Web Scale http://www.youtube.com/watch?v=b2F-DItXtZs).
Целью доклада является упорядочение хаоса в головах разработчиков.
- Обзор популярных БД и их классификация (KV store, document store, columnar, etc).
- CAP-теорема и её применение к выбору БД (где-то параметры можно настроить, где-то подпереть сбоку костылем, где-то - увы).
- Типичные примеры применения.
- Антипаттерны применения (из личного опыта и тысяч прочитанных вопросов на stackoverflow :) ).
«Дорожная сеть в графовой базе данных Neo4j» — Вадим Шашенко, 2ГИС2ГИС Технологии
В своем докладе я расскажу, почему мы выбрали графовую базу данных Neo4j для проверки дорожного графа городов России (все населенные пункты с населением больше 300 000 жителей). Основные задачи, которые мы решаем средствами Neo4j — это проверки на связность и доступность проезда.
Опорные пункты доклада:
— SQL против графовых баз данных;
— обзор графовой базы данных neo4j;
— архитектура решения, в котором используется графовая БД;
— выполнение алгоритмов на графе в условиях его частых изменений.
В основе доклада лежат результаты работы над проектом «Fiji». Это внутрикорпоративная система, которая позволяет штатным картографам 2ГИС создавать, хранить и экспортировать карту во внешние продукты: онлайн-, десктоп- и мобильную версии 2ГИС.
NoSQL - коротко о главном / Сергей Туленцев (TextMaster)Ontico
В последнее время сайты и веб-приложения растут всё быстрее, а задачи, стоящие перед БД, эволюционируют. Поэтому для (успешных) проектов традиционная реляционная СУБД часто не может удовлетворить все нужды. В ответ на эту проблему возникло большое количество разнообразных решений, очень различающихся по функциональности и характеристикам. При этом они все заносятся под один большой зонтик "NoSQL", что не способствует пониманию вещей. Запутанные веб-разработчики пытаются взять текущую модную и обсуждаемую NoSQL БД и приспособить её под свои нужды, не всегда понимая, нужную ли технологию они выбрали (референс к MongoDB is Web Scale http://www.youtube.com/watch?v=b2F-DItXtZs).
Целью доклада является упорядочение хаоса в головах разработчиков.
- Обзор популярных БД и их классификация (KV store, document store, columnar, etc).
- CAP-теорема и её применение к выбору БД (где-то параметры можно настроить, где-то подпереть сбоку костылем, где-то - увы).
- Типичные примеры применения.
- Антипаттерны применения (из личного опыта и тысяч прочитанных вопросов на stackoverflow :) ).
«Дорожная сеть в графовой базе данных Neo4j» — Вадим Шашенко, 2ГИС2ГИС Технологии
В своем докладе я расскажу, почему мы выбрали графовую базу данных Neo4j для проверки дорожного графа городов России (все населенные пункты с населением больше 300 000 жителей). Основные задачи, которые мы решаем средствами Neo4j — это проверки на связность и доступность проезда.
Опорные пункты доклада:
— SQL против графовых баз данных;
— обзор графовой базы данных neo4j;
— архитектура решения, в котором используется графовая БД;
— выполнение алгоритмов на графе в условиях его частых изменений.
В основе доклада лежат результаты работы над проектом «Fiji». Это внутрикорпоративная система, которая позволяет штатным картографам 2ГИС создавать, хранить и экспортировать карту во внешние продукты: онлайн-, десктоп- и мобильную версии 2ГИС.
Движок LMDB — особенный чемпион / Юрьев Леонид (Петер-Сервис R&D)Ontico
Lightning Memory-Mapped Database (LMDB) представляет собой интересный, во многом уникальный движок базы данных класса Berkeley DB и Level DB с ребус-подобным исходным кодом. Будучи относительно малоизвестным, LMDB показывает ЧЕМПИОНСКУЮ производительность по чтению. Однако при интенсивной записи всё не так радужно…
Было ещё несколько проблем и недостатков, которые нам пришлось устранить, разбираясь в ребусах исходного кода. Доклад точно будет интересен разработчикам, интересующимся внутренностями баз данных или характеристиками отдельных движков.
Проект реализуется силами компании Петер-Сервис R&D, резидента Сколково, для применения в телеком-проектах федерального масштаба.
Информация о нашем проекте https://github.com/ReOpen/ReOpenLDAP/wiki, об исходной версии LMDB http://symas.com/mdb/.
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочет�
Преимущества NoSQL баз данных на примере MongoDBUNETA
Докладчик: Винников Олег – .NET Developer in Digital Cloud Technologies (https://twitter.com/#!/VinnikovOleg)
Тема доклада: «Преимущества NoSQL баз данных на примере MongoDB».
Доклад посвящен альтернативе реляционных СУБД - классу концепций NoSQL. Вы узнаете о основных видах NoSQL баз данных, их отличие и преимущества перед реляционными базами данных. Как основное преимущество, в докладе будет рассмотренно масштабирование NoSQL баз данных на примере MongoDB. Ключевые вопросы, которые будут рассмотрены в докладе:
- Почему NoSql;
- Краткий обзор видов NoSql баз данных;
- Масштабирование NoSql баз данных;
- Шардинг и репликация на примере MongoDB;
http://uneta.ua/community/events/9
Движок LMDB — особенный чемпион / Юрьев Леонид (Петер-Сервис R&D)Ontico
Lightning Memory-Mapped Database (LMDB) представляет собой интересный, во многом уникальный движок базы данных класса Berkeley DB и Level DB с ребус-подобным исходным кодом. Будучи относительно малоизвестным, LMDB показывает ЧЕМПИОНСКУЮ производительность по чтению. Однако при интенсивной записи всё не так радужно…
Было ещё несколько проблем и недостатков, которые нам пришлось устранить, разбираясь в ребусах исходного кода. Доклад точно будет интересен разработчикам, интересующимся внутренностями баз данных или характеристиками отдельных движков.
Проект реализуется силами компании Петер-Сервис R&D, резидента Сколково, для применения в телеком-проектах федерального масштаба.
Информация о нашем проекте https://github.com/ReOpen/ReOpenLDAP/wiki, об исходной версии LMDB http://symas.com/mdb/.
1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочет�
Преимущества NoSQL баз данных на примере MongoDBUNETA
Докладчик: Винников Олег – .NET Developer in Digital Cloud Technologies (https://twitter.com/#!/VinnikovOleg)
Тема доклада: «Преимущества NoSQL баз данных на примере MongoDB».
Доклад посвящен альтернативе реляционных СУБД - классу концепций NoSQL. Вы узнаете о основных видах NoSQL баз данных, их отличие и преимущества перед реляционными базами данных. Как основное преимущество, в докладе будет рассмотренно масштабирование NoSQL баз данных на примере MongoDB. Ключевые вопросы, которые будут рассмотрены в докладе:
- Почему NoSql;
- Краткий обзор видов NoSql баз данных;
- Масштабирование NoSql баз данных;
- Шардинг и репликация на примере MongoDB;
http://uneta.ua/community/events/9
Выбор NoSQL базы данных для вашего проекта: "Не в свои сани не садись"Alexey Zinoviev
Alexey Zinoviev Алексей Зиновьев рассказывает о выборе одной из следующих баз данных CouchDB, Neo4j, Mongo, Cassandra, HBase, Riak на Happydev 2013
Article "Choice of NoSQL database for your project: Don't bite off more than you can chew" presented on HappyDev 2013 (IT-conference in Omsk) by Alexey Zinoviev
The main idea of this article is comparison of the most popular NoSQL databases: CouchDB, Cassandra, Mongodb, Riak, Neo4j, HBase
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуат...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуатация HBase на паре жизненных примеров", Александр Чистяков (ведущий разработчик Git in Sky)
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Строим N...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Когда надо изобретать свой велосипед? Строим NoSQL хранилище в приемлемые сроки", Александр Календарёв (разработчик РБК-Медиа Холдинг / Love Planet)
Аннотация
- Что из себя представляет Современная служба знакомств (крупная соцсеть в миниатюре).
- Какие задачи мы решаем и немного про общую архитектуру проекта.
- Обзор про существующие key/value решения
- Почему не нас не устроили memcachedb, redis, tarantool или MongoDВ...
- Какие велосипеды пришлось изобретать и что взяли готовое.
- Протокол обмена, почему выбрали memcached
- Как и зачем расширять существующие протоколы
- Как устроено хранилище изнутри (на базе key/value Hash & Tree), немного скучной теории про структуры данных, полезно тем, кто все же рискнет написать что-то своё.
- какие key/value АПИ можно еще использовать.
- Проблемы здоровья хранилища или зачем и как делать Мониторинг.
- возможность масштабирования, проблемы и пути решения.
Биография
Опыт в IT индустрии 15 лет, кандидат наук. Докладчик на Hi++ 2011, ADDConf-2, DevConf 2012, PHPConf 2009 и других. Автор блога highloadblog.ru. Круг интересов: хранение и обработка данных.
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Оптимиза...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Оптимизация архитектуры для работы 24/7", Олег Краснов (системный архитектор SEMrush)
Аннотация
Со времени предыдущего доклада прошло полгода и мы сделали огромный рывок вперёд. В 2008 году система хранения SEMrush была построена на базе сочетания SQL с файловым хранилищем и позволяла выдерживать нагрузку примерно в 3 миллиона запросов в день. К моменту прошлого выступления нагрузка возросла на порядок, а сейчас на подобной нагрузке было успешно введено обновление данных онлайн без потери производительности.
В докладе, через призму краткой ретроспективы, будут освещены изменения технологий обработки данных проекта SEMrush. В ходе выступления будет проведен обзор изменившихся требований к системе, как в плане надёжности, так и скорости реакции на запросы пользователей. Выступление будет дополнено реальными проблемами, программного обеспечения и оборудования, а также способами их решения. Кроме этого будет произведён обзор планов на ближайшее будущее.
О компании
Компания SEMrush является разработчиком программного обеспечения для анализа конкурентов и определения ключевых слов для SEO оптимизации, входит в тройку мировых лидеров разработчиков аналитических инструментов для изучения трафика. Существует на рынке с 2007 года. Сервис SEMrush предоставляет пользователям информацию, необходимую для анализа конкурентной среды и оптимизации поисковой выдачи. SEMrush незаменим для углубленного анализа ключевых слов, позиций конкурентов, AdWords кампаний.
Как выбрать In-memory NoSQL базу данных с умом. Тестируем производительность ...Ontico
В настоящее время, когда рынок полон различных In-memory NoSQL решений, вопрос выбора особенно актуален. Часто приходится видеть ситуацию, когда базу данных выбирают по принципу "самая распиаренная", "друг посоветовал" и пр. Такой подход имеет мало общего с инженерным мышлением. Может ли оказаться так, что решение, которое на первый взгляд лежит на поверхности, оказывается вовсе не лучшим для поставленной задачи?
Я расскажу о своих муках выбора, в процессе которых был изучен существующий инструментарий (а также написан недостающий), позволяющий оценить применимость той или иной базы данных к текущей задаче. Также в докладе я покажу, к каким результатам привели тесты (да, будет очень много графиков) таких In-memory NoSQL решений как Memcached, Redis, Tarantool, CouchBase и др.
Непременным приложением к докладу будут все исходные коды и образы виртуальных машин, так что при желании вы сможете повторить все у себя :)
СУБД 2013 Лекция №10 "Нереляционное решение в области баз данных — NoSQL"Technopark
Технопарк Mail.ru Group, МГТУ им. Н.Э. Баумана. Курс "Базы данных".
Лекция №10 "Нереляционное решение в области баз данных — NoSQL". Лектор - Станислав Ступников.
Вводная часть посвящена определению и истории развития концепции NoSQL. Даются характеристики, рассказывается о способах использования. Рассматриваются виды NoSQL БД, теоретические основы NoSQL, а в конце лекции обсуждаются недостатки NoSQL-решений, а также проводится сравнение разных NoSQL-решений.
Видео лекции курса https://www.youtube.com/playlist?list=PLrCZzMib1e9obOz5K695ugYuiOOCBciEi
NewSQL: SQL никуда не уходит / Константин Осипов (tarantool.org)Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 12:00
Тезисы:
http://backendconf.ru/2017/abstracts/2788.html
Что такое NewSQL, почему NoSQL-движение превращается в NewSQL, и что эта трансформация привносит в SQL?
Попробуем разобраться, почему NoSQL-вендоры добавляют всё больше SQL-возможностей, почему стандарт SQL не пользуется популярностью, и куда это всё идёт.
Рассмотрим новые диалекты языка SQL, такие как:
- Cassandra QL
- Couchbase NQL
- Elastisearch
и сравним их с подходом MongoDB & RethinkDB, добавляющим новый язык работы с данными.
Останется ли в мире СУБД что-то ценного от NoSQL-движения?
Ну и, наконец, рассмотрим новый вызов реляционной модели: multi-model databases.
HighLoad++ 2017
Зал «Сингапур», 7 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/3069.html
Если ещё 10 лет назад движение нереляционных СУБД подчёркнуто называлось NoSQL и ходило под лозунгом «SQL is kludge», то сейчас мы видим, что на SQL можно «поговорить» практически с любыми источниками данных: двигаясь от SQL-подобных диалектов (вроде HiveQL, AQL, CQL), возникла целая плеяда SQL-on-Hadoop, среди которых есть способный просверлиться в самые невероятные нереляционные структуры Apache Drill, а в конце августа 2017 появился даже KSQL — SQL-движок над поточником Apache Kafka. И гордость российского NoSQL-субдостроения — Tarantool — также оснастился SQL-движком, а в мире IMDG (резидентных гридов данных) уже речь идёт не просто о поддержке SQL, а ведётся соревнование между движками за полноту соответствия стандартам SQL-99.
...
Ceph является одной из мнообещающих архитектур для построения облачных хранилищ данных. В презентации приведены основные возможности, описана архитектура, дан краткий обзор команд CLI
IBM Cloudant и Apache CouchDB: NoSQL базы данных эпохи облаковMaxim Zinal
Какой должна быть NoSQL СУБД эпохи облаков? Что такое IBM Cloudant и Apache CouchDB?
Как они связаны друг с другом, и есть ли польза для Open Source проекта от коммерческого облачного сервиса на его основе?
Azkaban is a batch workflow job scheduler created by LinkedIn to run Hadoop jobs. It features a simple web UI, scheduling of workflows, tracking of user actions, and email alerts. While it has a small community and only time-based scheduling, it can run command-line processes making it a good alternative to cron. The architecture includes a solo server mode for investigation and a two server mode for production.
2. 1. О задачах
2. О разновидностях (по структуре)
3. О разновидностях (CAP)
4. Об особенностях (транзакции, агрегаты)
5. Беглый обзор NoSQL решений
6. О проектном использовании
13. ● AC
Гибкие запросы, отличная согласованность, но отсутствие
горизонтального масштабирования: MySQL, MS SQL Server, Oracle DB
● AP
Географическая доступность: Cassandra*, MongoDB*,Couchbase
● CP
Аналитика, распределенные вычисления: HBase, MongoDB*
Назначение
14. Redis
● Open-source, НЕ распределенное, быстрое Key-Value
хранилище
● In-memory с сохранением на диск (append only log /
dump)
● Master-slave репликация (backup).
● Возможно хранить как простые примитивы, так и
сложные структуры (списки, словари, множества)
● Поддерживает сложные операции (работа с битовыми
масками, счетчики)
16. Aerospike
● Proprietary, распределенное, быстрое Key-Value
хранилище
● In-memory, SSD
● Шардинг
● Возможно хранить как простые примитивы, так и
сложные структуры
● Поддерживает вторичные индексы
17. Aerospike
● Встроенный язык Lua
● CP в CAP теореме
● Поддерживает репликацию между дата центрами
● Поддерживает сложные операции (compare and set,
set if unmodified, set if unique)
18. Couchbase
● Open-source, распределенное, документо-
ориентированное хранилище, может использоваться
как быстрое KV (кеш).
● Memcache - совместимое, с сохранением на диск.
● Protocol: memcached + extensions
● Язык запросов N1QL
19. Couchbase
● Все ноды равноценны (master-master replication)
● Отличный web интерфейс для управления
кластером
● Инкрементальный map/reduce
● Репликация между-дата центрами
● Вторичные индексы
20. MongoDB
● Open-source, распределенное, документо-
ориентированное хранилище
● Не равнозначные ноды Master/slave replication
● Протокол: Custom, binary (BSON)
● Javascript используется в качестве языка запросов
● Функции на стороне сервера. Инкрементальный
map/reduce
● Вторичные индексы
21. HBase
● Open-source, распределенная, версионная,
колоночная
● Хранит миллионы колонок, миллиарды записей.
● Работает по верх HDFS
● Используется для аналитики данных
● CP в CAP теореме
● Не поддерживает классический update
22. HBase
● Поддерживает:
○ Hadoop MapReduce
○ Random, fast read and write access
○ Запросы по диапазонам, с использованием
фильтров
○ Атомарный compare and set
○ Strong consistent reads and writes
● Не поддерживает:
○ ACID транзакции
23. Cassandra
● Open-source, распределенная, колоночная
● Хранит миллионы колонок, миллиарды записей.
● Самодостаточна (в отличии от HBase которая
работает по верх HDFS)
● AP/CP в CAP теореме
● Очень хороша для репликации данных между дата
центрами
24. Cassandra
● Поддерживает:
○ Язык CQL (без JION)
○ Конфигурируемая consistency
○ Random, fast read and write access
○ Атомарный compare and set, counters
○ MapReduce (нужен Hadoop)
○ Вторичные индексы*
● Не поддерживает:
○ ACID транзакции
25. HBase vs Cassandra
Это братья, а не конкуренты
Cassandra - AP (доступность)
HBase - CP (аналитика)
26. Neo4J
● Open-source, графовое хранилище
● Persistent disk-based storage written in Java
● ACID транзакции
● Миллиарды вершин на одном хосте.
● Индексы и атрибуты связи.
● Мощный поиск по графу через API и язык запросов
по графу Cypher
27. Транзакции, агрегаты, JOIN
● Транзакции не всегда нужны.
● Когда есть самодостаточные агрегаты.
● Блокировки на уровне агрегатов.
● JOIN -> Map-Reduce
28. В проектах: Tinkoff digital
● HBase - аналитика (сортированные данные, рандомный доступ, в
сравнении с логами)
● MongoDB - купились на шардинг и индексы (плохая идея)
32. Резюме
Нужен быстрый доступ к данным?
Redis, Aerospoke, Couchbase
BigData?
HBase, Cassandra
Разно-структурированные данные и гибкая
система запросов?
MongoDB