CodeFest 2018. Павел Димитрюк (Beeline) — Обработка и хранение потоковых данных в Apache Ignite

CodeFest 2018. Павел Димитрюк (Beeline) — Обработка и хранение потоковых данных в Apache Ignite

Посмотрите выступление Павла: https://2018.codefest.ru/lecture/1288/

Хочу поделиться опытом применения Apache Ignite в обработке потоковых данных больших объемов (500К/sec). Показать какие дополнительные возможности появляются в случае хранения окна потоковых данных в in-memory. Рассказать какие бизнес-кейсы мы решили на базе Apache Ignite. Показать на проблемы с которыми мы сталкивались в процессе эксплуатации.

16b6c87229eaf58768d25ed7b2bbbf52?s=128

CodeFest

April 05, 2018
Tweet

Transcript

  1. Обработка и хранение потоковых данных в Apache Ignite Хочу поделиться

    опытом применения технологии In-Memory Data Grid в потоковой обработке данных (500К/sec) Павел Димитрюк Программист Beeline
  2. Это моё личное мнение • Я показываю только суть и

    применяемые подходы • Реализация имеет право отличаться • Не согласны? Давайте спорить! 2
  3. Кому интересно? • Разработчики ◦ JVM languages ◦ C++ ◦

    .NET ◦ JDBC, ODBC ◦ ... 3
  4. Кому интересно? • Разработчики ◦ JVM languages ◦ C++ ◦

    .NET ◦ JDBC, ODBC ◦ ... • Архитекторы 4
  5. Немного о нас Нам департамент занимается развитием технологий больших данных

    в Билайн. 5
  6. Немного о нас Нам департамент занимается развитием технологий больших данных

    в Билайн. Данное подразделение образовано в 2012 году в Новосибирске. Уже как 6 лет мы занимается opensource технологиями связанными с BigData. 6
  7. Немного о нас Нам департамент занимается развитием технологий больших данных

    в Билайн. Данное подразделение образовано в 2012 году в Новосибирске. Уже как 6 лет мы занимается opensource технологиями связанными с BigData. Мы занимается развитием и сопровождением core-части Data Management Platform. Стараемся использовать только opensource 7
  8. План доклада • Текущую архитектуру BigData платформы 8

  9. План доклада • Текущую архитектуру BigData платформы • Почему начали

    смотреть на IMDG? ◦ Распределенные системы ◦ Немного об Apache Ignite 9
  10. План доклада • Текущую архитектуру BigData платформы • Почему начали

    смотреть на IMDG? ◦ Распределенные системы ◦ Немного об Apache Ignite • Задачи решаемые на Apache Ignite ◦ Как реализована обработка потоковых данных? ◦ Хранение данных в Apache Ignite ◦ Зачем хранить окна потоковых данных в памяти? 10
  11. План доклада • Текущую архитектуру BigData платформы • Почему начали

    смотреть на IMDG? ◦ Распределенные системы ◦ Немного об Apache Ignite • Задачи решаемые на Apache Ignite ◦ Как реализована обработка потоковых данных? ◦ Хранение данных в Apache Ignite ◦ Зачем хранить окна потоковых данных в памяти? • Особенности эксплуатации Apache Ignite 11
  12. Ну, поехали! • Текущую архитектуру BigData платформы • Почему начали

    смотреть на IMDG? ◦ Распределенные системы ◦ Немного об Apache Ignite • Задачи решаемые на Apache Ignite ◦ Как реализована обработка потоковых данных? ◦ Хранение данных в Apache Ignite ◦ Зачем хранить окна потоковых данных в памяти? • Особенности эксплуатации Apache Ignite 12
  13. Что такое DMP? 13

  14. Что такое DMP? 14

  15. Что такое DMP? 15

  16. Что такое DMP? 16

  17. Что такое DMP? 17

  18. Что такое DMP? 18

  19. Что такое DMP? 19

  20. Что такое DMP? 20

  21. 21

  22. Цель кластера • Запросы на данных больших объемов (источники по

    2TB в день) 22
  23. Цель кластера • Запросы на данных больших объемов (источники по

    2TB в день) • Объединение данных из различных источников (> 50 источников) 23
  24. Цель кластера • Запросы на данных больших объемов (источники по

    2TB в день) • Объединение данных из различных источников (> 50 источников) • Анализ показателей мобильной сети 24
  25. Цель кластера • Запросы на данных больших объемов (источники по

    2TB в день) • Объединение данных из различных источников (> 50 источников) • Анализ показателей мобильной сети • Построение витрин данных 25
  26. Цель кластера • Запросы на данных больших объемов (источники по

    2TB в день) • Объединение данных из различных источников (> 50 источников) • Анализ показателей мобильной сети • Построение витрин данных • Аналитические запросы 26
  27. Цель кластера • Запросы на данных больших объемов (источники по

    2TB в день) • Объединение данных из различных источников (> 50 источников) • Анализ показателей мобильной сети • Построение витрин данных • Аналитические запросы • Машинное обучение 27
  28. Какие данные собираем? Данные поступают более чем из 50 источников

    Природа данных: • События с телекоммуникационного оборудования • Логи • Информация из различных информационных систем • Справочники 28
  29. Немного цифр 29 Hadoop: Серверов: более 250 node CPU: более

    6000 core HDD: более 10 PB RAM: более 25 TB Ежедневный прирост: 15 TB Kafka: Серверов: более 15 node Input: 1’700’000 rec/sec (240 MB/sec) Output: 530 MB/sec NoSQL: 350K req/sec NiFi: Серверов: более 20 node Output: 1’400’000 rec/sec Ignite: Серверов: около 10 node RAM: 900 GB Input: 500’000 rec/sec
  30. Немного цифр 30 Hadoop: Серверов: более 250 node CPU: более

    6000 core HDD: более 10 PB RAM: более 25 TB Ежедневный прирост: 15 TB Kafka: Серверов: более 15 node Input: 1’700’000 rec/sec (240 MB/sec) Output: 530 MB/sec NoSQL: 350K req/sec NiFi: Серверов: более 20 node Output: 1’400’000 rec/sec Ignite: Серверов: около 10 node RAM: 900 GB Input: 500’000 rec/sec
  31. Немного цифр 31 Hadoop: Серверов: более 250 node CPU: более

    6000 core HDD: более 10 PB RAM: более 25 TB Ежедневный прирост: 15 TB Kafka: Серверов: более 15 node Input: 1’700’000 rec/sec (240 MB/sec) Output: 530 MB/sec NoSQL: 350K req/sec NiFi: Серверов: более 20 node Output: 1’400’000 rec/sec Ignite: Серверов: около 10 node RAM: 900 GB Input: 500’000 rec/sec
  32. Немного цифр 32 Hadoop: Серверов: более 250 node CPU: более

    6000 core HDD: более 10 PB RAM: более 25 TB Ежедневный прирост: 15 TB Kafka: Серверов: более 15 node Input: 1’700’000 rec/sec (240 MB/sec) Output: 530 MB/sec NoSQL: 350K req/sec NiFi: Серверов: более 20 node Output: 1’400’000 rec/sec Ignite: Серверов: около 10 node RAM: 900 GB Input: 500’000 rec/sec
  33. Batch vs Stream processing • Пакетная обработка данных (batch processing)

    ◦ off-line ◦ большие пачки данных 33
  34. Batch vs Stream processing • Пакетная обработка данных (batch processing)

    ◦ off-line ◦ большие пачки данных • Потоковая обработка данных (stream processing) ◦ on-line ◦ данные поступают непрерывно ◦ интересно каждое событие в отдельности 34
  35. Где stream? 35

  36. Где stream? 36

  37. Где stream? 37

  38. Ей, что дальше? • Текущую архитектуру BigData платформы • Почему

    начали смотреть на IMDG? ◦ Распределенные системы ◦ Немного об Apache Ignite • Задачи решаемые на Apache Ignite ◦ Как реализована обработка потоковых данных? ◦ Хранение данных в Apache Ignite ◦ Зачем хранить окна потоковых данных в памяти? • Особенности эксплуатации Apache Ignite 38
  39. Какие задачи? • Обработка потоковых данных с “какой-то” бизнес логикой

    ◦ Обогащение потока данных 39
  40. Какие задачи? • Обработка потоковых данных с “какой-то” бизнес логикой

    ◦ Обогащение потока данных ◦ Создание триггерной системы (реагирование на определенные события происходящие в рамках одного ключа) 40
  41. Какие задачи? • Обработка потоковых данных с “какой-то” бизнес логикой

    ◦ Обогащение потока данных ◦ Создание триггерной системы (реагирование на определенные события происходящие в рамках одного ключа) ◦ Актуализация профиля в realtime 41
  42. Какие задачи? • Обработка потоковых данных с “какой-то” бизнес логикой

    ◦ Обогащение потока данных ◦ Создание триггерной системы (реагирование на определенные события происходящие в рамках одного ключа) ◦ Актуализация профиля в realtime • Доступ по REST API 42
  43. В чем сложность? • Поток данных в 500’000 в сек

    43
  44. В чем сложность? • Поток данных в 500’000 в сек

    • 90’000’000 пар ключ-значение 44
  45. В чем сложность? • Поток данных в 500’000 в сек

    • 90’000’000 пар ключ-значение • Реагирование на изменение в атрибутах 45
  46. В чем сложность? • Поток данных в 500’000 в сек

    • 90’000’000 пар ключ-значение • Реагирование на изменение в атрибутах • Расчет “оконных метрик” 46
  47. Эти задачи сводятся к ... Некоему гибриду из: • Потоковой

    обработки 47
  48. Эти задачи сводятся к ... Некоему гибриду из: • Потоковой

    обработки • Накопления стейта из потока данных 48
  49. Эти задачи сводятся к ... Некоему гибриду из: • Потоковой

    обработки • Накопления стейта из потока данных • Получение данных из стейта по ключу ◦ Данные можно привести в виду key -> value 49
  50. Эти задачи сводятся к ... Некоему гибриду из: • Потоковой

    обработки • Накопления стейта из потока данных • Получение данных из стейта по ключу ◦ Данные можно привести в виду key -> value • Job-ы на этом стейте 50
  51. На кой черт тебе это надо? • Текущую архитектуру BigData

    платформы • Почему начали смотреть на IMDG? ◦ Распределенные системы ◦ Немного об Apache Ignite • Задачи решаемые на Apache Ignite ◦ Как реализована обработка потоковых данных? ◦ Хранение данных в Apache Ignite ◦ Зачем хранить окна потоковых данных в памяти? • Особенности эксплуатации Apache Ignite 51
  52. Зачем тут распределенные системы? • Как выдержать такой поток обновлений?

    52
  53. Зачем тут распределенные системы? • Как выдержать такой поток обновлений?

    • Горизонтальное масштабирование 53
  54. Зачем тут распределенные системы? • Как выдержать такой поток обновлений?

    • Горизонтальное масштабирование • Сохранность данных 54
  55. Зачем тут распределенные системы? • Как выдержать такой поток обновлений?

    • Горизонтальное масштабирование • Сохранность данных • Логика обработки отправляется к данным 55
  56. Зачем тут распределенные системы? • Как выдержать такой поток обновлений?

    • Горизонтальное масштабирование • Сохранность данных • Логика обработки отправляется к данным • Ночью нужно спать! 56
  57. Что такое распределенные системы? 57

  58. Что такое распределенные системы? 58

  59. Что такое распределенные системы? 59

  60. Что такое распределенные системы? 60

  61. Что такое распределенные системы? 61 • Шардирование данных

  62. Что такое распределенные системы? 62 • Шардирование данных • Избыточность

    в хранении ◦ Достижение консенсуса
  63. Что такое распределенные системы? 63 • Шардирование данных • Избыточность

    в хранении ◦ Достижение консенсуса • Распределенные вычисления
  64. Distributed + Streaming = ? 64

  65. Distributed + Streaming = ? 65

  66. Неужели… дошли до Ignite! • Текущую архитектуру BigData платформы •

    Почему начали смотреть на IMDG? ◦ Распределенные системы ◦ Немного об Apache Ignite • Задачи решаемые на Apache Ignite ◦ Как реализована обработка потоковых данных? ◦ Хранение данных в Apache Ignite ◦ Зачем хранить окна потоковых данных в памяти? • Особенности эксплуатации Apache Ignite 66
  67. Внимание Мное что будет рассказано о возможностях Apache Ignite, актуально

    и для других IMDG систем На время доклада это все одно и тоже: • Apache Ignite • IMDG (In-Memory Data Grid) • IMDF (In-Memory Data Fabric) 67
  68. Что такое Apache Ignite? (Key, Value) -> 68 p/s Так

    происходило мое осознание :)
  69. Что такое Apache Ignite? (Key, Value) -> HashMap -> get(),

    put() 69 p/s Так происходило мое осознание :)
  70. Что такое Apache Ignite? (Key, Value) -> HashMap -> get(),

    put() ConcurrentHashMap -> JCache, transaction 70 p/s Так происходило мое осознание :)
  71. Что такое Apache Ignite? (Key, Value) -> HashMap -> get(),

    put() ConcurrentHashMap -> JCache, transaction Distributed Cache -> peer-to-peer communication 71 p/s Так происходило мое осознание :)
  72. Что такое Apache Ignite? (Key, Value) -> HashMap -> get(),

    put() ConcurrentHashMap -> JCache, transaction Distributed Cache -> peer-to-peer communication Distributed computing -> tasks, map-reduce 72 p/s Так происходило мое осознание :)
  73. Что такое Apache Ignite? (Key, Value) -> HashMap -> get(),

    put() ConcurrentHashMap -> JCache, transaction Distributed Cache -> peer-to-peer communication Distributed computing -> tasks, map-reduce Distributed DataBase -> SQL, Table, Indexes 73 p/s Так происходило мое осознание :)
  74. Что такое Apache Ignite? (Key, Value) -> HashMap -> get(),

    put() ConcurrentHashMap -> JCache, transaction Distributed Cache -> peer-to-peer communication Distributed computing -> tasks, map-reduce Distributed DataBase -> SQL, Table, Indexes Distributed services -> Service grid 74 p/s Так происходило мое осознание :)
  75. Кеши, какие они? • LOCAL 75

  76. Кеши, какие они? • LOCAL • REPLICATED 76

  77. Кеши, какие они? • LOCAL • REPLICATED • PARTITIONED 77

  78. Кеши, какие они? • LOCAL • REPLICATED • PARTITIONED •

    NEAR 78
  79. Еще что-то есть…? • Текущую архитектуру BigData платформы • Почему

    начали смотреть на IMDG? ◦ Распределенные системы ◦ Немного об Apache Ignite • Задачи решаемые на Apache Ignite ◦ Как реализована обработка потоковых данных? ◦ Хранение данных в Apache Ignite ◦ Зачем хранить окна потоковых данных в памяти? • Особенности эксплуатации Apache Ignite 79
  80. А где же у Вас Ignite? 80

  81. Просто огонь! 81

  82. Можно подробней о stream processing? 82

  83. Можно подробней о stream processing? 83

  84. Можно подробней о stream processing? 84

  85. Можно подробней о stream processing? 85

  86. А причем тут Ignite? 86

  87. Какой следующий шаг эволюции? 87

  88. Следующий шаг эволюции 88 • Affinity collocation ◦ Данные и

    вычисления радом ◦ Связанные данные рядом
  89. Следующий шаг эволюции 89 • Affinity collocation ◦ Данные и

    вычисления радом ◦ Связанные данные рядом • P2P коммуникация узлов
  90. Как готовим Ignite? • Ignite развернут в Kubernetes 90

  91. Как готовим Ignite? • Ignite развернут в Kubernetes • Данные

    из Kafka вычитываются каждой серверной Ignite нодой ◦ Часть данных через клиентские Ignite ноды 91
  92. Как готовим Ignite? • Ignite развернут в Kubernetes • Данные

    из Kafka вычитываются каждой серверной Ignite нодой ◦ Часть данных через клиентские Ignite ноды • Данные распределяются по узлам кластера согласно Affinity function 92
  93. Как готовим Ignite? • Ignite развернут в Kubernetes • Данные

    из Kafka вычитываются каждой серверной Ignite нодой ◦ Часть данных через клиентские Ignite ноды • Данные распределяются по узлам кластера согласно Affinity function • На нодах происходит обработка бизнес логикой ◦ Все данные по одному ключу находятся на одной ноде 93
  94. Как готовим Ignite? • Ignite развернут в Kubernetes • Данные

    из Kafka вычитываются каждой серверной Ignite нодой ◦ Часть данных через клиентские Ignite ноды • Данные распределяются по узлам кластера согласно Affinity function • На нодах происходит обработка бизнес логикой ◦ Все данные по одному ключу находятся на одной ноде • Персистентном для Ignite служит Cassandra 94
  95. Какой API для загрузки данных? • DataStreamer ◦ StreamReceiver ▪

    данные сохранять не обязательно 95
  96. Какой API для загрузки данных? • DataStreamer ◦ StreamReceiver ▪

    данные сохранять не обязательно • Загрузка данных их kafka реализована на reartive-kafka ◦ Мы отказались от KafkaStreamer и DataStreamer ▪ когда сдвигать offset в kafka? 96
  97. Какой API для загрузки данных? • DataStreamer ◦ StreamReceiver ▪

    данные сохранять не обязательно • Загрузка данных их kafka реализована на reartive-kafka ◦ Мы отказались от KafkaStreamer и DataStreamer ▪ когда сдвигать offset в kafka? ◦ Используем reactive-kafka и обычный putAll() ▪ offset сдвигаем после успешной записи 97
  98. Обогащение потока данных 98

  99. Обогащение потока данных 99

  100. Обогащение потока данных 100

  101. Подписываемся на поток изменений 101 • Использование continuous query ◦

    LocalListener ◦ RemoteFilter ◦ initial QueryCursor
  102. Подписываемся на поток изменений 102 • Использование continuous query ◦

    LocalListener ◦ RemoteFilter ◦ initial QueryCursor • Использование services ◦ Логика на том же узле где происходят изменения
  103. Подписываемся на поток изменений 103

  104. Подписываемся на поток изменений 104

  105. Подписываемся на поток изменений 105

  106. Подписываемся на поток изменений 106

  107. Подписываемся на поток изменений 107

  108. Только нужные данные 108

  109. Только нужные данные 109

  110. Только нужные данные 110

  111. Только нужные данные 111

  112. Идем дальше... • Текущую архитектуру BigData платформы • Почему начали

    смотреть на IMDG? ◦ Распределенные системы ◦ Немного об Apache Ignite • Задачи решаемые на Apache Ignite ◦ Как реализована обработка потоковых данных? ◦ Хранение данных в Apache Ignite ◦ Зачем хранить окна потоковых данных в памяти? • Особенности эксплуатации Apache Ignite 112
  113. In-memory… а где гарантии? 113 • Ignite Native Persistence ◦

    почти все хорошо ;)
  114. In-memory… а где гарантии? 114 • Ignite Native Persistence ◦

    почти все хорошо ;) • 3rd party persistent storage ◦ дополнительные накладные расходы ◦ прогрев кешей
  115. 115 - Я так сильно потерялась, что потеряла то место,

    где я потерялась...
  116. - Я так сильно потерялась, что потеряла то место, где

    я потерялась... 116 Возможна ли потеря данных при аварийном выключении нод? • Синхронная запись
  117. - Я так сильно потерялась, что потеряла то место, где

    я потерялась... 117 Возможна ли потеря данных при аварийном выключении нод? • Синхронная запись • Фоновая запись ◦ batch - операции
  118. - Я так сильно потерялась, что потеряла то место, где

    я потерялась... 118 Возможна ли потеря данных при аварийном выключении нод? • Синхронная запись • Фоновая запись ◦ batch - операции • Write-Ahead Log?
  119. Прогрев caches в Ignite 119

  120. Прогрев caches в Ignite 120 • Загрузка данных при старте

    нод, без неё: ◦ Нельзя SQL, task и map-reduce ◦ Можно только get*(), put*()
  121. Прогрев caches в Ignite 121 • Загрузка данных при старте

    нод, без неё: ◦ Нельзя SQL, task и map-reduce ◦ Можно только get*(), put*() • Предопределили LifeCycle ◦ Ожидание топологии в N нод
  122. Прогрев caches в Ignite 122 • Загрузка данных при старте

    нод, без неё: ◦ Нельзя SQL, task и map-reduce ◦ Можно только get*(), put*() • Предопределили LifeCycle ◦ Ожидание топологии в N нод • Использование нового персистента Apache Ignite
  123. Ignite Native Persistence 123 • Durable Memory ◦ SQL и

    Map-Reduce без прогрева ◦ Часть в памяти, чать на диске
  124. Ignite Native Persistence 124 • Durable Memory ◦ SQL и

    Map-Reduce без прогрева ◦ Часть в памяти, чать на диске • Write-Ahead Log ◦ медленная синхронная запись
  125. Ignite Native Persistence 125 • Durable Memory ◦ SQL и

    Map-Reduce без прогрева ◦ Часть в памяти, чать на диске • Write-Ahead Log ◦ медленная синхронная запись • Index
  126. Ignite Native Persistence 126 • Durable Memory ◦ SQL и

    Map-Reduce без прогрева ◦ Часть в памяти, чать на диске • Write-Ahead Log ◦ медленная синхронная запись • Index • Данные на том же узле кластера
  127. Формат хранения данных 127 • Как Java Class ◦ Должен

    быть в CLASSPATH на каждом узле ◦ Что будет если отличаются версии класса?
  128. Формат хранения данных 128 • Как Java Class ◦ Должен

    быть в CLASSPATH на каждом узле ◦ Что будет если отличаются версии класса? • BinaryObject ◦ Для cassandra конвертируем к виду Map[String, Object]
  129. Формат хранения данных 129 • Как Java Class ◦ Должен

    быть в CLASSPATH на каждом узле ◦ Что будет если отличаются версии класса? • BinaryObject ◦ Для cassandra конвертируем к виду Map[String, Object] • Есть ли проблема эволюции структуры данных?
  130. Обновление только одного атрибута в значении 130 • lock ->

    get() -> modify -> put() -> unlock
  131. Обновление только одного атрибута в значении 131 • lock ->

    get() -> modify -> put() -> unlock • invoke() + EntryProcessor
  132. Обновление только одного атрибута в значении 132 • lock ->

    get() -> modify -> put() -> unlock • invoke() + EntryProcessor • put() + CacheInterceptor
  133. Оно точно надо? • Текущую архитектуру BigData платформы • Почему

    начали смотреть на IMDG? ◦ Распределенные системы ◦ Немного об Apache Ignite • Задачи решаемые на Apache Ignite ◦ Как реализована обработка потоковых данных? ◦ Хранение данных в Apache Ignite ◦ Зачем хранить окна потоковых данных в памяти? • Особенности эксплуатации Apache Ignite 133
  134. Какие возможности дает “окно” данных? 134 • Запуск Tasks или

    SQL слепке данных ◦ Нужно избавиться от сетевого взаимодействия при JOIN ◦ JDBC, ODBC ◦ Интеграция с Apache Zeppelin
  135. Какие возможности дает “окно” данных? 135 • Запуск Tasks или

    SQL слепке данных ◦ Нужно избавиться от сетевого взаимодействия при JOIN ◦ JDBC, ODBC ◦ Интеграция с Apache Zeppelin • Расчет оконных метрик
  136. Какие возможности дает “окно” данных? 136 • Запуск Tasks или

    SQL слепке данных ◦ Нужно избавиться от сетевого взаимодействия при JOIN ◦ JDBC, ODBC ◦ Интеграция с Apache Zeppelin • Расчет оконных метрик • Агрегация данных в удобном разрезе
  137. Как организовать “окно” данных? 137 • Вытеснение по объему ◦

    Page-based eviction ◦ Entry-based eviction
  138. Как организовать “окно” данных? 138 • Вытеснение по объему ◦

    Page-based eviction ◦ Entry-based eviction • Вытеснение по времени (TTL)
  139. Ну почти… • Текущую архитектуру BigData платформы • Почему начали

    смотреть на IMDG? ◦ Распределенные системы ◦ Немного об Apache Ignite • Задачи решаемые на Apache Ignite ◦ Как реализована обработка потоковых данных? ◦ Хранение данных в Apache Ignite ◦ Зачем хранить окна потоковых данных в памяти? • Особенности эксплуатации Apache Ignite 139
  140. Защита от split brain 140 Интересно? Давайте обсудим в дискуссионной

    зоне :)
  141. Особенности эксплуатации 141 • BinaryObject и его SerialVersionUID

  142. Особенности эксплуатации 142 • BinaryObject и его SerialVersionUID • -Djava.net.preferIPv4Stack=true

  143. Особенности эксплуатации 143 • BinaryObject и его SerialVersionUID • -Djava.net.preferIPv4Stack=true

    • Корректный shutdown. SIGKILL + Docker
  144. Особенности эксплуатации 144 • BinaryObject и его SerialVersionUID • -Djava.net.preferIPv4Stack=true

    • Корректный shutdown. SIGKILL + Docker • Thread pools ◦ Простая логика в EntryProcessor или Deadlock
  145. Особенности эксплуатации 145 • BinaryObject и его SerialVersionUID • -Djava.net.preferIPv4Stack=true

    • Корректный shutdown. SIGKILL + Docker • Thread pools ◦ Простая логика в EntryProcessor или Deadlock • Ребалансировка
  146. Особенности эксплуатации 146 • BinaryObject и его SerialVersionUID • -Djava.net.preferIPv4Stack=true

    • Корректный shutdown. SIGKILL + Docker • Thread pools ◦ Простая логика в EntryProcessor или Deadlock • Ребалансировка • Деплой новой версии
  147. Статус системы? • Сервисы в production ◦ ≈ 24/7 147

  148. Статус системы? • Сервисы в production ◦ ≈ 24/7 •

    Сервисы не business-critical 148
  149. Основные плюсы для нас 149 • Ignite Native Persistence ◦

    SQL и Map-Reduce без прогрева Cache
  150. Основные плюсы для нас 150 • Ignite Native Persistence ◦

    SQL и Map-Reduce без прогрева Cache • Данные и логика обработка живут в одной JVM ◦ Это и плюс и минус ◦ Именно нужные данные рядом!
  151. Основные плюсы для нас 151 • Ignite Native Persistence ◦

    SQL и Map-Reduce без прогрева Cache • Данные и логика обработка живут в одной JVM ◦ Это и плюс и минус ◦ Именно нужные данные рядом! • Хранение данных в offHeap
  152. Основные плюсы для нас 152 • Ignite Native Persistence ◦

    SQL и Map-Reduce без прогрева Cache • Данные и логика обработка живут в одной JVM ◦ Это и плюс и минус ◦ Именно нужные данные рядом! • Хранение данных в offHeap • Наличие вторичных индексов ◦ Key-value недостаточно, нужны вторичные индексы
  153. Минусы • Медленный персистент в случае WAL + FSYNC mode

    153
  154. Минусы • Медленный персистент в случае WAL + FSYNC mode

    • Критичны “тормоза” в коммуникации узлов кластера ◦ Одна нода может влиять на весь кластер 154
  155. Минусы • Медленный персистент в случае WAL + FSYNC mode

    • Критичны “тормоза” в коммуникации узлов кластера ◦ Одна нода может влиять на весь кластер • Деплоймент новой версии приложения 155
  156. Минусы • Медленный персистент в случае WAL + FSYNC mode

    • Критичны “тормоза” в коммуникации узлов кластера ◦ Одна нода может влиять на весь кластер • Деплоймент новой версии приложения • Прогревание caches в случае “3rd party persistent storage” 156
  157. Минусы • Медленный персистент в случае WAL + FSYNC mode

    • Критичны “тормоза” в коммуникации узлов кластера ◦ Одна нода может влиять на весь кластер • Деплоймент новой версии приложения • Прогревание caches в случае “3rd party persistent storage” • Нет возможности управления правами доступа 157
  158. Не перестарайтесь! • Монолит 158

  159. Не перестарайтесь! • Монолит • Микросервисная архитектура 159

  160. Не перестарайтесь! • Монолит • Микросервисная архитектура • Распределенная система

    160
  161. Не перестарайтесь! • Монолит • Микросервисная архитектура • Распределенная система

    • Распределенный монолит ;) 161
  162. Вопросы? PDimitryuk@gmail.com Павел Димитрюк Программист Beeline