SlideShare a Scribd company logo
1 of 53
Download to read offline
Распределенные cистемы хранения
данных для аналитики:
Vertica и другие системы

Александр Зайцев
О чем мы будем говорить
• Что такое аналитика больших данных
• Функциональные требования
• Технические сложности и проблемы
• Как они решаются или не решаются в разных
распределенных системах
Откуда я об этом знаю?
• LifeStreet:

• Performance advertising с 2006г
• Top FaceBook In-Apps ad network c 2010г
• RTB c 2012г

• Аналитическая инфраструктура – ключевой компонент
• Каждый год нагрузка вырастает в 2-3 раза
• Сейчас (октябрь 2013) – 4 миллиарда событий в день

• Попробовали разные решения и продолжаем
пробовать
Что такое большие данные
• БАК (LHC) генерирует 40TB/sec
• В 2011 году всего было сгенерировано 1.8
зеттабайт
• Закон Мура для данных
• Веб-логи
• Игры (Zynga – 5TB/day два года назад)
Непрерывный поток данных
• надо писать быстро
• нельзя останавливаться
• желательно выживать при частичном отказе
железа (чтобы не останавливаться)
• желательно дублирование (как минимум) в
реальном времени
Многомерный анализ данных
• Данные моделируются как многомерные кубы:
• сотни измерений (дискретных и непрерывных)
• десятки метрик

• Способы работы:
• Сечения (фильтры)
• Проекции (агрегирование)
• Объединения кубов или проекций
Ip | access_time | user_agent |page_url | response_code | response_time
Измерения:
• IP (+ geo lookup)
• Время (иерархия: Год, Дата, Час, Минута и т.д.)
• Пользовательский агент (2 или более иерархий, по браузеру по OS)
• Ресурс (иерархия по структуре URL)
• Код ответа

Метрики:
• Время ответа
• Количество запросов
• Количество успешных запросов (HTTP200)
Кубы, сечения, проекции
Типичный аналитический запрос: агрегация +
range filter + group by на маленькое подмножество измерений

Query result

N-dimensional
cube
сечение

M-dimensional
projection

Range filter
Аналитические запросы
• Сканирование и агрегирование больших
объемов данных
=> очень много IO и CPU на типичный запрос

• В разных направлениях (измерениях)
=> кэш, индексы – все работает плохо
Как получить хорошую
производительость?
Две стратегии:
1. «Уменьшить» данные
2. Увеличить IO/CPU системы

Лучше все сразу
Как можно «уменьшить» данные
• Логическая модель (нормализация и т.д.)
• Физическое хранение данных
• Компрессия
• Кодирование

• Физическая модель – локализация данных:
• Индексы, партиционирование, row/column store,
сегментирование/шардинг
Как можно увеличить IO/CPU
• RAID
• RAID5 vs RAID10

• Использование всех ядер для одного запроса
• Распределенная система
Преимущества распределенных
систем
• «Размазывание» данных по серверам
• Больше объем дисков
• Быстрее доступ к большему объему

• Сложение вычислительных ресурсов
• Масштабируемость
• Надежность за счет дублирования
Сложности распределенных
систем
• Надежность
• Балансировка/перестройка кластера
• Не все алгоритмы хорошо распределяются
(select distinct)
• Cеть
Итак
• Для аналитических задач нам нужна система:
• Распределенная для производительности и
надежности
• Эффективно хранящая данные
• Хорошо локализующая данные
• Быстро загружающая новые данные
• Управляемая
• Разумно стоящая
Отступление: из чего
складывается стоимость
• Стоимость железа (лучше чужого)
• Стоимость лицензии и поддержки, если есть
• Стоимость внутреннего администрирования и
разработки
• Стоимость простоя из-за отказов железа или
софта
Какие есть варианты?
• Не самые удачные:
• Обычные коммерческие базы данных – не интересно
• In-memory DBs (e.g. MemSQL) – очень дорого и не
очень надежно
• NoSQL Dynamo-like – не предназначены для
агрегации и больших range scans
Какие есть варианты?
• Стоящие рассмотрения:
• MySQL + специализированный engine + шардинг
• Аналитические MPP базы данных
• Hadoop Stinger
Что можно «выжать» из MySQL
• MySQL NDB Cluster – работает только на небольших
данных в памяти и плохо агрегирует
• TokuDB – storage engine для аналитики
• Шардинг (dbShards, Shard-Query, ScaleDB, ScaleBase)
– распределенность, но
• Тяжело управлять
• Часто неэффективные запросы и джойны
• Кроме Shard-Query – не бесплатны
Пару слов про TokuDB
• Компрессия (примерно в 5 раз)
• Хорошо «держит» большие объемы за счет структуры
индекса (сотни GB)

• Производительность перестройки индекса не падает с ростом
размера таблиц

• Сокращает время доступа к данным за счет
«кластеризующих» индексов
• Выполнение аналитических запросов в 5-10 раз быстрее, чем
InnoDB
• 5 раз компрессия и до двух раз из-за «кластеризующего» индекса
Рабочий вариант
• TokuDB + Shard-Query
• 100-200GB/server
• Ограничения:
•
•
•
•

shard column одна для всех таблиц
Нет центрального управления, все вручную
TokuDB плохо работает при больших range scan
И еще одно...
Help!
Help, I need somebody
Help, not just anybody
Help, you know I need someone, help

Help
Help
Help,
Help

When I was younger so much younger than today
I never needed anybody's help in any way
But now these days are gone, I'm not so self assured
Now I find I've changed my mind and opened up the doors

help

Help me if you can, I'm feeling down
And I do appreciate you being round
Help me get my feet back on the ground
Won't you please, please help me

Help
Help
help
Строки vs. колонки
Row store

Column store
• Колонки

Таблица хранится по строкам

Каждая колонка хранится отдельно

При любом обращении строка читается
целиком

При обращении к полю, читается только
одна колонка или ее фрагмент

Данные по строкам плохо сжимаются

Колонки отлично сжимаются

Дешевый update/delete

Дорогой update/delete

Легко реализуется

Достаточно сложно реализуется
Пример
Таблица T 100 bigint колонок и 1 000 000 000 записей
select sum(x) from T;

Row store: 1 000 000 000 * 100 * 8 = 800 GB
Column store: 1 000 000 000 * 1 * 8 = 8 GB
Если учесть компрессию, то на порядок меньше
Колоночные RDBMS
• Open Source:
• C-Store (pre-Vertica)
• MonetDB (pre-VectorWise)
• LucidDB

• Коммерческие
•
•
•
•
•
•
•

Sybase IQ
InfoBright *
InfiniDB *
ParAccel (and Amazon Redshift)
GreenPlum (“эмуляция” на PostgreSQL)
Vertica *
VectorWise

* Есть бесплатные версии ограниченной функциональности
• 1140M строк в таблице
• 20 колонок (int, float)
• 5 серверов (native/ Shard-Query)

250
215
200

select
country_code,
count(*),
sum(revenue)
From test_table a,
dim_country c
where country_code in ('US’,'GB')
and a.country_key=c.country_key
group by country_code;

150

100
79
61
50

3,22

2,42

0

MonetDB

TokuDB InfoBright ParAccel
EE

Vertica
Vertica – это:
•
•
•
•

Колонки!
Нет индексов!!
Нет таблиц!!!
Эффективная компрессия данных

• У нас в среднем в 13 раз, но может достигать и до 10....00
раз на колонку

• Полный контроль над физической организацией
• Очень быстрая загрузка
• Shared nothing MPP
Vertica: проекции
• Таблиц физически нет, это логическая
абстракция
• Проекции (projection)
• Подмножество колонок с сортировкой
• Для каждой таблицы есть супер-проекция = все
колонки
• Для одной таблицы может быть любое число
проекций разной структуры
Vertica: проекции
• Тип кодирования колонок:
•
•
•
•

RLE
DELTAVAL
BLOCK_DICT
И еще 12 разных способов

• Сортировка! (особенно важна для RLE)
• Группы колонок (фрагменты строк)
• Сегментация по узлам кластера
Vertica: физическое хранение
• Большие блоки (мин 1Mb), после записи не
меняются
• Автоматическое объединение (со сборкой мусора и
перекодированием)
• Оптимизировано на последовательное чтениезапись с диска
• Оптимизировано под кэш уровня OS или
контроллера
Vertica: выполнение запросов
• Только «нужные» колонки
• Предикаты могут выполняться на закодированных
колонках
• Сильно зависит от структуры проекций (не таблиц)
• Ключевые инструменты – RLE с сортировкой и
сегментация
• Предикаты по отсортированной колонке ~ индексы
• Джойны – merge, hash
• Группировка, pipelined group by
Любой запрос, это ...
Full Scan
Как работает сортировка и RLE
Gender

Age

M

1-20
21-25
26-35
36+

F

Impressions

1-20
21-25
26-35
36+

1 I/O

1 I/O

1 I/O

select sum(impressions) from t
where gender=‘M’ and age=‘21-25’
Как работает сортировка и RLE
Gender

Age

M

1-20
21-25
26-35
36+

F

Impressions

1-20
21-25
26-35
36+
2 I/O

2 I/O

select sum(impressions) from t
where age=‘21-25’
Сортировка и pipelined group-by
SELECT X, COUNT(*) FROM T GROUP BY X
X (sorted)
A
A
B
B
C
C
D
D
…

A: 2
B: 2

• Выполняется в один проход
• Почти не расходует память (stream)
• Для кластера, если сегментировать по X, то
тоже в один проход

C: 2
D: 2

Сегментация
по узлам
Сортировка и merge join
X (sorted)
A
A
B
B
C
C
D
D

Y (sorted)
A
B
C
D

• Работает, если сортировка одинаковая с
обеих сторон
• Для кластера:
• одинаковая сегментация, или
• одна из таблиц несегментирована
(обычно)

Сегментация
по узлам
Vertica: загрузка данных
• Две зоны хранения:
• WOS (in-memory)
• ROS (on-disk)
• Перенос из WOS в ROS автоматический (можно force)

• Загрузка большими порциями очень быстрая:
• В ROS: порядка 2-5M «колонок» в секунду на сервер
• В WOS: еще быстрее, но может быть переполнение
Vertica: кластер
• 3..N одинаковых узлов – архитектура shared nothing
• Конфигурируется на уровне проекции
• Несегментированные – каждая нода содержит полные
данные
• Сегментированные – каждая нода 1/N данных
• K-safety level – уровень дублирования

1

2

3

4

5

A
A
E

A
B
A

A
C
B

A
D
C

A
E
D

Несегментированная
Сегментированная,
K=1 со сдвигом 1
Vertica: aдминистрирование
• Переконфигурирования кластера – все на лету
•
•
•
•
•

Выключение/включение узла
Замена узла
Добавление узла
Изменение проекций
И т. д.

• Как этого добиваются?
• Рестарт – только при апгрейде версии софта
Vertica: cколько «тянет» один
сервер/узел
• 5 TB raw data или ~500 GB на диске

• Если физический дизайн правильно настроен под конкретные
задачи

• Примерный сервер:

• 2xE5620 или E5630
• 24-64GB RAM – зависит от задач и режима использования
• 250-300GB SATA/SAS диски в RAID5 или RAID10

• Для кластера – 1Gb сеть между узлами (желательно, private)
• Кластер на 3х узлах ~= отдельному серверу по скорости
• Почему? K-safety=1 + сеть
Vertica: cколько стоит?
• It depends
• Лицензируется объем сырых данных в «боевой»
системе
• Единовременно + support fee
• Верхняя граница -- $100K за 1TB (list price)
• Нижняя граница $2M за 1PB или $2K за 1TB
Vertica Community Edition
• 1 TB данных, 3 сервера в кластере
• Достаточно для любых тестов, POC и т.д.
• На объемах до 1TB обгонит всех БЕСПЛАТНО
Сравнимые
альтернативы?
ParAccel
• Тоже быстрая колоночная MPP RDBMS
• Может быть быстрее Vertica на ad-hoc запросах
• Используется как бэкенд Amazon Redshift
ParAccel – основные отличия
• Ограниченные возможности настройки физической
структуры, только одна сортировка на таблицу
• Неэффективный Vacuum («сборка мусора»)
• Нет партиционирования
• Только последовательная загрузка
• Два типа узлов: Leader Node (1) и Сompute Nodes (N)
• Все кластерные операции требуют остановки БД
• Более высокие требования к железу и сети
• Лицензия per server/node
Hadoop
• Исторически – batch processing
• Долгий старт задачи на больших кластерах
• HDFS медленная
• Материализация на диск промежуточных этапов
• Hive неэффективен
• Слишком generic
Hadoop vs Vertica
• SIGMOD 2009 paper: A Comparison of Approaches to
Large-Scale Data Analysis
http://database.cs.brown.edu/papers/benchmarkssigmod09.pdf

• В «идеальных условиях» в среднем в 10 раз медленнее,
чем Vertica
• Агрегация медленнее в 15 раз
• Джойны – в 20-30

• Hive примерно в 100 раз медленнее (наши тесты
2012)
HadApt
• Hadoop инфраструктура поверх PosgtreSQL
• Очевидные преимущества PostgreSQL над HDFS
• Те же недостатки Hadoop, плюс недостатки row
store
Hadoop Stinger
• http://hortonworks.com/labs/stinger/
• Часть Hadoop 2.0
• Декларируемая Цель: ускорить Hive в 100 раз
Hadoop Stinger: как?
• ORC – новый колоночный формат HDFS:
• RLE, dictionary encoding etc.

• SQL типы данных и прочая SQL-семантика на уровне
платформы
• HСatalog – новое эффективное хранилище метаданных
• Tez – новый MR-«движок», заточенный под Hive
• Нет промежуточной материализации, наконец-то!
• 100ms время старта

• Новый cost-based query optimizer
Hadoop Stinger: когда?
• Частично уже (Oct 2013 -- HDP 2.0, Hive 0.12),
утверждается увеличение производительности
SQL/Hive в 35-40 раз
• Полностью – coming soon
• Будем пробовать 
Резюме
Спасибо

Alexander.Zaitsev @ LifeStreet.com

More Related Content

What's hot

NoSQL внутри SQL: приземленные вопросы практического применения / Дмитрий До...
NoSQL внутри SQL: приземленные вопросы практического применения /  Дмитрий До...NoSQL внутри SQL: приземленные вопросы практического применения /  Дмитрий До...
NoSQL внутри SQL: приземленные вопросы практического применения / Дмитрий До...Ontico
 
Cоциальный граф "Одноклассников" в myTarget
Cоциальный граф "Одноклассников" в myTargetCоциальный граф "Одноклассников" в myTarget
Cоциальный граф "Одноклассников" в myTargetOleg Tsarev
 
Выбор NoSQL базы данных для вашего проекта: "Не в свои сани не садись"
Выбор NoSQL базы данных для вашего проекта: "Не в свои сани не садись"Выбор NoSQL базы данных для вашего проекта: "Не в свои сани не садись"
Выбор NoSQL базы данных для вашего проекта: "Не в свои сани не садись"Alexey Zinoviev
 
Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему ...
Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему ...Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему ...
Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему ...Oleg Tsarev
 
ClickHouse как решение для бизнес аналитики. Дмитрий Кузьмин
ClickHouse как решение для бизнес аналитики. Дмитрий КузьминClickHouse как решение для бизнес аналитики. Дмитрий Кузьмин
ClickHouse как решение для бизнес аналитики. Дмитрий КузьминHOWWEDOIT
 
Брокер сообщений Kafka в условиях повышенной нагрузки / Артём Выборнов (Rambl...
Брокер сообщений Kafka в условиях повышенной нагрузки / Артём Выборнов (Rambl...Брокер сообщений Kafka в условиях повышенной нагрузки / Артём Выборнов (Rambl...
Брокер сообщений Kafka в условиях повышенной нагрузки / Артём Выборнов (Rambl...Ontico
 
Где сегодня использовать ElasticSearch
Где сегодня использовать ElasticSearchГде сегодня использовать ElasticSearch
Где сегодня использовать ElasticSearchИлья Середа
 
Cистема внутренней статистики Odnoklassniki.ru
Cистема внутренней статистики Odnoklassniki.ruCистема внутренней статистики Odnoklassniki.ru
Cистема внутренней статистики Odnoklassniki.ruodnoklassniki.ru
 
Построение системы аналитики
Построение системы аналитикиПостроение системы аналитики
Построение системы аналитикиИлья Середа
 
NoSQL - взрыв возможностей
NoSQL - взрыв возможностейNoSQL - взрыв возможностей
NoSQL - взрыв возможностейAleksey Solntsev
 
Машинное обучение в электронной коммерции — практика использования и подводны...
Машинное обучение в электронной коммерции — практика использования и подводны...Машинное обучение в электронной коммерции — практика использования и подводны...
Машинное обучение в электронной коммерции — практика использования и подводны...Ontico
 
"Новые возможности MySQL 5.7"
"Новые возможности MySQL 5.7""Новые возможности MySQL 5.7"
"Новые возможности MySQL 5.7"Badoo Development
 
"PostgreSQL для разработчиков приложений", Павел Лузанов, (Постгрес Профессио...
"PostgreSQL для разработчиков приложений", Павел Лузанов, (Постгрес Профессио..."PostgreSQL для разработчиков приложений", Павел Лузанов, (Постгрес Профессио...
"PostgreSQL для разработчиков приложений", Павел Лузанов, (Постгрес Профессио...Badoo Development
 
Олег Бартунов (ГАИШ МГУ), Александр Коротков (Интаро-Софт)
Олег Бартунов (ГАИШ МГУ), Александр Коротков (Интаро-Софт)Олег Бартунов (ГАИШ МГУ), Александр Коротков (Интаро-Софт)
Олег Бартунов (ГАИШ МГУ), Александр Коротков (Интаро-Софт)Ontico
 
MongoDB. Области применения, преимущества и узкие места, тонкости использован...
MongoDB. Области применения, преимущества и узкие места, тонкости использован...MongoDB. Области применения, преимущества и узкие места, тонкости использован...
MongoDB. Области применения, преимущества и узкие места, тонкости использован...phpdevby
 
Migrating from PHP/MySQL to Redis/Lua, my talk on High load++ (Russian)
Migrating from PHP/MySQL to Redis/Lua, my talk on High load++ (Russian)Migrating from PHP/MySQL to Redis/Lua, my talk on High load++ (Russian)
Migrating from PHP/MySQL to Redis/Lua, my talk on High load++ (Russian)Dmitry Degtyarev
 
Промышленное ускорение сайтов / Николай Мациевский (Айри.рф)
Промышленное ускорение сайтов / Николай Мациевский (Айри.рф)Промышленное ускорение сайтов / Николай Мациевский (Айри.рф)
Промышленное ускорение сайтов / Николай Мациевский (Айри.рф)Ontico
 
High load++2016.highlights (dropbox+clickhouse)
High load++2016.highlights (dropbox+clickhouse)High load++2016.highlights (dropbox+clickhouse)
High load++2016.highlights (dropbox+clickhouse)Pavel Alexeev
 
Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...
Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...
Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...Ontico
 

What's hot (20)

NoSQL внутри SQL: приземленные вопросы практического применения / Дмитрий До...
NoSQL внутри SQL: приземленные вопросы практического применения /  Дмитрий До...NoSQL внутри SQL: приземленные вопросы практического применения /  Дмитрий До...
NoSQL внутри SQL: приземленные вопросы практического применения / Дмитрий До...
 
Cоциальный граф "Одноклассников" в myTarget
Cоциальный граф "Одноклассников" в myTargetCоциальный граф "Одноклассников" в myTarget
Cоциальный граф "Одноклассников" в myTarget
 
Выбор NoSQL базы данных для вашего проекта: "Не в свои сани не садись"
Выбор NoSQL базы данных для вашего проекта: "Не в свои сани не садись"Выбор NoSQL базы данных для вашего проекта: "Не в свои сани не садись"
Выбор NoSQL базы данных для вашего проекта: "Не в свои сани не садись"
 
Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему ...
Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему ...Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему ...
Асинхронная репликация без цензуры: архитектурные проблемы MySQL, или почему ...
 
ClickHouse как решение для бизнес аналитики. Дмитрий Кузьмин
ClickHouse как решение для бизнес аналитики. Дмитрий КузьминClickHouse как решение для бизнес аналитики. Дмитрий Кузьмин
ClickHouse как решение для бизнес аналитики. Дмитрий Кузьмин
 
Брокер сообщений Kafka в условиях повышенной нагрузки / Артём Выборнов (Rambl...
Брокер сообщений Kafka в условиях повышенной нагрузки / Артём Выборнов (Rambl...Брокер сообщений Kafka в условиях повышенной нагрузки / Артём Выборнов (Rambl...
Брокер сообщений Kafka в условиях повышенной нагрузки / Артём Выборнов (Rambl...
 
Где сегодня использовать ElasticSearch
Где сегодня использовать ElasticSearchГде сегодня использовать ElasticSearch
Где сегодня использовать ElasticSearch
 
Cистема внутренней статистики Odnoklassniki.ru
Cистема внутренней статистики Odnoklassniki.ruCистема внутренней статистики Odnoklassniki.ru
Cистема внутренней статистики Odnoklassniki.ru
 
Построение системы аналитики
Построение системы аналитикиПостроение системы аналитики
Построение системы аналитики
 
NoSQL - взрыв возможностей
NoSQL - взрыв возможностейNoSQL - взрыв возможностей
NoSQL - взрыв возможностей
 
Машинное обучение в электронной коммерции — практика использования и подводны...
Машинное обучение в электронной коммерции — практика использования и подводны...Машинное обучение в электронной коммерции — практика использования и подводны...
Машинное обучение в электронной коммерции — практика использования и подводны...
 
"Новые возможности MySQL 5.7"
"Новые возможности MySQL 5.7""Новые возможности MySQL 5.7"
"Новые возможности MySQL 5.7"
 
No sql.mongodb scaling
No sql.mongodb scalingNo sql.mongodb scaling
No sql.mongodb scaling
 
"PostgreSQL для разработчиков приложений", Павел Лузанов, (Постгрес Профессио...
"PostgreSQL для разработчиков приложений", Павел Лузанов, (Постгрес Профессио..."PostgreSQL для разработчиков приложений", Павел Лузанов, (Постгрес Профессио...
"PostgreSQL для разработчиков приложений", Павел Лузанов, (Постгрес Профессио...
 
Олег Бартунов (ГАИШ МГУ), Александр Коротков (Интаро-Софт)
Олег Бартунов (ГАИШ МГУ), Александр Коротков (Интаро-Софт)Олег Бартунов (ГАИШ МГУ), Александр Коротков (Интаро-Софт)
Олег Бартунов (ГАИШ МГУ), Александр Коротков (Интаро-Софт)
 
MongoDB. Области применения, преимущества и узкие места, тонкости использован...
MongoDB. Области применения, преимущества и узкие места, тонкости использован...MongoDB. Области применения, преимущества и узкие места, тонкости использован...
MongoDB. Области применения, преимущества и узкие места, тонкости использован...
 
Migrating from PHP/MySQL to Redis/Lua, my talk on High load++ (Russian)
Migrating from PHP/MySQL to Redis/Lua, my talk on High load++ (Russian)Migrating from PHP/MySQL to Redis/Lua, my talk on High load++ (Russian)
Migrating from PHP/MySQL to Redis/Lua, my talk on High load++ (Russian)
 
Промышленное ускорение сайтов / Николай Мациевский (Айри.рф)
Промышленное ускорение сайтов / Николай Мациевский (Айри.рф)Промышленное ускорение сайтов / Николай Мациевский (Айри.рф)
Промышленное ускорение сайтов / Николай Мациевский (Айри.рф)
 
High load++2016.highlights (dropbox+clickhouse)
High load++2016.highlights (dropbox+clickhouse)High load++2016.highlights (dropbox+clickhouse)
High load++2016.highlights (dropbox+clickhouse)
 
Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...
Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...
Простая и дешёвая бизнес-аналитика на базе Google BigQuery / Алексей Паршуков...
 

Similar to Aлександр Зайцев, LifeStreet

HighLoad systems: tips & tricks
HighLoad systems: tips & tricksHighLoad systems: tips & tricks
HighLoad systems: tips & tricksSveta Bozhko
 
Обзор перспективных баз данных для highload / Юрий Насретдинов
Обзор перспективных баз данных для highload / Юрий НасретдиновОбзор перспективных баз данных для highload / Юрий Насретдинов
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
 
Всеволод Поляков "История одного мониторинга"
Всеволод Поляков "История одного мониторинга"Всеволод Поляков "История одного мониторинга"
Всеволод Поляков "История одного мониторинга"Fwdays
 
Ускорение веб-аналитики с использованием Column-oriented СУБД (Иван Авсеянко)
Ускорение веб-аналитики с использованием Column-oriented СУБД (Иван Авсеянко)Ускорение веб-аналитики с использованием Column-oriented СУБД (Иван Авсеянко)
Ускорение веб-аналитики с использованием Column-oriented СУБД (Иван Авсеянко)Ontico
 
Open source субд глазами обычного программиста
Open source субд глазами обычного программистаOpen source субд глазами обычного программиста
Open source субд глазами обычного программистаSlach
 
High load2007 scaling-web-applications-rus
High load2007 scaling-web-applications-rusHigh load2007 scaling-web-applications-rus
High load2007 scaling-web-applications-rusVladd Ev
 
Спасение 6 миллионов файлов в условиях полного Хецнера
Спасение 6 миллионов файлов в условиях полного ХецнераСпасение 6 миллионов файлов в условиях полного Хецнера
Спасение 6 миллионов файлов в условиях полного ХецнераDaniel Podolsky
 
Реляционные базы данных
Реляционные базы данныхРеляционные базы данных
Реляционные базы данныхLevon Avakyan
 
2014.12.23 Александр Андреев, Parallels
2014.12.23 Александр Андреев, Parallels2014.12.23 Александр Андреев, Parallels
2014.12.23 Александр Андреев, ParallelsNikolay Samokhvalov
 
Пётр Зайцев, Percona
Пётр Зайцев, PerconaПётр Зайцев, Percona
Пётр Зайцев, PerconaOntico
 
Oracle exa2 biz_summit
Oracle exa2 biz_summitOracle exa2 biz_summit
Oracle exa2 biz_summitNick Turunov
 
Oracle database In-Memory - новая технология обработки в памяти
Oracle database In-Memory - новая технология обработки в памятиOracle database In-Memory - новая технология обработки в памяти
Oracle database In-Memory - новая технология обработки в памятиAndrey Akulov
 
Александр Шарак, "Одноклассники"
Александр Шарак, "Одноклассники"Александр Шарак, "Одноклассники"
Александр Шарак, "Одноклассники"Ontico
 
Cравнительный анализ хранилищ данных (Олег Царев, Кирилл Коринский)
Cравнительный анализ хранилищ данных (Олег Царев, Кирилл Коринский)Cравнительный анализ хранилищ данных (Олег Царев, Кирилл Коринский)
Cравнительный анализ хранилищ данных (Олег Царев, Кирилл Коринский)Ontico
 
Практический опыт использования некоторых современных решений репликации MySQL
Практический опыт использования некоторых современных решений репликации MySQLПрактический опыт использования некоторых современных решений репликации MySQL
Практический опыт использования некоторых современных решений репликации MySQLAlex Chistyakov
 
Знакомство с In-Memory Data Grid
Знакомство с In-Memory Data GridЗнакомство с In-Memory Data Grid
Знакомство с In-Memory Data GridMikhail Shcherbakov
 
Информационные технологии в эру Больших данных
Информационные технологии в эру Больших данныхИнформационные технологии в эру Больших данных
Информационные технологии в эру Больших данныхСергей Макрушин
 
Информационные технологии в эру Больших данных
Информационные технологии в эру Больших данныхИнформационные технологии в эру Больших данных
Информационные технологии в эру Больших данныхSergey Makrushin
 
Что такое Postgresql (Максим Богук)
Что такое Postgresql (Максим Богук)Что такое Postgresql (Максим Богук)
Что такое Postgresql (Максим Богук)Ontico
 

Similar to Aлександр Зайцев, LifeStreet (20)

HighLoad systems: tips & tricks
HighLoad systems: tips & tricksHighLoad systems: tips & tricks
HighLoad systems: tips & tricks
 
Обзор перспективных баз данных для highload / Юрий Насретдинов
Обзор перспективных баз данных для highload / Юрий НасретдиновОбзор перспективных баз данных для highload / Юрий Насретдинов
Обзор перспективных баз данных для highload / Юрий Насретдинов
 
Всеволод Поляков "История одного мониторинга"
Всеволод Поляков "История одного мониторинга"Всеволод Поляков "История одного мониторинга"
Всеволод Поляков "История одного мониторинга"
 
Ускорение веб-аналитики с использованием Column-oriented СУБД (Иван Авсеянко)
Ускорение веб-аналитики с использованием Column-oriented СУБД (Иван Авсеянко)Ускорение веб-аналитики с использованием Column-oriented СУБД (Иван Авсеянко)
Ускорение веб-аналитики с использованием Column-oriented СУБД (Иван Авсеянко)
 
Open source субд глазами обычного программиста
Open source субд глазами обычного программистаOpen source субд глазами обычного программиста
Open source субд глазами обычного программиста
 
High load2007 scaling-web-applications-rus
High load2007 scaling-web-applications-rusHigh load2007 scaling-web-applications-rus
High load2007 scaling-web-applications-rus
 
Спасение 6 миллионов файлов в условиях полного Хецнера
Спасение 6 миллионов файлов в условиях полного ХецнераСпасение 6 миллионов файлов в условиях полного Хецнера
Спасение 6 миллионов файлов в условиях полного Хецнера
 
Реляционные базы данных
Реляционные базы данныхРеляционные базы данных
Реляционные базы данных
 
2014.12.23 Александр Андреев, Parallels
2014.12.23 Александр Андреев, Parallels2014.12.23 Александр Андреев, Parallels
2014.12.23 Александр Андреев, Parallels
 
Пётр Зайцев, Percona
Пётр Зайцев, PerconaПётр Зайцев, Percona
Пётр Зайцев, Percona
 
Oracle exa2 biz_summit
Oracle exa2 biz_summitOracle exa2 biz_summit
Oracle exa2 biz_summit
 
Oracle database In-Memory - новая технология обработки в памяти
Oracle database In-Memory - новая технология обработки в памятиOracle database In-Memory - новая технология обработки в памяти
Oracle database In-Memory - новая технология обработки в памяти
 
Александр Шарак, "Одноклассники"
Александр Шарак, "Одноклассники"Александр Шарак, "Одноклассники"
Александр Шарак, "Одноклассники"
 
Cравнительный анализ хранилищ данных (Олег Царев, Кирилл Коринский)
Cравнительный анализ хранилищ данных (Олег Царев, Кирилл Коринский)Cравнительный анализ хранилищ данных (Олег Царев, Кирилл Коринский)
Cравнительный анализ хранилищ данных (Олег Царев, Кирилл Коринский)
 
Практический опыт использования некоторых современных решений репликации MySQL
Практический опыт использования некоторых современных решений репликации MySQLПрактический опыт использования некоторых современных решений репликации MySQL
Практический опыт использования некоторых современных решений репликации MySQL
 
Знакомство с In-Memory Data Grid
Знакомство с In-Memory Data GridЗнакомство с In-Memory Data Grid
Знакомство с In-Memory Data Grid
 
Информационные технологии в эру Больших данных
Информационные технологии в эру Больших данныхИнформационные технологии в эру Больших данных
Информационные технологии в эру Больших данных
 
Информационные технологии в эру Больших данных
Информационные технологии в эру Больших данныхИнформационные технологии в эру Больших данных
Информационные технологии в эру Больших данных
 
Pgconfru 2015 kosmodemiansky
Pgconfru 2015 kosmodemianskyPgconfru 2015 kosmodemiansky
Pgconfru 2015 kosmodemiansky
 
Что такое Postgresql (Максим Богук)
Что такое Postgresql (Максим Богук)Что такое Postgresql (Максим Богук)
Что такое Postgresql (Максим Богук)
 

More from Ontico

One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
 
Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Ontico
 
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Ontico
 
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Ontico
 
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Ontico
 
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)Ontico
 
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Ontico
 
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Ontico
 
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)Ontico
 
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)MySQL Replication — Advanced Features / Петр Зайцев (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)Ontico
 
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Ontico
 
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Ontico
 
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Ontico
 
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Ontico
 
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)Ontico
 
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Ontico
 
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
 
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...100500 способов кэширования в Oracle Database или как достичь максимальной ск...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...Ontico
 
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Ontico
 
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...Ontico
 

More from Ontico (20)

One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...
 
Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Масштабируя DNS / Артем Гавриченков (Qrator Labs)Масштабируя DNS / Артем Гавриченков (Qrator Labs)
Масштабируя DNS / Артем Гавриченков (Qrator Labs)
 
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
 
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
Готовим тестовое окружение, или сколько тестовых инстансов вам нужно / Алекса...
 
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
Новые технологии репликации данных в PostgreSQL / Александр Алексеев (Postgre...
 
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
PostgreSQL Configuration for Humans / Alvaro Hernandez (OnGres)
 
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
Inexpensive Datamasking for MySQL with ProxySQL — Data Anonymization for Deve...
 
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...
 
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
ProxySQL Use Case Scenarios / Alkin Tezuysal (Percona)
 
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)MySQL Replication — Advanced Features / Петр Зайцев (Percona)
MySQL Replication — Advanced Features / Петр Зайцев (Percona)
 
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
Внутренний open-source. Как разрабатывать мобильное приложение большим количе...
 
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
Подробно о том, как Causal Consistency реализовано в MongoDB / Михаил Тюленев...
 
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
Балансировка на скорости проводов. Без ASIC, без ограничений. Решения NFWare ...
 
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
Перехват трафика — мифы и реальность / Евгений Усков (Qrator Labs)
 
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
И тогда наверняка вдруг запляшут облака! / Алексей Сушков (ПЕТЕР-СЕРВИС)
 
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
Как мы заставили Druid работать в Одноклассниках / Юрий Невиницин (OK.RU)
 
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)
 
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...100500 способов кэширования в Oracle Database или как достичь максимальной ск...
100500 способов кэширования в Oracle Database или как достичь максимальной ск...
 
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
Apache Ignite Persistence: зачем Persistence для In-Memory, и как он работает...
 
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
Механизмы мониторинга баз данных: взгляд изнутри / Дмитрий Еманов (Firebird P...
 

Aлександр Зайцев, LifeStreet

  • 1. Распределенные cистемы хранения данных для аналитики: Vertica и другие системы Александр Зайцев
  • 2. О чем мы будем говорить • Что такое аналитика больших данных • Функциональные требования • Технические сложности и проблемы • Как они решаются или не решаются в разных распределенных системах
  • 3. Откуда я об этом знаю? • LifeStreet: • Performance advertising с 2006г • Top FaceBook In-Apps ad network c 2010г • RTB c 2012г • Аналитическая инфраструктура – ключевой компонент • Каждый год нагрузка вырастает в 2-3 раза • Сейчас (октябрь 2013) – 4 миллиарда событий в день • Попробовали разные решения и продолжаем пробовать
  • 4. Что такое большие данные • БАК (LHC) генерирует 40TB/sec • В 2011 году всего было сгенерировано 1.8 зеттабайт • Закон Мура для данных • Веб-логи • Игры (Zynga – 5TB/day два года назад)
  • 5. Непрерывный поток данных • надо писать быстро • нельзя останавливаться • желательно выживать при частичном отказе железа (чтобы не останавливаться) • желательно дублирование (как минимум) в реальном времени
  • 6. Многомерный анализ данных • Данные моделируются как многомерные кубы: • сотни измерений (дискретных и непрерывных) • десятки метрик • Способы работы: • Сечения (фильтры) • Проекции (агрегирование) • Объединения кубов или проекций
  • 7. Ip | access_time | user_agent |page_url | response_code | response_time Измерения: • IP (+ geo lookup) • Время (иерархия: Год, Дата, Час, Минута и т.д.) • Пользовательский агент (2 или более иерархий, по браузеру по OS) • Ресурс (иерархия по структуре URL) • Код ответа Метрики: • Время ответа • Количество запросов • Количество успешных запросов (HTTP200)
  • 8. Кубы, сечения, проекции Типичный аналитический запрос: агрегация + range filter + group by на маленькое подмножество измерений Query result N-dimensional cube сечение M-dimensional projection Range filter
  • 9. Аналитические запросы • Сканирование и агрегирование больших объемов данных => очень много IO и CPU на типичный запрос • В разных направлениях (измерениях) => кэш, индексы – все работает плохо
  • 10. Как получить хорошую производительость? Две стратегии: 1. «Уменьшить» данные 2. Увеличить IO/CPU системы Лучше все сразу
  • 11. Как можно «уменьшить» данные • Логическая модель (нормализация и т.д.) • Физическое хранение данных • Компрессия • Кодирование • Физическая модель – локализация данных: • Индексы, партиционирование, row/column store, сегментирование/шардинг
  • 12. Как можно увеличить IO/CPU • RAID • RAID5 vs RAID10 • Использование всех ядер для одного запроса • Распределенная система
  • 13. Преимущества распределенных систем • «Размазывание» данных по серверам • Больше объем дисков • Быстрее доступ к большему объему • Сложение вычислительных ресурсов • Масштабируемость • Надежность за счет дублирования
  • 14. Сложности распределенных систем • Надежность • Балансировка/перестройка кластера • Не все алгоритмы хорошо распределяются (select distinct) • Cеть
  • 15. Итак • Для аналитических задач нам нужна система: • Распределенная для производительности и надежности • Эффективно хранящая данные • Хорошо локализующая данные • Быстро загружающая новые данные • Управляемая • Разумно стоящая
  • 16. Отступление: из чего складывается стоимость • Стоимость железа (лучше чужого) • Стоимость лицензии и поддержки, если есть • Стоимость внутреннего администрирования и разработки • Стоимость простоя из-за отказов железа или софта
  • 17. Какие есть варианты? • Не самые удачные: • Обычные коммерческие базы данных – не интересно • In-memory DBs (e.g. MemSQL) – очень дорого и не очень надежно • NoSQL Dynamo-like – не предназначены для агрегации и больших range scans
  • 18. Какие есть варианты? • Стоящие рассмотрения: • MySQL + специализированный engine + шардинг • Аналитические MPP базы данных • Hadoop Stinger
  • 19. Что можно «выжать» из MySQL • MySQL NDB Cluster – работает только на небольших данных в памяти и плохо агрегирует • TokuDB – storage engine для аналитики • Шардинг (dbShards, Shard-Query, ScaleDB, ScaleBase) – распределенность, но • Тяжело управлять • Часто неэффективные запросы и джойны • Кроме Shard-Query – не бесплатны
  • 20. Пару слов про TokuDB • Компрессия (примерно в 5 раз) • Хорошо «держит» большие объемы за счет структуры индекса (сотни GB) • Производительность перестройки индекса не падает с ростом размера таблиц • Сокращает время доступа к данным за счет «кластеризующих» индексов • Выполнение аналитических запросов в 5-10 раз быстрее, чем InnoDB • 5 раз компрессия и до двух раз из-за «кластеризующего» индекса
  • 21. Рабочий вариант • TokuDB + Shard-Query • 100-200GB/server • Ограничения: • • • • shard column одна для всех таблиц Нет центрального управления, все вручную TokuDB плохо работает при больших range scan И еще одно...
  • 22. Help! Help, I need somebody Help, not just anybody Help, you know I need someone, help Help Help Help, Help When I was younger so much younger than today I never needed anybody's help in any way But now these days are gone, I'm not so self assured Now I find I've changed my mind and opened up the doors help Help me if you can, I'm feeling down And I do appreciate you being round Help me get my feet back on the ground Won't you please, please help me Help Help help
  • 23. Строки vs. колонки Row store Column store • Колонки Таблица хранится по строкам Каждая колонка хранится отдельно При любом обращении строка читается целиком При обращении к полю, читается только одна колонка или ее фрагмент Данные по строкам плохо сжимаются Колонки отлично сжимаются Дешевый update/delete Дорогой update/delete Легко реализуется Достаточно сложно реализуется
  • 24. Пример Таблица T 100 bigint колонок и 1 000 000 000 записей select sum(x) from T; Row store: 1 000 000 000 * 100 * 8 = 800 GB Column store: 1 000 000 000 * 1 * 8 = 8 GB Если учесть компрессию, то на порядок меньше
  • 25. Колоночные RDBMS • Open Source: • C-Store (pre-Vertica) • MonetDB (pre-VectorWise) • LucidDB • Коммерческие • • • • • • • Sybase IQ InfoBright * InfiniDB * ParAccel (and Amazon Redshift) GreenPlum (“эмуляция” на PostgreSQL) Vertica * VectorWise * Есть бесплатные версии ограниченной функциональности
  • 26. • 1140M строк в таблице • 20 колонок (int, float) • 5 серверов (native/ Shard-Query) 250 215 200 select country_code, count(*), sum(revenue) From test_table a, dim_country c where country_code in ('US’,'GB') and a.country_key=c.country_key group by country_code; 150 100 79 61 50 3,22 2,42 0 MonetDB TokuDB InfoBright ParAccel EE Vertica
  • 27. Vertica – это: • • • • Колонки! Нет индексов!! Нет таблиц!!! Эффективная компрессия данных • У нас в среднем в 13 раз, но может достигать и до 10....00 раз на колонку • Полный контроль над физической организацией • Очень быстрая загрузка • Shared nothing MPP
  • 28. Vertica: проекции • Таблиц физически нет, это логическая абстракция • Проекции (projection) • Подмножество колонок с сортировкой • Для каждой таблицы есть супер-проекция = все колонки • Для одной таблицы может быть любое число проекций разной структуры
  • 29. Vertica: проекции • Тип кодирования колонок: • • • • RLE DELTAVAL BLOCK_DICT И еще 12 разных способов • Сортировка! (особенно важна для RLE) • Группы колонок (фрагменты строк) • Сегментация по узлам кластера
  • 30. Vertica: физическое хранение • Большие блоки (мин 1Mb), после записи не меняются • Автоматическое объединение (со сборкой мусора и перекодированием) • Оптимизировано на последовательное чтениезапись с диска • Оптимизировано под кэш уровня OS или контроллера
  • 31. Vertica: выполнение запросов • Только «нужные» колонки • Предикаты могут выполняться на закодированных колонках • Сильно зависит от структуры проекций (не таблиц) • Ключевые инструменты – RLE с сортировкой и сегментация • Предикаты по отсортированной колонке ~ индексы • Джойны – merge, hash • Группировка, pipelined group by
  • 33. Как работает сортировка и RLE Gender Age M 1-20 21-25 26-35 36+ F Impressions 1-20 21-25 26-35 36+ 1 I/O 1 I/O 1 I/O select sum(impressions) from t where gender=‘M’ and age=‘21-25’
  • 34. Как работает сортировка и RLE Gender Age M 1-20 21-25 26-35 36+ F Impressions 1-20 21-25 26-35 36+ 2 I/O 2 I/O select sum(impressions) from t where age=‘21-25’
  • 35. Сортировка и pipelined group-by SELECT X, COUNT(*) FROM T GROUP BY X X (sorted) A A B B C C D D … A: 2 B: 2 • Выполняется в один проход • Почти не расходует память (stream) • Для кластера, если сегментировать по X, то тоже в один проход C: 2 D: 2 Сегментация по узлам
  • 36. Сортировка и merge join X (sorted) A A B B C C D D Y (sorted) A B C D • Работает, если сортировка одинаковая с обеих сторон • Для кластера: • одинаковая сегментация, или • одна из таблиц несегментирована (обычно) Сегментация по узлам
  • 37. Vertica: загрузка данных • Две зоны хранения: • WOS (in-memory) • ROS (on-disk) • Перенос из WOS в ROS автоматический (можно force) • Загрузка большими порциями очень быстрая: • В ROS: порядка 2-5M «колонок» в секунду на сервер • В WOS: еще быстрее, но может быть переполнение
  • 38. Vertica: кластер • 3..N одинаковых узлов – архитектура shared nothing • Конфигурируется на уровне проекции • Несегментированные – каждая нода содержит полные данные • Сегментированные – каждая нода 1/N данных • K-safety level – уровень дублирования 1 2 3 4 5 A A E A B A A C B A D C A E D Несегментированная Сегментированная, K=1 со сдвигом 1
  • 39. Vertica: aдминистрирование • Переконфигурирования кластера – все на лету • • • • • Выключение/включение узла Замена узла Добавление узла Изменение проекций И т. д. • Как этого добиваются? • Рестарт – только при апгрейде версии софта
  • 40. Vertica: cколько «тянет» один сервер/узел • 5 TB raw data или ~500 GB на диске • Если физический дизайн правильно настроен под конкретные задачи • Примерный сервер: • 2xE5620 или E5630 • 24-64GB RAM – зависит от задач и режима использования • 250-300GB SATA/SAS диски в RAID5 или RAID10 • Для кластера – 1Gb сеть между узлами (желательно, private) • Кластер на 3х узлах ~= отдельному серверу по скорости • Почему? K-safety=1 + сеть
  • 41. Vertica: cколько стоит? • It depends • Лицензируется объем сырых данных в «боевой» системе • Единовременно + support fee • Верхняя граница -- $100K за 1TB (list price) • Нижняя граница $2M за 1PB или $2K за 1TB
  • 42. Vertica Community Edition • 1 TB данных, 3 сервера в кластере • Достаточно для любых тестов, POC и т.д. • На объемах до 1TB обгонит всех БЕСПЛАТНО
  • 44. ParAccel • Тоже быстрая колоночная MPP RDBMS • Может быть быстрее Vertica на ad-hoc запросах • Используется как бэкенд Amazon Redshift
  • 45. ParAccel – основные отличия • Ограниченные возможности настройки физической структуры, только одна сортировка на таблицу • Неэффективный Vacuum («сборка мусора») • Нет партиционирования • Только последовательная загрузка • Два типа узлов: Leader Node (1) и Сompute Nodes (N) • Все кластерные операции требуют остановки БД • Более высокие требования к железу и сети • Лицензия per server/node
  • 46. Hadoop • Исторически – batch processing • Долгий старт задачи на больших кластерах • HDFS медленная • Материализация на диск промежуточных этапов • Hive неэффективен • Слишком generic
  • 47. Hadoop vs Vertica • SIGMOD 2009 paper: A Comparison of Approaches to Large-Scale Data Analysis http://database.cs.brown.edu/papers/benchmarkssigmod09.pdf • В «идеальных условиях» в среднем в 10 раз медленнее, чем Vertica • Агрегация медленнее в 15 раз • Джойны – в 20-30 • Hive примерно в 100 раз медленнее (наши тесты 2012)
  • 48. HadApt • Hadoop инфраструктура поверх PosgtreSQL • Очевидные преимущества PostgreSQL над HDFS • Те же недостатки Hadoop, плюс недостатки row store
  • 49. Hadoop Stinger • http://hortonworks.com/labs/stinger/ • Часть Hadoop 2.0 • Декларируемая Цель: ускорить Hive в 100 раз
  • 50. Hadoop Stinger: как? • ORC – новый колоночный формат HDFS: • RLE, dictionary encoding etc. • SQL типы данных и прочая SQL-семантика на уровне платформы • HСatalog – новое эффективное хранилище метаданных • Tez – новый MR-«движок», заточенный под Hive • Нет промежуточной материализации, наконец-то! • 100ms время старта • Новый cost-based query optimizer
  • 51. Hadoop Stinger: когда? • Частично уже (Oct 2013 -- HDP 2.0, Hive 0.12), утверждается увеличение производительности SQL/Hive в 35-40 раз • Полностью – coming soon • Будем пробовать 