thevar1able/ClickHouse
1
0
Fork 0
mirror of https://github.com/ClickHouse/ClickHouse.git synced 2024-11-22 07:31:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

Document tree and project settings are prepared for site generation. Final step of NO-RST company.

Browse Source
This commit is contained in:
BayoNet 2018-02-11 11:18:20 +03:00
parent 53e1ac918e
commit 5f0fa2c2fb
57 changed files with 298 additions and 598 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
docs/build.sh
View File

@ -9,6 +9,7 @@ fi
for lang in $LANGS; do
echo -e "\n\nLANG=$lang. Creating single page source"
mkdir $lang'_single_page'
cp -r $lang/images $lang'_single_page'
./concatenate.py $lang
echo -e "\n\nLANG=$lang. Building multipage..."
mkdocs build -f mkdocs_$lang.yml

2
docs/create_contents.py
View File

@ -1,7 +1,7 @@
#!/usr/bin/env python
# -*- coding: utf-8 -*-
SOURCES_TREE = 'en'
SOURCES_TREE = 'ru'
from os import walk
def get_header(filepath):

11
docs/en/agg_functions/index.md
View File

@ -8,14 +8,3 @@ ClickHouse also supports:
- [Parametric aggregate functions](parametric_functions.md#aggregate_functions_parametric), which accept other parameters in addition to columns.
- [Combinators](combinators.md#aggregate_functions_combinators), which change the behavior of aggregate functions.
**Table of Contents**
```eval_rst
.. toctree::
reference
parametric_functions
combinators
```

10
docs/en/data_types/index.md
View File

@ -2,12 +2,6 @@
# Data types
```eval_rst
.. toctree::
:glob:
*
*/index
```
ClickHouse table fields can contain data of different types.
The topic contains descriptions of data types supported and specificity of their usage of implementation if exists.

8
docs/en/data_types/nested_data_structures/index.md
View File

@ -1,9 +1 @@
# Nested data structures
```eval_rst
.. toctree::
:glob:
*
```

7
docs/en/data_types/special_data_types/index.md
View File

@ -2,10 +2,3 @@
Special data type values can't be saved to a table or output in results, but are used as the intermediate result of running a query.
```eval_rst
.. toctree::
:glob:
*
```

7
docs/en/development/index.md
View File

@ -1,9 +1,2 @@
# ClickHouse Development
```eval_rst
.. toctree::
:glob:
*
```

8
docs/en/dicts/index.md
View File

@ -5,11 +5,3 @@ You can think of this as a more convenient and efficient type of JOIN with dimen
There are built-in (internal) and add-on (external) dictionaries.
```eval_rst
.. toctree::
external_dicts
internal_dicts
```

8
docs/en/formats/index.md
View File

@ -3,11 +3,3 @@
# Formats
The format determines how data is returned to you after SELECTs (how it is written and formatted by the server), and how it is accepted for INSERTs (how it is read and parsed by the server).
```eval_rst
.. toctree::
:glob:
*
```

7
docs/en/functions/index.md
View File

@ -6,13 +6,6 @@ In this section we discuss regular functions. For aggregate functions, see the s
\* - There is a third type of function that the 'arrayJoin' function belongs to; table functions can also be mentioned separately.\*
```eval_rst
.. toctree::
:glob:
*
```
## Strong typing
In contrast to standard SQL, ClickHouse has strong typing. In other words, it doesn't make implicit conversions between types. Each function works for a specific set of types. This means that sometimes you need to use type conversion functions.

10
docs/en/getting_started/index.md
View File

@ -132,12 +132,4 @@ SELECT 1
**Congratulations, the system works!**
To continue experimenting, you can try to download from the test data sets:
```eval_rst
.. toctree::
:glob:
example_datasets/*
```
To continue experimenting, you can try to download from the test data sets.

141
docs/en/index.md
View File

@ -1,24 +1,123 @@
# Documentation
# What is ClickHouse?
```eval_rst
.. toctree::
:maxdepth: 6
introduction/index
getting_started/index
interfaces/index
query_language/index
table_engines/index
system_tables/index
table_functions/index
formats/index
data_types/index
operators/index
functions/index
agg_functions/index
dicts/index
operations/index
development/index
roadmap
ClickHouse is a columnar DBMS for OLAP.
In a "normal" row-oriented DBMS, data is stored in this order:
```text
5123456789123456789 1 Eurobasket - Greece - Bosnia and Herzegovina - example.com 1 2011-09-01 01:03:02 6274717 1294101174 11409 612345678912345678 0 33 6 http://www.example.com/basketball/team/123/match/456789.html http://www.example.com/basketball/team/123/match/987654.html 0 1366 768 32 10 3183 0 0 13 0\0 1 1 0 0 2011142 -1 0 0 01321 613 660 2011-09-01 08:01:17 0 0 0 0 utf-8 1466 0 0 0 5678901234567890123 277789954 0 0 0 0 0
5234985259563631958 0 Consulting, Tax assessment, Accounting, Law 1 2011-09-01 01:03:02 6320881 2111222333 213 6458937489576391093 0 3 2 http://www.example.ru/ 0 800 600 16 10 2 153.1 0 0 10 63 1 1 0 0 2111678 000 0 588 368 240 2011-09-01 01:03:17 4 0 60310 0 windows-1251 1466 0 000 778899001 0 0 0 0 0
...
```
In order words, all the values related to a row are stored next to each other.
Examples of a row-oriented DBMS are MySQL, Postgres, MS SQL Server, and others.
In a column-oriented DBMS, data is stored like this:
```text
WatchID: 5385521489354350662 5385521490329509958 5385521489953706054 5385521490476781638 5385521490583269446 5385521490218868806 5385521491437850694 5385521491090174022 5385521490792669254 5385521490420695110 5385521491532181574 5385521491559694406 5385521491459625030 5385521492275175494 5385521492781318214 5385521492710027334 5385521492955615302 5385521493708759110 5385521494506434630 5385521493104611398
JavaEnable: 1 0 1 0 0 0 1 0 1 1 1 1 1 1 0 1 0 0 1 1
Title: Yandex Announcements - Investor Relations - Yandex Yandex — Contact us — Moscow Yandex — Mission Ru Yandex — History — History of Yandex Yandex Financial Releases - Investor Relations - Yandex Yandex — Locations Yandex Board of Directors - Corporate Governance - Yandex Yandex — Technologies
GoodEvent: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
EventTime: 2016-05-18 05:19:20 2016-05-18 08:10:20 2016-05-18 07:38:00 2016-05-18 01:13:08 2016-05-18 00:04:06 2016-05-18 04:21:30 2016-05-18 00:34:16 2016-05-18 07:35:49 2016-05-18 11:41:59 2016-05-18 01:13:32
```
These examples only show the order that data is arranged in.
The values from different columns are stored separately, and data from the same column is stored together.
Examples of column-oriented DBMSs: `Vertica`, `Paraccel (Actian Matrix) (Amazon Redshift)`, `Sybase IQ`, `Exasol`, `Infobright`, `InfiniDB`, `MonetDB (VectorWise) (Actian Vector)`, `LucidDB`, `SAP HANA`, `Google Dremel`, `Google PowerDrill`, `Druid`, `kdb+`, and so on.
Different orders for storing data are better suited to different scenarios.
The data access scenario refers to what queries are made, how often, and in what proportion; how much data is read for each type of query – rows, columns, and bytes; the relationship between reading and updating data; the working size of the data and how locally it is used; whether transactions are used, and how isolated they are; requirements for data replication and logical integrity; requirements for latency and throughput for each type of query, and so on.
The higher the load on the system, the more important it is to customize the system to the scenario, and the more specific this customization becomes. There is no system that is equally well-suited to significantly different scenarios. If a system is adaptable to a wide set of scenarios, under a high load, the system will handle all the scenarios equally poorly, or will work well for just one of the scenarios.
We'll say that the following is true for the OLAP (online analytical processing) scenario:
- The vast majority of requests are for read access.
- Data is updated in fairly large batches (> 1000 rows), not by single rows; or it is not updated at all.
- Data is added to the DB but is not modified.
- For reads, quite a large number of rows are extracted from the DB, but only a small subset of columns.
- Tables are "wide," meaning they contain a large number of columns.
- Queries are relatively rare (usually hundreds of queries per server or less per second).
- For simple queries, latencies around 50 ms are allowed.
- Column values are fairly small: numbers and short strings (for example, 60 bytes per URL).
- Requires high throughput when processing a single query (up to billions of rows per second per server).
- There are no transactions.
- Low requirements for data consistency.
- There is one large table per query. All tables are small, except for one.
- A query result is significantly smaller than the source data. In other words, data is filtered or aggregated. The result fits in a single server's RAM.
It is easy to see that the OLAP scenario is very different from other popular scenarios (such as OLTP or Key-Value access). So it doesn't make sense to try to use OLTP or a Key-Value DB for processing analytical queries if you want to get decent performance. For example, if you try to use MongoDB or Elliptics for analytics, you will get very poor performance compared to OLAP databases.
Columnar-oriented databases are better suited to OLAP scenarios (at least 100 times better in processing speed for most queries), for the following reasons:
1. For I/O.
2. For an analytical query, only a small number of table columns need to be read. In a column-oriented database, you can read just the data you need. For example, if you need 5 columns out of 100, you can expect a 20-fold reduction in I/O.
3. Since data is read in packets, it is easier to compress. Data in columns is also easier to compress. This further reduces the I/O volume.
4. Due to the reduced I/O, more data fits in the system cache.
For example, the query "count the number of records for each advertising platform" requires reading one "advertising platform ID" column, which takes up 1 byte uncompressed. If most of the traffic was not from advertising platforms, you can expect at least 10-fold compression of this column. When using a quick compression algorithm, data decompression is possible at a speed of at least several gigabytes of uncompressed data per second. In other words, this query can be processed at a speed of approximately several billion rows per second on a single server. This speed is actually achieved in practice.
Example:
```bash
milovidov@hostname:~$ clickhouse-client
ClickHouse client version 0.0.52053.
Connecting to localhost:9000.
Connected to ClickHouse server version 0.0.52053.
:) SELECT CounterID, count() FROM hits GROUP BY CounterID ORDER BY count() DESC LIMIT 20
SELECT
CounterID,
count()
FROM hits
GROUP BY CounterID
ORDER BY count() DESC
LIMIT 20
┌─CounterID─┬──count()─┐
│ 114208 │ 56057344 │
│ 115080 │ 51619590 │
│ 3228 │ 44658301 │
│ 38230 │ 42045932 │
│ 145263 │ 42042158 │
│ 91244 │ 38297270 │
│ 154139 │ 26647572 │
│ 150748 │ 24112755 │
│ 242232 │ 21302571 │
│ 338158 │ 13507087 │
│ 62180 │ 12229491 │
│ 82264 │ 12187441 │
│ 232261 │ 12148031 │
│ 146272 │ 11438516 │
│ 168777 │ 11403636 │
│ 4120072 │ 11227824 │
│ 10938808 │ 10519739 │
│ 74088 │ 9047015 │
│ 115079 │ 8837972 │
│ 337234 │ 8205961 │
└───────────┴──────────┘
20 rows in set. Elapsed: 0.153 sec. Processed 1.00 billion rows, 4.00 GB (6.53 billion rows/s., 26.10 GB/s.)
:)
```
2. For CPU.
Since executing a query requires processing a large number of rows, it helps to dispatch all operations for entire vectors instead of for separate rows, or to implement the query engine so that there is almost no dispatching cost. If you don't do this, with any half-decent disk subsystem, the query interpreter inevitably stalls the CPU.
It makes sense to both store data in columns and process it, when possible, by columns.
There are two ways to do this:
1. A vector engine. All operations are written for vectors, instead of for separate values. This means you don't need to call operations very often, and dispatching costs are negligible. Operation code contains an optimized internal cycle.
2. Code generation. The code generated for the query has all the indirect calls in it.
This is not done in "normal" databases, because it doesn't make sense when running simple queries. However, there are exceptions. For example, MemSQL uses code generation to reduce latency when processing SQL queries. (For comparison, analytical DBMSs require optimization of throughput, not latency.)
Note that for CPU efficiency, the query language must be declarative (SQL or MDX), or at least a vector (J, K). The query should only contain implicit loops, allowing for optimization.

10
docs/en/interfaces/index.md
View File

@ -2,12 +2,4 @@
# Interfaces
To explore the system's capabilities, download data to tables, or make manual queries, use the clickhouse-client program.
```eval_rst
.. toctree::
:glob:
*
```
To explore the system's capabilities, download data to tables, or make manual queries, use the clickhouse-client program.

12
docs/en/introduction/index.md
View File

@ -1,13 +1 @@
# Introduction
```eval_rst
.. toctree::
what_is_clickhouse
distinctive_features
features_considered_disadvantages
ya_metrika_task
possible_silly_questions
performance
```

123
docs/en/introduction/what_is_clickhouse.md
View File

@ -1,123 +0,0 @@
# What is ClickHouse?
ClickHouse is a columnar DBMS for OLAP.
In a "normal" row-oriented DBMS, data is stored in this order:
```text
5123456789123456789 1 Eurobasket - Greece - Bosnia and Herzegovina - example.com 1 2011-09-01 01:03:02 6274717 1294101174 11409 612345678912345678 0 33 6 http://www.example.com/basketball/team/123/match/456789.html http://www.example.com/basketball/team/123/match/987654.html 0 1366 768 32 10 3183 0 0 13 0\0 1 1 0 0 2011142 -1 0 0 01321 613 660 2011-09-01 08:01:17 0 0 0 0 utf-8 1466 0 0 0 5678901234567890123 277789954 0 0 0 0 0
5234985259563631958 0 Consulting, Tax assessment, Accounting, Law 1 2011-09-01 01:03:02 6320881 2111222333 213 6458937489576391093 0 3 2 http://www.example.ru/ 0 800 600 16 10 2 153.1 0 0 10 63 1 1 0 0 2111678 000 0 588 368 240 2011-09-01 01:03:17 4 0 60310 0 windows-1251 1466 0 000 778899001 0 0 0 0 0
...
```
In order words, all the values related to a row are stored next to each other.
Examples of a row-oriented DBMS are MySQL, Postgres, MS SQL Server, and others.
In a column-oriented DBMS, data is stored like this:
```text
WatchID: 5385521489354350662 5385521490329509958 5385521489953706054 5385521490476781638 5385521490583269446 5385521490218868806 5385521491437850694 5385521491090174022 5385521490792669254 5385521490420695110 5385521491532181574 5385521491559694406 5385521491459625030 5385521492275175494 5385521492781318214 5385521492710027334 5385521492955615302 5385521493708759110 5385521494506434630 5385521493104611398
JavaEnable: 1 0 1 0 0 0 1 0 1 1 1 1 1 1 0 1 0 0 1 1
Title: Yandex Announcements - Investor Relations - Yandex Yandex — Contact us — Moscow Yandex — Mission Ru Yandex — History — History of Yandex Yandex Financial Releases - Investor Relations - Yandex Yandex — Locations Yandex Board of Directors - Corporate Governance - Yandex Yandex — Technologies
GoodEvent: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
EventTime: 2016-05-18 05:19:20 2016-05-18 08:10:20 2016-05-18 07:38:00 2016-05-18 01:13:08 2016-05-18 00:04:06 2016-05-18 04:21:30 2016-05-18 00:34:16 2016-05-18 07:35:49 2016-05-18 11:41:59 2016-05-18 01:13:32
```
These examples only show the order that data is arranged in.
The values from different columns are stored separately, and data from the same column is stored together.
Examples of column-oriented DBMSs: `Vertica`, `Paraccel (Actian Matrix) (Amazon Redshift)`, `Sybase IQ`, `Exasol`, `Infobright`, `InfiniDB`, `MonetDB (VectorWise) (Actian Vector)`, `LucidDB`, `SAP HANA`, `Google Dremel`, `Google PowerDrill`, `Druid`, `kdb+`, and so on.
Different orders for storing data are better suited to different scenarios.
The data access scenario refers to what queries are made, how often, and in what proportion; how much data is read for each type of query – rows, columns, and bytes; the relationship between reading and updating data; the working size of the data and how locally it is used; whether transactions are used, and how isolated they are; requirements for data replication and logical integrity; requirements for latency and throughput for each type of query, and so on.
The higher the load on the system, the more important it is to customize the system to the scenario, and the more specific this customization becomes. There is no system that is equally well-suited to significantly different scenarios. If a system is adaptable to a wide set of scenarios, under a high load, the system will handle all the scenarios equally poorly, or will work well for just one of the scenarios.
We'll say that the following is true for the OLAP (online analytical processing) scenario:
- The vast majority of requests are for read access.
- Data is updated in fairly large batches (> 1000 rows), not by single rows; or it is not updated at all.
- Data is added to the DB but is not modified.
- For reads, quite a large number of rows are extracted from the DB, but only a small subset of columns.
- Tables are "wide," meaning they contain a large number of columns.
- Queries are relatively rare (usually hundreds of queries per server or less per second).
- For simple queries, latencies around 50 ms are allowed.
- Column values are fairly small: numbers and short strings (for example, 60 bytes per URL).
- Requires high throughput when processing a single query (up to billions of rows per second per server).
- There are no transactions.
- Low requirements for data consistency.
- There is one large table per query. All tables are small, except for one.
- A query result is significantly smaller than the source data. In other words, data is filtered or aggregated. The result fits in a single server's RAM.
It is easy to see that the OLAP scenario is very different from other popular scenarios (such as OLTP or Key-Value access). So it doesn't make sense to try to use OLTP or a Key-Value DB for processing analytical queries if you want to get decent performance. For example, if you try to use MongoDB or Elliptics for analytics, you will get very poor performance compared to OLAP databases.
Columnar-oriented databases are better suited to OLAP scenarios (at least 100 times better in processing speed for most queries), for the following reasons:
1. For I/O.
2. For an analytical query, only a small number of table columns need to be read. In a column-oriented database, you can read just the data you need. For example, if you need 5 columns out of 100, you can expect a 20-fold reduction in I/O.
3. Since data is read in packets, it is easier to compress. Data in columns is also easier to compress. This further reduces the I/O volume.
4. Due to the reduced I/O, more data fits in the system cache.
For example, the query "count the number of records for each advertising platform" requires reading one "advertising platform ID" column, which takes up 1 byte uncompressed. If most of the traffic was not from advertising platforms, you can expect at least 10-fold compression of this column. When using a quick compression algorithm, data decompression is possible at a speed of at least several gigabytes of uncompressed data per second. In other words, this query can be processed at a speed of approximately several billion rows per second on a single server. This speed is actually achieved in practice.
Example:
```bash
milovidov@hostname:~$ clickhouse-client
ClickHouse client version 0.0.52053.
Connecting to localhost:9000.
Connected to ClickHouse server version 0.0.52053.
:) SELECT CounterID, count() FROM hits GROUP BY CounterID ORDER BY count() DESC LIMIT 20
SELECT
CounterID,
count()
FROM hits
GROUP BY CounterID
ORDER BY count() DESC
LIMIT 20
┌─CounterID─┬──count()─┐
│ 114208 │ 56057344 │
│ 115080 │ 51619590 │
│ 3228 │ 44658301 │
│ 38230 │ 42045932 │
│ 145263 │ 42042158 │
│ 91244 │ 38297270 │
│ 154139 │ 26647572 │
│ 150748 │ 24112755 │
│ 242232 │ 21302571 │
│ 338158 │ 13507087 │
│ 62180 │ 12229491 │
│ 82264 │ 12187441 │
│ 232261 │ 12148031 │
│ 146272 │ 11438516 │
│ 168777 │ 11403636 │
│ 4120072 │ 11227824 │
│ 10938808 │ 10519739 │
│ 74088 │ 9047015 │
│ 115079 │ 8837972 │
│ 337234 │ 8205961 │
└───────────┴──────────┘
20 rows in set. Elapsed: 0.153 sec. Processed 1.00 billion rows, 4.00 GB (6.53 billion rows/s., 26.10 GB/s.)
:)
```
2. For CPU.
Since executing a query requires processing a large number of rows, it helps to dispatch all operations for entire vectors instead of for separate rows, or to implement the query engine so that there is almost no dispatching cost. If you don't do this, with any half-decent disk subsystem, the query interpreter inevitably stalls the CPU.
It makes sense to both store data in columns and process it, when possible, by columns.
There are two ways to do this:
1. A vector engine. All operations are written for vectors, instead of for separate values. This means you don't need to call operations very often, and dispatching costs are negligible. Operation code contains an optimized internal cycle.
2. Code generation. The code generated for the query has all the indirect calls in it.
This is not done in "normal" databases, because it doesn't make sense when running simple queries. However, there are exceptions. For example, MemSQL uses code generation to reduce latency when processing SQL queries. (For comparison, analytical DBMSs require optimization of throughput, not latency.)
Note that for CPU efficiency, the query language must be declarative (SQL or MDX), or at least a vector (J, K). The query should only contain implicit loops, allowing for optimization.

9
docs/en/operations/index.md
View File

@ -1,10 +1 @@
# Operation
```eval_rst
.. toctree::
:glob:
*
*/index
```

8
docs/en/operations/server_settings/index.md
View File

@ -9,11 +9,3 @@ These settings are stored in the ` config.xml` file on the ClickHouse server.
Other settings are described in the "[Settings](../settings/index.md#settings)" section.
Before studying the settings, read the [Configuration files](../configuration_files.md#configuration_files) section and note the use of substitutions (the `incl` and `optional` attributes).
```eval_rst
.. toctree::
:glob:
*
```

7
docs/en/operations/settings/index.md
View File

@ -22,10 +22,3 @@ Similarly, you can use ClickHouse sessions in the HTTP protocol. To do this, you
Settings that can only be made in the server config file are not covered in this section.
```eval_rst
.. toctree::
:glob:
*
```

8
docs/en/query_language/index.md
View File

@ -1,9 +1 @@
# Query language
```eval_rst
.. toctree::
:glob:
*
```

3
docs/en/query_language/queries.md
View File

@ -11,6 +11,9 @@ CREATE DATABASE [IF NOT EXISTS] db_name
`A database` is just a directory for tables.
If `IF NOT EXISTS` is included, the query won't return an error if the database already exists.
<a name="query_language-queries-create_table"></a>
## CREATE TABLE
The `CREATE TABLE` query can have several forms.

7
docs/en/system_tables/index.md
View File

@ -6,10 +6,3 @@ System tables don't have files with data on the disk or files with metadata. The
System tables are read-only.
System tables are located in the 'system' database.
```eval_rst
.. toctree::
:glob:
*
```

7
docs/en/table_engines/index.md
View File

@ -12,10 +12,3 @@ The table engine (type of table) determines:
Note that for most serious tasks, you should use engines from the MergeTree family.
```eval_rst
.. toctree::
:glob:
*
```

2
docs/en/table_engines/materializedview.md
View File

@ -1,4 +1,4 @@
# MaterializedView
Used for implementing materialized views (for more information, see `CREATE MATERIALIZED VIEW`). For storing data, it uses a different engine that was specified when creating the view. When reading from a table, it just uses this engine.
Used for implementing materialized views (for more information, see [CREATE TABLE](../query_language/queries.md#query_language-queries-create_table)). For storing data, it uses a different engine that was specified when creating the view. When reading from a table, it just uses this engine.

7
docs/en/table_functions/index.md
View File

@ -4,10 +4,3 @@ Table functions can be specified in the FROM clause instead of the database and
Table functions can only be used if 'readonly' is not set.
Table functions aren't related to other functions.
```eval_rst
.. toctree::
:glob:
*
```

BIN
docs/mkdocs-material-theme/assets/images/Copy (1) favicon.ico
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 1.1 KiB

BIN
docs/mkdocs-material-theme/assets/images/Copy (1) favicon.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 521 B

BIN
docs/mkdocs-material-theme/assets/images/favicon.ico
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1.1 KiB

After

Width:  |  Height:  |  Size: 171 B

BIN
docs/mkdocs-material-theme/assets/images/favicon.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 521 B

BIN
docs/mkdocs-material-theme/assets/images/logo.ico
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 17 KiB

12
docs/mkdocs-material-theme/assets/images/logo.svg
View File

@ -1,12 +0,0 @@
<svg xmlns="http://www.w3.org/2000/svg" width="54" height="48" viewBox="0 0 9 8">
<style>
.o{fill:#fc0}
.r{fill:#f00}
</style>
<path class="r" d="M0,7 h1 v1 h-1 z"/>
<path class="o" d="M0,0 h1 v7 h-1 z"/>
<path class="o" d="M2,0 h1 v8 h-1 z"/>
<path class="o" d="M4,0 h1 v8 h-1 z"/>
<path class="o" d="M6,0 h1 v8 h-1 z"/>
<path class="o" d="M8,3.25 h1 v1.5 h-1 z"/>
</svg>
Side by Side

Before

Width:  |  Height:  |  Size: 421 B

BIN
docs/mkdocs-material-theme/assets/images/logo_ch.ico
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 4.2 KiB

31
docs/mkdocs-material-theme/partials/header.html
View File

@ -1,4 +1,35 @@
<header class="md-header" data-md-component="header">
<!-- Yandex.Metrika counter -->
<script type="text/javascript">
(function (d, w, c) {
(w[c] = w[c] || []).push(function() {
try {
w.yaCounter18343495 = new Ya.Metrika2({
id:18343495,
clickmap:true,
trackLinks:true,
accurateTrackBounce:true,
webvisor: {% if builder != "singlehtml" %}true{% else %}false{% endif %}
});
} catch(e) { }
});
var n = d.getElementsByTagName("script")[0],
s = d.createElement("script"),
f = function () { n.parentNode.insertBefore(s, n); };
s.type = "text/javascript";
s.async = true;
s.src = "https://mc.yandex.ru/metrika/tag.js";
if (w.opera == "[object Opera]") {
d.addEventListener("DOMContentLoaded", f, false);
} else { f(); }
})(document, window, "yandex_metrika_callbacks2");
</script>
<noscript>
<div><img src="https://mc.yandex.ru/watch/18343495" style="position:absolute; left:-9999px;" alt=""/></div>
</noscript>
<!-- /Yandex.Metrika counter -->
<nav class="md-header-nav md-grid">
<div class="md-flex">
<div class="md-flex__cell md-flex__cell--shrink">

9
docs/mkdocs_en.yml
View File

@ -21,7 +21,7 @@ theme:
text: Roboto
code: Roboto Mono
logo: 'images/logo.svg'
favicon: 'assets/images/logo_ch.ico'
favicon: 'assets/images/favicon.ico'
include_search_page: false
search_index_only: true
static_templates:
@ -34,11 +34,10 @@ extra:
pages:
- 'Contents': 'index.md'
- 'ClickHouse': 'index.md'
- 'Introduction':
# - 'Введение': 'introduction/index.md'
- 'What is ClickHouse?': 'introduction/what_is_clickhouse.md'
- 'Distinctive features of ClickHouse': 'introduction/distinctive_features.md'
- 'ClickHouse features that can be considered disadvantages': 'introduction/features_considered_disadvantages.md'
- 'The Yandex.Metrica task': 'introduction/ya_metrika_task.md'
@ -65,7 +64,7 @@ pages:
- 'Visual interfaces from third-party developers': 'interfaces/third-party_gui.md'
- 'Query language':
- 'Query language': 'query_language/index.md'
# - 'Query language': 'query_language/index.md'
- 'Queries': 'query_language/queries.md'
- 'Syntax': 'query_language/syntax.md'
- 'The clickhouse-local program': 'query_language/clickhouse_local.md'
@ -147,7 +146,7 @@ pages:
- 'XML': 'formats/xml.md'
- 'Data types':
# - 'Типы данных': 'data_types/index.md'
- 'Introduction': 'data_types/index.md'
- 'Array(T)': 'data_types/array.md'
- 'Boolean values': 'data_types/boolean.md'
- 'Date': 'data_types/date.md'

7
docs/mkdocs_ru.yml
View File

@ -21,7 +21,7 @@ theme:
text: Roboto
code: Roboto Mono
logo: 'images/logo.svg'
favicon: 'assets/images/logo_ch.ico'
favicon: 'assets/images/favicon.ico'
include_search_page: false
search_index_only: true
static_templates:
@ -34,11 +34,10 @@ extra:
pages:
- 'Оглавление': 'index.md'
- 'ClickHouse': 'index.md'
- 'Введение':
# - 'Введение': 'introduction/index.md'
- 'Что такое ClickHouse': 'introduction/what_is_clickhouse.md'
- 'Отличительные возможности ClickHouse': 'introduction/distinctive_features.md'
- 'Особенности ClickHouse, которые могут считаться недостатками': 'introduction/features_considered_disadvantages.md'
- 'Постановка задачи в Яндекс.Метрике': 'introduction/ya_metrika_task.md'
@ -148,7 +147,7 @@ pages:
- 'XML': 'formats/xml.md'
- 'Типы данных':
# - 'Типы данных': 'data_types/index.md'
- 'Введение': 'data_types/index.md'
- 'Array(T)': 'data_types/array.md'
- 'Булевы значения': 'data_types/boolean.md'
- 'Date': 'data_types/date.md'

10
docs/ru/agg_functions/index.md
View File

@ -8,13 +8,3 @@ ClickHouse поддерживает также:
- [Параметрические агрегатные функции](parametric_functions.md#aggregate_functions_parametric), которые помимо стоблцов принимаю и другие параметры.
- [Комбинаторы](combinators.md#aggregate_functions_combinators), которые изменяют поведение агрегатных фунций.
**Оглавление раздела**
```eval_rst
.. toctree::
reference
parametric_functions
combinators
```

9
docs/ru/data_types/index.md
View File

@ -2,11 +2,6 @@
# Типы данных
```eval_rst
.. toctree::
:glob:
ClickHouse может сохранять в ячейках таблиц данные различных типов.
*
*/index
```
Раздел содержит описания поддерживаемых типов данных и специфику их использования и/или реализации, если таковые имеются.

9
docs/ru/data_types/nested_data_structures/index.md
View File

@ -1,8 +1 @@
# Вложенные структуры данных
```eval_rst
.. toctree::
:glob:
*
```
# Вложенные структуры данных

7
docs/ru/data_types/special_data_types/index.md
View File

@ -1,10 +1,3 @@
# Служебные типы данных
Значения служебных типов данных не могут сохраняться в таблицу и выводиться в качестве результата, а возникают как промежуточный результат выполнения запроса.
```eval_rst
.. toctree::
:glob:
*
```

7
docs/ru/development/index.md
View File

@ -1,8 +1 @@
# ClickHouse Development
```eval_rst
.. toctree::
:glob:
*
```

8
docs/ru/dicts/index.md
View File

@ -4,11 +4,3 @@
Это можно рассматривать как более удобный и максимально эффективный вариант JOIN-а с таблицами-справочниками (dimension tables).
Существуют встроенные и подключаемые (внешние) словари.
```eval_rst
.. toctree::
external_dicts
internal_dicts
```

7
docs/ru/formats/index.md
View File

@ -3,10 +3,3 @@
# Форматы
Формат определяет, в каком виде данные отдаются вам (пишутся, форматируются сервером) при SELECT-е и в каком виде принимаются (читаются, парсятся сервером) при INSERT-е.
```eval_rst
.. toctree::
:glob:
*
```

7
docs/ru/functions/index.md
View File

@ -6,13 +6,6 @@
\* - есть ещё третий вид функций, к которым относится функция arrayJoin; также можно отдельно иметь ввиду табличные функции.\*
```eval_rst
.. toctree::
:glob:
*
```
## Строгая типизация
В ClickHouse, в отличие от стандартного SQL, типизация является строгой. То есть, не производится неявных преобразований между типами. Все функции работают для определённого набора типов. Это значит, что иногда вам придётся использовать функции преобразования типов.

9
docs/ru/getting_started/index.md
View File

@ -135,11 +135,4 @@ SELECT 1
**Поздравляем, система работает!**
Для дальнейших экспериментов можно попробовать загрузить из тестовых наборов данных:
```eval_rst
.. toctree::
:glob:
example_datasets/*
```
Для дальнейших экспериментов можно попробовать загрузить из тестовых наборов данных.

143
docs/ru/index.md
View File

@ -1,23 +1,122 @@
# Документация
# Что такое ClickHouse
```eval_rst
.. toctree::
:maxdepth: 6
introduction/index
getting_started/index
interfaces/index
query_language/index
table_engines/index
system_tables/index
table_functions/index
formats/index
data_types/index
operators/index
functions/index
agg_functions/index
dicts/index
operations/index
development/index
roadmap
```
ClickHouse - столбцовая СУБД для OLAP (Columnar DBMS).
В обычной, "строковой" СУБД, данные хранятся в таком порядке:
```text
5123456789123456789 1 Eurobasket - Greece - Bosnia and Herzegovina - example.com 1 2011-09-01 01:03:02 6274717 1294101174 11409 612345678912345678 0 33 6 http://www.example.com/basketball/team/123/match/456789.html http://www.example.com/basketball/team/123/match/987654.html 0 1366 768 32 10 3183 0 0 13 0\0 1 1 0 0 2011142 -1 0 0 01321 613 660 2011-09-01 08:01:17 0 0 0 0 utf-8 1466 0 0 0 5678901234567890123 277789954 0 0 0 0 0
5234985259563631958 0 Consulting, Tax assessment, Accounting, Law 1 2011-09-01 01:03:02 6320881 2111222333 213 6458937489576391093 0 3 2 http://www.example.ru/ 0 800 600 16 10 2 153.1 0 0 10 63 1 1 0 0 2111678 000 0 588 368 240 2011-09-01 01:03:17 4 0 60310 0 windows-1251 1466 0 000 778899001 0 0 0 0 0
...
```
То есть, значения, относящиеся к одной строке, хранятся рядом.
Примеры строковых СУБД: MySQL, Postgres, MS SQL Server и т. п.
В столбцовых СУБД, данные хранятся в таком порядке:
```text
WatchID: 5385521489354350662 5385521490329509958 5385521489953706054 5385521490476781638 5385521490583269446 5385521490218868806 5385521491437850694 5385521491090174022 5385521490792669254 5385521490420695110 5385521491532181574 5385521491559694406 5385521491459625030 5385521492275175494 5385521492781318214 5385521492710027334 5385521492955615302 5385521493708759110 5385521494506434630 5385521493104611398
JavaEnable: 1 0 1 0 0 0 1 0 1 1 1 1 1 1 0 1 0 0 1 1
Title: Yandex Announcements - Investor Relations - Yandex Yandex — Contact us — Moscow Yandex — Mission Ru Yandex — History — History of Yandex Yandex Financial Releases - Investor Relations - Yandex Yandex — Locations Yandex Board of Directors - Corporate Governance - Yandex Yandex — Technologies
GoodEvent: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
EventTime: 2016-05-18 05:19:20 2016-05-18 08:10:20 2016-05-18 07:38:00 2016-05-18 01:13:08 2016-05-18 00:04:06 2016-05-18 04:21:30 2016-05-18 00:34:16 2016-05-18 07:35:49 2016-05-18 11:41:59 2016-05-18 01:13:32
```
В примерах изображён только порядок расположения данных.
То есть, значения из разных столбцов хранятся отдельно, а данные одного столбца - вместе.
Примеры столбцовых СУБД: `Vertica`, `Paraccel (Actian Matrix) (Amazon Redshift)`, `Sybase IQ`, `Exasol`, `Infobright`, `InfiniDB`, `MonetDB (VectorWise) (Actian Vector)`, `LucidDB`, `SAP HANA`, `Google Dremel`, `Google PowerDrill`, `Druid`, `kdb+` и т. п.
Разный порядок хранения данных лучше подходит для разных сценариев работы.
Сценарий работы с данными - это то, какие производятся запросы, как часто и в каком соотношении; сколько читается данных на запросы каждого вида - строк, столбцов, байт; как соотносятся чтения и обновления данных; какой рабочий размер данных и насколько локально он используется; используются ли транзакции и с какой изолированностью; какие требования к дублированию данных и логической целостности; требования к задержкам на выполнение и пропускной способности запросов каждого вида и т. п.
Чем больше нагрузка на систему, тем более важной становится специализация под сценарий работы, и тем более конкретной становится эта специализация. Не существует системы, одинаково хорошо подходящей под существенно различные сценарии работы. Если система подходит под широкое множество сценариев работы, то при достаточно большой нагрузке, система будет справляться со всеми сценариями работы плохо, или справляться хорошо только с одним из сценариев работы.
Будем говорить, что OLAP (онлайн обработка аналитических запросов) сценарий работы - это:
- подавляющее большинство запросов - на чтение;
- данные обновляются достаточно большими пачками (> 1000 строк), а не по одной строке, или не обновляются вообще;
- данные добавляются в БД, но не изменяются;
- при чтении, вынимается достаточно большое количество строк из БД, но только небольшое подмножество столбцов;
- таблицы являются "широкими", то есть, содержат большое количество столбцов;
- запросы идут сравнительно редко (обычно не более сотни в секунду на сервер);
- при выполнении простых запросов, допустимы задержки в районе 50 мс;
- значения в столбцах достаточно мелкие - числа и небольшие строки (пример - 60 байт на URL);
- требуется высокая пропускная способность при обработке одного запроса (до миллиардов строк в секунду на один сервер);
- транзакции отсутствуют;
- низкие требования к консистентности данных;
- в запросе одна большая таблица, все таблицы кроме одной маленькие;
- результат выполнения запроса существенно меньше исходных данных - то есть, данные фильтруются или агрегируются; результат выполнения помещается в оперативку на одном сервере;
Легко видеть, что OLAP сценарий работы существенно отличается от других распространённых сценариев работы (например, OLTP или Key-Value сценариев работы). Таким образом, не имеет никакого смысла пытаться использовать OLTP или Key-Value БД для обработки аналитических запросов, если вы хотите получить приличную производительность ("выше плинтуса"). Например, если вы попытаетесь использовать для аналитики MongoDB или Elliptics - вы получите анекдотически низкую производительность по сравнению с OLAP-СУБД.
Столбцовые СУБД лучше (от 100 раз по скорости обработки большинства запросов) подходят для OLAP сценария работы по следующим причинам:
1. По I/O.
2. Для выполнения аналитического запроса, требуется прочитать небольшое количество столбцов таблицы. В столбцовой БД для этого можно читать только нужные данные. Например, если вам требуется только 5 столбцов из 100, то следует рассчитывать на 20-кратное уменьшение ввода-вывода.
3. Так как данные читаются пачками, то их проще сжимать. Данные, лежащие по столбцам также лучше сжимаются. За счёт этого, дополнительно уменьшается объём ввода-вывода.
4. За счёт уменьшения ввода-вывода, больше данных влезает в системный кэш.
Для примера, для запроса "посчитать количество записей для каждой рекламной системы", требуется прочитать один столбец "идентификатор рекламной системы", который занимает 1 байт в несжатом виде. Если большинство переходов было не с рекламных систем, то можно рассчитывать хотя бы на десятикратное сжатие этого столбца. При использовании быстрого алгоритма сжатия, возможно разжатие данных со скоростью более нескольких гигабайт несжатых данных в секунду. То есть, такой запрос может выполняться со скоростью около нескольких миллиардов строк в секунду на одном сервере. На практике, такая скорость действительно достигается.
Пример:
```bash
milovidov@hostname:~$ clickhouse-client
ClickHouse client version 0.0.52053.
Connecting to localhost:9000.
Connected to ClickHouse server version 0.0.52053.
:) SELECT CounterID, count() FROM hits GROUP BY CounterID ORDER BY count() DESC LIMIT 20
SELECT
CounterID,
count()
FROM hits
GROUP BY CounterID
ORDER BY count() DESC
LIMIT 20
┌─CounterID─┬──count()─┐
│ 114208 │ 56057344 │
│ 115080 │ 51619590 │
│ 3228 │ 44658301 │
│ 38230 │ 42045932 │
│ 145263 │ 42042158 │
│ 91244 │ 38297270 │
│ 154139 │ 26647572 │
│ 150748 │ 24112755 │
│ 242232 │ 21302571 │
│ 338158 │ 13507087 │
│ 62180 │ 12229491 │
│ 82264 │ 12187441 │
│ 232261 │ 12148031 │
│ 146272 │ 11438516 │
│ 168777 │ 11403636 │
│ 4120072 │ 11227824 │
│ 10938808 │ 10519739 │
│ 74088 │ 9047015 │
│ 115079 │ 8837972 │
│ 337234 │ 8205961 │
└───────────┴──────────┘
20 rows in set. Elapsed: 0.153 sec. Processed 1.00 billion rows, 4.00 GB (6.53 billion rows/s., 26.10 GB/s.)
:)
```
2. По CPU.
Так как для выполнения запроса надо обработать достаточно большое количество строк, становится актуальным диспетчеризовывать все операции не для отдельных строк, а для целых векторов, или реализовать движок выполнения запроса так, чтобы издержки на диспетчеризацию были примерно нулевыми. Если этого не делать, то при любой не слишком плохой дисковой подсистеме, интерпретатор запроса неизбежно упрётся в CPU.
Имеет смысл не только хранить данные по столбцам, но и обрабатывать их, по возможности, тоже по столбцам.
Есть два способа это сделать:
1. Векторный движок. Все операции пишутся не для отдельных значений, а для векторов. То есть, вызывать операции надо достаточно редко, и издержки на диспетчеризацию становятся пренебрежимо маленькими. Код операции содержит в себе хорошо оптимизированный внутренний цикл.
2. Кодогенерация. Для запроса генерируется код, в котором подставлены все косвенные вызовы.
В "обычных" БД этого не делается, так как не имеет смысла при выполнении простых запросов. Хотя есть исключения. Например, в MemSQL кодогенерация используется для уменьшения latency при выполнении SQL запросов. (Для сравнения - в аналитических СУБД, требуется оптимизация throughput, а не latency).
Стоит заметить, что для эффективности по CPU требуется, чтобы язык запросов был декларативным (SQL, MDX) или хотя бы векторным (J, K). То есть, чтобы запрос содержал циклы только в неявном виде, открывая возможности для оптимизации.

7
docs/ru/interfaces/index.md
View File

@ -3,10 +3,3 @@
# Интерфейсы
Для изучения возможностей системы, загрузки данных в таблицы, ручных запросов, используйте программу clickhouse-client.
```eval_rst
.. toctree::
:glob:
*
```

12
docs/ru/introduction/index.md
View File

@ -1,13 +1 @@
# Введение
```eval_rst
.. toctree::
what_is_clickhouse
distinctive_features
features_considered_disadvantages
ya_metrika_task
possible_silly_questions
performance
```

122
docs/ru/introduction/what_is_clickhouse.md
View File

@ -1,122 +0,0 @@
# Что такое ClickHouse
ClickHouse - столбцовая СУБД для OLAP (Columnar DBMS).
В обычной, "строковой" СУБД, данные хранятся в таком порядке:
```text
5123456789123456789 1 Eurobasket - Greece - Bosnia and Herzegovina - example.com 1 2011-09-01 01:03:02 6274717 1294101174 11409 612345678912345678 0 33 6 http://www.example.com/basketball/team/123/match/456789.html http://www.example.com/basketball/team/123/match/987654.html 0 1366 768 32 10 3183 0 0 13 0\0 1 1 0 0 2011142 -1 0 0 01321 613 660 2011-09-01 08:01:17 0 0 0 0 utf-8 1466 0 0 0 5678901234567890123 277789954 0 0 0 0 0
5234985259563631958 0 Consulting, Tax assessment, Accounting, Law 1 2011-09-01 01:03:02 6320881 2111222333 213 6458937489576391093 0 3 2 http://www.example.ru/ 0 800 600 16 10 2 153.1 0 0 10 63 1 1 0 0 2111678 000 0 588 368 240 2011-09-01 01:03:17 4 0 60310 0 windows-1251 1466 0 000 778899001 0 0 0 0 0
...
```
То есть, значения, относящиеся к одной строке, хранятся рядом.
Примеры строковых СУБД: MySQL, Postgres, MS SQL Server и т. п.
В столбцовых СУБД, данные хранятся в таком порядке:
```text
WatchID: 5385521489354350662 5385521490329509958 5385521489953706054 5385521490476781638 5385521490583269446 5385521490218868806 5385521491437850694 5385521491090174022 5385521490792669254 5385521490420695110 5385521491532181574 5385521491559694406 5385521491459625030 5385521492275175494 5385521492781318214 5385521492710027334 5385521492955615302 5385521493708759110 5385521494506434630 5385521493104611398
JavaEnable: 1 0 1 0 0 0 1 0 1 1 1 1 1 1 0 1 0 0 1 1
Title: Yandex Announcements - Investor Relations - Yandex Yandex — Contact us — Moscow Yandex — Mission Ru Yandex — History — History of Yandex Yandex Financial Releases - Investor Relations - Yandex Yandex — Locations Yandex Board of Directors - Corporate Governance - Yandex Yandex — Technologies
GoodEvent: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
EventTime: 2016-05-18 05:19:20 2016-05-18 08:10:20 2016-05-18 07:38:00 2016-05-18 01:13:08 2016-05-18 00:04:06 2016-05-18 04:21:30 2016-05-18 00:34:16 2016-05-18 07:35:49 2016-05-18 11:41:59 2016-05-18 01:13:32
```
В примерах изображён только порядок расположения данных.
То есть, значения из разных столбцов хранятся отдельно, а данные одного столбца - вместе.
Примеры столбцовых СУБД: `Vertica`, `Paraccel (Actian Matrix) (Amazon Redshift)`, `Sybase IQ`, `Exasol`, `Infobright`, `InfiniDB`, `MonetDB (VectorWise) (Actian Vector)`, `LucidDB`, `SAP HANA`, `Google Dremel`, `Google PowerDrill`, `Druid`, `kdb+` и т. п.
Разный порядок хранения данных лучше подходит для разных сценариев работы.
Сценарий работы с данными - это то, какие производятся запросы, как часто и в каком соотношении; сколько читается данных на запросы каждого вида - строк, столбцов, байт; как соотносятся чтения и обновления данных; какой рабочий размер данных и насколько локально он используется; используются ли транзакции и с какой изолированностью; какие требования к дублированию данных и логической целостности; требования к задержкам на выполнение и пропускной способности запросов каждого вида и т. п.
Чем больше нагрузка на систему, тем более важной становится специализация под сценарий работы, и тем более конкретной становится эта специализация. Не существует системы, одинаково хорошо подходящей под существенно различные сценарии работы. Если система подходит под широкое множество сценариев работы, то при достаточно большой нагрузке, система будет справляться со всеми сценариями работы плохо, или справляться хорошо только с одним из сценариев работы.
Будем говорить, что OLAP (онлайн обработка аналитических запросов) сценарий работы - это:
- подавляющее большинство запросов - на чтение;
- данные обновляются достаточно большими пачками (> 1000 строк), а не по одной строке, или не обновляются вообще;
- данные добавляются в БД, но не изменяются;
- при чтении, вынимается достаточно большое количество строк из БД, но только небольшое подмножество столбцов;
- таблицы являются "широкими", то есть, содержат большое количество столбцов;
- запросы идут сравнительно редко (обычно не более сотни в секунду на сервер);
- при выполнении простых запросов, допустимы задержки в районе 50 мс;
- значения в столбцах достаточно мелкие - числа и небольшие строки (пример - 60 байт на URL);
- требуется высокая пропускная способность при обработке одного запроса (до миллиардов строк в секунду на один сервер);
- транзакции отсутствуют;
- низкие требования к консистентности данных;
- в запросе одна большая таблица, все таблицы кроме одной маленькие;
- результат выполнения запроса существенно меньше исходных данных - то есть, данные фильтруются или агрегируются; результат выполнения помещается в оперативку на одном сервере;
Легко видеть, что OLAP сценарий работы существенно отличается от других распространённых сценариев работы (например, OLTP или Key-Value сценариев работы). Таким образом, не имеет никакого смысла пытаться использовать OLTP или Key-Value БД для обработки аналитических запросов, если вы хотите получить приличную производительность ("выше плинтуса"). Например, если вы попытаетесь использовать для аналитики MongoDB или Elliptics - вы получите анекдотически низкую производительность по сравнению с OLAP-СУБД.
Столбцовые СУБД лучше (от 100 раз по скорости обработки большинства запросов) подходят для OLAP сценария работы по следующим причинам:
1. По I/O.
2. Для выполнения аналитического запроса, требуется прочитать небольшое количество столбцов таблицы. В столбцовой БД для этого можно читать только нужные данные. Например, если вам требуется только 5 столбцов из 100, то следует рассчитывать на 20-кратное уменьшение ввода-вывода.
3. Так как данные читаются пачками, то их проще сжимать. Данные, лежащие по столбцам также лучше сжимаются. За счёт этого, дополнительно уменьшается объём ввода-вывода.
4. За счёт уменьшения ввода-вывода, больше данных влезает в системный кэш.
Для примера, для запроса "посчитать количество записей для каждой рекламной системы", требуется прочитать один столбец "идентификатор рекламной системы", который занимает 1 байт в несжатом виде. Если большинство переходов было не с рекламных систем, то можно рассчитывать хотя бы на десятикратное сжатие этого столбца. При использовании быстрого алгоритма сжатия, возможно разжатие данных со скоростью более нескольких гигабайт несжатых данных в секунду. То есть, такой запрос может выполняться со скоростью около нескольких миллиардов строк в секунду на одном сервере. На практике, такая скорость действительно достигается.
Пример:
```bash
milovidov@hostname:~$ clickhouse-client
ClickHouse client version 0.0.52053.
Connecting to localhost:9000.
Connected to ClickHouse server version 0.0.52053.
:) SELECT CounterID, count() FROM hits GROUP BY CounterID ORDER BY count() DESC LIMIT 20
SELECT
CounterID,
count()
FROM hits
GROUP BY CounterID
ORDER BY count() DESC
LIMIT 20
┌─CounterID─┬──count()─┐
│ 114208 │ 56057344 │
│ 115080 │ 51619590 │
│ 3228 │ 44658301 │
│ 38230 │ 42045932 │
│ 145263 │ 42042158 │
│ 91244 │ 38297270 │
│ 154139 │ 26647572 │
│ 150748 │ 24112755 │
│ 242232 │ 21302571 │
│ 338158 │ 13507087 │
│ 62180 │ 12229491 │
│ 82264 │ 12187441 │
│ 232261 │ 12148031 │
│ 146272 │ 11438516 │
│ 168777 │ 11403636 │
│ 4120072 │ 11227824 │
│ 10938808 │ 10519739 │
│ 74088 │ 9047015 │
│ 115079 │ 8837972 │
│ 337234 │ 8205961 │
└───────────┴──────────┘
20 rows in set. Elapsed: 0.153 sec. Processed 1.00 billion rows, 4.00 GB (6.53 billion rows/s., 26.10 GB/s.)
:)
```
2. По CPU.
Так как для выполнения запроса надо обработать достаточно большое количество строк, становится актуальным диспетчеризовывать все операции не для отдельных строк, а для целых векторов, или реализовать движок выполнения запроса так, чтобы издержки на диспетчеризацию были примерно нулевыми. Если этого не делать, то при любой не слишком плохой дисковой подсистеме, интерпретатор запроса неизбежно упрётся в CPU.
Имеет смысл не только хранить данные по столбцам, но и обрабатывать их, по возможности, тоже по столбцам.
Есть два способа это сделать:
1. Векторный движок. Все операции пишутся не для отдельных значений, а для векторов. То есть, вызывать операции надо достаточно редко, и издержки на диспетчеризацию становятся пренебрежимо маленькими. Код операции содержит в себе хорошо оптимизированный внутренний цикл.
2. Кодогенерация. Для запроса генерируется код, в котором подставлены все косвенные вызовы.
В "обычных" БД этого не делается, так как не имеет смысла при выполнении простых запросов. Хотя есть исключения. Например, в MemSQL кодогенерация используется для уменьшения latency при выполнении SQL запросов. (Для сравнения - в аналитических СУБД, требуется оптимизация throughput, а не latency).
Стоит заметить, что для эффективности по CPU требуется, чтобы язык запросов был декларативным (SQL, MDX) или хотя бы векторным (J, K). То есть, чтобы запрос содержал циклы только в неявном виде, открывая возможности для оптимизации.

8
docs/ru/operations/index.md
View File

@ -1,9 +1 @@
# Эксплуатация
```eval_rst
.. toctree::
:glob:
*
*/index
```

7
docs/ru/operations/server_settings/index.md
View File

@ -9,10 +9,3 @@
Прочие настройки описаны в разделе "[Настройки](../settings/index.md#settings)".
Перед изучением настроек ознакомьтесь с разделом [Конфигурационные файлы](../configuration_files.md#configuration_files), обратите внимание на использование подстановок (атрибуты `incl` и `optional`).
```eval_rst
.. toctree::
:glob:
*
```

7
docs/ru/operations/settings/index.md
View File

@ -21,10 +21,3 @@
- При использовании HTTP API передавайте cgi-параметры (`URL?setting_1=value&setting_2=value...`).
Настройки, которые можно задать только в конфигурационном файле сервера, в разделе не рассматриваются.
```eval_rst
.. toctree::
:glob:
*
```

7
docs/ru/query_language/index.md
View File

@ -1,8 +1 @@
# Язык запросов
```eval_rst
.. toctree::
:glob:
*
```

3
docs/ru/query_language/queries.md
View File

@ -10,6 +10,9 @@ CREATE DATABASE [IF NOT EXISTS] db_name
`База данных` - это просто директория для таблиц.
Если написано `IF NOT EXISTS`, то запрос не будет возвращать ошибку, если база данных уже существует.
<a name="query_language-queries-create_table"></a>
## CREATE TABLE
Запрос `CREATE TABLE` может иметь несколько форм.

7
docs/ru/system_tables/index.md
View File

@ -5,10 +5,3 @@
Для системных таблиц нет файлов с данными на диске и файлов с метаданными. Сервер создаёт все системные таблицы при старте.
В системные таблицы нельзя записывать данные - можно только читать.
Системные таблицы расположены в базе данных system.
```eval_rst
.. toctree::
:glob:
*
```

2
docs/ru/table_engines/dictionary.md
View File

@ -60,7 +60,7 @@ WHERE name = 'products'
└──────────┴──────┴────────┴─────────────────┴─────────────────┴─────────────────┴───────────────┴─────────────────┘
```
В таком виде данные из словаря можно смотреть/использовать при помощи функций [dictGet*](../functions/ext_dict_functions.md).
В таком виде данные из словаря можно смотреть/использовать при помощи функций [dictGet*](../functions/ext_dict_functions.md#ext_dict_functions).
Это бывает не всегда угодно, когда требуется выполнять JOIN операции или просто получить данные находящиеся сейчас в словаре.
Мы можем использовать джок таблицы `Dictionary` для отображения данных словаря в таблицу.

7
docs/ru/table_engines/index.md
View File

@ -12,10 +12,3 @@
но в некоторых случаях, запрос может быть частично обработан в рамках движка таблицы.
Забегая вперёд, заметим, что для большинства серьёзных задач, следует использовать движки семейства MergeTree.
```eval_rst
.. toctree::
:glob:
*
```

2
docs/ru/table_engines/materializedview.md
View File

@ -1,3 +1,3 @@
# MaterializedView
Используется для реализации материализованных представлений (подробнее см. запрос `CREATE MATERIALIZED VIEW`). Для хранения данных, использует другой движок, который был указан при создании представления. При чтении из таблицы, просто использует этот движок.
Используется для реализации материализованных представлений (подробнее см. запрос [CREATE TABLE](../query_language/queries.md#query_language-queries-create_table)). Для хранения данных, использует другой движок, который был указан при создании представления. При чтении из таблицы, просто использует этот движок.

7
docs/ru/table_functions/index.md
View File

@ -3,10 +3,3 @@
Табличные функции могут указываться в секции FROM вместо имени БД и таблицы.
Табличные функции можно использовать только если не выставлена настройка readonly.
Табличные функции не имеют отношения к другим функциям.
```eval_rst
.. toctree::
:glob:
*
```