«Якщо ви можете кешувати все дуже ефективним способом, то ви часто можете змінити правила гри»
Ми, розробники програмного забезпечення, часто стикаємося з проблемами, що потребують поширення деякого набору даних, який не відповідає назві «великі дані». Прикладами проблем такого типу є такі:
- Метадані продукту в інтернет-магазині
- Метадані документа в пошуковій машині
- Метадані фільмів і ТВ-шоу
Стикаючись з цим, ми зазвичай вибираємо один з двох шляхів:
- Зберігання цих даних в якомусь централізованому сховищі (наприклад, реляційна СУБД, інформаційний склад NoSQL або кластер memcached) для віддаленого доступу користувачів
- Серіалізація (наприклад, json, XML тощо) і поширення серед споживачів, які зберігатимуть локальну копію
Застосування кожного з цих підходів має свої проблеми. Централізація даних може дозволити вашому набору даних необмежено зростати, однак:
- Мають місце затримки і обмеження по смузі пропускання при взаємодії з цими даними
- Віддалений інформаційний склад не може зрівнятися за надійністю з локальною копією даних
З іншого боку, серіалізація і збереження локальної копії даних повністю в ОЗУ може забезпечити на порядки менший час затримки і більш високу частоту доступу, однак і цей підхід несе з собою проблеми, пов'язані з масштабуванням, які стають більш комплексними в міру збільшення набору даних:
- Обсяг динамічної пам'яті, що займається набором даних, зростає
- Отримання набору даних вимагає завантаження додаткових бітів
- Оновлення набору даних може вимагати значних ресурсів ЦП або впливати на роботу автоматичного керування пам'яттю
Розробники часто вибирають гібридний підхід - кешують локально дані з частим доступом і використовують віддалено - з рідкісним. Такий підхід має свої проблеми:
- Управління структурами даних може вимагати значної кількості динамічної кеш-пам'яті
- Об'єкти часто зберігаються досить довго, щоб їх можна було поширювати, і негативно впливають на роботу автоматичного управління пам'яттю
У Netflix ми усвідомили, що такий гібридний підхід часто створює лише ілюзію виграшу. Розмір локального кешу часто є результатом ретельного пошуку компромісу між затримкою при дистанційному доступі для багатьох записів і вимогою до сховища (хіпу) при локальному зберіганні більшої кількості даних. Але якщо ви можете кешувати все дуже ефективним способом, то ви часто можете змінити гру - і тримати весь набір даних в пам'яті, використовуючи хіп меншого розміру і менше завантажуючи ЦП, ніж при зберіганні лише частини цього набору. І тут вступає в дію Hollow - останній проект з відкритим вихідним кодом від Netflix.
Hollow являє собою Java-бібліотеку і всеосяжний набір інструментів для використання розташованих в оперативній пам'яті наборів даних малого і середнього розміру, які поширюються від одного виробника до багатьох споживачів з доступом тільки для читання.
"Hollow змінює підхід... Набори даних, для яких раніше таку можливість ніколи не можна було навіть розглядати, тепер можуть бути кандидатами для Hollow.
Функціонування
Hollow зосереджений виключно на своєму запропонованому наборі проблем: зберігання цільного набору даних «тільки для читання» в оперативній пам'яті споживачів. Він долає наслідки оновлення і вивантаження даних з часткового кешу.
Завдяки своїм робочим характеристикам Hollow змінює підхід з позиції розмірів відповідних наборів даних для вирішення за допомогою оперативної пам'яті. Набори даних, для яких раніше таку можливість ніколи не можна було навіть розглядати, тепер можуть бути кандидатами для Hollow. Наприклад, Hollow може бути повністю прийнятним для наборів даних, які, якщо представляти їх в json або XML, зажадали б більше 100 Гб.
Швидкість адаптації
Hollow не просто покращує функціонування - цей пакет значно посилює швидкість адаптації команди при роботі із завданнями, пов'язаними з наборами даних.
Використання Hollow є простим прямо з першого кроку. Hollow автоматично створює користувальницький API, що базується на специфічній моделі даних, завдяки чому користувачі можуть інтуїтивно взаємодіяти з даними, користуючись перевагами виконання IDE-коду.
Але серйозний виграш виникає при використанні Hollow на постійній основі. Якщо ваші дані постійно знаходяться в Hollow, то з'являється багато можливостей. Уявіть, що ви можете швидко пройти весь виробничий набір даних - поточний або з будь-якої точки в недавньому минулому, аж до локальної робочої станції розробки: завантажити його, а потім точно відтворити певні виробничі сценарії.
Вибір Hollow дасть вам перевагу на інструментарії; Hollow поставляється з безліччю готових утиліт, щоб забезпечити розуміння ваших наборів даних і поводження з ними.
Стійкість
Скільки дев'яток надійності ви хотіли б мати? Три, чотири, п'ять? Дев'ять? Будучи локальним сховищем даних в оперативній пам'яті, Hollow не схильний до проблем, пов'язаних з навколишнім середовищем, в тому числі з мережевими збоями, несправностями дисків, перешкодами від сусідів в централізованому сховищі даних тощо. Якщо ваш виробник даних виходить з ладу або ваш споживач не може підключитися до сховища даних, то ви можете працювати з застарілими даними - але дані будуть як і раніше присутні, а ваш сервіс буде як і раніше працювати.
Hollow був доопрацьований протягом більш ніж двох років безперервної жорсткої експлуатації на Netflix. Ми використовуємо його для надання важливих наборів даних, необхідних для виконання взаємодії в Netflix, на серверах, що швидко обслуговують в реальному часі запити клієнтів при максимальній продуктивності або близько до неї. Незважаючи на те, що Hollow витрачає величезні зусилля, щоб витиснути кожен останній біт продуктивності з апаратних засобів серверів, величезна увага до деталей стала частиною зміцнення цієї критичної частини нашої інфраструктури.
Джерело
Три роки тому ми анонсували Zeno - наше чинне в даний час рішення в цій області. Hollow замінює Zeno, але є багато в чому його духовним наступником.
Концепції Zeno щодо виробника, споживачів, стану даних, копій стану об'єкта і змін стану перейшли в Hollow
Як і раніше, тимчасова послідовність змінюваного набору даних може бути розбита на дискретні стани даних, кожне з яких являє собою повну копію стану даних на певний момент часу. Hollow автоматично визначає зміну станів - зусилля, необхідне від користувача на підтримку оновленого стану, є мінімальним. Hollow автоматично дедуплікує дані, щоб мінімізувати обсяг динамічної пам'яті наших наборів даних у споживачів.
Розвиток
Hollow бере ці концепції і розвиває їх, покращуючи майже кожен аспект рішення.
Hollow уникає використання POJOs як представлення в оперативній пам'яті - натомість замінює їх компактним, з фіксованою довжиною, сильно типізованим шифруванням даних. Таке шифрування призначене як для мінімізації обсягу динамічної пам'яті наборів даних, так і для зниження частки вартості, пов'язаної з ЦП, при забезпеченні доступу до даних в реальному часі. Всі зашифровані записи упаковані в повторно використовувані блоки пам'яті, які розташовуються в JVM-хіпі, щоб запобігти впливу на роботу автоматичного управління пам'яттю на працюючих серверах.
Приклад розташування в пам'яті записів типу OBJECT
Набори даних в Hollow є самодостатніми - для серіалізованого блобу, щоб цей блоб міг би бути використаний фреймворком, не потрібен супровід з коду, специфічного для варіанту використання. Додатково Hollow розроблений зі зворотною сумісністю, завдяки чому розгортання може відбуватися рідше.
«Можливість побудови потужних систем доступу, незалежно від того, чи передбачалися вони спочатку при розробці моделі даних».
Оскільки Hollow повністю побудований на оперативній пам'яті, то інструментарій може бути реалізований за умови, що довільний доступ по всій ширині набору даних може бути виконаний, не виходячи з Java-хіпа. Безліч готових інструментів входить до складу Hollow, а створення ваших власних інструментів завдяки базовим компонувальним блокам, що надаються бібліотекою, є нескладною справою.
Основою використання Hollow є концепція індексування даних різними способами. Це забезпечує O (1) -доступ до відповідних записів в даних, що дає можливість побудови потужних систем доступу незалежно від того, чи передбачалися вони спочатку при розробці моделі даних.
Переваги
Інструментарій Hollow легко встановити і він має інтуїтивно зрозуміле управління. Ви зможете зрозуміти у ваших даних деякі аспекти, про які ви і не підозрювали.
Інструмент відстеження змін надає вам змогу слідкувати за зміною певних записів у часі
Hollow може посилити ваші можливості. Якщо щось у якомусь записі здається неправильним, то можна точно з'ясувати, що і коли сталося, використовуючи простий запит в інструмент відстеження змін. Якщо відбувається аварія і випадково відбувається випуск неналежного набору даних, то ваш набір даних можна відкотити назад до того, який був перед виникненням помилки, зафіксувавши виробничі проблеми на їх шляхах. Оскільки перехід між станами відбувається швидко, то ця дія може дати результат на всьому парку машин вже через кілька секунд.
«Якщо ваші дані постійно знаходяться в Hollow, то з'являється багато можливостей».
Hollow проявив себе як надзвичайно корисний засіб на Netflix - ми побачили повсюдне зменшення часу запуску серверів і зниження займаного обсягу динамічної пам'яті при постійно зростаючій потребі в метаданих. Завдяки цілеспрямованим зусиллям з моделювання даних, здійснюваним за результатами детального аналізу використання динамічної пам'яті, який став можливим з появою Hollow, ми зможемо і далі покращувати показники.
На додаток до виграшу в якості функціонування ми бачимо величезний приріст продуктивності, пов'язаний з поширенням наших каталожних даних. Це пояснюється частково тим інструментарієм, який є в Hollow, а почасти тією архітектурою, яка була б неможлива без нього.
Ув'язнення
Скрізь, де ми бачимо проблему, ми бачимо, що вона може бути вирішена за допомогою Hollow. Сьогодні Hollow доступний для використання всьому світу.
Hollow не призначений для роботи з наборами даних будь-якого розміру. Якщо даних досить багато, то збереження всього набору даних в пам'яті не є можливим. Однак при використанні належної структури і деякого моделювання даних цей поріг може бути набагато вище, ніж ви думаєте.
Документація є на http://hollow.how, а код - на GitHub. Ми рекомендуємо звернутися до короткого керівництва - потрібно лише кілька хвилин, щоб переглянути деморолик і побачити роботу, а ознайомлення з повністю промисловою реалізацією Hollow вимагає приблизно годину. Після цього можна з'єднати вашу модель даних і - вперед.
Якщо ви почали працювати, то можна отримати допомогу безпосередньо від нас або від інших користувачів через Gitter або Stack Overflow, помістивши мітку «hollow».