Yandex.Metrica previously used a classical approach, when raw data was stored in aggregated form. This approach can help reduce the amount of stored data. However, it has several limitations and disadvantages:
The list of available reports must be pre-determined, and there is no way to make a custom report.
The volume of data can increase after aggregation. This happens when data is aggregated by a large number of keys or using keys with high cardinality.
It's difficult to support logical consistency around reports with different aggregations.
A different approach is to store unaggregated data. Processing raw data requires a high-performance system, since all calculations are made in real time. To solve this problem, a column-oriented DBMS is needed that can handle analytical data on the scale of the entire Internet. Yandex began developing its own. The first ClickHouse prototype appeared in 2009. By the end of 2014, Yandex.Metrica version 2.0 was released. The new version has an interface for creating custom reports and uses ClickHouse for storing and processing data.
Features
The main features of the ClickHouse DBMS are:
True column-oriented DBMS. Nothing is stored with the values. For example, constant-length values are supported to avoid storing their length "number" next to the values.
Linear scalability. It's possible to extend a cluster by adding servers.
Fault tolerance. The system is a cluster of shards, where each shard is a group of replicas. ClickHouse uses asynchronous multimaster replication. Data is written to any available replica, then distributed to all the remaining replicas. ZooKeeper is used for coordinating processes, but it's not involved in query processing and execution.
Capability to store and process petabytes of data.
SQL support. ClickHouse supports an extended SQL-like language that includes arrays and nested data structures, approximate and URI functions, and the availability to connect an external key-value store.
High performance.
* Vector calculations are used. Data is not only stored by columns, but is processed by vectors. This approach allows to achieve high CPU performance.
* Sampling and approximate calculations are supported.
* Parallel and distributed query processing is available.
By default when performing aggregations the query intermediate states must fit in the RAM on a single server. However ClickHouse can be configured to spill on the disk in such case.
Lack of full-fledged UPDATE/DELETE implementation.
It works with a small number of tables that contain a large number of columns.
Queries can use a large number of rows extracted from the DB, but only a small subset of columns.
Queries are relatively rare.
For simple queries, latencies of about 50 ms are allowed.
Column values are fairly small, usually consisting of numbers and short strings.
High throughput is required when processing a single query.
A query result is mostly filtered or aggregated.
Data update uses a simple scenario.
One of the common cases for ClickHouse is server log analysis. After setting regular data uploads to ClickHouse, it's possible to analyze incidents with instant queries or monitor a service's metrics, such as error rates, response times, and so on. ClickHouse can also be used as an internal data warehouse for in-house analysts. ClickHouse can store data from different systems and analysts can build internal dashboards with the data or perform real-time analysis for business purposes.
Benchmark results
According to benchmark tests conducted by developers, for OLAP queries ClickHouse is more than 100 times faster than Hive or MySQL.
