Highload++ 2016 short present of 3: Оригинальные доклады, рекомендуемые к просмотру: * Особенности архитектуры распределённого хранилища в Dropbox. Слава Бахмутов (SRE в группе разработки стораджа в Dropbox) - http://www.highload.ru/2016/abstracts/2257.html * ClickHouse: очень быстро и очень удобно. Виктор Тарнавский (Руководитель разработки аналитических продуктов в Яндексе), Алексей Миловидов (Главный разработчик ClickHouse) - http://www.highload.ru/2016/abstracts/2327.html * Переезжаем на Yandex ClickHouse - Александр Зайцев (LifeStreet) - http://www.highload.ru/2016/abstracts/2297.html

1. Highload++2016highlight
Особенности архитектуры распределённого хранилища в Dropbox
+
ClickHouse: очень быстро и очень удобно <=> Переезжаем на Yandex ClickHouse
© Pavel Alexeev, 2016 1

2. Disclaimer
Информация и часть слайдов заимствованы из оригинальных презентаций:
● Особенности архитектуры распределённого хранилища в Dropbox - Слава
Бахмутов (SRE в группе разработки стораджа в Dropbox)
● ClickHouse: очень быстро и очень удобно - Виктор Тарнавский
(Руководитель разработки аналитических продуктов в Яндексе), Алексей
Миловидов (Главный разработчик ClickHouse)
● Переезжаем на Yandex ClickHouse - Александр Зайцев (LifeStreet)
2

3. 3
Dropbox:
Isolation+Verification+Automatization
=Availability

4. 4
Cross-zone replication

5. 5
Availability

6. 6
Надёжность оборудования - миф

7. 7
Составные доступности

8. 8
Физическая изоляция

9. 9
Логическая изоляция

10. 10
Эксплуатационная изоляция

11. 11
Защита
● Валидация операций
○ Оператор не виноват. Если что-то может быть поломано - оно будет поломано
○ Команды проще
○ Однозначный синтаксис
● Восстановление
○ Многое можно восстановить автоматически
● Тестирование
○ Тестировать стоит ПО, процедуры и даже тестирование
● Всегда что-то может пойти не так
○ Необходимо определять что именно и где

12. 12
Тестирование

13. 13
Верификация

14. 14
Автоматизация
Параноидальная автоматизация

15. 15
Naoru

16. 16
Naoru - пример

17. 17

18. 18
Другие решения

19. 19
YandexClickHouse
Vendorview

20. 20
Яндекс.Метрика

21. 21
Хранение данных
Классический подход
● Агрегированные данные
● Нормализация
● Множество таблиц
● Key -> Metrics
Современный подход
● Сырые данные
● Небольшое количество широких таблиц
● Огромное количество фильтров и группировок
● Event -> Properties

22. 22
Основные идеи создания
➔ SQL диалект
➔ Линейная масштабируемость
➔ Фокус на скорости выполнения
запросов
➔ Приблизительные вычисления
➔ Массивы, кортежи
➔ Распределённые запросы “из коробки”
➔ Внешние словари
➔ URI и другие функции

23. 23
Скорость на грани фантастики
➔ Типичные запросы быстрее секунды
➔ >100 раз быстрей нам Hadoop
➔ >100 раз быстрей чем типичная RDBMS
➔ 100 млн - 1 миллиард строк в секунду на одной ноде
➔ До 2 терабайт в секунду для кластера на 400 нод

24. 24
Померяемся?

25. 25
Когда не надо использовать
➔ OLTP
➔ Key-value
➔ Document-oriented
➔ Модификация данных

26. 26
Best practises
➔ Широкие таблицы, множество колонок
➔ QPS относительно небольшой, но много данных
используется в каждом запросе
➔ Большой поток входящих данных
➔ Аналитика по петабайтам данных

27. 27
YandexClickHouse
Sideview

28. 28
LifeStreet

29. 29

30. 30
Быстрые результаты пилота
Две крайности

31. 31
Быстрые результаты пилота

32. 32
А если надо обновлять таблицу?

33. 33
А если надо удалять?

34. 34
А теперь боль!

35. 35
Залог успешного переезда

36. 36
Спасибо!
Pavel.Alekseev@Taskdata.com