Big data Moscow meetup - presentation from AT Consulting

1. Переход из SQL на NoSQL
(Making the switch from SQL to
NoSQL)
Shamim Ahmed
Big united meetup: BigMoscow and Moscow Cassandra Users

2. 2
AT Consulting
О нас ЧАСТЬ 1
Предоставляем консалтинговую услуги, разработка ПО для
отраслей телекоммуникации, финансы и энергетики.
Данный момент в более 3х проектах применяются NoSQL для
решения разных типов задачи.

3. 3
Agenda
Переход из SQL на NoSQL ЧАСТЬ 1
Наш цель использование Cassandra и Hadoop.
 Какие проблемы мы решаем.
Наша Cassandra/Hadoop архитектура.
 Наш опыт проектирование и эксплуатации ПО на базе
Cassandra/Hadoop.

4. Функция централизованного система логирования
5
ЧАСТЬ 1

5. Функция централизованного система логирования
7
ЧАСТЬ 1
Высоко уровного архитектура

6. Недостатки
9
ЧАСТЬ 1
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
2011 2012 2013
Динамика роста сервисов
Динамика роста сервисов

7. Недостатки
10
ЧАСТЬ 1
Высокий уровень роста потребности сервиса
0
5
10
15
20
25
30
35
Feb-11
Apr-11
Jun-11
Aug-11
Oct-11
Dec-11
Feb-12
Apr-12
Jun-12
Aug-12
Oct-12
Dec-12
Feb-13
Apr-13
Jun-13
Макс. записей в
лог, млн
Мин. записей в
лог, млн

8. Недостатки
11
ЧАСТЬ 1
Низкая производительности разбора сообщения
Разбор сообщения в PL/SQL.
Разбор 450,000 логов за 110 минут.

9. Недостатки
12
ЧАСТЬ 1
Тяжелая репликация данных между ЦоД
Репликация данных через Golden Gate,Oracle Stream иWare
house builder.
Плохой канал связи.

10. Недостатки
13
ЧАСТЬ 1
Плохая масштабируемости RDBMS
Не линейная масштабируемости Oracle RAC

11. Функция централизованного система логирования
14
ЧАСТЬ 1
Дорогостоящие лицензии на ПО
Стоимости лицензии на поддержку продукты Oracle > $456,720 в год.
Продукт Лицензия на
CPU, USD
Техподдерж
ка на CPU,
USD
Количество
ядро в CPU
Core Factor Стоимость, USD Поддержка, USD
Oracle
Database EE
47500 10450 64 0,5 1520000 334400
Oracle
Database
RAC option
23000 5060 24 0,5 276000 60720
GoldenGate 17500 3850 32 0,5 280000 61600
Итого 2076000 456720

12. Причина пользования Cassandra
15
Автоматическая репликация данных по дата центру.
Out of Box Sharding
Линейное масштабирование кластера.
Отсутствие точки отказа кластера.
Big table дата модель.
 Open source.
ЧАСТЬ 2

13. 16
Концептуальная архитектура на базе NoSQL ЧАСТЬ 2

14. 17
NoSQL стек ЧАСТЬ 2

15. 18
Разбор сообщения и агрегация данных ЧАСТЬ 2

16. 19
Количества серверов ЧАСТЬ 2
№ DC Rack Status State Token
1 p00skimdc RACK2 Up Normal 10000
2 p00skimdc RACK2 Up Normal 2,83569E+37
3 p00skimdc RACK2 Up Normal 5,67137E+37
4 p00skimdc RACK2 Up Normal 8,50706E+37
5 p00skimdc RACK2 Up Normal 1,13427E+38
6 p00skimdc RACK2 Up Normal 1,41784E+38
7 p00smevdc RACK1 Up Normal 0
8 p00smevdc RACK1 Up Normal 4,25353E+37
9 p00smevdc RACK1 Up Normal 8,50706E+37
10 p00smevdc RACK1 Up Normal 1,27606E+38
11 pk1smevdc RACK11 Up Normal 100
12 pk1smevdc RACK11 Up Normal 5,67137E+37
13 pk1smevdc RACK11 Up Normal 1,13427E+38
14 pk2smevdc RACK21 Up Normal 200
15 pk2smevdc RACK21 Up Normal 5,67137E+37
16 pk2smevdc RACK21 Up Normal 1,13427E+38
17 pk3smevdc RACK31 Up Normal 300
18 pk3smevdc RACK31 Up Normal 5,67137E+37
19 pk3smevdc RACK31 Up Normal 1,13427E+38
20 pk4smevdc RACK41 Up Normal 400
21 pk4smevdc RACK41 Up Normal 5,67137E+37
22 pk4smevdc RACK41 Up Normal 1,13427E+38
23 pk5smevdc RACK51 Up Normal 500
24 pk5smevdc RACK51 Up Normal 5,67137E+37
25 pk5smevdc RACK51 Up Normal 1,13427E+38
26 pk6smevdc RACK61 Up Normal 600
27 pk6smevdc RACK61 Up Normal 5,67137E+37
28 pk6smevdc RACK61 Up Normal 1,13427E+38
29 pk7smevdc RACK71 Up Normal 700
30 pk7smevdc RACK71 Up Normal 5,67137E+37
31 pk7smevdc RACK71 Up Normal 1,13427E+38

17. 20
Производительность ЧАСТЬ 2
0
50
100
150
200
250
300
350
39 57 70 100
Разбор сообщения (Map)
Количества строк
(млн)
0
50
100
150
200
250
300
350
57 71 129 170
Построение агрегатных
данных(Map Reduce)
Количества строк
(млн)

18. 21
Производительность ЧАСТЬ 2

19. 22
Возникающие проблемы при проектировании ЦСЛ
Архивация данных
Удаление устаревших данных
Ограничения TTL
Большой объем устаревших данных за время Map Reduce
Cassandra Bug – CASSANDRA-5544,CASSANDRA-5234
ЧАСТЬ 3

20. 24
Применение шаблонов для решения задачи
Использование отдельного датацентра для архивации первичных данных.
Использование шаблона Bucket или shared для хранения данных.
ЧАСТЬ 3

21. 25
Проектирование инфраструктуры и Sizing
Характеристика рабочих нагрузок
Disk IOPS
Размер Диска commit log для Кассандра и Hadoop
Место для Compaction и Map reduce temp файлов
Разделение дисков для Hadoop и Cassandra для большой пропускной
способности
Выбор RAID 0/1/10
Выбор JVM
ЧАСТЬ 4

22. Администрирование и эксплуатация систем
26
ЧАСТЬ 5
Синхронизация времени NTP сервера (SchemaMismatch or Schema Disagree)
Добавление нового узла в кластер Cassandra
Увеличение количества map в процессе работы Hadoop

23. Наша рекомендация
27
ЧАСТЬ 5
Использовать Cassandra CQLStorage для выборки данных (версия > 1.2.7)
Настраивать Bloom фильтр, если увас есть аналитические узлы
Пользуйтесь Row Cache, в Cassandra Row Cache – это off heap cache. Это
немного медленнее чем читать строки из Heap, ну гораздо быстрее чем читать
данные из Диска
Использовать Pig как Ad Hoc query, Casscading и Hive для агрегации данных
Если планируете использовать Hadoop для Map Reduce – постарайтесь не
пользоватьсяVnodes, количества Map увеличивается при этом 2-3 раза.
Если у вас размер Heap большее чем 8 ГВ, попробуйте другие JVM, например
Azul или IBM JVM9. Если heap большее 8 ГВ, то GC pause в Oracle JVM 1.6
слишком велика.
Пользуйтесь отдельным диском для commit log, если это RAID тогда RAID 1
Если у вас RAID попробуйте создавать отдельный LUN для каждого узла
Cassandra
Используйте раздельные диски или RAID массивы для Hadoop и Cassandra
storage
Cleaning и house keeping

24. 28
Обратная связь
bsha@at-consulting.ru
Blog: http://frommyworkshop.blogspot.ru
WE ARE HIRING

25. 29
Вопросы