mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-09-19 16:20:50 +00:00
WIP on documentation (#2692)
* Additional .gitignore entries * Merge a bunch of small articles about system tables into single one * Merge a bunch of small articles about formats into single one * Adapt table with formats to English docs too * Add SPb meetup link to main page * Move Utilities out of top level of docs (the location is probably not yet final) + translate couple articles * Merge MacOS.md into build_osx.md * Move Data types higher in ToC * Publish changelog on website alongside documentation * Few fixes for en/table_engines/file.md * Use smaller header sizes in changelogs * Group up table engines inside ToC * Move table engines out of top level too * Specificy in ToC that query language is SQL based. Thats a bit excessive, but catches eye. * Move stuff that is part of query language into respective folder * Move table functions lower in ToC * Lost redirects.txt update * Do not rely on comments in yaml + fix few ru titles * Extract major parts of queries.md into separate articles * queries.md has been supposed to be removed * Fix weird translation * Fix a bunch of links * There is only table of contents left * "Query language" is actually part of SQL abbreviation * Change filename in README.md too * fix mistype * s/formats\/interfaces/interfaces\/formats/g * Remove extra clarification from header as it was too verbose, probably making it a bit more confusing * Empty article was supposed to be hidden * At least change incorrect title * Move special links to the bottom of nav and slightly highlight them * Skip hidden pages in bottom navigation too * Make front page of documentation to be part of Introduction * Make tables in introduction somewhat readable + move abbreviation definitions earlier * Some introduction text refactoring * Some docs introduction refactoring * Use admonitions instead of divs * Additional .gitignore * Treat .gif as images too * Clarify ToC item
This commit is contained in:
Ivan Blinkov
GitHub
parent
7be750afe9
commit
c7e526e050
2
.gitignore
vendored
2
.gitignore
vendored
@ -15,6 +15,8 @@
|
||||
/docs/tools/venv/
|
||||
/docs/en/development/build/
|
||||
/docs/ru/development/build/
|
||||
/docs/en/single.md
|
||||
/docs/ru/single.md
|
||||
|
||||
# callgrind files
|
||||
callgrind.out.*
|
||||
|
||||
@ -43,9 +43,8 @@ cd ..
|
||||
|
||||
If you intend to run clickhouse-server, make sure to increase the system's maxfiles variable.
|
||||
|
||||
<div class="admonition info">
|
||||
Note: you'll need to use sudo.
|
||||
</div>
|
||||
!!! info "Note"
|
||||
You'll need to use sudo.
|
||||
|
||||
To do so, create the following file:
|
||||
|
||||
|
||||
BIN
docs/en/images/column_oriented.gif
Normal file
BIN
docs/en/images/column_oriented.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
BIN
docs/en/images/row_oriented.gif
Normal file
BIN
docs/en/images/row_oriented.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
@ -1,69 +1,87 @@
|
||||
# What is ClickHouse?
|
||||
|
||||
ClickHouse is a columnar DBMS for OLAP.
|
||||
ClickHouse is a columnar database management system (DBMS) for online analytical processing (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
|
||||
...
|
||||
```
|
||||
| Row | WatchID | JavaEnable | Title | GoodEvent | EventTime |
|
||||
| --- | ------------------- | ---------- | ------------------ | --------- | ------------------- |
|
||||
| #0 | 5385521489354350662 | 1 | Investor Relations | 1 | 2016-05-18 05:19:20 |
|
||||
| #1 | 5385521490329509958 | 0 | Contact us | 1 | 2016-05-18 08:10:20 |
|
||||
| #2 | 5385521489953706054 | 1 | Mission | 1 | 2016-05-18 07:38:00 |
|
||||
| #N | ... | ... | ... | ... | ... |
|
||||
|
||||
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 order words, all the values related to a row are physically stored next to each other.
|
||||
|
||||
Examples of a row-oriented DBMSs are MySQL, Postgres and MS SQL Server.
|
||||
{: .grey }
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
| Row: | #0 | #1 | #2 | #N |
|
||||
| ----------- | ------------------- | ------------------- | ------------------- | ------------------- |
|
||||
| WatchID: | 5385521489354350662 | 5385521490329509958 | 5385521489953706054 | ... |
|
||||
| JavaEnable: | 1 | 0 | 1 | ... |
|
||||
| Title: | Investor Relations | Contact us | Mission | ... |
|
||||
| GoodEvent: | 1 | 1 | 1 | ... |
|
||||
| EventTime: | 2016-05-18 05:19:20 | 2016-05-18 08:10:20 | 2016-05-18 07:38:00 | ... |
|
||||
|
||||
|
||||
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.
|
||||
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+.
|
||||
{: .grey }
|
||||
|
||||
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.
|
||||
Different orders for storing data are better suited to different scenarios. The data access scenario refers to which 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 writing data; the size of the actively used dataset 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.
|
||||
The higher the load on the system, the more important it is to customize the system set up to match the requirements of the usage scenario, and the more fine grained 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 or few of possible scenarios.
|
||||
|
||||
We'll say that the following is true for the OLAP (online analytical processing) scenario:
|
||||
## Key properties of OLAP 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 ingested 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).
|
||||
- Tables are "wide", meaning they contain a large number of columns.
|
||||
- Queries are relatively rare (usually hundreds of queries per second per server or less).
|
||||
- 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.
|
||||
- Transactions are not necessary.
|
||||
- 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.
|
||||
- A query result is significantly smaller than the source data. In other words, data is filtered or aggregated, so 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.
|
||||
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 Redis 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:
|
||||
## Reasons why columnar databases are better suited for OLAP scenario
|
||||
|
||||
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.
|
||||
Column-oriented databases are better suited to OLAP scenarios (at least 100 times better in processing speed for most queries). The reasons for that are explained below in detail, but it's easier to be demonstrated visually:
|
||||
|
||||
**Row oriented**
|
||||
|
||||
|
||||
|
||||
**Column oriented**
|
||||
|
||||
|
||||
|
||||
See the difference? Read further to learn why this happens.
|
||||
|
||||
### Input/output
|
||||
|
||||
1. 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.
|
||||
2. 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.
|
||||
3. 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
|
||||
ClickHouse client version 0.0.52053.
|
||||
Connecting to localhost:9000.
|
||||
Connected to ClickHouse server version 0.0.52053.
|
||||
@ -106,7 +124,7 @@ LIMIT 20
|
||||
:)
|
||||
```
|
||||
|
||||
2. For CPU.
|
||||
### 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.
|
||||
|
||||
@ -1,2 +0,0 @@
|
||||
# Introduction
|
||||
|
||||
@ -1,2 +1,2 @@
|
||||
# Usage
|
||||
# Operations
|
||||
|
||||
|
||||
@ -22,11 +22,8 @@ Default value: 3600.
|
||||
|
||||
Data compression settings.
|
||||
|
||||
<div class="admonition warning">
|
||||
|
||||
Don't use it if you have just started using ClickHouse.
|
||||
|
||||
</div>
|
||||
!!! warning "Warning"
|
||||
Don't use it if you have just started using ClickHouse.
|
||||
|
||||
The configuration looks like this:
|
||||
|
||||
@ -334,7 +331,7 @@ Also, logging to syslog is possible. Configuration example:
|
||||
<use_syslog>1</use_syslog>
|
||||
<syslog>
|
||||
<address>syslog.remote:10514</address>
|
||||
<hostname>myhost.local</hostname>
|
||||
<hostname>myhost.local</hostname>
|
||||
<facility>LOG_LOCAL6</facility>
|
||||
<format>syslog</format>
|
||||
</syslog>
|
||||
@ -345,8 +342,8 @@ Keys:
|
||||
- user_syslog - activation key, turning on syslog logging.
|
||||
- address - host[:port] of syslogd. If not specified, local one would be used.
|
||||
- hostname - optional, source host of logs
|
||||
- facility - [syslog facility](https://en.wikipedia.org/wiki/Syslog#Facility),
|
||||
in uppercase, prefixed with "LOG_": (``LOG_USER``, ``LOG_DAEMON``, ``LOG_LOCAL3`` etc.).
|
||||
- facility - [syslog facility](https://en.wikipedia.org/wiki/Syslog#Facility),
|
||||
in uppercase, prefixed with "LOG_": (``LOG_USER``, ``LOG_DAEMON``, ``LOG_LOCAL3`` etc.).
|
||||
Default values: when ``address`` is specified, then ``LOG_USER``, otherwise - ``LOG_DAEMON``
|
||||
- format - message format. Possible values are - ``bsd`` and ``syslog``
|
||||
|
||||
@ -561,11 +558,9 @@ Use the following parameters to configure logging:
|
||||
|
||||
The path to the directory containing data.
|
||||
|
||||
<div class="admonition warning">
|
||||
!!! warning "Attention"
|
||||
The trailing slash is mandatory.
|
||||
|
||||
The end slash is mandatory.
|
||||
|
||||
</div>
|
||||
|
||||
**Example**
|
||||
|
||||
@ -651,11 +646,8 @@ Port for communicating with clients over the TCP protocol.
|
||||
|
||||
Path to temporary data for processing large queries.
|
||||
|
||||
<div class="admonition warning">
|
||||
|
||||
The end slash is mandatory.
|
||||
|
||||
</div>
|
||||
!!! warning "Attention"
|
||||
The trailing slash is mandatory.
|
||||
|
||||
**Example**
|
||||
|
||||
|
||||
@ -24,9 +24,8 @@ When creating table using `File(Format)` it creates empty subdirectory in that f
|
||||
|
||||
You may manually create this subfolder and file in server filesystem and then [ATTACH](../../query_language/misc.md#queries-attach) it to table information with matching name, so you can query data from that file.
|
||||
|
||||
<div class="admonition warning">
|
||||
Be careful with this funcionality, because ClickHouse does not keep track of external changes to such files. The result of simultaneous writes via ClickHouse and outside of ClickHouse is undefined.
|
||||
</div>
|
||||
!!! warning
|
||||
Be careful with this funcionality, because ClickHouse does not keep track of external changes to such files. The result of simultaneous writes via ClickHouse and outside of ClickHouse is undefined.
|
||||
|
||||
**Example:**
|
||||
|
||||
|
||||
@ -10,9 +10,8 @@ Accepts data that represent tables and queries them using [ClickHouse SQL dialec
|
||||
|
||||
By default `clickhouse-local` does not have access to data on the same host, but it supports loading server configuration using `--config-file` argument.
|
||||
|
||||
<div class="admonition warning">
|
||||
It is not recommended to load production server configuration into `clickhouse-local` because data can be damaged in case of human error.
|
||||
</div>
|
||||
!!! warning
|
||||
It is not recommended to load production server configuration into `clickhouse-local` because data can be damaged in case of human error.
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
@ -39,8 +39,5 @@ You can [configure](external_dicts_dict.md#dicts-external_dicts_dict) any number
|
||||
|
||||
See also "[Functions for working with external dictionaries](../functions/ext_dict_functions.md#ext_dict_functions)".
|
||||
|
||||
<div class="admonition attention">
|
||||
|
||||
You can convert values for a small dictionary by describing it in a `SELECT` query (see the [transform](../functions/other_functions.md#other_functions-transform) function). This functionality is not related to external dictionaries.
|
||||
|
||||
</div>
|
||||
!!! attention
|
||||
You can convert values for a small dictionary by describing it in a `SELECT` query (see the [transform](../functions/other_functions.md#other_functions-transform) function). This functionality is not related to external dictionaries.
|
||||
|
||||
@ -219,11 +219,8 @@ Set a large enough cache size. You need to experiment to select the number of ce
|
||||
3. Assess memory consumption using the `system.dictionaries` table.
|
||||
4. Increase or decrease the number of cells until the required memory consumption is reached.
|
||||
|
||||
<div class="admonition warning">
|
||||
|
||||
Do not use ClickHouse as a source, because it is slow to process queries with random reads.
|
||||
|
||||
</div>
|
||||
!!! warning
|
||||
Do not use ClickHouse as a source, because it is slow to process queries with random reads.
|
||||
|
||||
<a name="dicts-external_dicts_dict_layout-complex_key_cache"></a>
|
||||
|
||||
|
||||
@ -39,11 +39,8 @@ ClickHouse supports the following types of keys:
|
||||
|
||||
A structure can contain either `<id>` or `<key>` .
|
||||
|
||||
<div class="admonition attention">
|
||||
|
||||
The key doesn't need to be defined separately in attributes.
|
||||
|
||||
</div>
|
||||
!!! warning
|
||||
The key doesn't need to be defined separately in attributes.
|
||||
|
||||
### Numeric key
|
||||
|
||||
@ -65,9 +62,8 @@ Configuration fields:
|
||||
|
||||
The key can be a `tuple` from any types of fields. The [layout](external_dicts_dict_layout.md#dicts-external_dicts_dict_layout) in this case must be `complex_key_hashed` or `complex_key_cache`.
|
||||
|
||||
<div class="admonition tip">
|
||||
A composite key can consist of a single element. This makes it possible to use a string as the key, for instance.
|
||||
</div>
|
||||
!!! tip
|
||||
A composite key can consist of a single element. This makes it possible to use a string as the key, for instance.
|
||||
|
||||
The key structure is set in the element `<key>`. Key fields are specified in the same format as the dictionary [attributes](external_dicts_dict_structure.md#dicts-external_dicts_dict_structure-attributes). Example:
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# SQL dialect
|
||||
# SQL reference
|
||||
|
||||
* [SELECT](select.md#select)
|
||||
* [INSERT INTO](insert_into.md#queries-insert)
|
||||
|
||||
@ -175,6 +175,9 @@ Supported only by `*MergeTree` engines, in which this query initializes a non-sc
|
||||
If you specify a `PARTITION`, only the specified partition will be optimized.
|
||||
If you specify `FINAL`, optimization will be performed even when all the data is already in one part.
|
||||
|
||||
!!! warning
|
||||
OPTIMIZE can't fix the "Too many parts" error.
|
||||
|
||||
## KILL QUERY
|
||||
|
||||
```sql
|
||||
|
||||
@ -722,11 +722,8 @@ A subquery in the IN clause is always run just one time on a single server. Ther
|
||||
|
||||
There are two options for IN-s with subqueries (similar to JOINs): normal `IN` / ` OIN` and `IN GLOBAL` / `GLOBAL JOIN`. They differ in how they are run for distributed query processing.
|
||||
|
||||
<div class="admonition attention">
|
||||
|
||||
Remember that the algorithms described below may work differently depending on the [settings](../operations/settings/settings.md#settings-distributed_product_mode) `distributed_product_mode` setting.
|
||||
|
||||
</div>
|
||||
!!! attention
|
||||
Remember that the algorithms described below may work differently depending on the [settings](../operations/settings/settings.md#settings-distributed_product_mode) `distributed_product_mode` setting.
|
||||
|
||||
When using the regular IN, the query is sent to remote servers, and each of them runs the subqueries in the `IN` or `JOIN` clause.
|
||||
|
||||
|
||||
@ -13,11 +13,8 @@ remote('addresses_expr', db.table[, 'user'[, 'password']])
|
||||
|
||||
`addresses_expr` – An expression that generates addresses of remote servers. This may be just one server address. The server address is `host:port`, or just `host`. The host can be specified as the server name, or as the IPv4 or IPv6 address. An IPv6 address is specified in square brackets. The port is the TCP port on the remote server. If the port is omitted, it uses `tcp_port` from the server's config file (by default, 9000).
|
||||
|
||||
<div class="admonition important">
|
||||
|
||||
The port is required for an IPv6 address.
|
||||
|
||||
</div>
|
||||
!!! important
|
||||
The port is required for an IPv6 address.
|
||||
|
||||
Examples:
|
||||
|
||||
|
||||
BIN
docs/ru/images/column_oriented.gif
Normal file
BIN
docs/ru/images/column_oriented.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
BIN
docs/ru/images/row_oriented.gif
Normal file
BIN
docs/ru/images/row_oriented.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
@ -1,39 +1,44 @@
|
||||
# Что такое ClickHouse
|
||||
|
||||
ClickHouse - столбцовая СУБД для OLAP (Columnar DBMS).
|
||||
ClickHouse - столбцовая система управления базами данных (СУБД) для онлайн обработки аналитических запросов (OLAP).
|
||||
|
||||
В обычной, "строковой" СУБД, данные хранятся в таком порядке:
|
||||
|
||||
```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
|
||||
...
|
||||
```
|
||||
| Строка | WatchID | JavaEnable | Title | GoodEvent | EventTime |
|
||||
| ------ | ------------------- | ---------- | ------------------ | --------- | ------------------- |
|
||||
| #0 | 5385521489354350662 | 1 | Investor Relations | 1 | 2016-05-18 05:19:20 |
|
||||
| #1 | 5385521490329509958 | 0 | Contact us | 1 | 2016-05-18 08:10:20 |
|
||||
| #2 | 5385521489953706054 | 1 | Mission | 1 | 2016-05-18 07:38:00 |
|
||||
| #N | ... | ... | ... | ... | ... |
|
||||
|
||||
То есть, значения, относящиеся к одной строке, хранятся рядом.
|
||||
Примеры строковых СУБД: MySQL, Postgres, MS SQL Server и т. п.
|
||||
То есть, значения, относящиеся к одной строке, физически хранятся рядом.
|
||||
|
||||
Примеры строковых СУБД: MySQL, Postgres, MS SQL Server.
|
||||
{: .grey }
|
||||
|
||||
В столбцовых СУБД, данные хранятся в таком порядке:
|
||||
|
||||
```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
|
||||
```
|
||||
| Строка: | #0 | #1 | #2 | #N |
|
||||
| ----------- | ------------------- | ------------------- | ------------------- | ------------------- |
|
||||
| WatchID: | 5385521489354350662 | 5385521490329509958 | 5385521489953706054 | ... |
|
||||
| JavaEnable: | 1 | 0 | 1 | ... |
|
||||
| Title: | Investor Relations | Contact us | Mission | ... |
|
||||
| GoodEvent: | 1 | 1 | 1 | ... |
|
||||
| EventTime: | 2016-05-18 05:19:20 | 2016-05-18 08:10:20 | 2016-05-18 07:38:00 | ... |
|
||||
|
||||
|
||||
В примерах изображён только порядок расположения данных.
|
||||
То есть, значения из разных столбцов хранятся отдельно, а данные одного столбца - вместе.
|
||||
|
||||
Примеры столбцовых СУБД: `Vertica`, `Paraccel (Actian Matrix) (Amazon Redshift)`, `Sybase IQ`, `Exasol`, `Infobright`, `InfiniDB`, `MonetDB (VectorWise) (Actian Vector)`, `LucidDB`, `SAP HANA`, `Google Dremel`, `Google PowerDrill`, `Druid`, `kdb+` и т. п.
|
||||
Примеры столбцовых СУБД: Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
|
||||
{: .grey }
|
||||
|
||||
Разный порядок хранения данных лучше подходит для разных сценариев работы.
|
||||
Сценарий работы с данными - это то, какие производятся запросы, как часто и в каком соотношении; сколько читается данных на запросы каждого вида - строк, столбцов, байт; как соотносятся чтения и обновления данных; какой рабочий размер данных и насколько локально он используется; используются ли транзакции и с какой изолированностью; какие требования к дублированию данных и логической целостности; требования к задержкам на выполнение и пропускной способности запросов каждого вида и т. п.
|
||||
|
||||
Чем больше нагрузка на систему, тем более важной становится специализация под сценарий работы, и тем более конкретной становится эта специализация. Не существует системы, одинаково хорошо подходящей под существенно различные сценарии работы. Если система подходит под широкое множество сценариев работы, то при достаточно большой нагрузке, система будет справляться со всеми сценариями работы плохо, или справляться хорошо только с одним из сценариев работы.
|
||||
|
||||
Будем говорить, что OLAP (онлайн обработка аналитических запросов) сценарий работы - это:
|
||||
## Ключевые особенности OLAP сценария работы
|
||||
|
||||
- подавляющее большинство запросов - на чтение;
|
||||
- данные обновляются достаточно большими пачками (> 1000 строк), а не по одной строке, или не обновляются вообще;
|
||||
@ -49,21 +54,34 @@ EventTime: 2016-05-18 05:19:20 2016-05-18 08:10:20 2016-05-18 07:38:00
|
||||
- в запросе одна большая таблица, все таблицы кроме одной маленькие;
|
||||
- результат выполнения запроса существенно меньше исходных данных - то есть, данные фильтруются или агрегируются; результат выполнения помещается в оперативку на одном сервере;
|
||||
|
||||
Легко видеть, что OLAP сценарий работы существенно отличается от других распространённых сценариев работы (например, OLTP или Key-Value сценариев работы). Таким образом, не имеет никакого смысла пытаться использовать OLTP или Key-Value БД для обработки аналитических запросов, если вы хотите получить приличную производительность ("выше плинтуса"). Например, если вы попытаетесь использовать для аналитики MongoDB или Elliptics - вы получите анекдотически низкую производительность по сравнению с OLAP-СУБД.
|
||||
Легко видеть, что OLAP сценарий работы существенно отличается от других распространённых сценариев работы (например, OLTP или Key-Value сценариев работы). Таким образом, не имеет никакого смысла пытаться использовать OLTP или Key-Value БД для обработки аналитических запросов, если вы хотите получить приличную производительность ("выше плинтуса"). Например, если вы попытаетесь использовать для аналитики MongoDB или Redis - вы получите анекдотически низкую производительность по сравнению с OLAP-СУБД.
|
||||
|
||||
Столбцовые СУБД лучше (от 100 раз по скорости обработки большинства запросов) подходят для OLAP сценария работы по следующим причинам:
|
||||
## Причины, по которым столбцовые СУБД лучше подходят для OLAP сценария
|
||||
|
||||
1. По I/O.
|
||||
2. Для выполнения аналитического запроса, требуется прочитать небольшое количество столбцов таблицы. В столбцовой БД для этого можно читать только нужные данные. Например, если вам требуется только 5 столбцов из 100, то следует рассчитывать на 20-кратное уменьшение ввода-вывода.
|
||||
3. Так как данные читаются пачками, то их проще сжимать. Данные, лежащие по столбцам также лучше сжимаются. За счёт этого, дополнительно уменьшается объём ввода-вывода.
|
||||
4. За счёт уменьшения ввода-вывода, больше данных влезает в системный кэш.
|
||||
Столбцовые СУБД лучше (от 100 раз по скорости обработки большинства запросов) подходят для OLAP сценария работы. Причины в деталях буду разъяснены ниже, а сам факт проще проще продемонстрировать визуально:
|
||||
|
||||
**Строковые СУБД**
|
||||
|
||||
|
||||
|
||||
**Столбцовые СУБД**
|
||||
|
||||
|
||||
|
||||
Видите разницу?
|
||||
|
||||
### По вводу-выводу
|
||||
|
||||
1. Для выполнения аналитического запроса, требуется прочитать небольшое количество столбцов таблицы. В столбцовой БД для этого можно читать только нужные данные. Например, если вам требуется только 5 столбцов из 100, то следует рассчитывать на 20-кратное уменьшение ввода-вывода.
|
||||
2. Так как данные читаются пачками, то их проще сжимать. Данные, лежащие по столбцам также лучше сжимаются. За счёт этого, дополнительно уменьшается объём ввода-вывода.
|
||||
3. За счёт уменьшения ввода-вывода, больше данных влезает в системный кэш.
|
||||
|
||||
Для примера, для запроса "посчитать количество записей для каждой рекламной системы", требуется прочитать один столбец "идентификатор рекламной системы", который занимает 1 байт в несжатом виде. Если большинство переходов было не с рекламных систем, то можно рассчитывать хотя бы на десятикратное сжатие этого столбца. При использовании быстрого алгоритма сжатия, возможно разжатие данных со скоростью более нескольких гигабайт несжатых данных в секунду. То есть, такой запрос может выполняться со скоростью около нескольких миллиардов строк в секунду на одном сервере. На практике, такая скорость действительно достигается.
|
||||
|
||||
Пример:
|
||||
|
||||
```bash
|
||||
milovidov@hostname:~$ clickhouse-client
|
||||
$ clickhouse-client
|
||||
ClickHouse client version 0.0.52053.
|
||||
Connecting to localhost:9000.
|
||||
Connected to ClickHouse server version 0.0.52053.
|
||||
@ -106,7 +124,7 @@ LIMIT 20
|
||||
:)
|
||||
```
|
||||
|
||||
2. По CPU.
|
||||
### По вычислениям
|
||||
|
||||
Так как для выполнения запроса надо обработать достаточно большое количество строк, становится актуальным диспетчеризовывать все операции не для отдельных строк, а для целых векторов, или реализовать движок выполнения запроса так, чтобы издержки на диспетчеризацию были примерно нулевыми. Если этого не делать, то при любой не слишком плохой дисковой подсистеме, интерпретатор запроса неизбежно упрётся в CPU.
|
||||
Имеет смысл не только хранить данные по столбцам, но и обрабатывать их, по возможности, тоже по столбцам.
|
||||
|
||||
@ -1 +0,0 @@
|
||||
# Введение
|
||||
@ -22,11 +22,8 @@ ClickHouse перезагружает встроенные словари с з
|
||||
|
||||
Настройки компрессии данных.
|
||||
|
||||
<div class="admonition warning">
|
||||
|
||||
Не используйте, если вы только начали работать с ClickHouse.
|
||||
|
||||
</div>
|
||||
!!! warning "Внимание"
|
||||
Лучше не использовать, если вы только начали работать с ClickHouse.
|
||||
|
||||
Общий вид конфигурации:
|
||||
|
||||
@ -335,7 +332,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
<use_syslog>1</use_syslog>
|
||||
<syslog>
|
||||
<address>syslog.remote:10514</address>
|
||||
<hostname>myhost.local</hostname>
|
||||
<hostname>myhost.local</hostname>
|
||||
<facility>LOG_LOCAL6</facility>
|
||||
<format>syslog</format>
|
||||
</syslog>
|
||||
@ -346,12 +343,12 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
- user_syslog - обязательная настройка, если требуется запись в syslog
|
||||
- address - хост[:порт] демона syslogd. Если не указан, используется локальный
|
||||
- hostname - опционально, имя хоста, с которого отсылаются логи
|
||||
- facility - [категория syslog](https://en.wikipedia.org/wiki/Syslog#Facility),
|
||||
записанная в верхнем регистре, с префиксом "LOG_": (``LOG_USER``, ``LOG_DAEMON``, ``LOG_LOCAL3`` и прочие).
|
||||
- facility - [категория syslog](https://en.wikipedia.org/wiki/Syslog#Facility),
|
||||
записанная в верхнем регистре, с префиксом "LOG_": (``LOG_USER``, ``LOG_DAEMON``, ``LOG_LOCAL3`` и прочие).
|
||||
Значения по-умолчанию: при указанном ``address`` - ``LOG_USER``, иначе - ``LOG_DAEMON``
|
||||
- format - формат сообщений. Возможные значения - ``bsd`` и ``syslog``
|
||||
|
||||
|
||||
|
||||
<a name="server_settings-macros"></a>
|
||||
|
||||
## macros
|
||||
@ -564,11 +561,8 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
|
||||
Путь к каталогу с данными.
|
||||
|
||||
<div class="admonition warning">
|
||||
|
||||
Завершающий слеш обязателен.
|
||||
|
||||
</div>
|
||||
!!! warning "Обратите внимание"
|
||||
Завершающий слеш обязателен.
|
||||
|
||||
**Пример**
|
||||
|
||||
@ -655,11 +649,8 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
|
||||
Путь ко временным данным для обработки больших запросов.
|
||||
|
||||
<div class="admonition warning">
|
||||
|
||||
Завершающий слеш обязателен.
|
||||
|
||||
</div>
|
||||
!!! warning "Обратите внимание"
|
||||
Завершающий слеш обязателен.
|
||||
|
||||
**Пример**
|
||||
|
||||
|
||||
@ -24,9 +24,8 @@ File(Format)
|
||||
|
||||
Можно вручную создать в хранилище каталог таблицы, поместить туда файл, затем на сервере ClickHouse добавить ([ATTACH](../../query_language/misc.md#queries-attach)) информацию о таблице, соответствующей имени каталога и прочитать из файла данные.
|
||||
|
||||
<div class="admonition warning">
|
||||
Будьте аккуратны с этой функциональностью, поскольку сервер ClickHouse не отслеживает внешние изменения данных. Если в файл будет производиться запись одновременно со стороны сервера ClickHouse и с внешней стороны, то результат непредсказуем.
|
||||
</div>
|
||||
!!! warning
|
||||
Будьте аккуратны с этой функциональностью, поскольку сервер ClickHouse не отслеживает внешние изменения данных. Если в файл будет производиться запись одновременно со стороны сервера ClickHouse и с внешней стороны, то результат непредсказуем.
|
||||
|
||||
**Пример:**
|
||||
|
||||
|
||||
@ -8,10 +8,8 @@
|
||||
|
||||
`clickhouse-local` при настройке по умолчанию не имеет доступа к данным, которыми управляет сервер ClickHouse, установленный на этом же хосте, однако можно подключить конфигурацию сервера с помощью ключа `--config-file`.
|
||||
|
||||
<div class="admonition warning">
|
||||
Мы не рекомендуем подключать серверную конфигурацию к `clickhouse-local`, поскольку данные можно легко повредить неосторожными действиями.
|
||||
</div>
|
||||
|
||||
!!! warning
|
||||
Мы не рекомендуем подключать серверную конфигурацию к `clickhouse-local`, поскольку данные можно легко повредить неосторожными действиями.
|
||||
|
||||
## Вызов программы
|
||||
|
||||
|
||||
@ -217,11 +217,8 @@
|
||||
3. Оценить потребление оперативной памяти с помощью таблицы `system.dictionaries`.
|
||||
4. Увеличивать/уменьшать количество ячеек до получения требуемого расхода оперативной памяти.
|
||||
|
||||
<div class="admonition warning">
|
||||
|
||||
Не используйте в качестве источника ClickHouse, поскольку он медленно обрабатывает запросы со случайным чтением.
|
||||
|
||||
</div>
|
||||
!!! warning
|
||||
Не используйте в качестве источника ClickHouse, поскольку он медленно обрабатывает запросы со случайным чтением.
|
||||
|
||||
<a name="dicts-external_dicts_dict_layout-complex_key_cache"></a>
|
||||
|
||||
|
||||
@ -39,11 +39,8 @@ ClickHouse поддерживает следующие виды ключей:
|
||||
|
||||
Структура может содержать либо `<id>` либо `<key>`.
|
||||
|
||||
<div class="admonition attention">
|
||||
|
||||
Ключ не надо дополнительно описывать в атрибутах.
|
||||
|
||||
</div>
|
||||
!!! attention "Обратите внимание"
|
||||
Ключ не надо дополнительно описывать в атрибутах.
|
||||
|
||||
### Числовой ключ
|
||||
|
||||
@ -65,9 +62,8 @@ ClickHouse поддерживает следующие виды ключей:
|
||||
|
||||
Ключем может быть кортеж (`tuple`) из полей произвольных типов. [layout](external_dicts_dict_layout.md#dicts-external_dicts_dict_layout) в этом случае должен быть `complex_key_hashed` или `complex_key_cache`.
|
||||
|
||||
<div class="admonition tip">
|
||||
Cоставной ключ может состоять из одного элемента. Это даёт возможность использовать в качестве ключа, например, строку.
|
||||
</div>
|
||||
!!! tip "Совет"
|
||||
Cоставной ключ может состоять из одного элемента. Это даёт возможность использовать в качестве ключа, например, строку.
|
||||
|
||||
Структура ключа задаётся в элементе `<key>`. Поля ключа задаются в том же формате, что и [атрибуты](external_dicts_dict_structure.md#dicts-external_dicts_dict_structure-attributes) словаря. Пример:
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Диалект SQL
|
||||
# Справка по SQL
|
||||
|
||||
* [SELECT](select.md#select)
|
||||
* [INSERT INTO](insert_into.md#queries-insert)
|
||||
|
||||
@ -174,9 +174,8 @@ OPTIMIZE TABLE [db.]name [PARTITION partition] [FINAL]
|
||||
Если указан `PARTITION`, то оптимизация будет производиться только для указаной партиции.
|
||||
Если указан `FINAL`, то оптимизация будет производиться даже когда все данные уже лежат в одном куске.
|
||||
|
||||
<div class="admonition warning">
|
||||
Запрос OPTIMIZE не может устранить причину появления ошибки "Too many parts".
|
||||
</div>
|
||||
!!! warning "Внимание"
|
||||
Запрос OPTIMIZE не может устранить причину появления ошибки "Too many parts".
|
||||
|
||||
## KILL QUERY
|
||||
|
||||
|
||||
@ -724,11 +724,8 @@ ORDER BY EventDate ASC
|
||||
|
||||
Существует два варианта IN-ов с подзапросами (аналогично для JOIN-ов): обычный `IN` / `JOIN` и `GLOBAL IN` / `GLOBAL JOIN`. Они отличаются способом выполнения при распределённой обработке запроса.
|
||||
|
||||
<div class="admonition attention">
|
||||
|
||||
Помните, что алгоритмы, описанные ниже, могут работать иначе в зависимости от [настройки](../operations/settings/settings.md#settings-distributed_product_mode) `distributed_product_mode`.
|
||||
|
||||
</div>
|
||||
!!! attention
|
||||
Помните, что алгоритмы, описанные ниже, могут работать иначе в зависимости от [настройки](../operations/settings/settings.md#settings-distributed_product_mode) `distributed_product_mode`.
|
||||
|
||||
При использовании обычного IN-а, запрос отправляется на удалённые серверы, и на каждом из них выполняются подзапросы в секциях `IN` / `JOIN`.
|
||||
|
||||
|
||||
@ -13,11 +13,8 @@ remote('addresses_expr', db.table[, 'user'[, 'password']])
|
||||
|
||||
`addresses_expr` - выражение, генерирующее адреса удалённых серверов. Это может быть просто один адрес сервера. Адрес сервера - это `хост:порт`, или только `хост`. Хост может быть указан в виде имени сервера, или в виде IPv4 или IPv6 адреса. IPv6 адрес указывается в квадратных скобках. Порт - TCP-порт удалённого сервера. Если порт не указан, используется `tcp_port` из конфигурационного файла сервера (по умолчанию - 9000).
|
||||
|
||||
<div class="admonition important">
|
||||
|
||||
С IPv6-адресом обязательно указывать порт.
|
||||
|
||||
</div>
|
||||
!!! important "Важно"
|
||||
С IPv6-адресом обязательно нужно указывать порт.
|
||||
|
||||
Примеры:
|
||||
|
||||
|
||||
@ -1,8 +1,6 @@
|
||||
pages:
|
||||
- 'ClickHouse': 'index.md'
|
||||
|
||||
- 'Introduction':
|
||||
- 'hidden': 'introduction/index.md'
|
||||
- 'Overview': 'index.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'
|
||||
@ -50,7 +48,7 @@ pages:
|
||||
- 'Expression': 'data_types/special_data_types/expression.md'
|
||||
- 'Set': 'data_types/special_data_types/set.md'
|
||||
|
||||
- 'SQL dialect':
|
||||
- 'SQL reference':
|
||||
- 'hidden': 'query_language/index.md'
|
||||
- 'SELECT': 'query_language/select.md'
|
||||
- 'INSERT INTO': 'query_language/insert_into.md'
|
||||
@ -108,9 +106,9 @@ pages:
|
||||
- 'Internal dictionaries': 'query_language/dicts/internal_dicts.md'
|
||||
- 'Operators': 'query_language/operators.md'
|
||||
- 'General syntax': 'query_language/syntax.md'
|
||||
|
||||
|
||||
- 'Operations':
|
||||
- 'Operations': 'operations/index.md'
|
||||
- 'hidden': 'operations/index.md'
|
||||
- 'Table engines':
|
||||
- 'Introduction': 'operations/table_engines/index.md'
|
||||
- 'MergeTree family':
|
||||
@ -160,7 +158,7 @@ pages:
|
||||
- 'clickhouse-copier': 'operations/utils/clickhouse-copier.md'
|
||||
- 'clickhouse-local': 'operations/utils/clickhouse-local.md'
|
||||
|
||||
- 'ClickHouse Development':
|
||||
- 'Development':
|
||||
- 'hidden': 'development/index.md'
|
||||
- 'Overview of ClickHouse architecture': 'development/architecture.md'
|
||||
- 'How to build ClickHouse on Linux': 'development/build.md'
|
||||
|
||||
@ -1,8 +1,7 @@
|
||||
pages:
|
||||
- 'ClickHouse': 'index.md'
|
||||
|
||||
- 'Введение':
|
||||
- 'hidden': 'introduction/index.md'
|
||||
- 'Обзор': 'index.md'
|
||||
- 'Отличительные возможности ClickHouse': 'introduction/distinctive_features.md'
|
||||
- 'Особенности ClickHouse, которые могут считаться недостатками': 'introduction/features_considered_disadvantages.md'
|
||||
- 'Постановка задачи в Яндекс.Метрике': 'introduction/ya_metrika_task.md'
|
||||
@ -50,7 +49,7 @@ pages:
|
||||
- 'Expression': 'data_types/special_data_types/expression.md'
|
||||
- 'Set': 'data_types/special_data_types/set.md'
|
||||
|
||||
- 'SQL диалект':
|
||||
- 'Справка по SQL':
|
||||
- 'hidden': 'query_language/index.md'
|
||||
- 'SELECT': 'query_language/select.md'
|
||||
- 'INSERT INTO': 'query_language/insert_into.md'
|
||||
@ -86,7 +85,7 @@ pages:
|
||||
- 'Функции для реализации оператора IN.': 'query_language/functions/in_functions.md'
|
||||
- 'Функция arrayJoin': 'query_language/functions/array_join.md'
|
||||
- 'Функции для работы с географическими координатами': 'query_language/functions/geo.md'
|
||||
|
||||
|
||||
- 'Агрегатные функции':
|
||||
- 'Введение': 'query_language/agg_functions/index.md'
|
||||
- 'Справочник функций': 'query_language/agg_functions/reference.md'
|
||||
@ -110,7 +109,7 @@ pages:
|
||||
- 'Встроенные словари': 'query_language/dicts/internal_dicts.md'
|
||||
- 'Операторы': 'query_language/operators.md'
|
||||
- 'Общий синтаксис': 'query_language/syntax.md'
|
||||
|
||||
|
||||
|
||||
- 'Эксплуатация':
|
||||
- 'hidden': 'operations/index.md'
|
||||
@ -125,13 +124,13 @@ pages:
|
||||
- 'AggregatingMergeTree': 'operations/table_engines/aggregatingmergetree.md'
|
||||
- 'CollapsingMergeTree': 'operations/table_engines/collapsingmergetree.md'
|
||||
- 'GraphiteMergeTree': 'operations/table_engines/graphitemergetree.md'
|
||||
- 'Для небольших объемов данных':
|
||||
- 'Для небольших объемов данных':
|
||||
- 'TinyLog': 'operations/table_engines/tinylog.md'
|
||||
- 'Log': 'operations/table_engines/log.md'
|
||||
- 'Memory': 'operations/table_engines/memory.md'
|
||||
- 'Buffer': 'operations/table_engines/buffer.md'
|
||||
- 'Внешние данные': 'operations/table_engines/external_data.md'
|
||||
- 'Особые':
|
||||
- 'Особые':
|
||||
- 'Distributed': 'operations/table_engines/distributed.md'
|
||||
- 'Dictionary': 'operations/table_engines/dictionary.md'
|
||||
- 'Merge': 'operations/table_engines/merge.md'
|
||||
@ -141,7 +140,7 @@ pages:
|
||||
- 'Join': 'operations/table_engines/join.md'
|
||||
- 'View': 'operations/table_engines/view.md'
|
||||
- 'MaterializedView': 'operations/table_engines/materializedview.md'
|
||||
- 'Интеграции':
|
||||
- 'Интеграции':
|
||||
- 'Kafka': 'operations/table_engines/kafka.md'
|
||||
- 'MySQL': 'operations/table_engines/mysql.md'
|
||||
- 'Права доступа': 'operations/access_rights.md'
|
||||
@ -162,7 +161,7 @@ pages:
|
||||
- 'clickhouse-copier': 'operations/utils/clickhouse-copier.md'
|
||||
- 'clickhouse-local': 'operations/utils/clickhouse-local.md'
|
||||
|
||||
- 'Разработка ClickHouse':
|
||||
- 'Разработка':
|
||||
- 'hidden': 'development/index.md'
|
||||
- 'Overview of ClickHouse architecture': 'development/architecture.md'
|
||||
- 'Как собрать ClickHouse на Linux': 'development/build.md'
|
||||
|
||||
@ -79,7 +79,11 @@ def build_for_lang(lang, args):
|
||||
repo_url='https://github.com/yandex/ClickHouse/',
|
||||
edit_uri='edit/master/docs/%s' % lang,
|
||||
extra_css=['assets/stylesheets/custom.css'],
|
||||
markdown_extensions=['codehilite']
|
||||
markdown_extensions=[
|
||||
'admonition',
|
||||
'attr_list',
|
||||
'codehilite'
|
||||
]
|
||||
)
|
||||
|
||||
mkdocs_build.build(cfg)
|
||||
|
||||
@ -128,3 +128,12 @@ h1, h2, h3, .md-logo {
|
||||
.md-hide {
|
||||
display: none;
|
||||
}
|
||||
|
||||
#md-extra-nav {
|
||||
background: #efefef;
|
||||
padding-top: 0.5rem;
|
||||
}
|
||||
|
||||
.grey {
|
||||
color: #666;
|
||||
}
|
||||
|
||||
@ -3,6 +3,11 @@
|
||||
{% if page.previous_page or page.next_page %}
|
||||
<div class="md-footer-nav">
|
||||
<nav class="md-footer-nav__inner md-grid">
|
||||
{% for _ in range(0, 9) %}
|
||||
{% if page.previous_page and page.previous_page.title == "hidden" %}
|
||||
{{ page.__dict__.update({"previous_page": page.previous_page.previous_page}) }}
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
{% if page.previous_page %}
|
||||
<a href="{{ page.previous_page.url }}" title="{{ page.previous_page.title }}" class="md-flex md-footer-nav__link md-footer-nav__link--prev" rel="prev">
|
||||
<div class="md-flex__cell md-flex__cell--shrink">
|
||||
@ -18,6 +23,11 @@
|
||||
</div>
|
||||
</a>
|
||||
{% endif %}
|
||||
{% for _ in range(0, 9) %}
|
||||
{% if page.next_page and page.next_page.title == "hidden" %}
|
||||
{{ page.__dict__.update({"next_page": page.next_page.next_page}) }}
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
{% if page.next_page %}
|
||||
<a href="{{ page.next_page.url }}" title="{{ page.next_page.title }}" class="md-flex md-footer-nav__link md-footer-nav__link--next" rel="next">
|
||||
<div class="md-flex__cell md-flex__cell--stretch md-footer-nav__title">
|
||||
|
||||
@ -3,7 +3,17 @@
|
||||
{{ config.site_name }}
|
||||
</label>
|
||||
|
||||
{% if not config.extra.single_page %}
|
||||
<ul class="md-nav__list" data-md-scrollfix>
|
||||
{% for nav_item in nav %}
|
||||
{% set path = "nav-" + loop.index | string %}
|
||||
{% set level = 1 %}
|
||||
{% include "partials/nav-item.html" %}
|
||||
{% endfor %}
|
||||
</ul>
|
||||
{% endif %}
|
||||
|
||||
<ul id="md-extra-nav" class="md-nav__list" data-md-scrollfix>
|
||||
<li class="md-nav__item md-nav__item--active">
|
||||
<script type="text/javascript">
|
||||
if (window.location.pathname.indexOf('/ru/') >= 0) {
|
||||
@ -12,7 +22,7 @@
|
||||
} else {
|
||||
document.write("<a href=\"{{ base_url }}/single/\" class=\"md-nav__link md-nav__link--active\">Одностраничная версия</a>")
|
||||
}
|
||||
}else{
|
||||
} else {
|
||||
if (window.location.pathname.indexOf('/single/') >= 0) {
|
||||
document.write("<a href=\"{{ base_url }}/../\" class=\"md-nav__link md-nav__link--active\">Multi page version</a>")
|
||||
}else{
|
||||
@ -33,14 +43,4 @@
|
||||
</a>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
{% if not config.extra.single_page %}
|
||||
<ul class="md-nav__list" data-md-scrollfix>
|
||||
{% for nav_item in nav %}
|
||||
{% set path = "nav-" + loop.index | string %}
|
||||
{% set level = 1 %}
|
||||
{% include "partials/nav-item.html" %}
|
||||
{% endfor %}
|
||||
</ul>
|
||||
{% endif %}
|
||||
</nav>
|
||||
|
||||
@ -39,10 +39,10 @@ var paths = {
|
||||
'!presentations/**/*.css',
|
||||
'!public/**/*.css'],
|
||||
images: [
|
||||
'**/*.{jpg,jpeg,png,svg,ico}',
|
||||
'!node_modules/**/*.{jpg,jpeg,png,svg,ico}',
|
||||
'!presentations/**/*.{jpg,jpeg,png,svg,ico}',
|
||||
'!public/**/*.{jpg,jpeg,png,svg,ico}'],
|
||||
'**/*.{jpg,jpeg,png,gif,svg,ico}',
|
||||
'!node_modules/**/*.{jpg,jpeg,png,gif,svg,ico}',
|
||||
'!presentations/**/*.{jpg,jpeg,png,gif,svg,ico}',
|
||||
'!public/**/*.{jpg,jpeg,png,gif,svg,ico}'],
|
||||
robotstxt: ['robots.txt'],
|
||||
presentations: ['presentations/**/*']
|
||||
};
|
||||
|
||||
Loading…
Reference in New Issue
Block a user