Где сегодня использовать ElasticSearch
•
1 like•167 views
Про некоторые кейсы использования elasticsearch в современных проектах. - С какими сложностями столкнулись - Где успешо применили elasticsearch, а где был избыточен Презентация с мероприятия https://habr.com/ru/company/odnoklassniki/blog/452978/
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Где сегодня использовать ElasticSearch
Similar to Где сегодня использовать ElasticSearch (20)
Где сегодня использовать ElasticSearch
- 1. Где сегодня использовать ElasticSearch Илья Середа, Lead Data Engineer +
- 2. Чем занимаюсь • Создаю инфраструктуру для аналитиков • Инструменты сбора данных о действиях пользователей • Системой АБ-тестов и т.д
- 3. О посетителей в день 1 млн. посетителей в месяц 17 млн. сотрудников >390 Туту.ру — сервис путешествий №1 в России (данные кросс-медийной панели GfK Rus, дек. 2016). Продаем туры, билеты на самолеты, поезда и автобусы, бронируем отели, рассказываем о расписании электричек.
- 4. О чем? • Основные понятия и терминология • Пройдемся по кейсам 1. Полнотекстовый поиск 2. Изменчивая структура данных 3. Хранение логов 4. Аналитическое хранилище 5. Хранилище для DWH
- 6. Ехал Индекс через индекс. Сунул Индекс индекс в индекс… • Индекс - от англ. indices, группа инвертированных индексов • Поле индекса - на англ. index, а этот тот самый инвертированный индекс
- 7. 1. Полнотекстовый поиск Задача — Саджесты/подсказки в формах поиска Требования • Быстрый ответ на индексе в несколько gb • Обслуживать много запросов на чтение • Возможность частичного обновления • Высокие требования к стабильности
- 8. ✅ Получили • Гибкая настройка ранжирования • Работа с синонимами • Отправка запросов напрямую из nginx без задержки на запрос к бекендам • Минимум затрат на поддержку решения в эксплуатации более двух лет Объемы данных • 7000 запросов в минуту • Размер индекса 12 гб • ~ 6 млн. документов • Скорость ответа 10мс Машинки • 3-и ноды • по 8gb RAM • по 4-е ядра • Утилизация ~20% 1. Полнотекстовый поиск
- 9. 2. Изменчивая структура Задача — Кеш поисковой выдачи туров
- 10. 2. Изменчивая структура Задача — Кеш поисковой выдачи туров Требования • Легкость добавления новых полей в документ • Легкость адаптации данных к поискам по разным параметрам • Фасетный поиск + полнотекст
- 11. Жила была MongoDB • Каждый новый запрос на выборку - новый индекс • 40+ индексов • Долгая индексация документов • Около полугода периодического тюнинга 2. Изменчивая структура
- 12. ✅ Получили • Стабильная работа и ускорение • Мало накладных расходов на добавление новых полей • Проще поддержка • Возможность построить аналитику Объем данных • Размер индекса 50gb • Вставка 40 т. записей в минуту Машинки • 3-и ноды на MongoDB было 6-ть • По 8gb RAM • По 8 ядер • 250gb SSD 2. Изменчивая структура
- 13. 3. Хранение логов Задача — Распределенное хранилище логов приложений Требования • Большие объемы неструктурированных данных • Искать по любому полю и строить визуализацию • Легкие запросы • Простой способ исследовать данные
- 14. ✅ Получили • Исследуем данные в kibana • Пишем через logstash • Алертинг и визуализация из grafana • Hot-Warm - экономит деньги 3. Хранение логов
- 15. ❌ Минусы • Без очереди - никуда. Используем redis • Требует поддержки • Требователен к ресурсам • Сложность выявлять узкие места, нужно больше метрик 3. Хранение логов Объем данных • Размер индекса ~20TB • Вставка ~1.2 млн. записей в минуту 63 Мбит/с • 22 млрд. записей в индексах Машинки • 14 нод (bare metal server) • 2-а координатора • 6 ssd - свежие индексы • 6 hdd - старые индексы • По 64 RAM и 16 ядер • Доступный объем в кластере 43TB SSD + HDD
- 16. Дальнейшие планы — Смотрим в сторону clickhouse, но пока болит не сильно 3. Хранение логов
- 17. 4. Аналитическое хранилище Задача — Быстрый* доступ к clickstream за несколько лет Требования • Тяжёлые запросы • Низкие требования по SLA
- 18. 4. Аналитическое хранилище Data Mart =
- 19. 4. Аналитическое хранилище DWH + Data Mart =
- 20. ✅ Получили • Аналитики строят сложные агрегации из python и визуализации в kibana Объем данных • Размер индекса ~10TB • Вставка ~18 т. записей в минуту • 16 млрд. записей в индексе Машинки • 12 нод (bare metal server) • По 64 RAM • По 16 ядер • Всего 42 TB SSD • Утилизация 5%-100% 4. Аналитическое хранилище
- 21. ✅ Получили • Аналитики строят сложные агрегации из python и визуализации в kibana • Связи через parent/child Объем данных • Размер индекса ~10TB • Вставка ~18 т. записей в минуту • 16 млрд. записей в индексе Машинки • 12 нод (bare metal server) • По 64 RAM • По 16 ядер • Всего 42 TB SSD • Утилизация 5%-100% 4. Аналитическое хранилище
- 22. ✅ Получили • Аналитики строят сложные агрегации из python и визуализации в kibana • Связи через parent/child • Гибкое и простое масштабирование • Бесплатно Объем данных • Размер индекса ~10TB • Вставка ~18 т. записей в минуту • 16 млрд. записей в индексе Машинки • 12 нод (bare metal server) • По 64 RAM • По 16 ядер • Всего 42 TB SSD • Утилизация 5%-100% 4. Аналитическое хранилище
- 23. ❌ Минусы • Не можем разбивать/партиционировать индекс по времени • Связи накладывают ограничения 4. Аналитическое хранилище
- 24. ❌ Минусы • Не можем разбивать/партиционировать индекс по времени • Связи накладывают ограничения 4. Аналитическое хранилище
- 25. ❌ Минусы • Не можем разбивать/партиционировать индекс по времени • Связи накладывают ограничения • Ограничения кол-ва записей в шарде (2,147,483,519 документов) • Размер шард < 50gb • Нет SQL ANSI Время на обучение аналитика работы с хранилищем • Ограниченное использование BI инструментов Microsoft Power BI, Tableau и пр. • Неоптимальное использование ресурсов Кластер в среднем утилизирован на 10% • Только append only 4. Аналитическое хранилище
- 26. 4. Аналитическое хранилище К чему пришли • ElasticSearch прожил 3-и года и останется, но в качестве витрины • Будем менять модель данных • Используем хранилища с SQL для BI • Хранить историчные данные в DWH
- 27. 5. Хранилище для DWH Задача — Хранение результатов поисков пользователей Требования • К данным обращаются редко • Неизвестно как будут выбирать и какие агрегации строить • Хранить нужно за всю историю проекта и не разориться
- 28. 5. Хранилище для DWH Получили Ну точнее хотели получить • Сложные агрегации - если бы все ресурсы не забивала индексация • Простое масштабирование Объем данных • В пиках до 600mb в минуту, 460gb в сутки • 1.5 млн. записей в сутки Машинки • 3 ноды • По 64gb RAM • По 16 ядер • Всего 12TB HDD
- 29. 5. Хранилище для DWH ❌ Минусы • Не оптимально работает с диском
- 30. 5. Хранилище для DWH ❌ Минусы • Не оптимально работает с диском • Каждый документ - это дополнительный расход памяти при выборке по полю индекс шарды целиком загружаются в память • Избегать большой иерархии документов
- 31. 5. Хранилище для DWH К чему пришли • Пишем через kafka connect пачками в S3 • Аналитика данных через python или spark из S3 • Вместо 5TB в elastic, уместили все в архивы по 700MB
- 32. • 10 кластеров • Всего 49 нод • Обрабатывают в среднем 2.5 млн. запросов в минуту Общее кол-во инсталляций
- 33. Итог • Мощь ElasticSearch не в оптимальности используемых ресурсов, а в его универсальности и гибкости Кейсы: DWH, полнотекстовый поиск, изменчевая структура данных
- 34. Итог • Мощь ElasticSearch не в оптимальности используемых ресурсов, а в его универсальности и гибкости • Требователен к объему памяти и скорости дисков Кейсы: аналитическое хранилище, логи, DWH
- 35. Итог • Мощь ElasticSearch не в оптимальности используемых ресурсов, а в его универсальности и гибкости • Требователен к объему памяти и скорости дисков • Хорошо справляется с десятками терабайт данных Кейсы: аналитическое хранилище, логи
- 36. Итог • Мощь ElasticSearch не в оптимальности используемых ресурсов, а в его универсальности и гибкости • Требователен к объему памяти и скорости дисков • Хорошо справляется с десятками терабайт данных • Храните денормализованные данные в плоской структуре Кейсы: аналитическое хранилище, логи
- 37. Итог • Мощь ElasticSearch не в оптимальности используемых ресурсов, а в его универсальности и гибкости • Требователен к объему памяти и скорости дисков • Хорошо справляется с десятками терабайт данных • Храните денормализованные данные в плоской структуре • Нарезайте индексы по временным промежуткам Кейсы: аналитическое хранилище, логи
- 38. Итог • Мощь ElasticSearch не в оптимальности используемых ресурсов, а в его универсальности и гибкости • Требователен к объему памяти и скорости дисков • Хорошо справляется с десятками терабайт данных • Храните денормализованные данные в плоской структуре • Нарезайте индексы по временным промежуткам • Append only Кейсы: аналитическое хранилище
- 39. Спасибо# Кейсы 1. Полнотекстовый поиск 2. Изменчивая структура данных 3. Хранение логов 4. Аналитическое хранилище 5. Хранилище для DWH Выводы • ElasticSearch - это гибкость • Платим памятью и скоростью дисков • Хорош для средних объемов данных • Хранение денормализованных данных • Нарезайте индексы по времени • Append only Илья Середа weberdever sereda@tutu.ru