Tarantool: приклади використання



Tarantool — це СУБД з відкритим вихідним кодом. Хто завгодно може скачати її з GitHub і використовувати як в комерційних додатках, так і в некомерційних. Сьогодні технічний директор Почта@Mail.ru Денис Анікін розповість про приклади використання цієї бази даних. Матеріал підготовлений за мотивами виступу на конференції FailOver Conference.

Tarantool розробляється Mail.Ru Group вже більше семи років. Ця СУБД розрахована на високонавантажених системи. Її основна відмінність: це база даних, яка поєднує в собі властивості цієї БД — транзакції, реплікації, все що стосується надійності, — але при цьому вона така ж швидка, як і кеші, наприклад, Memcached або Redis.

В Mail.Ru Group добра половина продуктів працює на Tarantool. Йому віддається перевага в тих випадках, коли від СУБД потрібні властивості кешу, тобто вона повинна вміти робити 100 тис. апдейтів в секунду, в неї має бути дуже гарне latency — 1 мс або менше — і так далі. Багато СУБД не задовольняють цим критеріями. Якщо використовується багато шардов, то це не йде на користь: перестають працювати транзакції, втрачається цілісність і виникають інші проблеми. А кеші, в свою чергу, не володіють багатьма корисними властивостями БД: надійність зберігання даних на диску, транзакціями і так далі. Наприклад, в кешах зазвичай немає такої важливої штуки, як збережені процедури. Вони дозволяють переносити логіку на бік сховища даних.

БД + кеш = ?
Звичайно, можна жити на високонавантажених проектах і без Tarantool. Припустимо, вам потрібні властивості і бази, і кеша в одному флаконі. Тоді можна застосувати дуже популярну схему: помістити кеш поверх БД. Тоді всі запити йдуть спочатку в кеш, якщо в ньому є потрібні дані, то вони віддаються користувачеві. Якщо їх там немає, то запит переадресовується у БД. Всі оновлення йдуть відразу і в БД, і в кеш, адже ми не можемо щось зберігати в кеші, не зберігши це в базі, інакше ці дані можуть бути втрачені.

Така схема дозволяє отримати частину властивостей СУБД. Наприклад, транзакцій і зберігання процедур вже не буде, тому що коли з'являються дві системи, особливо кеш, то ні про які транзакції мова не йде. У якомусь сенсі втрачається і реплікації, тому що дані в базі реплікуються, а в кеш — як би не зовсім. Також губляться збережені процедури і інші властивості БД. Властивості кеша зберігаються теж частково. Така система працює швидше, тому що збільшується швидкість обробки звернень на читання, але при цьому, наприклад, звернення на запис швидше не стає. Якщо база даних загальмувала, тому що у неї відбувається вакуум таблиці або щось ще, то система буде гальмувати на запис, тому що без БД запис не працює.

В цілому, це робоча схема. Вона дозволяє отримати частину властивостей і бази, і кеша в одній системі. Якщо вам цього достатньо, то таку схему і треба використовувати.

Правда, в цьому випадку виникають дві часті проблеми — неузгоджені дані і холодний старт. «Неузгодженість» означає, що дані в кеші і базі можуть виявитися різними, тому що кеш і база не є реплікою один одного, це просто дві окремі сутності. «Холодний старт» — це ситуація, коли при старті кешу він ще порожній, даних в ньому немає, тому всі запити летять в базу, і продуктивність системи залишає бажати кращого.

Якщо вас не бентежать ці моменти, то схема «кеш поверх БД» — цілком робочий варіант. В іншому випадку доцільно звернути увагу на Tarantool, тому що в ньому всі ці проблеми вирішені спочатку. Одна з причин його розробки і полягає в тому, щоб не городити такі складні гетерогенні системи, що складаються з декількох сховищ, а спокійно обходитися одним і зберігати в ньому всі гарячі дані.

Движки
У Tarantool є два движка зберігання даних. Один з них — це in-memory движок. Влаштований він так: всі дані зберігаються в пам'яті, копії даних є на диску. На диск пишеться кожна транзакція просто в loc, і час від часу на диск скидається цілком snapshot всієї бази. Скидається асинхронно у фоновому режимі. Поки він скидається, база працює, тому що всі нові оновлення йдуть в окремі місця. Тобто все працює без гальм. Loc транзакцій пишеться завжди.

Другий движок дисковий. Він дозволяє зберігати всі на диску. Причому можна використовувати як SSD, так і вінчестери. Цей движок зріс з гуглового LevelDB, який був оптимізований.

Переваги та недоліки
Tarantool притаманні властивості, характерні для кеша:

  • Гарячі дані.
  • Доступність 99,99%.
  • Оптимальна робота при високій паралельної навантаженні.
  • Latency:
    • 99% запитів < 1 мс
    • 99,9% запитів < 3 мс

  • Навантаження на запис до 1 мільйона операцій в секунду на одному ядрі ЦП.
  • Не потрібно багато серверів.
  • Оптимальне використання пам'яті.
  • Система працює постійно, не потрібно робити перерву на профілактичні роботи.
В основному тут все пов'язано з високою швидкістю роботи. Традиційні СУБД позбавлені цих властивостей. При цьому Tarantool володіє і властивостями класичних СУБД:

  • Персистування (надійність зберігання даних на диску).
  • Транзакції ACID.
  • Реплікація (master-slave і master-master).
  • Збережені процедури.
  • Неблокирующие серверні сценарії.
  • Зручні бекапи.
  • Виконання запитів Cursors, Range і Full scan.
  • Первинні і вторинні індекси.
  • Таблиці.
Знову ж таки, у кешу цих властивостей немає, а в Tarantool вони присутні.

Одні сучасні БД націлені на високу надійність роботи, інші роблять упор на швидкість роботи. Це два різних світи, які, в основному, не перетинаються. Tarantool — це досить успішна спроба об'єднати обидва світу в одному рішенні.



До недоліків Tarantool можна віднести наступне:

  • У нього поки не дуже велика спільнота. Перш ніж застосовувати якусь технологію, кожна людина завжди думає: «якщо вона не буде працювати? У кого спитаю?». Розробники Tarantool намагаються бути і відповідати на питання скрізь: в Facebook, на Stack Overflow і так далі. Але з точки зору ряду користувачів є ризик не отримати відповідь через нечисленності співтовариства.
  • Відсутня консистентный шардінг. Над цим зараз ведеться робота, щоб він вже з коробки був нормальний, з підтримкою транзакцій.
  • Пропрієтарний протокол.
Приклади використання Tarantool
Всі приклади взяті з досвіду роботи проектів Mail.Ru Group. Насправді їх дуже багато, але ми розглянемо лише три: систему аутентифікації, систему push-повідомлень і систему показу реклами. Зазвичай вони самі високонавантажених.

Система аутентифікації

Вона повинна володіти рядом, здавалося б, суперечливих вимог.

  • Висока затребуваність: аутентифікація повинна перевірятися при кожному хіті на веб-сайті або в мобільному додатку. Потрібно перевірити пароль, куки, токен, що завгодно, адже не можна просто так впускати користувача. На порталі Mail.Ru і в мобільних додатках кількість запитів до системи аутентифікації обчислюється мільйонами в секунду.
  • Latency — час між запитом і відповіддю від бази даних. Воно повинно бути якомога менше, інакше все буде гальмувати, в тому числі і веб-сервер, який використовує аутентифікацію. Поки він чекає відповіді від БД, він займає який-небудь потік або процес, дані висять в пам'яті, і це теж споживає серверні ресурси. Тобто повільна система роботи аутентифікації може потягти за собою купу проблем, тому вона повинна працювати просто моментально.
  • Висока доступність. Якщо система автентифікації не буде працювати в 1% випадків, то й весь сайт не буде працювати в 1% випадків.
  • Постійні звернення до сховища. Кожний хіт в системі аутентифікації — це перевірка сесії, пароля, токена.
  • Захист від brute-force атак і шахрайства. Систему аутентифікації постійно намагаються зламати.
  • Майже кожне звернення пов'язане з виконанням транзакції, тобто з необхідністю зміни будь-яких даних. Наприклад, при виконанні аутентифікації потрібно перевірити введені дані, відновити місце та час аутентифікації, інші параметри для системи захисту від brute-force. Все це — пряма транзакція в БД. Цей запис не можна втрачати.
  • Багато неминучої зайвої роботи. Коли всі намагаються зламати систему, то за кулісами відбувається дуже багато звернень, які генеруються не користувачами, а засобами злому. Ці звернення не несуть корисний трафік або прибуток. Це зайве навантаження. Але їх доводиться обробляти і перевіряти.
  • Великий розмір даних. Природно, в системі аутентифікації повинна зберігатися вся користувацька база.
  • Наявність терміну дії введених користувачем даних (expiration). З міркувань безпеки, якщо користувач не активний якийсь час, його сесія завершується. Для цього необхідно перевіряти час початку сесії і наявність активності.
  • Надійність зберігання даних (persistence). Очевидно, що якщо система автентифікації «забуде» частина користувачів в результаті втрати облікових даних, то це прямий збиток репутації.
У цілому цей набір властивостей може виглядати суперечливим. Якісь з них зазвичай реалізуються кэшами, а якісь- базами даних. Система аутентифікації повинна бути надійна і довговічна як вантажівка, але при цьому така ж швидка, як спортивна машина. І Tarantool припав тут як не можна до речі.

Схема роботи системи аутентифікації Mail.Ru за логіном і паролем:



Тільки при перевірці логінів та паролів Mail.Ru виконується 50 тис. транзакцій в секунду. Захист від brute-force і система аутентифікації кожен раз читають і пишуть в Tarantool. Ця сумарна навантаження досягає приблизно мільйона запитів в секунду: від всього порталу, від всіх мобільних додатків, від усіх Ajax — і неАјах-запитів.



При цьому сесії обслуговує всього 4 сервера, а профілі користувачів — 8 серверів. Не якісь брендові, спеціальні сервери, а самі звичайні, з звичайними процесорами. Нічого космічного.

Система push-повідомлень

Як ви знаєте, мобільні додатки люблять надсилати користувачам push-повідомлення, щоб вони залишалися у них довше. Тобто це така гарна і вдячна штука.

Як влаштована система сповіщень Mail.Ru?



Коли на сервері відбуваються якісь події — прийшов лист, повідомлення в месенджер, з'явилася новина — потрібно надіслати повідомлення на мобільні телефони кінцевих користувачів. Безпосередньо це зробити неможливо. Тому Apple і Google надають API для iOS і Android, за допомогою яких можна смикати мобільні додатки.

Але звертатися до цих API безпосередньо з сервера не можна. Чому — про це трохи нижче. Крім того, при кожному генеруванні події треба сходити в сховище, щоб зрозуміти, якому користувачеві доставляти це подія. І не забути прочитати токен, тому що API працюють з токенами. І все це треба зробити дуже швидко.

Також вкрай важливо зберегти дуже низьке latency, оскільки події генеруються з великої кількості різних контекстів і серверних середовищ. Ніколи не можна гальмувати на сервері, чекати секунду-дві, бо інакше всі інші учасники процесу по ланцюжку почнуть працювати повільно. З цієї причини ми до API не безпосередньо з сервера, а через чергу, теж працює на Tarantool. Ця СУБД може надавати і сервіс черг, причому персистентних і реплицируемой. Тобто при падінні машини, при виході диска з ладу, при перезавантаження сервера ніхто нічого не помічає.

Виходить, що сервер працює безпосередньо лише з швидким сховищем, а всі повільне розташоване далі, за чергою. Така схема дозволяє швидко обробляти всі: сумарна кількість запитів у цій системі близько 200 тис. в секунду.

Система показу реклами

Це, напевно, самий перевантажений варіант використання Tarantool, і це найбільша ферма, яка є в Mail.Ru Group. Система відповідає за показ реклами майже на всіх сторінках величезного порталу, причому рекламних блоків на сторінці зазвичай не менше 10.

Щоб показати кожен рекламний блок, потрібно зрозуміти, що взагалі потрібно показувати користувачеві. Для цього дані про нього збираються з декількох різних джерел. Все це агрегується та формується результат. Все це робиться для кожного блоку, і на це треба витратити менше однієї мілісекунди. Звідки така вимога? Тому що користувачі не захочуть, щоб сервіс гальмував через реклами, вона і так всіх дратує, але є необхідним злом.



Навантаження на систему показу реклами — близько 3 млн запитів в секунду. Причому 1 млн з них — це зміни, тому що показ реклами часто призводить до оновлення профілю користувача.

Короткий висновок
Якщо вам потрібно поєднувати властивості БД і кеша, — надійність і швидкість, — і якщо якимись простими методами, якими ви звичайно це робите, не вдається цього досягти, то придивіться до Tarantool. Швидше за все, він цю проблему вирішить.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.