CC BY
11
МАТЕМАТИКА, ИНФОРМАТИКА И ИНЖЕНЕРИЯ
УДК 004.65
Терских М.Г.
специалист по разработке распределённых вычислительных систем компании "EXON LV", студент магистратуры 2 курса факультет «Информатики и систем управления»
МГТУ им. Н.Э. Баумана Россия, г. Москва
ИССЛЕДОВАНИЕ БАЗ ДАННЫХ ДЛЯ ХРАНЕНИЯ ВРЕМЕННЫХ
РЯДОВ
Аннотация
Поставлена актуальная проблема быстрой обработки больших данных. Описаны ключевые возможности Yandex Clickhouse. Представлена архитектура кластеров в среде PostgerSQL и Yandex Clickhouse. Приведено описание базы данных, которая хранится на кластерах. Проведено тестирование быстродействия калстеров в системе управления базами данных PostgerSQL и Yandex Clickhouse. Сделаны выводы о целесообразности использования системы управления базами данных Yandex Clickhouse.
Ключевые слова: система управления базами данных, постгескьюэль, кликхауз, кластер, хранение временных рядов.
Terskikh M.G.
specialist in the development of distributed computing systems of the
"EXONLV" company student of the Master's program of «Informatics and management systems» Bauman Moscow State Technical University
Russia, Moscow RESEARCH DATABASES FOR STORING TIME-SERIES
Abstract
The article touches upon the issue of the actual problem of fast processing of big data. The key features of Yandex Clickhouse are described. The architecture of the cluster in an environment PostgreSQL and Yandex Clickhouse is showed. The description of the database, which is stored in the clusters, is reported. There is a testing of clusters in a database management system PostgreSQL and Yandex Clickhouse in the article. The conclusion about the feasibility of using a database management system Yandex Clickhouse is done.
Keywords: database management system, PostgreSQL, Clickhouse, cluster, storage time series.
Введение
С тех пор как люди начали собирать данные, разработчики сталкиваются с хранением и обработкой данных сгруппированных по дате и зависимые от неё. Главная особенность таких данных это наличие атрибута даты и времени, а также возможное большое количество столбцов. Примером может служить сбор температурных показателей в течение времени. Другой пример, который будет описываться, и анализироваться в статье, это хранение звонков из колл-центра. Из приведенных примеров, очевидно, что главным параметром в запросах является указание времени. Одним из наиболее продуктивных и доступных решений для хранения и обработки статистических данных на рынке, является СУБД Clickhouse от российской компании Yandex. На данной СУБД на текущий момент времени работают такие сервисы как Yandex Метрика, Yandex Маркет и другие крупные проекты от Yandex. В объединение с другим открытым проектом Apache Zookeeper, появляется возможность развернуть высокодоступный, распределенный кластер под любую задачу, связанную с хранением и обработкой статистики.
В данной статье будет проведено тестирование и сравнение быстродействия работы СУБД PostgreSQL и СУБД Yandex Clickhouse на примере развернутого кластера в обеих средах.
Немного о Yandex Clickhouse
Clickhouse - полностью столбцовая система управления базами данных (СУБД) для аналитической обработки в реальном времени (англ. online analytical processing OLAP) [1, с. 10]..
Ключевые особенности СУБД:
• Все столбцы хранятся в отдельных файлах, что позволяет прочитывать только те столбцы, по которым построен аналитический запрос. В случае, когда в таблице больше 100 столбцов, а запрос строится по 5 из них, то количество операций ввода/вывода уменьшается в 20 раз.
• СУБД использует векторный движок, позволяющий производить обработку данных по столбцам. В качестве вектора выступает столбец.
• Clickhouse строго использует значения постоянной длины, чтобы очистить данные от мусора в виде специальных символов. Что приводит к уменьшению нагрузки на CPU и повышает пропускную способность.
• Clickhouse СУБД является многопоточным, и обработка запросов распараллеливаются естественным образом.
• Первичный ключ обязателен и должен является датой. Каждый пулл данных с одинаковым первичным ключём Clickhouse хранит в одном образе.
• Существует возможность в реализации репликации и шардировании данных.
Для работы репликации (хранение метаданных и координация
действий) требуется ZooKeeper [2, c.15]. ClickHouse будет самостоятельно обеспечивать консистентность данных на репликах и производить восстановление после сбоев.
В рамках той достаточно узкой ниши, в которой находится ClickHouse, у него до сих пор нет альтернатив. В рамках более широкой области применения, ClickHouse может оказаться выгоднее других систем с точки зрения скорости обработки запросов, эффективности использования ресурсов и простоты эксплуатации.
Архитектура кластеров
Для реализации минимально возможного хранилища с использованием СУБД Yandex ClickHouse, отвечающего по надежности, высокой доступности и скорости обработки, необходимо 5 серверов [3, c.87]. Данные были разделены на 2 части, и каждая часть хранится в двух экземплярах. Минимальные требования к серверу: 512MB RAM, 1 CPU, 2GB SWAP, Ubuntu 14.04 x64.
На рисунке 1 изображена архитектура кластера с использованием СУБД Yandex ClickHouse.
Сервер 2 Сервер 3 Сервер 4 Сервер 5
Рисунок 1 - Архитектура кластера с использованием Clickhouse
Сервер 1 - обеспечивает обработку данных, занимается распараллеливанием задач между репликами. Он собирает данные присланные от подчиненных серверов и формирует ответ на запрос. На этом сервере данные не хранятся.
Сервер 2,3 - хранит первую половину данных. Оба сервера хранят одинаковые данные и постоянно синхронизируются. Они образуют 1-ый шард.
Сервер 3,4 - хранит вторую половину данных. Оба сервера хранят одинаковые данные и постоянно синхронизируются. Они образуют 2-ой шард.
В качестве сравнения, взят кластер из 4 серверов, практически идентичных по мощности с установленным PostgreSQL [4, c.145].
Конфигурация каждой машины: 1GB RAM, 2GB SWAP, 1 CPU, Ubuntu 14.04 x64.
Сервер 1 Сервер 2 Сервер 3 Сервер 4
Рисунок 2 - Архитектура кластера с использованием PostgreSQL
Сервер 1 и сервер 2 хранят первую половину одних и тех же данных, образуя первый шард.
Сервер 3 и сервер 4 хранят вторую половину одних и тех же данных, образуя второй шард.
Тестирование
В качестве данных для тестирования взята база данных звонков колл-центра. В среднем на каждый день формируется 10 000 записей о звонке. Специально для тестирования выбран годовой диапазон или примерно 3,6 миллиона записей.
В таблице 1 приведено описание полей, содержащихся в базе данных.
Таблица 1
Описание полей базы данных
Название столбца Тип в PostgreSQL Тип в Clickhouse
session id character varying(64) String
project id character varying(64) String
created date character varying(20) String
created hour integer Int64
created min slot integer Int64
created ts timestamp without time zone DateTime
queued ts timestamp without time zone DateTime
unblocked ts timestamp without time zone DateTime
connected ts timestamp without time zone DateTime
ended ts timestamp without time zone DateTime
is unblocked boolean UInt8
incoming asa integer, UInt8
incoming rt integer UInt8
incoming tt integer UInt8
hold duration integer UInt8
is_processed boolean UInt8
is_processed_after_threshold boolean UInt8
is abandoned boolean UInt8
is abandoned after threshold boolean UInt8
is shortly abandoned boolean UInt8
is abandoned on hold boolean UInt8
is abandoned on ivr boolean UInt8
agent connected character varying(256) String
has agent leg boolean UInt8
created ts - Date
Обратим внимание на последнее поле created_ts. Оно присутствует только лишь в базе данных среды Clickhouse. Данное поле нужно было для создания реплицируемых таблиц на серверах 2,3 и серверах 4,5 с движками типа MergeTree.
В качестве задачи, выделено три аналитических запроса:
1. Запрос, сгруппированный по дню
На входе: дата
На выходе: проект (project_id), кол-во звонков (quantity_of_calls), обслужен или нет (is_processed), дата (created_ts_date)
SELECT pro]ect_id,COUNT(} AS quantity_of_callsJis_processedicreated_ts_date GROUP BY cneated_ts_dateJprQ]"ect_idJis_processed
Рисунок - Листинг запроса 1
2. Запрос, сгруппированный по часу
На входе: дата
На выходе: проект (project_id), кол-во звонков (quantity_of_calls), обслужен или нет (is_processed), дата (created_ts_date)
SELECT projected,COUNT() AS quantity_of_calls,
is_pracessed jtaDateTime (toUInt32 (tobtartOiFHour ( created_ts }} + 3600) AS en FROM inbound_call_data WHERE created_ts_time = '2016-e6-29' GROUP BY created_ts_hoursJproject_idfis_processed ORDER BY created_ts_hours, projected DESC;
Рисунок - Листинг запроса 2
3. Запрос, сгруппированный по 15 минут
На входе: дата
На выходе: проект (project_id), кол-во звонков (quantity_of_calls), обслужен или нет (is_processed), дата (created_ts_date)
SELECT project_id,COUNT( } AS quantity_of_callsf
is_processeditoDateTime(toUIntB2(created_ts) - toUInt32(created_ts) Я AS created_ts_15_min FROM inbound_call_data WHERE с re at e d_t s_t i me = '2016-06-29' GROUP BY created_ts_15_min JprQ]"ect_idJis_processed ORDER BY created_ts_15_mini project_id DESC;
Рисунок - Листинг запроса 3
В таблице 2 приведено время работы вышеописанных запросов.
Таблица 2
_ Время работы запросов_
"—■—^^^^ СУБД Запрос —— PostgreSQL Clickhouse
Запрос, сгруппированный 0.8 с 0.054 с
по дню.
Запрос, сгруппированный 0.83 с 0.055 с
по часу.
Запрос, сгруппированный 0.95 с 0.063 с
по 15 минут.
Вывод
Исходя из результатов видно, что скорость обработки запросов СУБД Yandex Clickhouse на порядок выше, чем у СУБД PostgreSQL. При обработке данных в режиме реального времени скорость играет ключевую роль и СУБД PostgreSQL не справляется с поставленной задачей, в то время как СУБД Yandex Clickhouse показывает отличные результаты при обработке большого количества данных.
Использованные источники:
1. Руководство Yandex Clickhouse. URL: https://clickhouse.yandex7reference_ru.html (дата обращения: 15.10.2016).
2. Руководство Apache ZooKeeper. URL: https://zookeeper.apache.org/doc/r3.5.2-alpha/ (дата обращения: 10.10.2016).
3. Flavio Junqueira, Benjamin Reed. ZooKeeper Distributed Process Coordination. USA, O'Reilly Media, 2014, 246 p.
4. Григорьев Ю.А., Ревнуков Г.И. Банки данных. Москва, МГТУ им. Н.Э. Баумана, 2002, 320 с.
