Тестування «швидкої MongoDB» - TokuMX в умовах, близьких до реальності

  В останньому випуску Радіо-Т ми згадували TokuMX — High-Performance MongoDB Distribution . Продукт цей звучить цікаво — 9ти кратне стиснення даних в комплекті з 20ти кратним приростом швидкості і підтримкою транзакцій. При цьому перехід з mongo на tokumx вельми простий і з точки зору зовнішнього спостерігача — повністю прозорий. Таке чарівництво здалося мені більш ніж привабливим і я вирішив перевірити наскільки все добре на практиці.
 
Зараз я використовую кілька mongodb систем різного розміру, як в AWS так і в приватних дата центрах. Мій патерн використання в основному орієнтований на рідкісну, але масивну запис даних (раз на день), кілька більш часті масивні операції читання (набір різноманітних аналізів) і постійне читання в режимі забезпечення даними фронтенд. Ніяких особливих проблем з Монг у мене немає, за винятком підступаючої (по розрахунком через 6 місяців) проблеми диска. Дані з нашої системи ніколи не видаляються і зрештою перестануть влазити на диски. У AWS Монг біжить на відносно дорогих EBS томах з гарантованим IOPS. Я вже планував конвенціональне вирішення проблеми відсутності місця на диску (перенесення старих даних на окрему Монгу в дешевій конфігурації), але тут попалася на очі TokuMX з обіцянкою стиснення в 9 разів, що відклало б мою проблему на наступні 4 роки. Крім того, відкат записи в Монжа робиться тільки з боку клієнта, і було б непогано обійтися без цього, але перенести на рівень сервера.
 
Якщо вам цікаво, як саме працює магія TokuMX, то ласкаво просимо на їх сайт . Тут я не буду розповідати що це таке і як його налаштувати, але поділюся результатами поверхневого тестування. Мої тести не претендують на наукову акуратність і основною метою мають показати, що буде в моїх реальних системах якщо перейти з Монг на току.
 
 Прозорість переходу:
 
З цим все прекрасно. Ні в одному з моїх тестів, що покривають роботу з Монг (близько 200), ніяких проблем не виникло. Все, що працювало з Монг працює і з току. Інтеграційні тести теж не виявили жодних проблем, тобто в моєму випадку можна перенаправити клієнтські системи на адреси TokuMX і вони продовжать роботу не помітивши підміни. Режим гібридної роботи Монг з току в одному replica set я не тестував, але підозрюю що і це буде працювати.
 
 Тестування запису:
 
Тести проводилися на 2х ідентичних віртуальних машинках з 2ма процесорами на кожну, 20G диска і 1G RAM. Хостової комп'ютер — MBPR i7, SSD, 16G RAM. Встявляісь запису (trade candles) за один день, всього 1.4м свічок. Середній розмір запису 270 байт. 3 додаткових індексу (один простий, 2 композитних).
 
 image
Як бачимо, різниця є і TokuMX реально швидше. Звичайно не в обіцяні 20 раз, але теж непогано. Хоча при цьому і спостерігається значно більше навантаження на процесор, але подібне можна чекати у зв'язку з компресією.
 
Розмір даних + індекси в TokuMX теж виявився менше, ніж у Монго, але всього в 1.6 рази .
 
 Тестування читання:
 
Читання тестувалося в режимі близькому до реального використання. Всі швидкі запити (по тікер) проводилися багато разів для випадкової вибірки з 200 токарів, всього 10000 запитів, результат усереднювався. Інтервальні (за часом) запити проводилися для 10-ти випадкових інтервалів і теж багато разів. У Монгу і току посилалися одні й ті ж запити в однаковому порядку. Основна мета цього тесту була створити активність, максимально близьку до реальної. Час приведено в мікросекундах.
 
 image
Не повіривши своїм очам, я провів ці тести багаторазово і подібний результат (з невеликими флуктуаціями) повторювався стабільно. У всіх моїх тестах подібна різниця, де монго обганяє tokumx в півтора — три рази, незмінно відтворювалася.
 
Вирішивши, що можливо справа в тому, що для TokuMX треба більше CPU, я провів нерівний бій де виртуалка з toku з 4мя процесорами змагалася з Монг на двох. Результат трохи краще, але все одно монго залишається швидше навіть у цих, нерівних умовах (різниця в середньому в 1.4 рази). Єдиний тест, в якому току обійшла Монгу (майже в 2 рази) це останній — все свічки за день.
 
Подумавши, як би все це потестувати ще, я зменшив обсяг RAM для обох конкурсантів, щоб набір даних не поміщався в пам'яті. Отримав ось такі результати:
 image
Загалом цей результат виглядає ще гірше і різниця в 12 раз не викликає особливого оптимізму. Однак перші два тести помітно ближче до Монжа, і в моєму випадку загальний результат мабуть буде порівнянний, тому що подібних "поліпшених" запросив у мене багато разів більше, ніж сильно просіли.
 
У процесі тестування в малій кількості пам'яті, натрапив на якусь дивну особливість току — якщо заданий об'єм кеша не поміщається в доступний RAM, току просто обрізає відповідь і звичайно клієнтська сторона від цього приходить в сильне здивування і починає кричати, що дані закінчилися раніше ніж очікувалося.
 
І ще одне — у всіх цих тестах була монго "з коробки". Для TokuMX я зробив послаблення в останньому тесті — активував direct IO і задав розмір кеша як рекомендовано у них в керівництві.
 
 Висновки:
Мій попередній висновок такий: те, що TokuMX пише про себе, а саме "в 20 разів швидше і в 9 разів компактніше з коробки", в моєму випадку не зовсім правда. Практично всі операції читання були повільніше (іноді значно повільніше) у TokuMX і лякаюче тихе обрізання відповіді теж не радує. Для мене підтримка транзакцій, прискорення записи в 1.4 рази (при цьому немає лока на базу, але тільки на документ) і виграш у розмірі даних в 1.6 рази, не варті значного просідання продуктивності всіх операцій читання.
  
Джерело: Хабрахабр

0 коментарів

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