Новый тренд на 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" при бронировании билетов.
И совсем последнее: Конференция уже на следующей неделе и мы станем писать реже — будем отсыпаться и отдыхать. Но потом мы вернёмся, новые публикации вы сможете найти в блоге на Хабре и в наших бесплатных рассылках. Будем рады оставаться на связи!
