Эта статья была впервые опубликована на:Уокер ИИ
Вычисление показателей данных раундовых боев занимает слишком много времени, и даже одиночная машина не может удовлетворить спрос из-за нехватки памяти, поэтому принято решение заменить исходный одноузловой одномашинный ClickHouse на кластер, а использовать распределенный таблицы для соответствующих расчетов.
1. Строительство окружающей среды
1.1 Автономное решение
| Экземпляр ClickHouse | CPU | ОЗУ | диск |
|---|---|---|---|
| ClickHouse | 16C | 64G | 4T, высокий ввод-вывод |
1.2 Схема кластера 3 сегмента 1 реплика
| Экземпляр ClickHouse | CPU | ОЗУ | диск |
|---|---|---|---|
| ClickHouse1 | 16C | 64G | 4T, высокий ввод-вывод |
| ClickHouse2 | 8C | 32G | 1T, сверхвысокий ввод-вывод |
| ClickHouse3 | 8C | 32G | 1T, сверхвысокий ввод-вывод |
2. Сравнение схем
2.1 Сравнение скорости записи
Объем данных: 26910101 строк
Решение 1: Автономное решение (полные данные вставляются в таблицу для одного компьютера)
| Экземпляр ClickHouse | скорость письма |
|---|---|
| ClickHouse | 26.009 sec ;1.03 million rows/s , 504.78 MB/s |
Схема 2: Кластерная схема (данные записываются в физическую таблицу, а данные записываются в физическую таблицу 3-х машин параллельно)
| Экземпляр ClickHouse | скорость письма |
|---|---|
| ClickHouse1 | 13.640 sec; 1.97 million rows/s., 320.96 MB/s |
| ClickHouse2 | 9.166 sec ; 2.94 million rows/s, 982.03 MB/s |
| ClickHouse3 | 9.632 sec; 2.79 million rows/s., 931.00 MB/s |
Вывод: скорость записи данных связана с дисковым вводом-выводом, а запись данных кластерной схемы имеет значительные преимущества перед автономной схемой.
2.2 Сравнение запросов (в основном для группового запроса и связанных операций запроса)
(1) Метод построения распределенной таблицы
--物理表
CREATE table rd_physical.rd_baseinfo_physical on cluster cluster_3shards_1replicas
(
`appId` String,
`pvpId` String,
`accountId` String,
`userName` String,
`round` Nullable(Int32),
`event` String,
`mode` Nullable(Int32),
`win` Int32,
`country` String,
`timeStamp` String,
`ts` DateTime,
`ds` Date
)
ENGINE = ReplicatedMergeTree('/clickhouse/rd_physical/tables/{shard}/rd_baseinfo_physical', '{replica}')
PARTITION BY (ds)
ORDER BY (appId, accountId, pvpId)
SETTINGS index_granularity = 8192
--逻辑表
CREATE table rd_data.rd_baseinfo on cluster cluster_3shards_1replicas
(
`appId` String,
`pvpId` String,
`accountId` String,
`userName` String,
`round` Nullable(Int32),
`event` String,
`mode` Nullable(Int32),
`win` Int32,
`country` String,
`timeStamp` String,
`ts` DateTime,
`ds` Date
)
ENGINE =Distributed(cluster_3shards_1replicas, rd_physical, rd_baseinfo_physical, cityHash64(accountId))
(2) Групповой запрос
Оператор SQL: выберите count(*), accountId,pvpId из rd.rd_baseinfo, где ds>='2019-12-01' и ds
| Автономное решение | Кластерное решение |
|---|---|
| 10.177 sec ; 78.81 million rows/s., 2.66 GB/s | 6.264 sec ;104.32 million rows/s., 3.46 GB/s |
Вывод: Эффективность классификации данных и запросов в кластерной схеме примерно на 25% выше, чем у одиночной машины.
(3) Ассоциативный запрос
| Ассоциация | Автономное решение | Кластерное решение |
|---|---|---|
| 5 миллионов присоединяются к 1 миллиону | 0.946 sec; 0.86 million rows/s., 53.29 MB/s | 0.920 sec; 1.09 million rows/s., 75.70 MB/s |
| 10 миллионов присоединяются к 1 миллиону | 0.880 sec; 0.94 million rows/s., 58.80 MB/s | 0.921 sec; 1.09 million rows/s., 75.59 MB/s |
| 20 миллионов присоединяются к 1 миллиону | 0.938 sec; 0.87 million rows/s., 53.96 MB/s | 0.923 sec; 1.08 million rows/s., 75.41 MB/s |
| 50 миллионов присоединяются к 1 миллиону | 0.940 sec; 0.86 million rows/s., 53.81 MB/s | 0.960 sec; 1.04 million rows/s., 72.53 MB/s |
| 100 миллионов присоединяются к 1 миллиону | 1.906 sec; 0.90 million rows/s., 56.56 MB/s | 1.135 sec; 880.95 thousand rows/s., 61.34 MB/s. |
| 5 миллионов присоединиться к 5 миллионам | 5.141 sec; 1.01 million rows/s., 74.07 MB/s | 3.791 sec; 1.32 million rows/s., 91.46 MB/s |
| 10 миллионов присоединяются к 5 миллионам | 5.149 sec; 1.01 million rows/s., 73.92 MB/s | 4.127 sec; 1.21 million rows/s., 84.00 MB/s |
| 20 миллионов присоединяются к 5 миллионам | 5.172 sec; 1.00 million rows/s., 73.46 MB/s | 4.110 sec; 1.22 million rows/s., 84.36 MB/s |
| 50 миллионов присоединяются к 5 миллионам | 5.096 sec; 1.02 million rows/s., 75.00 MB/s | 4.342 sec; 1.15 million rows/s., 79.84 MB/s |
| 100 миллионов присоединиться к 5 миллионам | 6.108 sec; 1.02 million rows/s., 74.75 MB/s | 4.362 sec; 1.15 million rows/s., 79.49 MB/s |
| 5 миллионов присоединяются к 10 миллионам | 12.341 sec; 1.16 million rows/s., 85.39 MB/s | 7.885 sec; 1.27 million rows/s., 87.61 MB/s |
| 10 миллионов присоединяются к 10 миллионам | 12.337 sec; 1.16 million rows/s., 85.44 MB/s | 7.916 sec; 1.26 million rows/s., 87.27 MB/s |
| 20 миллионов присоединяются к 10 миллионам | 12.324 sec; 1.17 million rows/s., 85.61 MB/s | 7.777 sec; 1.29 million rows/s., 88.84 MB/s |
| 50 миллионов присоединяются к 10 миллионам | 13.039 sec; 1.14 million rows/s., 87.10 MB/s | 8.083 sec; 1.24 million rows/s., 85.46 MB/s |
| 100 миллионов присоединяются к 10 миллионам | 13.101 sec; 1.13 million rows/s., 86.43 MB/s | 8.578 sec; 1.17 million rows/s., 80.53 MB/s |
Вывод: для операций присоединения небольших объемов данных разница между решением для одной машины и кластерным решением незначительна; решение для одной машины с большим объемом данных не так хорошо, как решение для кластера, а решение для одной машины также может проблемы, такие как нехватка памяти.
3. Другие аспекты
ClickHouse менее параллелен, и официальный запрос веб-сайта рекомендует 100 Queries/sec.ClickHouse для одной машины не подходит для запросов бизнес-типа с высоким параллелизмом. Кластер ClickHouse может проксировать параллельные запросы к каждому сегменту в кластере через chproxy, что может значительно улучшить параллелизм.
4. Резюме теста производительности
Производительность автономного решения для записи данных значительно уступает кластерному решению.
С точки зрения запроса нет очевидной разницы между решением для одной машины и кластерным решением, когда объем данных мал.Когда объем данных велик, кластерное решение не будет иметь таких проблем, как нехватка памяти и ЦП, а также эффективность запросов также выше, чем у одномашинного решения.
По сравнению с автономным решением кластерное решение немного громоздко для построения таблиц.Данные записи распределенной таблицы не могут быть записаны в физическую таблицу каждого шарда в режиме реального времени, а будут сначала записываться в память, а затем синхронизироваться с каждым shard.Поэтому нам нужно писать в каждый шард.Физическая таблица пишет данные одновременно.
Подводя итог, можно сказать, что в настоящее время объем данных round и roundData увеличивается, и можно построить кластерную схему распределенного хранения данных.
PS: Для получения дополнительной технической галантереи, пожалуйста, обратите внимание на [Публичный аккаунт | xingzhe_ai] и обсудите с ходоками!