Як вибрати In-memory NoSQL базу даних з розумом. Тестуємо продуктивність

image

Дмитро Калугін-Балашов (Mail.RU
Доповідь у мене по базах даних In-Memory NoSQL. Хто знає, що таке In-Memory NoSQL база даних? Підніміть руки, будь ласка… Як вам не соромно? Зал по базах даних, і тільки половина знає, що це таке.

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




Перший варіант — популярність. Так склалося історично, тобто ви прийшли на роботу, і у вас там така база даних, ви її не обирали, ви просто хочете, наприклад, її змінити.

Другий варіант — мені порадив друг. Цей варіант теж досить популярний.

Третій варіант — повірив рекламі. Це теж пов'язано з популярністю, прочитали якусь статтю: «О, Redis — класна база даних, давайте його використовувати».

А тепер у мене таке питання: хто з вас вважає себе інженером? Тобто ви закінчили внз і маєте інженерну освіту. Я пропоную використовувати інженерний підхід до вибору бази даних. Я пропоную їх тестувати. Самостійно. Ви можете розумно мені заперечити, що в Інтернеті вже повно тестувань баз даних, і ви можете просто подивитися, як люди тестували. Так робити теж не треба, бо ви побачите, що все дуже сильно залежить від конкретної ситуації. Тобто ви можете подивитися, як протестована база даних, запустити у себе і не отримати те, що у тієї людини. Тобто вам треба тестувати на своїй навантаженні, на своїх машинах — віртуальних чи невиртуальных, на своєму оточенні. Тому весь мій звіт про інженерний підхід до вибору баз даних.

Дивіться, цей чоловічок — це ви. Ви вважаєте себе інженером. Тобто цей чоловічок крутий.



А є чоловічок, який не інженер, який може бути повівся на рекламу, може бути повірив одному або просто вибрав Redis, тому що всі вибирають його. Так от, нам з ним не по дорозі. І тому ми будемо вибирати зеленого чоловічка, будемо діяти як інженери.

Тепер питання: що ми будемо тестувати? Як думаєте, що можна тестувати? Яку кількість даних можна вмістити?

Дивіться, є два параметри — throughput і latency.



Підніміть руки, хто розуміє різницю між цими параметрами? Десь 10% слухачів у залі. Тоді я поясню. Хто ходив в такий магазин коли-небудь?



Є палять? Куди ви за сигаретами ходіть, в Ашан або ближче? Ближче, напевно, так? Так от, цей магазин — він особливий, у нього дуже маленька latency. Latency — це очікуваний час, коли ви йдете за сигаретами, наприклад, між прийняттям рішення і, власне, як ви їх отримали. Тобто ви зрозуміли, що їх треба купити, спустилися в двір, зайшли в магазин, взяли, підійшли до кас, купили, повернулися. Пройшло 15 хвилин. Це ваше latency.

Throughput — це вже параметр магазину — скільки людей таких, як ви, він в одиницю часу може пропустити. Тобто в цьому магазині зазвичай одна каса, з купою народу, і там проходить один чоловік у дві хвилини.



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

Є інша сторона, обратн а сторона Місяця. Виглядає ось так:



Хто був в Ашані? Всі були. Відмінно. Бачили, як він влаштований? Там кас багато. І вони працюють паралельно, в один і той же час.



Таким чином, в один момент Ашан пропускає через себе більше людей. Але якщо ви захочете щось купити в Ашані, вам треба спершу сісти в машину, доїхати кудись за МКАД, припаркуватися, вийти, взяти візок, простирчати там дві години, купити і приїхати додому. Тобто latency для вас буде дуже великим, але throughput у цього магазину маленький.

Всі зрозуміли, що таке throughput і latency, якщо ми говоримо про базах даних? Очікуваний час виконання запитів — це latency, а throughput — це скільки запитів в секунду ми здатні обробити.

І ще один параметр, який треба тестувати — це memory footprint.



Знаєте, як з англійської «footprint» перекладається? Відбиток ноги. Такий ось.



Спеціально з ранку обвів ногу дружини, поки вона спала, підписав, це memory footprint. Що ж це таке? Якщо ми Гбайт чистих даних засунемо в базу даних і подивимося, скільки в СУБД наша сама програма в пам'яті займає, то це буде не Гбайт, це буде більше. На скільки більше — це і є величина memory footprint. Навіть «під» скільки більше разів, тобто скільки байт ми на 1 байт додатково витрачаємо. Це важливий параметр, тому що він визначає, скільки нам треба купувати оперативної пам'яті. Тобто це такий грошовий параметр.

І як ми будемо бази даних тестувати? Є утиліта YCSB — Yahoo! Cloud Serving Benchmark. З цієї ссилочку є її клон:



Це мій репозиторій в github, там деякі зміни, я про них розповім.

Чому саме цю утиліту треба використовувати?



  1. По-перше, вона є галузевим стандартом, йому довіряють, тобто нею, взагалі, тестують NoSQL бази даних.
  2. Далі, там дуже легко написати свої профілі навантажень, тобто якщо він у вас якийсь нестандартний профіль, то ви можете легко конфігурацію написати і
    протестувати.
  3. Там легко написати драйвера для інших баз даних, там і так стандартних багато, але якщо у вас щось нестандартне, ви можете самі написати.
А чому її не варто використовувати? Я знайшов одну велику причину:



Ті, хто любить Java, ви краще всіх, мабуть, знаєте, її негативні сторони. Вона витрачає багато ресурсів. І, як раз, Костя розповідав про гроші, оскільки саме Java з'їла мої гроші, тому що машину-тестер довелося замовляти більш потужну, ніж якщо б… Я думав, там трохи потрібно, а Java не влазить ні в пам'ять, і CPU там багато ядер потрібно. Мені потрібна була більш дорога машинка, щоб протестувати, тому це я записав в мінус. Але це мінус мій особистий, може бути, ви мільйонер, і Java вам не завадить в цій справі.

У цього YCSB є стандартні workload'и. Workload — це профіль навантаження. Які вони є? Їх шість стандартних видів:



A — це 50% запитів на читання, 50% — на запис. Простий workload.

B — це 95% на читання, 5% на update, на запис.

C — це 100% read-only.

Далі йдуть більш цікаві.

D — це 95% на читання, 5% на insert, але там одна специфіка є — він читає тільки те, що нещодавно вставлено. Це, наприклад, ви в ВК пишете новину, написали, відправили — це insert. 5% insert. А ваші друзі, у вас їх тонна, вони починають читати, F5 смикають, і навантаження ось так створюється. Тобто такий профіль — це щось на зразок стрічки новин.

Профіль E — це важкі запити типу scan. Це запит по діапазону. 5% insert і 95% scan. Тобто це коли у вас якийсь пошук відбувається по купі даних, які поруч не лежать.

І останній — це теж цікавий workload. Там 50% голих read'ів, а 50% такої композиції — спершу read, потім modify, потім write. Тобто ми прочитали якийсь шматочок, змінили і записали. Досить часто така комбінація.

Ми можемо дуже легко написати будь шар. Там дуже прості конфіги — у п'ять рядків, просто процентовку пишемо і спосіб впливу, наприклад, якщо insert, то ми потім селектим найсвіжіші дані — це для workload D.

Отже, як написати свій драйвер? Тому що там не було драйвера memcached. Я розумію, що багато memcached за базу даних, взагалі не вважають. Що робимо?



Є такий java клас, можемо від нього отнаследоваться. Реалізуємо ось такі. Там їх п'ять методів. Їх просто реалізуємо. Якщо якийсь workload не передбачає метод, наприклад, у нас не було workload з методом delete, то ми можемо його навіть не реалізовувати.

Будемо будувати такі графіки:



Дивіться, по горизонталі у нас число потоків, і ми точки вказуємо логарифмічно — 8 потоків, 16, 32 і так до 1024. А по вертикалі — графік throughput — скільки запитів в секунду. Це слабка квола виртуалка. Це база даних Tarantool. Це workload A.

Як ми будемо тестувати?



Дуже важливо, щоб машина-тестер і машина з базою даних перебували в рамках одного датацентру і як можна ближче, щоб виключити вплив мережі на latency.

Чому не можна тестувати на одній машині? Я протестував. Бачите, це один і той же Tarantool на одній і тій же машині. Зелененька — це на одній машині, а красненьке — це на двох машинах. Це роздільно, це разом.



Давайте подивимося на цей горбик. Поки у нас 8, 16, 32 потоків у нас дійсно throughput вище на одній машині, але як тільки з'являється більше, з двох потоків, у нас сам тестер починає конкурувати за ресурси з базою даних і починає забирати ресурси, і ми назад падаємо.

Однак, з latency картина інша.



Latency, коли роздільно, нижче, тому що у нас є якась мережа, яка latency і поїдає, тобто у нас таку відстань. Коли ми тестуємо разом, у нас latency буде краще.

Реальна історія, пов, звичайно, роздільне тестування.



Далі, всі тести були дуже кволих виртуалках, дуже затиснуті ресурсів. Якщо у нас буде виділений сервер, то у нас форма кривої збережеться, але у нас буде величезна відстань.



Це була Azure найменша, яка можна, або майже найменша, з парою ядер.



Знаєте, що таке WAL? Це засіб збереження персистентності, Write-Ahead Log. Як це працює? Ви додаєте щось в базу даних, це лог транзакції — туди кінець записується, що ви зробили з базою даних, тобто всі зміни. Якщо у нас з якоїсь причини вимкнули живлення, просто перезавантажили, при старті ми прочитуємо — уздовж цей лог — і зчитуємо всі команди, відновлюємо посмертне такий стан.

З WAL воно буде працювати по-іншому. Ці всі тести були без WAL. Як воно буде працювати з WAL, різницю покажу:



Бачите, зелена — це з WAL. Тут є різниця. Це без WAL, це з WAL. І тут є. Чому різниця? Це workload A, що означає, що 50% read, 50% update.

Якщо ми візьмемо latency за read, дивіться, що буде:



Тут немає ніякої різниці. Тобто на читання взагалі WAL не впливає. Бачите, як вийшло?

А коли ми робимо update, різниця є:



Тому що нам доводиться писати на диск і, зрозуміло, це уповільнює справа.



Виртуалки теж бувають різні. Тобто чому не можна брати з Інтернету готові результати тестів? Дивіться, це дві виртуалки:



Це DigitalOcean, це Azure. Бачите, вони зовсім по-різному працюють.

І тепер — як ми, взагалі, вибираємо базу даних? У нас буде, якщо ми говоримо про інженерний підхід, кілька етапів. Перший етап — ми вибираємо її як якісно.

Я взяв чотири бази даних. Перша — це редиска.



І я просто передплачую те, що важливо для мого проекту, якісь якісні значення, тобто просто, що прийде в голову, mind map малюю. Що є у Redis? Є Only Append Files — це WAL, як раз, тобто ми можемо якусь персистування зберігати. Що ще є? У нього, що важливо для проекту, наприклад, розвинуте ком'юніті. Якщо мені це важливо, то я це вписую собі. Що ще у Redis хорошого? У нього текстовий протокол, але це недобре, тобто воно виписано як мінус. Зазвичай текстові протоколи повільніше, ніж бінарні. Це добре видно на прикладі memcached, де є і такий, і такий протоколи, і бінарний швидше. І є збережені процедури, які часто в бізнес-логікою ми пишемо з збереженими процедурами, тому вони є.



Tarantool. Хто, взагалі, користується Tarantool? Трохи в залі. Перше, Tarantool — це документно-орієнтована база даних, така справжня. Основні її конкуренти — це key value. По-друге, є дерев'яні індекси (або деревні? B-дерево, бінарне дерево — це воно і є, загалом-то, це жаргон такий). Ще є WAL в Tarantool, тобто може персистування мати. Там ще й снепшоты є. Є збережені процедури на Lua, їх теж можна порівнювати. Тут у мене тестів не буде, але їх можна порівнювати з тим же Redis, виходять вельми цікаві результати. І ще один шматочок лише для мене, для вас це, скоріше, не так, але Tarantool був зроблений у нас, в Mail.ru і якщо у мене якісь питання (тобто це те ж саме, що ком'юніті Redis), а тут можу прийти до Кості Осипову і запитати: «А що це таке?». Тому це я виписав собі в плюс. Спеціально пунктиром.



Далі, Memcached. Знаєте, звідки заєць? На головній сторінці Memcached такі ось зайці є. Memcached, на відміну від попередніх двох, навантажує всі ядра, він має бінарний протокол, тобто по-старому використовує текстовий, але ще у нього є бінарний, який швидше. І ще у нього немає персистентності, якщо ми впали, ми все втратили. Тобто можна як кеш використовувати, як щось інше — не можна.



І є CouchBase. Чому, взагалі, CouchBase в цій добірці? Він трохи відрізняється. Він є повноцінним enterprise-рішенням. Настільки повноцінним, що його дуже легко встановлювати. Настільки легко, що впорається дитина. Більш того, можна кластер зробити дуже легко. І теж дитина впорається. Тобто це на рівні кількох кліків миші. Це його сильно відрізняє від попередніх баз даних. І у нього ще memcached-протокол як у memcached, ну, дуже схожий, тому можна один і той же драйвер використовувати, і нам гріх не протестувати його, цей CouchBase, тому ми його взяли в тест.



І давайте тестувати за Throughput. Що у нас вийшло? Вийшла ось така картинка:



Синій колір — це база даних Tarantool. Темно-синій — це hash-індекси, світло-синій — це tree-індекси. Червоний у нас Redis. Помаранчевий, взагалі кажучи, теж Redis, але особливий, він називається Azure Redis Cache. Це сервіс від Microsoft. Він хмарний, його можна встановити в тому ж датацентрі, що і вашу тестову віртуалку, тому можна так протестить. Сіреньке у нас CouchBase. І зелененькі — Memcached. Дивіться, як memcached цікаво пішов. Є гіпотеза, тому що він все ядра навантажує, то він стелі пізніше досягає, але вона не перевірена поки.

Якщо ми змінюємо Workload'и на всіх, то картинка особливо не змінюється.







Workload F — це важкий workload.



Ось така картинка. Tarantool за throughput сильно виявився вище всіх конкурентів, прямо пристойно.



Якщо тестувати з WAL, що буде?

Це наша картинка без WAL:



І тепер ми додаємо WAL:



В принципі трохи знизилася, але нічого не змінюється. Tarantool і Redis — основна конкуренція, така картинка виходить. CouchBase і Memcached — вони сильно нижче, але у них WAL немає. У CouchBase є, але ще не тестував, у Memcached немає.



З приводу latency. Ця утиліта Yahoo!, вона latency за всіма типами команд вважає окремо. І Read latency так от виглядає:



І дивіться, latency чим нижче, тим краще. Тобто якщо throughput ми дивилися вгору, то тут треба дивитися вниз. Кольори ті ж самі, Tarantool нижче, потім Redis. Це latency середній.



Yahoo! вже дає дві перцентилі з коробки, але можна пропатчити, він вміє будувати гістограми, можна будь-яку перцентиль зробити, він дає 95-ту.

І ось дивіться сюди:



У нас Redis трохи гірше Tarantool на 95-ої перцентилі. А ось на 99-ой навпаки:



Тобто вони дуже близькі, але вони міняються місцями на 95-ої перцентилі. Тут ніякої похибки, тут точні дані. Тут число запитів було 5 млн. запитів, і перцентиль всі ці дані побудував на 5 млн. запитів на 2-х млн. записів.



Якщо у нас Upadate будуть (у нас workload A досі), що:



Average у нас ось такий буде. Бачите, де Memcached виявився, цікаво як.

А ось 95-й перцентиль, і Tarantool знову краще:



Але, коли ми йдемо в 99-ту перцентиль, тут знову краще Redis, але тут вже відстань між ними сильніше:



Чому так, що це означає? У Tarantool дуже багато швидких запитів, але є хвостик повільних запитів, а у Redis всі запити більше в серединці, тобто його гістограма трохи правіше йде. У Tarantool два «горба», тобто спершу швидкі запити, багато їх — 95%, а потім йдемо далі і багато повільних запитів, десь після 99-ої перцентилі йде за Redis. А у Redis один «горб» в середині. І якщо побудувати гістограми, Yahoo! тест вміє їх будувати, то ми це побачимо. Єдине, якщо там їх будете будувати самі, то за логарифмічною шкалою Х треба будувати, інакше нічого не побачите.



Є така цікава команда Read-Modify-Write. Це workload F. тобто прочитати-змінити-записати. Це важка команда, тому що там throughput залежить дуже сильно від latency, тому що ми повинні дочекатися даних від рідерів, щоб пропустити запит через себе.

Дивіться, там виходить картинка така от:



Тобто Tarantool за latency сильно нижче. І дивіться, тут дуже високо пішов хмарний наш Redis.

Якщо у нас 95-й перцентиль, Redis червоненький притиснувся до Tarantool, хмарний з memcached втекли:



Якщо у нас 99-а перцентиль, то вже Redis знову Tarantool трохи обігнав, тобто на 99-ої перцентилі Redis трохи Tarantool обганяє. Tarantool, який з дерев'яним індексом, пішов вгору. Така ось цікава картина:



Тепер дивіться, це один із способів тестування, Yahoo! тест. Я спробував написати інший тест, спробував змінити трошки підхід до тестування, не сильно, спробував вичавити максимум throughput, у першу чергу, з бази даних, тобто прямо до межі її дотиснути без всяких workload'ів. Такий тест складається з двох частин: спершу ми дані забиваємо, потім ми дані вычитываем. Є сторіночка, це дуже простий тест.



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



Як це працює? У нас є купа pool-потоків для нагнітання запитів до бази для throughput. Тут є сокети, їх там n штук, скільки хочемо, і кожному сокету у нас по два потоку. Один пише, взагалі, без розбору, пише-пише-пише, прямо автоматом. А другий вичитує дані щодо готовності. І є потоки для підрахунку latency. Їх трохи. Перше потоків багато і вони парами, потоки для latency — один, іноді два-три, і вони спершу пишуть, потім очікують відповіді, вичитують відповідь і те, що виділено там, вони підсумують. Спеціальні змінні атомарно підсумовуються, і вважається середнє. Тобто поки ще перцентиль не вважається. Найближчим часом я її зроблю, але поки вважається середнє. Звичайно, вони один одного аффектят, але за рахунок того, що у latency потоків дві-три штуки, а thoughput — там їх сотні, то аффектят вони несильно. До того ж, throughput сильно більше нагнітає без зупинки, а latency чекає. І є потік, який монітором разів в секунду зчитує всі змінні з пам'яті і виводить на екран.

І що у нас виходить?



Що погано в тесті Yahoo!, це те, що він використовує стандартні клієнти, тобто він тестує не саму базу даних, а базу даних у зв'язці з клієнтом. Коли я писав клієнт для Memcached, використовував spymemcached. Це бібліотека від авторів CouchBase, досить швидка, але, тим не менше, для нас це чорний ящик. І я поставив собі мету, взагалі, від клієнтів позбутися і зробити найпростіший клієнт, який лише для тіста, він взагалі не несе функціональності, в роботі його використовувати не можна, він уміє тільки відправляти запити та читати відповіді. Як це зробити? Дивіться, у Tarantool там три шматочка: перший — це розмір, header + body, а другий — це header, два числа. Нас цікавить те, що синім виділено. Це наш код повернення — або помилка, або не помилка. І знаючи перше поле, ми вважали перше поле, вважали header і вважали інше, знаючи розмір. І просто зчитуємо-зчитуємо-зчитуємо це справа без розбору в цих парах потоків (див. слайд ще вище), там зелененькі і червоненькі, які просто зчитують ломовим способом.

Msgpack — це такий бінарний протокол реалізації. Звичайна бібліотека від нього повільна і т. к. я намагався позбутися всіх бібліотек, є реалізація, написана теж у нас в компанії, називається msgpuck. Вона швидка, я її трохи допрацював для цієї справи.

З Memcached все ще простіше. Протокол у неї бінарний, fixed size структурка і плюс змінні довжини поля. Вичитали структурку, отримали код повернення, вичитали полі. Всі. Тобто дуже просто.

З Redis складніше, у нього текстовий протокол. Якщо ми заліземо в протокол Redis, то побачимо, що будь-який успішний відповідь на select починається з плюсик, тобто «+» і там далі щось повернеться. Будь-яка помилка — з минусиком. І якщо ми домовимося, що ні в них, ні в значеннях наших наборів даних, які ми записуємо і читаємо, не буде ні «+» ні «-», то читаючи голий потік байт з сокета, можна просто вважати плюси і вважати мінуси. «+» — це скільки повернулося успішних відповідей, «-» — це скільки повернулося помилок. Така реалізація буде швидкою, тобто «+» і «-», все. Зчитуємо, якщо байт не«+»,« -», ми його пропускаємо, якщо «+» або «-» — просто лічильники додаємо. І починаємо цю штуку ганяти. Ганялася вона на Azure і отримали такі результати:



Такі картинки я спершу приготував. Це весь тест. Бачите, там початок, це фази селектов, що відбувається там, RPS досить високі, вони сильно вище виходили, ніж у тесті Yahoo!.. Там, де пунктири, там WAL, там, де не пунктири — без WAL. Червоний — Tarantool, помаранчевий — Tarantool з деревом, зелений — Memcached, синій — Redis версії 2.

Так у нас були инсерты:



Чим більше у нас throughput, тим менше тест триває, тому що швидше запихається дані.

І так у нас вважається latency:



Відразу зверніть увагу, цей тест не від числа потоків графіки тут побудовані, а від часу.



І тут є «провали», тобто іноді тест Yahoo! може показати хороший результат, але коли починаємо роботу, в якісь моменти починає різко тупити. Середнє, начебто, нормальне, а тупежи такі можуть проходити. І графіки по часу бажано будувати. В Yahoo! це можна, якщо побудувати невеликі милиці. Тут воно будується досить природним способом, там відразу csv експортується в excel або ще куди-небудь. Ці графіки я приніс начальника, начальник сказав, дурниця, нечитаемо. Тому я перемалював. Ось так:



Це у нас throughput за селекту. Червоне — Tarantool (hash), а оранжевий — Tarantool (tree). Потім Memcached і тільки потім у нас Redis і Azure Redis Cached. Тут Redis версії 2. Не 3-й, останній, 3-ій трохи вище або в районі Memcached буде.

Якщо у нас з WAL, то картина не змінюється:



А якщо у нас latency, то ми можемо побачити, як раз, ті самі «провали».



Тобто, начебто, у нас великий throughput, але з'являється така штука, яка може нас у якісь моменти псувати все, що у нас тут працює. Це видно.



Якщо ми порівнюємо инсерты, то картина знову ж таки абсолютно передбачувана, як ми бачимо, тобто знову ж Tarantool вище.



І latency. Latency у Redis сильно вище, ніж у всіх інших, тобто там три лінії — всі в одну.



І тут теж таким ось чином.

І як вимірювати memory footprint?



Для цього маленький скриптик написаний. Він просто вважає, скільки пам'яті займає даний біт у нас, даний ідентифікатор процесу. Скрипт ось такий:



Читаємо просто RSS і складаємо ці шматочки RSS і через bc підсумовуємо. І ми виводимо його на стороні сервера з timeout'ом і складаємо.



І водночас, ми знаємо, скільки у нас даних пішло, бо на стороні тестера ми знаємо, скільки у нас вирушило запитів до бази даних. І можна побудувати графік.

Графіки цікаві самі по собі, але найцікавіше тут посмертне стан. І тут дуже несподівана картина, тобто її розмах буде дуже несподіваний.



Tarantool з хешем, ось Tarantool з деревом… Тут сіренькі — це скільки у нас байт фізично знаходиться в базі даних, а сіреньке + червоне — це скільки пам'яті займає сама наша СУБД, тобто скільки оперативної пам'яті вона витрачає. Дивіться, що відбувається тут — сильно багато виходу з пам'яті у нас. З Memcached — поменше. Ось такі картинки.

І ми підходимо до кінця. Тобто починав я з інженерного підходу, як ми взагалі вибираємо базу даних, і я його нагадаю. У нас така вороночка буде:



На вході у нас якісь є точки — це бази даних. І ми кожним ходом їх відсіваємо.

Є розумне питання: «А на хрена, взагалі, тестувати на синтетиці?». Відразу відповім.

У нас є багато баз даних. Я тестував чотири, їх, звичайно, більше. Можна і потрібно більше тестувати. Ми спершу вибираємо саме по якісним характеристикам, наприклад, нам потрібен селект по range from to, нам обов'язково потрібно B-дерево, і ми можемо відсіяти те, що у нас з хешем, який-небудь Memcached або інше. Чи нам потрібен обов'язково WAL, теж Memcached відсіється. І ми відсіємо спершу по якісним характеристикам. У нас є завдання якась, і ми просто видаляємо саме ті бази даних. Красненьким відзначені ті, які не підходять.

Далі ми тестуємо на синтетиці. Дивіться, баз даних у нас багато, на картинці у нас п'ять штук. Чому на синтетиці? Тому що якщо ми будемо тестувати одразу на реальних даних, ми помремо. Нам доведеться реалізувати бізнес-логіку для всіх баз даних, а це складно. Синтетика пишеться дуже швидко. Всякі утилітки, взагалі, «на коліні» робляться, налагоджують, звичайно, верифікуються, щоб схоже на правду, але все-таки робляться недовго. Якщо писати ще бізнес-логіку, то вона робиться довше, сильно довше.

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

Такий підхід. Моєю метою було показати, як треба вибирати базу даних.

Контакти

rvncerr
facebook
Блог компанії Mail.ru

Ця доповідь — розшифровка одного з кращих виступів на конференції розробників високонавантажених систем HighLoad++. Зараз ми активно готуємо конференцію 2016 року — у цьому році HighLoad++ пройде в Сколково, 7 і 8 листопада.

Також деякі з цих матеріалів використовуються нами в навчальному онлайн-курс по розробці високонавантажених систем HighLoad.Guide — це ланцюжок спеціально підібраних листів, статей, матеріалів, відео. Вже зараз у нашому підручнику понад 30 унікальних матеріалів. Підключайтеся!
Джерело: Хабрахабр

0 коментарів

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