Новый тренд на HighLoad++ — множество докладов об использовании оперативной памяти. Слово Константину Осипову, разработчику платформы Tarantool, автору доклада «Что особенного в СУБД для данных в оперативной памяти».
Ты отвечал в MySQL за производительность, как так получилось, что ты решил разрабатывать свою СУБД?
В MySQL я руководил одной из команд разработки сервера, за производительность там отвечали все.
MySQL по многим параметрам был работой мечты, но, к сожалению после того, как мы стали частью Oracle, многое изменилось.
Несколько моих коллег ушли в MariaDB, кто-то основал свою компанию (SeveralNines, FromDual). Я никогда не чувствовал себя «недогруженным», а с уходом многих ключевых разработчиков работа вообще превратилась в марафон по передаче знаний. Сопротивление поглощению, желание начать всё с чистого листа, бунт против медленного принятия решений большой компанией, нежелание по разным причинам уезжать в США, в конце концов, хорошее предложение от Mail.Ru, которому к этому моменту уже было около года — и я ушёл.
Если бы знал, куда ухожу, ещё десять раз подумал бы. Иногда вообще не было веры, что удастся сделать что-то полезное, чем будут пользоваться за пределами Mail.Ru, да и сейчас Tarantool очень далёк пока от «идеальной СУБД».
Почему Tarantool не просто СУБД, а именно платформа? В чём фишка делать платформу?
Мы просто делаем то, что имеет смысл. Если для классических СУБД оптимизация работы всегда идёт вокруг дисковой подсистемы, для СУБД в оперативной памяти узким местом в производительности очень быстро становится сеть. 100 000 запросов в секунду при размере запроса 1 КБ — и уже полоса 1ГБ карточки забита на 100%. При работе с памятью 100 000 запросов может дать один Тарантул, утилизирующий 1 ядро. А в современной машине ядер могут быть десятки. Поэтому и делаем application server, чтобы вычисления можно было делать не только на клиенте, но и приносить к данным.
Второе соображение в том, что очень многие продукты просто дублируют функционал друг друга. Например, сегодня очень многие используют Редис как замену Мемкэшу, просто чтобы иметь меньший «зоопарк» решений. Технологии под капотом там практически одинаковые. Платформа позволяет заменить несколько решений сразу, например, недавно мы сделали Memcached plugin, который реализует бинарный протокол Memcached для Тарантула.
В качестве бонуса пользователь получает все остальные наши возможности — мастер-мастер репликацию и подключаемые движки хранения, например.
Куда движется мир баз данных? Возрождение NoSQL — это ведь хорошо забытое старое? Почему именно сейчас? Что будет дальше?
Это большая тема для разговора, развивается сразу много параллельных трендов. Например, одновременно происходит и «специализация» — появляются нишевые инструменты, решающие узкий ряд задач очень качественно, и генерализация — в какой-то момент сообщество устаёт от зоопарка и останавливается на одном.
Думаю, в целом можно сказать, что эра NoSQL позади. Все NoSQL-решения добавляют SQL, просто не все это ещё успели сделать. Развиваются расширения SQL для работы с специализированными видами данных — графами, например.
С другой стороны, есть ещё очень большой пласт задач, для которого вообще нет стандартных декларативных языков — всё, что связано с большими данными и поиском знаний. Я думаю, нас в течение следующей декады ждёт конвергенция на этом фронте.
Из «железных» трендов, думаю, в ближайшие годы очень серьёзно будет развиваться ARM-платформа, стоит посмотреть хотя бы на продукты Cavium, облачный хостинг Scaleway, и во многом основанная на ARM глобальная автоматизация «оффлайн» среды.
В области бизнеса всем уже понятно, что облачные технологии становятся повсеместными. Для нас как для вендора это очень важно — нам придётся менять средства «доставки» продукта потребителю.
Если сегодня мы просто даём пакеты для разных популярных дистрибутивов, то завтра нам понадобится поддерживать ещё и множество облачных платформ — начиная просто с образа для Докера и заканчивая one-click-install в каком-нибудь Microsoft Azure или Heroku. Есть риск, что ситуация с облаками станет похожа на ситуацию с доступностью полок крупных супермаркетов мелким фермерам, хотя пока это совершенно не так.
Оперативная память становится всё более дешёвой и производительной, что позволяет использовать её для хранения рабочего набора данных всё большего числа приложений. Хранение всех данных в оперативной памяти позволяет сделать их высокодоступными, а алгоритмы для работы с данными либо существенно упростить, либо ускорить, а иногда — и то, и другое.
Что особенного в in-memory DBMS и чем работа такой программы отличается от произвольной высоконагруженной системы, написанной на С, С++, Java?
В своём докладе я расскажу о специализированных алгоритмах и структурах данных для хранения данных в RAM:
— Аллокация памяти без компромиссов: почему это возможно только в СУБД
— Хэши и ассоциативные массивы: как сделать их не только быстрыми, но и компактными
— Как может быть реализовано конкурентное обновление одних и тех же данных в памяти без блокировок
«Узкие места» в СУБД в памяти настолько существенно отличаются от аналогов в «классических» СУБД, что простота и элегантность являются необходимым условием выживания. Борьба идёт за байты и инструкции, и сложный код просто не может работать эффективно. Я расскажу, как простые решения для обработки транзакций в памяти позволяют упростить и ускорить репликацию, откат при аборте транзакции, поддержку «продвинутых» возможностей, таких как триггеры и изменение схемы данных.
Тему продолжает Дмитрий Калугин-Балашов с докладом «Как выбрать In-memory NoSQL базу данных с умом? Тестируем производительность». Мы обожаем такие доклады — Дмитрий провёл тесты таких NoSQL-решений как Memcached, Redis, Tarantool и CouchBase и представит на конференции результаты этого тестирования.
Мы не знаем, что выбрал Дмитрий, но один из лучших выборов — платформа Tarantool, СУБД и сервер приложений в одном флаконе. Команда Mail.Ru будет рассказывать о том, как переводили на Tarantool такие проекты как Почта, Рейтинги и Облака.
Внедрение в Почту позволило компании сэкономить миллион долларов — говорит нам технический директор Почта@Mail.ru Денис Аникин.
Василий Сошников (Рейтинги@Mail.ru) и Андрей Дроздов (Tarantool) расскажут об таком архитектурном паттерне как построение сервисов на базе Nginx и Tarantool. Учебный доклад, по шагам объясняющий логику работы паттерна. Кстати, у Tarantool есть upstream-модуль для Nginx.
Антон Резников и Владимир Перепелица (Облако@Mail.ru) расскажут о реализации поверх Tarantool концепции микросервисов. Да, Tarantool — это еще одна NoSQL база данных, но еще это полноценный сервер приложений. Приложений, расположенных рядом с данными!
— Не-не-не! Tarantool для нас это слишком, есть ли что-нибудь другое из NoSQL? — спросите нас вы.
Да, есть. Доклад Владимира Акрицкого «NodeJS в HighLoad проекте».
В течение последнего года мы разрабатывали проект DMP (Data Management Platform), используя NodeJS для прототипирования. На данный момент проект в большей степени все еще остался на JS и без труда справляется с текущими нагрузками в 10 000 запросов в секунду.
В докладе расскажу, почему остановились именно на NodeJS, хотя выбирали между .NET, Go, NodeJS, Python и Ruby. Почему не жалеем о своем выборе и будем дальше использовать для некоторых проектов.
Интересно?
Приходите на HighLoad++, у нас осталось меньше недели до конференции!
И последнее: Для пользователей «Хабрахабра» конференция предлагает специальную скидку в 15%, всё что нужно сделать — это воспользоваться кодом "IAmHabr" при бронировании билетов.
И совсем последнее: Конференция уже на следующей неделе и мы станем писать реже — будем отсыпаться и отдыхать. Но потом мы вернёмся, новые публикации вы сможете найти в блоге на Хабре и в наших бесплатных рассылках. Будем рады оставаться на связи!
Комментарии (30)
evocatus
28.10.2015 00:57+1На снимке экрана код на Lua, хотя в статье про него ни слова
youROCK
28.10.2015 01:19+1Приложения под Tarantool пишутся на LuaJIT
rtsisyk
28.10.2015 14:19+1Также имеется возможность написания модулей на C/C++ [1]. При помощи данного API можно подключить любой другой язык программирования или библиотеку, было бы желание. В частности, наш memcached[2] написан на сишном API.
[1]: tarantool.org/doc/reference/capi.html
[2]: github.com/tarantool/memcached
// Disclaimer: tarantool.org contributor
leventov
28.10.2015 05:47Мне кажется, Non-Volatile Memory может очень сильно поменять ландшафт систем хранения данных, и систем обработки данных в целом.
23derevo
28.10.2015 11:09+2это все баззворд очередной. По факту у нас сейчас в реальном мире есть иерархия памяти. Более быстрая — волатильна, более медленная персистентна. То, что мы сейчас называем оперативной памятью — ну да, волатильна. Но персистентность в этом месте стоит денег. Мы ведь с тобой понимаем, что чем ближе память к процу, тем она быстрее и дороже, а чем дальше — тем дешевле.
Так что я не соглашусь — с приходом NVM поменяется только свойства одного конкретного слоя, а не всей иерархии. Чтобы поменять ландшафт, нужно менять принципы, менять всю иерархию, а не только свойство конкретного слоя в нем.
demimurych
28.10.2015 13:59Если я верно понял весь сыр бор о том как правильно использовать большие обьемы данных размещенных в оперативной памяти. Иначе говоря, они уже уперлись в верхний потолок настолько, что выигрыш на сокращении таких издержек оказывается значимым.
То есть да, для разработчика БД в целом ничего не меняется. Все сливки для тех кто делает инструменты для разработчика. И когда говорят о структурном изменении какого то слоя иерархии — для них, тех кто делает инструмент, равнозначно изменению ландшафта в целом.23derevo
28.10.2015 14:13согласен. Зааффектятся именно разработчики инструментов, условно говоря, того же MySQL или Tarantool. Они будут делать изменения именно в изменившемся слое (например, RAM) и соседних слоях.
Тем не менее, практически невозможно оценить impact абстрактного изменения памяти на абстрактную (неизвестно какую) NVM :)leventov
28.10.2015 14:46Как раз мне кажется, что изменится поход. Зачем городить SQL запросы, если, грубо говоря, все состояние системы, удобно разложенное в родные рантаймовые структуры типа списков и мапов — durable из коробки.
Я говорю, может быть, не о 3d xpoint, который пока 1) помедленнее обычной памяти, 2) имеет чуть другой интерфейс, чтобы просто выбросить всю старую память и заменить на него. Но в перспективе 10, ну 15 лет, мне кажется, очевидно, что железячники закроют этот технологический зазор, и брать волатильную память не будет никакого смысла, потому что она будет стоить столько же и работать не быстрее.23derevo
28.10.2015 18:26за 10-15 лет столько всего может произойти, что ппц. Вот пришли лет 5 назад на рынок SSD, о которых 10 лет назад никто не слыхивал. Они на один-два порядка быстрее HDD десятилетней давности в разных сценариях. И что, разве мы можем сказать, что как-то принципиально изменились внутренности инструментов? Да нифига! Безусловно, разработчики инструментов и фреймворков адаптировали свои решения, но разве это было прямо-уж-так-заметно?
rudenkovk
28.10.2015 09:52Технологии под капотом там практически одинаковые. Платформа позволяет заменить несколько решений сразу, например, недавно мы сделали Memcached plugin, который реализует бинарный протокол Memcached для Тарантула.
Документация
Tarantool does not support the binary protocol of Memcached. If top performance is a must, Tarantool's own binary protocol should be used.
Где искать?
kostja
28.10.2015 13:13+2github.com/tarantool/memcached
вчера выложили, новая реализация бинарного протокола на новом plugin api
пока ещё сыро :)
talanchor
28.10.2015 13:58>>> В качестве бонуса пользователь получает все остальные наши возможности — мастер-мастер репликацию и подключаемые движки хранения, например.
Года два назад я слышал на каком-то докладе про то, что в тарантуле уже есть дисковый движок. Но по отзывам тех кто его пробовал — работа с ним была нестабильной и его использование в продакшене из-за этого было немного стремновато. Как сейчас с ним обстоят дела? Он уже стабилен и зарелизен или пока еще нет?
И еще вопрос про репликацию: мастер-мастер репликация — достаточно сложная, но нужная фича для отказоустойчивой работы системы. Правильно ли я понимаю, что тарантул умеет синхронно реплицировать данные между узлами, и в случае выхода из строя скажем одного из трех узлов продолжать работу и писать данные на оставшиеся два, и данные при этом остаются всегда консистентными?kostja
28.10.2015 14:05+2Привет!
София сейчас по нашим оценкам достаточно хорошо работает с объёмом данных до 500ГБ на инстанс, сейчас пытаемся сделать так чтобы нормально работала с терабайтными объёмами. Из существенных ограничений — пока нет вторичных ключей. Многокомпонентные ключи есть. В проде в mail.ru пока нигде нет — нам нужны как раз терабайтные объёмы, пытаемся запустить.
Мастер-мастер асинхронный, синхронный делаем в 1.7, который должен выйти в этом году.
igor_suhorukov
28.10.2015 15:28Разве на объемах 500ГБ на инстанс не выгоднее использовать шардированную реляционную или объектно-реляционную СУБД схожих объемов на инстанс, настроенную чтобы иметь большой дисковый кеш в ОЗУ?
По моему опыту, все inmemory db не дают таких же ACID гарантий как РСУБД, даже если СУБД используется как DataStore позади inmemory db
ilukyanov
29.10.2015 08:42А в чем разница Софии относительно LevelDB/RocksDB? Она работает поверх сырого блочного устройства или тоже поверх файловой системы?
igor_suhorukov
28.10.2015 15:22+1Все NoSQL-решения добавляют SQL, просто не все это ещё успели сделать.
Декларативный язык запросов и обновления упрощает работу с БД.
Но не то чтобы все, но многие… crate.io база на основе Elasticsearch — SQL JOINs are nearly ready
4dmonster
Если грубо упростить, развитие индустрии заключается в придумывании на каждом витке новых терминов.
— «Эра NoSQL позади»
— Что, опять?
— «один из лучших выборов — платформа…, СУБД и сервер приложений в одном флаконе»
— Что, опять?
— Все NoSQL-решения добавляют SQL, просто не все это ещё успели сделать. Все SQL-решения добавляют NoSQL, просто не все это ещё успели сделать.
— Что, опять?
— «Борьба идёт за байты и инструкции, и сложный код просто не может работать эффективно.»
— Что, опять?
23derevo
Это вообще характерное для любого явления развитие, не только в IT.
olegbunin
Константин Осипов работает в области баз данных уже несколько лет, а сейчас разработчик собственного NoSQL-решения. В Mail.RU Tarantool обслуживает сотни тысяч запросов в секунду. Мне кажется, что его мнение основано всё таки не на голословных утверждениях, а на реальной оценки ситуации.
4dmonster
Я не смог определить, где я опровергаю его мнение.
Если очистить содержимое статьи от мактетологии, а мой коммент от сарказма, они, как мне кажется, совпадут.
Хотя, есть предчувствие, что пока ещё на новый виток выруливать рано.
psman
leventov
Это не тот случай. Есть системы с протоколом (тот же memcached), а есть — позволяющие делать что угодно, реализовывать протоколы, например
psman
Не суть.
Тарантул конечно штука хорошая, но это +1 инструмент.
С нуля может и стоит начинать юзать где либо с оговорками на сырость и недоработки + особенности работы.
В текущих проектах рефакторить уже местами сложновато.