mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-25 17:12:03 +00:00
Normalize header styles
This commit is contained in:
Ivan Blinkov
parent
20f5a8e41f
commit
756cad8d80
@ -1,62 +1,62 @@
|
||||
Distinctive features of ClickHouse
|
||||
==================================
|
||||
|
||||
1. True column-oriented DBMS.
|
||||
-----------------------------
|
||||
True column-oriented DBMS
|
||||
-------------------------
|
||||
In a true column-oriented DBMS, there isn't any "garbage" stored with the values. For example, constant-length values must be supported, to avoid storing their length "number" next to the values. As an example, a billion UInt8-type values should actually consume around 1 GB uncompressed, or this will strongly affect the CPU use. It is very important to store data compactly (without any "garbage") even when uncompressed, since the speed of decompression (CPU usage) depends mainly on the volume of uncompressed data.
|
||||
|
||||
This is worth noting because there are systems that can store values of separate columns separately, but that can't effectively process analytical queries due to their optimization for other scenarios. Example are HBase, BigTable, Cassandra, and HyperTable. In these systems, you will get throughput around a hundred thousand rows per second, but not hundreds of millions of rows per second.
|
||||
|
||||
Also note that ClickHouse is a DBMS, not a single database. ClickHouse allows creating tables and databases in runtime, loading data, and running queries without reconfiguring and restarting the server.
|
||||
|
||||
2. Data compression.
|
||||
--------------------
|
||||
Data compression
|
||||
----------------
|
||||
Some column-oriented DBMSs (InfiniDB CE and MonetDB) do not use data compression. However, data compression really improves performance.
|
||||
|
||||
3. Disk storage of data.
|
||||
------------------------
|
||||
Disk storage of data
|
||||
--------------------
|
||||
Many column-oriented DBMSs (SAP HANA, and Google PowerDrill) can only work in RAM. But even on thousands of servers, the RAM is too small for storing all the pageviews and sessions in Yandex.Metrica.
|
||||
|
||||
4. Parallel processing on multiple cores.
|
||||
-----------------------------------------
|
||||
Parallel processing on multiple cores
|
||||
-------------------------------------
|
||||
Large queries are parallelized in a natural way.
|
||||
|
||||
5. Distributed processing on multiple servers.
|
||||
----------------------------------------------
|
||||
Distributed processing on multiple servers
|
||||
------------------------------------------
|
||||
Almost none of the columnar DBMSs listed above have support for distributed processing.
|
||||
In ClickHouse, data can reside on different shards. Each shard can be a group of replicas that are used for fault tolerance. The query is processed on all the shards in parallel. This is transparent for the user.
|
||||
|
||||
6. SQL support.
|
||||
---------------
|
||||
SQL support
|
||||
-----------
|
||||
If you are familiar with standard SQL, we can't really talk about SQL support.
|
||||
NULLs are not supported. All the functions have different names. However, this is a declarative query language based on SQL that can't be differentiated from SQL in many instances.
|
||||
JOINs are supported. Subqueries are supported in FROM, IN, JOIN clauses; and scalar subqueries.
|
||||
Correlated subqueries are not supported.
|
||||
|
||||
7. Vector engine.
|
||||
-----------------
|
||||
Vector engine
|
||||
-------------
|
||||
Data is not only stored by columns, but is processed by vectors - parts of columns. This allows us to achieve high CPU performance.
|
||||
|
||||
8. Real-time data updates.
|
||||
--------------------------
|
||||
Real time data updates
|
||||
----------------------
|
||||
ClickHouse supports primary key tables. In order to quickly perform queries on the range of the primary key, the data is sorted incrementally using the merge tree. Due to this, data can continually be added to the table. There is no locking when adding data.
|
||||
|
||||
9. Indexes.
|
||||
-----------
|
||||
Indexes
|
||||
-------
|
||||
Having a primary key allows, for example, extracting data for specific clients (Metrica counters) for a specific time range, with low latency less than several dozen milliseconds.
|
||||
|
||||
10. Suitable for online queries.
|
||||
--------------------------------
|
||||
Suitable for online queries
|
||||
---------------------------
|
||||
This lets us use the system as the back-end for a web interface. Low latency means queries can be processed without delay, while the Yandex.Metrica interface page is loading (in online mode).
|
||||
|
||||
11. Support for approximated calculations.
|
||||
------------------------------------------
|
||||
Support for approximated calculations
|
||||
-------------------------------------
|
||||
|
||||
#. The system contains aggregate functions for approximated calculation of the number of various values, medians, and quantiles.
|
||||
#. Supports running a query based on a part (sample) of data and getting an approximated result. In this case, proportionally less data is retrieved from the disk.
|
||||
#. Supports running an aggregation for a limited number of random keys, instead of for all keys. Under certain conditions for key distribution in the data, this provides a reasonably accurate result while using fewer resources.
|
||||
|
||||
14. Data replication and support for data integrity on replicas.
|
||||
----------------------------------------------------------------
|
||||
Data replication and support for data integrity on replicas
|
||||
-----------------------------------------------------------
|
||||
Uses asynchronous multi-master replication. After being written to any available replica, data is distributed to all the remaining replicas. The system maintains identical data on different replicas. Data is restored automatically after a failure, or using a "button" for complex cases.
|
||||
For more information, see the section "Data replication".
|
||||
|
||||
@ -6,7 +6,7 @@ Introduction
|
||||
|
||||
what_is_clickhouse
|
||||
distinctive_features
|
||||
features
|
||||
features_considered_disadvantages
|
||||
ya_metrika_task
|
||||
possible_silly_questions
|
||||
performance
|
||||
|
||||
@ -8,14 +8,14 @@ Throughput can be measured in rows per second or in megabytes per second. If the
|
||||
|
||||
The processing speed increases almost linearly for distributed processing, but only if the number of rows resulting from aggregation or sorting is not too large.
|
||||
|
||||
Latency when processing short queries.
|
||||
--------------------------------------
|
||||
Latency when processing short queries
|
||||
-------------------------------------
|
||||
If a query uses a primary key and does not select too many rows to process (hundreds of thousands), and does not use too many columns, we can expect less than 50 milliseconds of latency (single digits of milliseconds in the best case) if data is placed in the page cache. Otherwise, latency is calculated from the number of seeks. If you use rotating drives, for a system that is not overloaded, the latency is calculated by this formula: seek time (10 ms) * number of columns queried * number of data parts.
|
||||
|
||||
Throughput when processing a large quantity of short queries.
|
||||
-------------------------------------------------------------
|
||||
Throughput when processing a large quantity of short queries
|
||||
------------------------------------------------------------
|
||||
Under the same conditions, ClickHouse can handle several hundred queries per second on a single server (up to several thousand in the best case). Since this scenario is not typical for analytical DBMSs, we recommend expecting a maximum of 100 queries per second.
|
||||
|
||||
Performance on data insertion.
|
||||
------------------------------
|
||||
Performance on data insertion
|
||||
-----------------------------
|
||||
We recommend inserting data in packets of at least 1000 rows, or no more than a single request per second. When inserting to a MergeTree table from a tab-separated dump, the insertion speed will be from 50 to 200 MB/s. If the inserted rows are around 1 Kb in size, the speed will be from 50,000 to 200,000 rows per second. If the rows are small, the performance will be higher in rows per second (on Yandex Banner System data -> 500,000 rows per second, on Graphite data -> 1,000,000 rows per second). To improve performance, you can make multiple INSERT queries in parallel, and performance will increase linearly.
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
Possible silly questions
|
||||
------------------------
|
||||
|
||||
1. Why not to use systems like map-reduce?
|
||||
""""""""""""""""""""""""""""""""""""""""""
|
||||
Why not to use systems like MapReduce?
|
||||
""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
Systems like map-reduce are distributed computing systems, where the reduce phase is performed using distributed sorting.
|
||||
Regarding this aspect, map-reduce is similar to other systems like YAMR, Hadoop, YT.
|
||||
|
||||
@ -251,6 +251,7 @@ JVM parameters:
|
||||
Инициализация через Salt:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
description "zookeeper-{{ cluster['name'] }} centralized coordination service"
|
||||
|
||||
start on runlevel [2345]
|
||||
|
||||
@ -91,8 +91,8 @@ In all cases, if TEMPORARY is specified, a temporary table will be created. Temp
|
||||
|
||||
In most cases, temporary tables are not created manually, but when using external data for a query, or for distributed (GLOBAL) IN. For more information, see the appropriate sections.
|
||||
|
||||
Distributed DDL queries (section ``ON CLUSTER``)
|
||||
""""""""""""""""""""""""""""""""""""""""""""""""
|
||||
Distributed DDL queries (ON CLUSTER section)
|
||||
""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
Queries ``CREATE``, ``DROP``, ``ALTER``, ``RENAME`` support distributed execution on cluster.
|
||||
For example, the following query creates ``Distributed`` table ``all_hits`` for each host of the cluster ``cluster``:
|
||||
|
||||
@ -1,63 +1,63 @@
|
||||
Отличительные возможности ClickHouse
|
||||
====================================
|
||||
|
||||
1. По-настоящему столбцовая СУБД.
|
||||
---------------------------------
|
||||
По-настоящему столбцовая СУБД
|
||||
-----------------------------
|
||||
В по-настоящему столбцовой СУБД рядом со значениями не хранится никакого "мусора". Например, должны поддерживаться значения постоянной длины, чтобы не хранить рядом со значениями типа "число" их длины. Для примера, миллиард значений типа UInt8 должен действительно занимать в несжатом виде около 1GB, иначе это сильно ударит по эффективности использования CPU. Очень важно хранить данные компактно (без "мусора") в том числе в несжатом виде, так как скорость разжатия (использование CPU) зависит, в основном, от объёма несжатых данных.
|
||||
|
||||
Этот пункт пришлось выделить, так как существуют системы, которые могут хранить значения отдельных столбцов по отдельности, но не могут эффективно выполнять аналитические запросы в силу оптимизации под другой сценарий работы. Примеры: HBase, BigTable, Cassandra, HyperTable. В этих системах вы получите throughput в районе сотен тысяч строк в секунду, но не сотен миллионов строк в секунду.
|
||||
|
||||
Также стоит заметить, что ClickHouse является СУБД, а не одной базой данных. То есть, ClickHouse позволяет создавать таблицы и базы данных в runtime, загружать данные и выполнять запросы без переконфигурирования и перезапуска сервера.
|
||||
|
||||
2. Сжатие данных.
|
||||
-----------------
|
||||
Сжатие данных
|
||||
-------------
|
||||
Некоторые столбцовые СУБД (InfiniDB CE, MonetDB) не используют сжатие данных. Но сжатие данных действительно серьёзно увеличивает производительность.
|
||||
|
||||
3. Хранение данных на диске.
|
||||
----------------------------
|
||||
Хранение данных на диске
|
||||
------------------------
|
||||
Многие столбцовые СУБД (SAP HANA, Google PowerDrill) могут работать только в оперативке. Но оперативки (даже на тысячах серверах) слишком мало для хранения всех хитов и визитов в Яндекс.Метрике.
|
||||
|
||||
4. Параллельная обработка запроса на многих процессорных ядрах.
|
||||
---------------------------------------------------------------
|
||||
Параллельная обработка запроса на многих процессорных ядрах
|
||||
-----------------------------------------------------------
|
||||
Большие запросы естественным образом распараллеливаются.
|
||||
|
||||
5. Распределённая обработка запроса на многих серверах.
|
||||
-------------------------------------------------------
|
||||
Распределённая обработка запроса на многих серверах
|
||||
---------------------------------------------------
|
||||
Почти все перечисленные ранее столбцовые СУБД не поддерживают распределённую обработку запроса.
|
||||
В ClickHouse данные могут быть расположены на разных шардах. Каждый шард может представлять собой группу реплик, которые используются для отказоустойчивости. Запрос будет выполнен на всех шардах параллельно. Это делается прозрачно для пользователя.
|
||||
|
||||
6. Поддержка SQL.
|
||||
-----------------
|
||||
Поддержка SQL
|
||||
-------------
|
||||
Если вы знаете, что такое стандартный SQL, то говорить о поддержке SQL всё-таки нельзя.
|
||||
Не поддерживаются NULL-ы. Все функции названы по-другому.
|
||||
Тем не менее, это - декларативный язык запросов на основе SQL и во многих случаях не отличимый от SQL.
|
||||
Поддерживаются JOIN-ы. Поддерживаются подзапросы в секциях FROM, IN, JOIN, а также скалярные подзапросы.
|
||||
Зависимые подзапросы не поддерживаются.
|
||||
|
||||
7. Векторный движок.
|
||||
--------------------
|
||||
Векторный движок
|
||||
----------------
|
||||
Данные не только хранятся по столбцам, но и обрабатываются по векторам - кусочкам столбцов. За счёт этого достигается высокая эффективность по CPU.
|
||||
|
||||
8. Обновление данных в реальном времени.
|
||||
----------------------------------------
|
||||
Обновление данных в реальном времени
|
||||
------------------------------------
|
||||
ClickHouse поддерживает таблицы с первичным ключом. Для того, чтобы можно было быстро выполнять запросы по диапазону первичного ключа, данные инкрементально сортируются с помощью merge дерева. За счёт этого, поддерживается постоянное добавление данных в таблицу. Блокировки при добавлении данных отсутствуют.
|
||||
|
||||
9. Наличие индексов.
|
||||
--------------------
|
||||
Наличие индексов
|
||||
----------------
|
||||
Наличие первичного ключа позволяет, например, вынимать данные для конкретных клиентов (счётчиков Метрики), для заданного диапазона времени, с низкими задержками - менее десятков миллисекунд.
|
||||
|
||||
10. Подходит для онлайн запросов.
|
||||
---------------------------------
|
||||
Подходит для онлайн запросов
|
||||
----------------------------
|
||||
Это позволяет использовать систему в качестве бэкенда для веб-интерфейса. Низкие задержки позволяют не откладывать выполнение запроса, а выполнять его в момент загрузки страницы интерфейса Яндекс.Метрики. То есть, в режиме онлайн.
|
||||
|
||||
11. Поддержка приближённых вычислений.
|
||||
--------------------------------------
|
||||
Поддержка приближённых вычислений
|
||||
---------------------------------
|
||||
|
||||
#. Система содержит агрегатные функции для приближённого вычисления количества различных значений, медианы и квантилей.
|
||||
#. Поддерживается возможность выполнить запрос на основе части (выборки) данных и получить приближённый результат. При этом, с диска будет считано пропорционально меньше данных.
|
||||
#. Поддерживается возможность выполнить агрегацию не для всех ключей, а для ограниченного количества первых попавшихся ключей. При выполнении некоторых условий на распределение ключей в данных, это позволяет получить достаточно точный результат с использованием меньшего количества ресурсов.
|
||||
|
||||
14. Репликация данных, поддержка целостности данных на репликах.
|
||||
----------------------------------------------------------------
|
||||
Репликация данных, поддержка целостности данных на репликах
|
||||
-----------------------------------------------------------
|
||||
Используется асинхронная multimaster репликация. После записи на любую доступную реплику, данные распространяются на все остальные реплики. Система поддерживает полную идентичность данных на разных репликах. Восстановление после сбоя осуществляется автоматически, а в сложных случаях - "по кнопке".
|
||||
Подробнее смотрите раздел :ref:`table_engines-replication`.
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
what_is_clickhouse
|
||||
distinctive_features
|
||||
features
|
||||
features_considered_disadvantages
|
||||
ya_metrika_task
|
||||
possible_silly_questions
|
||||
performance
|
||||
|
||||
@ -8,14 +8,14 @@
|
||||
|
||||
При распределённой обработке запроса, скорость обработки запроса растёт почти линейно, но только при условии, что в результате агрегации или при сортировке получается не слишком большое множество строчек.
|
||||
|
||||
Задержки при обработке коротких запросов.
|
||||
-----------------------------------------
|
||||
Задержки при обработке коротких запросов
|
||||
----------------------------------------
|
||||
Если запрос использует первичный ключ, и выбирает для обработки не слишком большое количество строчек (сотни тысяч), и использует не слишком большое количество столбцов, то вы можете рассчитывать на latency менее 50 миллисекунд (от единиц миллисекунд в лучшем случае), при условии, что данные помещаются в page cache. Иначе latency вычисляется из количества seek-ов. Если вы используйте вращающиеся диски, то на не слишком сильно нагруженной системе, latency вычисляется по формуле: seek time (10 мс.) * количество столбцов в запросе * количество кусков с данными.
|
||||
|
||||
Пропускная способность при обработке большого количества коротких запросов.
|
||||
---------------------------------------------------------------------------
|
||||
Пропускная способность при обработке большого количества коротких запросов
|
||||
--------------------------------------------------------------------------
|
||||
При тех же условиях, ClickHouse может обработать несколько сотен (до нескольких тысяч в лучшем случае) запросов в секунду на одном сервере. Так как такой сценарий работы не является типичным для аналитических СУБД, рекомендуется рассчитывать не более чем на 100 запросов в секунду.
|
||||
|
||||
Производительность при вставке данных.
|
||||
--------------------------------------
|
||||
Производительность при вставке данных
|
||||
-------------------------------------
|
||||
Данные рекомендуется вставлять пачками не менее 1000 строк или не более одного запроса в секунду. При вставке в таблицу типа MergeTree из tab-separated дампа, скорость вставки будет в районе 50-200 МБ/сек. Если вставляются строчки размером около 1 КБ, то скорость будет в районе 50 000 - 200 000 строчек в секунду. Если строчки маленькие - производительность в строчках в секунду будет выше (на данных БК - > 500 000 строк в секунду, на данных Graphite - > 1 000 000 строк в секунду). Для увеличения производительности, можно производить несколько запросов INSERT параллельно - при этом производительность растёт линейно.
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
Возможные глупые вопросы
|
||||
------------------------
|
||||
|
||||
1. Почему бы не использовать системы типа map-reduce?
|
||||
"""""""""""""""""""""""""""""""""""""""""""""""""""""
|
||||
Почему бы не использовать системы типа MapReduce?
|
||||
"""""""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
Системами типа map-reduce будем называть системы распределённых вычислений, в которых операция reduce сделана на основе распределённой сортировки. Таким образом, к ним относятся YAMR, Hadoop, YT.
|
||||
|
||||
|
||||
@ -251,6 +251,7 @@ zoo.cfg:
|
||||
Salt init:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
description "zookeeper-{{ cluster['name'] }} centralized coordination service"
|
||||
|
||||
start on runlevel [2345]
|
||||
|
||||
@ -92,8 +92,8 @@ CREATE TABLE
|
||||
|
||||
В большинстве случаев, временные таблицы создаются не вручную, а при использовании внешних данных для запроса, или при распределённом ``(GLOBAL) IN``. Подробнее см. соответствующие разделы
|
||||
|
||||
Распределенные DDL запросы (секция ``ON CLUSTER``)
|
||||
""""""""""""""""""""""""""""""""""""""""""""""""""
|
||||
Распределенные DDL запросы (секция ON CLUSTER)
|
||||
""""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
Запросы ``CREATE``, ``DROP``, ``ALTER``, ``RENAME`` поддерживают возможность распределенного выполнения на кластере.
|
||||
Например, следующий запрос создает ``Distributed``-таблицу ``all_hits`` на каждом хосте кластера ``cluster``:
|
||||
|
||||
Loading…
Reference in New Issue
Block a user