mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-25 17:12:03 +00:00
Merge branch 'master' into direct_queries
This commit is contained in:
Артем Стрельцов
commit
ce01d0aa85
@ -641,4 +641,4 @@
|
||||
#### Security Fix
|
||||
* Fixed the possibility of reading directories structure in tables with `File` table engine. This fixes [#8536](https://github.com/ClickHouse/ClickHouse/issues/8536). [#8537](https://github.com/ClickHouse/ClickHouse/pull/8537) ([alexey-milovidov](https://github.com/alexey-milovidov))
|
||||
|
||||
## [Changelog for 2019](https://github.com/ClickHouse/ClickHouse/blob/master/docs/en/changelog/2019.md)
|
||||
## [Changelog for 2019](https://github.com/ClickHouse/ClickHouse/blob/master/docs/en/whats_new/changelog/2019.md)
|
||||
|
||||
@ -15,7 +15,6 @@ ClickHouse is an open-source column-oriented database management system that all
|
||||
|
||||
## Upcoming Events
|
||||
|
||||
* [ClickHouse in Avito (online in Russian)](https://avitotech.timepad.ru/event/1290051/) on April 9, 2020.
|
||||
* [ClickHouse Monitoring Round Table (online in English)](https://www.eventbrite.com/e/clickhouse-april-virtual-meetup-tickets-102272923066) on April 15, 2020.
|
||||
* [ClickHouse Workshop in Novosibirsk](https://2020.codefest.ru/lecture/1628) on TBD date.
|
||||
* [Yandex C++ Open-Source Sprints in Moscow](https://events.yandex.ru/events/otkrytyj-kod-v-yandek-28-03-2020) on TBD date.
|
||||
|
||||
@ -135,16 +135,13 @@ When adding a new file:
|
||||
$ ln -sr en/new/file.md lang/new/file.md
|
||||
```
|
||||
|
||||
- Reference the file from `toc_{en,ru,zh,ja,fa}.yaml` files with the pages index.
|
||||
|
||||
|
||||
<a name="adding-a-new-language"/>
|
||||
|
||||
### Adding a New Language
|
||||
|
||||
1. Create a new docs subfolder named using the [ISO-639-1 language code](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes).
|
||||
2. Add Markdown files with the translation, mirroring the folder structure of other languages.
|
||||
3. Commit and open a pull request with the new content.
|
||||
3. Commit and open a pull-request with the new content.
|
||||
|
||||
When everything is ready, we will add the new language to the website.
|
||||
|
||||
@ -206,4 +203,4 @@ Templates:
|
||||
|
||||
## How to Build Documentation
|
||||
|
||||
You can build your documentation manually by following the instructions in [docs/tools/README.md](docs/tools/README.md). Also, our CI runs the documentation build after the `documentation` label is added to PR. You can see the results of a build in the GitHub interface. If you have no permissions to add labels, a reviewer of your PR will add it.
|
||||
You can build your documentation manually by following the instructions in [docs/tools/README.md](../docs/tools/README.md). Also, our CI runs the documentation build after the `documentation` label is added to PR. You can see the results of a build in the GitHub interface. If you have no permissions to add labels, a reviewer of your PR will add it.
|
||||
|
||||
@ -1,7 +1,3 @@
|
||||
---
|
||||
en_copy: true
|
||||
---
|
||||
|
||||
Row 1:
|
||||
──────
|
||||
count(): 6344
|
||||
|
||||
@ -1,265 +0,0 @@
|
||||
---
|
||||
en_copy: true
|
||||
---
|
||||
|
||||
### ClickHouse release 1.1.54327, 2017-12-21 {#clickhouse-release-1-1-54327-2017-12-21}
|
||||
|
||||
This release contains bug fixes for the previous release 1.1.54318:
|
||||
|
||||
- Fixed bug with possible race condition in replication that could lead to data loss. This issue affects versions 1.1.54310 and 1.1.54318. If you use one of these versions with Replicated tables, the update is strongly recommended. This issue shows in logs in Warning messages like `Part ... from own log doesn't exist.` The issue is relevant even if you don’t see these messages in logs.
|
||||
|
||||
### ClickHouse release 1.1.54318, 2017-11-30 {#clickhouse-release-1-1-54318-2017-11-30}
|
||||
|
||||
This release contains bug fixes for the previous release 1.1.54310:
|
||||
|
||||
- Fixed incorrect row deletions during merges in the SummingMergeTree engine
|
||||
- Fixed a memory leak in unreplicated MergeTree engines
|
||||
- Fixed performance degradation with frequent inserts in MergeTree engines
|
||||
- Fixed an issue that was causing the replication queue to stop running
|
||||
- Fixed rotation and archiving of server logs
|
||||
|
||||
### ClickHouse release 1.1.54310, 2017-11-01 {#clickhouse-release-1-1-54310-2017-11-01}
|
||||
|
||||
#### New features: {#new-features}
|
||||
|
||||
- Custom partitioning key for the MergeTree family of table engines.
|
||||
- [Kafka](https://clickhouse.yandex/docs/en/operations/table_engines/kafka/) table engine.
|
||||
- Added support for loading [CatBoost](https://catboost.yandex/) models and applying them to data stored in ClickHouse.
|
||||
- Added support for time zones with non-integer offsets from UTC.
|
||||
- Added support for arithmetic operations with time intervals.
|
||||
- The range of values for the Date and DateTime types is extended to the year 2105.
|
||||
- Added the `CREATE MATERIALIZED VIEW x TO y` query (specifies an existing table for storing the data of a materialized view).
|
||||
- Added the `ATTACH TABLE` query without arguments.
|
||||
- The processing logic for Nested columns with names ending in -Map in a SummingMergeTree table was extracted to the sumMap aggregate function. You can now specify such columns explicitly.
|
||||
- Max size of the IP trie dictionary is increased to 128M entries.
|
||||
- Added the getSizeOfEnumType function.
|
||||
- Added the sumWithOverflow aggregate function.
|
||||
- Added support for the Cap’n Proto input format.
|
||||
- You can now customize compression level when using the zstd algorithm.
|
||||
|
||||
#### Backward incompatible changes: {#backward-incompatible-changes}
|
||||
|
||||
- Creation of temporary tables with an engine other than Memory is not allowed.
|
||||
- Explicit creation of tables with the View or MaterializedView engine is not allowed.
|
||||
- During table creation, a new check verifies that the sampling key expression is included in the primary key.
|
||||
|
||||
#### Bug fixes: {#bug-fixes}
|
||||
|
||||
- Fixed hangups when synchronously inserting into a Distributed table.
|
||||
- Fixed nonatomic adding and removing of parts in Replicated tables.
|
||||
- Data inserted into a materialized view is not subjected to unnecessary deduplication.
|
||||
- Executing a query to a Distributed table for which the local replica is lagging and remote replicas are unavailable does not result in an error anymore.
|
||||
- Users don’t need access permissions to the `default` database to create temporary tables anymore.
|
||||
- Fixed crashing when specifying the Array type without arguments.
|
||||
- Fixed hangups when the disk volume containing server logs is full.
|
||||
- Fixed an overflow in the toRelativeWeekNum function for the first week of the Unix epoch.
|
||||
|
||||
#### Build improvements: {#build-improvements}
|
||||
|
||||
- Several third-party libraries (notably Poco) were updated and converted to git submodules.
|
||||
|
||||
### ClickHouse release 1.1.54304, 2017-10-19 {#clickhouse-release-1-1-54304-2017-10-19}
|
||||
|
||||
#### New features: {#new-features-1}
|
||||
|
||||
- TLS support in the native protocol (to enable, set `tcp_ssl_port` in `config.xml` ).
|
||||
|
||||
#### Bug fixes: {#bug-fixes-1}
|
||||
|
||||
- `ALTER` for replicated tables now tries to start running as soon as possible.
|
||||
- Fixed crashing when reading data with the setting `preferred_block_size_bytes=0.`
|
||||
- Fixed crashes of `clickhouse-client` when pressing `Page Down`
|
||||
- Correct interpretation of certain complex queries with `GLOBAL IN` and `UNION ALL`
|
||||
- `FREEZE PARTITION` always works atomically now.
|
||||
- Empty POST requests now return a response with code 411.
|
||||
- Fixed interpretation errors for expressions like `CAST(1 AS Nullable(UInt8)).`
|
||||
- Fixed an error when reading `Array(Nullable(String))` columns from `MergeTree` tables.
|
||||
- Fixed crashing when parsing queries like `SELECT dummy AS dummy, dummy AS b`
|
||||
- Users are updated correctly with invalid `users.xml`
|
||||
- Correct handling when an executable dictionary returns a non-zero response code.
|
||||
|
||||
### ClickHouse release 1.1.54292, 2017-09-20 {#clickhouse-release-1-1-54292-2017-09-20}
|
||||
|
||||
#### New features: {#new-features-2}
|
||||
|
||||
- Added the `pointInPolygon` function for working with coordinates on a coordinate plane.
|
||||
- Added the `sumMap` aggregate function for calculating the sum of arrays, similar to `SummingMergeTree`.
|
||||
- Added the `trunc` function. Improved performance of the rounding functions (`round`, `floor`, `ceil`, `roundToExp2`) and corrected the logic of how they work. Changed the logic of the `roundToExp2` function for fractions and negative numbers.
|
||||
- The ClickHouse executable file is now less dependent on the libc version. The same ClickHouse executable file can run on a wide variety of Linux systems. There is still a dependency when using compiled queries (with the setting `compile = 1` , which is not used by default).
|
||||
- Reduced the time needed for dynamic compilation of queries.
|
||||
|
||||
#### Bug fixes: {#bug-fixes-2}
|
||||
|
||||
- Fixed an error that sometimes produced `part ... intersects previous part` messages and weakened replica consistency.
|
||||
- Fixed an error that caused the server to lock up if ZooKeeper was unavailable during shutdown.
|
||||
- Removed excessive logging when restoring replicas.
|
||||
- Fixed an error in the UNION ALL implementation.
|
||||
- Fixed an error in the concat function that occurred if the first column in a block has the Array type.
|
||||
- Progress is now displayed correctly in the system.merges table.
|
||||
|
||||
### ClickHouse release 1.1.54289, 2017-09-13 {#clickhouse-release-1-1-54289-2017-09-13}
|
||||
|
||||
#### New features: {#new-features-3}
|
||||
|
||||
- `SYSTEM` queries for server administration: `SYSTEM RELOAD DICTIONARY`, `SYSTEM RELOAD DICTIONARIES`, `SYSTEM DROP DNS CACHE`, `SYSTEM SHUTDOWN`, `SYSTEM KILL`.
|
||||
- Added functions for working with arrays: `concat`, `arraySlice`, `arrayPushBack`, `arrayPushFront`, `arrayPopBack`, `arrayPopFront`.
|
||||
- Added `root` and `identity` parameters for the ZooKeeper configuration. This allows you to isolate individual users on the same ZooKeeper cluster.
|
||||
- Added aggregate functions `groupBitAnd`, `groupBitOr`, and `groupBitXor` (for compatibility, they are also available under the names `BIT_AND`, `BIT_OR`, and `BIT_XOR`).
|
||||
- External dictionaries can be loaded from MySQL by specifying a socket in the filesystem.
|
||||
- External dictionaries can be loaded from MySQL over SSL (`ssl_cert`, `ssl_key`, `ssl_ca` parameters).
|
||||
- Added the `max_network_bandwidth_for_user` setting to restrict the overall bandwidth use for queries per user.
|
||||
- Support for `DROP TABLE` for temporary tables.
|
||||
- Support for reading `DateTime` values in Unix timestamp format from the `CSV` and `JSONEachRow` formats.
|
||||
- Lagging replicas in distributed queries are now excluded by default (the default threshold is 5 minutes).
|
||||
- FIFO locking is used during ALTER: an ALTER query isn’t blocked indefinitely for continuously running queries.
|
||||
- Option to set `umask` in the config file.
|
||||
- Improved performance for queries with `DISTINCT` .
|
||||
|
||||
#### Bug fixes: {#bug-fixes-3}
|
||||
|
||||
- Improved the process for deleting old nodes in ZooKeeper. Previously, old nodes sometimes didn’t get deleted if there were very frequent inserts, which caused the server to be slow to shut down, among other things.
|
||||
- Fixed randomization when choosing hosts for the connection to ZooKeeper.
|
||||
- Fixed the exclusion of lagging replicas in distributed queries if the replica is localhost.
|
||||
- Fixed an error where a data part in a `ReplicatedMergeTree` table could be broken after running `ALTER MODIFY` on an element in a `Nested` structure.
|
||||
- Fixed an error that could cause SELECT queries to “hang”.
|
||||
- Improvements to distributed DDL queries.
|
||||
- Fixed the query `CREATE TABLE ... AS <materialized view>`.
|
||||
- Resolved the deadlock in the `ALTER ... CLEAR COLUMN IN PARTITION` query for `Buffer` tables.
|
||||
- Fixed the invalid default value for `Enum` s (0 instead of the minimum) when using the `JSONEachRow` and `TSKV` formats.
|
||||
- Resolved the appearance of zombie processes when using a dictionary with an `executable` source.
|
||||
- Fixed segfault for the HEAD query.
|
||||
|
||||
#### Improved workflow for developing and assembling ClickHouse: {#improved-workflow-for-developing-and-assembling-clickhouse}
|
||||
|
||||
- You can use `pbuilder` to build ClickHouse.
|
||||
- You can use `libc++` instead of `libstdc++` for builds on Linux.
|
||||
- Added instructions for using static code analysis tools: `Coverage`, `clang-tidy`, `cppcheck`.
|
||||
|
||||
#### Please note when upgrading: {#please-note-when-upgrading}
|
||||
|
||||
- There is now a higher default value for the MergeTree setting `max_bytes_to_merge_at_max_space_in_pool` (the maximum total size of data parts to merge, in bytes): it has increased from 100 GiB to 150 GiB. This might result in large merges running after the server upgrade, which could cause an increased load on the disk subsystem. If the free space available on the server is less than twice the total amount of the merges that are running, this will cause all other merges to stop running, including merges of small data parts. As a result, INSERT queries will fail with the message “Merges are processing significantly slower than inserts.” Use the `SELECT * FROM system.merges` query to monitor the situation. You can also check the `DiskSpaceReservedForMerge` metric in the `system.metrics` table, or in Graphite. You don’t need to do anything to fix this, since the issue will resolve itself once the large merges finish. If you find this unacceptable, you can restore the previous value for the `max_bytes_to_merge_at_max_space_in_pool` setting. To do this, go to the <merge_tree> section in config.xml, set ``` <merge_tree>``<max_bytes_to_merge_at_max_space_in_pool>107374182400</max_bytes_to_merge_at_max_space_in_pool> ``` and restart the server.
|
||||
|
||||
### ClickHouse release 1.1.54284, 2017-08-29 {#clickhouse-release-1-1-54284-2017-08-29}
|
||||
|
||||
- This is a bugfix release for the previous 1.1.54282 release. It fixes leaks in the parts directory in ZooKeeper.
|
||||
|
||||
### ClickHouse release 1.1.54282, 2017-08-23 {#clickhouse-release-1-1-54282-2017-08-23}
|
||||
|
||||
This release contains bug fixes for the previous release 1.1.54276:
|
||||
|
||||
- Fixed `DB::Exception: Assertion violation: !_path.empty()` when inserting into a Distributed table.
|
||||
- Fixed parsing when inserting in RowBinary format if input data starts with’;’.
|
||||
- Errors during runtime compilation of certain aggregate functions (e.g. `groupArray()`).
|
||||
|
||||
### Clickhouse Release 1.1.54276, 2017-08-16 {#clickhouse-release-1-1-54276-2017-08-16}
|
||||
|
||||
#### New features: {#new-features-4}
|
||||
|
||||
- Added an optional WITH section for a SELECT query. Example query: `WITH 1+1 AS a SELECT a, a*a`
|
||||
- INSERT can be performed synchronously in a Distributed table: OK is returned only after all the data is saved on all the shards. This is activated by the setting insert\_distributed\_sync=1.
|
||||
- Added the UUID data type for working with 16-byte identifiers.
|
||||
- Added aliases of CHAR, FLOAT and other types for compatibility with the Tableau.
|
||||
- Added the functions toYYYYMM, toYYYYMMDD, and toYYYYMMDDhhmmss for converting time into numbers.
|
||||
- You can use IP addresses (together with the hostname) to identify servers for clustered DDL queries.
|
||||
- Added support for non-constant arguments and negative offsets in the function `substring(str, pos, len).`
|
||||
- Added the max\_size parameter for the `groupArray(max_size)(column)` aggregate function, and optimized its performance.
|
||||
|
||||
#### Main changes: {#main-changes}
|
||||
|
||||
- Security improvements: all server files are created with 0640 permissions (can be changed via <umask> config parameter).
|
||||
- Improved error messages for queries with invalid syntax.
|
||||
- Significantly reduced memory consumption and improved performance when merging large sections of MergeTree data.
|
||||
- Significantly increased the performance of data merges for the ReplacingMergeTree engine.
|
||||
- Improved performance for asynchronous inserts from a Distributed table by combining multiple source inserts. To enable this functionality, use the setting distributed\_directory\_monitor\_batch\_inserts=1.
|
||||
|
||||
#### Backward incompatible changes: {#backward-incompatible-changes-1}
|
||||
|
||||
- Changed the binary format of aggregate states of `groupArray(array_column)` functions for arrays.
|
||||
|
||||
#### Complete list of changes: {#complete-list-of-changes}
|
||||
|
||||
- Added the `output_format_json_quote_denormals` setting, which enables outputting nan and inf values in JSON format.
|
||||
- Optimized stream allocation when reading from a Distributed table.
|
||||
- Settings can be configured in readonly mode if the value doesn’t change.
|
||||
- Added the ability to retrieve non-integer granules of the MergeTree engine in order to meet restrictions on the block size specified in the preferred\_block\_size\_bytes setting. The purpose is to reduce the consumption of RAM and increase cache locality when processing queries from tables with large columns.
|
||||
- Efficient use of indexes that contain expressions like `toStartOfHour(x)` for conditions like `toStartOfHour(x) op сonstexpr.`
|
||||
- Added new settings for MergeTree engines (the merge\_tree section in config.xml):
|
||||
- replicated\_deduplication\_window\_seconds sets the number of seconds allowed for deduplicating inserts in Replicated tables.
|
||||
- cleanup\_delay\_period sets how often to start cleanup to remove outdated data.
|
||||
- replicated\_can\_become\_leader can prevent a replica from becoming the leader (and assigning merges).
|
||||
- Accelerated cleanup to remove outdated data from ZooKeeper.
|
||||
- Multiple improvements and fixes for clustered DDL queries. Of particular interest is the new setting distributed\_ddl\_task\_timeout, which limits the time to wait for a response from the servers in the cluster. If a ddl request has not been performed on all hosts, a response will contain a timeout error and a request will be executed in an async mode.
|
||||
- Improved display of stack traces in the server logs.
|
||||
- Added the “none” value for the compression method.
|
||||
- You can use multiple dictionaries\_config sections in config.xml.
|
||||
- It is possible to connect to MySQL through a socket in the file system.
|
||||
- The system.parts table has a new column with information about the size of marks, in bytes.
|
||||
|
||||
#### Bug fixes: {#bug-fixes-4}
|
||||
|
||||
- Distributed tables using a Merge table now work correctly for a SELECT query with a condition on the `_table` field.
|
||||
- Fixed a rare race condition in ReplicatedMergeTree when checking data parts.
|
||||
- Fixed possible freezing on “leader election” when starting a server.
|
||||
- The max\_replica\_delay\_for\_distributed\_queries setting was ignored when using a local replica of the data source. This has been fixed.
|
||||
- Fixed incorrect behavior of `ALTER TABLE CLEAR COLUMN IN PARTITION` when attempting to clean a non-existing column.
|
||||
- Fixed an exception in the multiIf function when using empty arrays or strings.
|
||||
- Fixed excessive memory allocations when deserializing Native format.
|
||||
- Fixed incorrect auto-update of Trie dictionaries.
|
||||
- Fixed an exception when running queries with a GROUP BY clause from a Merge table when using SAMPLE.
|
||||
- Fixed a crash of GROUP BY when using distributed\_aggregation\_memory\_efficient=1.
|
||||
- Now you can specify the database.table in the right side of IN and JOIN.
|
||||
- Too many threads were used for parallel aggregation. This has been fixed.
|
||||
- Fixed how the “if” function works with FixedString arguments.
|
||||
- SELECT worked incorrectly from a Distributed table for shards with a weight of 0. This has been fixed.
|
||||
- Running `CREATE VIEW IF EXISTS no longer causes crashes.`
|
||||
- Fixed incorrect behavior when input\_format\_skip\_unknown\_fields=1 is set and there are negative numbers.
|
||||
- Fixed an infinite loop in the `dictGetHierarchy()` function if there is some invalid data in the dictionary.
|
||||
- Fixed `Syntax error: unexpected (...)` errors when running distributed queries with subqueries in an IN or JOIN clause and Merge tables.
|
||||
- Fixed an incorrect interpretation of a SELECT query from Dictionary tables.
|
||||
- Fixed the “Cannot mremap” error when using arrays in IN and JOIN clauses with more than 2 billion elements.
|
||||
- Fixed the failover for dictionaries with MySQL as the source.
|
||||
|
||||
#### Improved workflow for developing and assembling ClickHouse: {#improved-workflow-for-developing-and-assembling-clickhouse-1}
|
||||
|
||||
- Builds can be assembled in Arcadia.
|
||||
- You can use gcc 7 to compile ClickHouse.
|
||||
- Parallel builds using ccache+distcc are faster now.
|
||||
|
||||
### ClickHouse release 1.1.54245, 2017-07-04 {#clickhouse-release-1-1-54245-2017-07-04}
|
||||
|
||||
#### New features: {#new-features-5}
|
||||
|
||||
- Distributed DDL (for example, `CREATE TABLE ON CLUSTER`)
|
||||
- The replicated query `ALTER TABLE CLEAR COLUMN IN PARTITION.`
|
||||
- The engine for Dictionary tables (access to dictionary data in the form of a table).
|
||||
- Dictionary database engine (this type of database automatically has Dictionary tables available for all the connected external dictionaries).
|
||||
- You can check for updates to the dictionary by sending a request to the source.
|
||||
- Qualified column names
|
||||
- Quoting identifiers using double quotation marks.
|
||||
- Sessions in the HTTP interface.
|
||||
- The OPTIMIZE query for a Replicated table can can run not only on the leader.
|
||||
|
||||
#### Backward incompatible changes: {#backward-incompatible-changes-2}
|
||||
|
||||
- Removed SET GLOBAL.
|
||||
|
||||
#### Minor changes: {#minor-changes}
|
||||
|
||||
- Now after an alert is triggered, the log prints the full stack trace.
|
||||
- Relaxed the verification of the number of damaged/extra data parts at startup (there were too many false positives).
|
||||
|
||||
#### Bug fixes: {#bug-fixes-5}
|
||||
|
||||
- Fixed a bad connection “sticking” when inserting into a Distributed table.
|
||||
- GLOBAL IN now works for a query from a Merge table that looks at a Distributed table.
|
||||
- The incorrect number of cores was detected on a Google Compute Engine virtual machine. This has been fixed.
|
||||
- Changes in how an executable source of cached external dictionaries works.
|
||||
- Fixed the comparison of strings containing null characters.
|
||||
- Fixed the comparison of Float32 primary key fields with constants.
|
||||
- Previously, an incorrect estimate of the size of a field could lead to overly large allocations.
|
||||
- Fixed a crash when querying a Nullable column added to a table using ALTER.
|
||||
- Fixed a crash when sorting by a Nullable column, if the number of rows is less than LIMIT.
|
||||
- Fixed an ORDER BY subquery consisting of only constant values.
|
||||
- Previously, a Replicated table could remain in the invalid state after a failed DROP TABLE.
|
||||
- Aliases for scalar subqueries with empty results are no longer lost.
|
||||
- Now a query that used compilation does not fail with an error if the .so file gets damaged.
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@ -1 +0,0 @@
|
||||
../../../CHANGELOG.md
|
||||
@ -1,20 +1,16 @@
|
||||
---
|
||||
en_copy: true
|
||||
---
|
||||
# Поставщики облачных услуг ClickHouse {#clickhouse-cloud-service-providers}
|
||||
|
||||
# ClickHouse Cloud Service Providers {#clickhouse-cloud-service-providers}
|
||||
|
||||
!!! info "Info"
|
||||
If you have launched a public cloud with managed ClickHouse service, feel free to [open a pull-request](https://github.com/ClickHouse/ClickHouse/edit/master/docs/en/commercial/cloud.md) adding it to the following list.
|
||||
!!! info "Инфо"
|
||||
Если вы запустили публичный облачный сервис с управляемым ClickHouse, не стесняйтесь [открыть pull request](https://github.com/ClickHouse/ClickHouse/edit/master/docs/en/commercial/cloud.md) c добавлением его в последующий список.
|
||||
|
||||
## Yandex Cloud {#yandex-cloud}
|
||||
|
||||
[Yandex Managed Service for ClickHouse](https://cloud.yandex.com/services/managed-clickhouse?utm_source=referrals&utm_medium=clickhouseofficialsite&utm_campaign=link3) provides the following key features:
|
||||
[Yandex Managed Service for ClickHouse](https://cloud.yandex.ru/services/managed-clickhouse?utm_source=referrals&utm_medium=clickhouseofficialsite&utm_campaign=link3) предоставляет следующие ключевые возможности:
|
||||
|
||||
- Fully managed ZooKeeper service for [ClickHouse replication](../operations/table_engines/replication.md)
|
||||
- Multiple storage type choices
|
||||
- Replicas in different availability zones
|
||||
- Encryption and isolation
|
||||
- Automated maintenance
|
||||
- Полностью управляемый сервис ZooKeeper для [репликации ClickHouse](../engines/table_engines/mergetree_family/replication.md)
|
||||
- Выбор типа хранилища
|
||||
- Реплики в разных зонах доступности
|
||||
- Шифрование и изоляция
|
||||
- Автоматизированное техническое обслуживание
|
||||
|
||||
{## [Original article](https://clickhouse.tech/docs/en/commercial/cloud/) ##}
|
||||
{## [Оригинальная статья](https://clickhouse.tech/docs/ru/commercial/cloud/) ##}
|
||||
|
||||
7
docs/ru/commercial/index.md
Normal file
7
docs/ru/commercial/index.md
Normal file
@ -0,0 +1,7 @@
|
||||
---
|
||||
toc_folder_title: Commercial
|
||||
toc_priority: 70
|
||||
toc_title: Commercial
|
||||
---
|
||||
|
||||
|
||||
@ -1,200 +1,201 @@
|
||||
---
|
||||
en_copy: true
|
||||
machine_translated: true
|
||||
machine_translated_rev: 1cd5f0028d917696daf71ac1c9ee849c99c1d5c8
|
||||
---
|
||||
|
||||
# Overview of ClickHouse Architecture {#overview-of-clickhouse-architecture}
|
||||
# Обзор архитектуры ClickHouse {#overview-of-clickhouse-architecture}
|
||||
|
||||
ClickHouse is a true column-oriented DBMS. Data is stored by columns and during the execution of arrays (vectors or chunks of columns). Whenever possible, operations are dispatched on arrays, rather than on individual values. It is called “vectorized query execution,” and it helps lower the cost of actual data processing.
|
||||
ClickHouse-это настоящая СУБД, ориентированная на столбцы. Данные хранятся столбцами и во время выполнения массивов (векторов или кусков столбцов). Когда это возможно, операции отправляются на массивы, а не на отдельные значения. Это называется «vectorized query execution,» и это помогает снизить стоимость фактической обработки данных.
|
||||
|
||||
> This idea is nothing new. It dates back to the `APL` programming language and its descendants: `A +`, `J`, `K`, and `Q`. Array programming is used in scientific data processing. Neither is this idea something new in relational databases: for example, it is used in the `Vectorwise` system.
|
||||
> В этой идее нет ничего нового. Она восходит к тому времени, когда `APL` язык программирования и его потомки: `A +`, `J`, `K`, и `Q`. Массивное программирование используется в научной обработке данных. Эта идея также не является чем-то новым в реляционных базах данных: например, она используется в `Vectorwise` система.
|
||||
|
||||
There are two different approaches for speeding up query processing: vectorized query execution and runtime code generation. The latter removes all indirection and dynamic dispatch. Neither of these approaches is strictly better than the other. Runtime code generation can be better when it fuses many operations, thus fully utilizing CPU execution units and the pipeline. Vectorized query execution can be less practical because it involves temporary vectors that must be written to the cache and read back. If the temporary data does not fit in the L2 cache, this becomes an issue. But vectorized query execution more easily utilizes the SIMD capabilities of the CPU. A [research paper](http://15721.courses.cs.cmu.edu/spring2016/papers/p5-sompolski.pdf) written by our friends shows that it is better to combine both approaches. ClickHouse uses vectorized query execution and has limited initial support for runtime code generation.
|
||||
Существует два различных подхода для ускорения обработки запросов: векторизованное выполнение запросов и генерация кода во время выполнения. Последнее устраняет все косвенные действия и динамическую диспетчеризацию. Ни один из этих подходов не является строго лучшим, чем другой. Генерация кода во время выполнения может быть лучше, когда он объединяет множество операций, таким образом полностью используя исполнительные блоки процессора и конвейер. Векторизованное выполнение запроса может быть менее практичным, поскольку оно включает временные векторы, которые должны быть записаны в кэш и считаны обратно. Если временные данные не помещаются в кэш L2, это становится проблемой. Но векторизованное выполнение запросов более легко использует возможности SIMD центрального процессора. Один [научная статья](http://15721.courses.cs.cmu.edu/spring2016/papers/p5-sompolski.pdf) написанное нашими друзьями показывает, что лучше сочетать оба подхода. ClickHouse использует векторизованное выполнение запросов и имеет ограниченную начальную поддержку для генерации кода во время выполнения.
|
||||
|
||||
## Columns {#columns}
|
||||
## Столбцы {#columns}
|
||||
|
||||
`IColumn` interface is used to represent columns in memory (actually, chunks of columns). This interface provides helper methods for the implementation of various relational operators. Almost all operations are immutable: they do not modify the original column, but create a new modified one. For example, the `IColumn :: filter` method accepts a filter byte mask. It is used for the `WHERE` and `HAVING` relational operators. Additional examples: the `IColumn :: permute` method to support `ORDER BY`, the `IColumn :: cut` method to support `LIMIT`.
|
||||
`IColumn` интерфейс используется для представления столбцов в памяти (собственно, кусков столбцов). Этот интерфейс предоставляет вспомогательные методы для реализации различных реляционных операторов. Почти все операции неизменяемы: они не изменяют исходный столбец, а создают новый измененный. Например, в `IColumn :: filter` метод принимает маску байта фильтра. Он используется для `WHERE` и `HAVING` реляционный оператор. Дополнительные примеры: `IColumn :: permute` способ поддержки `ORDER BY`, этот `IColumn :: cut` способ поддержки `LIMIT`.
|
||||
|
||||
Various `IColumn` implementations (`ColumnUInt8`, `ColumnString`, and so on) are responsible for the memory layout of columns. The memory layout is usually a contiguous array. For the integer type of columns, it is just one contiguous array, like `std :: vector`. For `String` and `Array` columns, it is two vectors: one for all array elements, placed contiguously, and a second one for offsets to the beginning of each array. There is also `ColumnConst` that stores just one value in memory, but looks like a column.
|
||||
Различный `IColumn` реализации (`ColumnUInt8`, `ColumnString`, и так далее) отвечают за расположение столбцов в памяти. Расположение памяти обычно представляет собой непрерывный массив. Для целочисленного типа столбцов это всего лишь один непрерывный массив, например `std :: vector`. Для `String` и `Array` столбцы, это два вектора: один для всех элементов массива, расположенных последовательно, и второй для смещений к началу каждого массива. Существует также `ColumnConst` это сохраняет только одно значение в памяти, но выглядит как столбец.
|
||||
|
||||
## Field {#field}
|
||||
## Поле {#field}
|
||||
|
||||
Nevertheless, it is possible to work with individual values as well. To represent an individual value, the `Field` is used. `Field` is just a discriminated union of `UInt64`, `Int64`, `Float64`, `String` and `Array`. `IColumn` has the `operator[]` method to get the n-th value as a `Field` and the `insert` method to append a `Field` to the end of a column. These methods are not very efficient, because they require dealing with temporary `Field` objects representing an individual value. There are more efficient methods, such as `insertFrom`, `insertRangeFrom`, and so on.
|
||||
Тем не менее, можно работать и с индивидуальными ценностями. Чтобы представить индивидуальную ценность, то `Field` предназначенный. `Field` это просто дискриминированный Союз `UInt64`, `Int64`, `Float64`, `String` и `Array`. `IColumn` имеет `operator[]` метод получения n-го значения в виде a `Field` и `insert` способ, чтобы добавить `Field` до самого конца колонны. Эти методы не очень эффективны, потому что они требуют решения временных проблем `Field` объекты, представляющие индивидуальную ценность. Существуют и более эффективные методы, такие как `insertFrom`, `insertRangeFrom` и так далее.
|
||||
|
||||
`Field` doesn’t have enough information about a specific data type for a table. For example, `UInt8`, `UInt16`, `UInt32`, and `UInt64` are all represented as `UInt64` in a `Field`.
|
||||
`Field` у него нет достаточной информации о конкретном типе данных для таблицы. Например, `UInt8`, `UInt16`, `UInt32`, и `UInt64` все они представлены в виде `UInt64` в `Field`.
|
||||
|
||||
## Leaky Abstractions {#leaky-abstractions}
|
||||
## Дырявые абстракции {#leaky-abstractions}
|
||||
|
||||
`IColumn` has methods for common relational transformations of data, but they don’t meet all needs. For example, `ColumnUInt64` doesn’t have a method to calculate the sum of two columns, and `ColumnString` doesn’t have a method to run a substring search. These countless routines are implemented outside of `IColumn`.
|
||||
`IColumn` есть методы для общих реляционных преобразований данных, но они не удовлетворяют всем потребностям. Например, `ColumnUInt64` не имеет метода для вычисления суммы двух столбцов, и `ColumnString` у него нет метода для запуска поиска по подстрокам. Эти бесчисленные процедуры реализуются за пределами `IColumn`.
|
||||
|
||||
Various functions on columns can be implemented in a generic, non-efficient way using `IColumn` methods to extract `Field` values, or in a specialized way using knowledge of inner memory layout of data in a specific `IColumn` implementation. It is implemented by casting functions to a specific `IColumn` type and deal with internal representation directly. For example, `ColumnUInt64` has the `getData` method that returns a reference to an internal array, then a separate routine reads or fills that array directly. We have “leaky abstractions” to allow efficient specializations of various routines.
|
||||
Различные функции на столбцах могут быть реализованы общим, неэффективным способом с использованием `IColumn` способы извлечения `Field` значения, или специализированным способом, использующим знание внутренней компоновки памяти данных в определенном месте. `IColumn` реализация. Он реализуется путем приведения функций к определенному виду `IColumn` тип и дело с внутренним представлением непосредственно. Например, `ColumnUInt64` имеет `getData` метод, который возвращает ссылку на внутренний массив, а затем отдельная процедура считывает или заполняет этот массив непосредственно. У нас есть «leaky abstractions» чтобы обеспечить эффективную специализацию различных процедур.
|
||||
|
||||
## Data Types {#data_types}
|
||||
## Тип данных {#data_types}
|
||||
|
||||
`IDataType` is responsible for serialization and deserialization: for reading and writing chunks of columns or individual values in binary or text form. `IDataType` directly corresponds to data types in tables. For example, there are `DataTypeUInt32`, `DataTypeDateTime`, `DataTypeString` and so on.
|
||||
`IDataType` отвечает за сериализацию и десериализацию: чтение и запись фрагментов столбцов или отдельных значений в двоичной или текстовой форме. `IDataType` непосредственно соответствует типам данных в таблицах. Например, существуют `DataTypeUInt32`, `DataTypeDateTime`, `DataTypeString` и так далее.
|
||||
|
||||
`IDataType` and `IColumn` are only loosely related to each other. Different data types can be represented in memory by the same `IColumn` implementations. For example, `DataTypeUInt32` and `DataTypeDateTime` are both represented by `ColumnUInt32` or `ColumnConstUInt32`. In addition, the same data type can be represented by different `IColumn` implementations. For example, `DataTypeUInt8` can be represented by `ColumnUInt8` or `ColumnConstUInt8`.
|
||||
`IDataType` и `IColumn` они лишь слабо связаны друг с другом. Различные типы данных могут быть представлены в памяти одним и тем же именем `IColumn` реализации. Например, `DataTypeUInt32` и `DataTypeDateTime` оба они представлены следующим образом `ColumnUInt32` или `ColumnConstUInt32`. Кроме того, один и тот же тип данных может быть представлен разными `IColumn` реализации. Например, `DataTypeUInt8` может быть представлен следующим образом `ColumnUInt8` или `ColumnConstUInt8`.
|
||||
|
||||
`IDataType` only stores metadata. For instance, `DataTypeUInt8` doesn’t store anything at all (except vptr) and `DataTypeFixedString` stores just `N` (the size of fixed-size strings).
|
||||
`IDataType` хранит только метаданные. Например, `DataTypeUInt8` не хранит вообще ничего (кроме vptr) и `DataTypeFixedString` магазины просто `N` (размер строк фиксированного размера).
|
||||
|
||||
`IDataType` has helper methods for various data formats. Examples are methods to serialize a value with possible quoting, to serialize a value for JSON, and to serialize a value as part of the XML format. There is no direct correspondence to data formats. For example, the different data formats `Pretty` and `TabSeparated` can use the same `serializeTextEscaped` helper method from the `IDataType` interface.
|
||||
`IDataType` имеет вспомогательные методы для различных форматов данных. Примерами являются методы сериализации значения с возможным цитированием, сериализации значения для JSON и сериализации значения в формате XML. Прямого соответствия форматам данных не существует. Например, различные форматы данных `Pretty` и `TabSeparated` можно использовать то же самое `serializeTextEscaped` вспомогательный метод от `IDataType` интерфейс.
|
||||
|
||||
## Block {#block}
|
||||
## Блок {#block}
|
||||
|
||||
A `Block` is a container that represents a subset (chunk) of a table in memory. It is just a set of triples: `(IColumn, IDataType, column name)`. During query execution, data is processed by `Block`s. If we have a `Block`, we have data (in the `IColumn` object), we have information about its type (in `IDataType`) that tells us how to deal with that column, and we have the column name. It could be either the original column name from the table or some artificial name assigned for getting temporary results of calculations.
|
||||
A `Block` это контейнер, представляющий подмножество (фрагмент) таблицы в памяти. Это всего лишь набор троек: `(IColumn, IDataType, column name)`. Во время выполнения запроса данные обрабатываются с помощью `Block`s. Если у нас есть `Block`, у нас есть данные (в `IColumn` объект), у нас есть информация о его типе (в `IDataType`) это говорит нам, как обращаться с этим столбцом, и у нас есть имя столбца. Это может быть либо исходное имя столбца из таблицы, либо какое-то искусственное имя, назначенное для получения временных результатов вычислений.
|
||||
|
||||
When we calculate some function over columns in a block, we add another column with its result to the block, and we don’t touch columns for arguments of the function because operations are immutable. Later, unneeded columns can be removed from the block, but not modified. It is convenient for the elimination of common subexpressions.
|
||||
Когда мы вычисляем некоторую функцию по столбцам в блоке, мы добавляем другой столбец с его результатом в блок, и мы не касаемся столбцов для аргументов функции, потому что операции неизменяемы. Позже ненужные столбцы могут быть удалены из блока, но не изменены. Это удобно для исключения общих подвыражений.
|
||||
|
||||
Blocks are created for every processed chunk of data. Note that for the same type of calculation, the column names and types remain the same for different blocks, and only column data changes. It is better to split block data from the block header because small block sizes have a high overhead of temporary strings for copying shared\_ptrs and column names.
|
||||
Блоки создаются для каждого обработанного фрагмента данных. Обратите внимание, что для одного и того же типа вычисления имена столбцов и типы остаются одинаковыми для разных блоков, и изменяются только данные столбцов. Лучше разделить данные блока из заголовка блока, потому что небольшие размеры блока имеют высокую нагрузку временных строк для копирования shared\_ptrs и имен столбцов.
|
||||
|
||||
## Block Streams {#block-streams}
|
||||
## Блокировать Потоки {#block-streams}
|
||||
|
||||
Block streams are for processing data. We use streams of blocks to read data from somewhere, perform data transformations, or write data to somewhere. `IBlockInputStream` has the `read` method to fetch the next block while available. `IBlockOutputStream` has the `write` method to push the block somewhere.
|
||||
Блочные потоки предназначены для обработки данных. Мы используем потоки блоков для чтения данных откуда-то, выполнения преобразований данных или записи данных куда-то. `IBlockInputStream` имеет `read` метод для извлечения следующего блока, пока он доступен. `IBlockOutputStream` имеет `write` метод, чтобы подтолкнуть блок куда-то.
|
||||
|
||||
Streams are responsible for:
|
||||
Потоки отвечают за:
|
||||
|
||||
1. Reading or writing to a table. The table just returns a stream for reading or writing blocks.
|
||||
2. Implementing data formats. For example, if you want to output data to a terminal in `Pretty` format, you create a block output stream where you push blocks, and it formats them.
|
||||
3. Performing data transformations. Let’s say you have `IBlockInputStream` and want to create a filtered stream. You create `FilterBlockInputStream` and initialize it with your stream. Then when you pull a block from `FilterBlockInputStream`, it pulls a block from your stream, filters it, and returns the filtered block to you. Query execution pipelines are represented this way.
|
||||
1. Чтение или письмо за столом. Таблица просто возвращает поток для чтения или записи блоков.
|
||||
2. Реализация форматов данных. Например, если вы хотите вывести данные на терминал в `Pretty` форматирование, вы создаете поток вывода блока, где вы толкаете блоки, и он форматирует их.
|
||||
3. Выполнение преобразований данных. Скажем так у вас есть `IBlockInputStream` и хотите создать отфильтрованный поток. Вы создаете `FilterBlockInputStream` и инициализируйте его с помощью своего потока. Затем, когда вы вытащите блок из `FilterBlockInputStream`, он извлекает блок из вашего потока, фильтрует его и возвращает отфильтрованный блок вам. Конвейеры выполнения запросов представлены таким образом.
|
||||
|
||||
There are more sophisticated transformations. For example, when you pull from `AggregatingBlockInputStream`, it reads all data from its source, aggregates it, and then returns a stream of aggregated data for you. Another example: `UnionBlockInputStream` accepts many input sources in the constructor and also a number of threads. It launches multiple threads and reads from multiple sources in parallel.
|
||||
Есть и более сложные трансформации. Например, когда вы тянете из `AggregatingBlockInputStream`, он считывает все данные из своего источника, агрегирует их, а затем возвращает поток агрегированных данных для вас. Еще пример: `UnionBlockInputStream` принимает множество источников ввода в конструкторе, а также ряд потоков. Он запускает несколько потоков и читает из нескольких источников параллельно.
|
||||
|
||||
> Block streams use the “pull” approach to control flow: when you pull a block from the first stream, it consequently pulls the required blocks from nested streams, and the entire execution pipeline will work. Neither “pull” nor “push” is the best solution, because control flow is implicit, and that limits the implementation of various features like simultaneous execution of multiple queries (merging many pipelines together). This limitation could be overcome with coroutines or just running extra threads that wait for each other. We may have more possibilities if we make control flow explicit: if we locate the logic for passing data from one calculation unit to another outside of those calculation units. Read this [article](http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-out/) for more thoughts.
|
||||
> Потоки блокируют использовать «pull» подход к управлению потоком: когда вы вытягиваете блок из первого потока, он, следовательно, вытягивает необходимые блоки из вложенных потоков, и весь конвейер выполнения будет работать. Ни «pull» ни «push» это лучшее решение, потому что поток управления является неявным, и это ограничивает реализацию различных функций, таких как одновременное выполнение нескольких запросов (объединение многих конвейеров вместе). Это ограничение может быть преодолено с помощью сопрограмм или просто запуском дополнительных потоков, которые ждут друг друга. У нас может быть больше возможностей, если мы сделаем поток управления явным: если мы найдем логику для передачи данных из одной расчетной единицы в другую вне этих расчетных единиц. Читать это [статья](http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-out/) для новых мыслей.
|
||||
|
||||
We should note that the query execution pipeline creates temporary data at each step. We try to keep block size small enough so that temporary data fits in the CPU cache. With that assumption, writing and reading temporary data is almost free in comparison with other calculations. We could consider an alternative, which is to fuse many operations in the pipeline together. It could make the pipeline as short as possible and remove much of the temporary data, which could be an advantage, but it also has drawbacks. For example, a split pipeline makes it easy to implement caching intermediate data, stealing intermediate data from similar queries running at the same time, and merging pipelines for similar queries.
|
||||
Следует отметить, что конвейер выполнения запроса создает временные данные на каждом шаге. Мы стараемся держать размер блока достаточно маленьким, чтобы временные данные помещались в кэш процессора. При таком допущении запись и чтение временных данных практически бесплатны по сравнению с другими расчетами. Мы могли бы рассмотреть альтернативу, которая заключается в том, чтобы объединить многие операции в трубопроводе вместе. Это может сделать конвейер как можно короче и удалить большую часть временных данных, что может быть преимуществом, но у него также есть недостатки. Например, разделенный конвейер позволяет легко реализовать кэширование промежуточных данных, кражу промежуточных данных из аналогичных запросов, выполняемых одновременно, и объединение конвейеров для аналогичных запросов.
|
||||
|
||||
## Formats {#formats}
|
||||
## Форматы {#formats}
|
||||
|
||||
Data formats are implemented with block streams. There are “presentational” formats only suitable for the output of data to the client, such as `Pretty` format, which provides only `IBlockOutputStream`. And there are input/output formats, such as `TabSeparated` or `JSONEachRow`.
|
||||
Форматы данных реализуются с помощью блочных потоков. Есть «presentational» форматы, пригодные только для вывода данных клиенту, такие как `Pretty` формат, который предоставляет только `IBlockOutputStream`. И есть форматы ввода/вывода, такие как `TabSeparated` или `JSONEachRow`.
|
||||
|
||||
There are also row streams: `IRowInputStream` and `IRowOutputStream`. They allow you to pull/push data by individual rows, not by blocks. And they are only needed to simplify the implementation of row-oriented formats. The wrappers `BlockInputStreamFromRowInputStream` and `BlockOutputStreamFromRowOutputStream` allow you to convert row-oriented streams to regular block-oriented streams.
|
||||
Существуют также потоки подряд : `IRowInputStream` и `IRowOutputStream`. Они позволяют вытягивать / выталкивать данные отдельными строками, а не блоками. И они нужны только для упрощения реализации ориентированных на строки форматов. Обертка `BlockInputStreamFromRowInputStream` и `BlockOutputStreamFromRowOutputStream` позволяет конвертировать потоки, ориентированные на строки, в обычные потоки, ориентированные на блоки.
|
||||
|
||||
## I/O {#io}
|
||||
|
||||
For byte-oriented input/output, there are `ReadBuffer` and `WriteBuffer` abstract classes. They are used instead of C++ `iostream`s. Don’t worry: every mature C++ project is using something other than `iostream`s for good reasons.
|
||||
Для байт-ориентированных входов / выходов существуют `ReadBuffer` и `WriteBuffer` абстрактный класс. Они используются вместо C++ `iostream`s. Не волнуйтесь: каждый зрелый проект C++ использует что-то другое, чем `iostream`s по уважительным причинам.
|
||||
|
||||
`ReadBuffer` and `WriteBuffer` are just a contiguous buffer and a cursor pointing to the position in that buffer. Implementations may own or not own the memory for the buffer. There is a virtual method to fill the buffer with the following data (for `ReadBuffer`) or to flush the buffer somewhere (for `WriteBuffer`). The virtual methods are rarely called.
|
||||
`ReadBuffer` и `WriteBuffer` это просто непрерывный буфер и курсор, указывающий на позицию в этом буфере. Реализации могут владеть или не владеть памятью для буфера. Существует виртуальный метод заполнения буфера следующими данными (для `ReadBuffer`) или смыть буфер куда-нибудь (например `WriteBuffer`). Виртуальные методы редко вызываются.
|
||||
|
||||
Implementations of `ReadBuffer`/`WriteBuffer` are used for working with files and file descriptors and network sockets, for implementing compression (`CompressedWriteBuffer` is initialized with another WriteBuffer and performs compression before writing data to it), and for other purposes – the names `ConcatReadBuffer`, `LimitReadBuffer`, and `HashingWriteBuffer` speak for themselves.
|
||||
Реализация следующих принципов: `ReadBuffer`/`WriteBuffer` используются для работы с файлами и файловыми дескрипторами, а также сетевыми сокетами, для реализации сжатия (`CompressedWriteBuffer` is initialized with another WriteBuffer and performs compression before writing data to it), and for other purposes – the names `ConcatReadBuffer`, `LimitReadBuffer`, и `HashingWriteBuffer` за себя говорить.
|
||||
|
||||
Read/WriteBuffers only deal with bytes. There are functions from `ReadHelpers` and `WriteHelpers` header files to help with formatting input/output. For example, there are helpers to write a number in decimal format.
|
||||
Буферы чтения/записи имеют дело только с байтами. Есть функции от `ReadHelpers` и `WriteHelpers` заголовочные файлы, чтобы помочь с форматированием ввода / вывода. Например, есть помощники для записи числа в десятичном формате.
|
||||
|
||||
Let’s look at what happens when you want to write a result set in `JSON` format to stdout. You have a result set ready to be fetched from `IBlockInputStream`. You create `WriteBufferFromFileDescriptor(STDOUT_FILENO)` to write bytes to stdout. You create `JSONRowOutputStream`, initialized with that `WriteBuffer`, to write rows in `JSON` to stdout. You create `BlockOutputStreamFromRowOutputStream` on top of it, to represent it as `IBlockOutputStream`. Then you call `copyData` to transfer data from `IBlockInputStream` to `IBlockOutputStream`, and everything works. Internally, `JSONRowOutputStream` will write various JSON delimiters and call the `IDataType::serializeTextJSON` method with a reference to `IColumn` and the row number as arguments. Consequently, `IDataType::serializeTextJSON` will call a method from `WriteHelpers.h`: for example, `writeText` for numeric types and `writeJSONString` for `DataTypeString`.
|
||||
Давайте посмотрим, что происходит, когда вы хотите написать результирующий набор в `JSON` форматирование в stdout. У вас есть результирующий набор, готовый к извлечению из него `IBlockInputStream`. Вы создаете `WriteBufferFromFileDescriptor(STDOUT_FILENO)` чтобы записать байты в stdout. Вы создаете `JSONRowOutputStream`, инициализируется с помощью этого `WriteBuffer`, чтобы записать строки в `JSON` в stdout. Вы создаете `BlockOutputStreamFromRowOutputStream` кроме того, чтобы представить его как `IBlockOutputStream`. А потом ты позвонишь `copyData` для передачи данных из `IBlockInputStream` к `IBlockOutputStream` и все это работает. Внутренне, `JSONRowOutputStream` буду писать в формате JSON различные разделители и вызвать `IDataType::serializeTextJSON` метод со ссылкой на `IColumn` и номер строки в качестве аргументов. Следовательно, `IDataType::serializeTextJSON` вызовет метод из `WriteHelpers.h`: например, `writeText` для числовых типов и `writeJSONString` для `DataTypeString`.
|
||||
|
||||
## Tables {#tables}
|
||||
## Таблицы {#tables}
|
||||
|
||||
The `IStorage` interface represents tables. Different implementations of that interface are different table engines. Examples are `StorageMergeTree`, `StorageMemory`, and so on. Instances of these classes are just tables.
|
||||
То `IStorage` интерфейс представляет собой таблицы. Различные реализации этого интерфейса являются различными движками таблиц. Примеры `StorageMergeTree`, `StorageMemory` и так далее. Экземпляры этих классов являются просто таблицами.
|
||||
|
||||
The key `IStorage` methods are `read` and `write`. There are also `alter`, `rename`, `drop`, and so on. The `read` method accepts the following arguments: the set of columns to read from a table, the `AST` query to consider, and the desired number of streams to return. It returns one or multiple `IBlockInputStream` objects and information about the stage of data processing that was completed inside a table engine during query execution.
|
||||
Ключ `IStorage` методы `read` и `write`. Есть и другие варианты `alter`, `rename`, `drop` и так далее. То `read` метод принимает следующие аргументы: набор столбцов для чтения из таблицы, набор столбцов для чтения из таблицы. `AST` запрос для рассмотрения и желаемое количество потоков для возврата. Он возвращает один или несколько `IBlockInputStream` объекты и информация о стадии обработки данных, которая была завершена внутри табличного движка во время выполнения запроса.
|
||||
|
||||
In most cases, the read method is only responsible for reading the specified columns from a table, not for any further data processing. All further data processing is done by the query interpreter and is outside the responsibility of `IStorage`.
|
||||
В большинстве случаев метод read отвечает только за чтение указанных столбцов из таблицы, а не за дальнейшую обработку данных. Вся дальнейшая обработка данных осуществляется интерпретатором запросов и не входит в сферу ответственности компании `IStorage`.
|
||||
|
||||
But there are notable exceptions:
|
||||
Но есть и заметные исключения:
|
||||
|
||||
- The AST query is passed to the `read` method, and the table engine can use it to derive index usage and to read fewer data from a table.
|
||||
- Sometimes the table engine can process data itself to a specific stage. For example, `StorageDistributed` can send a query to remote servers, ask them to process data to a stage where data from different remote servers can be merged, and return that preprocessed data. The query interpreter then finishes processing the data.
|
||||
- Запрос AST передается на сервер `read` метод, и механизм таблиц может использовать его для получения использования индекса и считывания меньшего количества данных из таблицы.
|
||||
- Иногда механизм таблиц может сам обрабатывать данные до определенного этапа. Например, `StorageDistributed` можно отправить запрос на удаленные серверы, попросить их обработать данные на этапе, когда данные с разных удаленных серверов могут быть объединены, и вернуть эти предварительно обработанные данные. Затем интерпретатор запросов завершает обработку данных.
|
||||
|
||||
The table’s `read` method can return multiple `IBlockInputStream` objects to allow parallel data processing. These multiple block input streams can read from a table in parallel. Then you can wrap these streams with various transformations (such as expression evaluation or filtering) that can be calculated independently and create a `UnionBlockInputStream` on top of them, to read from multiple streams in parallel.
|
||||
Стол `read` метод может возвращать несколько значений `IBlockInputStream` объекты, позволяющие осуществлять параллельную обработку данных. Эти несколько блочных входных потоков могут считываться из таблицы параллельно. Затем вы можете обернуть эти потоки с помощью различных преобразований (таких как вычисление выражений или фильтрация), которые могут быть вычислены независимо, и создать `UnionBlockInputStream` поверх них, чтобы читать из нескольких потоков параллельно.
|
||||
|
||||
There are also `TableFunction`s. These are functions that return a temporary `IStorage` object to use in the `FROM` clause of a query.
|
||||
Есть и другие варианты `TableFunction`s. Это функции, которые возвращают временное значение `IStorage` объект для использования в `FROM` предложение запроса.
|
||||
|
||||
To get a quick idea of how to implement your table engine, look at something simple, like `StorageMemory` or `StorageTinyLog`.
|
||||
Чтобы получить быстрое представление о том, как реализовать свой движок таблиц, посмотрите на что-то простое, например `StorageMemory` или `StorageTinyLog`.
|
||||
|
||||
> As the result of the `read` method, `IStorage` returns `QueryProcessingStage` – information about what parts of the query were already calculated inside storage.
|
||||
> В результате этого `read` метод, `IStorage` возвращается `QueryProcessingStage` – information about what parts of the query were already calculated inside storage.
|
||||
|
||||
## Parsers {#parsers}
|
||||
## Синтаксический анализатор {#parsers}
|
||||
|
||||
A hand-written recursive descent parser parses a query. For example, `ParserSelectQuery` just recursively calls the underlying parsers for various parts of the query. Parsers create an `AST`. The `AST` is represented by nodes, which are instances of `IAST`.
|
||||
Написанный от руки рекурсивный парсер спуска анализирует запрос. Например, `ParserSelectQuery` просто рекурсивно вызывает базовые Парсеры для различных частей запроса. Парсеры создают `AST`. То `AST` представлен узлами, которые являются экземплярами `IAST`.
|
||||
|
||||
> Parser generators are not used for historical reasons.
|
||||
> Генераторы парсеров не используются по историческим причинам.
|
||||
|
||||
## Interpreters {#interpreters}
|
||||
## Переводчики {#interpreters}
|
||||
|
||||
Interpreters are responsible for creating the query execution pipeline from an `AST`. There are simple interpreters, such as `InterpreterExistsQuery` and `InterpreterDropQuery`, or the more sophisticated `InterpreterSelectQuery`. The query execution pipeline is a combination of block input or output streams. For example, the result of interpreting the `SELECT` query is the `IBlockInputStream` to read the result set from; the result of the INSERT query is the `IBlockOutputStream` to write data for insertion to, and the result of interpreting the `INSERT SELECT` query is the `IBlockInputStream` that returns an empty result set on the first read, but that copies data from `SELECT` to `INSERT` at the same time.
|
||||
Интерпретаторы отвечают за создание конвейера выполнения запроса из `AST`. Есть простые переводчики, такие как `InterpreterExistsQuery` и `InterpreterDropQuery` или более изощренные `InterpreterSelectQuery`. Конвейер выполнения запроса представляет собой комбинацию блочных входных и выходных потоков. Например, результат интерпретации `SELECT` запросов `IBlockInputStream` для чтения результирующего набора из; результат запроса INSERT - это `IBlockOutputStream` чтобы записать данные для вставки в, и результат интерпретации `INSERT SELECT` запросов `IBlockInputStream` это возвращает пустой результирующий набор при первом чтении, но копирует данные из него `SELECT` к `INSERT` в то же время.
|
||||
|
||||
`InterpreterSelectQuery` uses `ExpressionAnalyzer` and `ExpressionActions` machinery for query analysis and transformations. This is where most rule-based query optimizations are done. `ExpressionAnalyzer` is quite messy and should be rewritten: various query transformations and optimizations should be extracted to separate classes to allow modular transformations or query.
|
||||
`InterpreterSelectQuery` использует `ExpressionAnalyzer` и `ExpressionActions` машины для анализа запросов и преобразований. Именно здесь выполняется большинство оптимизаций запросов на основе правил. `ExpressionAnalyzer` это довольно грязно и должно быть переписано: различные преобразования запросов и оптимизации должны быть извлечены в отдельные классы, чтобы позволить модульные преобразования или запрос.
|
||||
|
||||
## Functions {#functions}
|
||||
## Функции {#functions}
|
||||
|
||||
There are ordinary functions and aggregate functions. For aggregate functions, see the next section.
|
||||
Существуют обычные функции и агрегатные функции. Агрегатные функции см. В следующем разделе.
|
||||
|
||||
Ordinary functions don’t change the number of rows – they work as if they are processing each row independently. In fact, functions are not called for individual rows, but for `Block`’s of data to implement vectorized query execution.
|
||||
Ordinary functions don't change the number of rows – they work as if they are processing each row independently. In fact, functions are not called for individual rows, but for `Block`'s данных для реализации векторизованного выполнения запросов.
|
||||
|
||||
There are some miscellaneous functions, like [blockSize](../query_language/functions/other_functions.md#function-blocksize), [rowNumberInBlock](../query_language/functions/other_functions.md#function-rownumberinblock), and [runningAccumulate](../query_language/functions/other_functions.md#function-runningaccumulate), that exploit block processing and violate the independence of rows.
|
||||
Есть некоторые другие функции, такие как [размер блока](../sql_reference/functions/other_functions.md#function-blocksize), [роунумберинблок](../sql_reference/functions/other_functions.md#function-rownumberinblock), и [runningAccumulate](../sql_reference/functions/other_functions.md#function-runningaccumulate), которые эксплуатируют обработку блоков и нарушают независимость строк.
|
||||
|
||||
ClickHouse has strong typing, so there’s no implicit type conversion. If a function doesn’t support a specific combination of types, it throws an exception. But functions can work (be overloaded) for many different combinations of types. For example, the `plus` function (to implement the `+` operator) works for any combination of numeric types: `UInt8` + `Float32`, `UInt16` + `Int8`, and so on. Also, some variadic functions can accept any number of arguments, such as the `concat` function.
|
||||
ClickHouse имеет сильную типизацию, поэтому нет никакого неявного преобразования типов. Если функция не поддерживает определенную комбинацию типов, она создает исключение. Но функции могут работать (перегружаться) для многих различных комбинаций типов. Например, в `plus` функция (для реализации `+` оператор) работает для любой комбинации числовых типов: `UInt8` + `Float32`, `UInt16` + `Int8` и так далее. Кроме того, некоторые вариадические функции могут принимать любое количество аргументов, например `concat` функция.
|
||||
|
||||
Implementing a function may be slightly inconvenient because a function explicitly dispatches supported data types and supported `IColumns`. For example, the `plus` function has code generated by instantiation of a C++ template for each combination of numeric types, and constant or non-constant left and right arguments.
|
||||
Реализация функции может быть немного неудобной, поскольку функция явно отправляет поддерживаемые типы данных и поддерживается `IColumns`. Например, в `plus` функция имеет код, генерируемый экземпляром шаблона C++ для каждой комбинации числовых типов, а также постоянные или непостоянные левые и правые аргументы.
|
||||
|
||||
It is an excellent place to implement runtime code generation to avoid template code bloat. Also, it makes it possible to add fused functions like fused multiply-add or to make multiple comparisons in one loop iteration.
|
||||
Это отличное место для реализации генерации кода во время выполнения, чтобы избежать раздувания кода шаблона. Кроме того, он позволяет добавлять слитые функции, такие как fused multiply-add или выполнять несколько сравнений в одной итерации цикла.
|
||||
|
||||
Due to vectorized query execution, functions are not short-circuited. For example, if you write `WHERE f(x) AND g(y)`, both sides are calculated, even for rows, when `f(x)` is zero (except when `f(x)` is a zero constant expression). But if the selectivity of the `f(x)` condition is high, and calculation of `f(x)` is much cheaper than `g(y)`, it’s better to implement multi-pass calculation. It would first calculate `f(x)`, then filter columns by the result, and then calculate `g(y)` only for smaller, filtered chunks of data.
|
||||
Из-за векторизованного выполнения запроса функции не закорачиваются. Например, если вы пишете `WHERE f(x) AND g(y)`, обе стороны вычисляются, даже для строк, когда `f(x)` равно нулю (за исключением тех случаев, когда `f(x)` является нулевым постоянным выражением). Но если избирательность самого `f(x)` состояние является высоким, и расчет `f(x)` это гораздо дешевле, чем `g(y)`, лучше всего реализовать многоходовой расчет. Это будет первый расчет `f(x)`, затем отфильтруйте столбцы по результату, а затем вычислите `g(y)` только для небольших отфильтрованных фрагментов данных.
|
||||
|
||||
## Aggregate Functions {#aggregate-functions}
|
||||
## Статистическая функция {#aggregate-functions}
|
||||
|
||||
Aggregate functions are stateful functions. They accumulate passed values into some state and allow you to get results from that state. They are managed with the `IAggregateFunction` interface. States can be rather simple (the state for `AggregateFunctionCount` is just a single `UInt64` value) or quite complex (the state of `AggregateFunctionUniqCombined` is a combination of a linear array, a hash table, and a `HyperLogLog` probabilistic data structure).
|
||||
Агрегатные функции - это функции, определяющие состояние. Они накапливают переданные значения в некотором состоянии и позволяют получать результаты из этого состояния. Они управляются с помощью `IAggregateFunction` интерфейс. Состояния могут быть довольно простыми (состояние для `AggregateFunctionCount` это всего лишь один человек `UInt64` значение) или довольно сложное (состояние `AggregateFunctionUniqCombined` представляет собой комбинацию линейного массива, хэш-таблицы и `HyperLogLog` вероятностная структура данных).
|
||||
|
||||
States are allocated in `Arena` (a memory pool) to deal with multiple states while executing a high-cardinality `GROUP BY` query. States can have a non-trivial constructor and destructor: for example, complicated aggregation states can allocate additional memory themselves. It requires some attention to creating and destroying states and properly passing their ownership and destruction order.
|
||||
Государства распределяются в `Arena` (пул памяти) для работы с несколькими состояниями при выполнении высокой мощности `GROUP BY` запрос. Состояния могут иметь нетривиальный конструктор и деструктор: например, сложные агрегатные состояния могут сами выделять дополнительную память. Это требует некоторого внимания к созданию и уничтожению государств и правильной передаче их права собственности и порядка уничтожения.
|
||||
|
||||
Aggregation states can be serialized and deserialized to pass over the network during distributed query execution or to write them on the disk where there is not enough RAM. They can even be stored in a table with the `DataTypeAggregateFunction` to allow incremental aggregation of data.
|
||||
Агрегатные состояния могут быть сериализованы и десериализованы для передачи по сети во время выполнения распределенного запроса или для записи их на диск, где недостаточно оперативной памяти. Они даже могут храниться в таблице с `DataTypeAggregateFunction` чтобы разрешить инкрементное агрегирование данных.
|
||||
|
||||
> The serialized data format for aggregate function states is not versioned right now. It is ok if aggregate states are only stored temporarily. But we have the `AggregatingMergeTree` table engine for incremental aggregation, and people are already using it in production. It is the reason why backward compatibility is required when changing the serialized format for any aggregate function in the future.
|
||||
> Сериализованный формат данных для состояний агрегатных функций в настоящее время не является версионным. Это нормально, если агрегатные состояния хранятся только временно. Но у нас есть такая возможность `AggregatingMergeTree` механизм таблиц для инкрементного агрегирования, и люди уже используют его в производстве. Именно по этой причине обратная совместимость требуется при изменении сериализованного формата для любой агрегатной функции в будущем.
|
||||
|
||||
## Server {#server}
|
||||
## Сервер {#server}
|
||||
|
||||
The server implements several different interfaces:
|
||||
Сервер реализует несколько различных интерфейсов:
|
||||
|
||||
- An HTTP interface for any foreign clients.
|
||||
- A TCP interface for the native ClickHouse client and for cross-server communication during distributed query execution.
|
||||
- An interface for transferring data for replication.
|
||||
- Интерфейс HTTP для любых иностранных клиентов.
|
||||
- TCP-интерфейс для собственного клиента ClickHouse и для межсерверной связи во время выполнения распределенного запроса.
|
||||
- Интерфейс для передачи данных для репликации.
|
||||
|
||||
Internally, it is just a primitive multithreaded server without coroutines or fibers. Since the server is not designed to process a high rate of simple queries but to process a relatively low rate of complex queries, each of them can process a vast amount of data for analytics.
|
||||
Внутренне это просто примитивный многопоточный сервер без сопрограмм или волокон. Поскольку сервер предназначен не для обработки высокой скорости простых запросов, а для обработки относительно низкой скорости сложных запросов, каждый из них может обрабатывать огромное количество данных для аналитики.
|
||||
|
||||
The server initializes the `Context` class with the necessary environment for query execution: the list of available databases, users and access rights, settings, clusters, the process list, the query log, and so on. Interpreters use this environment.
|
||||
Сервер инициализирует программу `Context` класс с необходимой средой для выполнения запроса: список доступных баз данных, пользователей и прав доступа, настройки, кластеры, список процессов, журнал запросов и так далее. Переводчики используют эту среду.
|
||||
|
||||
We maintain full backward and forward compatibility for the server TCP protocol: old clients can talk to new servers, and new clients can talk to old servers. But we don’t want to maintain it eternally, and we are removing support for old versions after about one year.
|
||||
Мы поддерживаем полную обратную и прямую совместимость для протокола TCP сервера: старые клиенты могут разговаривать с новыми серверами, а новые клиенты-со старыми серверами. Но мы не хотим поддерживать его вечно, и мы удаляем поддержку старых версий примерно через год.
|
||||
|
||||
!!! note "Note"
|
||||
For most external applications, we recommend using the HTTP interface because it is simple and easy to use. The TCP protocol is more tightly linked to internal data structures: it uses an internal format for passing blocks of data, and it uses custom framing for compressed data. We haven’t released a C library for that protocol because it requires linking most of the ClickHouse codebase, which is not practical.
|
||||
!!! note "Примечание"
|
||||
Для большинства внешних приложений мы рекомендуем использовать интерфейс HTTP, поскольку он прост и удобен в использовании. Протокол TCP более тесно связан с внутренними структурами данных: он использует внутренний формат для передачи блоков данных, а также использует пользовательское обрамление для сжатых данных. Мы не выпустили библиотеку C для этого протокола, потому что она требует связывания большей части кодовой базы ClickHouse, что нецелесообразно.
|
||||
|
||||
## Distributed Query Execution {#distributed-query-execution}
|
||||
## Выполнение Распределенных Запросов {#distributed-query-execution}
|
||||
|
||||
Servers in a cluster setup are mostly independent. You can create a `Distributed` table on one or all servers in a cluster. The `Distributed` table does not store data itself – it only provides a “view” to all local tables on multiple nodes of a cluster. When you SELECT from a `Distributed` table, it rewrites that query, chooses remote nodes according to load balancing settings, and sends the query to them. The `Distributed` table requests remote servers to process a query just up to a stage where intermediate results from different servers can be merged. Then it receives the intermediate results and merges them. The distributed table tries to distribute as much work as possible to remote servers and does not send much intermediate data over the network.
|
||||
Серверы в кластерной установке в основном независимы. Вы можете создать `Distributed` таблица на одном или всех серверах кластера. То `Distributed` table does not store data itself – it only provides a «view» ко всем локальным таблицам на нескольких узлах кластера. Когда вы выберите из `Distributed` таблица, он переписывает этот запрос, выбирает удаленные узлы в соответствии с настройками балансировки нагрузки и отправляет запрос к ним. То `Distributed` таблица запрашивает удаленные серверы для обработки запроса только до стадии, когда промежуточные результаты с разных серверов могут быть объединены. Затем он получает промежуточные результаты и сливает их. Распределенная таблица пытается распределить как можно больше работы на удаленные серверы и не отправляет много промежуточных данных по сети.
|
||||
|
||||
Things become more complicated when you have subqueries in IN or JOIN clauses, and each of them uses a `Distributed` table. We have different strategies for the execution of these queries.
|
||||
Все становится сложнее, когда у вас есть подзапросы в предложениях IN или JOIN, и каждый из них использует a `Distributed` стол. У нас есть разные стратегии выполнения этих запросов.
|
||||
|
||||
There is no global query plan for distributed query execution. Each node has its local query plan for its part of the job. We only have simple one-pass distributed query execution: we send queries for remote nodes and then merge the results. But this is not feasible for complicated queries with high cardinality GROUP BYs or with a large amount of temporary data for JOIN. In such cases, we need to “reshuffle” data between servers, which requires additional coordination. ClickHouse does not support that kind of query execution, and we need to work on it.
|
||||
Глобального плана запросов для выполнения распределенных запросов не существует. Каждый узел имеет свой локальный план запроса для своей части задания. У нас есть только простое однопроходное распределенное выполнение запросов: мы отправляем запросы на удаленные узлы, а затем объединяем результаты. Но это неосуществимо для сложных запросов с высокой мощностью группы BYs или с большим количеством временных данных для соединения. В таких случаях нам необходимо: «reshuffle» данные между серверами, что требует дополнительной координации. ClickHouse не поддерживает такого рода выполнение запросов, и мы должны работать над этим.
|
||||
|
||||
## Merge Tree {#merge-tree}
|
||||
## Дерево Слияния {#merge-tree}
|
||||
|
||||
`MergeTree` is a family of storage engines that supports indexing by primary key. The primary key can be an arbitrary tuple of columns or expressions. Data in a `MergeTree` table is stored in “parts”. Each part stores data in the primary key order, so data is ordered lexicographically by the primary key tuple. All the table columns are stored in separate `column.bin` files in these parts. The files consist of compressed blocks. Each block is usually from 64 KB to 1 MB of uncompressed data, depending on the average value size. The blocks consist of column values placed contiguously one after the other. Column values are in the same order for each column (the primary key defines the order), so when you iterate by many columns, you get values for the corresponding rows.
|
||||
`MergeTree` это семейство механизмов хранения данных, поддерживающих индексацию по первичному ключу. Первичный ключ может быть произвольным кортежем столбцов или выражений. Данные в a `MergeTree` таблица хранится в «parts». Каждая часть хранит данные в порядке первичного ключа, поэтому данные лексикографически упорядочиваются кортежем первичного ключа. Все столбцы таблицы хранятся отдельно `column.bin` файлы в этих краях. Файлы состоят из сжатых блоков. Каждый блок обычно содержит от 64 КБ до 1 МБ несжатых данных, в зависимости от среднего размера значения. Блоки состоят из значений столбцов, расположенных последовательно друг за другом. Значения столбцов находятся в одном и том же порядке для каждого столбца (первичный ключ определяет порядок), поэтому при итерации по многим столбцам вы получаете значения для соответствующих строк.
|
||||
|
||||
The primary key itself is “sparse”. It doesn’t address every single row, but only some ranges of data. A separate `primary.idx` file has the value of the primary key for each N-th row, where N is called `index_granularity` (usually, N = 8192). Also, for each column, we have `column.mrk` files with “marks,” which are offsets to each N-th row in the data file. Each mark is a pair: the offset in the file to the beginning of the compressed block, and the offset in the decompressed block to the beginning of data. Usually, compressed blocks are aligned by marks, and the offset in the decompressed block is zero. Data for `primary.idx` always resides in memory, and data for `column.mrk` files is cached.
|
||||
Сам первичный ключ является «sparse». Он адресует не каждую отдельную строку, а только некоторые диапазоны данных. Разделение `primary.idx` файл имеет значение первичного ключа для каждой N-й строки, где N называется `index_granularity` (обычно N = 8192). Кроме того, для каждой колонки у нас есть `column.mrk` файлы с «marks,» которые являются смещениями для каждой N-й строки в файле данных. Каждая метка представляет собой пару: смещение в файле к началу сжатого блока и смещение в распакованном блоке к началу данных. Обычно сжатые блоки выравниваются по меткам, а смещение в распакованном блоке равно нулю. Данные для `primary.idx` всегда находится в памяти, а данные для `column.mrk` файлы кэшируются.
|
||||
|
||||
When we are going to read something from a part in `MergeTree`, we look at `primary.idx` data and locate ranges that could contain requested data, then look at `column.mrk` data and calculate offsets for where to start reading those ranges. Because of sparseness, excess data may be read. ClickHouse is not suitable for a high load of simple point queries, because the entire range with `index_granularity` rows must be read for each key, and the entire compressed block must be decompressed for each column. We made the index sparse because we must be able to maintain trillions of rows per single server without noticeable memory consumption for the index. Also, because the primary key is sparse, it is not unique: it cannot check the existence of the key in the table at INSERT time. You could have many rows with the same key in a table.
|
||||
Когда мы собираемся прочитать что-то из части в `MergeTree`, мы смотрим на `primary.idx` данные и найдите диапазоны, которые могут содержать запрошенные данные, а затем посмотрите на `column.mrk` данные и рассчитать смещения для того, чтобы начать чтение этих диапазонов. Из-за разреженности могут быть прочитаны избыточные данные. ClickHouse не подходит для высокой загрузки простых точечных запросов, так как весь диапазон с `index_granularity` строки должны быть прочитаны для каждого ключа, и весь сжатый блок должен быть распакован для каждого столбца. Мы сделали индекс разреженным, потому что мы должны быть в состоянии поддерживать триллионы строк на одном сервере без заметного потребления памяти для индекса. Кроме того, поскольку первичный ключ разрежен, он не является уникальным: он не может проверить существование ключа в таблице во время вставки. В таблице может быть много строк с одним и тем же ключом.
|
||||
|
||||
When you `INSERT` a bunch of data into `MergeTree`, that bunch is sorted by primary key order and forms a new part. There are background threads that periodically select some parts and merge them into a single sorted part to keep the number of parts relatively low. That’s why it is called `MergeTree`. Of course, merging leads to “write amplification”. All parts are immutable: they are only created and deleted, but not modified. When SELECT is executed, it holds a snapshot of the table (a set of parts). After merging, we also keep old parts for some time to make a recovery after failure easier, so if we see that some merged part is probably broken, we can replace it with its source parts.
|
||||
Когда вы `INSERT` куча данных в `MergeTree`, эта связка сортируется по порядку первичного ключа и образует новую часть. Существуют фоновые потоки, которые периодически выделяют некоторые детали и объединяют их в одну сортированную деталь, чтобы сохранить количество деталей относительно низким. Вот почему он так называется `MergeTree`. Конечно, слияние приводит к тому, что «write amplification». Все части неизменны: они только создаются и удаляются, но не изменяются. Когда SELECT выполняется, он содержит снимок таблицы (набор деталей). После слияния мы также сохраняем старые детали в течение некоторого времени, чтобы облегчить восстановление после сбоя, поэтому, если мы видим, что какая-то объединенная деталь, вероятно, сломана, мы можем заменить ее исходными частями.
|
||||
|
||||
`MergeTree` is not an LSM tree because it doesn’t contain “memtable” and “log”: inserted data is written directly to the filesystem. This makes it suitable only to INSERT data in batches, not by individual row and not very frequently – about once per second is ok, but a thousand times a second is not. We did it this way for simplicity’s sake, and because we are already inserting data in batches in our applications.
|
||||
`MergeTree` это не дерево LSM, потому что оно не содержит «memtable» и «log»: inserted data is written directly to the filesystem. This makes it suitable only to INSERT data in batches, not by individual row and not very frequently – about once per second is ok, but a thousand times a second is not. We did it this way for simplicity's sake, and because we are already inserting data in batches in our applications.
|
||||
|
||||
> MergeTree tables can only have one (primary) index: there aren’t any secondary indices. It would be nice to allow multiple physical representations under one logical table, for example, to store data in more than one physical order or even to allow representations with pre-aggregated data along with original data.
|
||||
> Таблицы MergeTree могут иметь только один (первичный) индекс: вторичных индексов не существует. Было бы неплохо разрешить несколько физических представлений в одной логической таблице, например, хранить данные в более чем одном физическом порядке или даже разрешить представления с предварительно агрегированными данными наряду с исходными данными.
|
||||
|
||||
There are MergeTree engines that are doing additional work during background merges. Examples are `CollapsingMergeTree` and `AggregatingMergeTree`. This could be treated as special support for updates. Keep in mind that these are not real updates because users usually have no control over the time when background merges are executed, and data in a `MergeTree` table is almost always stored in more than one part, not in completely merged form.
|
||||
Есть движки MergeTree, которые выполняют дополнительную работу во время фоновых слияний. Примеры `CollapsingMergeTree` и `AggregatingMergeTree`. Это можно рассматривать как специальную поддержку обновлений. Имейте в виду, что это не настоящие обновления, поскольку пользователи обычно не имеют никакого контроля над временем выполнения фоновых слияний, а данные в `MergeTree` таблица почти всегда хранится в нескольких частях, а не в полностью объединенном виде.
|
||||
|
||||
## Replication {#replication}
|
||||
## Копирование {#replication}
|
||||
|
||||
Replication in ClickHouse can be configured on a per-table basis. You could have some replicated and some non-replicated tables on the same server. You could also have tables replicated in different ways, such as one table with two-factor replication and another with three-factor.
|
||||
Репликация в ClickHouse может быть настроена на основе каждой таблицы. Вы можете иметь некоторые реплицированные и некоторые нереплицированные таблицы на одном сервере. Вы также можете иметь таблицы, реплицируемые различными способами,например, одна таблица с двухфакторной репликацией, а другая-с трехфакторной.
|
||||
|
||||
Replication is implemented in the `ReplicatedMergeTree` storage engine. The path in `ZooKeeper` is specified as a parameter for the storage engine. All tables with the same path in `ZooKeeper` become replicas of each other: they synchronize their data and maintain consistency. Replicas can be added and removed dynamically simply by creating or dropping a table.
|
||||
Репликация осуществляется в виде `ReplicatedMergeTree` подсистема хранилища. Путь в `ZooKeeper` указывается в качестве параметра для механизма хранения данных. Все таблицы с одинаковым путем внутри `ZooKeeper` становятся репликами друг друга: они синхронизируют свои данные и поддерживают согласованность. Реплики можно добавлять и удалять динамически, просто создавая или удаляя таблицу.
|
||||
|
||||
Replication uses an asynchronous multi-master scheme. You can insert data into any replica that has a session with `ZooKeeper`, and data is replicated to all other replicas asynchronously. Because ClickHouse doesn’t support UPDATEs, replication is conflict-free. As there is no quorum acknowledgment of inserts, just-inserted data might be lost if one node fails.
|
||||
Репликация использует асинхронную многомастерную схему. Вы можете вставить данные в любую реплику, которая имеет сеанс с `ZooKeeper`, и данные реплицируются во все остальные реплики асинхронно. Поскольку ClickHouse не поддерживает обновления, репликация является бесконфликтной. Поскольку нет подтверждения кворума вставок, только что вставленные данные могут быть потеряны, если один узел выйдет из строя.
|
||||
|
||||
Metadata for replication is stored in ZooKeeper. There is a replication log that lists what actions to do. Actions are: get part; merge parts; drop a partition, and so on. Each replica copies the replication log to its queue and then executes the actions from the queue. For example, on insertion, the “get the part” action is created in the log, and every replica downloads that part. Merges are coordinated between replicas to get byte-identical results. All parts are merged in the same way on all replicas. It is achieved by electing one replica as the leader, and that replica initiates merges and writes “merge parts” actions to the log.
|
||||
Метаданные для репликации хранятся в ZooKeeper. Существует журнал репликации, в котором перечислены необходимые действия. Действия таковы: получить часть; объединить части; удалить раздел и так далее. Каждая реплика копирует журнал репликации в свою очередь, а затем выполняет действия из этой очереди. Например, при вставке «get the part» действие создается в журнале, и каждая реплика загружает эту часть. Слияния координируются между репликами для получения идентичных байтам результатов. Все части объединяются одинаково на всех репликах. Это достигается путем выбора одной реплики в качестве лидера, и эта реплика инициирует слияние и запись «merge parts» действия по ведению журнала.
|
||||
|
||||
Replication is physical: only compressed parts are transferred between nodes, not queries. Merges are processed on each replica independently in most cases to lower the network costs by avoiding network amplification. Large merged parts are sent over the network only in cases of significant replication lag.
|
||||
Репликация является физической: между узлами передаются только сжатые части, а не запросы. Слияния обрабатываются на каждой реплике независимо в большинстве случаев, чтобы снизить затраты на сеть, избегая усиления сети. Большие объединенные части передаются по сети только в случаях значительного запаздывания репликации.
|
||||
|
||||
Besides, each replica stores its state in ZooKeeper as the set of parts and its checksums. When the state on the local filesystem diverges from the reference state in ZooKeeper, the replica restores its consistency by downloading missing and broken parts from other replicas. When there is some unexpected or broken data in the local filesystem, ClickHouse does not remove it, but moves it to a separate directory and forgets it.
|
||||
Кроме того, каждая реплика хранит свое состояние в ZooKeeper как набор деталей и их контрольные суммы. Когда состояние локальной файловой системы отличается от эталонного состояния в ZooKeeper, реплика восстанавливает свою согласованность, загружая недостающие и сломанные части из других реплик. Когда в локальной файловой системе появляются неожиданные или неработающие данные, ClickHouse не удаляет их, а перемещает в отдельный каталог и забывает.
|
||||
|
||||
!!! note "Note"
|
||||
The ClickHouse cluster consists of independent shards, and each shard consists of replicas. The cluster is **not elastic**, so after adding a new shard, data is not rebalanced between shards automatically. Instead, the cluster load is supposed to be adjusted to be uneven. This implementation gives you more control, and it is ok for relatively small clusters, such as tens of nodes. But for clusters with hundreds of nodes that we are using in production, this approach becomes a significant drawback. We should implement a table engine that spans across the cluster with dynamically replicated regions that could be split and balanced between clusters automatically.
|
||||
!!! note "Примечание"
|
||||
Кластер ClickHouse состоит из независимых сегментов, и каждый сегмент состоит из реплик. Кластер таков **неупругий**, поэтому после добавления нового осколка данные не будут автоматически перебалансированы между осколками. Вместо этого предполагается, что нагрузка на кластер будет регулироваться неравномерно. Эта реализация дает вам больше контроля, и это нормально для относительно небольших кластеров, таких как десятки узлов. Но для кластеров с сотнями узлов, которые мы используем в производстве, этот подход становится существенным недостатком. Мы должны реализовать механизм таблиц, который охватывает весь кластер с динамически реплицируемыми областями, которые могут быть разделены и сбалансированы между кластерами автоматически.
|
||||
|
||||
{## [Original article](https://clickhouse.tech/docs/en/development/architecture/) ##}
|
||||
{## [Оригинальная статья](https://clickhouse.tech/docs/en/development/architecture/) ##}
|
||||
|
||||
@ -1,26 +1,27 @@
|
||||
---
|
||||
en_copy: true
|
||||
machine_translated: true
|
||||
machine_translated_rev: 1cd5f0028d917696daf71ac1c9ee849c99c1d5c8
|
||||
---
|
||||
|
||||
# How to Build ClickHouse for Development {#how-to-build-clickhouse-for-development}
|
||||
# Как построить ClickHouse для развития {#how-to-build-clickhouse-for-development}
|
||||
|
||||
The following tutorial is based on the Ubuntu Linux system.
|
||||
With appropriate changes, it should also work on any other Linux distribution.
|
||||
Supported platforms: x86\_64 and AArch64. Support for Power9 is experimental.
|
||||
Следующий учебник основан на системе Ubuntu Linux.
|
||||
С соответствующими изменениями он также должен работать на любом другом дистрибутиве Linux.
|
||||
Поддерживаемые платформы: x86\_64 и AArch64. Поддержка Power9 является экспериментальной.
|
||||
|
||||
## Install Git, CMake, Python and Ninja {#install-git-cmake-python-and-ninja}
|
||||
## Установите Git, CMake, Python и Ninja {#install-git-cmake-python-and-ninja}
|
||||
|
||||
``` bash
|
||||
$ sudo apt-get install git cmake python ninja-build
|
||||
```
|
||||
|
||||
Or cmake3 instead of cmake on older systems.
|
||||
Или cmake3 вместо cmake на старых системах.
|
||||
|
||||
## Install GCC 9 {#install-gcc-9}
|
||||
## Установка GCC 9 {#install-gcc-9}
|
||||
|
||||
There are several ways to do this.
|
||||
Есть несколько способов сделать это.
|
||||
|
||||
### Install from a PPA Package {#install-from-a-ppa-package}
|
||||
### Установка из PPA пакет {#install-from-a-ppa-package}
|
||||
|
||||
``` bash
|
||||
$ sudo apt-get install software-properties-common
|
||||
@ -29,30 +30,30 @@ $ sudo apt-get update
|
||||
$ sudo apt-get install gcc-9 g++-9
|
||||
```
|
||||
|
||||
### Install from Sources {#install-from-sources}
|
||||
### Установка из источников {#install-from-sources}
|
||||
|
||||
Look at [utils/ci/build-gcc-from-sources.sh](https://github.com/ClickHouse/ClickHouse/blob/master/utils/ci/build-gcc-from-sources.sh)
|
||||
Смотреть на [utils/ci/build-gcc-from-sources.sh](https://github.com/ClickHouse/ClickHouse/blob/master/utils/ci/build-gcc-from-sources.sh)
|
||||
|
||||
## Use GCC 9 for Builds {#use-gcc-9-for-builds}
|
||||
## Использовать GCC для сборки 9 {#use-gcc-9-for-builds}
|
||||
|
||||
``` bash
|
||||
$ export CC=gcc-9
|
||||
$ export CXX=g++-9
|
||||
```
|
||||
|
||||
## Checkout ClickHouse Sources {#checkout-clickhouse-sources}
|
||||
## Проверка Источников ClickHouse {#checkout-clickhouse-sources}
|
||||
|
||||
``` bash
|
||||
$ git clone --recursive git@github.com:ClickHouse/ClickHouse.git
|
||||
```
|
||||
|
||||
or
|
||||
или
|
||||
|
||||
``` bash
|
||||
$ git clone --recursive https://github.com/ClickHouse/ClickHouse.git
|
||||
```
|
||||
|
||||
## Build ClickHouse {#build-clickhouse}
|
||||
## Построить ClickHouse {#build-clickhouse}
|
||||
|
||||
``` bash
|
||||
$ cd ClickHouse
|
||||
@ -63,23 +64,23 @@ $ ninja
|
||||
$ cd ..
|
||||
```
|
||||
|
||||
To create an executable, run `ninja clickhouse`.
|
||||
This will create the `programs/clickhouse` executable, which can be used with `client` or `server` arguments.
|
||||
Чтобы создать исполняемый файл, выполните команду `ninja clickhouse`.
|
||||
Это позволит создать `programs/clickhouse` исполняемый файл, который может быть использован с `client` или `server` аргументы.
|
||||
|
||||
# How to Build ClickHouse on Any Linux {#how-to-build-clickhouse-on-any-linux}
|
||||
# Как построить ClickHouse на любом Linux {#how-to-build-clickhouse-on-any-linux}
|
||||
|
||||
The build requires the following components:
|
||||
Для сборки требуются следующие компоненты:
|
||||
|
||||
- Git (is used only to checkout the sources, it’s not needed for the build)
|
||||
- CMake 3.10 or newer
|
||||
- Ninja (recommended) or Make
|
||||
- C++ compiler: gcc 9 or clang 8 or newer
|
||||
- Linker: lld or gold (the classic GNU ld won’t work)
|
||||
- Python (is only used inside LLVM build and it is optional)
|
||||
- Git (используется только для проверки исходных текстов, он не нужен для сборки)
|
||||
- CMake 3.10 или новее
|
||||
- Ниндзя (рекомендуется) или сделать
|
||||
- Компилятор C++: gcc 9 или clang 8 или новее
|
||||
- Компоновщик: lld или gold (классический GNU ld не будет работать)
|
||||
- Python (используется только внутри сборки LLVM и является необязательным)
|
||||
|
||||
If all the components are installed, you may build in the same way as the steps above.
|
||||
Если все компоненты установлены, Вы можете построить их так же, как и описанные выше шаги.
|
||||
|
||||
Example for Ubuntu Eoan:
|
||||
Пример для Ubuntu Eoan:
|
||||
|
||||
sudo apt update
|
||||
sudo apt install git cmake ninja-build g++ python
|
||||
@ -88,7 +89,7 @@ Example for Ubuntu Eoan:
|
||||
cmake ../ClickHouse
|
||||
ninja
|
||||
|
||||
Example for OpenSUSE Tumbleweed:
|
||||
Пример для OpenSUSE перекати-поле:
|
||||
|
||||
sudo zypper install git cmake ninja gcc-c++ python lld
|
||||
git clone --recursive https://github.com/ClickHouse/ClickHouse.git
|
||||
@ -96,7 +97,7 @@ Example for OpenSUSE Tumbleweed:
|
||||
cmake ../ClickHouse
|
||||
ninja
|
||||
|
||||
Example for Fedora Rawhide:
|
||||
Пример для сыромятной кожи Fedora:
|
||||
|
||||
sudo yum update
|
||||
yum --nogpg install git cmake make gcc-c++ python2
|
||||
@ -105,34 +106,34 @@ Example for Fedora Rawhide:
|
||||
cmake ../ClickHouse
|
||||
make -j $(nproc)
|
||||
|
||||
# You Don’t Have to Build ClickHouse {#you-dont-have-to-build-clickhouse}
|
||||
# Вам не нужно строить ClickHouse {#you-dont-have-to-build-clickhouse}
|
||||
|
||||
ClickHouse is available in pre-built binaries and packages. Binaries are portable and can be run on any Linux flavour.
|
||||
ClickHouse доступен в готовых двоичных файлах и пакетах. Двоичные файлы являются портативными и могут быть запущены на любом вкусе Linux.
|
||||
|
||||
They are built for stable, prestable and testing releases as long as for every commit to master and for every pull request.
|
||||
Они созданы для стабильных, предустановленных и тестовых релизов до тех пор, пока для каждого коммита к мастеру и для каждого запроса на вытягивание.
|
||||
|
||||
To find the freshest build from `master`, go to [commits page](https://github.com/ClickHouse/ClickHouse/commits/master), click on the first green checkmark or red cross near commit, and click to the “Details” link right after “ClickHouse Build Check”.
|
||||
Чтобы найти самую свежую сборку из `master`, обратиться [совершает страницы](https://github.com/ClickHouse/ClickHouse/commits/master), нажмите на первую зеленую галочку или красный крестик рядом с фиксацией и нажмите на кнопку «Details» ссылка сразу после этого «ClickHouse Build Check».
|
||||
|
||||
# How to Build ClickHouse Debian Package {#how-to-build-clickhouse-debian-package}
|
||||
# Как создать пакет ClickHouse Debian {#how-to-build-clickhouse-debian-package}
|
||||
|
||||
## Install Git and Pbuilder {#install-git-and-pbuilder}
|
||||
## Установите Git и Pbuilder {#install-git-and-pbuilder}
|
||||
|
||||
``` bash
|
||||
$ sudo apt-get update
|
||||
$ sudo apt-get install git python pbuilder debhelper lsb-release fakeroot sudo debian-archive-keyring debian-keyring
|
||||
```
|
||||
|
||||
## Checkout ClickHouse Sources {#checkout-clickhouse-sources-1}
|
||||
## Проверка Источников ClickHouse {#checkout-clickhouse-sources-1}
|
||||
|
||||
``` bash
|
||||
$ git clone --recursive --branch master https://github.com/ClickHouse/ClickHouse.git
|
||||
$ cd ClickHouse
|
||||
```
|
||||
|
||||
## Run Release Script {#run-release-script}
|
||||
## Запустить Сценарий Выпуска {#run-release-script}
|
||||
|
||||
``` bash
|
||||
$ ./release
|
||||
```
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/development/build/) <!--hide-->
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/en/development/build/) <!--hide-->
|
||||
|
||||
@ -1,17 +1,18 @@
|
||||
---
|
||||
en_copy: true
|
||||
machine_translated: true
|
||||
machine_translated_rev: 1cd5f0028d917696daf71ac1c9ee849c99c1d5c8
|
||||
---
|
||||
|
||||
# How to Build ClickHouse on Linux for AARCH64 (ARM64) architecture {#how-to-build-clickhouse-on-linux-for-aarch64-arm64-architecture}
|
||||
# Как построить ClickHouse на Linux для архитектуры AArch64 (ARM64) {#how-to-build-clickhouse-on-linux-for-aarch64-arm64-architecture}
|
||||
|
||||
This is for the case when you have Linux machine and want to use it to build `clickhouse` binary that will run on another Linux machine with AARCH64 CPU architecture. This is intended for continuous integration checks that run on Linux servers.
|
||||
Это для случая, когда у вас есть Linux-машина и вы хотите использовать ее для сборки `clickhouse` двоичный файл, который будет работать на другой машине Linux с архитектурой процессора AARCH64. Это предназначено для непрерывной проверки интеграции, которая выполняется на серверах Linux.
|
||||
|
||||
The cross-build for AARCH64 is based on the [Build instructions](build.md), follow them first.
|
||||
Кросс-сборка для AARCH64 основана на следующих принципах: [Инструкции по сборке](build.md)- сначала следуйте за ними.
|
||||
|
||||
# Install Clang-8 {#install-clang-8}
|
||||
# Установка Clang-8 {#install-clang-8}
|
||||
|
||||
Follow the instructions from https://apt.llvm.org/ for your Ubuntu or Debian setup.
|
||||
For example, in Ubuntu Bionic you can use the following commands:
|
||||
Следуйте инструкциям от https://apt.llvm.org/ для вашей установки Ubuntu или Debian.
|
||||
Например, в Ubuntu Bionic вы можете использовать следующие команды:
|
||||
|
||||
``` bash
|
||||
echo "deb [trusted=yes] http://apt.llvm.org/bionic/ llvm-toolchain-bionic-8 main" | sudo tee /etc/apt/sources.list.d/llvm.list
|
||||
@ -19,7 +20,7 @@ sudo apt-get update
|
||||
sudo apt-get install clang-8
|
||||
```
|
||||
|
||||
# Install Cross-Compilation Toolset {#install-cross-compilation-toolset}
|
||||
# Установка Набора Инструментов Перекрестной Компиляции {#install-cross-compilation-toolset}
|
||||
|
||||
``` bash
|
||||
cd ClickHouse
|
||||
@ -28,7 +29,7 @@ wget 'https://developer.arm.com/-/media/Files/downloads/gnu-a/8.3-2019.03/binrel
|
||||
tar xJf gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu.tar.xz -C build-aarch64/cmake/toolchain/linux-aarch64 --strip-components=1
|
||||
```
|
||||
|
||||
# Build ClickHouse {#build-clickhouse}
|
||||
# Построить ClickHouse {#build-clickhouse}
|
||||
|
||||
``` bash
|
||||
cd ClickHouse
|
||||
@ -37,4 +38,4 @@ CC=clang-8 CXX=clang++-8 cmake . -Bbuild-arm64 -DCMAKE_TOOLCHAIN_FILE=cmake/linu
|
||||
ninja -C build-arm64
|
||||
```
|
||||
|
||||
The resulting binary will run only on Linux with the AARCH64 CPU architecture.
|
||||
Полученный двоичный файл будет работать только в Linux с архитектурой процессора AARCH64.
|
||||
|
||||
@ -1,26 +1,27 @@
|
||||
---
|
||||
en_copy: true
|
||||
machine_translated: true
|
||||
machine_translated_rev: 1cd5f0028d917696daf71ac1c9ee849c99c1d5c8
|
||||
---
|
||||
|
||||
# How to Build ClickHouse on Linux for Mac OS X {#how-to-build-clickhouse-on-linux-for-mac-os-x}
|
||||
# Как построить ClickHouse на Linux для Mac OS X {#how-to-build-clickhouse-on-linux-for-mac-os-x}
|
||||
|
||||
This is for the case when you have Linux machine and want to use it to build `clickhouse` binary that will run on OS X. This is intended for continuous integration checks that run on Linux servers. If you want to build ClickHouse directly on Mac OS X, then proceed with [another instruction](build_osx.md).
|
||||
Это для случая, когда у вас есть Linux-машина и вы хотите использовать ее для сборки `clickhouse` двоичный файл, который будет работать на OS X. Это предназначено для непрерывной проверки интеграции, которая выполняется на серверах Linux. Если вы хотите построить ClickHouse непосредственно на Mac OS X, то продолжайте [еще одна инструкция](build_osx.md).
|
||||
|
||||
The cross-build for Mac OS X is based on the [Build instructions](build.md), follow them first.
|
||||
Кросс-сборка для Mac OS X основана на следующих принципах: [Инструкции по сборке](build.md)- сначала следуйте за ними.
|
||||
|
||||
# Install Clang-8 {#install-clang-8}
|
||||
# Установка Clang-8 {#install-clang-8}
|
||||
|
||||
Follow the instructions from https://apt.llvm.org/ for your Ubuntu or Debian setup.
|
||||
For example the commands for Bionic are like:
|
||||
Следуйте инструкциям от https://apt.llvm.org/ для вашей установки Ubuntu или Debian.
|
||||
Например команды для Bionic выглядят так:
|
||||
|
||||
``` bash
|
||||
sudo echo "deb [trusted=yes] http://apt.llvm.org/bionic/ llvm-toolchain-bionic-8 main" >> /etc/apt/sources.list
|
||||
sudo apt-get install clang-8
|
||||
```
|
||||
|
||||
# Install Cross-Compilation Toolset {#install-cross-compilation-toolset}
|
||||
# Установка Набора Инструментов Перекрестной Компиляции {#install-cross-compilation-toolset}
|
||||
|
||||
Let’s remember the path where we install `cctools` as ${CCTOOLS}
|
||||
Давайте вспомним путь, по которому мы устанавливаем `cctools` как ${CCTOOLS}
|
||||
|
||||
``` bash
|
||||
mkdir ${CCTOOLS}
|
||||
@ -37,7 +38,7 @@ cd cctools-port/cctools
|
||||
make install
|
||||
```
|
||||
|
||||
Also, we need to download macOS X SDK into the working tree.
|
||||
Кроме того, нам нужно загрузить MacOS X SDK в рабочее дерево.
|
||||
|
||||
``` bash
|
||||
cd ClickHouse
|
||||
@ -46,7 +47,7 @@ mkdir -p build-darwin/cmake/toolchain/darwin-x86_64
|
||||
tar xJf MacOSX10.14.sdk.tar.xz -C build-darwin/cmake/toolchain/darwin-x86_64 --strip-components=1
|
||||
```
|
||||
|
||||
# Build ClickHouse {#build-clickhouse}
|
||||
# Построить ClickHouse {#build-clickhouse}
|
||||
|
||||
``` bash
|
||||
cd ClickHouse
|
||||
@ -58,4 +59,4 @@ CC=clang-8 CXX=clang++-8 cmake . -Bbuild-osx -DCMAKE_TOOLCHAIN_FILE=cmake/darwin
|
||||
ninja -C build-osx
|
||||
```
|
||||
|
||||
The resulting binary will have a Mach-O executable format and can’t be run on Linux.
|
||||
Полученный двоичный файл будет иметь исполняемый формат Mach-O и не может быть запущен в Linux.
|
||||
|
||||
@ -1,30 +1,31 @@
|
||||
---
|
||||
en_copy: true
|
||||
machine_translated: true
|
||||
machine_translated_rev: 1cd5f0028d917696daf71ac1c9ee849c99c1d5c8
|
||||
---
|
||||
|
||||
# How to Build ClickHouse on Mac OS X {#how-to-build-clickhouse-on-mac-os-x}
|
||||
# Как построить ClickHouse на Mac OS X {#how-to-build-clickhouse-on-mac-os-x}
|
||||
|
||||
Build should work on Mac OS X 10.15 (Catalina)
|
||||
Сборка должна работать на Mac OS X 10.15 (Catalina)
|
||||
|
||||
## Install Homebrew {#install-homebrew}
|
||||
## Установите Homebrew {#install-homebrew}
|
||||
|
||||
``` bash
|
||||
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
|
||||
```
|
||||
|
||||
## Install Required Compilers, Tools, and Libraries {#install-required-compilers-tools-and-libraries}
|
||||
## Установите необходимые компиляторы, инструменты и библиотеки {#install-required-compilers-tools-and-libraries}
|
||||
|
||||
``` bash
|
||||
$ brew install cmake ninja libtool gettext
|
||||
```
|
||||
|
||||
## Checkout ClickHouse Sources {#checkout-clickhouse-sources}
|
||||
## Проверка Источников ClickHouse {#checkout-clickhouse-sources}
|
||||
|
||||
``` bash
|
||||
$ git clone --recursive git@github.com:ClickHouse/ClickHouse.git
|
||||
```
|
||||
|
||||
or
|
||||
или
|
||||
|
||||
``` bash
|
||||
$ git clone --recursive https://github.com/ClickHouse/ClickHouse.git
|
||||
@ -32,7 +33,7 @@ $ git clone --recursive https://github.com/ClickHouse/ClickHouse.git
|
||||
$ cd ClickHouse
|
||||
```
|
||||
|
||||
## Build ClickHouse {#build-clickhouse}
|
||||
## Построить ClickHouse {#build-clickhouse}
|
||||
|
||||
``` bash
|
||||
$ mkdir build
|
||||
@ -42,16 +43,16 @@ $ ninja
|
||||
$ cd ..
|
||||
```
|
||||
|
||||
## Caveats {#caveats}
|
||||
## Предостережения {#caveats}
|
||||
|
||||
If you intend to run clickhouse-server, make sure to increase the system’s maxfiles variable.
|
||||
Если вы собираетесь запустить clickhouse-сервер, убедитесь в том, чтобы увеличить параметром maxfiles системная переменная.
|
||||
|
||||
!!! info "Note"
|
||||
You’ll need to use sudo.
|
||||
!!! info "Примечание"
|
||||
Вам нужно будет использовать sudo.
|
||||
|
||||
To do so, create the following file:
|
||||
Для этого создайте следующий файл:
|
||||
|
||||
/Library/LaunchDaemons/limit.maxfiles.plist:
|
||||
/Библиотека / LaunchDaemons / limit.параметром maxfiles.файл plist:
|
||||
|
||||
``` xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
@ -77,14 +78,14 @@ To do so, create the following file:
|
||||
</plist>
|
||||
```
|
||||
|
||||
Execute the following command:
|
||||
Выполните следующую команду:
|
||||
|
||||
``` bash
|
||||
$ sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist
|
||||
```
|
||||
|
||||
Reboot.
|
||||
Перезагрузить.
|
||||
|
||||
To check if it’s working, you can use `ulimit -n` command.
|
||||
Чтобы проверить, работает ли он, вы можете использовать `ulimit -n` команда.
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/development/build_osx/) <!--hide-->
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/en/development/build_osx/) <!--hide-->
|
||||
|
||||
@ -1,7 +1,8 @@
|
||||
---
|
||||
en_copy: true
|
||||
machine_translated: true
|
||||
machine_translated_rev: 1cd5f0028d917696daf71ac1c9ee849c99c1d5c8
|
||||
---
|
||||
|
||||
# ClickHouse Development {#clickhouse-development}
|
||||
# Разработка ClickHouse {#clickhouse-development}
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/development/) <!--hide-->
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/en/development/) <!--hide-->
|
||||
|
||||
@ -1,87 +1,88 @@
|
||||
---
|
||||
en_copy: true
|
||||
machine_translated: true
|
||||
machine_translated_rev: 1cd5f0028d917696daf71ac1c9ee849c99c1d5c8
|
||||
---
|
||||
|
||||
# ClickHouse Testing {#clickhouse-testing}
|
||||
# Тестирование ClickHouse {#clickhouse-testing}
|
||||
|
||||
## Functional Tests {#functional-tests}
|
||||
## Функциональные пробы {#functional-tests}
|
||||
|
||||
Functional tests are the most simple and convenient to use. Most of ClickHouse features can be tested with functional tests and they are mandatory to use for every change in ClickHouse code that can be tested that way.
|
||||
Функциональные тесты являются наиболее простыми и удобными в использовании. Большинство функций ClickHouse можно протестировать с помощью функциональных тестов, и они обязательны для использования при каждом изменении кода ClickHouse, которое может быть протестировано таким образом.
|
||||
|
||||
Each functional test sends one or multiple queries to the running ClickHouse server and compares the result with reference.
|
||||
Каждый функциональный тест отправляет один или несколько запросов на запущенный сервер ClickHouse и сравнивает результат со ссылкой.
|
||||
|
||||
Tests are located in `queries` directory. There are two subdirectories: `stateless` and `stateful`. Stateless tests run queries without any preloaded test data - they often create small synthetic datasets on the fly, within the test itself. Stateful tests require preloaded test data from Yandex.Metrica and not available to general public. We tend to use only `stateless` tests and avoid adding new `stateful` tests.
|
||||
Тесты расположены в `queries` каталог. Существует два подкаталога: `stateless` и `stateful`. Тесты без состояния выполняют запросы без каких - либо предварительно загруженных тестовых данных-они часто создают небольшие синтетические наборы данных на лету, в самом тесте. Статусные тесты требуют предварительно загруженных тестовых данных от Яндекса.Метрика и не доступна широкой публике. Мы склонны использовать только `stateless` тесты и избегайте добавления новых `stateful` тесты.
|
||||
|
||||
Each test can be one of two types: `.sql` and `.sh`. `.sql` test is the simple SQL script that is piped to `clickhouse-client --multiquery --testmode`. `.sh` test is a script that is run by itself.
|
||||
Каждый тест может быть одного из двух типов: `.sql` и `.sh`. `.sql` тест - это простой SQL-скрипт, который передается по конвейеру в `clickhouse-client --multiquery --testmode`. `.sh` тест - это скрипт, который запускается сам по себе.
|
||||
|
||||
To run all tests, use `testskhouse-test` tool. Look `--help` for the list of possible options. You can simply run all tests or run subset of tests filtered by substring in test name: `./clickhouse-test substring`.
|
||||
Чтобы выполнить все тесты, используйте `testskhouse-test` инструмент. Смотри `--help` для списка возможных вариантов. Вы можете просто запустить все тесты или запустить подмножество тестов, отфильтрованных по подстроке в имени теста: `./clickhouse-test substring`.
|
||||
|
||||
The most simple way to invoke functional tests is to copy `clickhouse-client` to `/usr/bin/`, run `clickhouse-server` and then run `./clickhouse-test` from its own directory.
|
||||
Самый простой способ вызвать функциональные тесты-это скопировать `clickhouse-client` к `/usr/bin/`, бежать `clickhouse-server` а потом бежать `./clickhouse-test` из собственного каталога.
|
||||
|
||||
To add new test, create a `.sql` or `.sh` file in `queries/0_stateless` directory, check it manually and then generate `.reference` file in the following way: `clickhouse-client -n --testmode < 00000_test.sql > 00000_test.reference` or `./00000_test.sh > ./00000_test.reference`.
|
||||
Чтобы добавить новый тест, создайте `.sql` или `.sh` файл в `queries/0_stateless` каталог, проверьте его вручную, а затем сгенерируйте `.reference` файл создается следующим образом: `clickhouse-client -n --testmode < 00000_test.sql > 00000_test.reference` или `./00000_test.sh > ./00000_test.reference`.
|
||||
|
||||
Tests should use (create, drop, etc) only tables in `test` database that is assumed to be created beforehand; also tests can use temporary tables.
|
||||
Тесты должны использовать (создавать, отбрасывать и т. д.) Только таблицы в `test` предполагается, что база данных создается заранее; также тесты могут использовать временные таблицы.
|
||||
|
||||
If you want to use distributed queries in functional tests, you can leverage `remote` table function with `127.0.0.{1..2}` addresses for the server to query itself; or you can use predefined test clusters in server configuration file like `test_shard_localhost`.
|
||||
Если вы хотите использовать распределенные запросы в функциональных тестах, вы можете использовать их в качестве рычагов `remote` функция таблицы с `127.0.0.{1..2}` адреса для запроса самого сервера; или вы можете использовать предопределенные тестовые кластеры в файле конфигурации сервера, например `test_shard_localhost`.
|
||||
|
||||
Some tests are marked with `zookeeper`, `shard` or `long` in their names.
|
||||
`zookeeper` is for tests that are using ZooKeeper. `shard` is for tests that
|
||||
requires server to listen `127.0.0.*`; `distributed` or `global` have the same
|
||||
meaning. `long` is for tests that run slightly longer that one second. You can
|
||||
disable these groups of tests using `--no-zookeeper`, `--no-shard` and
|
||||
`--no-long` options, respectively.
|
||||
Некоторые тесты помечены знаком `zookeeper`, `shard` или `long` в своем названии.
|
||||
`zookeeper` это для тестов, которые используют ZooKeeper. `shard` это для тестов, что
|
||||
требуется сервер для прослушивания `127.0.0.*`; `distributed` или `global` есть то же самое
|
||||
значение. `long` это для тестов, которые работают немного дольше, чем одна секунда. Ты можешь
|
||||
отключите эти группы тестов с помощью `--no-zookeeper`, `--no-shard` и
|
||||
`--no-long` варианты, соответственно.
|
||||
|
||||
## Known bugs {#known-bugs}
|
||||
## Известная ошибка {#known-bugs}
|
||||
|
||||
If we know some bugs that can be easily reproduced by functional tests, we place prepared functional tests in `queries/bugs` directory. These tests will be moved to `teststests_stateless` when bugs are fixed.
|
||||
Если мы знаем некоторые ошибки, которые могут быть легко воспроизведены функциональными тестами, мы помещаем подготовленные функциональные тесты в `queries/bugs` каталог. Эти тесты будут перенесены в `teststests_stateless` когда ошибки будут исправлены.
|
||||
|
||||
## Integration Tests {#integration-tests}
|
||||
## Интеграционные Тесты {#integration-tests}
|
||||
|
||||
Integration tests allow to test ClickHouse in clustered configuration and ClickHouse interaction with other servers like MySQL, Postgres, MongoDB. They are useful to emulate network splits, packet drops, etc. These tests are run under Docker and create multiple containers with various software.
|
||||
Интеграционные тесты позволяют тестировать ClickHouse в кластерной конфигурации и взаимодействие ClickHouse с другими серверами, такими как MySQL, Postgres, MongoDB. Они полезны для эмуляции сетевых разбиений, отбрасывания пакетов и т. д. Эти тесты выполняются в Docker и создают несколько контейнеров с различным программным обеспечением.
|
||||
|
||||
See `testsgration/README.md` on how to run these tests.
|
||||
Видеть `testsgration/README.md` о том, как проводить эти тесты.
|
||||
|
||||
Note that integration of ClickHouse with third-party drivers is not tested. Also we currently don’t have integration tests with our JDBC and ODBC drivers.
|
||||
Обратите внимание, что интеграция ClickHouse со сторонними драйверами не тестируется. Кроме того, в настоящее время у нас нет интеграционных тестов с нашими драйверами JDBC и ODBC.
|
||||
|
||||
## Unit Tests {#unit-tests}
|
||||
## Модульное тестирование {#unit-tests}
|
||||
|
||||
Unit tests are useful when you want to test not the ClickHouse as a whole, but a single isolated library or class. You can enable or disable build of tests with `ENABLE_TESTS` CMake option. Unit tests (and other test programs) are located in `tests` subdirectories across the code. To run unit tests, type `ninja test`. Some tests use `gtest`, but some are just programs that return non-zero exit code on test failure.
|
||||
Модульные тесты полезны, если вы хотите протестировать не весь ClickHouse в целом, а одну изолированную библиотеку или класс. Вы можете включить или отключить сборку тестов с помощью `ENABLE_TESTS` Вариант CMake. Модульные тесты (и другие тестовые программы) расположены в `tests` подкаталоги по всему коду. Чтобы запустить модульные тесты, введите `ninja test`. Некоторые тесты используют `gtest`, но некоторые из них-это просто программы, которые возвращают ненулевой код выхода при сбое теста.
|
||||
|
||||
It’s not necessarily to have unit tests if the code is already covered by functional tests (and functional tests are usually much more simple to use).
|
||||
Не обязательно иметь модульные тесты, Если код уже охвачен функциональными тестами (а функциональные тесты обычно гораздо более просты в использовании).
|
||||
|
||||
## Performance Tests {#performance-tests}
|
||||
## Эксплуатационное испытание {#performance-tests}
|
||||
|
||||
Performance tests allow to measure and compare performance of some isolated part of ClickHouse on synthetic queries. Tests are located at `tests/performance`. Each test is represented by `.xml` file with description of test case. Tests are run with `clickhouse performance-test` tool (that is embedded in `clickhouse` binary). See `--help` for invocation.
|
||||
Тесты производительности позволяют измерять и сравнивать производительность некоторой изолированной части ClickHouse по синтетическим запросам. Тесты расположены по адресу `tests/performance`. Каждый тест представлен следующим образом `.xml` файл с описанием тестового случая. Тесты выполняются с помощью `clickhouse performance-test` инструмент (который встроен в `clickhouse` двоичный). Видеть `--help` для призыва.
|
||||
|
||||
Each test run one or miltiple queries (possibly with combinations of parameters) in a loop with some conditions for stop (like “maximum execution speed is not changing in three seconds”) and measure some metrics about query performance (like “maximum execution speed”). Some tests can contain preconditions on preloaded test dataset.
|
||||
Каждый тест запускает один или несколько запросов (возможно, с комбинациями параметров) в цикле с некоторыми условиями остановки (например «maximum execution speed is not changing in three seconds») и измерьте некоторые показатели производительности запросов (например, «maximum execution speed»). Некоторые тесты могут содержать предварительные условия для предварительно загруженного тестового набора данных.
|
||||
|
||||
If you want to improve performance of ClickHouse in some scenario, and if improvements can be observed on simple queries, it is highly recommended to write a performance test. It always makes sense to use `perf top` or other perf tools during your tests.
|
||||
Если вы хотите улучшить производительность ClickHouse в каком-то сценарии, и если улучшения могут наблюдаться в простых запросах, настоятельно рекомендуется написать тест производительности. Это всегда имеет смысл использовать `perf top` или другие инструменты perf во время ваших тестов.
|
||||
|
||||
## Test Tools And Scripts {#test-tools-and-scripts}
|
||||
## Инструменты И Сценарии Тестирования {#test-tools-and-scripts}
|
||||
|
||||
Some programs in `tests` directory are not prepared tests, but are test tools. For example, for `Lexer` there is a tool `dbms/Parsers/tests/lexer` that just do tokenization of stdin and writes colorized result to stdout. You can use these kind of tools as a code examples and for exploration and manual testing.
|
||||
Некоторые программы в `tests` каталог-это не подготовленные тесты, а инструменты тестирования. Например, для `Lexer` есть такой инструмент `dbms/Parsers/tests/lexer` это просто делает токенизацию stdin и записывает раскрашенный результат в stdout. Вы можете использовать эти инструменты в качестве примеров кода, а также для исследования и ручного тестирования.
|
||||
|
||||
You can also place pair of files `.sh` and `.reference` along with the tool to run it on some predefined input - then script result can be compared to `.reference` file. These kind of tests are not automated.
|
||||
Вы также можете разместить пару файлов `.sh` и `.reference` вместе с инструментом нужно запустить его на каком - то заранее заданном входе- тогда результат скрипта можно сравнить с `.reference` файл. Такого рода тесты не автоматизированы.
|
||||
|
||||
## Miscellanous Tests {#miscellanous-tests}
|
||||
## Различные Тесты {#miscellanous-tests}
|
||||
|
||||
There are tests for external dictionaries located at `tests/external_dictionaries` and for machine learned models in `tests/external_models`. These tests are not updated and must be transferred to integration tests.
|
||||
Существуют тесты для внешних словарей, расположенных по адресу `tests/external_dictionaries` и для машинно-обученных моделей в `tests/external_models`. Эти тесты не обновляются и должны быть перенесены в интеграционные тесты.
|
||||
|
||||
There is separate test for quorum inserts. This test run ClickHouse cluster on separate servers and emulate various failure cases: network split, packet drop (between ClickHouse nodes, between ClickHouse and ZooKeeper, between ClickHouse server and client, etc.), `kill -9`, `kill -STOP` and `kill -CONT` , like [Jepsen](https://aphyr.com/tags/Jepsen). Then the test checks that all acknowledged inserts was written and all rejected inserts was not.
|
||||
Существует отдельный тест для вставки кворума. Этот тест запускает кластер ClickHouse на отдельных серверах и эмулирует различные случаи сбоя: разделение сети, отбрасывание пакетов (между узлами ClickHouse, между ClickHouse и ZooKeeper, между сервером ClickHouse и клиентом и т. д.), `kill -9`, `kill -STOP` и `kill -CONT` , любить [Джепсен](https://aphyr.com/tags/Jepsen). Затем тест проверяет, что все признанные вставки были записаны, а все отклоненные вставки-нет.
|
||||
|
||||
Quorum test was written by separate team before ClickHouse was open-sourced. This team no longer work with ClickHouse. Test was accidentially written in Java. For these reasons, quorum test must be rewritten and moved to integration tests.
|
||||
Тест кворума был написан отдельной командой еще до того, как ClickHouse стал открытым исходным кодом. Эта команда больше не работает с ClickHouse. Тест был случайно написан на Java. По этим причинам тест кворума должен быть переписан и перенесен в интеграционные тесты.
|
||||
|
||||
## Manual Testing {#manual-testing}
|
||||
## Ручное тестирование {#manual-testing}
|
||||
|
||||
When you develop a new feature, it is reasonable to also test it manually. You can do it with the following steps:
|
||||
Когда вы разрабатываете новую функцию, разумно также протестировать ее вручную. Вы можете сделать это с помощью следующих шагов:
|
||||
|
||||
Build ClickHouse. Run ClickHouse from the terminal: change directory to `programs/clickhouse-server` and run it with `./clickhouse-server`. It will use configuration (`config.xml`, `users.xml` and files within `config.d` and `users.d` directories) from the current directory by default. To connect to ClickHouse server, run `programs/clickhouse-client/clickhouse-client`.
|
||||
Постройте ClickHouse. Запустите ClickHouse из терминала: измените каталог на `programs/clickhouse-server` и запустить его с помощью `./clickhouse-server`. Он будет использовать конфигурацию (`config.xml`, `users.xml` и файлы внутри `config.d` и `users.d` каталоги) из текущего каталога по умолчанию. Чтобы подключиться к серверу ClickHouse, выполните команду `programs/clickhouse-client/clickhouse-client`.
|
||||
|
||||
Note that all clickhouse tools (server, client, etc) are just symlinks to a single binary named `clickhouse`. You can find this binary at `programs/clickhouse`. All tools can also be invoked as `clickhouse tool` instead of `clickhouse-tool`.
|
||||
Обратите внимание, что все инструменты clickhouse (сервер, клиент и т. д.) являются просто символическими ссылками на один двоичный файл с именем `clickhouse`. Вы можете найти этот двоичный файл по адресу `programs/clickhouse`. Все инструменты также могут быть вызваны как `clickhouse tool` вместо `clickhouse-tool`.
|
||||
|
||||
Alternatively you can install ClickHouse package: either stable release from Yandex repository or you can build package for yourself with `./release` in ClickHouse sources root. Then start the server with `sudo service clickhouse-server start` (or stop to stop the server). Look for logs at `/etc/clickhouse-server/clickhouse-server.log`.
|
||||
В качестве альтернативы вы можете установить пакет ClickHouse: либо стабильный релиз из репозитория Яндекса, либо вы можете построить пакет для себя с помощью `./release` в корне источников ClickHouse. Затем запустите сервер с помощью `sudo service clickhouse-server start` (или остановить, чтобы остановить сервер). Ищите журналы по адресу `/etc/clickhouse-server/clickhouse-server.log`.
|
||||
|
||||
When ClickHouse is already installed on your system, you can build a new `clickhouse` binary and replace the existing binary:
|
||||
Когда ClickHouse уже установлен в вашей системе, вы можете построить новый `clickhouse` двоичный код и заменить существующий двоичный код:
|
||||
|
||||
``` bash
|
||||
$ sudo service clickhouse-server stop
|
||||
@ -89,161 +90,161 @@ $ sudo cp ./clickhouse /usr/bin/
|
||||
$ sudo service clickhouse-server start
|
||||
```
|
||||
|
||||
Also you can stop system clickhouse-server and run your own with the same configuration but with logging to terminal:
|
||||
Также вы можете остановить системный clickhouse-сервер и запустить свой собственный с той же конфигурацией, но с регистрацией в терминал:
|
||||
|
||||
``` bash
|
||||
$ sudo service clickhouse-server stop
|
||||
$ sudo -u clickhouse /usr/bin/clickhouse server --config-file /etc/clickhouse-server/config.xml
|
||||
```
|
||||
|
||||
Example with gdb:
|
||||
Пример с gdb:
|
||||
|
||||
``` bash
|
||||
$ sudo -u clickhouse gdb --args /usr/bin/clickhouse server --config-file /etc/clickhouse-server/config.xml
|
||||
```
|
||||
|
||||
If the system clickhouse-server is already running and you don’t want to stop it, you can change port numbers in your `config.xml` (or override them in a file in `config.d` directory), provide appropriate data path, and run it.
|
||||
Если системный clickhouse-сервер уже запущен, и вы не хотите его останавливать, вы можете изменить номера портов в своей системе. `config.xml` (или переопределить их в файле внутри `config.d` каталог), укажите соответствующий путь к данным и запустите его.
|
||||
|
||||
`clickhouse` binary has almost no dependencies and works across wide range of Linux distributions. To quick and dirty test your changes on a server, you can simply `scp` your fresh built `clickhouse` binary to your server and then run it as in examples above.
|
||||
`clickhouse` binary почти не имеет зависимостей и работает в широком диапазоне дистрибутивов Linux. Чтобы быстро и грязно протестировать свои изменения на сервере, вы можете просто `scp` ваша свежая постройка `clickhouse` двоичный файл на ваш сервер, а затем запустите его, как в приведенных выше примерах.
|
||||
|
||||
## Testing Environment {#testing-environment}
|
||||
## Тестовая среда {#testing-environment}
|
||||
|
||||
Before publishing release as stable we deploy it on testing environment. Testing environment is a cluster that process 1/39 part of [Yandex.Metrica](https://metrica.yandex.com/) data. We share our testing environment with Yandex.Metrica team. ClickHouse is upgraded without downtime on top of existing data. We look at first that data is processed successfully without lagging from realtime, the replication continue to work and there is no issues visible to Yandex.Metrica team. First check can be done in the following way:
|
||||
Перед публикацией релиза как стабильного мы развертываем его в тестовой среде. Среда тестирования-это кластер, который обрабатывает 1/39 часть [Яндекс.Метрика](https://metrica.yandex.com/) данные. Мы делимся нашей тестовой средой с Яндексом.Команда метрики. ClickHouse обновляется без простоев поверх существующих данных. Мы смотрим сначала на то, что данные обрабатываются успешно, не отставая от реального времени, репликация продолжает работать и нет никаких проблем, видимых Яндексу.Команда метрики. Первую проверку можно провести следующим образом:
|
||||
|
||||
``` sql
|
||||
SELECT hostName() AS h, any(version()), any(uptime()), max(UTCEventTime), count() FROM remote('example01-01-{1..3}t', merge, hits) WHERE EventDate >= today() - 2 GROUP BY h ORDER BY h;
|
||||
```
|
||||
|
||||
In some cases we also deploy to testing environment of our friend teams in Yandex: Market, Cloud, etc. Also we have some hardware servers that are used for development purposes.
|
||||
В некоторых случаях мы также развернуть на тестирование среды нашего друга команды Яндекса: Маркет, облако и т. д. Кроме того, у нас есть некоторые аппаратные серверы, которые используются для целей разработки.
|
||||
|
||||
## Load Testing {#load-testing}
|
||||
## Нагрузочное тестирование {#load-testing}
|
||||
|
||||
After deploying to testing environment we run load testing with queries from production cluster. This is done manually.
|
||||
После развертывания в среде тестирования мы запускаем нагрузочное тестирование с запросами из производственного кластера. Это делается вручную.
|
||||
|
||||
Make sure you have enabled `query_log` on your production cluster.
|
||||
Убедитесь, что вы включили `query_log` на вашем производственном кластере.
|
||||
|
||||
Collect query log for a day or more:
|
||||
Сбор журнала запросов в течение одного или нескольких дней:
|
||||
|
||||
``` bash
|
||||
$ clickhouse-client --query="SELECT DISTINCT query FROM system.query_log WHERE event_date = today() AND query LIKE '%ym:%' AND query NOT LIKE '%system.query_log%' AND type = 2 AND is_initial_query" > queries.tsv
|
||||
```
|
||||
|
||||
This is a way complicated example. `type = 2` will filter queries that are executed successfully. `query LIKE '%ym:%'` is to select relevant queries from Yandex.Metrica. `is_initial_query` is to select only queries that are initiated by client, not by ClickHouse itself (as parts of distributed query processing).
|
||||
Это очень сложный пример. `type = 2` будет фильтровать запросы, которые выполняются успешно. `query LIKE '%ym:%'` это выбор релевантных запросов от Яндекса.Метрика. `is_initial_query` это выбор только тех запросов, которые инициируются клиентом, а не самим ClickHouse (как части распределенной обработки запросов).
|
||||
|
||||
`scp` this log to your testing cluster and run it as following:
|
||||
`scp` это войдите в свой тестовый кластер и запустите его следующим образом:
|
||||
|
||||
``` bash
|
||||
$ clickhouse benchmark --concurrency 16 < queries.tsv
|
||||
```
|
||||
|
||||
(probably you also want to specify a `--user`)
|
||||
(вероятно, вы также хотите указать a `--user`)
|
||||
|
||||
Then leave it for a night or weekend and go take a rest.
|
||||
Затем оставьте его на ночь или выходные и идите отдыхать.
|
||||
|
||||
You should check that `clickhouse-server` doesn’t crash, memory footprint is bounded and performance not degrading over time.
|
||||
Вы должны это проверить `clickhouse-server` не дает сбоя, объем памяти ограничен, а производительность не ухудшается с течением времени.
|
||||
|
||||
Precise query execution timings are not recorded and not compared due to high variability of queries and environment.
|
||||
Точные тайминги выполнения запросов не регистрируются и не сравниваются из-за высокой вариативности запросов и окружающей среды.
|
||||
|
||||
## Build Tests {#build-tests}
|
||||
## Построение Тестов {#build-tests}
|
||||
|
||||
Build tests allow to check that build is not broken on various alternative configurations and on some foreign systems. Tests are located at `ci` directory. They run build from source inside Docker, Vagrant, and sometimes with `qemu-user-static` inside Docker. These tests are under development and test runs are not automated.
|
||||
Тесты сборки позволяют проверить, что сборка не нарушается на различных альтернативных конфигурациях и на некоторых зарубежных системах. Тесты расположены по адресу `ci` каталог. Они запускают сборку из исходного кода внутри Docker, Vagrant, а иногда и с помощью `qemu-user-static` внутри Докер. Эти тесты находятся в стадии разработки, и тестовые запуски не автоматизированы.
|
||||
|
||||
Motivation:
|
||||
Мотивация:
|
||||
|
||||
Normally we release and run all tests on a single variant of ClickHouse build. But there are alternative build variants that are not thoroughly tested. Examples:
|
||||
Обычно мы выпускаем и запускаем все тесты на одном варианте сборки ClickHouse. Но есть и альтернативные варианты сборки, которые не проходят тщательной проверки. Примеры:
|
||||
|
||||
- build on FreeBSD;
|
||||
- build on Debian with libraries from system packages;
|
||||
- build with shared linking of libraries;
|
||||
- build on AArch64 platform;
|
||||
- build on PowerPc platform.
|
||||
- сборка на FreeBSD;
|
||||
- сборка на Debian с библиотеками из системных пакетов;
|
||||
- сборка с общим связыванием библиотек;
|
||||
- построить на платформе AArch64 ;
|
||||
- постройте на платформе PowerPc.
|
||||
|
||||
For example, build with system packages is bad practice, because we cannot guarantee what exact version of packages a system will have. But this is really needed by Debian maintainers. For this reason we at least have to support this variant of build. Another example: shared linking is a common source of trouble, but it is needed for some enthusiasts.
|
||||
Например, сборка с системными пакетами-это плохая практика, потому что мы не можем гарантировать, какая именно версия пакетов будет у системы. Но это действительно необходимо сопровождающим Debian. По этой причине мы, по крайней мере, должны поддерживать этот вариант сборки. Другой пример: Общие ссылки-это общий источник проблем, но он необходим для некоторых энтузиастов.
|
||||
|
||||
Though we cannot run all tests on all variant of builds, we want to check at least that various build variants are not broken. For this purpose we use build tests.
|
||||
Хотя мы не можем выполнить все тесты на всех вариантах сборки, мы хотим проверить, по крайней мере, что различные варианты сборки не нарушены. Для этого мы используем тесты сборки.
|
||||
|
||||
## Testing For Protocol Compatibility {#testing-for-protocol-compatibility}
|
||||
## Тестирование Совместимости Протоколов {#testing-for-protocol-compatibility}
|
||||
|
||||
When we extend ClickHouse network protocol, we test manually that old clickhouse-client works with new clickhouse-server and new clickhouse-client works with old clickhouse-server (simply by running binaries from corresponding packages).
|
||||
Когда мы расширяем сетевой протокол ClickHouse, мы вручную проверяем, что старый clickhouse-клиент работает с новым clickhouse-сервером, а новый clickhouse-клиент работает со старым clickhouse-сервером (просто запустив двоичные файлы из соответствующих пакетов).
|
||||
|
||||
## Help From The Compiler {#help-from-the-compiler}
|
||||
## Помощь От Компилятора {#help-from-the-compiler}
|
||||
|
||||
Main ClickHouse code (that is located in `dbms` directory) is built with `-Wall -Wextra -Werror` and with some additional enabled warnings. Although these options are not enabled for third-party libraries.
|
||||
Основной код ClickHouse (который находится в `dbms` каталог) строится с помощью `-Wall -Wextra -Werror` и с некоторыми дополнительными включенными предупреждениями. Хотя эти параметры не включены для сторонних библиотек.
|
||||
|
||||
Clang has even more useful warnings - you can look for them with `-Weverything` and pick something to default build.
|
||||
У Clang есть еще более полезные предупреждения - вы можете искать их с помощью `-Weverything` и выберите что-то для сборки по умолчанию.
|
||||
|
||||
For production builds, gcc is used (it still generates slightly more efficient code than clang). For development, clang is usually more convenient to use. You can build on your own machine with debug mode (to save battery of your laptop), but please note that compiler is able to generate more warnings with `-O3` due to better control flow and inter-procedure analysis. When building with clang, `libc++` is used instead of `libstdc++` and when building with debug mode, debug version of `libc++` is used that allows to catch more errors at runtime.
|
||||
Для производственных сборок используется gcc (он все еще генерирует немного более эффективный код, чем clang). Для развития, лязгают, как правило, более удобны в использовании. Вы можете построить на своей собственной машине с режимом отладки (чтобы сэкономить батарею вашего ноутбука), но обратите внимание, что компилятор способен генерировать больше предупреждений с помощью `-O3` благодаря лучшему потоку управления и межпроцедурному анализу. При строительстве с лязгом, `libc++` используется вместо `libstdc++` и при построении с режимом отладки, отладочная версия `libc++` используется, что позволяет ловить больше ошибок во время выполнения.
|
||||
|
||||
## Sanitizers {#sanitizers}
|
||||
## Дезинфицирующее средство {#sanitizers}
|
||||
|
||||
**Address sanitizer**.
|
||||
We run functional and integration tests under ASan on per-commit basis.
|
||||
**Адрес дезинфицирующее средство**.
|
||||
Мы проводим функциональные и интеграционные тесты в асане на фиксации основы.
|
||||
|
||||
**Valgrind (Memcheck)**.
|
||||
We run functional tests under Valgrind overnight. It takes multiple hours. Currently there is one known false positive in `re2` library, see [this article](https://research.swtch.com/sparse).
|
||||
**С Valgrind (Помощи Valgrind)**.
|
||||
Мы проводим функциональные тесты под Valgrind ночь. Это займет несколько часов. В настоящее время существует один известный ложноположительный результат в `re2` библиотека, см. [эта статья](https://research.swtch.com/sparse).
|
||||
|
||||
**Undefined behaviour sanitizer.**
|
||||
We run functional and integration tests under ASan on per-commit basis.
|
||||
**Неопределенное поведение дезинфицирующего средства.**
|
||||
Мы проводим функциональные и интеграционные тесты в асане на фиксации основы.
|
||||
|
||||
**Thread sanitizer**.
|
||||
We run functional tests under TSan on per-commit basis. We still don’t run integration tests under TSan on per-commit basis.
|
||||
**Дезинфицирующее средство для нитей**.
|
||||
Мы проводим функциональные тесты в рамках TSan на основе per-commit. Мы все еще не запускаем интеграционные тесты под TSan на основе per-commit.
|
||||
|
||||
**Memory sanitizer**.
|
||||
Currently we still don’t use MSan.
|
||||
**Дезинфицирующее средство для памяти**.
|
||||
В настоящее время мы все еще не используем MSan.
|
||||
|
||||
**Debug allocator.**
|
||||
Debug version of `jemalloc` is used for debug build.
|
||||
**Отладочный распределитель.**
|
||||
Отладочная версия `jemalloc` используется для отладки сборки.
|
||||
|
||||
## Fuzzing {#fuzzing}
|
||||
## Затуманивающего {#fuzzing}
|
||||
|
||||
We use simple fuzz test to generate random SQL queries and to check that the server doesn’t die. Fuzz testing is performed with Address sanitizer. You can find it in `00746_sql_fuzzy.pl`. This test should be run continuously (overnight and longer).
|
||||
Мы используем простой тест fuzz для генерации случайных SQL-запросов и проверки того, что сервер не умирает. Тестирование пуха проводится с помощью адресного дезинфицирующего средства. Вы можете найти его в `00746_sql_fuzzy.pl`. Этот тест следует проводить непрерывно (в течение ночи и дольше).
|
||||
|
||||
As of December 2018, we still don’t use isolated fuzz testing of library code.
|
||||
По состоянию на декабрь 2018 года мы все еще не используем изолированное тестирование fuzz библиотечного кода.
|
||||
|
||||
## Security Audit {#security-audit}
|
||||
## Аудит безопасности {#security-audit}
|
||||
|
||||
People from Yandex Cloud department do some basic overview of ClickHouse capabilities from the security standpoint.
|
||||
Люди из облачного отдела Яндекса делают некоторый базовый обзор возможностей ClickHouse с точки зрения безопасности.
|
||||
|
||||
## Static Analyzers {#static-analyzers}
|
||||
## Статический анализатор {#static-analyzers}
|
||||
|
||||
We run `PVS-Studio` on per-commit basis. We have evaluated `clang-tidy`, `Coverity`, `cppcheck`, `PVS-Studio`, `tscancode`. You will find instructions for usage in `tests/instructions/` directory. Also you can read [the article in russian](https://habr.com/company/yandex/blog/342018/).
|
||||
Мы бежим `PVS-Studio` на основе каждой фиксации. Мы провели оценку `clang-tidy`, `Coverity`, `cppcheck`, `PVS-Studio`, `tscancode`. Вы найдете инструкции по использованию в `tests/instructions/` каталог. Кроме того, вы можете читать [статья на русском языке](https://habr.com/company/yandex/blog/342018/).
|
||||
|
||||
If you use `CLion` as an IDE, you can leverage some `clang-tidy` checks out of the box.
|
||||
Если вы используете `CLion` как IDE, вы можете использовать некоторые из них `clang-tidy` выписывает чеки из коробки.
|
||||
|
||||
## Hardening {#hardening}
|
||||
## Затвердение {#hardening}
|
||||
|
||||
`FORTIFY_SOURCE` is used by default. It is almost useless, but still makes sense in rare cases and we don’t disable it.
|
||||
`FORTIFY_SOURCE` используется по умолчанию. Это почти бесполезно, но все же имеет смысл в редких случаях, и мы не отключаем его.
|
||||
|
||||
## Code Style {#code-style}
|
||||
## Стиль Кода {#code-style}
|
||||
|
||||
Code style rules are described [here](https://clickhouse.tech/docs/en/development/style/).
|
||||
Описаны правила стиля кода [здесь](https://clickhouse.tech/docs/en/development/style/).
|
||||
|
||||
To check for some common style violations, you can use `utils/check-style` script.
|
||||
Чтобы проверить наличие некоторых распространенных нарушений стиля, вы можете использовать `utils/check-style` скрипт.
|
||||
|
||||
To force proper style of your code, you can use `clang-format`. File `.clang-format` is located at the sources root. It mostly corresponding with our actual code style. But it’s not recommended to apply `clang-format` to existing files because it makes formatting worse. You can use `clang-format-diff` tool that you can find in clang source repository.
|
||||
Чтобы принудительно создать правильный стиль вашего кода, Вы можете использовать `clang-format`. Файл `.clang-format` находится в корне источника. Это в основном соответствует нашему фактическому стилю кода. Но применять его не рекомендуется `clang-format` к существующим файлам, потому что это ухудшает форматирование. Вы можете использовать `clang-format-diff` инструмент, который вы можете найти в репозитории Clang source.
|
||||
|
||||
Alternatively you can try `uncrustify` tool to reformat your code. Configuration is in `uncrustify.cfg` in the sources root. It is less tested than `clang-format`.
|
||||
В качестве альтернативы вы можете попробовать `uncrustify` инструмент для переформатирования вашего кода. Конфигурации в `uncrustify.cfg` в корне источников. Это меньше, чем `clang-format`.
|
||||
|
||||
`CLion` has its own code formatter that has to be tuned for our code style.
|
||||
`CLion` имеет свой собственный формататор кода, который должен быть настроен для нашего стиля кода.
|
||||
|
||||
## Metrica B2B Tests {#metrica-b2b-tests}
|
||||
## В2В метрика тесты {#metrica-b2b-tests}
|
||||
|
||||
Each ClickHouse release is tested with Yandex Metrica and AppMetrica engines. Testing and stable versions of ClickHouse are deployed on VMs and run with a small copy of Metrica engine that is processing fixed sample of input data. Then results of two instances of Metrica engine are compared together.
|
||||
Каждый релиз ClickHouse тестируется с помощью движков Yandex Metrica и AppMetrica. Тестовые и стабильные версии ClickHouse развертываются на виртуальных машинах и запускаются с небольшой копией движка Metrica engine, который обрабатывает фиксированную выборку входных данных. Затем результаты двух экземпляров двигателя Metrica сравниваются вместе.
|
||||
|
||||
These tests are automated by separate team. Due to high number of moving parts, tests are fail most of the time by completely unrelated reasons, that are very difficult to figure out. Most likely these tests have negative value for us. Nevertheless these tests was proved to be useful in about one or two times out of hundreds.
|
||||
Эти тесты автоматизированы отдельной командой. Из-за большого количества движущихся частей тесты чаще всего проваливаются по совершенно несвязанным причинам, которые очень трудно выяснить. Скорее всего, эти тесты имеют для нас отрицательное значение. Тем не менее эти тесты оказались полезными примерно в одном или двух случаях из сотен.
|
||||
|
||||
## Test Coverage {#test-coverage}
|
||||
## Тестовое покрытие {#test-coverage}
|
||||
|
||||
As of July 2018 we don’t track test coverage.
|
||||
По состоянию на июль 2018 года мы не отслеживаем покрытие тестов.
|
||||
|
||||
## Test Automation {#test-automation}
|
||||
## Автоматизация тестирования {#test-automation}
|
||||
|
||||
We run tests with Yandex internal CI and job automation system named “Sandbox”.
|
||||
Мы проводим тесты с помощью внутренней CI Яндекса и системы автоматизации заданий под названием «Sandbox».
|
||||
|
||||
Build jobs and tests are run in Sandbox on per commit basis. Resulting packages and test results are published in GitHub and can be downloaded by direct links. Artifacts are stored eternally. When you send a pull request on GitHub, we tag it as “can be tested” and our CI system will build ClickHouse packages (release, debug, with address sanitizer, etc) for you.
|
||||
Задания сборки и тесты выполняются в песочнице на основе каждой фиксации. Полученные пакеты и результаты тестирования публикуются на GitHub и могут быть загружены по прямым ссылкам. Артефакты хранятся вечно. Когда вы отправляете запрос на вытягивание на GitHub, мы помечаем его как «can be tested» и наша система CI построит пакеты ClickHouse (release, debug, with address sanitizer и т. д.) Для вас.
|
||||
|
||||
We don’t use Travis CI due to the limit on time and computational power.
|
||||
We don’t use Jenkins. It was used before and now we are happy we are not using Jenkins.
|
||||
Мы не используем Travis CI из-за ограничения по времени и вычислительной мощности.
|
||||
Мы не используем Дженкинса. Он был использован раньше, и теперь мы счастливы, что не используем Дженкинса.
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/development/tests/) <!--hide-->
|
||||
velopment/tests/) <!--hide-->
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/en/development/tests/) <!--hide-->
|
||||
разработка / испытания/) <!--hide-->
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
Движки баз данных обеспечивают работу с таблицами.
|
||||
|
||||
По умолчанию ClickHouse использует собственный движок баз данных, который поддерживает конфигурируемые [движки таблиц](../operations/table_engines/index.md) и [диалект SQL](../query_language/syntax.md).
|
||||
По умолчанию ClickHouse использует собственный движок баз данных, который поддерживает конфигурируемые [движки таблиц](../../engines/database_engines/index.md) и [диалект SQL](../../engines/database_engines/index.md).
|
||||
|
||||
Также можно использовать следующие движки баз данных:
|
||||
|
||||
@ -28,23 +28,23 @@ ENGINE = MySQL('host:port', ['database' | database], 'user', 'password')
|
||||
|
||||
| MySQL | ClickHouse |
|
||||
|----------------------------------|---------------------------------------------|
|
||||
| UNSIGNED TINYINT | [UInt8](../data_types/int_uint.md) |
|
||||
| TINYINT | [Int8](../data_types/int_uint.md) |
|
||||
| UNSIGNED SMALLINT | [UInt16](../data_types/int_uint.md) |
|
||||
| SMALLINT | [Int16](../data_types/int_uint.md) |
|
||||
| UNSIGNED INT, UNSIGNED MEDIUMINT | [UInt32](../data_types/int_uint.md) |
|
||||
| INT, MEDIUMINT | [Int32](../data_types/int_uint.md) |
|
||||
| UNSIGNED BIGINT | [UInt64](../data_types/int_uint.md) |
|
||||
| BIGINT | [Int64](../data_types/int_uint.md) |
|
||||
| FLOAT | [Float32](../data_types/float.md) |
|
||||
| DOUBLE | [Float64](../data_types/float.md) |
|
||||
| DATE | [Date](../data_types/date.md) |
|
||||
| DATETIME, TIMESTAMP | [DateTime](../data_types/datetime.md) |
|
||||
| BINARY | [FixedString](../data_types/fixedstring.md) |
|
||||
| UNSIGNED TINYINT | [UInt8](../../engines/database_engines/mysql.md) |
|
||||
| TINYINT | [Int8](../../engines/database_engines/mysql.md) |
|
||||
| UNSIGNED SMALLINT | [UInt16](../../engines/database_engines/mysql.md) |
|
||||
| SMALLINT | [Int16](../../engines/database_engines/mysql.md) |
|
||||
| UNSIGNED INT, UNSIGNED MEDIUMINT | [UInt32](../../engines/database_engines/mysql.md) |
|
||||
| INT, MEDIUMINT | [Int32](../../engines/database_engines/mysql.md) |
|
||||
| UNSIGNED BIGINT | [UInt64](../../engines/database_engines/mysql.md) |
|
||||
| BIGINT | [Int64](../../engines/database_engines/mysql.md) |
|
||||
| FLOAT | [Float32](../../engines/database_engines/mysql.md) |
|
||||
| DOUBLE | [Float64](../../engines/database_engines/mysql.md) |
|
||||
| DATE | [Date](../../engines/database_engines/mysql.md) |
|
||||
| DATETIME, TIMESTAMP | [DateTime](../../engines/database_engines/mysql.md) |
|
||||
| BINARY | [FixedString](../../engines/database_engines/mysql.md) |
|
||||
|
||||
Все прочие типы данных преобразуются в [String](../data_types/string.md).
|
||||
Все прочие типы данных преобразуются в [String](../../engines/database_engines/mysql.md).
|
||||
|
||||
[Nullable](../data_types/nullable.md) поддержан.
|
||||
[Nullable](../../engines/database_engines/mysql.md) поддержан.
|
||||
|
||||
## Примеры использования {#primery-ispolzovaniia}
|
||||
|
||||
6
docs/ru/engines/index.md
Normal file
6
docs/ru/engines/index.md
Normal file
@ -0,0 +1,6 @@
|
||||
---
|
||||
toc_folder_title: Engines
|
||||
toc_priority: 25
|
||||
---
|
||||
|
||||
|
||||
@ -13,27 +13,27 @@
|
||||
|
||||
### MergeTree {#mergetree}
|
||||
|
||||
Наиболее универсальные и функциональные движки таблиц для задач с высокой загрузкой. Общим свойством этих движков является быстрая вставка данных с последующей фоновой обработкой данных. Движки `*MergeTree` поддерживают репликацию данных (в [Replicated\*](replication.md) версиях движков), партиционирование, и другие возможности не поддержанные для других движков.
|
||||
Наиболее универсальные и функциональные движки таблиц для задач с высокой загрузкой. Общим свойством этих движков является быстрая вставка данных с последующей фоновой обработкой данных. Движки `*MergeTree` поддерживают репликацию данных (в [Replicated\*](mergetree_family/replication.md) версиях движков), партиционирование, и другие возможности не поддержанные для других движков.
|
||||
|
||||
Движки семейства:
|
||||
|
||||
- [MergeTree](mergetree.md)
|
||||
- [ReplacingMergeTree](replacingmergetree.md)
|
||||
- [SummingMergeTree](summingmergetree.md)
|
||||
- [AggregatingMergeTree](aggregatingmergetree.md)
|
||||
- [CollapsingMergeTree](collapsingmergetree.md)
|
||||
- [VersionedCollapsingMergeTree](versionedcollapsingmergetree.md)
|
||||
- [GraphiteMergeTree](graphitemergetree.md)
|
||||
- [MergeTree](mergetree_family/mergetree.md)
|
||||
- [ReplacingMergeTree](mergetree_family/replacingmergetree.md)
|
||||
- [SummingMergeTree](mergetree_family/summingmergetree.md)
|
||||
- [AggregatingMergeTree](mergetree_family/aggregatingmergetree.md)
|
||||
- [CollapsingMergeTree](mergetree_family/collapsingmergetree.md)
|
||||
- [VersionedCollapsingMergeTree](mergetree_family/versionedcollapsingmergetree.md)
|
||||
- [GraphiteMergeTree](mergetree_family/graphitemergetree.md)
|
||||
|
||||
### Log {#log}
|
||||
|
||||
Простые [движки](log_family.md) с минимальной функциональностью. Они наиболее эффективны, когда вам нужно быстро записать много небольших таблиц (до примерно 1 миллиона строк) и прочитать их позже целиком.
|
||||
Простые [движки](log_family/index.md) с минимальной функциональностью. Они наиболее эффективны, когда вам нужно быстро записать много небольших таблиц (до примерно 1 миллиона строк) и прочитать их позже целиком.
|
||||
|
||||
Движки семейства:
|
||||
|
||||
- [TinyLog](tinylog.md)
|
||||
- [StripeLog](stripelog.md)
|
||||
- [Log](log.md)
|
||||
- [TinyLog](log_family/tinylog.md)
|
||||
- [StripeLog](log_family/stripelog.md)
|
||||
- [Log](log_family/log.md)
|
||||
|
||||
### Движки для интеграции {#dvizhki-dlia-integratsii}
|
||||
|
||||
@ -41,27 +41,27 @@
|
||||
|
||||
Движки семейства:
|
||||
|
||||
- [Kafka](kafka.md)
|
||||
- [MySQL](mysql.md)
|
||||
- [ODBC](odbc.md)
|
||||
- [JDBC](jdbc.md)
|
||||
- [Kafka](integrations/kafka.md)
|
||||
- [MySQL](integrations/mysql.md)
|
||||
- [ODBC](integrations/odbc.md)
|
||||
- [JDBC](integrations/jdbc.md)
|
||||
|
||||
### Специальные движки {#spetsialnye-dvizhki}
|
||||
|
||||
Движки семейства:
|
||||
|
||||
- [Distributed](distributed.md)
|
||||
- [MaterializedView](materializedview.md)
|
||||
- [Dictionary](dictionary.md)
|
||||
- [Merge](merge.md)
|
||||
- [File](file.md)
|
||||
- [Null](null.md)
|
||||
- [Set](set.md)
|
||||
- [Join](join.md)
|
||||
- [URL](url.md)
|
||||
- [View](view.md)
|
||||
- [Memory](memory.md)
|
||||
- [Buffer](buffer.md)
|
||||
- [Distributed](special/distributed.md)
|
||||
- [MaterializedView](special/materializedview.md)
|
||||
- [Dictionary](special/dictionary.md)
|
||||
- [Merge](special/merge.md)
|
||||
- [File](special/file.md)
|
||||
- [Null](special/null.md)
|
||||
- [Set](special/set.md)
|
||||
- [Join](special/join.md)
|
||||
- [URL](special/url.md)
|
||||
- [View](special/view.md)
|
||||
- [Memory](special/memory.md)
|
||||
- [Buffer](special/buffer.md)
|
||||
|
||||
## Виртуальные столбцы {#table_engines-virtual-columns}
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# HDFS {#table_engines-hdfs}
|
||||
|
||||
Управляет данными в HDFS. Данный движок похож на движки [File](file.md) и [URL](url.md).
|
||||
Управляет данными в HDFS. Данный движок похож на движки [File](../special/file.md) и [URL](../special/url.md).
|
||||
|
||||
## Использование движка {#ispolzovanie-dvizhka}
|
||||
|
||||
@ -9,7 +9,7 @@ ENGINE = HDFS(URI, format)
|
||||
```
|
||||
|
||||
В параметр `URI` нужно передавать полный URI файла в HDFS.
|
||||
Параметр `format` должен быть таким, который ClickHouse может использовать и в запросах `INSERT`, и в запросах `SELECT`. Полный список поддерживаемых форматов смотрите в разделе [Форматы](../../interfaces/formats.md#formats).
|
||||
Параметр `format` должен быть таким, который ClickHouse может использовать и в запросах `INSERT`, и в запросах `SELECT`. Полный список поддерживаемых форматов смотрите в разделе [Форматы](../../../interfaces/formats.md#formats).
|
||||
Часть URI с путем файла может содержать шаблоны. В этом случае таблица может использоваться только для чтения.
|
||||
|
||||
**Пример:**
|
||||
@ -56,7 +56,7 @@ SELECT * FROM hdfs_engine_table LIMIT 2
|
||||
- `{some_string,another_string,yet_another_one}` — Заменяет любую из строк `'some_string', 'another_string', 'yet_another_one'`.
|
||||
- `{N..M}` — Заменяет любое число в интервале от `N` до `M` включительно (может содержать ведущие нули).
|
||||
|
||||
Конструкция с `{}` аналогична табличной функции [remote](../../query_language/table_functions/remote.md).
|
||||
Конструкция с `{}` аналогична табличной функции [remote](../../../engines/table_engines/integrations/hdfs.md).
|
||||
|
||||
**Пример**
|
||||
|
||||
5
docs/ru/engines/table_engines/integrations/index.md
Normal file
5
docs/ru/engines/table_engines/integrations/index.md
Normal file
@ -0,0 +1,5 @@
|
||||
---
|
||||
toc_folder_title: Integrations
|
||||
toc_priority: 30
|
||||
---
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
Для реализации соединения по JDBC ClickHouse использует отдельную программу [clickhouse-jdbc-bridge](https://github.com/alex-krash/clickhouse-jdbc-bridge), которая должна запускаться как демон.
|
||||
|
||||
Движок поддерживает тип данных [Nullable](../../data_types/nullable.md).
|
||||
Движок поддерживает тип данных [Nullable](../../../engines/table_engines/integrations/jdbc.md).
|
||||
|
||||
## Создание таблицы {#sozdanie-tablitsy}
|
||||
|
||||
@ -82,6 +82,6 @@ FROM jdbc_table
|
||||
|
||||
## Смотрите также {#smotrite-takzhe}
|
||||
|
||||
- [Табличная функция JDBC](../../query_language/table_functions/jdbc.md).
|
||||
- [Табличная функция JDBC](../../../engines/table_engines/integrations/jdbc.md).
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/table_engines/jdbc/) <!--hide-->
|
||||
@ -33,7 +33,7 @@ SETTINGS
|
||||
- `kafka_broker_list` – перечень брокеров, разделенный запятыми (`localhost:9092`).
|
||||
- `kafka_topic_list` – перечень необходимых топиков Kafka.
|
||||
- `kafka_group_name` – группа потребителя Kafka. Отступы для чтения отслеживаются для каждой группы отдельно. Если необходимо, чтобы сообщения не повторялись на кластере, используйте везде одно имя группы.
|
||||
- `kafka_format` – формат сообщений. Названия форматов должны быть теми же, что можно использовать в секции `FORMAT`, например, `JSONEachRow`. Подробнее читайте в разделе [Форматы](../../interfaces/formats.md).
|
||||
- `kafka_format` – формат сообщений. Названия форматов должны быть теми же, что можно использовать в секции `FORMAT`, например, `JSONEachRow`. Подробнее читайте в разделе [Форматы](../../../interfaces/formats.md).
|
||||
|
||||
Опциональные параметры:
|
||||
|
||||
@ -123,7 +123,7 @@ Kafka(kafka_broker_list, kafka_topic_list, kafka_group_name, kafka_format
|
||||
SELECT level, sum(total) FROM daily GROUP BY level;
|
||||
```
|
||||
|
||||
Для улучшения производительности полученные сообщения группируются в блоки размера [max\_insert\_block\_size](../settings/settings.md#settings-max_insert_block_size). Если блок не удалось сформировать за [stream\_flush\_interval\_ms](../settings/settings.md) миллисекунд, то данные будут сброшены в таблицу независимо от полноты блока.
|
||||
Для улучшения производительности полученные сообщения группируются в блоки размера [max\_insert\_block\_size](../../../operations/settings/settings.md#settings-max_insert_block_size). Если блок не удалось сформировать за [stream\_flush\_interval\_ms](../../../operations/settings/settings.md) миллисекунд, то данные будут сброшены в таблицу независимо от полноты блока.
|
||||
|
||||
Чтобы остановить получение данных топика или изменить логику преобразования, отсоедините материализованное представление:
|
||||
|
||||
@ -13,12 +13,12 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
) ENGINE = MySQL('host:port', 'database', 'table', 'user', 'password'[, replace_query, 'on_duplicate_clause']);
|
||||
```
|
||||
|
||||
Смотрите подробное описание запроса [CREATE TABLE](../../query_language/create.md#create-table-query).
|
||||
Смотрите подробное описание запроса [CREATE TABLE](../../../engines/table_engines/integrations/mysql.md#create-table-query).
|
||||
|
||||
Структура таблицы может отличаться от исходной структуры таблицы MySQL:
|
||||
|
||||
- Имена столбцов должны быть такими же, как в исходной таблице MySQL, но вы можете использовать только некоторые из этих столбцов и в любом порядке.
|
||||
- Типы столбцов могут отличаться от типов в исходной таблице MySQL. ClickHouse пытается [приводить](../../query_language/functions/type_conversion_functions.md#type_conversion_function-cast) значения к типам данных ClickHouse.
|
||||
- Типы столбцов могут отличаться от типов в исходной таблице MySQL. ClickHouse пытается [приводить](../../../engines/table_engines/integrations/mysql.md#type_conversion_function-cast) значения к типам данных ClickHouse.
|
||||
|
||||
**Параметры движка**
|
||||
|
||||
@ -92,7 +92,7 @@ SELECT * FROM mysql_table
|
||||
|
||||
## Смотрите также {#smotrite-takzhe}
|
||||
|
||||
- [Табличная функция ‘mysql’](../../query_language/table_functions/mysql.md)
|
||||
- [Использование MySQL в качестве источника для внешнего словаря](../../query_language/dicts/external_dicts_dict_sources.md#dicts-external_dicts_dict_sources-mysql)
|
||||
- [Табличная функция ‘mysql’](../../../engines/table_engines/integrations/mysql.md)
|
||||
- [Использование MySQL в качестве источника для внешнего словаря](../../../engines/table_engines/integrations/mysql.md#dicts-external_dicts_dict_sources-mysql)
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/table_engines/mysql/) <!--hide-->
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
Чтобы использование ODBC было безопасным, ClickHouse использует отдельную программу `clickhouse-odbc-bridge`. Если драйвер ODBC подгружать непосредственно из `clickhouse-server`, то проблемы с драйвером могут привести к аварийной остановке сервера ClickHouse. ClickHouse автоматически запускает `clickhouse-odbc-bridge` по мере необходимости. Программа устанавливается из того же пакета, что и `clickhouse-server`.
|
||||
|
||||
Движок поддерживает тип данных [Nullable](../../data_types/nullable.md).
|
||||
Движок поддерживает тип данных [Nullable](../../../engines/table_engines/integrations/odbc.md).
|
||||
|
||||
## Создание таблицы {#sozdanie-tablitsy}
|
||||
|
||||
@ -18,12 +18,12 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
ENGINE = ODBC(connection_settings, external_database, external_table)
|
||||
```
|
||||
|
||||
Смотрите подробное описание запроса [CREATE TABLE](../../query_language/create.md#create-table-query).
|
||||
Смотрите подробное описание запроса [CREATE TABLE](../../../engines/table_engines/integrations/odbc.md#create-table-query).
|
||||
|
||||
Структура таблицы может отличаться от структуры исходной таблицы в удалённой СУБД:
|
||||
|
||||
- Имена столбцов должны быть такими же, как в исходной таблице, но вы можете использовать только некоторые из этих столбцов и в любом порядке.
|
||||
- Типы столбцов могут отличаться от типов аналогичных столбцов в исходной таблице. ClickHouse пытается [приводить](../../query_language/functions/type_conversion_functions.md#type_conversion_function-cast) значения к типам данных ClickHouse.
|
||||
- Типы столбцов могут отличаться от типов аналогичных столбцов в исходной таблице. ClickHouse пытается [приводить](../../../engines/table_engines/integrations/odbc.md#type_conversion_function-cast) значения к типам данных ClickHouse.
|
||||
|
||||
**Параметры движка**
|
||||
|
||||
@ -119,7 +119,7 @@ SELECT * FROM odbc_t
|
||||
|
||||
## Смотрите также {#smotrite-takzhe}
|
||||
|
||||
- [Внешние словари ODBC](../../query_language/dicts/external_dicts_dict_sources.md#dicts-external_dicts_dict_sources-odbc)
|
||||
- [Табличная функция odbc](../../query_language/table_functions/odbc.md)
|
||||
- [Внешние словари ODBC](../../../engines/table_engines/integrations/odbc.md#dicts-external_dicts_dict_sources-odbc)
|
||||
- [Табличная функция odbc](../../../engines/table_engines/integrations/odbc.md)
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/table_engines/odbc/) <!--hide-->
|
||||
5
docs/ru/engines/table_engines/log_family/index.md
Normal file
5
docs/ru/engines/table_engines/log_family/index.md
Normal file
@ -0,0 +1,5 @@
|
||||
---
|
||||
toc_folder_title: Log Family
|
||||
toc_priority: 29
|
||||
---
|
||||
|
||||
@ -20,7 +20,7 @@
|
||||
|
||||
Во время запросов `INSERT` таблица блокируется, а другие запросы на чтение и запись ожидают разблокировки таблицы. Если запросов на запись данных нет, то можно выполнять любое количество конкуретных запросов на чтение.
|
||||
|
||||
- Не поддерживают операции [мутации](../../query_language/alter.md#alter-mutations).
|
||||
- Не поддерживают операции [мутации](../../../engines/table_engines/log_family/log_family.md#alter-mutations).
|
||||
|
||||
- Не поддерживают индексы.
|
||||
|
||||
@ -15,7 +15,7 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
) ENGINE = StripeLog
|
||||
```
|
||||
|
||||
Смотрите подробное описание запроса [CREATE TABLE](../../query_language/create.md#create-table-query).
|
||||
Смотрите подробное описание запроса [CREATE TABLE](../../../engines/table_engines/log_family/stripelog.md#create-table-query).
|
||||
|
||||
## Запись данных {#table_engines-stripelog-writing-the-data}
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
Таблицы типа `AggregatingMergeTree` могут использоваться для инкрементальной агрегации данных, в том числе, для агрегирующих материализованных представлений.
|
||||
|
||||
Движок обрабатывает все столбцы типа [AggregateFunction](../../data_types/nested_data_structures/aggregatefunction.md).
|
||||
Движок обрабатывает все столбцы типа [AggregateFunction](../../../engines/table_engines/mergetree_family/aggregatingmergetree.md).
|
||||
|
||||
Использование `AggregatingMergeTree` оправдано только в том случае, когда это уменьшает количество строк на порядки.
|
||||
|
||||
@ -23,7 +23,7 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
[SETTINGS name=value, ...]
|
||||
```
|
||||
|
||||
Описание параметров запроса смотрите в [описании запроса](../../query_language/create.md).
|
||||
Описание параметров запроса смотрите в [описании запроса](../../../engines/table_engines/mergetree_family/aggregatingmergetree.md).
|
||||
|
||||
**Секции запроса**
|
||||
|
||||
@ -21,7 +21,7 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
[SETTINGS name=value, ...]
|
||||
```
|
||||
|
||||
Подробности про `CREATE TABLE` смотрите в [описании запроса](../../query_language/create.md).
|
||||
Подробности про `CREATE TABLE` смотрите в [описании запроса](../../../engines/table_engines/mergetree_family/collapsingmergetree.md).
|
||||
|
||||
**Параметры CollapsingMergeTree**
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Произвольный ключ партиционирования {#proizvolnyi-kliuch-partitsionirovaniia}
|
||||
|
||||
Партиционирование данных доступно для таблиц семейства [MergeTree](mergetree.md) (включая [реплицированные таблицы](replication.md)). Таблицы [MaterializedView](materializedview.md), созданные на основе таблиц MergeTree, также поддерживают партиционирование.
|
||||
Партиционирование данных доступно для таблиц семейства [MergeTree](mergetree.md) (включая [реплицированные таблицы](replication.md)). Таблицы [MaterializedView](../special/materializedview.md), созданные на основе таблиц MergeTree, также поддерживают партиционирование.
|
||||
|
||||
Партиция – это набор записей в таблице, объединенных по какому-либо критерию. Например, партиция может быть по месяцу, по дню или по типу события. Данные для разных партиций хранятся отдельно. Это позволяет оптимизировать работу с данными, так как при обработке запросов будет использоваться только необходимое подмножество из всевозможных данных. Например, при получении данных за определенный месяц, ClickHouse будет считывать данные только за этот месяц.
|
||||
|
||||
@ -33,7 +33,7 @@ ORDER BY (CounterID, StartDate, intHash32(UserID));
|
||||
!!! info "Info"
|
||||
Не рекомендуется делать слишком гранулированное партиционирование – то есть задавать партиции по столбцу, в котором будет слишком большой разброс значений (речь идет о порядке более тысячи партиций). Это приведет к скоплению большого числа файлов и файловых дескрипторов в системе, что может значительно снизить производительность запросов `SELECT`.
|
||||
|
||||
Чтобы получить набор кусков и партиций таблицы, можно воспользоваться системной таблицей [system.parts](../system_tables.md#system_tables-parts). В качестве примера рассмотрим таблицу `visits`, в которой задано партиционирование по месяцам. Выполним `SELECT` для таблицы `system.parts`:
|
||||
Чтобы получить набор кусков и партиций таблицы, можно воспользоваться системной таблицей [system.parts](../../../engines/table_engines/mergetree_family/custom_partitioning_key.md#system_tables-parts). В качестве примера рассмотрим таблицу `visits`, в которой задано партиционирование по месяцам. Выполним `SELECT` для таблицы `system.parts`:
|
||||
|
||||
``` sql
|
||||
SELECT
|
||||
@ -74,7 +74,7 @@ WHERE table = 'visits'
|
||||
|
||||
Как видно из примера выше, таблица содержит несколько отдельных кусков для одной и той же партиции (например, куски `201901_1_3_1` и `201901_1_9_2` принадлежат партиции `201901`). Это означает, что эти куски еще не были объединены – в файловой системе они хранятся отдельно. После того как будет выполнено автоматическое слияние данных (выполняется примерно спустя 10 минут после вставки данных), исходные куски будут объединены в один более крупный кусок и помечены как неактивные.
|
||||
|
||||
Вы можете запустить внеочередное слияние данных с помощью запроса [OPTIMIZE](../../query_language/misc.md#misc_operations-optimize). Пример:
|
||||
Вы можете запустить внеочередное слияние данных с помощью запроса [OPTIMIZE](../../../engines/table_engines/mergetree_family/custom_partitioning_key.md#misc_operations-optimize). Пример:
|
||||
|
||||
``` sql
|
||||
OPTIMIZE TABLE visits PARTITION 201902;
|
||||
@ -115,12 +115,12 @@ drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 1 16:48 detached
|
||||
|
||||
Директория `detached` содержит куски, отсоединенные от таблицы с помощью запроса [DETACH](#alter_detach-partition). Поврежденные куски также попадают в эту директорию – они не удаляются с сервера.
|
||||
|
||||
Сервер не использует куски из директории `detached`. Вы можете в любое время добавлять, удалять, модифицировать данные в директории detached - сервер не будет об этом знать, пока вы не сделаете запрос [ATTACH](../../query_language/alter.md#alter_attach-partition).
|
||||
Сервер не использует куски из директории `detached`. Вы можете в любое время добавлять, удалять, модифицировать данные в директории detached - сервер не будет об этом знать, пока вы не сделаете запрос [ATTACH](../../../engines/table_engines/mergetree_family/custom_partitioning_key.md#alter_attach-partition).
|
||||
|
||||
Следует иметь в виду, что при работающем сервере нельзя вручную изменять набор кусков на файловой системе, так как сервер не будет знать об этом.
|
||||
Для нереплицируемых таблиц, вы можете это делать при остановленном сервере, однако это не рекомендуется.
|
||||
Для реплицируемых таблиц, набор кусков нельзя менять в любом случае.
|
||||
|
||||
ClickHouse позволяет производить различные манипуляции с кусками: удалять, копировать из одной таблицы в другую или создавать их резервные копии. Подробнее см. в разделе [Манипуляции с партициями и кусками](../../query_language/alter.md#alter_manipulations-with-partitions).
|
||||
ClickHouse позволяет производить различные манипуляции с кусками: удалять, копировать из одной таблицы в другую или создавать их резервные копии. Подробнее см. в разделе [Манипуляции с партициями и кусками](../../../engines/table_engines/mergetree_family/custom_partitioning_key.md#alter_manipulations-with-partitions).
|
||||
|
||||
[Оригинальная статья:](https://clickhouse.tech/docs/ru/operations/table_engines/custom_partitioning_key/) <!--hide-->
|
||||
@ -23,7 +23,7 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
[SETTINGS name=value, ...]
|
||||
```
|
||||
|
||||
Смотрите описание запроса [CREATE TABLE](../../query_language/create.md#create-table-query).
|
||||
Смотрите описание запроса [CREATE TABLE](../../../engines/table_engines/mergetree_family/graphitemergetree.md#create-table-query).
|
||||
|
||||
В таблице должны быть столбцы для следующих данных:
|
||||
|
||||
@ -74,7 +74,7 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
|
||||
## Конфигурация rollup {#rollup-configuration}
|
||||
|
||||
Настройки прореживания данных задаются параметром [graphite\_rollup](../server_settings/settings.md#server_settings-graphite_rollup) в конфигурации сервера . Имя параметра может быть любым. Можно создать несколько конфигураций и использовать их для разных таблиц.
|
||||
Настройки прореживания данных задаются параметром [graphite\_rollup](../../../operations/server_configuration_parameters/settings.md#server_configuration_parameters-graphite_rollup) в конфигурации сервера . Имя параметра может быть любым. Можно создать несколько конфигураций и использовать их для разных таблиц.
|
||||
|
||||
Структура конфигурации rollup:
|
||||
|
||||
5
docs/ru/engines/table_engines/mergetree_family/index.md
Normal file
5
docs/ru/engines/table_engines/mergetree_family/index.md
Normal file
@ -0,0 +1,5 @@
|
||||
---
|
||||
toc_folder_title: MergeTree Family
|
||||
toc_priority: 28
|
||||
---
|
||||
|
||||
@ -23,7 +23,7 @@
|
||||
При необходимости можно задать способ сэмплирования данных в таблице.
|
||||
|
||||
!!! info "Info"
|
||||
Движок [Merge](merge.md) не относится к семейству `*MergeTree`.
|
||||
Движок [Merge](../special/merge.md) не относится к семейству `*MergeTree`.
|
||||
|
||||
## Создание таблицы {#table_engine-mergetree-creating-a-table}
|
||||
|
||||
@ -44,7 +44,7 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
[SETTINGS name=value, ...]
|
||||
```
|
||||
|
||||
Описание параметров смотрите в [описании запроса CREATE](../../query_language/create.md).
|
||||
Описание параметров смотрите в [описании запроса CREATE](../../../engines/table_engines/mergetree_family/mergetree.md).
|
||||
|
||||
!!! note "Note"
|
||||
`INDEX` — экспериментальная возможность, смотрите [Индексы пропуска данных](#table_engine-mergetree-data_skipping-indexes).
|
||||
@ -55,7 +55,7 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
|
||||
- `PARTITION BY` — [ключ партиционирования](custom_partitioning_key.md).
|
||||
|
||||
Для партиционирования по месяцам используйте выражение `toYYYYMM(date_column)`, где `date_column` — столбец с датой типа [Date](../../data_types/date.md). В этом случае имена партиций имеют формат `"YYYYMM"`.
|
||||
Для партиционирования по месяцам используйте выражение `toYYYYMM(date_column)`, где `date_column` — столбец с датой типа [Date](../../../engines/table_engines/mergetree_family/mergetree.md). В этом случае имена партиций имеют формат `"YYYYMM"`.
|
||||
|
||||
- `ORDER BY` — ключ сортировки.
|
||||
|
||||
@ -84,7 +84,7 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
- `index_granularity` — максимальное количество строк данных между засечками индекса. По умолчанию — 8192. Смотрите [Хранение данных](#mergetree-data-storage).
|
||||
- `index_granularity_bytes` — максимальный размер гранул данных в байтах. По умолчанию — 10Mb. Чтобы ограничить размер гранул только количеством строк, установите значение 0 (не рекомендовано). Смотрите [Хранение данных](#mergetree-data-storage).
|
||||
- `enable_mixed_granularity_parts` — включает или выключает переход к ограничению размера гранул с помощью настройки `index_granularity_bytes`. До версии 19.11, размер гранул ограничивался только настройкой `index_granularity`. Настройка `index_granularity_bytes` улучшает производительность ClickHouse при выборке данных из таблиц с большими (десятки и сотни мегабайтов) строками. Если у вас есть таблицы с большими строками, можно включить эту настройку, чтобы повысить эффективность запросов `SELECT`.
|
||||
- `use_minimalistic_part_header_in_zookeeper` — Способ хранения заголовков кусков данных в ZooKeeper. Если `use_minimalistic_part_header_in_zookeeper = 1`, то ZooKeeper хранит меньше данных. Подробнее читайте в [описании настройки](../server_settings/settings.md#server-settings-use_minimalistic_part_header_in_zookeeper) в разделе "Конфигурационные параметры сервера".
|
||||
- `use_minimalistic_part_header_in_zookeeper` — Способ хранения заголовков кусков данных в ZooKeeper. Если `use_minimalistic_part_header_in_zookeeper = 1`, то ZooKeeper хранит меньше данных. Подробнее читайте в [описании настройки](../../../operations/server_configuration_parameters/settings.md#server-settings-use_minimalistic_part_header_in_zookeeper) в разделе "Конфигурационные параметры сервера".
|
||||
- `min_merge_bytes_to_use_direct_io` — минимальный объём данных при слиянии, необходимый для прямого (небуферизованного) чтения/записи (direct I/O) на диск. При слиянии частей данных ClickHouse вычисляет общий объём хранения всех данных, подлежащих слиянию. Если общий объём хранения всех данных для чтения превышает `min_bytes_to_use_direct_io` байт, тогда ClickHouse использует флаг `O_DIRECT` при чтении данных с диска. Если `min_merge_bytes_to_use_direct_io = 0`, тогда прямой ввод-вывод отключен. Значение по умолчанию: `10 * 1024 * 1024 * 1024` байтов.
|
||||
<a name="mergetree_setting-merge_with_ttl_timeout"></a>
|
||||
- `merge_with_ttl_timeout` — минимальное время в секундах перед повторным слиянием с TTL. По умолчанию — 86400 (1 день).
|
||||
@ -100,7 +100,7 @@ ENGINE MergeTree() PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDa
|
||||
|
||||
В примере мы устанавливаем партиционирование по месяцам.
|
||||
|
||||
Также мы задаем выражение для сэмплирования в виде хэша по идентификатору посетителя. Это позволяет псевдослучайным образом перемешать данные в таблице для каждого `CounterID` и `EventDate`. Если при выборке данных задать секцию [SAMPLE](../../query_language/select.md#select-sample-clause), то ClickHouse вернёт равномерно-псевдослучайную выборку данных для подмножества посетителей.
|
||||
Также мы задаем выражение для сэмплирования в виде хэша по идентификатору посетителя. Это позволяет псевдослучайным образом перемешать данные в таблице для каждого `CounterID` и `EventDate`. Если при выборке данных задать секцию [SAMPLE](../../../engines/table_engines/mergetree_family/mergetree.md#select-sample-clause), то ClickHouse вернёт равномерно-псевдослучайную выборку данных для подмножества посетителей.
|
||||
|
||||
`index_granularity` можно было не указывать, поскольку 8192 — это значение по умолчанию.
|
||||
|
||||
@ -122,9 +122,9 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
|
||||
**Параметры MergeTree()**
|
||||
|
||||
- `date-column` — имя столбца с типом [Date](../../data_types/date.md). На основе этого столбца ClickHouse автоматически создаёт партиции по месяцам. Имена партиций имеют формат `"YYYYMM"`.
|
||||
- `date-column` — имя столбца с типом [Date](../../../engines/table_engines/mergetree_family/mergetree.md). На основе этого столбца ClickHouse автоматически создаёт партиции по месяцам. Имена партиций имеют формат `"YYYYMM"`.
|
||||
- `sampling_expression` — выражение для сэмплирования.
|
||||
- `(primary, key)` — первичный ключ. Тип — [Tuple()](../../data_types/tuple.md)
|
||||
- `(primary, key)` — первичный ключ. Тип — [Tuple()](../../../engines/table_engines/mergetree_family/mergetree.md)
|
||||
- `index_granularity` — гранулярность индекса. Число строк данных между «засечками» индекса. Для большинства задач подходит значение 8192.
|
||||
|
||||
**Пример**
|
||||
@ -214,7 +214,7 @@ ClickHouse не требует уникального первичного кл
|
||||
|
||||
В этом сценарии имеет смысл оставить в первичном ключе всего несколько столбцов, которые обеспечат эффективную фильтрацию по индексу, а остальные столбцы-измерения добавить в выражение ключа сортировки.
|
||||
|
||||
[ALTER ключа сортировки](../../query_language/alter.md) — лёгкая операция, так как при одновременном добавлении нового столбца в таблицу и ключ сортировки не нужно изменять данные кусков (они остаются упорядоченными и по новому выражению ключа).
|
||||
[ALTER ключа сортировки](../../../engines/table_engines/mergetree_family/mergetree.md) — лёгкая операция, так как при одновременном добавлении нового столбца в таблицу и ключ сортировки не нужно изменять данные кусков (они остаются упорядоченными и по новому выражению ключа).
|
||||
|
||||
### Использование индексов и партиций в запросах {#ispolzovanie-indeksov-i-partitsii-v-zaprosakh}
|
||||
|
||||
@ -246,7 +246,7 @@ ClickHouse будет использовать индекс по первичн
|
||||
SELECT count() FROM table WHERE CounterID = 34 OR URL LIKE '%upyachka%'
|
||||
```
|
||||
|
||||
Чтобы проверить, сможет ли ClickHouse использовать индекс при выполнении запроса, используйте настройки [force\_index\_by\_date](../settings/settings.md#settings-force_index_by_date) и [force\_primary\_key](../settings/settings.md#settings-force_primary_key).
|
||||
Чтобы проверить, сможет ли ClickHouse использовать индекс при выполнении запроса, используйте настройки [force\_index\_by\_date](../../../operations/settings/settings.md#settings-force_index_by_date) и [force\_primary\_key](../../../operations/settings/settings.md#settings-force_primary_key).
|
||||
|
||||
Ключ партиционирования по месяцам обеспечивает чтение только тех блоков данных, которые содержат даты из нужного диапазона. При этом блок данных может содержать данные за многие даты (до целого месяца). В пределах одного блока данные упорядочены по первичному ключу, который может не содержать дату в качестве первого столбца. В связи с этим, при использовании запроса с указанием условия только на дату, но не на префикс первичного ключа, будет читаться данных больше, чем за одну дату.
|
||||
|
||||
@ -304,7 +304,7 @@ SELECT count() FROM table WHERE u64 * i32 == 10 AND u64 * length(s) >= 1234
|
||||
|
||||
Поддержанные типы данных: `Int*`, `UInt*`, `Float*`, `Enum`, `Date`, `DateTime`, `String`, `FixedString`.
|
||||
|
||||
Фильтром могут пользоваться функции: [equals](../../query_language/functions/comparison_functions.md), [notEquals](../../query_language/functions/comparison_functions.md), [in](../../query_language/functions/in_functions.md), [notIn](../../query_language/functions/in_functions.md).
|
||||
Фильтром могут пользоваться функции: [equals](../../../engines/table_engines/mergetree_family/mergetree.md), [notEquals](../../../engines/table_engines/mergetree_family/mergetree.md), [in](../../../engines/table_engines/mergetree_family/mergetree.md), [notIn](../../../engines/table_engines/mergetree_family/mergetree.md).
|
||||
|
||||
**Примеры**
|
||||
|
||||
@ -321,21 +321,21 @@ INDEX b (u64 * length(str), i32 + f64 * 100, date, str) TYPE set(100) GRANULARIT
|
||||
|
||||
| Function (operator) / Index | primary key | minmax | ngrambf\_v1 | tokenbf\_v1 | bloom\_filter |
|
||||
|----------------------------------------------------------------------------------------------------------|-------------|--------|-------------|-------------|---------------|
|
||||
| [equals (=, ==)](../../query_language/functions/comparison_functions.md#function-equals) | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||
| [notEquals(!=, \<\>)](../../query_language/functions/comparison_functions.md#function-notequals) | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||
| [like](../../query_language/functions/string_search_functions.md#function-like) | ✔ | ✔ | ✔ | ✗ | ✗ |
|
||||
| [notLike](../../query_language/functions/string_search_functions.md#function-notlike) | ✔ | ✔ | ✔ | ✔ | ✗ |
|
||||
| [startsWith](../../query_language/functions/string_functions.md#startswith) | ✔ | ✔ | ✔ | ✔ | ✗ |
|
||||
| [endsWith](../../query_language/functions/string_functions.md#endswith) | ✗ | ✗ | ✔ | ✔ | ✗ |
|
||||
| [multiSearchAny](../../query_language/functions/string_search_functions.md#function-multisearchany) | ✗ | ✗ | ✔ | ✔ | ✗ |
|
||||
| [in](../../query_language/functions/in_functions.md#in-functions) | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||
| [notIn](../../query_language/functions/in_functions.md#in-functions) | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||
| [less (\<)](../../query_language/functions/comparison_functions.md#function-less) | ✔ | ✔ | ✗ | ✗ | ✗ |
|
||||
| [greater (\>)](../../query_language/functions/comparison_functions.md#function-greater) | ✔ | ✔ | ✗ | ✗ | ✗ |
|
||||
| [lessOrEquals (\<=)](../../query_language/functions/comparison_functions.md#function-lessorequals) | ✔ | ✔ | ✗ | ✗ | ✗ |
|
||||
| [greaterOrEquals (\>=)](../../query_language/functions/comparison_functions.md#function-greaterorequals) | ✔ | ✔ | ✗ | ✗ | ✗ |
|
||||
| [empty](../../query_language/functions/array_functions.md#function-empty) | ✔ | ✔ | ✗ | ✗ | ✗ |
|
||||
| [notEmpty](../../query_language/functions/array_functions.md#function-notempty) | ✔ | ✔ | ✗ | ✗ | ✗ |
|
||||
| [equals (=, ==)](../../../engines/table_engines/mergetree_family/mergetree.md#function-equals) | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||
| [notEquals(!=, \<\>)](../../../engines/table_engines/mergetree_family/mergetree.md#function-notequals) | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||
| [like](../../../engines/table_engines/mergetree_family/mergetree.md#function-like) | ✔ | ✔ | ✔ | ✗ | ✗ |
|
||||
| [notLike](../../../engines/table_engines/mergetree_family/mergetree.md#function-notlike) | ✔ | ✔ | ✔ | ✔ | ✗ |
|
||||
| [startsWith](../../../engines/table_engines/mergetree_family/mergetree.md#startswith) | ✔ | ✔ | ✔ | ✔ | ✗ |
|
||||
| [endsWith](../../../engines/table_engines/mergetree_family/mergetree.md#endswith) | ✗ | ✗ | ✔ | ✔ | ✗ |
|
||||
| [multiSearchAny](../../../engines/table_engines/mergetree_family/mergetree.md#function-multisearchany) | ✗ | ✗ | ✔ | ✔ | ✗ |
|
||||
| [in](../../../engines/table_engines/mergetree_family/mergetree.md#in-functions) | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||
| [notIn](../../../engines/table_engines/mergetree_family/mergetree.md#in-functions) | ✔ | ✔ | ✔ | ✔ | ✔ |
|
||||
| [less (\<)](../../../engines/table_engines/mergetree_family/mergetree.md#function-less) | ✔ | ✔ | ✗ | ✗ | ✗ |
|
||||
| [greater (\>)](../../../engines/table_engines/mergetree_family/mergetree.md#function-greater) | ✔ | ✔ | ✗ | ✗ | ✗ |
|
||||
| [lessOrEquals (\<=)](../../../engines/table_engines/mergetree_family/mergetree.md#function-lessorequals) | ✔ | ✔ | ✗ | ✗ | ✗ |
|
||||
| [greaterOrEquals (\>=)](../../../engines/table_engines/mergetree_family/mergetree.md#function-greaterorequals) | ✔ | ✔ | ✗ | ✗ | ✗ |
|
||||
| [empty](../../../engines/table_engines/mergetree_family/mergetree.md#function-empty) | ✔ | ✔ | ✗ | ✗ | ✗ |
|
||||
| [notEmpty](../../../engines/table_engines/mergetree_family/mergetree.md#function-notempty) | ✔ | ✔ | ✗ | ✗ | ✗ |
|
||||
| hasToken | ✗ | ✗ | ✗ | ✔ | ✗ |
|
||||
|
||||
Функции с постоянным агрументом, который меньше, чем размер ngram не могут использовать индекс `ngrambf_v1` для оптимизации запроса.
|
||||
@ -367,7 +367,7 @@ INDEX b (u64 * length(str), i32 + f64 * 100, date, str) TYPE set(100) GRANULARIT
|
||||
|
||||
Секция `TTL` может быть установлена как для всей таблицы, так и для каждого отдельного столбца. Правила `TTL` для таблицы позволяют указать целевые диски или тома для фонового перемещения на них частей данных.
|
||||
|
||||
Выражения должны возвращать тип [Date](../../data_types/date.md) или [DateTime](../../data_types/datetime.md).
|
||||
Выражения должны возвращать тип [Date](../../../engines/table_engines/mergetree_family/mergetree.md) или [DateTime](../../../engines/table_engines/mergetree_family/mergetree.md).
|
||||
|
||||
Для задания времени жизни столбца, например:
|
||||
|
||||
@ -376,7 +376,7 @@ TTL time_column
|
||||
TTL time_column + interval
|
||||
```
|
||||
|
||||
Чтобы задать `interval`, используйте операторы [интервала времени](../../query_language/operators.md#operators-datetime).
|
||||
Чтобы задать `interval`, используйте операторы [интервала времени](../../../engines/table_engines/mergetree_family/mergetree.md#operators-datetime).
|
||||
|
||||
``` sql
|
||||
TTL date_time + INTERVAL 1 MONTH
|
||||
@ -465,7 +465,7 @@ ALTER TABLE example_table
|
||||
|
||||
Когда ClickHouse видит, что некоторые данные устарели, он выполняет внеплановые мёржи. Для управление частотой подобных мёржей, можно задать настройку [merge\_with\_ttl\_timeout](#mergetree_setting-merge_with_ttl_timeout). Если её значение слишком низкое, придется выполнять много внеплановых мёржей, которые могут начать потреблять значительную долю ресурсов сервера.
|
||||
|
||||
Если вы выполните запрос `SELECT` между слияниями вы можете получить устаревшие данные. Чтобы избежать этого используйте запрос [OPTIMIZE](../../query_language/misc.md#misc_operations-optimize) перед `SELECT`.
|
||||
Если вы выполните запрос `SELECT` между слияниями вы можете получить устаревшие данные. Чтобы избежать этого используйте запрос [OPTIMIZE](../../../engines/table_engines/mergetree_family/mergetree.md#misc_operations-optimize) перед `SELECT`.
|
||||
|
||||
## Хранение данных таблицы на нескольких блочных устройствах {#table_engine-mergetree-multiple-volumes}
|
||||
|
||||
@ -473,16 +473,16 @@ ALTER TABLE example_table
|
||||
|
||||
Движки таблиц семейства `MergeTree` могут хранить данные на нескольких блочных устройствах. Это может оказаться полезным, например, при неявном разделении данных одной таблицы на «горячие» и «холодные». Наиболее свежая часть занимает малый объём и запрашивается регулярно, а большой хвост исторических данных запрашивается редко. При наличии в системе нескольких дисков, «горячая» часть данных может быть размещена на быстрых дисках (например, на NVMe SSD или в памяти), а холодная на более медленных (например, HDD).
|
||||
|
||||
Минимальной перемещаемой единицей для `MergeTree` является кусок данных (data part). Данные одного куска могут находится только на одном диске. Куски могут перемещаться между дисками в фоне, согласно пользовательским настройкам, а также с помощью запросов [ALTER](../../query_language/alter.md#alter_move-partition).
|
||||
Минимальной перемещаемой единицей для `MergeTree` является кусок данных (data part). Данные одного куска могут находится только на одном диске. Куски могут перемещаться между дисками в фоне, согласно пользовательским настройкам, а также с помощью запросов [ALTER](../../../engines/table_engines/mergetree_family/mergetree.md#alter_move-partition).
|
||||
|
||||
### Термины {#terminy}
|
||||
|
||||
- Диск — примонтированное в файловой системе блочное устройство.
|
||||
- Диск по умолчанию — диск, на котором находится путь, указанный в конфигурационной настройке сервера [path](../server_settings/settings.md#server_settings-path).
|
||||
- Диск по умолчанию — диск, на котором находится путь, указанный в конфигурационной настройке сервера [path](../../../operations/server_configuration_parameters/settings.md#server_configuration_parameters-path).
|
||||
- Том (Volume) — упорядоченный набор равноценных дисков (схоже с [JBOD](https://ru.wikipedia.org/wiki/JBOD))
|
||||
- Политика хранения (StoragePolicy) — множество томов с правилами перемещения данных между ними.
|
||||
|
||||
У всех описанных сущностей при создании указываются имена, можно найти в системных таблицах [system.storage\_policies](../system_tables.md#system_tables-storage_policies) и [system.disks](../system_tables.md#system_tables-disks). Имя политики хранения можно указать в настройке `storage_policy` движков таблиц семейства `MergeTree`.
|
||||
У всех описанных сущностей при создании указываются имена, можно найти в системных таблицах [system.storage\_policies](../../../engines/table_engines/mergetree_family/mergetree.md#system_tables-storage_policies) и [system.disks](../../../engines/table_engines/mergetree_family/mergetree.md#system_tables-disks). Имя политики хранения можно указать в настройке `storage_policy` движков таблиц семейства `MergeTree`.
|
||||
|
||||
### Конфигурация {#table_engine-mergetree-multiple-volumes-configure}
|
||||
|
||||
@ -616,9 +616,9 @@ SETTINGS storage_policy = 'moving_from_ssd_to_hdd'
|
||||
В таблицах `MergeTree` данные попадают на диск несколькими способами:
|
||||
|
||||
- В результате вставки (запрос `INSERT`).
|
||||
- В фоновых операциях слияний и [мутаций](../../query_language/alter.md#alter-mutations).
|
||||
- В фоновых операциях слияний и [мутаций](../../../engines/table_engines/mergetree_family/mergetree.md#alter-mutations).
|
||||
- При скачивании данных с другой реплики.
|
||||
- В результате заморозки партиций [ALTER TABLE … FREEZE PARTITION](../../query_language/alter.md#alter_freeze-partition).
|
||||
- В результате заморозки партиций [ALTER TABLE … FREEZE PARTITION](../../../engines/table_engines/mergetree_family/mergetree.md#alter_freeze-partition).
|
||||
|
||||
Во всех случаях, кроме мутаций и заморозки партиций, при записи куска выбирается том и диск в соответствии с указанной конфигурацией хранилища:
|
||||
|
||||
@ -627,9 +627,8 @@ SETTINGS storage_policy = 'moving_from_ssd_to_hdd'
|
||||
|
||||
Мутации и запросы заморозки партиций в реализации используют [жесткие ссылки](https://ru.wikipedia.org/wiki/%D0%96%D1%91%D1%81%D1%82%D0%BA%D0%B0%D1%8F_%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B0). Жесткие ссылки между различными дисками не поддерживаются, поэтому в случае таких операций куски размещаются на тех же дисках, что и исходные.
|
||||
|
||||
В фоне куски перемещаются между томами на основе информации о занятом месте (настройка `move_factor`) по порядку, в котором указаны тома в конфигурации. Данные никогда не перемещаются с последнего тома и на первый том. Следить за фоновыми перемещениями можно с помощью системных таблиц [system.part\_log](../system_tables.md#system_tables-part-log) (поле `type = MOVE_PART`) и [system.parts](../system_tables.md#system_tables-parts) (поля `path` и `disk`). Также подробная информация о перемещениях доступна в логах сервера.
|
||||
|
||||
С помощью запроса [ALTER TABLE … MOVE PART\|PARTITION … TO VOLUME\|DISK …](../../query_language/alter.md#alter_move-partition) пользователь может принудительно перенести кусок или партицию с одного раздела на другой. При этом учитываются все ограничения, указанные для фоновых операций. Запрос самостоятельно инициирует процесс перемещения не дожидаясь фоновых операций. В случае недостатка места или неудовлетворения ограничениям пользователь получит сообщение об ошибке.
|
||||
В фоне куски перемещаются между томами на основе информации о занятом месте (настройка `move_factor`) по порядку, в котором указаны тома в конфигурации. Данные никогда не перемещаются с последнего тома и на первый том. Следить за фоновыми перемещениями можно с помощью системных таблиц [system.part\_log](../../../engines/table_engines/mergetree_family/mergetree.md#system_tables-part-log) (поле `type = MOVE_PART`) и [system.parts](../../../engines/table_engines/mergetree_family/mergetree.md#system_tables-parts) (поля `path` и `disk`). Также подробная информация о перемещениях доступна в логах сервера.
|
||||
С помощью запроса [ALTER TABLE … MOVE PART\|PARTITION … TO VOLUME\|DISK …](../../../engines/table_engines/mergetree_family/mergetree.md#alter_move-partition) пользователь может принудительно перенести кусок или партицию с одного раздела на другой. При этом учитываются все ограничения, указанные для фоновых операций. Запрос самостоятельно инициирует процесс перемещения не дожидаясь фоновых операций. В случае недостатка места или неудовлетворения ограничениям пользователь получит сообщение об ошибке.
|
||||
|
||||
Перемещения данных не взаимодействуют с репликацией данных, поэтому на разных репликах одной и той же таблицы могут быть указаны разные политики хранения.
|
||||
|
||||
@ -21,7 +21,7 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
[SETTINGS name=value, ...]
|
||||
```
|
||||
|
||||
Описание параметров запроса смотрите в [описании запроса](../../query_language/create.md).
|
||||
Описание параметров запроса смотрите в [описании запроса](../../../engines/table_engines/mergetree_family/replacingmergetree.md).
|
||||
|
||||
**Параметры ReplacingMergeTree**
|
||||
|
||||
@ -14,7 +14,7 @@
|
||||
|
||||
Репликация не зависит от шардирования. На каждом шарде репликация работает независимо.
|
||||
|
||||
Реплицируются сжатые данные запросов `INSERT`, `ALTER` (см. подробности в описании запроса [ALTER](../../query_language/alter.md#query_language_queries_alter)).
|
||||
Реплицируются сжатые данные запросов `INSERT`, `ALTER` (см. подробности в описании запроса [ALTER](../../../engines/table_engines/mergetree_family/replication.md#query_language_queries_alter)).
|
||||
|
||||
Запросы `CREATE`, `DROP`, `ATTACH`, `DETACH` и `RENAME` выполняются на одном сервере и не реплицируются:
|
||||
|
||||
@ -24,7 +24,7 @@
|
||||
|
||||
ClickHouse хранит метаинформацию о репликах в [Apache ZooKeeper](https://zookeeper.apache.org). Используйте ZooKeeper 3.4.5 или новее.
|
||||
|
||||
Для использовании репликации, установите параметры в секции [zookeeper](../server_settings/settings.md#server-settings_zookeeper) конфигурации сервера.
|
||||
Для использовании репликации, установите параметры в секции [zookeeper](../../../operations/server_configuration_parameters/settings.md#server-settings_zookeeper) конфигурации сервера.
|
||||
|
||||
!!! attention "Внимание"
|
||||
Не пренебрегайте настройками безопасности. ClickHouse поддерживает [ACL схему](https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#sc_ZooKeeperAccessControl) `digest` подсистемы безопасности ZooKeeper.
|
||||
@ -52,7 +52,7 @@ ClickHouse хранит метаинформацию о репликах в [Apa
|
||||
|
||||
Если в конфигурационном файле не настроен ZooKeeper, то вы не сможете создать реплицируемые таблицы, а уже имеющиеся реплицируемые таблицы будут доступны в режиме только на чтение.
|
||||
|
||||
При запросах `SELECT`, ZooKeeper не используется, т.е. репликация не влияет на производительность `SELECT` и запросы работают так же быстро, как и для нереплицируемых таблиц. При запросах к распределенным реплицированным таблицам поведение ClickHouse регулируется настройками [max\_replica\_delay\_for\_distributed\_queries](../settings/settings.md#settings-max_replica_delay_for_distributed_queries) and [fallback\_to\_stale\_replicas\_for\_distributed\_queries](../settings/settings.md).
|
||||
При запросах `SELECT`, ZooKeeper не используется, т.е. репликация не влияет на производительность `SELECT` и запросы работают так же быстро, как и для нереплицируемых таблиц. При запросах к распределенным реплицированным таблицам поведение ClickHouse регулируется настройками [max\_replica\_delay\_for\_distributed\_queries](../../../operations/settings/settings.md#settings-max_replica_delay_for_distributed_queries) and [fallback\_to\_stale\_replicas\_for\_distributed\_queries](../../../operations/settings/settings.md).
|
||||
|
||||
При каждом запросе `INSERT`, делается около десятка записей в ZooKeeper в рамках нескольких транзакций. (Чтобы быть более точным, это для каждого вставленного блока данных; запрос INSERT содержит один блок или один блок на `max_insert_block_size = 1048576` строк.) Это приводит к некоторому увеличению задержек при `INSERT`, по сравнению с нереплицируемыми таблицами. Но если придерживаться обычных рекомендаций - вставлять данные пачками не более одного `INSERT` в секунду, то это не составляет проблем. На всём кластере ClickHouse, использующим для координации один кластер ZooKeeper, может быть в совокупности несколько сотен `INSERT` в секунду. Пропускная способность при вставке данных (количество строчек в секунду) такая же высокая, как для нереплицируемых таблиц.
|
||||
|
||||
@ -64,7 +64,7 @@ ClickHouse хранит метаинформацию о репликах в [Apa
|
||||
|
||||
Каждый блок данных записывается атомарно. Запрос INSERT разбивается на блоки данных размером до `max_insert_block_size = 1048576` строк. То есть, если в запросе `INSERT` менее 1048576 строк, то он делается атомарно.
|
||||
|
||||
Блоки данных дедуплицируются. При многократной записи одного и того же блока данных (блоков данных одинакового размера, содержащих одни и те же строчки в одном и том же порядке), блок будет записан только один раз. Это сделано для того, чтобы в случае сбоя в сети, когда клиентское приложение не может понять, были ли данные записаны в БД, можно было просто повторить запрос `INSERT`. При этом не имеет значения, на какую реплику будут отправлены INSERT-ы с одинаковыми данными. Запрос `INSERT` идемпотентный. Параметры дедуплицирования регулируются настройками сервера [merge\_tree](../server_settings/settings.md#server_settings-merge_tree)
|
||||
Блоки данных дедуплицируются. При многократной записи одного и того же блока данных (блоков данных одинакового размера, содержащих одни и те же строчки в одном и том же порядке), блок будет записан только один раз. Это сделано для того, чтобы в случае сбоя в сети, когда клиентское приложение не может понять, были ли данные записаны в БД, можно было просто повторить запрос `INSERT`. При этом не имеет значения, на какую реплику будут отправлены INSERT-ы с одинаковыми данными. Запрос `INSERT` идемпотентный. Параметры дедуплицирования регулируются настройками сервера [merge\_tree](../../../operations/server_configuration_parameters/settings.md#server_configuration_parameters-merge_tree)
|
||||
|
||||
При репликации, по сети передаются только исходные вставляемые данные. Дальнейшие преобразования данных (слияния) координируются и делаются на всех репликах одинаковым образом. За счёт этого минимизируется использование сети, и благодаря этому, репликация хорошо работает при расположении реплик в разных дата-центрах. (Стоит заметить, что дублирование данных в разных дата-центрах, по сути, является основной задачей репликации).
|
||||
|
||||
@ -19,7 +19,7 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
[SETTINGS name=value, ...]
|
||||
```
|
||||
|
||||
Описание параметров запроса смотрите в [описании запроса](../../query_language/create.md).
|
||||
Описание параметров запроса смотрите в [описании запроса](../../../engines/table_engines/mergetree_family/summingmergetree.md).
|
||||
|
||||
**Параметры SummingMergeTree**
|
||||
|
||||
@ -91,7 +91,7 @@ SELECT key, sum(value) FROM summtt GROUP BY key
|
||||
|
||||
При вставке данных в таблицу они сохраняются как есть. Периодически ClickHouse выполняет слияние вставленных кусков данных и именно в этот момент производится суммирование и замена многих строк с одинаковым первичным ключом на одну для каждого результирующего куска данных.
|
||||
|
||||
ClickHouse может слить куски данных таким образом, что не все строки с одинаковым первичным ключом окажутся в одном финальном куске, т.е. суммирование будет не полным. Поэтому, при выборке данных (`SELECT`) необходимо использовать агрегатную функцию [sum()](../../query_language/agg_functions/reference.md#agg_function-sum) и секцию `GROUP BY` как описано в примере выше.
|
||||
ClickHouse может слить куски данных таким образом, что не все строки с одинаковым первичным ключом окажутся в одном финальном куске, т.е. суммирование будет не полным. Поэтому, при выборке данных (`SELECT`) необходимо использовать агрегатную функцию [sum()](../../../engines/table_engines/mergetree_family/summingmergetree.md#agg_function-sum) и секцию `GROUP BY` как описано в примере выше.
|
||||
|
||||
### Общие правила суммирования {#obshchie-pravila-summirovaniia}
|
||||
|
||||
@ -105,7 +105,7 @@ ClickHouse может слить куски данных таким образо
|
||||
|
||||
### Суммирование в столбцах AggregateFunction {#summirovanie-v-stolbtsakh-aggregatefunction}
|
||||
|
||||
Для столбцов типа [AggregateFunction](../../data_types/nested_data_structures/aggregatefunction.md#data_type-aggregatefunction) ClickHouse выполняет агрегацию согласно заданной функции, повторяя поведение движка [AggregatingMergeTree](aggregatingmergetree.md).
|
||||
Для столбцов типа [AggregateFunction](../../../engines/table_engines/mergetree_family/summingmergetree.md#data_type-aggregatefunction) ClickHouse выполняет агрегацию согласно заданной функции, повторяя поведение движка [AggregatingMergeTree](aggregatingmergetree.md).
|
||||
|
||||
### Вложенные структуры {#vlozhennye-struktury}
|
||||
|
||||
@ -127,7 +127,7 @@ ClickHouse может слить куски данных таким образо
|
||||
[(1, 100), (2, 150)] + [(1, -100)] -> [(2, 150)]
|
||||
```
|
||||
|
||||
При запросе данных используйте функцию [sumMap(key, value)](../../query_language/agg_functions/reference.md) для агрегации `Map`.
|
||||
При запросе данных используйте функцию [sumMap(key, value)](../../../engines/table_engines/mergetree_family/summingmergetree.md) для агрегации `Map`.
|
||||
|
||||
Для вложенной структуры данных не нужно указывать её столбцы в кортеже столбцов для суммирования.
|
||||
|
||||
@ -24,7 +24,7 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
[SETTINGS name=value, ...]
|
||||
```
|
||||
|
||||
Подробности про `CREATE TABLE` смотрите в [описании запроса](../../query_language/create.md).
|
||||
Подробности про `CREATE TABLE` смотрите в [описании запроса](../../../engines/table_engines/mergetree_family/versionedcollapsingmergetree.md).
|
||||
|
||||
**Параметры движка**
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Dictionary {#dictionary}
|
||||
|
||||
Движок `Dictionary` отображает данные [словаря](../../query_language/dicts/external_dicts.md) как таблицу ClickHouse.
|
||||
Движок `Dictionary` отображает данные [словаря](../../../engines/table_engines/special/dictionary.md) как таблицу ClickHouse.
|
||||
|
||||
Рассмотрим для примера словарь `products` со следующей конфигурацией:
|
||||
|
||||
@ -57,7 +57,7 @@ WHERE name = 'products'
|
||||
└──────────┴──────┴────────┴─────────────────┴─────────────────┴─────────────────┴───────────────┴─────────────────┘
|
||||
```
|
||||
|
||||
В таком виде данные из словаря можно получить при помощи функций [dictGet\*](../../query_language/functions/ext_dict_functions.md#ext_dict_functions).
|
||||
В таком виде данные из словаря можно получить при помощи функций [dictGet\*](../../../engines/table_engines/special/dictionary.md#ext_dict_functions).
|
||||
|
||||
Такое представление неудобно, когда нам необходимо получить данные в чистом виде, а также при выполнении операции `JOIN`. Для этих случаев можно использовать движок `Dictionary`, который отобразит данные словаря в таблицу.
|
||||
|
||||
@ -61,12 +61,12 @@ logs - имя кластера в конфигурационном файле с
|
||||
В качестве параметров для каждого сервера указываются `host`, `port` и, не обязательно, `user`, `password`, `secure`, `compression`:
|
||||
- `host` - адрес удалённого сервера. Может быть указан домен, или IPv4 или IPv6 адрес. В случае указания домена, при старте сервера делается DNS запрос, и результат запоминается на всё время работы сервера. Если DNS запрос неуспешен, то сервер не запускается. Если вы изменяете DNS-запись, перезапустите сервер.
|
||||
- `port` - TCP-порт для межсерверного взаимодействия (в конфиге - tcp\_port, обычно 9000). Не перепутайте с http\_port.
|
||||
- `user` - имя пользователя для соединения с удалённым сервером. по умолчанию - default. Этот пользователь должен иметь доступ для соединения с указанным сервером. Доступы настраиваются в файле users.xml, подробнее смотрите в разделе [Права доступа](../../operations/access_rights.md).
|
||||
- `user` - имя пользователя для соединения с удалённым сервером. по умолчанию - default. Этот пользователь должен иметь доступ для соединения с указанным сервером. Доступы настраиваются в файле users.xml, подробнее смотрите в разделе [Права доступа](../../../operations/access_rights.md).
|
||||
- `password` - пароль для соединения с удалённым сервером, в открытом виде. по умолчанию - пустая строка.
|
||||
- `secure` - Использовать шифрованное соединение ssl, Обычно используется с портом `port` = 9440. Сервер должен слушать порт <tcp_port_secure>9440</tcp_port_secure> с корректными настройками сертификатов.
|
||||
- `compression` - Использовать сжатие данных. По умолчанию: true.
|
||||
|
||||
При указании реплик, для каждого из шардов, при чтении, будет выбрана одна из доступных реплик. Можно настроить алгоритм балансировки нагрузки (то есть, предпочтения, на какую из реплик идти) - см. настройку [load\_balancing](../settings/settings.md#settings-load_balancing).
|
||||
При указании реплик, для каждого из шардов, при чтении, будет выбрана одна из доступных реплик. Можно настроить алгоритм балансировки нагрузки (то есть, предпочтения, на какую из реплик идти) - см. настройку [load\_balancing](../../../operations/settings/settings.md#settings-load_balancing).
|
||||
Если соединение с сервером не установлено, то будет произведена попытка соединения с небольшим таймаутом. Если соединиться не удалось, то будет выбрана следующая реплика, и так для всех реплик. Если попытка соединения для всех реплик не удалась, то будут снова произведены попытки соединения по кругу, и так несколько раз.
|
||||
Это работает в пользу отказоустойчивости, хотя и не обеспечивает полную отказоустойчивость: удалённый сервер может принять соединение, но не работать, или плохо работать.
|
||||
|
||||
@ -78,7 +78,7 @@ logs - имя кластера в конфигурационном файле с
|
||||
|
||||
Движок Distributed позволяет работать с кластером, как с локальным сервером. При этом, кластер является неэластичным: вы должны прописать его конфигурацию в конфигурационный файл сервера (лучше всех серверов кластера).
|
||||
|
||||
Как видно, движок Distributed требует прописывания кластера в конфигурационный файл; кластера из конфигурационного файла обновляются налету, без перезапуска сервера. Если вам необходимо каждый раз отправлять запрос на неизвестный набор шардов и реплик, вы можете не создавать Distributed таблицу, а воспользоваться табличной функцией remote. Смотрите раздел [Табличные функции](../../query_language/table_functions/index.md).
|
||||
Как видно, движок Distributed требует прописывания кластера в конфигурационный файл; кластера из конфигурационного файла обновляются налету, без перезапуска сервера. Если вам необходимо каждый раз отправлять запрос на неизвестный набор шардов и реплик, вы можете не создавать Distributed таблицу, а воспользоваться табличной функцией remote. Смотрите раздел [Табличные функции](../../../engines/table_engines/special/distributed.md).
|
||||
|
||||
Есть два способа записывать данные на кластер:
|
||||
|
||||
@ -107,10 +107,10 @@ logs - имя кластера в конфигурационном файле с
|
||||
- используются запросы, требующие соединение данных (IN, JOIN) по определённому ключу - тогда если данные шардированы по этому ключу, то можно использовать локальные IN, JOIN вместо GLOBAL IN, GLOBAL JOIN, что кардинально более эффективно.
|
||||
- используется большое количество серверов (сотни и больше) и большое количество маленьких запросов (запросы отдельных клиентов - сайтов, рекламодателей, партнёров) - тогда, для того, чтобы маленькие запросы не затрагивали весь кластер, имеет смысл располагать данные одного клиента на одном шарде, или (вариант, который используется в Яндекс.Метрике) сделать двухуровневое шардирование: разбить весь кластер на «слои», где слой может состоять из нескольких шардов; данные для одного клиента располагаются на одном слое, но в один слой можно по мере необходимости добавлять шарды, в рамках которых данные распределены произвольным образом; создаются распределённые таблицы на каждый слой и одна общая распределённая таблица для глобальных запросов.
|
||||
|
||||
Запись данных осуществляется полностью асинхронно. При вставке в таблицу, блок данных сначала записывается в файловую систему. Затем, в фоновом режиме отправляются на удалённые серверы при первой возможности. Период отправки регулируется настройками [distributed\_directory\_monitor\_sleep\_time\_ms](../settings/settings.md#distributed_directory_monitor_sleep_time_ms) и [distributed\_directory\_monitor\_max\_sleep\_time\_ms](../settings/settings.md#distributed_directory_monitor_max_sleep_time_ms). Движок таблиц `Distributed` отправляет каждый файл со вставленными данными отдельно, но можно включить пакетную отправку данных настройкой [distributed\_directory\_monitor\_batch\_inserts](../settings/settings.md#distributed_directory_monitor_batch_inserts). Эта настройка улучшает производительность кластера за счет более оптимального использования ресурсов сервера-отправителя и сети. Необходимо проверять, что данные отправлены успешно, для этого проверьте список файлов (данных, ожидающих отправки) в каталоге таблицы `/var/lib/clickhouse/data/database/table/`.
|
||||
Запись данных осуществляется полностью асинхронно. При вставке в таблицу, блок данных сначала записывается в файловую систему. Затем, в фоновом режиме отправляются на удалённые серверы при первой возможности. Период отправки регулируется настройками [distributed\_directory\_monitor\_sleep\_time\_ms](../../../operations/settings/settings.md#distributed_directory_monitor_sleep_time_ms) и [distributed\_directory\_monitor\_max\_sleep\_time\_ms](../../../operations/settings/settings.md#distributed_directory_monitor_max_sleep_time_ms). Движок таблиц `Distributed` отправляет каждый файл со вставленными данными отдельно, но можно включить пакетную отправку данных настройкой [distributed\_directory\_monitor\_batch\_inserts](../../../operations/settings/settings.md#distributed_directory_monitor_batch_inserts). Эта настройка улучшает производительность кластера за счет более оптимального использования ресурсов сервера-отправителя и сети. Необходимо проверять, что данные отправлены успешно, для этого проверьте список файлов (данных, ожидающих отправки) в каталоге таблицы `/var/lib/clickhouse/data/database/table/`.
|
||||
|
||||
Если после INSERT-а в Distributed таблицу, сервер перестал существовать или был грубо перезапущен (например, в следствие аппаратного сбоя), то записанные данные могут быть потеряны. Если в директории таблицы обнаружен повреждённый кусок данных, то он переносится в поддиректорию broken и больше не используется.
|
||||
|
||||
При выставлении опции max\_parallel\_replicas выполнение запроса распараллеливается по всем репликам внутри одного шарда. Подробнее смотрите раздел [max\_parallel\_replicas](../settings/settings.md#settings-max_parallel_replicas).
|
||||
При выставлении опции max\_parallel\_replicas выполнение запроса распараллеливается по всем репликам внутри одного шарда. Подробнее смотрите раздел [max\_parallel\_replicas](../../../operations/settings/settings.md#settings-max_parallel_replicas).
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/table_engines/distributed/) <!--hide-->
|
||||
@ -14,13 +14,13 @@
|
||||
File(Format)
|
||||
```
|
||||
|
||||
`Format` должен быть таким, который ClickHouse может использовать и в запросах `INSERT` и в запросах `SELECT`. Полный список поддерживаемых форматов смотрите в разделе [Форматы](../../interfaces/formats.md#formats).
|
||||
`Format` должен быть таким, который ClickHouse может использовать и в запросах `INSERT` и в запросах `SELECT`. Полный список поддерживаемых форматов смотрите в разделе [Форматы](../../../interfaces/formats.md#formats).
|
||||
|
||||
Сервер ClickHouse не позволяет указать путь к файлу, с которым будет работать `File`. Используется путь к хранилищу, определенный параметром [path](../server_settings/settings.md) в конфигурации сервера.
|
||||
Сервер ClickHouse не позволяет указать путь к файлу, с которым будет работать `File`. Используется путь к хранилищу, определенный параметром [path](../../../operations/server_configuration_parameters/settings.md) в конфигурации сервера.
|
||||
|
||||
При создании таблицы с помощью `File(Format)` сервер ClickHouse создает в хранилище каталог с именем таблицы, а после добавления в таблицу данных помещает туда файл `data.Format`.
|
||||
|
||||
Можно вручную создать в хранилище каталог таблицы, поместить туда файл, затем на сервере ClickHouse добавить ([ATTACH](../../query_language/misc.md)) информацию о таблице, соответствующей имени каталога и прочитать из файла данные.
|
||||
Можно вручную создать в хранилище каталог таблицы, поместить туда файл, затем на сервере ClickHouse добавить ([ATTACH](../../../engines/table_engines/special/file.md)) информацию о таблице, соответствующей имени каталога и прочитать из файла данные.
|
||||
|
||||
!!! warning "Warning"
|
||||
Будьте аккуратны с этой функциональностью, поскольку сервер ClickHouse не отслеживает внешние изменения данных. Если в файл будет производиться запись одновременно со стороны сервера ClickHouse и с внешней стороны, то результат непредсказуем.
|
||||
@ -58,7 +58,7 @@ SELECT * FROM file_engine_table
|
||||
|
||||
## Использование движка в clickhouse-local {#ispolzovanie-dvizhka-v-clickhouse-local}
|
||||
|
||||
В [clickhouse-local](../utils/clickhouse-local.md) движок в качестве параметра принимает не только формат, но и путь к файлу. В том числе можно указать стандартные потоки ввода/вывода цифровым или буквенным обозначением `0` или `stdin`, `1` или `stdout`.
|
||||
В [clickhouse-local](../../../engines/table_engines/special/file.md) движок в качестве параметра принимает не только формат, но и путь к файлу. В том числе можно указать стандартные потоки ввода/вывода цифровым или буквенным обозначением `0` или `stdin`, `1` или `stdout`.
|
||||
|
||||
**Пример:**
|
||||
|
||||
59
docs/ru/engines/table_engines/special/generate.md
Normal file
59
docs/ru/engines/table_engines/special/generate.md
Normal file
@ -0,0 +1,59 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 1cd5f0028d917696daf71ac1c9ee849c99c1d5c8
|
||||
---
|
||||
|
||||
# GenerateRandom {#table_engines-generate}
|
||||
|
||||
Механизм генерации случайных таблиц генерирует случайные данные для данной схемы таблиц.
|
||||
|
||||
Примеры употребления:
|
||||
|
||||
- Используйте в тесте для заполнения воспроизводимого большого стола.
|
||||
- Генерируйте случайные входные данные для тестов размытия.
|
||||
|
||||
## Использование в сервере ClickHouse {#usage-in-clickhouse-server}
|
||||
|
||||
``` sql
|
||||
ENGINE = GenerateRandom(random_seed, max_string_length, max_array_length)
|
||||
```
|
||||
|
||||
То `max_array_length` и `max_string_length` параметры укажите максимальную длину всех
|
||||
столбцы массива и строки соответственно в генерируемых данных.
|
||||
|
||||
Генерация таблицы движок поддерживает только `SELECT` запросы.
|
||||
|
||||
Он поддерживает все [Тип данных](../../../engines/table_engines/special/generate.md) это может быть сохранено в таблице за исключением `LowCardinality` и `AggregateFunction`.
|
||||
|
||||
**Пример:**
|
||||
|
||||
**1.** Настройка системы `generate_engine_table` стол:
|
||||
|
||||
``` sql
|
||||
CREATE TABLE generate_engine_table (name String, value UInt32) ENGINE = GenerateRandom(1, 5, 3)
|
||||
```
|
||||
|
||||
**2.** Запрос данных:
|
||||
|
||||
``` sql
|
||||
SELECT * FROM generate_engine_table LIMIT 3
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─name─┬──────value─┐
|
||||
│ c4xJ │ 1412771199 │
|
||||
│ r │ 1791099446 │
|
||||
│ 7#$ │ 124312908 │
|
||||
└──────┴────────────┘
|
||||
```
|
||||
|
||||
## Детали внедрения {#details-of-implementation}
|
||||
|
||||
- Не поддерживаемый:
|
||||
- `ALTER`
|
||||
- `SELECT ... SAMPLE`
|
||||
- `INSERT`
|
||||
- Индексы
|
||||
- Копирование
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/en/operations/table_engines/generate/) <!--hide-->
|
||||
5
docs/ru/engines/table_engines/special/index.md
Normal file
5
docs/ru/engines/table_engines/special/index.md
Normal file
@ -0,0 +1,5 @@
|
||||
---
|
||||
toc_folder_title: Special
|
||||
toc_priority: 31
|
||||
---
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Join {#join}
|
||||
|
||||
Подготовленная структура данных для использования в операциях [JOIN](../../query_language/select.md#select-join).
|
||||
Подготовленная структура данных для использования в операциях [JOIN](../../../engines/table_engines/special/join.md#select-join).
|
||||
|
||||
## Создание таблицы {#creating-a-table}
|
||||
|
||||
@ -12,12 +12,12 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
) ENGINE = Join(join_strictness, join_type, k1[, k2, ...])
|
||||
```
|
||||
|
||||
Смотрите подробное описание запроса [CREATE TABLE](../../query_language/create.md#create-table-query).
|
||||
Смотрите подробное описание запроса [CREATE TABLE](../../../engines/table_engines/special/join.md#create-table-query).
|
||||
|
||||
**Параметры движка**
|
||||
|
||||
- `join_strictness` – [строгость JOIN](../../query_language/select.md#select-join-strictness).
|
||||
- `join_type` – [тип JOIN](../../query_language/select.md#select-join-types).
|
||||
- `join_strictness` – [строгость JOIN](../../../engines/table_engines/special/join.md#select-join-strictness).
|
||||
- `join_type` – [тип JOIN](../../../engines/table_engines/special/join.md#select-join-types).
|
||||
- `k1[, k2, ...]` – ключевые столбцы секции `USING` с которыми выполняется операция `JOIN`.
|
||||
|
||||
Вводите параметры `join_strictness` и `join_type` без кавычек, например, `Join(ANY, LEFT, col1)`. Они должны быть такими же как и в той операции `JOIN`, в которой таблица будет использоваться. Если параметры не совпадают, ClickHouse не генерирует исключение и может возвращать неверные данные.
|
||||
@ -79,21 +79,21 @@ SELECT joinGet('id_val_join', 'val', toUInt32(1))
|
||||
Из таблиц нельзя выбрать данные с помощью запроса `SELECT`. Вместо этого, используйте один из следующих методов:
|
||||
|
||||
- Используйте таблицу как правую в секции `JOIN`.
|
||||
- Используйте функцию [joinGet](../../query_language/functions/other_functions.md#joinget), которая позволяет извлекать данные из таблицы таким же образом как из словаря.
|
||||
- Используйте функцию [joinGet](../../../engines/table_engines/special/join.md#joinget), которая позволяет извлекать данные из таблицы таким же образом как из словаря.
|
||||
|
||||
### Ограничения и настройки {#join-limitations-and-settings}
|
||||
|
||||
При создании таблицы, применяются следующие параметры :
|
||||
|
||||
- [join\_use\_nulls](../settings/settings.md#join_use_nulls)
|
||||
- [max\_rows\_in\_join](../settings/query_complexity.md#settings-max_rows_in_join)
|
||||
- [max\_bytes\_in\_join](../settings/query_complexity.md#settings-max_bytes_in_join)
|
||||
- [join\_overflow\_mode](../settings/query_complexity.md#settings-join_overflow_mode)
|
||||
- [join\_any\_take\_last\_row](../settings/settings.md#settings-join_any_take_last_row)
|
||||
- [join\_use\_nulls](../../../operations/settings/settings.md#join_use_nulls)
|
||||
- [max\_rows\_in\_join](../../../operations/settings/query_complexity.md#settings-max_rows_in_join)
|
||||
- [max\_bytes\_in\_join](../../../operations/settings/query_complexity.md#settings-max_bytes_in_join)
|
||||
- [join\_overflow\_mode](../../../operations/settings/query_complexity.md#settings-join_overflow_mode)
|
||||
- [join\_any\_take\_last\_row](../../../operations/settings/settings.md#settings-join_any_take_last_row)
|
||||
|
||||
Таблицы с движком `Join` нельзя использовать в операциях `GLOBAL JOIN`.
|
||||
|
||||
Движок `Join` позволяет использовать параметр [join\_use\_nulls](../settings/settings.md#join_use_nulls) в запросе `CREATE TABLE`, который также можно использовать в запросе [SELECT](../../query_language/select.md). Если у вас разные настройки `join_use_nulls`, вы можете получить сообщение об ошибке при объединении таблиц. Это зависит от типа соединения. Когда вы используете функцию [joinGet](../../query_language/functions/other_functions.md#joinget), вам необходимо использовать один и тот же параметр `join_use_nulls` в запросах `CRATE TABLE` и `SELECT`.
|
||||
Движок `Join` позволяет использовать параметр [join\_use\_nulls](../../../operations/settings/settings.md#join_use_nulls) в запросе `CREATE TABLE`, который также можно использовать в запросе [SELECT](../../../engines/table_engines/special/join.md). Если у вас разные настройки `join_use_nulls`, вы можете получить сообщение об ошибке при объединении таблиц. Это зависит от типа соединения. Когда вы используете функцию [joinGet](../../../engines/table_engines/special/join.md#joinget), вам необходимо использовать один и тот же параметр `join_use_nulls` в запросах `CRATE TABLE` и `SELECT`.
|
||||
|
||||
## Хранение данных {#khranenie-dannykh}
|
||||
|
||||
@ -0,0 +1,5 @@
|
||||
# MaterializedView {#materializedview}
|
||||
|
||||
Используется для реализации материализованных представлений (подробнее см. запрос [CREATE TABLE](../../../engines/table_engines/special/materializedview.md)). Для хранения данных, использует другой движок, который был указан при создании представления. При чтении из таблицы, просто использует этот движок.
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/table_engines/materializedview/) <!--hide-->
|
||||
@ -52,7 +52,7 @@ FROM WatchLog
|
||||
|
||||
## Виртуальные столбцы {#virtualnye-stolbtsy}
|
||||
|
||||
- `_table` — содержит имя таблицы, из которой данные были прочитаны. Тип — [String](../../data_types/string.md).
|
||||
- `_table` — содержит имя таблицы, из которой данные были прочитаны. Тип — [String](../../../engines/table_engines/special/merge.md).
|
||||
|
||||
В секции `WHERE/PREWHERE` можно установить константное условие на столбец `_table` (например, `WHERE _table='xyz'`). В этом случае операции чтения выполняются только для тех таблиц, для которых выполняется условие на значение `_table`, таким образом, столбец `_table` работает как индекс.
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
|
||||
`Format` должен быть таким, который ClickHouse может использовать в запросах
|
||||
`SELECT` и, если есть необходимость, `INSERT`. Полный список поддерживаемых форматов смотрите в
|
||||
разделе [Форматы](../../interfaces/formats.md#formats).
|
||||
разделе [Форматы](../../../interfaces/formats.md#formats).
|
||||
|
||||
`URL` должен соответствовать структуре Uniform Resource Locator. По указанному URL должен находится сервер
|
||||
работающий по протоколу HTTP или HTTPS. При этом не должно требоваться никаких
|
||||
@ -17,7 +17,7 @@
|
||||
соответственно. Для обработки `POST`-запросов удаленный сервер должен поддерживать
|
||||
[Chunked transfer encoding](https://ru.wikipedia.org/wiki/Chunked_transfer_encoding).
|
||||
|
||||
Максимальное количество переходов по редиректам при выполнении HTTP-запроса методом GET можно ограничить с помощью настройки [max\_http\_get\_redirects](../settings/settings.md#setting-max_http_get_redirects).
|
||||
Максимальное количество переходов по редиректам при выполнении HTTP-запроса методом GET можно ограничить с помощью настройки [max\_http\_get\_redirects](../../../operations/settings/settings.md#setting-max_http_get_redirects).
|
||||
|
||||
**Пример:**
|
||||
|
||||
@ -25,7 +25,7 @@ NLS_LANG=RUSSIAN_RUSSIA.UTF8
|
||||
|
||||
### Секция INTO OUTFILE {#sektsiia-into-outfile}
|
||||
|
||||
Добавьте секцию [INTO OUTFILE](../query_language/select/#into-outfile-clause) к своему запросу.
|
||||
Добавьте секцию [INTO OUTFILE](../sql_reference/statements/select.md#into-outfile-clause) к своему запросу.
|
||||
|
||||
Например:
|
||||
|
||||
@ -33,7 +33,7 @@ NLS_LANG=RUSSIAN_RUSSIA.UTF8
|
||||
SELECT * FROM table INTO OUTFILE 'file'
|
||||
```
|
||||
|
||||
По умолчанию, для выдачи данных ClickHouse использует формат [TabSeparated](../interfaces/formats.md#tabseparated). Чтобы выбрать [формат данных](../interfaces/formats.md), используйте [секцию FORMAT](../query_language/select/#format-clause).
|
||||
По умолчанию, для выдачи данных ClickHouse использует формат [TabSeparated](../interfaces/formats.md#tabseparated). Чтобы выбрать [формат данных](../interfaces/formats.md), используйте [секцию FORMAT](../sql_reference/statements/select.md#format-clause).
|
||||
|
||||
Например:
|
||||
|
||||
@ -43,7 +43,7 @@ SELECT * FROM table INTO OUTFILE 'file' FORMAT CSV
|
||||
|
||||
### Таблица с движком File {#tablitsa-s-dvizhkom-file}
|
||||
|
||||
Смотрите [File](../operations/table_engines/file.md).
|
||||
Смотрите [File](../engines/table_engines/special/file.md).
|
||||
|
||||
### Перенаправление в командой строке {#perenapravlenie-v-komandoi-stroke}
|
||||
|
||||
|
||||
6
docs/ru/faq/index.md
Normal file
6
docs/ru/faq/index.md
Normal file
@ -0,0 +1,6 @@
|
||||
---
|
||||
toc_folder_title: F.A.Q.
|
||||
toc_priority: 76
|
||||
---
|
||||
|
||||
|
||||
@ -1,18 +1,19 @@
|
||||
---
|
||||
en_copy: true
|
||||
machine_translated: true
|
||||
machine_translated_rev: 1cd5f0028d917696daf71ac1c9ee849c99c1d5c8
|
||||
---
|
||||
|
||||
# ClickHouse Tutorial {#clickhouse-tutorial}
|
||||
# Учебник По Клик-Хаусу {#clickhouse-tutorial}
|
||||
|
||||
## What to Expect from This Tutorial? {#what-to-expect-from-this-tutorial}
|
||||
## Чего ожидать от этого урока? {#what-to-expect-from-this-tutorial}
|
||||
|
||||
By going through this tutorial, you’ll learn how to set up a simple ClickHouse cluster. It’ll be small, but fault-tolerant and scalable. Then we will use one of the example datasets to fill it with data and execute some demo queries.
|
||||
Пройдя через этот учебник,вы узнаете, как настроить простой кластер ClickHouse. Он будет небольшим, но отказоустойчивым и масштабируемым. Затем мы будем использовать один из примеров наборов данных, чтобы заполнить его данными и выполнить некоторые демонстрационные запросы.
|
||||
|
||||
## Single Node Setup {#single-node-setup}
|
||||
## Настройка Одного Узла {#single-node-setup}
|
||||
|
||||
To postpone the complexities of a distributed environment, we’ll start with deploying ClickHouse on a single server or virtual machine. ClickHouse is usually installed from [deb](index.md#install-from-deb-packages) or [rpm](index.md#from-rpm-packages) packages, but there are [alternatives](index.md#from-docker-image) for the operating systems that do no support them.
|
||||
Чтобы избежать сложностей распределенной среды, мы начнем с развертывания ClickHouse на одном сервере или виртуальной машине. ClickHouse обычно устанавливается из [дебютантка](install.md#install-from-deb-packages) или [оборотов в минуту](install.md#from-rpm-packages) пакеты, но есть и такие [альтернативы](install.md#from-docker-image) для операционных систем, которые их не поддерживают.
|
||||
|
||||
For example, you have chosen `deb` packages and executed:
|
||||
Например, вы выбрали `deb` пакеты и выполненные работы:
|
||||
|
||||
``` bash
|
||||
sudo apt-get install dirmngr
|
||||
@ -24,48 +25,48 @@ sudo apt-get update
|
||||
sudo apt-get install -y clickhouse-server clickhouse-client
|
||||
```
|
||||
|
||||
What do we have in the packages that got installed:
|
||||
Что у нас есть в пакетах, которые были установлены:
|
||||
|
||||
- `clickhouse-client` package contains [clickhouse-client](../interfaces/cli.md) application, interactive ClickHouse console client.
|
||||
- `clickhouse-common` package contains a ClickHouse executable file.
|
||||
- `clickhouse-server` package contains configuration files to run ClickHouse as a server.
|
||||
- `clickhouse-client` пакет содержит [clickhouse-клиент](../interfaces/cli.md) приложение, интерактивный консольный клиент ClickHouse.
|
||||
- `clickhouse-common` пакет содержит исполняемый файл ClickHouse.
|
||||
- `clickhouse-server` пакет содержит файлы конфигурации для запуска ClickHouse в качестве сервера.
|
||||
|
||||
Server config files are located in `/etc/clickhouse-server/`. Before going further, please notice the `<path>` element in `config.xml`. Path determines the location for data storage, so it should be located on volume with large disk capacity; the default value is `/var/lib/clickhouse/`. If you want to adjust the configuration, it’s not handy to directly edit `config.xml` file, considering it might get rewritten on future package updates. The recommended way to override the config elements is to create [files in config.d directory](../operations/configuration_files.md) which serve as “patches” to config.xml.
|
||||
Файлы конфигурации сервера находятся в `/etc/clickhouse-server/`. Прежде чем идти дальше, пожалуйста, обратите внимание на `<path>` элемент в `config.xml`. Путь определяет место для хранения данных, поэтому он должен быть расположен на Томе с большой емкостью диска; значение по умолчанию равно `/var/lib/clickhouse/`. Если вы хотите настроить конфигурацию, то это не удобно для непосредственного редактирования `config.xml` файл, учитывая, что он может быть переписан при будущих обновлениях пакета. Рекомендуемый способ переопределения элементов конфигурации заключается в создании [файлы в конфигурации.D каталог](../operations/configuration_files.md) которые служат в качестве «patches» к конфигурации.XML.
|
||||
|
||||
As you might have noticed, `clickhouse-server` is not launched automatically after package installation. It won’t be automatically restarted after updates, either. The way you start the server depends on your init system, usually, it is:
|
||||
Как вы могли заметить, `clickhouse-server` не запускается автоматически после установки пакета. Он также не будет автоматически перезапущен после обновления. То, как вы запускаете сервер, зависит от вашей системы init, как правило, это так:
|
||||
|
||||
``` bash
|
||||
sudo service clickhouse-server start
|
||||
```
|
||||
|
||||
or
|
||||
или
|
||||
|
||||
``` bash
|
||||
sudo /etc/init.d/clickhouse-server start
|
||||
```
|
||||
|
||||
The default location for server logs is `/var/log/clickhouse-server/`. The server is ready to handle client connections once it logs the `Ready for connections` message.
|
||||
По умолчанию для журналов сервера используется следующее расположение `/var/log/clickhouse-server/`. Сервер готов к обработке клиентских подключений, как только он регистрирует `Ready for connections` сообщение.
|
||||
|
||||
Once the `clickhouse-server` is up and running, we can use `clickhouse-client` to connect to the server and run some test queries like `SELECT "Hello, world!";`.
|
||||
Как только это произойдет `clickhouse-server` все готово и работает, мы можем использовать `clickhouse-client` чтобы подключиться к серверу и выполнить некоторые тестовые запросы, такие как `SELECT "Hello, world!";`.
|
||||
|
||||
<details markdown="1">
|
||||
|
||||
<summary>Quick tips for clickhouse-client</summary>
|
||||
Interactive mode:
|
||||
<summary>Быстрые советы для clickhouse-клиента</summary>
|
||||
Интерактивный режим:
|
||||
|
||||
``` bash
|
||||
clickhouse-client
|
||||
clickhouse-client --host=... --port=... --user=... --password=...
|
||||
```
|
||||
|
||||
Enable multiline queries:
|
||||
Включить многострочные запросы:
|
||||
|
||||
``` bash
|
||||
clickhouse-client -m
|
||||
clickhouse-client --multiline
|
||||
```
|
||||
|
||||
Run queries in batch-mode:
|
||||
Запуск запросов в пакетном режиме:
|
||||
|
||||
``` bash
|
||||
clickhouse-client --query='SELECT 1'
|
||||
@ -73,7 +74,7 @@ echo 'SELECT 1' | clickhouse-client
|
||||
clickhouse-client <<< 'SELECT 1'
|
||||
```
|
||||
|
||||
Insert data from a file in specified format:
|
||||
Вставка данных из файла в заданном формате:
|
||||
|
||||
``` bash
|
||||
clickhouse-client --query='INSERT INTO table VALUES' < data.txt
|
||||
@ -82,39 +83,39 @@ clickhouse-client --query='INSERT INTO table FORMAT TabSeparated' < data.tsv
|
||||
|
||||
</details>
|
||||
|
||||
## Import Sample Dataset {#import-sample-dataset}
|
||||
## Импорт Образца Набора Данных {#import-sample-dataset}
|
||||
|
||||
Now it’s time to fill our ClickHouse server with some sample data. In this tutorial, we’ll use the anonymized data of Yandex.Metrica, the first service that runs ClickHouse in production way before it became open-source (more on that in [history section](../introduction/history.md)). There are [multiple ways to import Yandex.Metrica dataset](example_datasets/metrica.md), and for the sake of the tutorial, we’ll go with the most realistic one.
|
||||
Теперь пришло время заполнить наш сервер ClickHouse некоторыми образцами данных. В этом уроке мы будем использовать анонимизированные данные Яндекса.Metrica, первый сервис, который запускает ClickHouse в производственном режиме до того, как он стал открытым исходным кодом (подробнее об этом в [раздел истории](../introduction/history.md)). Есть [несколько способов импорта Яндекса.Набор метрика ](example_datasets/metrica.md), и ради учебника мы пойдем с самым реалистичным из них.
|
||||
|
||||
### Download and Extract Table Data {#download-and-extract-table-data}
|
||||
### Загрузка и извлечение данных таблицы {#download-and-extract-table-data}
|
||||
|
||||
``` bash
|
||||
curl https://clickhouse-datasets.s3.yandex.net/hits/tsv/hits_v1.tsv.xz | unxz --threads=`nproc` > hits_v1.tsv
|
||||
curl https://clickhouse-datasets.s3.yandex.net/visits/tsv/visits_v1.tsv.xz | unxz --threads=`nproc` > visits_v1.tsv
|
||||
```
|
||||
|
||||
The extracted files are about 10GB in size.
|
||||
Извлеченные файлы имеют размер около 10 ГБ.
|
||||
|
||||
### Create Tables {#create-tables}
|
||||
### Создавать таблицы {#create-tables}
|
||||
|
||||
As in most databases management systems, ClickHouse logically groups tables into “databases”. There’s a `default` database, but we’ll create a new one named `tutorial`:
|
||||
Как и в большинстве систем управления базами данных, ClickHouse логически группирует таблицы в «databases». Там есть еще один `default` база данных, но мы создадим новую с именем `tutorial`:
|
||||
|
||||
``` bash
|
||||
clickhouse-client --query "CREATE DATABASE IF NOT EXISTS tutorial"
|
||||
```
|
||||
|
||||
Syntax for creating tables is way more complicated compared to databases (see [reference](../query_language/create.md). In general `CREATE TABLE` statement has to specify three key things:
|
||||
Синтаксис для создания таблиц намного сложнее по сравнению с базами данных (см. [ссылка](../sql_reference/statements/create.md). В общем `CREATE TABLE` в заявлении должны быть указаны три ключевых момента:
|
||||
|
||||
1. Name of table to create.
|
||||
2. Table schema, i.e. list of columns and their [data types](../data_types/index.md).
|
||||
3. [Table engine](../operations/table_engines/index.md) and it’s settings, which determines all the details on how queries to this table will be physically executed.
|
||||
1. Имя таблицы для создания.
|
||||
2. Table schema, i.e. list of columns and their [тип данных](../sql_reference/data_types/index.md).
|
||||
3. [Настольный двигатель](../engines/table_engines/index.md) и это настройки, которые определяют все детали того, как запросы к этой таблице будут физически выполняться.
|
||||
|
||||
Yandex.Metrica is a web analytics service, and sample dataset doesn’t cover its full functionality, so there are only two tables to create:
|
||||
Яндекс.Metrica - это сервис веб-аналитики, и пример набора данных не охватывает его полную функциональность, поэтому для создания необходимо создать только две таблицы:
|
||||
|
||||
- `hits` is a table with each action done by all users on all websites covered by the service.
|
||||
- `visits` is a table that contains pre-built sessions instead of individual actions.
|
||||
- `hits` это таблица с каждым действием, выполняемым всеми пользователями на всех веб-сайтах, охватываемых сервисом.
|
||||
- `visits` это таблица, которая содержит предварительно построенные сеансы вместо отдельных действий.
|
||||
|
||||
Let’s see and execute the real create table queries for these tables:
|
||||
Давайте посмотрим и выполним реальные запросы create table для этих таблиц:
|
||||
|
||||
``` sql
|
||||
CREATE TABLE tutorial.hits_v1
|
||||
@ -457,22 +458,22 @@ SAMPLE BY intHash32(UserID)
|
||||
SETTINGS index_granularity = 8192
|
||||
```
|
||||
|
||||
You can execute those queries using the interactive mode of `clickhouse-client` (just launch it in a terminal without specifying a query in advance) or try some [alternative interface](../interfaces/index.md) if you want.
|
||||
Вы можете выполнить эти запросы с помощью интерактивного режима `clickhouse-client` (просто запустите его в терминале, не указывая заранее запрос) или попробуйте некоторые [альтернативный интерфейс](../interfaces/index.md) если ты хочешь.
|
||||
|
||||
As we can see, `hits_v1` uses the [basic MergeTree engine](../operations/table_engines/mergetree.md), while the `visits_v1` uses the [Collapsing](../operations/table_engines/collapsingmergetree.md) variant.
|
||||
Как мы видим, `hits_v1` использует [базовый движок MergeTree](../engines/table_engines/mergetree_family/mergetree.md), в то время как `visits_v1` использует [Разрушение](../engines/table_engines/mergetree_family/collapsingmergetree.md) вариант.
|
||||
|
||||
### Import Data {#import-data}
|
||||
### Импортировать данные {#import-data}
|
||||
|
||||
Data import to ClickHouse is done via [INSERT INTO](../query_language/insert_into.md) query like in many other SQL databases. However, data is usually provided in one of the [supported serialization formats](../interfaces/formats.md) instead of `VALUES` clause (which is also supported).
|
||||
Импорт данных в ClickHouse осуществляется через [INSERT INTO](../sql_reference/statements/insert_into.md) запрос, как и во многих других базах данных SQL. Однако данные обычно приводятся в одном из следующих документов: [поддерживаемые форматы сериализации](../interfaces/formats.md) вместо `VALUES` предложение (которое также поддерживается).
|
||||
|
||||
The files we downloaded earlier are in tab-separated format, so here’s how to import them via console client:
|
||||
Файлы, которые мы загрузили ранее, находятся в формате с разделенными вкладками, поэтому вот как импортировать их через консольный клиент:
|
||||
|
||||
``` bash
|
||||
clickhouse-client --query "INSERT INTO tutorial.hits_v1 FORMAT TSV" --max_insert_block_size=100000 < hits_v1.tsv
|
||||
clickhouse-client --query "INSERT INTO tutorial.visits_v1 FORMAT TSV" --max_insert_block_size=100000 < visits_v1.tsv
|
||||
```
|
||||
|
||||
ClickHouse has a lot of [settings to tune](../operations/settings/index.md) and one way to specify them in console client is via arguments, as we can see with `--max_insert_block_size`. The easiest way to figure out what settings are available, what do they mean and what the defaults are is to query the `system.settings` table:
|
||||
У ClickHouse их очень много [настройки для настройки](../operations/settings/index.md) и один из способов указать их в консольном клиенте - это через аргументы, как мы видим с помощью `--max_insert_block_size`. Самый простой способ выяснить, какие настройки доступны, что они означают и каковы значения по умолчанию, - это запросить `system.settings` стол:
|
||||
|
||||
``` sql
|
||||
SELECT name, value, changed, description
|
||||
@ -483,23 +484,23 @@ FORMAT TSV
|
||||
max_insert_block_size 1048576 0 "The maximum block size for insertion, if we control the creation of blocks for insertion."
|
||||
```
|
||||
|
||||
Optionally you can [OPTIMIZE](../query_language/misc/#misc_operations-optimize) the tables after import. Tables that are configured with an engine from MergeTree-family always do merges of data parts in the background to optimize data storage (or at least check if it makes sense). These queries force the table engine to do storage optimization right now instead of some time later:
|
||||
По желанию вы можете [OPTIMIZE](../sql_reference/misc/#misc_operations-optimize) таблицы после импорта. Таблицы, настроенные с помощью движка из семейства MergeTree, всегда выполняют слияние частей данных в фоновом режиме для оптимизации хранения данных (или, по крайней мере, проверяют, имеет ли это смысл). Эти запросы заставляют механизм таблиц выполнять оптимизацию хранилища прямо сейчас, а не некоторое время спустя:
|
||||
|
||||
``` bash
|
||||
clickhouse-client --query "OPTIMIZE TABLE tutorial.hits_v1 FINAL"
|
||||
clickhouse-client --query "OPTIMIZE TABLE tutorial.visits_v1 FINAL"
|
||||
```
|
||||
|
||||
These queries start an I/O and CPU intensive operation, so if the table consistently receives new data, it’s better to leave it alone and let merges run in the background.
|
||||
Эти запросы запускают интенсивную работу ввода-вывода и процессора, поэтому, если таблица постоянно получает новые данные, лучше оставить ее в покое и позволить слияниям работать в фоновом режиме.
|
||||
|
||||
Now we can check if the table import was successful:
|
||||
Теперь мы можем проверить, был ли импорт таблицы успешным:
|
||||
|
||||
``` bash
|
||||
clickhouse-client --query "SELECT COUNT(*) FROM tutorial.hits_v1"
|
||||
clickhouse-client --query "SELECT COUNT(*) FROM tutorial.visits_v1"
|
||||
```
|
||||
|
||||
## Example Queries {#example-queries}
|
||||
## Пример запроса {#example-queries}
|
||||
|
||||
``` sql
|
||||
SELECT
|
||||
@ -521,18 +522,18 @@ FROM tutorial.visits_v1
|
||||
WHERE (CounterID = 912887) AND (toYYYYMM(StartDate) = 201403) AND (domain(StartURL) = 'yandex.ru')
|
||||
```
|
||||
|
||||
## Cluster Deployment {#cluster-deployment}
|
||||
## Развертывание Кластера {#cluster-deployment}
|
||||
|
||||
ClickHouse cluster is a homogenous cluster. Steps to set up:
|
||||
Кластер ClickHouse-это однородный кластер. Шаги для настройки:
|
||||
|
||||
1. Install ClickHouse server on all machines of the cluster
|
||||
2. Set up cluster configs in configuration files
|
||||
3. Create local tables on each instance
|
||||
4. Create a [Distributed table](../operations/table_engines/distributed.md)
|
||||
1. Установите сервер ClickHouse на всех компьютерах кластера
|
||||
2. Настройка конфигураций кластера в файлах конфигурации
|
||||
3. Создание локальных таблиц на каждом экземпляре
|
||||
4. Создать [Распространены таблицы](../engines/table_engines/special/distributed.md)
|
||||
|
||||
[Distributed table](../operations/table_engines/distributed.md) is actually a kind of “view” to local tables of ClickHouse cluster. SELECT query from a distributed table executes using resources of all cluster’s shards. You may specify configs for multiple clusters and create multiple distributed tables providing views to different clusters.
|
||||
[Распространены таблицы](../engines/table_engines/special/distributed.md) это на самом деле своего рода «view» к локальным таблицам кластера ClickHouse. Запрос SELECT из распределенной таблицы выполняется с использованием ресурсов всех сегментов кластера. Вы можете указать конфигурации для нескольких кластеров и создать несколько распределенных таблиц, предоставляющих представления для разных кластеров.
|
||||
|
||||
Example config for a cluster with three shards, one replica each:
|
||||
Пример конфигурации для кластера с тремя сегментами, по одной реплике в каждом:
|
||||
|
||||
``` xml
|
||||
<remote_servers>
|
||||
@ -559,37 +560,37 @@ Example config for a cluster with three shards, one replica each:
|
||||
</remote_servers>
|
||||
```
|
||||
|
||||
For further demonstration, let’s create a new local table with the same `CREATE TABLE` query that we used for `hits_v1`, but different table name:
|
||||
Для дальнейшей демонстрации давайте создадим новую локальную таблицу с тем же именем `CREATE TABLE` запрос, который мы использовали для `hits_v1`, но другое имя таблицы:
|
||||
|
||||
``` sql
|
||||
CREATE TABLE tutorial.hits_local (...) ENGINE = MergeTree() ...
|
||||
```
|
||||
|
||||
Creating a distributed table providing a view into local tables of the cluster:
|
||||
Создание распределенной таблицы, предоставляющей представление в локальные таблицы кластера:
|
||||
|
||||
``` sql
|
||||
CREATE TABLE tutorial.hits_all AS tutorial.hits_local
|
||||
ENGINE = Distributed(perftest_3shards_1replicas, tutorial, hits_local, rand());
|
||||
```
|
||||
|
||||
A common practice is to create similar Distributed tables on all machines of the cluster. It allows running distributed queries on any machine of the cluster. Also there’s an alternative option to create temporary distributed table for a given SELECT query using [remote](../query_language/table_functions/remote.md) table function.
|
||||
Распространенной практикой является создание одинаковых распределенных таблиц на всех машинах кластера. Он позволяет выполнять распределенные запросы на любой машине кластера. Кроме того, существует альтернативный вариант создания временной распределенной таблицы для данного запроса SELECT с помощью [удаленный](../sql_reference/table_functions/remote.md) табличная функция.
|
||||
|
||||
Let’s run [INSERT SELECT](../query_language/insert_into.md) into the Distributed table to spread the table to multiple servers.
|
||||
Давай убежим [INSERT SELECT](../sql_reference/statements/insert_into.md) в распределенную таблицу, чтобы распространить таблицу на несколько серверов.
|
||||
|
||||
``` sql
|
||||
INSERT INTO tutorial.hits_all SELECT * FROM tutorial.hits_v1;
|
||||
```
|
||||
|
||||
!!! warning "Notice"
|
||||
This approach is not suitable for the sharding of large tables. There’s a separate tool [clickhouse-copier](../operations/utils/clickhouse-copier.md) that can re-shard arbitrary large tables.
|
||||
!!! warning "Уведомление"
|
||||
Такой подход не подходит для сегментации больших столов. Есть отдельный инструмент [clickhouse-копировальный аппарат](../operations/utilities/clickhouse-copier.md) это может повторно осколить произвольные большие таблицы.
|
||||
|
||||
As you could expect, computationally heavy queries run N times faster if they utilize 3 servers instead of one.
|
||||
Как и следовало ожидать, вычислительно тяжелые запросы выполняются в N раз быстрее, если они используют 3 сервера вместо одного.
|
||||
|
||||
In this case, we have used a cluster with 3 shards, and each contains a single replica.
|
||||
В этом случае мы использовали кластер с 3 осколками, и каждый из них содержит одну реплику.
|
||||
|
||||
To provide resilience in a production environment, we recommend that each shard should contain 2-3 replicas spread between multiple availability zones or datacenters (or at least racks). Note that ClickHouse supports an unlimited number of replicas.
|
||||
Для обеспечения устойчивости в рабочей среде рекомендуется, чтобы каждый сегмент содержал 2-3 реплики, распределенные между несколькими зонами доступности или центрами обработки данных (или, по крайней мере, стойками). Обратите внимание, что ClickHouse поддерживает неограниченное количество реплик.
|
||||
|
||||
Example config for a cluster of one shard containing three replicas:
|
||||
Пример конфигурации для кластера из одного осколка, содержащего три реплики:
|
||||
|
||||
``` xml
|
||||
<remote_servers>
|
||||
@ -613,12 +614,12 @@ Example config for a cluster of one shard containing three replicas:
|
||||
</remote_servers>
|
||||
```
|
||||
|
||||
To enable native replication [ZooKeeper](http://zookeeper.apache.org/) is required. ClickHouse takes care of data consistency on all replicas and runs restore procedure after failure automatically. It’s recommended to deploy the ZooKeeper cluster on separate servers (where no other processes including ClickHouse are running).
|
||||
Чтобы включить собственную репликацию [Смотритель зоопарка](http://zookeeper.apache.org/) требуемый. ClickHouse заботится о согласованности данных во всех репликах и автоматически запускает процедуру восстановления после сбоя. Рекомендуется развернуть кластер ZooKeeper на отдельных серверах (где не выполняются никакие другие процессы, включая ClickHouse).
|
||||
|
||||
!!! note "Note"
|
||||
ZooKeeper is not a strict requirement: in some simple cases, you can duplicate the data by writing it into all the replicas from your application code. This approach is **not** recommended, in this case, ClickHouse won’t be able to guarantee data consistency on all replicas. Thus it becomes the responsibility of your application.
|
||||
!!! note "Примечание"
|
||||
ZooKeeper не является строгим требованием: в некоторых простых случаях вы можете дублировать данные, записав их во все реплики из кода вашего приложения. Такой подход является **нет** рекомендуется, чтобы в этом случае ClickHouse не мог гарантировать согласованность данных на всех репликах. Таким образом, это становится ответственностью вашего приложения.
|
||||
|
||||
ZooKeeper locations are specified in the configuration file:
|
||||
Расположение ZooKeeper указано в конфигурационном файле:
|
||||
|
||||
``` xml
|
||||
<zookeeper>
|
||||
@ -637,7 +638,7 @@ ZooKeeper locations are specified in the configuration file:
|
||||
</zookeeper>
|
||||
```
|
||||
|
||||
Also, we need to set macros for identifying each shard and replica which are used on table creation:
|
||||
Кроме того, нам нужно установить макросы для идентификации каждого осколка и реплики, которые используются при создании таблицы:
|
||||
|
||||
``` xml
|
||||
<macros>
|
||||
@ -646,7 +647,7 @@ Also, we need to set macros for identifying each shard and replica which are use
|
||||
</macros>
|
||||
```
|
||||
|
||||
If there are no replicas at the moment on replicated table creation, a new first replica is instantiated. If there are already live replicas, the new replica clones data from existing ones. You have an option to create all replicated tables first, and then insert data to it. Another option is to create some replicas and add the others after or during data insertion.
|
||||
Если в данный момент при создании реплицированной таблицы реплик нет, то создается новая первая реплика. Если уже существуют живые реплики, то новая реплика клонирует данные из существующих. У вас есть возможность сначала создать все реплицированные таблицы, а затем вставить в них данные. Другой вариант-создать некоторые реплики и добавить другие после или во время вставки данных.
|
||||
|
||||
``` sql
|
||||
CREATE TABLE tutorial.hits_replica (...)
|
||||
@ -657,12 +658,12 @@ ENGINE = ReplcatedMergeTree(
|
||||
...
|
||||
```
|
||||
|
||||
Here we use [ReplicatedMergeTree](../operations/table_engines/replication.md) table engine. In parameters we specify ZooKeeper path containing shard and replica identifiers.
|
||||
Здесь мы используем [ReplicatedMergeTree](../engines/table_engines/mergetree_family/replication.md) настольный двигатель. В параметрах мы указываем путь ZooKeeper, содержащий идентификаторы сегментов и реплик.
|
||||
|
||||
``` sql
|
||||
INSERT INTO tutorial.hits_replica SELECT * FROM tutorial.hits_local;
|
||||
```
|
||||
|
||||
Replication operates in multi-master mode. Data can be loaded into any replica, and the system then syncs it with other instances automatically. Replication is asynchronous so at a given moment, not all replicas may contain recently inserted data. At least one replica should be up to allow data ingestion. Others will sync up data and repair consistency once they will become active again. Note that this approach allows for the low possibility of a loss of recently inserted data.
|
||||
Репликация работает в режиме мульти-мастер. Данные могут быть загружены в любую реплику, а затем система автоматически синхронизирует их с другими экземплярами. Репликация является асинхронной, поэтому в данный момент не все реплики могут содержать недавно вставленные данные. По крайней мере, одна реплика должна быть готова, чтобы обеспечить прием данных. Другие будут синхронизировать данные и восстанавливать согласованность, как только они снова станут активными. Обратите внимание, что этот подход допускает низкую вероятность потери недавно вставленных данных.
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/getting_started/tutorial/) <!--hide-->
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/en/getting_started/tutorial/) <!--hide-->
|
||||
|
||||
@ -178,7 +178,7 @@ LIMIT 10
|
||||
```
|
||||
|
||||
!!! note "Примечание"
|
||||
Функция [modelEvaluate](../query_language/functions/other_functions.md#function-modelevaluate) возвращает кортежи (tuple) с исходными прогнозами по классам для моделей с несколькими классами.
|
||||
Функция [modelEvaluate](../sql_reference/functions/other_functions.md#function-modelevaluate) возвращает кортежи (tuple) с исходными прогнозами по классам для моделей с несколькими классами.
|
||||
|
||||
Спрогнозируйте вероятность:
|
||||
|
||||
@ -201,7 +201,7 @@ LIMIT 10
|
||||
```
|
||||
|
||||
!!! note "Примечание"
|
||||
Подробнее про функцию [exp()](../query_language/functions/math_functions.md).
|
||||
Подробнее про функцию [exp()](../sql_reference/functions/math_functions.md).
|
||||
|
||||
Посчитайте логистическую функцию потерь (LogLoss) на всей выборке:
|
||||
|
||||
@ -227,4 +227,4 @@ FROM
|
||||
```
|
||||
|
||||
!!! note "Примечание"
|
||||
Подробнее про функции [avg()](../query_language/agg_functions/reference.md#agg_function-avg), [log()](../query_language/functions/math_functions.md).
|
||||
Подробнее про функции [avg()](../sql_reference/aggregate_functions/reference.md#agg_function-avg), [log()](../sql_reference/functions/math_functions.md).
|
||||
|
||||
@ -88,7 +88,7 @@ clickhouse-client --param_parName="[1, 2]" -q "SELECT * FROM table WHERE a = {p
|
||||
```
|
||||
|
||||
- `name` — идентификатор подстановки. В консольном клиенте его следует использовать как часть имени параметра `--param_<name> = value`.
|
||||
- `data type` — [тип данных](../data_types/index.md) значения. Например, структура данных `(integer, ('string', integer))` может иметь тип данных `Tuple(UInt8, Tuple(String, UInt8))` ([целочисленный](../data_types/int_uint.md) тип может быть и другим).
|
||||
- `data type` — [тип данных](../sql_reference/data_types/index.md) значения. Например, структура данных `(integer, ('string', integer))` может иметь тип данных `Tuple(UInt8, Tuple(String, UInt8))` ([целочисленный](../sql_reference/data_types/int_uint.md) тип может быть и другим).
|
||||
|
||||
#### Пример {#primer}
|
||||
|
||||
|
||||
@ -99,9 +99,9 @@ world
|
||||
|
||||
Массивы форматируются в виде списка значений через запятую в квадратных скобках. Элементы массива - числа форматируются как обычно, а даты, даты-с-временем и строки - в одинарных кавычках с такими же правилами экранирования, как указано выше.
|
||||
|
||||
[NULL](../query_language/syntax.md) форматируется как `\N`.
|
||||
[NULL](../sql_reference/syntax.md) форматируется как `\N`.
|
||||
|
||||
Каждый элемент структуры типа [Nested](../data_types/nested_data_structures/nested.md) представляется как отдельный массив.
|
||||
Каждый элемент структуры типа [Nested](../sql_reference/data_types/nested_data_structures/nested.md) представляется как отдельный массив.
|
||||
|
||||
Например:
|
||||
|
||||
@ -302,7 +302,7 @@ SearchPhrase=дизайн штор count()=1064
|
||||
SearchPhrase=баку count()=1000
|
||||
```
|
||||
|
||||
[NULL](../query_language/syntax.md) форматируется как `\N`.
|
||||
[NULL](../sql_reference/syntax.md) форматируется как `\N`.
|
||||
|
||||
``` sql
|
||||
SELECT * FROM t_null FORMAT TSKV
|
||||
@ -432,7 +432,7 @@ JSON совместим с JavaScript. Для этого, дополнитель
|
||||
|
||||
Этот формат подходит только для вывода результата выполнения запроса, но не для парсинга (приёма данных для вставки в таблицу).
|
||||
|
||||
ClickHouse поддерживает [NULL](../query_language/syntax.md), который при выводе JSON будет отображен как `null`.
|
||||
ClickHouse поддерживает [NULL](../sql_reference/syntax.md), который при выводе JSON будет отображен как `null`.
|
||||
|
||||
Смотрите также формат [JSONEachRow](#jsoneachrow) .
|
||||
|
||||
@ -507,7 +507,7 @@ ClickHouse игнорирует пробелы между элементами
|
||||
|
||||
**Обработка пропущенных значений**
|
||||
|
||||
ClickHouse заменяет опущенные значения значениями по умолчанию для соответствующих [data types](../data_types/index.md).
|
||||
ClickHouse заменяет опущенные значения значениями по умолчанию для соответствующих [data types](../sql_reference/data_types/index.md).
|
||||
|
||||
Если указано `DEFAULT expr`, то ClickHouse использует различные правила подстановки в зависимости от настройки [input\_format\_defaults\_for\_omitted\_fields](../operations/settings/settings.md#session_settings-input_format_defaults_for_omitted_fields).
|
||||
|
||||
@ -552,7 +552,7 @@ CREATE TABLE IF NOT EXISTS example_table
|
||||
|
||||
### Использование вложенных структур {#jsoneachrow-nested}
|
||||
|
||||
Если у вас есть таблица со столбцами типа [Nested](../data_types/nested_data_structures/nested.md), то в неё можно вставить данные из JSON-документа с такой же структурой. Функциональность включается настройкой [input\_format\_import\_nested\_json](../operations/settings/settings.md#settings-input_format_import_nested_json).
|
||||
Если у вас есть таблица со столбцами типа [Nested](../sql_reference/data_types/nested_data_structures/nested.md), то в неё можно вставить данные из JSON-документа с такой же структурой. Функциональность включается настройкой [input\_format\_import\_nested\_json](../operations/settings/settings.md#settings-input_format_import_nested_json).
|
||||
|
||||
Например, рассмотрим следующую таблицу:
|
||||
|
||||
@ -626,7 +626,7 @@ SELECT * FROM json_each_row_nested
|
||||
Рисуется полная сетка таблицы и, таким образом, каждая строчка занимает две строки в терминале.
|
||||
Каждый блок результата выводится в виде отдельной таблицы. Это нужно, чтобы можно было выводить блоки без буферизации результата (буферизация потребовалась бы, чтобы заранее вычислить видимую ширину всех значений.)
|
||||
|
||||
[NULL](../query_language/syntax.md) выводится как `ᴺᵁᴸᴸ`.
|
||||
[NULL](../sql_reference/syntax.md) выводится как `ᴺᵁᴸᴸ`.
|
||||
|
||||
``` sql
|
||||
SELECT * FROM t_null
|
||||
@ -728,7 +728,7 @@ FixedString представлены просто как последовате
|
||||
|
||||
Array представлены как длина в формате varint (unsigned [LEB128](https://en.wikipedia.org/wiki/LEB128)), а затем элементы массива, подряд.
|
||||
|
||||
Для поддержки [NULL](../query_language/syntax.md#null-literal) перед каждым значением типа [Nullable](../data_types/nullable.md) следует байт содержащий 1 или 0. Если байт 1, то значение равно NULL, и этот байт интерпретируется как отдельное значение (т.е. после него следует значение следующего поля). Если байт 0, то после байта следует значение поля (не равно NULL).
|
||||
Для поддержки [NULL](../sql_reference/syntax.md#null-literal) перед каждым значением типа [Nullable](../sql_reference/data_types/nullable.md) следует байт содержащий 1 или 0. Если байт 1, то значение равно NULL, и этот байт интерпретируется как отдельное значение (т.е. после него следует значение следующего поля). Если байт 0, то после байта следует значение поля (не равно NULL).
|
||||
|
||||
## RowBinaryWithNamesAndTypes {#rowbinarywithnamesandtypes}
|
||||
|
||||
@ -740,7 +740,7 @@ Array представлены как длина в формате varint (unsig
|
||||
|
||||
## Values {#data-format-values}
|
||||
|
||||
Выводит каждую строку в скобках. Строки разделены запятыми. После последней строки запятой нет. Значения внутри скобок также разделены запятыми. Числа выводятся в десятичном виде без кавычек. Массивы выводятся в квадратных скобках. Строки, даты, даты-с-временем выводятся в кавычках. Правила экранирования и особенности парсинга аналогичны формату [TabSeparated](#tabseparated). При форматировании, лишние пробелы не ставятся, а при парсинге - допустимы и пропускаются (за исключением пробелов внутри значений типа массив, которые недопустимы). [NULL](../query_language/syntax.md) представляется как `NULL`.
|
||||
Выводит каждую строку в скобках. Строки разделены запятыми. После последней строки запятой нет. Значения внутри скобок также разделены запятыми. Числа выводятся в десятичном виде без кавычек. Массивы выводятся в квадратных скобках. Строки, даты, даты-с-временем выводятся в кавычках. Правила экранирования и особенности парсинга аналогичны формату [TabSeparated](#tabseparated). При форматировании, лишние пробелы не ставятся, а при парсинге - допустимы и пропускаются (за исключением пробелов внутри значений типа массив, которые недопустимы). [NULL](../sql_reference/syntax.md) представляется как `NULL`.
|
||||
|
||||
Минимальный набор символов, которых вам необходимо экранировать при передаче в Values формате: одинарная кавычка и обратный слеш.
|
||||
|
||||
@ -750,7 +750,7 @@ Array представлены как длина в формате varint (unsig
|
||||
|
||||
Выводит каждое значение на отдельной строке, с указанием имени столбца. Формат удобно использовать для вывода одной-нескольких строк, если каждая строка состоит из большого количества столбцов.
|
||||
|
||||
[NULL](../query_language/syntax.md) выводится как `ᴺᵁᴸᴸ`.
|
||||
[NULL](../sql_reference/syntax.md) выводится как `ᴺᵁᴸᴸ`.
|
||||
|
||||
Пример:
|
||||
|
||||
@ -928,7 +928,7 @@ message MessageType {
|
||||
```
|
||||
|
||||
ClickHouse попытается найти столбец с именем `x.y.z` (или `x_y_z`, или `X.y_Z` и т.п.).
|
||||
Вложенные сообщения удобно использовать в качестве соответствия для [вложенной структуры данных](../data_types/nested_data_structures/nested.md).
|
||||
Вложенные сообщения удобно использовать в качестве соответствия для [вложенной структуры данных](../sql_reference/data_types/nested_data_structures/nested.md).
|
||||
|
||||
Значения по умолчанию, определённые в схеме `proto2`, например,
|
||||
|
||||
@ -940,7 +940,7 @@ message MessageType {
|
||||
}
|
||||
```
|
||||
|
||||
не применяются; вместо них используются определенные в таблице [значения по умолчанию](../query_language/create.md#create-default-values).
|
||||
не применяются; вместо них используются определенные в таблице [значения по умолчанию](../sql_reference/statements/create.md#create-default-values).
|
||||
|
||||
ClickHouse пишет и читает сообщения `Protocol Buffers` в формате `length-delimited`. Это означает, что перед каждым сообщением пишется его длина
|
||||
в формате [varint](https://developers.google.com/protocol-buffers/docs/encoding#varints). См. также [как читать и записывать сообщения Protocol Buffers в формате length-delimited в различных языках программирования](https://cwiki.apache.org/confluence/display/GEODE/Delimiting+Protobuf+Messages).
|
||||
@ -951,25 +951,25 @@ ClickHouse пишет и читает сообщения `Protocol Buffers` в
|
||||
|
||||
### Соответствие типов данных {#sootvetstvie-tipov-dannykh}
|
||||
|
||||
Таблица ниже содержит поддерживаемые типы данных и их соответствие [типам данных](../data_types/index.md) ClickHouse для запросов `INSERT` и `SELECT`.
|
||||
Таблица ниже содержит поддерживаемые типы данных и их соответствие [типам данных](../sql_reference/data_types/index.md) ClickHouse для запросов `INSERT` и `SELECT`.
|
||||
|
||||
| Тип данных Parquet (`INSERT`) | Тип данных ClickHouse | Тип данных Parquet (`SELECT`) |
|
||||
|-------------------------------|---------------------------------------------|-------------------------------|
|
||||
| `UINT8`, `BOOL` | [UInt8](../data_types/int_uint.md) | `UINT8` |
|
||||
| `INT8` | [Int8](../data_types/int_uint.md) | `INT8` |
|
||||
| `UINT16` | [UInt16](../data_types/int_uint.md) | `UINT16` |
|
||||
| `INT16` | [Int16](../data_types/int_uint.md) | `INT16` |
|
||||
| `UINT32` | [UInt32](../data_types/int_uint.md) | `UINT32` |
|
||||
| `INT32` | [Int32](../data_types/int_uint.md) | `INT32` |
|
||||
| `UINT64` | [UInt64](../data_types/int_uint.md) | `UINT64` |
|
||||
| `INT64` | [Int64](../data_types/int_uint.md) | `INT64` |
|
||||
| `FLOAT`, `HALF_FLOAT` | [Float32](../data_types/float.md) | `FLOAT` |
|
||||
| `DOUBLE` | [Float64](../data_types/float.md) | `DOUBLE` |
|
||||
| `DATE32` | [Date](../data_types/date.md) | `UINT16` |
|
||||
| `DATE64`, `TIMESTAMP` | [DateTime](../data_types/datetime.md) | `UINT32` |
|
||||
| `STRING`, `BINARY` | [String](../data_types/string.md) | `STRING` |
|
||||
| — | [FixedString](../data_types/fixedstring.md) | `STRING` |
|
||||
| `DECIMAL` | [Decimal](../data_types/decimal.md) | `DECIMAL` |
|
||||
| `UINT8`, `BOOL` | [UInt8](../sql_reference/data_types/int_uint.md) | `UINT8` |
|
||||
| `INT8` | [Int8](../sql_reference/data_types/int_uint.md) | `INT8` |
|
||||
| `UINT16` | [UInt16](../sql_reference/data_types/int_uint.md) | `UINT16` |
|
||||
| `INT16` | [Int16](../sql_reference/data_types/int_uint.md) | `INT16` |
|
||||
| `UINT32` | [UInt32](../sql_reference/data_types/int_uint.md) | `UINT32` |
|
||||
| `INT32` | [Int32](../sql_reference/data_types/int_uint.md) | `INT32` |
|
||||
| `UINT64` | [UInt64](../sql_reference/data_types/int_uint.md) | `UINT64` |
|
||||
| `INT64` | [Int64](../sql_reference/data_types/int_uint.md) | `INT64` |
|
||||
| `FLOAT`, `HALF_FLOAT` | [Float32](../sql_reference/data_types/float.md) | `FLOAT` |
|
||||
| `DOUBLE` | [Float64](../sql_reference/data_types/float.md) | `DOUBLE` |
|
||||
| `DATE32` | [Date](../sql_reference/data_types/date.md) | `UINT16` |
|
||||
| `DATE64`, `TIMESTAMP` | [DateTime](../sql_reference/data_types/datetime.md) | `UINT32` |
|
||||
| `STRING`, `BINARY` | [String](../sql_reference/data_types/string.md) | `STRING` |
|
||||
| — | [FixedString](../sql_reference/data_types/fixedstring.md) | `STRING` |
|
||||
| `DECIMAL` | [Decimal](../sql_reference/data_types/decimal.md) | `DECIMAL` |
|
||||
|
||||
ClickHouse поддерживает настраиваемую точность для формата `Decimal`. При обработке запроса `INSERT`, ClickHouse обрабатывает тип данных Parquet `DECIMAL` как `Decimal128`.
|
||||
|
||||
@ -991,7 +991,7 @@ $ cat {filename} | clickhouse-client --query="INSERT INTO {some_table} FORMAT Pa
|
||||
$ clickhouse-client --query="SELECT * FROM {some_table} FORMAT Parquet" > {some_file.pq}
|
||||
```
|
||||
|
||||
Для обмена данными с экосистемой Hadoop можно использовать движки таблиц [HDFS](../operations/table_engines/hdfs.md).
|
||||
Для обмена данными с экосистемой Hadoop можно использовать движки таблиц [HDFS](../engines/table_engines/integrations/hdfs.md).
|
||||
|
||||
## ORC {#data-format-orc}
|
||||
|
||||
@ -999,24 +999,24 @@ $ clickhouse-client --query="SELECT * FROM {some_table} FORMAT Parquet" > {some_
|
||||
|
||||
### Соответствие типов данных {#sootvetstvie-tipov-dannykh-1}
|
||||
|
||||
Таблица показывает поддержанные типы данных и их соответствие [типам данных](../data_types/index.md) ClickHouse для запросов `INSERT`.
|
||||
Таблица показывает поддержанные типы данных и их соответствие [типам данных](../sql_reference/data_types/index.md) ClickHouse для запросов `INSERT`.
|
||||
|
||||
| Тип данных ORC (`INSERT`) | Тип данных ClickHouse |
|
||||
|---------------------------|---------------------------------------|
|
||||
| `UINT8`, `BOOL` | [UInt8](../data_types/int_uint.md) |
|
||||
| `INT8` | [Int8](../data_types/int_uint.md) |
|
||||
| `UINT16` | [UInt16](../data_types/int_uint.md) |
|
||||
| `INT16` | [Int16](../data_types/int_uint.md) |
|
||||
| `UINT32` | [UInt32](../data_types/int_uint.md) |
|
||||
| `INT32` | [Int32](../data_types/int_uint.md) |
|
||||
| `UINT64` | [UInt64](../data_types/int_uint.md) |
|
||||
| `INT64` | [Int64](../data_types/int_uint.md) |
|
||||
| `FLOAT`, `HALF_FLOAT` | [Float32](../data_types/float.md) |
|
||||
| `DOUBLE` | [Float64](../data_types/float.md) |
|
||||
| `DATE32` | [Date](../data_types/date.md) |
|
||||
| `DATE64`, `TIMESTAMP` | [DateTime](../data_types/datetime.md) |
|
||||
| `STRING`, `BINARY` | [String](../data_types/string.md) |
|
||||
| `DECIMAL` | [Decimal](../data_types/decimal.md) |
|
||||
| `UINT8`, `BOOL` | [UInt8](../sql_reference/data_types/int_uint.md) |
|
||||
| `INT8` | [Int8](../sql_reference/data_types/int_uint.md) |
|
||||
| `UINT16` | [UInt16](../sql_reference/data_types/int_uint.md) |
|
||||
| `INT16` | [Int16](../sql_reference/data_types/int_uint.md) |
|
||||
| `UINT32` | [UInt32](../sql_reference/data_types/int_uint.md) |
|
||||
| `INT32` | [Int32](../sql_reference/data_types/int_uint.md) |
|
||||
| `UINT64` | [UInt64](../sql_reference/data_types/int_uint.md) |
|
||||
| `INT64` | [Int64](../sql_reference/data_types/int_uint.md) |
|
||||
| `FLOAT`, `HALF_FLOAT` | [Float32](../sql_reference/data_types/float.md) |
|
||||
| `DOUBLE` | [Float64](../sql_reference/data_types/float.md) |
|
||||
| `DATE32` | [Date](../sql_reference/data_types/date.md) |
|
||||
| `DATE64`, `TIMESTAMP` | [DateTime](../sql_reference/data_types/datetime.md) |
|
||||
| `STRING`, `BINARY` | [String](../sql_reference/data_types/string.md) |
|
||||
| `DECIMAL` | [Decimal](../sql_reference/data_types/decimal.md) |
|
||||
|
||||
ClickHouse поддерживает настраиваемую точность для формата `Decimal`. При обработке запроса `INSERT`, ClickHouse обрабатывает тип данных Parquet `DECIMAL` как `Decimal128`.
|
||||
|
||||
@ -1032,7 +1032,7 @@ ClickHouse поддерживает настраиваемую точность
|
||||
$ cat filename.orc | clickhouse-client --query="INSERT INTO some_table FORMAT ORC"
|
||||
```
|
||||
|
||||
Для обмена данных с Hadoop можно использовать [движок таблиц HDFS](../operations/table_engines/hdfs.md).
|
||||
Для обмена данных с Hadoop можно использовать [движок таблиц HDFS](../engines/table_engines/integrations/hdfs.md).
|
||||
|
||||
## Схема формата {#formatschema}
|
||||
|
||||
@ -1045,6 +1045,6 @@ $ cat filename.orc | clickhouse-client --query="INSERT INTO some_table FORMAT OR
|
||||
относительно текущей директории на клиенте. Если клиент используется в [batch режиме](../interfaces/cli.md#cli_usage), то в записи схемы допускается только относительный путь, из соображений безопасности.
|
||||
|
||||
Если для ввода/вывода данных используется [HTTP-интерфейс](../interfaces/http.md), то файл со схемой должен располагаться на сервере в каталоге,
|
||||
указанном в параметре [format\_schema\_path](../operations/server_settings/settings.md#server_settings-format_schema_path) конфигурации сервера.
|
||||
указанном в параметре [format\_schema\_path](../operations/server_configuration_parameters/settings.md#server_configuration_parameters-format_schema_path) конфигурации сервера.
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/interfaces/formats/) <!--hide-->
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
HTTP интерфейс позволяет использовать ClickHouse на любой платформе, из любого языка программирования. У нас он используется для работы из Java и Perl, а также из shell-скриптов. В других отделах, HTTP интерфейс используется из Perl, Python и Go. HTTP интерфейс более ограничен по сравнению с родным интерфейсом, но является более совместимым.
|
||||
|
||||
По умолчанию, clickhouse-server слушает HTTP на порту 8123 (это можно изменить в конфиге).
|
||||
Если запросить GET / без параметров, то вернётся строка заданная с помощью настройки [http\_server\_default\_response](../operations/server_settings/settings.md#server_settings-http_server_default_response). Значение по умолчанию «Ok.» (с переводом строки на конце).
|
||||
Если запросить GET / без параметров, то вернётся строка заданная с помощью настройки [http\_server\_default\_response](../operations/server_configuration_parameters/settings.md#server_configuration_parameters-http_server_default_response). Значение по умолчанию «Ok.» (с переводом строки на конце).
|
||||
|
||||
``` bash
|
||||
$ curl 'http://localhost:8123/'
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# MySQL-интерфейс {#mysql-interface}
|
||||
|
||||
ClickHouse поддерживает взаимодействие по протоколу MySQL. Данная функция включается настройкой [mysql\_port](../operations/server_settings/settings.md#server_settings-mysql_port) в конфигурационном файле:
|
||||
ClickHouse поддерживает взаимодействие по протоколу MySQL. Данная функция включается настройкой [mysql\_port](../operations/server_configuration_parameters/settings.md#server_configuration_parameters-mysql_port) в конфигурационном файле:
|
||||
|
||||
``` xml
|
||||
<mysql_port>9004</mysql_port>
|
||||
|
||||
5
docs/ru/interfaces/third-party/index.md
vendored
Normal file
5
docs/ru/interfaces/third-party/index.md
vendored
Normal file
@ -0,0 +1,5 @@
|
||||
---
|
||||
toc_folder_title: Third-Party
|
||||
toc_priority: 24
|
||||
---
|
||||
|
||||
@ -35,7 +35,7 @@
|
||||
- [graphouse](https://github.com/yandex/graphouse)
|
||||
- [carbon-clickhouse](https://github.com/lomik/carbon-clickhouse) +
|
||||
- [graphite-clickhouse](https://github.com/lomik/graphite-clickhouse)
|
||||
- [graphite-ch-optimizer](https://github.com/innogames/graphite-ch-optimizer) - оптимизирует партиции таблиц [\*GraphiteMergeTree](../../operations/table_engines/graphitemergetree.md#graphitemergetree) согласно правилам в [конфигурации rollup](../../operations/table_engines/graphitemergetree.md#rollup-configuration)
|
||||
- [graphite-ch-optimizer](https://github.com/innogames/graphite-ch-optimizer) - оптимизирует партиции таблиц [\*GraphiteMergeTree](../../engines/table_engines/mergetree_family/graphitemergetree.md#graphitemergetree) согласно правилам в [конфигурации rollup](../../engines/table_engines/mergetree_family/graphitemergetree.md#rollup-configuration)
|
||||
- [Grafana](https://grafana.com/)
|
||||
- [clickhouse-grafana](https://github.com/Vertamedia/clickhouse-grafana)
|
||||
- [Prometheus](https://prometheus.io/)
|
||||
@ -72,7 +72,7 @@
|
||||
- [RClickhouse](https://github.com/IMSMWU/RClickhouse) (использует [clickhouse-cpp](https://github.com/artpaul/clickhouse-cpp))
|
||||
- Java
|
||||
- [Hadoop](http://hadoop.apache.org)
|
||||
- [clickhouse-hdfs-loader](https://github.com/jaykelin/clickhouse-hdfs-loader) (использует [JDBC](../../query_language/table_functions/jdbc.md))
|
||||
- [clickhouse-hdfs-loader](https://github.com/jaykelin/clickhouse-hdfs-loader) (использует [JDBC](../../sql_reference/table_functions/jdbc.md))
|
||||
- Scala
|
||||
- [Akka](https://akka.io)
|
||||
- [clickhouse-scala-client](https://github.com/crobox/clickhouse-scala-client)
|
||||
|
||||
@ -1,79 +1,80 @@
|
||||
---
|
||||
en_copy: true
|
||||
machine_translated: true
|
||||
machine_translated_rev: 1cd5f0028d917696daf71ac1c9ee849c99c1d5c8
|
||||
---
|
||||
|
||||
# ClickHouse Adopters {#clickhouse-adopters}
|
||||
# Усыновители ClickHouse {#clickhouse-adopters}
|
||||
|
||||
!!! warning "Disclaimer"
|
||||
The following list of companies using ClickHouse and their success stories is assembled from public sources, thus might differ from current reality. We’d appreciate it if you share the story of adopting ClickHouse in your company and [add it to the list](https://github.com/ClickHouse/ClickHouse/edit/master/docs/en/introduction/adopters.md), but please make sure you won’t have any NDA issues by doing so. Providing updates with publications from other companies is also useful.
|
||||
!!! warning "Оговорка"
|
||||
Следующий список компаний, использующих ClickHouse, и их истории успеха собраны из открытых источников, поэтому они могут отличаться от текущей реальности. Мы были бы очень признательны, если бы вы поделились историей принятия ClickHouse в свою компанию и [добавьте его в список](https://github.com/ClickHouse/ClickHouse/edit/master/docs/en/introduction/adopters.md), но, пожалуйста, убедитесь, что у вас не будет никаких проблем с NDA, сделав это. Предоставление обновлений с публикациями от других компаний также полезно.
|
||||
|
||||
| Company | Industry | Usecase | Cluster Size | (Un)Compressed Data Size<abbr title="of single replica"><sup>\*</sup></abbr> | Reference |
|
||||
|-----------------------------------------------------------------------------|---------------------------------|-----------------------|------------------------------------------------------------|------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [2gis](https://2gis.ru) | Maps | Monitoring | — | — | [Talk in Russian, July 2019](https://youtu.be/58sPkXfq6nw) |
|
||||
| [Aloha Browser](https://alohabrowser.com/) | Mobile App | Browser backend | — | — | [Slides in Russian, May 2019](https://github.com/yandex/clickhouse-presentations/blob/master/meetup22/aloha.pdf) |
|
||||
| [Amadeus](https://amadeus.com/) | Travel | Analytics | — | — | [Press Release, April 2018](https://www.altinity.com/blog/2018/4/5/amadeus-technologies-launches-investment-and-insights-tool-based-on-machine-learning-and-strategy-algorithms) |
|
||||
| [Appsflyer](https://www.appsflyer.com) | Mobile analytics | Main product | — | — | [Talk in Russian, July 2019](https://www.youtube.com/watch?v=M3wbRlcpBbY) |
|
||||
| [ArenaData](https://arenadata.tech/) | Data Platform | Main product | — | — | [Slides in Russian, December 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup38/indexes.pdf) |
|
||||
| [Badoo](https://badoo.com) | Dating | Timeseries | — | — | [Slides in Russian, December 2019](https://presentations.clickhouse.tech/meetup38/forecast.pdf) |
|
||||
| [Benocs](https://www.benocs.com/) | Network Telemetry and Analytics | Main Product | — | — | [Slides in English, October 2017](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup9/lpm.pdf) |
|
||||
| [Bloomberg](https://www.bloomberg.com/) | Finance, Media | Monitoring | 102 servers | — | [Slides, May 2018](https://www.slideshare.net/Altinity/http-analytics-for-6m-requests-per-second-using-clickhouse-by-alexander-bocharov) |
|
||||
| [Bloxy](https://bloxy.info) | Blockchain | Analytics | — | — | [Slides in Russian, August 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup17/4_bloxy.pptx) |
|
||||
| `Dataliance/UltraPower` | Telecom | Analytics | — | — | [Slides in Chinese, January 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup12/telecom.pdf) |
|
||||
| [CARTO](https://carto.com/) | Business Intelligence | Geo analytics | — | — | [Geospatial processing with Clickhouse](https://carto.com/blog/geospatial-processing-with-clickhouse/) |
|
||||
| [CERN](http://public.web.cern.ch/public/) | Research | Experiment | — | — | [Press release, April 2012](https://www.yandex.com/company/press_center/press_releases/2012/2012-04-10/) |
|
||||
| [Cisco](http://cisco.com/) | Networking | Traffic analysis | — | — | [Lightning talk, October 2019](https://youtu.be/-hI1vDR2oPY?t=5057) |
|
||||
| [Citadel Securities](https://www.citadelsecurities.com/) | Finance | — | — | — | [Contribution, March 2019](https://github.com/ClickHouse/ClickHouse/pull/4774) |
|
||||
| [Citymobil](https://city-mobil.ru) | Taxi | Analytics | — | — | [Blog Post in Russian, March 2020](https://habr.com/en/company/citymobil/blog/490660/) |
|
||||
| [ContentSquare](https://contentsquare.com) | Web analytics | Main product | — | — | [Blog post in French, November 2018](http://souslecapot.net/2018/11/21/patrick-chatain-vp-engineering-chez-contentsquare-penser-davantage-amelioration-continue-que-revolution-constante/) |
|
||||
| [Cloudflare](https://cloudflare.com) | CDN | Traffic analysis | 36 servers | — | [Blog post, May 2017](https://blog.cloudflare.com/how-cloudflare-analyzes-1m-dns-queries-per-second/), [Blog post, March 2018](https://blog.cloudflare.com/http-analytics-for-6m-requests-per-second-using-clickhouse/) |
|
||||
| [Corunet](https://coru.net/) | Analytics | Main product | — | — | [Slides in English, April 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup21/predictive_models.pdf) |
|
||||
| [CraiditX 氪信](https://creditx.com) | Finance AI | Analysis | — | — | [Slides in English, November 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup33/udf.pptx) |
|
||||
| [Criteo/Storetail](https://www.criteo.com/) | Retail | Main product | — | — | [Slides in English, October 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup18/3_storetail.pptx) |
|
||||
| [Deutsche Bank](https://db.com) | Finance | BI Analytics | — | — | [Slides in English, October 2019](https://bigdatadays.ru/wp-content/uploads/2019/10/D2-H3-3_Yakunin-Goihburg.pdf) |
|
||||
| [Diva-e](https://www.diva-e.com) | Digital consulting | Main Product | — | — | [Slides in English, September 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup29/ClickHouse-MeetUp-Unusual-Applications-sd-2019-09-17.pdf) |
|
||||
| [Exness](https://www.exness.com) | Trading | Metrics, Logging | — | — | [Talk in Russian, May 2019](https://youtu.be/_rpU-TvSfZ8?t=3215) |
|
||||
| [Geniee](https://geniee.co.jp) | Ad network | Main product | — | — | [Blog post in Japanese, July 2017](https://tech.geniee.co.jp/entry/2017/07/20/160100) |
|
||||
| [HUYA](https://www.huya.com/) | Video Streaming | Analytics | — | — | [Slides in Chinese, October 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup19/7.%20ClickHouse万亿数据分析实践%20李本旺(sundy-li)%20虎牙.pdf) |
|
||||
| [Idealista](https://www.idealista.com) | Real Estate | Analytics | — | — | [Blog Post in English, April 2019](https://clickhouse.yandex/blog/en/clickhouse-meetup-in-madrid-on-april-2-2019) |
|
||||
| [Infovista](https://www.infovista.com/) | Networks | Analytics | — | — | [Slides in English, October 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup30/infovista.pdf) |
|
||||
| [InnoGames](https://www.innogames.com) | Games | Metrics, Logging | — | — | [Slides in Russian, September 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup28/graphite_and_clickHouse.pdf) |
|
||||
| [Integros](https://integros.com) | Platform for video services | Analytics | — | — | [Slides in Russian, May 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup22/strategies.pdf) |
|
||||
| [Kodiak Data](https://www.kodiakdata.com/) | Clouds | Main product | — | — | [Slides in Engish, April 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup13/kodiak_data.pdf) |
|
||||
| [Kontur](https://kontur.ru) | Software Development | Metrics | — | — | [Talk in Russian, November 2018](https://www.youtube.com/watch?v=U4u4Bd0FtrY) |
|
||||
| [LifeStreet](https://lifestreet.com/) | Ad network | Main product | 75 servers (3 replicas) | 5.27 PiB | [Blog post in Russian, February 2017](https://habr.com/en/post/322620/) |
|
||||
| [Mail.ru Cloud Solutions](https://mcs.mail.ru/) | Cloud services | Main product | — | — | [Running ClickHouse Instance, in Russian](https://mcs.mail.ru/help/db-create/clickhouse#) |
|
||||
| [MessageBird](https://www.messagebird.com) | Telecommunications | Statistics | — | — | [Slides in English, November 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup20/messagebird.pdf) |
|
||||
| [MGID](https://www.mgid.com/) | Ad network | Web-analytics | — | — | [Our experience in implementing analytical DBMS ClickHouse, in Russian](http://gs-studio.com/news-about-it/32777----clickhouse---c) |
|
||||
| [OneAPM](https://www.oneapm.com/) | Monitorings and Data Analysis | Main product | — | — | [Slides in Chinese, October 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup19/8.%20clickhouse在OneAPM的应用%20杜龙.pdf) |
|
||||
| [Pragma Innovation](http://www.pragma-innovation.fr/) | Telemetry and Big Data Analysis | Main product | — | — | [Slides in English, October 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup18/4_pragma_innovation.pdf) |
|
||||
| [QINGCLOUD](https://www.qingcloud.com/) | Cloud services | Main product | — | — | [Slides in Chinese, October 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup19/4.%20Cloud%20%2B%20TSDB%20for%20ClickHouse%20张健%20QingCloud.pdf) |
|
||||
| [Qrator](https://qrator.net) | DDoS protection | Main product | — | — | [Blog Post, March 2019](https://blog.qrator.net/en/clickhouse-ddos-mitigation_37/) |
|
||||
| [Beijing PERCENT Information Technology Co., Ltd.](https://www.percent.cn/) | Analytics | Main Product | — | — | [Slides in Chinese, June 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup24/4.%20ClickHouse万亿数据双中心的设计与实践%20.pdf) |
|
||||
| [Rambler](https://rambler.ru) | Internet services | Analytics | — | — | [Talk in Russian, April 2018](https://medium.com/@ramblertop/разработка-api-clickhouse-для-рамблер-топ-100-f4c7e56f3141) |
|
||||
| [Tencent](https://www.tencent.com) | Messaging | Logging | — | — | [Talk in Chinese, November 2019](https://youtu.be/T-iVQRuw-QY?t=5050) |
|
||||
| [Traffic Stars](https://trafficstars.com/) | AD network | — | — | — | [Slides in Russian, May 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup15/lightning/ninja.pdf) |
|
||||
| [S7 Airlines](https://www.s7.ru) | Airlines | Metrics, Logging | — | — | [Talk in Russian, March 2019](https://www.youtube.com/watch?v=nwG68klRpPg&t=15s) |
|
||||
| [SEMrush](https://www.semrush.com/) | Marketing | Main product | — | — | [Slides in Russian, August 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup17/5_semrush.pdf) |
|
||||
| [scireum GmbH](https://www.scireum.de/) | e-Commerce | Main product | — | — | [Talk in German, February 2020](https://www.youtube.com/watch?v=7QWAn5RbyR4) |
|
||||
| [Sentry](https://sentry.io/) | Software developer | Backend for product | — | — | [Blog Post in English, May 2019](https://blog.sentry.io/2019/05/16/introducing-snuba-sentrys-new-search-infrastructure) |
|
||||
| [SGK](http://www.sgk.gov.tr/wps/portal/sgk/tr) | Goverment Social Security | Analytics | — | — | [Slides in English, November 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup35/ClickHouse%20Meetup-Ramazan%20POLAT.pdf) |
|
||||
| [seo.do](https://seo.do/) | Analytics | Main product | — | — | [Slides in English, November 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup35/CH%20Presentation-%20Metehan%20Çetinkaya.pdf) |
|
||||
| [Sina](http://english.sina.com/index.html) | News | — | — | — | [Slides in Chinese, October 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup19/6.%20ClickHouse最佳实践%20高鹏_新浪.pdf) |
|
||||
| [SMI2](https://smi2.ru/) | News | Analytics | — | — | [Blog Post in Russian, November 2017](https://habr.com/ru/company/smi2/blog/314558/) |
|
||||
| [Splunk](https://www.splunk.com/) | Business Analytics | Main product | — | — | [Slides in English, January 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup12/splunk.pdf) |
|
||||
| [Spotify](https://www.spotify.com) | Music | Experimentation | — | — | [Slides, July 2018](https://www.slideshare.net/glebus/using-clickhouse-for-experimentation-104247173) |
|
||||
| [Tencent](https://www.tencent.com) | Big Data | Data processing | — | — | [Slides in Chinese, October 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup19/5.%20ClickHouse大数据集群应用_李俊飞腾讯网媒事业部.pdf) |
|
||||
| [Uber](https://www.uber.com) | Taxi | Logging | — | — | [Slides, February 2020](https://presentations.clickhouse.tech/meetup40/uber.pdf) |
|
||||
| [VKontakte](https://vk.com) | Social Network | Statistics, Logging | — | — | [Slides in Russian, August 2018](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup17/3_vk.pdf) |
|
||||
| [Wisebits](https://wisebits.com/) | IT Solutions | Analytics | — | — | [Slides in Russian, May 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup22/strategies.pdf) |
|
||||
| [Xiaoxin Tech.](https://www.xiaoheiban.cn/) | Education | Common purpose | — | — | [Slides in English, November 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup33/sync-clickhouse-with-mysql-mongodb.pptx) |
|
||||
| [Ximalaya](https://www.ximalaya.com/) | Audio sharing | OLAP | — | — | [Slides in English, November 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup33/ximalaya.pdf) |
|
||||
| [Yandex Cloud](https://cloud.yandex.ru/services/managed-clickhouse) | Public Cloud | Main product | — | — | [Talk in Russian, December 2019](https://www.youtube.com/watch?v=pgnak9e_E0o) |
|
||||
| [Yandex DataLens](https://cloud.yandex.ru/services/datalens) | Business Intelligence | Main product | — | — | [Slides in Russian, December 2019](https://presentations.clickhouse.tech/meetup38/datalens.pdf) |
|
||||
| [Yandex Market](https://market.yandex.ru/) | e-Commerce | Metrics, Logging | — | — | [Talk in Russian, January 2019](https://youtu.be/_l1qP0DyBcA?t=478) |
|
||||
| [Yandex Metrica](https://metrica.yandex.com) | Web analytics | Main product | 360 servers in one cluster, 1862 servers in one department | 66.41 PiB / 5.68 PiB | [Slides, February 2020](https://presentations.clickhouse.tech/meetup40/introduction/#13) |
|
||||
| [ЦВТ](https://htc-cs.ru/) | Software Development | Metrics, Logging | — | — | [Blog Post, March 2019, in Russian](https://vc.ru/dev/62715-kak-my-stroili-monitoring-na-prometheus-clickhouse-i-elk) |
|
||||
| [МКБ](https://mkb.ru/) | Bank | Web-system monitoring | — | — | [Slides in Russian, September 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup28/mkb.pdf) |
|
||||
| [金数据](https://jinshuju.net) | BI Analytics | Main product | — | — | [Slides in Chinese, October 2019](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup24/3.%20金数据数据架构调整方案Public.pdf) |
|
||||
| Компания | Промышленность | Usecase | Размер кластера | (Un)Сжатый Размер Данных<abbr title="of single replica"><sup>\*</sup></abbr> | Ссылка |
|
||||
|---------------------------------------------------------------------------------|----------------------------------------|-----------------------------|------------------------------------------------------------|------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [2ГИС](https://2gis.ru) | Карты | Мониторинг | — | — | [Говорить по-русски, июль 2019](https://youtu.be/58sPkXfq6nw) |
|
||||
| [Браузер Aloha](https://alohabrowser.com/) | Мобильное приложение | Серверная часть браузера | — | — | [Слайды на русском языке, май 2019 года](https://github.com/yandex/clickhouse-presentations/blob/master/meetup22/aloha.pdf) |
|
||||
| [Компания Amadeus](https://amadeus.com/) | Путешествовать | Аналитика | — | — | [Пресс-Релиз, Апрель 2018 Года](https://www.altinity.com/blog/2018/4/5/amadeus-technologies-launches-investment-and-insights-tool-based-on-machine-learning-and-strategy-algorithms) |
|
||||
| [Компания](https://www.appsflyer.com) | Мобильная аналитика | Главный продукт | — | — | [Говорить по-русски, июль 2019](https://www.youtube.com/watch?v=M3wbRlcpBbY) |
|
||||
| [ArenaData](https://arenadata.tech/) | Платформа данных | Главный продукт | — | — | [Слайды на русском языке, декабрь 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup38/indexes.pdf) |
|
||||
| [На Badoo](https://badoo.com) | Знакомства | Таймсерии | — | — | [Слайды на русском языке, декабрь 2019 года](https://presentations.clickhouse.tech/meetup38/forecast.pdf) |
|
||||
| [Бенокс](https://www.benocs.com/) | Сетевая телеметрия и аналитика | Главный продукт | — | — | [Слайды на английском языке, октябрь 2017 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup9/lpm.pdf) |
|
||||
| [Блумберг](https://www.bloomberg.com/) | Финансы, СМИ | Мониторинг | 102 сервера | — | [Слайды, Май 2018 Года](https://www.slideshare.net/Altinity/http-analytics-for-6m-requests-per-second-using-clickhouse-by-alexander-bocharov) |
|
||||
| [Блокси](https://bloxy.info) | Блокчейн | Аналитика | — | — | [Слайды на русском языке, август 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup17/4_bloxy.pptx) |
|
||||
| `Dataliance/UltraPower` | Телекоммуникационный | Аналитика | — | — | [Слайды на китайском языке, январь 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup12/telecom.pdf) |
|
||||
| [CARTO](https://carto.com/) | Бизнес-разведка | Гео аналитика | — | — | [Геопространственная обработка с помощью Clickhouse](https://carto.com/blog/geospatial-processing-with-clickhouse/) |
|
||||
| [CERN](http://public.web.cern.ch/public/) | Исследование | Эксперимент | — | — | [Пресс-релиз, апрель 2012 года](https://www.yandex.com/company/press_center/press_releases/2012/2012-04-10/) |
|
||||
| [Компании Cisco](http://cisco.com/) | Сетевой | Анализ трафика | — | — | [Молниеносный разговор, октябрь 2019 года](https://youtu.be/-hI1vDR2oPY?t=5057) |
|
||||
| [Ценные Бумаги Цитадели](https://www.citadelsecurities.com/) | Финансы | — | — | — | [Взнос, Март 2019 Года](https://github.com/ClickHouse/ClickHouse/pull/4774) |
|
||||
| [Ситимобил](https://city-mobil.ru) | Такси | Аналитика | — | — | [Запись в блоге на русском языке, март 2020 года](https://habr.com/en/company/citymobil/blog/490660/) |
|
||||
| [ContentSquare](https://contentsquare.com) | Веб-аналитика | Главный продукт | — | — | [Запись в блоге на французском языке, ноябрь 2018 года](http://souslecapot.net/2018/11/21/patrick-chatain-vp-engineering-chez-contentsquare-penser-davantage-amelioration-continue-que-revolution-constante/) |
|
||||
| [Cloudflare](https://cloudflare.com) | CDN | Анализ трафика | 36 серверов | — | [Сообщение в блоге, май 2017 года](https://blog.cloudflare.com/how-cloudflare-analyzes-1m-dns-queries-per-second/), [Сообщение в блоге, март 2018 года](https://blog.cloudflare.com/http-analytics-for-6m-requests-per-second-using-clickhouse/) |
|
||||
| [Корунет](https://coru.net/) | Аналитика | Главный продукт | — | — | [Слайды на английском языке, апрель 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup21/predictive_models.pdf) |
|
||||
| [CraiditX 氪信](https://creditx.com) | Финансовый ИИ | Анализ | — | — | [Слайды на английском языке, ноябрь 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup33/udf.pptx) |
|
||||
| [Criteo / Storetail](https://www.criteo.com/) | Розничная торговля | Главный продукт | — | — | [Слайды на английском языке, октябрь 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup18/3_storetail.pptx) |
|
||||
| [Дойче банк](https://db.com) | Финансы | Би аналитика | — | — | [Слайды на английском языке, октябрь 2019 года](https://bigdatadays.ru/wp-content/uploads/2019/10/D2-H3-3_Yakunin-Goihburg.pdf) |
|
||||
| [Дива-е](https://www.diva-e.com) | Цифровой Консалтинг | Главный продукт | — | — | [Слайды на английском языке, сентябрь 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup29/ClickHouse-MeetUp-Unusual-Applications-sd-2019-09-17.pdf) |
|
||||
| [Компания Exness](https://www.exness.com) | Торговый | Метрики, Ведение Журнала | — | — | [Разговор на русском языке, май 2019 года](https://youtu.be/_rpU-TvSfZ8?t=3215) |
|
||||
| [Джинн](https://geniee.co.jp) | Рекламная сеть | Главный продукт | — | — | [Запись в блоге на японском языке, июль 2017 года](https://tech.geniee.co.jp/entry/2017/07/20/160100) |
|
||||
| [HUYA](https://www.huya.com/) | Потоковое видео | Аналитика | — | — | [Слайды на китайском языке, октябрь 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup19/7.%20ClickHouse万亿数据分析实践%20李本旺(sundy-li)%20虎牙.pdf) |
|
||||
| [Идеалиста](https://www.idealista.com) | Недвижимость | Аналитика | — | — | [Сообщение в блоге на английском языке, апрель 2019 года](https://clickhouse.yandex/blog/en/clickhouse-meetup-in-madrid-on-april-2-2019) |
|
||||
| [Infovista](https://www.infovista.com/) | Сети | Аналитика | — | — | [Слайды на английском языке, октябрь 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup30/infovista.pdf) |
|
||||
| [Компания innogames](https://www.innogames.com) | Игры | Метрики, Ведение Журнала | — | — | [Слайды на русском языке, сентябрь 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup28/graphite_and_clickHouse.pdf) |
|
||||
| [Интегрос](https://integros.com) | Платформа для видеосервисов | Аналитика | — | — | [Слайды на русском языке, май 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup22/strategies.pdf) |
|
||||
| [Данные По Кадьяку](https://www.kodiakdata.com/) | Облака | Главный продукт | — | — | [Слайды на английском языке, апрель 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup13/kodiak_data.pdf) |
|
||||
| [Контур](https://kontur.ru) | Разработка программного обеспечения | Метрика | — | — | [Говорить по-русски, ноябрь 2018](https://www.youtube.com/watch?v=U4u4Bd0FtrY) |
|
||||
| [LifeStreet](https://lifestreet.com/) | Рекламная сеть | Главный продукт | 75 серверов (3 реплики) | 5.27 ПИБ | [Запись в блоге на русском языке, февраль 2017 года](https://habr.com/en/post/322620/) |
|
||||
| [Mail.ru Облачные Решения](https://mcs.mail.ru/) | Облачные сервисы | Главный продукт | — | — | [Запуск экземпляра ClickHouse на русском языке](https://mcs.mail.ru/help/db-create/clickhouse#) |
|
||||
| [MessageBird](https://www.messagebird.com) | Электросвязь | Статистика | — | — | [Слайды на английском языке, ноябрь 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup20/messagebird.pdf) |
|
||||
| [MGID](https://www.mgid.com/) | Рекламная сеть | Веб-аналитика | — | — | [Наш опыт внедрения аналитической СУБД ClickHouse на русском языке](http://gs-studio.com/news-about-it/32777----clickhouse---c) |
|
||||
| [OneAPM](https://www.oneapm.com/) | Мониторинг и анализ данных | Главный продукт | — | — | [Слайды на китайском языке, октябрь 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup19/8.%20clickhouse在OneAPM的应用%20杜龙.pdf) |
|
||||
| [ПРАГМА Инноваций](http://www.pragma-innovation.fr/) | Телеметрия и анализ Больших Данных | Главный продукт | — | — | [Слайды на английском языке, октябрь 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup18/4_pragma_innovation.pdf) |
|
||||
| [QINGCLOUD](https://www.qingcloud.com/) | Облачные сервисы | Главный продукт | — | — | [Слайды на китайском языке, октябрь 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup19/4.%20Cloud%20%2B%20TSDB%20for%20ClickHouse%20张健%20QingCloud.pdf) |
|
||||
| [Qrator](https://qrator.net) | Защита от DDoS-атак | Главный продукт | — | — | [Сообщение В Блоге, Март 2019 Года](https://blog.qrator.net/en/clickhouse-ddos-mitigation_37/) |
|
||||
| [Beijing PERCENT Information Technology Co., Лимитед.](https://www.percent.cn/) | Аналитика | Главный продукт | — | — | [Слайды на китайском языке, июнь 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup24/4.%20ClickHouse万亿数据双中心的设计与实践%20.pdf) |
|
||||
| [Бродяга](https://rambler.ru) | Интернет услуги | Аналитика | — | — | [Говорить по-русски, апрель 2018](https://medium.com/@ramblertop/разработка-api-clickhouse-для-рамблер-топ-100-f4c7e56f3141) |
|
||||
| [Tencent](https://www.tencent.com) | Обмен сообщениями | Регистрация | — | — | [Говорить по-китайски, ноябрь 2019](https://youtu.be/T-iVQRuw-QY?t=5050) |
|
||||
| [Движения Звезд](https://trafficstars.com/) | Рекламная сеть | — | — | — | [Слайды на русском языке, май 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup15/lightning/ninja.pdf) |
|
||||
| [S7 Airlines](https://www.s7.ru) | Авиакомпании | Метрики, Ведение Журнала | — | — | [Разговор на русском языке, март 2019 года](https://www.youtube.com/watch?v=nwG68klRpPg&t=15s) |
|
||||
| [Общий](https://www.semrush.com/) | Маркетинг | Главный продукт | — | — | [Слайды на русском языке, август 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup17/5_semrush.pdf) |
|
||||
| [scireum ГмбХ](https://www.scireum.de/) | электронная коммерция | Главный продукт | — | — | [Говорить по-немецки, февраль 2020](https://www.youtube.com/watch?v=7QWAn5RbyR4) |
|
||||
| [Караул](https://sentry.io/) | Разработчик | Бэкэнд для продукта | — | — | [Сообщение в блоге на английском языке, май 2019 года](https://blog.sentry.io/2019/05/16/introducing-snuba-sentrys-new-search-infrastructure) |
|
||||
| [SGK](http://www.sgk.gov.tr/wps/portal/sgk/tr) | Государственное Социальное Обеспечение | Аналитика | — | — | [Слайды на английском языке, ноябрь 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup35/ClickHouse%20Meetup-Ramazan%20POLAT.pdf) |
|
||||
| [СЕО.делать](https://seo.do/) | Аналитика | Главный продукт | — | — | [Слайды на английском языке, ноябрь 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup35/CH%20Presentation-%20Metehan%20Çetinkaya.pdf) |
|
||||
| [Зина](http://english.sina.com/index.html) | Новости | — | — | — | [Слайды на китайском языке, октябрь 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup19/6.%20ClickHouse最佳实践%20高鹏_新浪.pdf) |
|
||||
| [SMI2](https://smi2.ru/) | Новости | Аналитика | — | — | [Запись в блоге на русском языке, ноябрь 2017 года](https://habr.com/ru/company/smi2/blog/314558/) |
|
||||
| [Чмок](https://www.splunk.com/) | Бизнес-аналитика | Главный продукт | — | — | [Слайды на английском языке, январь 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup12/splunk.pdf) |
|
||||
| [Спотифай](https://www.spotify.com) | Музыка | Экспериментирование | — | — | [Слайды, Июль 2018 Года](https://www.slideshare.net/glebus/using-clickhouse-for-experimentation-104247173) |
|
||||
| [Tencent](https://www.tencent.com) | Большие данные | Обработка данных | — | — | [Слайды на китайском языке, октябрь 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup19/5.%20ClickHouse大数据集群应用_李俊飞腾讯网媒事业部.pdf) |
|
||||
| [Убер](https://www.uber.com) | Такси | Регистрация | — | — | [Слайды, Февраль 2020 Года](https://presentations.clickhouse.tech/meetup40/uber.pdf) |
|
||||
| [ВКонтакте](https://vk.com) | Социальная сеть | Статистика, Ведение Журнала | — | — | [Слайды на русском языке, август 2018 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup17/3_vk.pdf) |
|
||||
| [Мудрецы](https://wisebits.com/) | IT-решение | Аналитика | — | — | [Слайды на русском языке, май 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup22/strategies.pdf) |
|
||||
| [Технология Сяосин.](https://www.xiaoheiban.cn/) | Образование | Общая цель | — | — | [Слайды на английском языке, ноябрь 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup33/sync-clickhouse-with-mysql-mongodb.pptx) |
|
||||
| [Сималайя](https://www.ximalaya.com/) | Общий доступ к аудио | OLAP | — | — | [Слайды на английском языке, ноябрь 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup33/ximalaya.pdf) |
|
||||
| [Облако Яндекса](https://cloud.yandex.ru/services/managed-clickhouse) | Публичное Облако | Главный продукт | — | — | [Разговор на русском языке, декабрь 2019 года](https://www.youtube.com/watch?v=pgnak9e_E0o) |
|
||||
| [DataLens Яндекс ](https://cloud.yandex.ru/services/datalens) | Бизнес-разведка | Главный продукт | — | — | [Слайды на русском языке, декабрь 2019 года](https://presentations.clickhouse.tech/meetup38/datalens.pdf) |
|
||||
| [Яндекс Маркет](https://market.yandex.ru/) | электронная коммерция | Метрики, Ведение Журнала | — | — | [Разговор на русском языке, январь 2019 года](https://youtu.be/_l1qP0DyBcA?t=478) |
|
||||
| [Яндекс Метрика](https://metrica.yandex.com) | Веб-аналитика | Главный продукт | 360 серверов в одном кластере, 1862 сервера в одном отделе | 66.41 ПИБ / 5.68 ПИБ | [Слайды, Февраль 2020 Года](https://presentations.clickhouse.tech/meetup40/introduction/#13) |
|
||||
| [ЦВТ](https://htc-cs.ru/) | Разработка программного обеспечения | Метрики, Ведение Журнала | — | — | [Сообщение в блоге, март 2019 года, на русском языке](https://vc.ru/dev/62715-kak-my-stroili-monitoring-na-prometheus-clickhouse-i-elk) |
|
||||
| [МКБ](https://mkb.ru/) | Банк | Мониторинг веб-систем | — | — | [Слайды на русском языке, сентябрь 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup28/mkb.pdf) |
|
||||
| [金数据](https://jinshuju.net) | Би аналитика | Главный продукт | — | — | [Слайды на китайском языке, октябрь 2019 года](https://github.com/ClickHouse/clickhouse-presentations/blob/master/meetup24/3.%20金数据数据架构调整方案Public.pdf) |
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/introduction/adopters/) <!--hide-->
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/en/introduction/adopters/) <!--hide-->
|
||||
|
||||
@ -59,6 +59,6 @@ ClickHouse предоставляет различные способы разм
|
||||
|
||||
Используется асинхронная multimaster репликация. После записи на любую доступную реплику, данные распространяются на все остальные реплики в фоне. Система поддерживает полную идентичность данных на разных репликах. Восстановление после большинства сбоев осуществляется автоматически, а в сложных случаях — полуавтоматически. При необходимости, можно [включить кворумную запись](../operations/settings/settings.md) данных.
|
||||
|
||||
Подробнее смотрите раздел [Репликация данных](../operations/table_engines/replication.md).
|
||||
Подробнее смотрите раздел [Репликация данных](../engines/table_engines/mergetree_family/replication.md).
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/introduction/distinctive_features/) <!--hide-->
|
||||
|
||||
6
docs/ru/introduction/index.md
Normal file
6
docs/ru/introduction/index.md
Normal file
@ -0,0 +1,6 @@
|
||||
---
|
||||
toc_folder_title: Introduction
|
||||
toc_priority: 1
|
||||
---
|
||||
|
||||
|
||||
@ -61,7 +61,7 @@
|
||||
|
||||
Здесь видно объявление двух пользователей - `default` и `web`. Пользователя `web` мы добавили самостоятельно.
|
||||
|
||||
Пользователь `default` выбирается в случаях, когда имя пользователя не передаётся. Также пользователь `default` может использоваться при распределённой обработке запроса - если в конфигурации кластера для сервера не указаны `user` и `password`. (см. раздел о движке [Distributed](../operations/table_engines/distributed.md)).
|
||||
Пользователь `default` выбирается в случаях, когда имя пользователя не передаётся. Также пользователь `default` может использоваться при распределённой обработке запроса - если в конфигурации кластера для сервера не указаны `user` и `password`. (см. раздел о движке [Distributed](../engines/table_engines/special/distributed.md)).
|
||||
|
||||
Пользователь, который используется для обмена информацией между серверами, объединенными в кластер, не должен иметь существенных ограничений или квот - иначе распределённые запросы сломаются.
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Резервное копирование данных {#rezervnoe-kopirovanie-dannykh}
|
||||
|
||||
[Репликация](table_engines/replication.md) обеспечивает защиту от аппаратных сбоев, но не защищает от человеческих ошибок: случайного удаления данных, удаления не той таблицы, которую надо было, или таблицы на не том кластере, а также программных ошибок, которые приводят к неправильной обработке данных или их повреждению. Во многих случаях подобные ошибки влияют на все реплики. ClickHouse имеет встроенные средства защиты для предотвращения некоторых типов ошибок — например, по умолчанию [не получится удалить таблицы \*MergeTree, содержащие более 50 Гб данных, одной командой](https://github.com/ClickHouse/ClickHouse/blob/v18.14.18-stable/programs/server/config.xml#L322-L330). Однако эти средства защиты не охватывают все возможные случаи и могут быть обойдены.
|
||||
[Репликация](../engines/table_engines/mergetree_family/replication.md) обеспечивает защиту от аппаратных сбоев, но не защищает от человеческих ошибок: случайного удаления данных, удаления не той таблицы, которую надо было, или таблицы на не том кластере, а также программных ошибок, которые приводят к неправильной обработке данных или их повреждению. Во многих случаях подобные ошибки влияют на все реплики. ClickHouse имеет встроенные средства защиты для предотвращения некоторых типов ошибок — например, по умолчанию [не получится удалить таблицы \*MergeTree, содержащие более 50 Гб данных, одной командой](https://github.com/ClickHouse/ClickHouse/blob/v18.14.18-stable/programs/server/config.xml#L322-L330). Однако эти средства защиты не охватывают все возможные случаи и могут быть обойдены.
|
||||
|
||||
Для того чтобы эффективно уменьшить возможные человеческие ошибки, следует тщательно подготовить стратегию резервного копирования и восстановления данных **заранее**.
|
||||
|
||||
@ -15,11 +15,11 @@
|
||||
|
||||
## Снимки файловой системы {#snimki-failovoi-sistemy}
|
||||
|
||||
Некоторые локальные файловые системы позволяют делать снимки (например, [ZFS](https://en.wikipedia.org/wiki/ZFS)), но они могут быть не лучшим выбором для обслуживания живых запросов. Возможным решением является создание дополнительных реплик с такой файловой системой и исключение их из [Distributed](table_engines/distributed.md) таблиц, используемых для запросов `SELECT`. Снимки на таких репликах будут недоступны для запросов, изменяющих данные. В качестве бонуса, эти реплики могут иметь особые конфигурации оборудования с большим количеством дисков, подключенных к серверу, что будет экономически эффективным.
|
||||
Некоторые локальные файловые системы позволяют делать снимки (например, [ZFS](https://en.wikipedia.org/wiki/ZFS)), но они могут быть не лучшим выбором для обслуживания живых запросов. Возможным решением является создание дополнительных реплик с такой файловой системой и исключение их из [Distributed](../engines/table_engines/special/distributed.md) таблиц, используемых для запросов `SELECT`. Снимки на таких репликах будут недоступны для запросов, изменяющих данные. В качестве бонуса, эти реплики могут иметь особые конфигурации оборудования с большим количеством дисков, подключенных к серверу, что будет экономически эффективным.
|
||||
|
||||
## clickhouse-copier {#clickhouse-copier}
|
||||
|
||||
[clickhouse-copier](utils/clickhouse-copier.md) — это универсальный инструмент, который изначально был создан для перешардирования таблиц с петабайтами данных. Его также можно использовать для резервного копирования и восстановления, поскольку он надёжно копирует данные между таблицами и кластерами ClickHouse.
|
||||
[clickhouse-copier](utilities/clickhouse-copier.md) — это универсальный инструмент, который изначально был создан для перешардирования таблиц с петабайтами данных. Его также можно использовать для резервного копирования и восстановления, поскольку он надёжно копирует данные между таблицами и кластерами ClickHouse.
|
||||
|
||||
Для небольших объёмов данных можно применять `INSERT INTO ... SELECT ...` в удалённые таблицы.
|
||||
|
||||
@ -27,7 +27,7 @@
|
||||
|
||||
ClickHouse позволяет использовать запрос `ALTER TABLE ... FREEZE PARTITION ...` для создания локальной копии партиций таблицы. Это реализуется с помощью жестких ссылок (hardlinks) на каталог `/var/lib/clickhouse/shadow/`, поэтому такая копия обычно не занимает дополнительное место на диске для старых данных. Созданные копии файлов не обрабатываются сервером ClickHouse, поэтому вы можете просто оставить их там: у вас будет простая резервная копия, которая не требует дополнительной внешней системы, однако при аппаратных проблемах вы можете утратить и актуальные данные и сохраненную копию. По этой причине, лучше удаленно скопировать их в другое место, а затем удалить локальную копию. Распределенные файловые системы и хранилища объектов по-прежнему являются хорошими вариантами для этого, однако можно использовать и обычные присоединенные файловые серверы с достаточно большой ёмкостью (в этом случае передача будет происходить через сетевую файловую систему или, возможно, [rsync](https://en.wikipedia.org/wiki/Rsync)).
|
||||
|
||||
Дополнительные сведения о запросах, связанных с манипуляциями партициями, см. в разделе [ALTER](../query_language/alter.md#alter_manipulations-with-partitions).
|
||||
Дополнительные сведения о запросах, связанных с манипуляциями партициями, см. в разделе [ALTER](../sql_reference/statements/alter.md#alter_manipulations-with-partitions).
|
||||
|
||||
Для автоматизации этого подхода доступен инструмент от сторонних разработчиков: [clickhouse-backup](https://github.com/AlexAkulov/clickhouse-backup).
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@
|
||||
|
||||
Если указано `remove` - удалить элемент.
|
||||
|
||||
Также в конфиге могут быть указаны «подстановки». Если у элемента присутствует атрибут `incl`, то в качестве значения будет использована соответствующая подстановка из файла. По умолчанию, путь к файлу с подстановками - `/etc/metrika.xml`. Он может быть изменён в конфигурации сервера в элементе [include\_from](server_settings/settings.md#server_settings-include_from). Значения подстановок указываются в элементах `/yandex/имя_подстановки` этого файла. Если подстановка, заданная в `incl` отсутствует, то в лог попадает соответствующая запись. Чтобы ClickHouse не писал в лог об отсутствии подстановки, необходимо указать атрибут `optional="true"` (например, настройка [macros](server_settings/settings.md)).
|
||||
Также в конфиге могут быть указаны «подстановки». Если у элемента присутствует атрибут `incl`, то в качестве значения будет использована соответствующая подстановка из файла. По умолчанию, путь к файлу с подстановками - `/etc/metrika.xml`. Он может быть изменён в конфигурации сервера в элементе [include\_from](server_configuration_parameters/settings.md#server_configuration_parameters-include_from). Значения подстановок указываются в элементах `/yandex/имя_подстановки` этого файла. Если подстановка, заданная в `incl` отсутствует, то в лог попадает соответствующая запись. Чтобы ClickHouse не писал в лог об отсутствии подстановки, необходимо указать атрибут `optional="true"` (например, настройка [macros](server_configuration_parameters/settings.md)).
|
||||
|
||||
Подстановки могут также выполняться из ZooKeeper. Для этого укажите у элемента атрибут `from_zk = "/path/to/node"`. Значение элемента заменится на содержимое узла `/path/to/node` в ZooKeeper. В ZooKeeper-узел также можно положить целое XML-поддерево, оно будет целиком вставлено в исходный элемент.
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@
|
||||
- [Конфигурационные файлы](configuration_files.md)
|
||||
- [Квоты](quotas.md)
|
||||
- [Системные таблицы](system_tables.md)
|
||||
- [Конфигурационные параметры сервера](server_settings/index.md)
|
||||
- [Конфигурационные параметры сервера](server_configuration_parameters/index.md)
|
||||
- [Тестирование севреров с помощью ClickHouse](performance_test.md)
|
||||
- [Настройки](settings/index.md)
|
||||
- [Утилиты](utils/index.md)
|
||||
|
||||
@ -21,7 +21,7 @@ ClickHouse не отслеживает состояние аппаратных
|
||||
|
||||
Сервер ClickHouse имеет встроенные инструменты мониторинга.
|
||||
|
||||
Для отслеживания событий на сервере используйте логи. Подробнее смотрите в разделе конфигурационного файла [logger](server_settings/settings.md#server_settings-logger).
|
||||
Для отслеживания событий на сервере используйте логи. Подробнее смотрите в разделе конфигурационного файла [logger](server_configuration_parameters/settings.md#server_configuration_parameters-logger).
|
||||
|
||||
ClickHouse собирает:
|
||||
|
||||
@ -30,7 +30,7 @@ ClickHouse собирает:
|
||||
|
||||
Метрики находятся в таблицах [system.metrics](system_tables.md#system_tables-metrics), [system.events](system_tables.md#system_tables-events) и [system.asynchronous\_metrics](system_tables.md#system_tables-asynchronous_metrics).
|
||||
|
||||
Можно настроить экспорт метрик из ClickHouse в [Graphite](https://github.com/graphite-project). Смотрите секцию [graphite](server_settings/settings.md#server_settings-graphite) конфигурационного файла ClickHouse. Перед настройкой экспорта метрик необходимо настроить Graphite, как указано в [официальном руководстве](https://graphite.readthedocs.io/en/latest/install.html).
|
||||
Можно настроить экспорт метрик из ClickHouse в [Graphite](https://github.com/graphite-project). Смотрите секцию [graphite](server_configuration_parameters/settings.md#server_configuration_parameters-graphite) конфигурационного файла ClickHouse. Перед настройкой экспорта метрик необходимо настроить Graphite, как указано в [официальном руководстве](https://graphite.readthedocs.io/en/latest/install.html).
|
||||
|
||||
Также, можно отслеживать доступность сервера через HTTP API. Отправьте `HTTP GET` к ресурсу `/ping`. Если сервер доступен, он отвечает `200 OK`.
|
||||
|
||||
|
||||
5
docs/ru/operations/optimizing_performance/index.md
Normal file
5
docs/ru/operations/optimizing_performance/index.md
Normal file
@ -0,0 +1,5 @@
|
||||
---
|
||||
toc_folder_title: Optimizing Performance
|
||||
toc_priority: 52
|
||||
---
|
||||
|
||||
@ -0,0 +1,62 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 1cd5f0028d917696daf71ac1c9ee849c99c1d5c8
|
||||
---
|
||||
|
||||
# Выборки Профилировщик Запросов {#sampling-query-profiler}
|
||||
|
||||
ClickHouse запускает профилировщик выборок, который позволяет анализировать выполнение запросов. С помощью profiler можно найти подпрограммы исходного кода, которые наиболее часто используются во время выполнения запроса. Вы можете отслеживать процессорное время и время работы настенных часов, включая время простоя.
|
||||
|
||||
Чтобы использовать профилировщик:
|
||||
|
||||
- Настройка программы [журнал трассировки](../server_configuration_parameters/settings.md#server_configuration_parameters-trace_log) раздел конфигурации сервера.
|
||||
|
||||
В этом разделе настраиваются следующие параметры: [журнал трассировки](../../operations/optimizing_performance/sampling_query_profiler.md#system_tables-trace_log) системная таблица, содержащая результаты работы профилировщика. Он настроен по умолчанию. Помните, что данные в этой таблице действительны только для работающего сервера. После перезагрузки сервера ClickHouse не очищает таблицу, и все сохраненные адреса виртуальной памяти могут стать недействительными.
|
||||
|
||||
- Настройка программы [query\_profiler\_cpu\_time\_period\_ns](../settings/settings.md#query_profiler_cpu_time_period_ns) или [query\_profiler\_real\_time\_period\_ns](../settings/settings.md#query_profiler_real_time_period_ns) настройки. Обе настройки можно использовать одновременно.
|
||||
|
||||
Эти параметры позволяют настроить таймеры профилировщика. Поскольку это параметры сеанса, вы можете получить различную частоту дискретизации для всего сервера, отдельных пользователей или профилей пользователей, для вашего интерактивного сеанса и для каждого отдельного запроса.
|
||||
|
||||
Частота дискретизации по умолчанию составляет одну выборку в секунду, и включены как ЦП, так и реальные таймеры. Эта частота позволяет собрать достаточно информации о кластере ClickHouse. В то же время, работая с такой частотой, профилировщик не влияет на производительность сервера ClickHouse. Если вам нужно профилировать каждый отдельный запрос, попробуйте использовать более высокую частоту дискретизации.
|
||||
|
||||
Для того чтобы проанализировать `trace_log` системная таблица:
|
||||
|
||||
- Установите устройство `clickhouse-common-static-dbg` пакет. Видеть [Установка из пакетов DEB](../../getting_started/install.md#install-from-deb-packages).
|
||||
|
||||
- Разрешить функции самоанализа с помощью [allow\_introspection\_functions](../settings/settings.md#settings-allow_introspection_functions) установка.
|
||||
|
||||
По соображениям безопасности функции самоанализа по умолчанию отключены.
|
||||
|
||||
- Используйте `addressToLine`, `addressToSymbol` и `demangle` [функции самоанализа](../../operations/optimizing_performance/sampling_query_profiler.md) чтобы получить имена функций и их позиции в коде ClickHouse. Чтобы получить профиль для какого-либо запроса, вам необходимо агрегировать данные из `trace_log` стол. Вы можете агрегировать данные по отдельным функциям или по всем трассировкам стека.
|
||||
|
||||
Если вам нужно визуализировать `trace_log` информация, попробуйте [огнемет](../../interfaces/third-party/gui/#clickhouse-flamegraph) и [speedscope](https://github.com/laplab/clickhouse-speedscope).
|
||||
|
||||
## Пример {#example}
|
||||
|
||||
В этом примере мы:
|
||||
|
||||
- Фильтрация `trace_log` данные по идентификатору запроса и текущей дате.
|
||||
|
||||
- Агрегирование по трассировке стека.
|
||||
|
||||
- Используя функции интроспекции, мы получим отчет о:
|
||||
|
||||
- Имена символов и соответствующие им функции исходного кода.
|
||||
- Расположение исходных кодов этих функций.
|
||||
|
||||
<!-- -->
|
||||
|
||||
``` sql
|
||||
SELECT
|
||||
count(),
|
||||
arrayStringConcat(arrayMap(x -> concat(demangle(addressToSymbol(x)), '\n ', addressToLine(x)), trace), '\n') AS sym
|
||||
FROM system.trace_log
|
||||
WHERE (query_id = 'ebca3574-ad0a-400a-9cbc-dca382f5998c') AND (event_date = today())
|
||||
GROUP BY trace
|
||||
ORDER BY count() DESC
|
||||
LIMIT 10
|
||||
```
|
||||
|
||||
``` text
|
||||
{% include "operations/performance/sampling_query_profiler_example_result.txt" %}
|
||||
```
|
||||
@ -1,61 +0,0 @@
|
||||
---
|
||||
en_copy: true
|
||||
---
|
||||
|
||||
# Sampling Query Profiler {#sampling-query-profiler}
|
||||
|
||||
ClickHouse runs sampling profiler that allows analyzing query execution. Using profiler you can find source code routines that used the most frequently during query execution. You can trace CPU time and wall-clock time spent including idle time.
|
||||
|
||||
To use profiler:
|
||||
|
||||
- Setup the [trace\_log](../server_settings/settings.md#server_settings-trace_log) section of the server configuration.
|
||||
|
||||
This section configures the [trace\_log](../system_tables.md#system_tables-trace_log) system table containing the results of the profiler functioning. It is configured by default. Remember that data in this table is valid only for a running server. After the server restart, ClickHouse doesn’t clean up the table and all the stored virtual memory address may become invalid.
|
||||
|
||||
- Setup the [query\_profiler\_cpu\_time\_period\_ns](../settings/settings.md#query_profiler_cpu_time_period_ns) or [query\_profiler\_real\_time\_period\_ns](../settings/settings.md#query_profiler_real_time_period_ns) settings. Both settings can be used simultaneously.
|
||||
|
||||
These settings allow you to configure profiler timers. As these are the session settings, you can get different sampling frequency for the whole server, individual users or user profiles, for your interactive session, and for each individual query.
|
||||
|
||||
The default sampling frequency is one sample per second and both CPU and real timers are enabled. This frequency allows collecting enough information about ClickHouse cluster. At the same time, working with this frequency, profiler doesn’t affect ClickHouse server’s performance. If you need to profile each individual query try to use higher sampling frequency.
|
||||
|
||||
To analyze the `trace_log` system table:
|
||||
|
||||
- Install the `clickhouse-common-static-dbg` package. See [Install from DEB Packages](../../getting_started/install.md#install-from-deb-packages).
|
||||
|
||||
- Allow introspection functions by the [allow\_introspection\_functions](../settings/settings.md#settings-allow_introspection_functions) setting.
|
||||
|
||||
For security reasons, introspection functions are disabled by default.
|
||||
|
||||
- Use the `addressToLine`, `addressToSymbol` and `demangle` [introspection functions](../../query_language/functions/introspection.md) to get function names and their positions in ClickHouse code. To get a profile for some query, you need to aggregate data from the `trace_log` table. You can aggregate data by individual functions or by the whole stack traces.
|
||||
|
||||
If you need to visualize `trace_log` info, try [flamegraph](../../interfaces/third-party/gui/#clickhouse-flamegraph) and [speedscope](https://github.com/laplab/clickhouse-speedscope).
|
||||
|
||||
## Example {#example}
|
||||
|
||||
In this example we:
|
||||
|
||||
- Filtering `trace_log` data by a query identifier and the current date.
|
||||
|
||||
- Aggregating by stack trace.
|
||||
|
||||
- Using introspection functions, we will get a report of:
|
||||
|
||||
- Names of symbols and corresponding source code functions.
|
||||
- Source code locations of these functions.
|
||||
|
||||
<!-- -->
|
||||
|
||||
``` sql
|
||||
SELECT
|
||||
count(),
|
||||
arrayStringConcat(arrayMap(x -> concat(demangle(addressToSymbol(x)), '\n ', addressToLine(x)), trace), '\n') AS sym
|
||||
FROM system.trace_log
|
||||
WHERE (query_id = 'ebca3574-ad0a-400a-9cbc-dca382f5998c') AND (event_date = today())
|
||||
GROUP BY trace
|
||||
ORDER BY count() DESC
|
||||
LIMIT 10
|
||||
```
|
||||
|
||||
``` text
|
||||
{% include "operations/performance/sampling_query_profiler_example_result.txt" %}
|
||||
```
|
||||
@ -1,7 +1,3 @@
|
||||
---
|
||||
en_copy: true
|
||||
---
|
||||
|
||||
Row 1:
|
||||
──────
|
||||
count(): 6344
|
||||
|
||||
@ -1,18 +1,19 @@
|
||||
---
|
||||
en_copy: true
|
||||
machine_translated: true
|
||||
machine_translated_rev: 1cd5f0028d917696daf71ac1c9ee849c99c1d5c8
|
||||
---
|
||||
|
||||
# How To Test Your Hardware With ClickHouse {#how-to-test-your-hardware-with-clickhouse}
|
||||
# Как Протестировать Ваше Оборудование С Помощью ClickHouse {#how-to-test-your-hardware-with-clickhouse}
|
||||
|
||||
With this instruction you can run basic ClickHouse performance test on any server without installation of ClickHouse packages.
|
||||
С помощью этой инструкции вы можете запустить базовый тест производительности ClickHouse на любом сервере без установки пакетов ClickHouse.
|
||||
|
||||
1. Go to “commits” page: https://github.com/ClickHouse/ClickHouse/commits/master
|
||||
1. Идти к «commits» страница: https://github.com/ClickHouse/ClickHouse/commits/master
|
||||
|
||||
2. Click on the first green check mark or red cross with green “ClickHouse Build Check” and click on the “Details” link near “ClickHouse Build Check”.
|
||||
2. Нажмите на первую зеленую галочку или красный крест с зеленым цветом «ClickHouse Build Check» и нажмите на кнопку «Details» ссылка рядом «ClickHouse Build Check».
|
||||
|
||||
3. Copy the link to “clickhouse” binary for amd64 or aarch64.
|
||||
3. Скопируйте ссылку на «clickhouse» двоичный код для amd64 или aarch64.
|
||||
|
||||
4. ssh to the server and download it with wget:
|
||||
4. ssh к серверу и скачать его с помощью wget:
|
||||
|
||||
<!-- -->
|
||||
|
||||
@ -23,7 +24,7 @@ With this instruction you can run basic ClickHouse performance test on any serve
|
||||
# Then do:
|
||||
chmod a+x clickhouse
|
||||
|
||||
1. Download configs:
|
||||
1. Скачать конфиги:
|
||||
|
||||
<!-- -->
|
||||
|
||||
@ -33,7 +34,7 @@ With this instruction you can run basic ClickHouse performance test on any serve
|
||||
wget https://raw.githubusercontent.com/ClickHouse/ClickHouse/master/programs/server/config.d/path.xml -O config.d/path.xml
|
||||
wget https://raw.githubusercontent.com/ClickHouse/ClickHouse/master/programs/server/config.d/log_to_console.xml -O config.d/log_to_console.xml
|
||||
|
||||
1. Download benchmark files:
|
||||
1. Скачать тест файлы:
|
||||
|
||||
<!-- -->
|
||||
|
||||
@ -41,7 +42,7 @@ With this instruction you can run basic ClickHouse performance test on any serve
|
||||
chmod a+x benchmark-new.sh
|
||||
wget https://raw.githubusercontent.com/ClickHouse/ClickHouse/master/benchmark/clickhouse/queries.sql
|
||||
|
||||
1. Download test data according to the [Yandex.Metrica dataset](../getting_started/example_datasets/metrica.md) instruction (“hits” table containing 100 million rows).
|
||||
1. Загрузите тестовые данные в соответствии с [Яндекс.Набор метрика ](../getting_started/example_datasets/metrica.md) инструкция («hits» таблица, содержащая 100 миллионов строк).
|
||||
|
||||
<!-- -->
|
||||
|
||||
@ -49,31 +50,31 @@ With this instruction you can run basic ClickHouse performance test on any serve
|
||||
tar xvf hits_100m_obfuscated_v1.tar.xz -C .
|
||||
mv hits_100m_obfuscated_v1/* .
|
||||
|
||||
1. Run the server:
|
||||
1. Запустите сервер:
|
||||
|
||||
<!-- -->
|
||||
|
||||
./clickhouse server
|
||||
|
||||
1. Check the data: ssh to the server in another terminal
|
||||
1. Проверьте данные: ssh на сервер в другом терминале
|
||||
|
||||
<!-- -->
|
||||
|
||||
./clickhouse client --query "SELECT count() FROM hits_100m_obfuscated"
|
||||
100000000
|
||||
|
||||
1. Edit the benchmark-new.sh, change “clickhouse-client” to “./clickhouse client” and add “–max\_memory\_usage 100000000000” parameter.
|
||||
1. Отредактируйте текст benchmark-new.sh, изменение «clickhouse-client» к «./clickhouse client» и добавить «–max\_memory\_usage 100000000000» параметр.
|
||||
|
||||
<!-- -->
|
||||
|
||||
mcedit benchmark-new.sh
|
||||
|
||||
1. Run the benchmark:
|
||||
1. Выполнить тест:
|
||||
|
||||
<!-- -->
|
||||
|
||||
./benchmark-new.sh hits_100m_obfuscated
|
||||
|
||||
1. Send the numbers and the info about your hardware configuration to clickhouse-feedback@yandex-team.com
|
||||
1. Отправьте номера и информацию о конфигурации вашего оборудования по адресу clickhouse-feedback@yandex-team.com
|
||||
|
||||
All the results are published here: https://clickhouse.tech/benchmark\_hardware.html
|
||||
Все результаты опубликованы здесь: https://clickhouse-да.технология / benchmark\_hardware.HTML
|
||||
|
||||
@ -17,9 +17,9 @@ ClickHouse реализует параллельную обработку дан
|
||||
- Сложности запросов.
|
||||
- Объёма данных, обрабатываемых в запросах.
|
||||
|
||||
Для расчета объёма RAM необходимо оценить размер промежуточных данных для операций [GROUP BY](../query_language/select.md#select-group-by-clause), [DISTINCT](../query_language/select.md#select-distinct), [JOIN](../query_language/select.md#select-join) а также других операций, которыми вы пользуетесь.
|
||||
Для расчета объёма RAM необходимо оценить размер промежуточных данных для операций [GROUP BY](../sql_reference/statements/select.md#select-group-by-clause), [DISTINCT](../sql_reference/statements/select.md#select-distinct), [JOIN](../sql_reference/statements/select.md#select-join) а также других операций, которыми вы пользуетесь.
|
||||
|
||||
ClickHouse может использовать внешнюю память для промежуточных данных. Подробнее смотрите в разделе [GROUP BY во внешней памяти](../query_language/select.md#select-group-by-in-external-memory).
|
||||
ClickHouse может использовать внешнюю память для промежуточных данных. Подробнее смотрите в разделе [GROUP BY во внешней памяти](../sql_reference/statements/select.md#select-group-by-in-external-memory).
|
||||
|
||||
## Файл подкачки {#fail-podkachki}
|
||||
|
||||
|
||||
@ -8,4 +8,4 @@
|
||||
|
||||
Перед изучением настроек ознакомьтесь с разделом [Конфигурационные файлы](../configuration_files.md#configuration_files), обратите внимание на использование подстановок (атрибуты `incl` и `optional`).
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/server_settings/) <!--hide-->
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/server_configuration_parameters/) <!--hide-->
|
||||
@ -58,7 +58,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
|
||||
База данных по умолчанию.
|
||||
|
||||
Перечень баз данных можно получить запросом [SHOW DATABASES](../../query_language/show.md#show-databases).
|
||||
Перечень баз данных можно получить запросом [SHOW DATABASES](../../operations/server_configuration_parameters/settings.md#show-databases).
|
||||
|
||||
**Пример**
|
||||
|
||||
@ -87,7 +87,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
- Указывается абсолютным или относительно конфигурационного файла сервера.
|
||||
- Может содержать wildcard-ы \* и ?.
|
||||
|
||||
Смотрите также «[Внешние словари](../../query_language/dicts/external_dicts.md)».
|
||||
Смотрите также «[Внешние словари](../../operations/server_configuration_parameters/settings.md)».
|
||||
|
||||
**Пример**
|
||||
|
||||
@ -111,7 +111,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
<dictionaries_lazy_load>true</dictionaries_lazy_load>
|
||||
```
|
||||
|
||||
## format\_schema\_path {#server_settings-format_schema_path}
|
||||
## format\_schema\_path {#server_configuration_parameters-format_schema_path}
|
||||
|
||||
Путь к каталогу со схемами для входных данных. Например со схемами для формата [CapnProto](../../interfaces/formats.md#capnproto).
|
||||
|
||||
@ -122,7 +122,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
<format_schema_path>format_schemas/</format_schema_path>
|
||||
```
|
||||
|
||||
## graphite {#server_settings-graphite}
|
||||
## graphite {#server_configuration_parameters-graphite}
|
||||
|
||||
Отправка данных в [Graphite](https://github.com/graphite-project).
|
||||
|
||||
@ -133,10 +133,10 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
- interval – Период отправки в секундах.
|
||||
- timeout – Таймаут отправки данных в секундах.
|
||||
- root\_path – Префикс для ключей.
|
||||
- metrics – Отправка данных из таблицы [system.metrics](../system_tables.md#system_tables-metrics).
|
||||
- events – Отправка дельты данных, накопленной за промежуток времени из таблицы [system.events](../system_tables.md#system_tables-events).
|
||||
- events\_cumulative – Отправка суммарных данных из таблицы [system.events](../system_tables.md#system_tables-events).
|
||||
- asynchronous\_metrics – Отправка данных из таблицы [system.asynchronous\_metrics](../system_tables.md#system_tables-asynchronous_metrics).
|
||||
- metrics – Отправка данных из таблицы [system.metrics](../../operations/server_configuration_parameters/settings.md#system_tables-metrics).
|
||||
- events – Отправка дельты данных, накопленной за промежуток времени из таблицы [system.events](../../operations/server_configuration_parameters/settings.md#system_tables-events).
|
||||
- events\_cumulative – Отправка суммарных данных из таблицы [system.events](../../operations/server_configuration_parameters/settings.md#system_tables-events).
|
||||
- asynchronous\_metrics – Отправка данных из таблицы [system.asynchronous\_metrics](../../operations/server_configuration_parameters/settings.md#system_tables-asynchronous_metrics).
|
||||
|
||||
Можно определить несколько секций `<graphite>`, например, для передачи различных данных с различной частотой.
|
||||
|
||||
@ -156,11 +156,11 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
</graphite>
|
||||
```
|
||||
|
||||
## graphite\_rollup {#server_settings-graphite-rollup}
|
||||
## graphite\_rollup {#server_configuration_parameters-graphite-rollup}
|
||||
|
||||
Настройка прореживания данных для Graphite.
|
||||
|
||||
Подробнее читайте в разделе [GraphiteMergeTree](../table_engines/graphitemergetree.md).
|
||||
Подробнее читайте в разделе [GraphiteMergeTree](../../operations/server_configuration_parameters/settings.md).
|
||||
|
||||
**Пример**
|
||||
|
||||
@ -188,7 +188,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
|
||||
Порт для обращений к серверу по протоколу HTTP(s).
|
||||
|
||||
Если указан `https_port`, то требуется конфигурирование [openSSL](#server_settings-openssl).
|
||||
Если указан `https_port`, то требуется конфигурирование [openSSL](#server_configuration_parameters-openssl).
|
||||
|
||||
Если указан `http_port`, то настройка openSSL игнорируется, даже если она задана.
|
||||
|
||||
@ -198,7 +198,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
<https>0000</https>
|
||||
```
|
||||
|
||||
## http\_server\_default\_response {#server_settings-http_server_default_response}
|
||||
## http\_server\_default\_response {#server_configuration_parameters-http_server_default_response}
|
||||
|
||||
Страница, показываемая по умолчанию, при обращении к HTTP(s) серверу ClickHouse.
|
||||
Значение по умолчанию «Ok.» (с переводом строки на конце).
|
||||
@ -213,7 +213,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
</http_server_default_response>
|
||||
```
|
||||
|
||||
## include\_from {#server_settings-include_from}
|
||||
## include\_from {#server_configuration_parameters-include_from}
|
||||
|
||||
Путь к файлу с подстановками.
|
||||
|
||||
@ -251,7 +251,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
|
||||
## interserver\_http\_credentials {#server-settings-interserver-http-credentials}
|
||||
|
||||
Имя пользователя и пароль, использующиеся для аутентификации при [репликации](../table_engines/replication.md) движками Replicated\*. Это имя пользователя и пароль используются только для взаимодействия между репликами кластера и никак не связаны с аутентификацией клиентов ClickHouse. Сервер проверяет совпадение имени и пароля для соединяющихся с ним реплик, а также использует это же имя и пароль для соединения с другими репликами. Соответственно, эти имя и пароль должны быть прописаны одинаковыми для всех реплик кластера.
|
||||
Имя пользователя и пароль, использующиеся для аутентификации при [репликации](../../operations/server_configuration_parameters/settings.md) движками Replicated\*. Это имя пользователя и пароль используются только для взаимодействия между репликами кластера и никак не связаны с аутентификацией клиентов ClickHouse. Сервер проверяет совпадение имени и пароля для соединяющихся с ним реплик, а также использует это же имя и пароль для соединения с другими репликами. Соответственно, эти имя и пароль должны быть прописаны одинаковыми для всех реплик кластера.
|
||||
По умолчанию аутентификация не используется.
|
||||
|
||||
Раздел содержит следующие параметры:
|
||||
@ -278,7 +278,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
<keep_alive_timeout>3</keep_alive_timeout>
|
||||
```
|
||||
|
||||
## listen\_host {#server_settings-listen_host}
|
||||
## listen\_host {#server_configuration_parameters-listen_host}
|
||||
|
||||
Ограничение по хостам, с которых может прийти запрос. Если необходимо, чтобы сервер отвечал всем, то надо указать `::`.
|
||||
|
||||
@ -289,7 +289,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
<listen_host>127.0.0.1</listen_host>
|
||||
```
|
||||
|
||||
## logger {#server_settings-logger}
|
||||
## logger {#server_configuration_parameters-logger}
|
||||
|
||||
Настройки логирования.
|
||||
|
||||
@ -342,7 +342,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
|
||||
Можно не указывать, если реплицируемых таблицы не используются.
|
||||
|
||||
Подробнее смотрите в разделе «[Создание реплицируемых таблиц](../../operations/table_engines/replication.md)».
|
||||
Подробнее смотрите в разделе «[Создание реплицируемых таблиц](../../operations/server_configuration_parameters/settings.md)».
|
||||
|
||||
**Пример**
|
||||
|
||||
@ -352,7 +352,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
|
||||
## mark\_cache\_size {#server-mark-cache-size}
|
||||
|
||||
Приблизительный размер (в байтах) кэша засечек, используемых движками таблиц семейства [MergeTree](../table_engines/mergetree.md).
|
||||
Приблизительный размер (в байтах) кэша засечек, используемых движками таблиц семейства [MergeTree](../../operations/server_configuration_parameters/settings.md).
|
||||
|
||||
Кэш общий для сервера, память выделяется по мере необходимости.
|
||||
|
||||
@ -400,7 +400,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
|
||||
Ограничение на удаление таблиц.
|
||||
|
||||
Если размер таблицы семейства [MergeTree](../table_engines/mergetree.md) превышает `max_table_size_to_drop` (в байтах), то ее нельзя удалить запросом DROP.
|
||||
Если размер таблицы семейства [MergeTree](../../operations/server_configuration_parameters/settings.md) превышает `max_table_size_to_drop` (в байтах), то ее нельзя удалить запросом DROP.
|
||||
|
||||
Если таблицу все же необходимо удалить, не перезапуская при этом сервер ClickHouse, то необходимо создать файл `<clickhouse-path>/flags/force_drop_table` и выполнить запрос DROP.
|
||||
|
||||
@ -414,9 +414,9 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
<max_table_size_to_drop>0</max_table_size_to_drop>
|
||||
```
|
||||
|
||||
## merge\_tree {#server_settings-merge_tree}
|
||||
## merge\_tree {#server_configuration_parameters-merge_tree}
|
||||
|
||||
Тонкая настройка таблиц семейства [MergeTree](../table_engines/mergetree.md).
|
||||
Тонкая настройка таблиц семейства [MergeTree](../../operations/server_configuration_parameters/settings.md).
|
||||
|
||||
Подробнее смотрите в заголовочном файле MergeTreeSettings.h.
|
||||
|
||||
@ -428,7 +428,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
</merge_tree>
|
||||
```
|
||||
|
||||
## openSSL {#server_settings-openssl}
|
||||
## openSSL {#server_configuration_parameters-openssl}
|
||||
|
||||
Настройки клиента/сервера SSL.
|
||||
|
||||
@ -487,17 +487,17 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
</openSSL>
|
||||
```
|
||||
|
||||
## part\_log {#server_settings-part-log}
|
||||
## part\_log {#server_configuration_parameters-part-log}
|
||||
|
||||
Логирование событий, связанных с данными типа [MergeTree](../table_engines/mergetree.md). Например, события добавления или мержа данных. Лог можно использовать для симуляции алгоритмов слияния, чтобы сравнивать их характеристики. Также, можно визуализировать процесс слияния.
|
||||
Логирование событий, связанных с данными типа [MergeTree](../../operations/server_configuration_parameters/settings.md). Например, события добавления или мержа данных. Лог можно использовать для симуляции алгоритмов слияния, чтобы сравнивать их характеристики. Также, можно визуализировать процесс слияния.
|
||||
|
||||
Запросы логируются не в отдельный файл, а в таблицу [system.part\_log](../system_tables.md#system_tables-part-log). Вы можете изменить название этой таблицы в параметре `table` (см. ниже).
|
||||
Запросы логируются не в отдельный файл, а в таблицу [system.part\_log](../../operations/server_configuration_parameters/settings.md#system_tables-part-log). Вы можете изменить название этой таблицы в параметре `table` (см. ниже).
|
||||
|
||||
При настройке логирования используются следующие параметры:
|
||||
|
||||
- `database` — имя базы данных;
|
||||
- `table` — имя таблицы;
|
||||
- `partition_by` — устанавливает [произвольный ключ партиционирования](../../operations/table_engines/custom_partitioning_key.md);
|
||||
- `partition_by` — устанавливает [произвольный ключ партиционирования](../../operations/server_configuration_parameters/settings.md);
|
||||
- `flush_interval_milliseconds` — период сброса данных из буфера в памяти в таблицу.
|
||||
|
||||
**Пример**
|
||||
@ -511,7 +511,7 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
</part_log>
|
||||
```
|
||||
|
||||
## path {#server_settings-path}
|
||||
## path {#server_configuration_parameters-path}
|
||||
|
||||
Путь к каталогу с данными.
|
||||
|
||||
@ -524,17 +524,17 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
<path>/var/lib/clickhouse/</path>
|
||||
```
|
||||
|
||||
## query\_log {#server_settings-query-log}
|
||||
## query\_log {#server_configuration_parameters-query-log}
|
||||
|
||||
Настройка логирования запросов, принятых с настройкой [log\_queries=1](../settings/settings.md).
|
||||
|
||||
Запросы логируются не в отдельный файл, а в системную таблицу [system.query\_log](../system_tables.md#system_tables-query-log). Вы можете изменить название этой таблицы в параметре `table` (см. ниже).
|
||||
Запросы логируются не в отдельный файл, а в системную таблицу [system.query\_log](../../operations/server_configuration_parameters/settings.md#system_tables-query-log). Вы можете изменить название этой таблицы в параметре `table` (см. ниже).
|
||||
|
||||
При настройке логирования используются следующие параметры:
|
||||
|
||||
- `database` — имя базы данных;
|
||||
- `table` — имя таблицы, куда будет записываться лог;
|
||||
- `partition_by` — [произвольный ключ партиционирования](../../operations/table_engines/custom_partitioning_key.md) для таблицы с логами;
|
||||
- `partition_by` — [произвольный ключ партиционирования](../../operations/server_configuration_parameters/settings.md) для таблицы с логами;
|
||||
- `flush_interval_milliseconds` — период сброса данных из буфера в памяти в таблицу.
|
||||
|
||||
Если таблица не существует, то ClickHouse создаст её. Если структура журнала запросов изменилась при обновлении сервера ClickHouse, то таблица со старой структурой переименовывается, а новая таблица создается автоматически.
|
||||
@ -550,17 +550,17 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
</query_log>
|
||||
```
|
||||
|
||||
## query\_thread\_log {#server_settings-query-thread-log}
|
||||
## query\_thread\_log {#server_configuration_parameters-query-thread-log}
|
||||
|
||||
Настройка логирования потоков выполнения запросов, принятых с настройкой [log\_query\_threads=1](../settings/settings.md#settings-log-query-threads).
|
||||
|
||||
Запросы логируются не в отдельный файл, а в системную таблицу [system.query\_thread\_log](../system_tables.md#system_tables-query-thread-log). Вы можете изменить название этой таблицы в параметре `table` (см. ниже).
|
||||
Запросы логируются не в отдельный файл, а в системную таблицу [system.query\_thread\_log](../../operations/server_configuration_parameters/settings.md#system_tables-query-thread-log). Вы можете изменить название этой таблицы в параметре `table` (см. ниже).
|
||||
|
||||
При настройке логирования используются следующие параметры:
|
||||
|
||||
- `database` — имя базы данных;
|
||||
- `table` — имя таблицы, куда будет записываться лог;
|
||||
- `partition_by` — [произвольный ключ партиционирования](../../operations/table_engines/custom_partitioning_key.md) для таблицы с логами;
|
||||
- `partition_by` — [произвольный ключ партиционирования](../../operations/server_configuration_parameters/settings.md) для таблицы с логами;
|
||||
- `flush_interval_milliseconds` — период сброса данных из буфера в памяти в таблицу.
|
||||
|
||||
Если таблица не существует, то ClickHouse создаст её. Если структура журнала запросов изменилась при обновлении сервера ClickHouse, то таблица со старой структурой переименовывается, а новая таблица создается автоматически.
|
||||
@ -576,15 +576,15 @@ ClickHouse проверит условия `min_part_size` и `min_part_size_rat
|
||||
</query_thread_log>
|
||||
```
|
||||
|
||||
## trace\_log {#server_settings-trace_log}
|
||||
## trace\_log {#server_configuration_parameters-trace_log}
|
||||
|
||||
Settings for the [trace\_log](../system_tables.md#system_tables-trace_log) system table operation.
|
||||
Settings for the [trace\_log](../../operations/server_configuration_parameters/settings.md#system_tables-trace_log) system table operation.
|
||||
|
||||
Parameters:
|
||||
|
||||
- `database` — Database for storing a table.
|
||||
- `table` — Table name.
|
||||
- `partition_by` — [Custom partitioning key](../../operations/table_engines/custom_partitioning_key.md) for a system table.
|
||||
- `partition_by` — [Custom partitioning key](../../operations/server_configuration_parameters/settings.md) for a system table.
|
||||
- `flush_interval_milliseconds` — Interval for flushing data from the buffer in memory to the table.
|
||||
|
||||
The default server configuration file `config.xml` contains the following settings section:
|
||||
@ -600,7 +600,7 @@ The default server configuration file `config.xml` contains the following settin
|
||||
|
||||
## remote\_servers {#server-settings-remote-servers}
|
||||
|
||||
Конфигурация кластеров, которые использует движок таблиц [Distributed](../../operations/table_engines/distributed.md) и табличная функция `cluster`.
|
||||
Конфигурация кластеров, которые использует движок таблиц [Distributed](../../operations/server_configuration_parameters/settings.md) и табличная функция `cluster`.
|
||||
|
||||
**Пример**
|
||||
|
||||
@ -614,7 +614,7 @@ The default server configuration file `config.xml` contains the following settin
|
||||
|
||||
- [skip\_unavailable\_shards](../settings/settings.md#settings-skip_unavailable_shards)
|
||||
|
||||
## timezone {#server_settings-timezone}
|
||||
## timezone {#server_configuration_parameters-timezone}
|
||||
|
||||
Временная зона сервера.
|
||||
|
||||
@ -628,7 +628,7 @@ The default server configuration file `config.xml` contains the following settin
|
||||
<timezone>Europe/Moscow</timezone>
|
||||
```
|
||||
|
||||
## tcp\_port {#server_settings-tcp_port}
|
||||
## tcp\_port {#server_configuration_parameters-tcp_port}
|
||||
|
||||
Порт для взаимодействия с клиентами по протоколу TCP.
|
||||
|
||||
@ -638,9 +638,9 @@ The default server configuration file `config.xml` contains the following settin
|
||||
<tcp_port>9000</tcp_port>
|
||||
```
|
||||
|
||||
## tcp\_port\_secure {#server_settings-tcp_port-secure}
|
||||
## tcp\_port\_secure {#server_configuration_parameters-tcp_port-secure}
|
||||
|
||||
TCP порт для защищённого обмена данными с клиентами. Используйте с настройкой [OpenSSL](#server_settings-openssl).
|
||||
TCP порт для защищённого обмена данными с клиентами. Используйте с настройкой [OpenSSL](#server_configuration_parameters-openssl).
|
||||
|
||||
**Возможные значения**
|
||||
|
||||
@ -652,7 +652,7 @@ TCP порт для защищённого обмена данными с кли
|
||||
<tcp_port_secure>9440</tcp_port_secure>
|
||||
```
|
||||
|
||||
## mysql\_port {#server_settings-mysql_port}
|
||||
## mysql\_port {#server_configuration_parameters-mysql_port}
|
||||
|
||||
Порт для взаимодействия с клиентами по протоколу MySQL.
|
||||
|
||||
@ -677,7 +677,7 @@ TCP порт для защищённого обмена данными с кли
|
||||
|
||||
## uncompressed\_cache\_size {#server-settings-uncompressed_cache_size}
|
||||
|
||||
Размер кеша (в байтах) для несжатых данных, используемых движками таблиц семейства [MergeTree](../table_engines/mergetree.md).
|
||||
Размер кеша (в байтах) для несжатых данных, используемых движками таблиц семейства [MergeTree](../../operations/server_configuration_parameters/settings.md).
|
||||
|
||||
Кеш единый для сервера. Память выделяется по требованию. Кеш используется в том случае, если включена опция [use\_uncompressed\_cache](../settings/settings.md).
|
||||
|
||||
@ -689,9 +689,9 @@ TCP порт для защищённого обмена данными с кли
|
||||
<uncompressed_cache_size>8589934592</uncompressed_cache_size>
|
||||
```
|
||||
|
||||
## user\_files\_path {#server_settings-user_files_path}
|
||||
## user\_files\_path {#server_configuration_parameters-user_files_path}
|
||||
|
||||
Каталог с пользовательскими файлами. Используется в табличной функции [file()](../../query_language/table_functions/file.md).
|
||||
Каталог с пользовательскими файлами. Используется в табличной функции [file()](../../operations/server_configuration_parameters/settings.md).
|
||||
|
||||
**Пример**
|
||||
|
||||
@ -763,7 +763,7 @@ ClickHouse использует ZooKeeper для хранения метадан
|
||||
|
||||
**Смотрите также**
|
||||
|
||||
- [Репликация](../../operations/table_engines/replication.md)
|
||||
- [Репликация](../../operations/server_configuration_parameters/settings.md)
|
||||
- [ZooKeeper Programmer’s Guide](http://zookeeper.apache.org/doc/current/zookeeperProgrammers.html)
|
||||
|
||||
## use\_minimalistic\_part\_header\_in\_zookeeper {#server-settings-use_minimalistic_part_header_in_zookeeper}
|
||||
@ -772,20 +772,20 @@ ClickHouse использует ZooKeeper для хранения метадан
|
||||
|
||||
Параметр применяется только к семейству таблиц `MergeTree`. Его можно установить:
|
||||
|
||||
- Глобально в разделе [merge\_tree](#server_settings-merge_tree) файла `config.xml`.
|
||||
- Глобально в разделе [merge\_tree](#server_configuration_parameters-merge_tree) файла `config.xml`.
|
||||
|
||||
ClickHouse использует этот параметр для всех таблиц на сервере. Вы можете изменить настройку в любое время. Существующие таблицы изменяют свое поведение при изменении параметра.
|
||||
|
||||
- Для каждой отдельной таблицы.
|
||||
|
||||
При создании таблицы укажите соответствующую [настройку движка](../table_engines/mergetree.md#table_engine-mergetree-creating-a-table). Поведение существующей таблицы с установленным параметром не изменяется даже при изменении глобального параметра.
|
||||
При создании таблицы укажите соответствующую [настройку движка](../../operations/server_configuration_parameters/settings.md#table_engine-mergetree-creating-a-table). Поведение существующей таблицы с установленным параметром не изменяется даже при изменении глобального параметра.
|
||||
|
||||
**Возможные значения**
|
||||
|
||||
- 0 — функциональность выключена.
|
||||
- 1 — функциональность включена.
|
||||
|
||||
Если `use_minimalistic_part_header_in_zookeeper = 1`, то [реплицированные](../table_engines/replication.md) таблицы хранят заголовки кусков данных в компактном виде, используя только одну `znode`. Если таблица содержит много столбцов, этот метод хранения значительно уменьшает объём данных, хранящихся в Zookeeper.
|
||||
Если `use_minimalistic_part_header_in_zookeeper = 1`, то [реплицированные](../../operations/server_configuration_parameters/settings.md) таблицы хранят заголовки кусков данных в компактном виде, используя только одну `znode`. Если таблица содержит много столбцов, этот метод хранения значительно уменьшает объём данных, хранящихся в Zookeeper.
|
||||
|
||||
!!! attention "Внимание"
|
||||
После того как вы установили `use_minimalistic_part_header_in_zookeeper = 1`, невозможно откатить ClickHouse до версии, которая не поддерживает этот параметр. Будьте осторожны при обновлении ClickHouse на серверах в кластере. Не обновляйте все серверы сразу. Безопаснее проверять новые версии ClickHouse в тестовой среде или только на некоторых серверах кластера.
|
||||
@ -808,4 +808,4 @@ ClickHouse использует ZooKeeper для хранения метадан
|
||||
|
||||
**Значение по умолчанию**: 15.
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/server_settings/settings/) <!--hide-->
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/server_configuration_parameters/settings/) <!--hide-->
|
||||
@ -76,11 +76,11 @@
|
||||
|
||||
## max\_bytes\_before\_external\_group\_by {#settings-max_bytes_before_external_group_by}
|
||||
|
||||
Включает или отключает выполнение секций `GROUP BY` во внешней памяти. Смотрите [GROUP BY во внешней памяти](../../query_language/select.md#select-group-by-in-external-memory).
|
||||
Включает или отключает выполнение секций `GROUP BY` во внешней памяти. Смотрите [GROUP BY во внешней памяти](../../sql_reference/statements/select.md#select-group-by-in-external-memory).
|
||||
|
||||
Возможные значения:
|
||||
|
||||
- Максимальный объём RAM (в байтах), который может использовать отдельная операция [GROUP BY](../../query_language/select.md#select-group-by-clause).
|
||||
- Максимальный объём RAM (в байтах), который может использовать отдельная операция [GROUP BY](../../sql_reference/statements/select.md#select-group-by-clause).
|
||||
- 0 — `GROUP BY` во внешней памяти отключен.
|
||||
|
||||
Значение по умолчанию — 0.
|
||||
@ -228,7 +228,7 @@ FORMAT Null;
|
||||
|
||||
Ограничивает количество строк в хэш-таблице, используемой при соединении таблиц.
|
||||
|
||||
Параметр применяется к операциям [SELECT… JOIN](../../query_language/select.md#select-join) и к движку таблиц [Join](../table_engines/join.md).
|
||||
Параметр применяется к операциям [SELECT… JOIN](../../sql_reference/statements/select.md#select-join) и к движку таблиц [Join](../../engines/table_engines/special/join.md).
|
||||
|
||||
Если запрос содержит несколько `JOIN`, то ClickHouse проверяет значение настройки для каждого промежуточного результата.
|
||||
|
||||
@ -245,7 +245,7 @@ FORMAT Null;
|
||||
|
||||
Ограничивает размер (в байтах) хэш-таблицы, используемой при объединении таблиц.
|
||||
|
||||
Параметр применяется к операциям [SELECT… JOIN](../../query_language/select.md#select-join) и к движку таблиц [Join](../table_engines/join.md).
|
||||
Параметр применяется к операциям [SELECT… JOIN](../../sql_reference/statements/select.md#select-join) и к движку таблиц [Join](../../engines/table_engines/special/join.md).
|
||||
|
||||
Если запрос содержит несколько `JOIN`, то ClickHouse проверяет значение настройки для каждого промежуточного результата.
|
||||
|
||||
@ -274,8 +274,8 @@ FORMAT Null;
|
||||
|
||||
**Смотрите также**
|
||||
|
||||
- [Секция JOIN](../../query_language/select.md#select-join)
|
||||
- [Движок таблиц Join](../table_engines/join.md)
|
||||
- [Секция JOIN](../../sql_reference/statements/select.md#select-join)
|
||||
- [Движоy таблиц Join](../../engines/table_engines/special/join.md)
|
||||
|
||||
## max\_partitions\_per\_insert\_block {#max-partitions-per-insert-block}
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
## distributed\_product\_mode {#distributed-product-mode}
|
||||
|
||||
Изменяет поведение [распределенных подзапросов](../../query_language/select.md).
|
||||
Изменяет поведение [распределенных подзапросов](../../sql_reference/statements/select.md).
|
||||
|
||||
ClickHouse применяет настройку в тех случаях, когда запрос содержит произведение распределённых таблиц, т.е. когда запрос к распределенной таблице содержит не-GLOBAL подзапрос к также распределенной таблице.
|
||||
|
||||
@ -11,7 +11,7 @@ ClickHouse применяет настройку в тех случаях, ко
|
||||
- Только подзапросы для IN, JOIN.
|
||||
- Только если в секции FROM используется распределённая таблица, содержащая более одного шарда.
|
||||
- Если подзапрос касается распределенной таблицы, содержащей более одного шарда.
|
||||
- Не используется в случае табличной функции [remote](../../query_language/table_functions/remote.md).
|
||||
- Не используется в случае табличной функции [remote](../../sql_reference/table_functions/remote.md).
|
||||
|
||||
Возможные значения:
|
||||
|
||||
@ -46,7 +46,7 @@ ClickHouse применяет настройку в тех случаях, ко
|
||||
|
||||
## fallback\_to\_stale\_replicas\_for\_distributed\_queries {#settings-fallback_to_stale_replicas_for_distributed_queries}
|
||||
|
||||
Форсирует запрос в устаревшую реплику в случае, если актуальные данные недоступны. См. [Репликация](../../operations/table_engines/replication.md).
|
||||
Форсирует запрос в устаревшую реплику в случае, если актуальные данные недоступны. См. [Репликация](../../engines/table_engines/mergetree_family/replication.md).
|
||||
|
||||
Из устаревших реплик таблицы ClickHouse выбирает наиболее актуальную.
|
||||
|
||||
@ -60,7 +60,7 @@ ClickHouse применяет настройку в тех случаях, ко
|
||||
|
||||
Работает с таблицами семейства MergeTree.
|
||||
|
||||
При `force_index_by_date=1` ClickHouse проверяет, есть ли в запросе условие на ключ даты, которое может использоваться для отсечения диапазонов данных. Если подходящего условия нет - кидается исключение. При этом не проверяется, действительно ли условие уменьшает объём данных для чтения. Например, условие `Date != '2000-01-01'` подходит даже в том случае, когда соответствует всем данным в таблице (т.е. для выполнения запроса требуется full scan). Подробнее про диапазоны данных в таблицах MergeTree читайте в разделе [MergeTree](../table_engines/mergetree.md).
|
||||
При `force_index_by_date=1` ClickHouse проверяет, есть ли в запросе условие на ключ даты, которое может использоваться для отсечения диапазонов данных. Если подходящего условия нет - кидается исключение. При этом не проверяется, действительно ли условие уменьшает объём данных для чтения. Например, условие `Date != '2000-01-01'` подходит даже в том случае, когда соответствует всем данным в таблице (т.е. для выполнения запроса требуется full scan). Подробнее про диапазоны данных в таблицах MergeTree читайте в разделе [MergeTree](../../engines/table_engines/mergetree_family/mergetree.md).
|
||||
|
||||
## force\_primary\_key {#settings-force-primary-key}
|
||||
|
||||
@ -68,7 +68,7 @@ ClickHouse применяет настройку в тех случаях, ко
|
||||
|
||||
Работает с таблицами семейства MergeTree.
|
||||
|
||||
При `force_primary_key=1` ClickHouse проверяет, есть ли в запросе условие на первичный ключ, которое может использоваться для отсечения диапазонов данных. Если подходящего условия нет - кидается исключение. При этом не проверяется, действительно ли условие уменьшает объём данных для чтения. Подробнее про диапазоны данных в таблицах MergeTree читайте в разделе [MergeTree](../table_engines/mergetree.md).
|
||||
При `force_primary_key=1` ClickHouse проверяет, есть ли в запросе условие на первичный ключ, которое может использоваться для отсечения диапазонов данных. Если подходящего условия нет - кидается исключение. При этом не проверяется, действительно ли условие уменьшает объём данных для чтения. Подробнее про диапазоны данных в таблицах MergeTree читайте в разделе [MergeTree](../../engines/table_engines/mergetree_family/mergetree.md).
|
||||
|
||||
## format\_schema {#format-schema}
|
||||
|
||||
@ -129,7 +129,7 @@ ClickHouse применяет настройку в тех случаях, ко
|
||||
|
||||
## max\_http\_get\_redirects {#setting-max_http_get_redirects}
|
||||
|
||||
Ограничивает максимальное количество переходов по редиректам в таблицах с движком [URL](../table_engines/url.md) при выполнении HTTP запросов методом GET. Настройка применяется для обоих типов таблиц: созданных запросом [CREATE TABLE](../../query_language/create/#create-table-query) и с помощью табличной функции [url](../../query_language/table_functions/url.md).
|
||||
Ограничивает максимальное количество переходов по редиректам в таблицах с движком [URL](../../engines/table_engines/special/url.md) при выполнении HTTP запросов методом GET. Настройка применяется для обоих типов таблиц: созданных запросом [CREATE TABLE](../../sql_reference/create/#create-table-query) и с помощью табличной функции [url](../../sql_reference/table_functions/url.md).
|
||||
|
||||
Возможные значения:
|
||||
|
||||
@ -165,7 +165,7 @@ ClickHouse применяет настройку в тех случаях, ко
|
||||
|
||||
## input\_format\_values\_interpret\_expressions {#settings-input_format_values_interpret_expressions}
|
||||
|
||||
Включает или отключает парсер SQL, если потоковый парсер не может проанализировать данные. Этот параметр используется только для формата [Values](../../interfaces/formats.md#data-format-values) при вставке данных. Дополнительные сведения о парсерах читайте в разделе [Синтаксис](../../query_language/syntax.md).
|
||||
Включает или отключает парсер SQL, если потоковый парсер не может проанализировать данные. Этот параметр используется только для формата [Values](../../interfaces/formats.md#data-format-values) при вставке данных. Дополнительные сведения о парсерах читайте в разделе [Синтаксис](../../sql_reference/syntax.md).
|
||||
|
||||
Возможные значения:
|
||||
|
||||
@ -181,7 +181,7 @@ ClickHouse применяет настройку в тех случаях, ко
|
||||
|
||||
Пример использования:
|
||||
|
||||
Вставим значение типа [DateTime](../../data_types/datetime.md) при разных значения настройки.
|
||||
Вставим значение типа [DateTime](../../sql_reference/data_types/datetime.md) при разных значения настройки.
|
||||
|
||||
``` sql
|
||||
SET input_format_values_interpret_expressions = 0;
|
||||
@ -298,7 +298,7 @@ Ok.
|
||||
|
||||
Выбор парсера для текстового представления дат и времени при обработке входного формата.
|
||||
|
||||
Настройка не применяется к [функциям для работы с датой и временем](../../query_language/functions/date_time_functions.md).
|
||||
Настройка не применяется к [функциям для работы с датой и временем](../../sql_reference/functions/date_time_functions.md).
|
||||
|
||||
Возможные значения:
|
||||
|
||||
@ -314,12 +314,12 @@ Ok.
|
||||
|
||||
См. также:
|
||||
|
||||
- [Тип данных DateTime.](../../data_types/datetime.md)
|
||||
- [Функции для работы с датой и временем.](../../query_language/functions/date_time_functions.md)
|
||||
- [Тип данных DateTime.](../../sql_reference/data_types/datetime.md)
|
||||
- [Функции для работы с датой и временем.](../../sql_reference/functions/date_time_functions.md)
|
||||
|
||||
## join\_default\_strictness {#settings-join_default_strictness}
|
||||
|
||||
Устанавливает строгость по умолчанию для [JOIN](../../query_language/select.md#select-join).
|
||||
Устанавливает строгость по умолчанию для [JOIN](../../sql_reference/statements/select.md#select-join).
|
||||
|
||||
Возможные значения
|
||||
|
||||
@ -334,7 +334,7 @@ Ok.
|
||||
Изменяет поведение операций, выполняемых со строгостью `ANY`.
|
||||
|
||||
!!! warning "Внимание"
|
||||
Настройка применяется только для операций `JOIN`, выполняемых над таблицами с движком [Join](../table_engines/join.md).
|
||||
Настройка применяется только для операций `JOIN`, выполняемых над таблицами с движком [Join](../../engines/table_engines/special/join.md).
|
||||
|
||||
Возможные значения:
|
||||
|
||||
@ -345,18 +345,18 @@ Ok.
|
||||
|
||||
См. также:
|
||||
|
||||
- [Секция JOIN](../../query_language/select.md#select-join)
|
||||
- [Движок таблиц Join](../table_engines/join.md)
|
||||
- [Секция JOIN](../../sql_reference/statements/select.md#select-join)
|
||||
- [Движок таблиц Join](../../engines/table_engines/special/join.md)
|
||||
- [join\_default\_strictness](#settings-join_default_strictness)
|
||||
|
||||
## join\_use\_nulls {#join_use_nulls}
|
||||
|
||||
Устанавливает тип поведения [JOIN](../../query_language/select.md). При объединении таблиц могут появиться пустые ячейки. ClickHouse заполняет их по-разному в зависимости от настроек.
|
||||
Устанавливает тип поведения [JOIN](../../sql_reference/statements/select.md). При объединении таблиц могут появиться пустые ячейки. ClickHouse заполняет их по-разному в зависимости от настроек.
|
||||
|
||||
Возможные значения
|
||||
|
||||
- 0 — пустые ячейки заполняются значением по умолчанию соответствующего типа поля.
|
||||
- 1 — `JOIN` ведёт себя как в стандартном SQL. Тип соответствующего поля преобразуется в [Nullable](../../data_types/nullable.md#data_type-nullable), а пустые ячейки заполняются значениями [NULL](../../query_language/syntax.md).
|
||||
- 1 — `JOIN` ведёт себя как в стандартном SQL. Тип соответствующего поля преобразуется в [Nullable](../../sql_reference/data_types/nullable.md#data_type-nullable), а пустые ячейки заполняются значениями [NULL](../../sql_reference/syntax.md).
|
||||
|
||||
Значение по умолчанию: 0.
|
||||
|
||||
@ -376,7 +376,7 @@ Ok.
|
||||
|
||||
## merge\_tree\_uniform\_read\_distribution {#setting-merge-tree-uniform-read-distribution}
|
||||
|
||||
При чтении из таблиц [MergeTree](../table_engines/mergetree.md) ClickHouse использует несколько потоков. Этот параметр включает/выключает равномерное распределение заданий по рабочим потокам. Алгоритм равномерного распределения стремится сделать время выполнения всех потоков примерно равным для одного запроса `SELECT`.
|
||||
При чтении из таблиц [MergeTree](../../engines/table_engines/mergetree_family/mergetree.md) ClickHouse использует несколько потоков. Этот параметр включает/выключает равномерное распределение заданий по рабочим потокам. Алгоритм равномерного распределения стремится сделать время выполнения всех потоков примерно равным для одного запроса `SELECT`.
|
||||
|
||||
Возможные значения:
|
||||
|
||||
@ -387,7 +387,7 @@ Ok.
|
||||
|
||||
## merge\_tree\_min\_rows\_for\_concurrent\_read {#setting-merge-tree-min-rows-for-concurrent-read}
|
||||
|
||||
Если количество строк, считываемых из файла таблицы [MergeTree](../table_engines/mergetree.md) превышает `merge_tree_min_rows_for_concurrent_read`, то ClickHouse пытается выполнить одновременное чтение из этого файла в несколько потоков.
|
||||
Если количество строк, считываемых из файла таблицы [MergeTree](../../engines/table_engines/mergetree_family/mergetree.md) превышает `merge_tree_min_rows_for_concurrent_read`, то ClickHouse пытается выполнить одновременное чтение из этого файла в несколько потоков.
|
||||
|
||||
Возможные значения:
|
||||
|
||||
@ -397,7 +397,7 @@ Ok.
|
||||
|
||||
## merge\_tree\_min\_bytes\_for\_concurrent\_read {#setting-merge-tree-min-bytes-for-concurrent-read}
|
||||
|
||||
Если число байтов, которое должно быть прочитано из одного файла таблицы с движком [MergeTree](../table_engines/mergetree.md), превышает значение `merge_tree_min_bytes_for_concurrent_read`, то ClickHouse выполняет одновременное чтение в несколько потоков из этого файла.
|
||||
Если число байтов, которое должно быть прочитано из одного файла таблицы с движком [MergeTree](../../engines/table_engines/mergetree_family/mergetree.md), превышает значение `merge_tree_min_bytes_for_concurrent_read`, то ClickHouse выполняет одновременное чтение в несколько потоков из этого файла.
|
||||
|
||||
Возможное значение:
|
||||
|
||||
@ -439,7 +439,7 @@ Ok.
|
||||
|
||||
Если требуется прочитать более, чем `merge_tree_max_rows_to_use_cache` строк в одном запросе, ClickHouse не используют кэш несжатых блоков.
|
||||
|
||||
Кэш несжатых блоков хранит данные, извлечённые при выполнении запросов. ClickHouse использует этот кэш для ускорения ответов на повторяющиеся небольшие запросы. Настройка защищает кэш от замусоривания запросами, для выполнения которых необходимо извлечь большое количество данных. Настройка сервера [uncompressed\_cache\_size](../server_settings/settings.md#server-settings-uncompressed_cache_size) определяет размер кэша несжатых блоков.
|
||||
Кэш несжатых блоков хранит данные, извлечённые при выполнении запросов. ClickHouse использует этот кэш для ускорения ответов на повторяющиеся небольшие запросы. Настройка защищает кэш от замусоривания запросами, для выполнения которых необходимо извлечь большое количество данных. Настройка сервера [uncompressed\_cache\_size](../server_configuration_parameters/settings.md#server-settings-uncompressed_cache_size) определяет размер кэша несжатых блоков.
|
||||
|
||||
Возможные значения:
|
||||
|
||||
@ -451,7 +451,7 @@ Ok.
|
||||
|
||||
Если требуется прочитать более, чем `merge_tree_max_bytes_to_use_cache` байтов в одном запросе, ClickHouse не используют кэш несжатых блоков.
|
||||
|
||||
Кэш несжатых блоков хранит данные, извлечённые при выполнении запросов. ClickHouse использует кэш для ускорения ответов на повторяющиеся небольшие запросы. Настройка защищает кэш от переполнения. Настройка сервера [uncompressed\_cache\_size](../server_settings/settings.md#server-settings-uncompressed_cache_size) определяет размер кэша несжатых блоков.
|
||||
Кэш несжатых блоков хранит данные, извлечённые при выполнении запросов. ClickHouse использует кэш для ускорения ответов на повторяющиеся небольшие запросы. Настройка защищает кэш от переполнения. Настройка сервера [uncompressed\_cache\_size](../server_configuration_parameters/settings.md#server-settings-uncompressed_cache_size) определяет размер кэша несжатых блоков.
|
||||
|
||||
Возможное значение:
|
||||
|
||||
@ -476,7 +476,7 @@ ClickHouse использует этот параметр при чтении д
|
||||
|
||||
Установка логирования запроса.
|
||||
|
||||
Запросы, переданные в ClickHouse с этой установкой, логируются согласно правилам конфигурационного параметра сервера [query\_log](../../operations/server_settings/settings.md#server_settings-query-log).
|
||||
Запросы, переданные в ClickHouse с этой установкой, логируются согласно правилам конфигурационного параметра сервера [query\_log](../../operations/server_configuration_parameters/settings.md#server_configuration_parameters-query-log).
|
||||
|
||||
Пример:
|
||||
|
||||
@ -488,7 +488,7 @@ log_queries=1
|
||||
|
||||
Установка логирования информации о потоках выполнения запроса.
|
||||
|
||||
Лог информации о потоках выполнения запросов, переданных в ClickHouse с этой установкой, записывается согласно правилам конфигурационного параметра сервера [query\_thread\_log](../server_settings/settings.md#server_settings-query-thread-log).
|
||||
Лог информации о потоках выполнения запросов, переданных в ClickHouse с этой установкой, записывается согласно правилам конфигурационного параметра сервера [query\_thread\_log](../server_configuration_parameters/settings.md#server_configuration_parameters-query-thread-log).
|
||||
|
||||
Пример:
|
||||
|
||||
@ -510,7 +510,7 @@ log_query_threads=1
|
||||
|
||||
## max\_replica\_delay\_for\_distributed\_queries {#settings-max_replica_delay_for_distributed_queries}
|
||||
|
||||
Отключает отстающие реплики при распределенных запросах. См. [Репликация](../../operations/table_engines/replication.md).
|
||||
Отключает отстающие реплики при распределенных запросах. См. [Репликация](../../engines/table_engines/mergetree_family/replication.md).
|
||||
|
||||
Устанавливает время в секундах. Если отставание реплики больше установленного значения, то реплика не используется.
|
||||
|
||||
@ -555,7 +555,7 @@ log_query_threads=1
|
||||
|
||||
## min\_compress\_block\_size {#min-compress-block-size}
|
||||
|
||||
Для таблиц типа [MergeTree](../table_engines/mergetree.md). В целях уменьшения задержек при обработке запросов, блок сжимается при записи следующей засечки, если его размер не меньше min\_compress\_block\_size. По умолчанию - 65 536.
|
||||
Для таблиц типа [MergeTree](../../engines/table_engines/mergetree_family/mergetree.md). В целях уменьшения задержек при обработке запросов, блок сжимается при записи следующей засечки, если его размер не меньше min\_compress\_block\_size. По умолчанию - 65 536.
|
||||
|
||||
Реальный размер блока, если несжатых данных меньше max\_compress\_block\_size, будет не меньше этого значения и не меньше объёма данных на одну засечку.
|
||||
|
||||
@ -634,7 +634,7 @@ log_query_threads=1
|
||||
|
||||
Использовать ли кэш разжатых блоков. Принимает 0 или 1. По умолчанию - 0 (выключено).
|
||||
|
||||
Использование кэша несжатых блоков (только для таблиц семейства MergeTree) может существенно сократить задержку и увеличить пропускную способность при работе с большим количеством коротких запросов. Включите эту настройку для пользователей, от которых идут частые короткие запросы. Также обратите внимание на конфигурационный параметр [uncompressed\_cache\_size](../server_settings/settings.md#server-settings-uncompressed_cache_size) (настраивается только в конфигурационном файле) – размер кэша разжатых блоков. По умолчанию - 8 GiB. Кэш разжатых блоков заполняется по мере надобности, а наиболее невостребованные данные автоматически удаляются.
|
||||
Использование кэша несжатых блоков (только для таблиц семейства MergeTree) может существенно сократить задержку и увеличить пропускную способность при работе с большим количеством коротких запросов. Включите эту настройку для пользователей, от которых идут частые короткие запросы. Также обратите внимание на конфигурационный параметр [uncompressed\_cache\_size](../server_configuration_parameters/settings.md#server-settings-uncompressed_cache_size) (настраивается только в конфигурационном файле) – размер кэша разжатых блоков. По умолчанию - 8 GiB. Кэш разжатых блоков заполняется по мере надобности, а наиболее невостребованные данные автоматически удаляются.
|
||||
|
||||
Для запросов, читающих хоть немного приличный объём данных (миллион строк и больше), кэш разжатых блоков автоматически выключается, чтобы оставить место для действительно мелких запросов. Поэтому, можно держать настройку `use_uncompressed_cache` всегда выставленной в 1.
|
||||
|
||||
@ -850,7 +850,7 @@ ClickHouse генерирует исключение
|
||||
|
||||
Значение по умолчанию: 1.
|
||||
|
||||
По умолчанию блоки, вставляемые в реплицируемые таблицы оператором `INSERT`, дедуплицируются (см. [Репликация данных](../table_engines/replication.md)).
|
||||
По умолчанию блоки, вставляемые в реплицируемые таблицы оператором `INSERT`, дедуплицируются (см. [Репликация данных](../../engines/table_engines/mergetree_family/replication.md)).
|
||||
|
||||
## deduplicate\_blocks\_in\_dependent\_materialized\_views {#settings-deduplicate-blocks-in-dependent-materialized-views}
|
||||
|
||||
@ -869,15 +869,15 @@ ClickHouse генерирует исключение
|
||||
|
||||
## count\_distinct\_implementation {#settings-count_distinct_implementation}
|
||||
|
||||
Задаёт, какая из функций `uniq*` используется при выполнении конструкции [COUNT(DISTINCT …)](../../query_language/agg_functions/reference.md#agg_function-count).
|
||||
Задаёт, какая из функций `uniq*` используется при выполнении конструкции [COUNT(DISTINCT …)](../../sql_reference/aggregate_functions/reference.md#agg_function-count).
|
||||
|
||||
Возможные значения:
|
||||
|
||||
- [uniq](../../query_language/agg_functions/reference.md#agg_function-uniq)
|
||||
- [uniqCombined](../../query_language/agg_functions/reference.md#agg_function-uniqcombined)
|
||||
- [uniqCombined64](../../query_language/agg_functions/reference.md#agg_function-uniqcombined64)
|
||||
- [uniqHLL12](../../query_language/agg_functions/reference.md#agg_function-uniqhll12)
|
||||
- [uniqExact](../../query_language/agg_functions/reference.md#agg_function-uniqexact)
|
||||
- [uniq](../../sql_reference/aggregate_functions/reference.md#agg_function-uniq)
|
||||
- [uniqCombined](../../sql_reference/aggregate_functions/reference.md#agg_function-uniqcombined)
|
||||
- [uniqCombined64](../../sql_reference/aggregate_functions/reference.md#agg_function-uniqcombined64)
|
||||
- [uniqHLL12](../../sql_reference/aggregate_functions/reference.md#agg_function-uniqhll12)
|
||||
- [uniqExact](../../sql_reference/aggregate_functions/reference.md#agg_function-uniqexact)
|
||||
|
||||
Значение по умолчанию: `uniqExact`.
|
||||
|
||||
@ -957,7 +957,7 @@ ClickHouse генерирует исключение
|
||||
|
||||
## optimize\_throw\_if\_noop {#setting-optimize_throw_if_noop}
|
||||
|
||||
Включает или отключает генерирование исключения в в случаях, когда запрос [OPTIMIZE](../../query_language/misc.md#misc_operations-optimize) не выполняет мёрж.
|
||||
Включает или отключает генерирование исключения в в случаях, когда запрос [OPTIMIZE](../../sql_reference/statements/misc.md#misc_operations-optimize) не выполняет мёрж.
|
||||
|
||||
По умолчанию, `OPTIMIZE` завершается успешно и в тех случаях, когда он ничего не сделал. Настройка позволяет отделить подобные случаи и включает генерирование исключения с поясняющим сообщением.
|
||||
|
||||
@ -970,7 +970,7 @@ ClickHouse генерирует исключение
|
||||
|
||||
## distributed\_directory\_monitor\_sleep\_time\_ms {#distributed_directory_monitor_sleep_time_ms}
|
||||
|
||||
Основной интервал отправки данных движком таблиц [Distributed](../table_engines/distributed.md). Фактический интервал растёт экспоненциально при возникновении ошибок.
|
||||
Основной интервал отправки данных движком таблиц [Distributed](../../engines/table_engines/special/distributed.md). Фактический интервал растёт экспоненциально при возникновении ошибок.
|
||||
|
||||
Возможные значения:
|
||||
|
||||
@ -980,7 +980,7 @@ ClickHouse генерирует исключение
|
||||
|
||||
## distributed\_directory\_monitor\_max\_sleep\_time\_ms {#distributed_directory_monitor_max_sleep_time_ms}
|
||||
|
||||
Максимальный интервал отправки данных движком таблиц [Distributed](../table_engines/distributed.md). Ограничивает экпоненциальный рост интервала, установленого настройкой [distributed\_directory\_monitor\_sleep\_time\_ms](#distributed_directory_monitor_sleep_time_ms).
|
||||
Максимальный интервал отправки данных движком таблиц [Distributed](../../engines/table_engines/special/distributed.md). Ограничивает экпоненциальный рост интервала, установленого настройкой [distributed\_directory\_monitor\_sleep\_time\_ms](#distributed_directory_monitor_sleep_time_ms).
|
||||
|
||||
Возможные значения:
|
||||
|
||||
@ -992,7 +992,7 @@ ClickHouse генерирует исключение
|
||||
|
||||
Включает/выключает пакетную отправку вставленных данных.
|
||||
|
||||
Если пакетная отправка включена, то движок таблиц [Distributed](../table_engines/distributed.md) вместо того, чтобы отправлять каждый файл со вставленными данными по отдельности, старается отправить их все за одну операцию. Пакетная отправка улучшает производительность кластера за счет более оптимального использования ресурсов сервера и сети.
|
||||
Если пакетная отправка включена, то движок таблиц [Distributed](../../engines/table_engines/special/distributed.md) вместо того, чтобы отправлять каждый файл со вставленными данными по отдельности, старается отправить их все за одну операцию. Пакетная отправка улучшает производительность кластера за счет более оптимального использования ресурсов сервера и сети.
|
||||
|
||||
Возможные значения:
|
||||
|
||||
@ -1018,7 +1018,7 @@ ClickHouse генерирует исключение
|
||||
|
||||
## query\_profiler\_real\_time\_period\_ns {#query_profiler_real_time_period_ns}
|
||||
|
||||
Sets the period for a real clock timer of the [query profiler](../../operations/performance/sampling_query_profiler.md). Real clock timer counts wall-clock time.
|
||||
Sets the period for a real clock timer of the [query profiler](../../operations/optimizing_performance/sampling_query_profiler.md). Real clock timer counts wall-clock time.
|
||||
|
||||
Possible values:
|
||||
|
||||
@ -1031,7 +1031,7 @@ Possible values:
|
||||
|
||||
- 0 for turning off the timer.
|
||||
|
||||
Type: [UInt64](../../data_types/int_uint.md).
|
||||
Type: [UInt64](../../sql_reference/data_types/int_uint.md).
|
||||
|
||||
Default value: 1000000000 nanoseconds (once a second).
|
||||
|
||||
@ -1041,7 +1041,7 @@ See also:
|
||||
|
||||
## query\_profiler\_cpu\_time\_period\_ns {#query_profiler_cpu_time_period_ns}
|
||||
|
||||
Sets the period for a CPU clock timer of the [query profiler](../../operations/performance/sampling_query_profiler.md). This timer counts only CPU time.
|
||||
Sets the period for a CPU clock timer of the [query profiler](../../operations/optimizing_performance/sampling_query_profiler.md). This timer counts only CPU time.
|
||||
|
||||
Possible values:
|
||||
|
||||
@ -1054,7 +1054,7 @@ Possible values:
|
||||
|
||||
- 0 for turning off the timer.
|
||||
|
||||
Type: [UInt64](../../data_types/int_uint.md).
|
||||
Type: [UInt64](../../sql_reference/data_types/int_uint.md).
|
||||
|
||||
Default value: 1000000000 nanoseconds.
|
||||
|
||||
@ -1064,7 +1064,7 @@ See also:
|
||||
|
||||
## allow\_introspection\_functions {#settings-allow_introspection_functions}
|
||||
|
||||
Enables of disables [introspections functions](../../query_language/functions/introspection.md) for query profiling.
|
||||
Enables of disables [introspections functions](../../sql_reference/functions/introspection.md) for query profiling.
|
||||
|
||||
Possible values:
|
||||
|
||||
@ -1075,7 +1075,7 @@ Default value: 0.
|
||||
|
||||
**See Also**
|
||||
|
||||
- [Sampling Query Profiler](../performance/sampling_query_profiler.md)
|
||||
- [Sampling Query Profiler](../optimizing_performance/sampling_query_profiler.md)
|
||||
- System table [trace\_log](../../operations/system_tables.md#system_tables-trace_log)
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/settings/settings/) <!--hide-->
|
||||
|
||||
@ -139,6 +139,6 @@
|
||||
</user1>
|
||||
```
|
||||
|
||||
Элемент `filter` содержать любое выражение, возвращающее значение типа [UInt8](../../data_types/int_uint.md). Обычно он содержит сравнения и логические операторы. Строки `database_name.table1`, для которых фильтр возвращает 0 не выдаются пользователю. Фильтрация несовместима с операциями `PREWHERE` и отключает оптимизацию `WHERE→PREWHERE`.
|
||||
Элемент `filter` содержать любое выражение, возвращающее значение типа [UInt8](../../sql_reference/data_types/int_uint.md). Обычно он содержит сравнения и логические операторы. Строки `database_name.table1`, для которых фильтр возвращает 0 не выдаются пользователю. Фильтрация несовместима с операциями `PREWHERE` и отключает оптимизацию `WHERE→PREWHERE`.
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/settings/settings_users/) <!--hide-->
|
||||
|
||||
@ -12,8 +12,8 @@
|
||||
|
||||
Столбцы:
|
||||
|
||||
- `metric` ([String](../data_types/string.md)) — название метрики.
|
||||
- `value` ([Float64](../data_types/float.md)) — значение метрики.
|
||||
- `metric` ([String](../sql_reference/data_types/string.md)) — название метрики.
|
||||
- `value` ([Float64](../sql_reference/data_types/float.md)) — значение метрики.
|
||||
|
||||
**Пример**
|
||||
|
||||
@ -63,7 +63,7 @@ user String — имя пользователя, которого использ
|
||||
|
||||
Содержит информацию о столбцах всех таблиц.
|
||||
|
||||
С помощью этой таблицы можно получить информацию аналогично запросу [DESCRIBE TABLE](../query_language/misc.md#misc-describe-table), но для многих таблиц сразу.
|
||||
С помощью этой таблицы можно получить информацию аналогично запросу [DESCRIBE TABLE](../sql_reference/statements/misc.md#misc-describe-table), но для многих таблиц сразу.
|
||||
|
||||
Таблица `system.columns` содержит столбцы (тип столбца указан в скобках):
|
||||
|
||||
@ -131,41 +131,41 @@ SELECT * FROM system.contributors WHERE name='Olga Khvostikova'
|
||||
|
||||
## system.detached\_parts {#system_tables-detached_parts}
|
||||
|
||||
Содержит информацию об отсоединённых кусках таблиц семейства [MergeTree](table_engines/mergetree.md). Столбец `reason` содержит причину, по которой кусок был отсоединён. Для кусов, отсоединённых пользователем, `reason` содержит пустую строку.
|
||||
Такие куски могут быть присоединены с помощью [ALTER TABLE ATTACH PARTITION\|PART](../query_language/query_language/alter/#alter_attach-partition). Остальные столбцы описаны в [system.parts](#system_tables-parts).
|
||||
Если имя куска некорректно, значения некоторых столбцов могут быть `NULL`. Такие куски могут быть удалены с помощью [ALTER TABLE DROP DETACHED PART](../query_language/query_language/alter/#alter_drop-detached).
|
||||
Содержит информацию об отсоединённых кусках таблиц семейства [MergeTree](../engines/table_engines/mergetree_family/mergetree.md). Столбец `reason` содержит причину, по которой кусок был отсоединён. Для кусов, отсоединённых пользователем, `reason` содержит пустую строку.
|
||||
Такие куски могут быть присоединены с помощью [ALTER TABLE ATTACH PARTITION\|PART](../sql_reference/alter/#alter_attach-partition). Остальные столбцы описаны в [system.parts](#system_tables-parts).
|
||||
Если имя куска некорректно, значения некоторых столбцов могут быть `NULL`. Такие куски могут быть удалены с помощью [ALTER TABLE DROP DETACHED PART](../sql_reference/alter/#alter_drop-detached).
|
||||
|
||||
## system.dictionaries {#system_tables-dictionaries}
|
||||
|
||||
Содержит информацию о [внешних словарях](../query_language/dicts/external_dicts.md).
|
||||
Содержит информацию о [внешних словарях](../sql_reference/dictionaries/external_dictionaries/external_dicts.md).
|
||||
|
||||
Столбцы:
|
||||
|
||||
- `database` ([String](../data_types/string.md)) — Имя базы данных, в которой находится словарь, созданный с помощью DDL-запроса. Пустая строка для других словарей.
|
||||
- `name` ([String](../data_types/string.md)) — [Имя словаря](../query_language/dicts/external_dicts_dict.md).
|
||||
- `status` ([Enum8](../data_types/enum.md)) — Статус словаря. Возможные значения:
|
||||
- `database` ([String](../sql_reference/data_types/string.md)) — Имя базы данных, в которой находится словарь, созданный с помощью DDL-запроса. Пустая строка для других словарей.
|
||||
- `name` ([String](../sql_reference/data_types/string.md)) — [Имя словаря](../sql_reference/dictionaries/external_dictionaries/external_dicts_dict.md).
|
||||
- `status` ([Enum8](../sql_reference/data_types/enum.md)) — Статус словаря. Возможные значения:
|
||||
- `NOT_LOADED` — Словарь не загружен, потому что не использовался.
|
||||
- `LOADED` — Словарь загружен успешно.
|
||||
- `FAILED` — Словарь не загружен в результате ошибки.
|
||||
- `LOADING` — Словарь в процессе загрузки.
|
||||
- `LOADED_AND_RELOADING` — Словарь загружен успешно, сейчас перезагружается (частые причины: запрос [SYSTEM RELOAD DICTIONARY](../query_language/system.md#query_language-system-reload-dictionary), таймаут, изменение настроек словаря).
|
||||
- `LOADED_AND_RELOADING` — Словарь загружен успешно, сейчас перезагружается (частые причины: запрос [SYSTEM RELOAD DICTIONARY](../sql_reference/statements/system.md#query_language-system-reload-dictionary), таймаут, изменение настроек словаря).
|
||||
- `FAILED_AND_RELOADING` — Словарь не загружен в результате ошибки, сейчас перезагружается.
|
||||
- `origin` ([String](../data_types/string.md)) — Путь к конфигурационному файлу, описывающему словарь.
|
||||
- `type` ([String](../data_types/string.md)) — Тип размещения словаря. [Хранение словарей в памяти](../query_language/dicts/external_dicts_dict_layout.md).
|
||||
- `key` — [Тип ключа](../query_language/dicts/external_dicts_dict_structure.md#ext_dict_structure-key): Числовой ключ ([UInt64](../data_types/int_uint.md#uint-ranges)) или Составной ключ ([String](../data_types/string.md)) — строка вида "(тип 1, тип 2, ..., тип n)".
|
||||
- `attribute.names` ([Array](../data_types/array.md)([String](../data_types/string.md))) — Массив [имен атрибутов](../query_language/dicts/external_dicts_dict_structure.md#ext_dict_structure-attributes), предоставляемых справочником.
|
||||
- `attribute.types` ([Array](../data_types/array.md)([String](../data_types/string.md))) — Соответствующий массив [типов атрибутов](../query_language/dicts/external_dicts_dict_structure.md#ext_dict_structure-attributes), предоставляемых справочником.
|
||||
- `bytes_allocated` ([UInt64](../data_types/int_uint.md#uint-ranges)) — Объем оперативной памяти, используемый словарем.
|
||||
- `query_count` ([UInt64](../data_types/int_uint.md#uint-ranges)) — Количество запросов с момента загрузки словаря или с момента последней успешной перезагрузки.
|
||||
- `hit_rate` ([Float64](../data_types/float.md)) — Для cache-словарей — процент закэшированных значений.
|
||||
- `element_count` ([UInt64](../data_types/int_uint.md#uint-ranges)) — Количество элементов, хранящихся в словаре.
|
||||
- `load_factor` ([Float64](../data_types/float.md)) — Процент заполнения словаря (для хэшированного словаря — процент заполнения хэш-таблицы).
|
||||
- `source` ([String](../data_types/string.md)) — Текст, описывающий [источник данных](../query_language/dicts/external_dicts_dict_sources.md) для словаря.
|
||||
- `lifetime_min` ([UInt64](../data_types/int_uint.md#uint-ranges)) — Минимальное [время обновления](../query_language/dicts/external_dicts_dict_lifetime.md) словаря в памяти, по истечении которого Clickhouse попытается перезагрузить словарь (если задано `invalidate_query`, то только если он изменился). Задается в секундах.
|
||||
- `lifetime_max` ([UInt64](../data_types/int_uint.md#uint-ranges)) — Максимальное [время обновления](../query_language/dicts/external_dicts_dict_lifetime.md) словаря в памяти, по истечении которого Clickhouse попытается перезагрузить словарь (если задано `invalidate_query`, то только если он изменился). Задается в секундах.
|
||||
- `loading_start_time` ([DateTime](../data_types/datetime.md)) — Время начала загрузки словаря.
|
||||
- `loading_duration` ([Float32](../data_types/float.md)) — Время, затраченное на загрузку словаря.
|
||||
- `last_exception` ([String](../data_types/string.md)) — Текст ошибки, возникающей при создании или перезагрузке словаря, если словарь не удалось создать.
|
||||
- `origin` ([String](../sql_reference/data_types/string.md)) — Путь к конфигурационному файлу, описывающему словарь.
|
||||
- `type` ([String](../sql_reference/data_types/string.md)) — Тип размещения словаря. [Хранение словарей в памяти](../sql_reference/dictionaries/external_dictionaries/external_dicts_dict_layout.md).
|
||||
- `key` — [Тип ключа](../sql_reference/dictionaries/external_dictionaries/external_dicts_dict_structure.md#ext_dict_structure-key): Числовой ключ ([UInt64](../sql_reference/data_types/int_uint.md#uint-ranges)) или Составной ключ ([String](../sql_reference/data_types/string.md)) — строка вида "(тип 1, тип 2, ..., тип n)".
|
||||
- `attribute.names` ([Array](../sql_reference/data_types/array.md)([String](../sql_reference/data_types/string.md))) — Массив [имен атрибутов](../sql_reference/dictionaries/external_dictionaries/external_dicts_dict_structure.md#ext_dict_structure-attributes), предоставляемых справочником.
|
||||
- `attribute.types` ([Array](../sql_reference/data_types/array.md)([String](../sql_reference/data_types/string.md))) — Соответствующий массив [типов атрибутов](../sql_reference/dictionaries/external_dictionaries/external_dicts_dict_structure.md#ext_dict_structure-attributes), предоставляемых справочником.
|
||||
- `bytes_allocated` ([UInt64](../sql_reference/data_types/int_uint.md#uint-ranges)) — Объем оперативной памяти, используемый словарем.
|
||||
- `query_count` ([UInt64](../sql_reference/data_types/int_uint.md#uint-ranges)) — Количество запросов с момента загрузки словаря или с момента последней успешной перезагрузки.
|
||||
- `hit_rate` ([Float64](../sql_reference/data_types/float.md)) — Для cache-словарей — процент закэшированных значений.
|
||||
- `element_count` ([UInt64](../sql_reference/data_types/int_uint.md#uint-ranges)) — Количество элементов, хранящихся в словаре.
|
||||
- `load_factor` ([Float64](../sql_reference/data_types/float.md)) — Процент заполнения словаря (для хэшированного словаря — процент заполнения хэш-таблицы).
|
||||
- `source` ([String](../sql_reference/data_types/string.md)) — Текст, описывающий [источник данных](../sql_reference/dictionaries/external_dictionaries/external_dicts_dict_sources.md) для словаря.
|
||||
- `lifetime_min` ([UInt64](../sql_reference/data_types/int_uint.md#uint-ranges)) — Минимальное [время обновления](../sql_reference/dictionaries/external_dictionaries/external_dicts_dict_lifetime.md) словаря в памяти, по истечении которого Clickhouse попытается перезагрузить словарь (если задано `invalidate_query`, то только если он изменился). Задается в секундах.
|
||||
- `lifetime_max` ([UInt64](../sql_reference/data_types/int_uint.md#uint-ranges)) — Максимальное [время обновления](../sql_reference/dictionaries/external_dictionaries/external_dicts_dict_lifetime.md) словаря в памяти, по истечении которого Clickhouse попытается перезагрузить словарь (если задано `invalidate_query`, то только если он изменился). Задается в секундах.
|
||||
- `loading_start_time` ([DateTime](../sql_reference/data_types/datetime.md)) — Время начала загрузки словаря.
|
||||
- `loading_duration` ([Float32](../sql_reference/data_types/float.md)) — Время, затраченное на загрузку словаря.
|
||||
- `last_exception` ([String](../sql_reference/data_types/string.md)) — Текст ошибки, возникающей при создании или перезагрузке словаря, если словарь не удалось создать.
|
||||
|
||||
**Пример**
|
||||
|
||||
@ -202,9 +202,9 @@ SELECT * FROM system.dictionaries
|
||||
|
||||
Столбцы:
|
||||
|
||||
- `event` ([String](../data_types/string.md)) — имя события.
|
||||
- `value` ([UInt64](../data_types/int_uint.md)) — количество произошедших событий.
|
||||
- `description` ([String](../data_types/string.md)) — описание события.
|
||||
- `event` ([String](../sql_reference/data_types/string.md)) — имя события.
|
||||
- `value` ([UInt64](../sql_reference/data_types/int_uint.md)) — количество произошедших событий.
|
||||
- `description` ([String](../sql_reference/data_types/string.md)) — описание события.
|
||||
|
||||
**Пример**
|
||||
|
||||
@ -240,7 +240,7 @@ SELECT * FROM system.events LIMIT 5
|
||||
|
||||
## system.graphite\_retentions {#system-graphite-retentions}
|
||||
|
||||
Содержит информацию о том, какие параметры [graphite\_rollup](server_settings/settings.md#server_settings-graphite_rollup) используются в таблицах с движками [\*GraphiteMergeTree](table_engines/graphitemergetree.md).
|
||||
Содержит информацию о том, какие параметры [graphite\_rollup](server_configuration_parameters/settings.md#server_configuration_parameters-graphite_rollup) используются в таблицах с движками [\*GraphiteMergeTree](../engines/table_engines/mergetree_family/graphitemergetree.md).
|
||||
|
||||
Столбцы:
|
||||
|
||||
@ -280,9 +280,9 @@ SELECT * FROM system.events LIMIT 5
|
||||
|
||||
Столбцы:
|
||||
|
||||
- `metric` ([String](../data_types/string.md)) — название метрики.
|
||||
- `value` ([Int64](../data_types/int_uint.md)) — значение метрики.
|
||||
- `description` ([String](../data_types/string.md)) — описание метрики.
|
||||
- `metric` ([String](../sql_reference/data_types/string.md)) — название метрики.
|
||||
- `value` ([Int64](../sql_reference/data_types/int_uint.md)) — значение метрики.
|
||||
- `description` ([String](../sql_reference/data_types/string.md)) — описание метрики.
|
||||
|
||||
Список поддержанных метрик смотрите в файле [src/Common/CurrentMetrics.cpp](https://github.com/ClickHouse/ClickHouse/blob/master/src/Common/CurrentMetrics.cpp).
|
||||
|
||||
@ -389,13 +389,13 @@ CurrentMetric_ReplicatedChecks: 0
|
||||
|
||||
## system.parts {#system_tables-parts}
|
||||
|
||||
Содержит информацию о кусках данных таблиц семейства [MergeTree](table_engines/mergetree.md).
|
||||
Содержит информацию о кусках данных таблиц семейства [MergeTree](../engines/table_engines/mergetree_family/mergetree.md).
|
||||
|
||||
Каждая строка описывает один кусок данных.
|
||||
|
||||
Столбцы:
|
||||
|
||||
- `partition` (`String`) – Имя партиции. Что такое партиция можно узнать из описания запроса [ALTER](../query_language/alter.md#query_language_queries_alter).
|
||||
- `partition` (`String`) – Имя партиции. Что такое партиция можно узнать из описания запроса [ALTER](../sql_reference/statements/alter.md#sql_reference_queries_alter).
|
||||
|
||||
Форматы:
|
||||
|
||||
@ -446,7 +446,7 @@ CurrentMetric_ReplicatedChecks: 0
|
||||
|
||||
- `primary_key_bytes_in_memory_allocated` (`UInt64`) – объём памяти (в байтах) выделенный для размещения первичных ключей.
|
||||
|
||||
- `is_frozen` (`UInt8`) – Признак, показывающий существование бэкапа партиции. 1, бэкап есть. 0, бэкапа нет. Смотрите раздел [FREEZE PARTITION](../query_language/alter.md#alter_freeze-partition).
|
||||
- `is_frozen` (`UInt8`) – Признак, показывающий существование бэкапа партиции. 1, бэкап есть. 0, бэкапа нет. Смотрите раздел [FREEZE PARTITION](../sql_reference/statements/alter.md#alter_freeze-partition).
|
||||
|
||||
- `database` (`String`) – имя базы данных.
|
||||
|
||||
@ -458,11 +458,11 @@ CurrentMetric_ReplicatedChecks: 0
|
||||
|
||||
- `disk` (`String`) – имя диска, на котором находится кусок данных.
|
||||
|
||||
- `hash_of_all_files` (`String`) – значение [sipHash128](../query_language/functions/hash_functions.md#hash_functions-siphash128) для сжатых файлов.
|
||||
- `hash_of_all_files` (`String`) – значение [sipHash128](../sql_reference/functions/hash_functions.md#hash_functions-siphash128) для сжатых файлов.
|
||||
|
||||
- `hash_of_uncompressed_files` (`String`) – значение [sipHash128](../query_language/functions/hash_functions.md#hash_functions-siphash128) несжатых файлов (файлы с засечками, первичным ключом и пр.)
|
||||
- `hash_of_uncompressed_files` (`String`) – значение [sipHash128](../sql_reference/functions/hash_functions.md#hash_functions-siphash128) несжатых файлов (файлы с засечками, первичным ключом и пр.)
|
||||
|
||||
- `uncompressed_hash_of_compressed_files` (`String`) – значение [sipHash128](../query_language/functions/hash_functions.md#hash_functions-siphash128) данных в сжатых файлах как если бы они были разжатыми.
|
||||
- `uncompressed_hash_of_compressed_files` (`String`) – значение [sipHash128](../sql_reference/functions/hash_functions.md#hash_functions-siphash128) данных в сжатых файлах как если бы они были разжатыми.
|
||||
|
||||
- `bytes` (`UInt64`) – алиас для `bytes_on_disk`.
|
||||
|
||||
@ -470,9 +470,9 @@ CurrentMetric_ReplicatedChecks: 0
|
||||
|
||||
## system.part\_log {#system_tables-part-log}
|
||||
|
||||
Системная таблица `system.part_log` создается только в том случае, если задана серверная настройка [part\_log](server_settings/settings.md#server_settings-part-log).
|
||||
Системная таблица `system.part_log` создается только в том случае, если задана серверная настройка [part\_log](server_configuration_parameters/settings.md#server_configuration_parameters-part-log).
|
||||
|
||||
Содержит информацию о всех событиях, произошедших с [кусками данных](table_engines/custom_partitioning_key.md) таблиц семейства [MergeTree](table_engines/mergetree.md) (например, события добавления, удаления или слияния данных).
|
||||
Содержит информацию о всех событиях, произошедших с [кусками данных](../engines/table_engines/mergetree_family/custom_partitioning_key.md) таблиц семейства [MergeTree](../engines/table_engines/mergetree_family/mergetree.md) (например, события добавления, удаления или слияния данных).
|
||||
|
||||
Столбцы:
|
||||
|
||||
@ -480,7 +480,7 @@ CurrentMetric_ReplicatedChecks: 0
|
||||
- `NEW_PART` — вставка нового куска.
|
||||
- `MERGE_PARTS` — слияние кусков.
|
||||
- `DOWNLOAD_PART` — загрузка с реплики.
|
||||
- `REMOVE_PART` — удаление или отсоединение из таблицы с помощью [DETACH PARTITION](../query_language/alter.md#alter_detach-partition).
|
||||
- `REMOVE_PART` — удаление или отсоединение из таблицы с помощью [DETACH PARTITION](../sql_reference/statements/alter.md#alter_detach-partition).
|
||||
- `MUTATE_PART` — изменение куска.
|
||||
- `MOVE_PART` — перемещение куска между дисками.
|
||||
- `event_date` (Date) — дата события.
|
||||
@ -524,7 +524,7 @@ CurrentMetric_ReplicatedChecks: 0
|
||||
!!! note "Внимание"
|
||||
Таблица не содержит входных данных для запросов `INSERT`.
|
||||
|
||||
ClickHouse создаёт таблицу только в том случае, когда установлен конфигурационный параметр сервера [query\_log](server_settings/settings.md#server_settings-query-log). Параметр задаёт правила ведения лога, такие как интервал логирования или имя таблицы, в которую будут логгироваться запросы.
|
||||
ClickHouse создаёт таблицу только в том случае, когда установлен конфигурационный параметр сервера [query\_log](server_configuration_parameters/settings.md#server_configuration_parameters-query-log). Параметр задаёт правила ведения лога, такие как интервал логирования или имя таблицы, в которую будут логгироваться запросы.
|
||||
|
||||
Чтобы включить логирование, задайте значение параметра [log\_queries](settings/settings.md#settings-log-queries) равным 1. Подробности смотрите в разделе [Настройки](settings/settings.md).
|
||||
|
||||
@ -594,14 +594,14 @@ ClickHouse создаёт таблицу только в том случае, к
|
||||
2. Если во время обработки запроса произошла ошибка, создаются два события с типами 1 и 4.
|
||||
3. Если ошибка произошла до запуска запроса, создается одно событие с типом 3.
|
||||
|
||||
По умолчанию, строки добавляются в таблицу логирования с интервалом в 7,5 секунд. Можно задать интервал в конфигурационном параметре сервера [query\_log](server_settings/settings.md#server_settings-query-log) (смотрите параметр `flush_interval_milliseconds`). Чтобы принудительно записать логи из буффера памяти в таблицу, используйте запрос `SYSTEM FLUSH LOGS`.
|
||||
По умолчанию, строки добавляются в таблицу логирования с интервалом в 7,5 секунд. Можно задать интервал в конфигурационном параметре сервера [query\_log](server_configuration_parameters/settings.md#server_configuration_parameters-query-log) (смотрите параметр `flush_interval_milliseconds`). Чтобы принудительно записать логи из буффера памяти в таблицу, используйте запрос `SYSTEM FLUSH LOGS`.
|
||||
|
||||
Если таблицу удалить вручную, она пересоздастся автоматически «на лету». При этом все логи на момент удаления таблицы будут удалены.
|
||||
|
||||
!!! note "Примечание"
|
||||
Срок хранения логов не ограничен. Логи не удаляются из таблицы автоматически. Вам необходимо самостоятельно организовать удаление устаревших логов.
|
||||
|
||||
Можно указать произвольный ключ партиционирования для таблицы `system.query_log` в конфигурации [query\_log](server_settings/settings.md#server_settings-query-log) (параметр `partition_by`).
|
||||
Можно указать произвольный ключ партиционирования для таблицы `system.query_log` в конфигурации [query\_log](server_configuration_parameters/settings.md#server_configuration_parameters-query-log) (параметр `partition_by`).
|
||||
|
||||
## system.query\_log {#system_tables-query_log}
|
||||
|
||||
@ -610,7 +610,7 @@ Contains information about execution of queries. For each query, you can see pro
|
||||
!!! note "Note"
|
||||
The table doesn’t contain input data for `INSERT` queries.
|
||||
|
||||
ClickHouse creates this table only if the [query\_log](server_settings/settings.md#server_settings-query-log) server parameter is specified. This parameter sets the logging rules, such as the logging interval or the name of the table the queries will be logged in.
|
||||
ClickHouse creates this table only if the [query\_log](server_configuration_parameters/settings.md#server_configuration_parameters-query-log) server parameter is specified. This parameter sets the logging rules, such as the logging interval or the name of the table the queries will be logged in.
|
||||
|
||||
To enable query logging, set the [log\_queries](settings/settings.md#settings-log-queries) parameter to 1. For details, see the [Settings](settings/settings.md) section.
|
||||
|
||||
@ -680,19 +680,19 @@ Each query creates one or two rows in the `query_log` table, depending on the st
|
||||
2. If an error occurred during query processing, two events with types 1 and 4 are created.
|
||||
3. If an error occurred before launching the query, a single event with type 3 is created.
|
||||
|
||||
By default, logs are added to the table at intervals of 7.5 seconds. You can set this interval in the [query\_log](server_settings/settings.md#server_settings-query-log) server setting (see the `flush_interval_milliseconds` parameter). To flush the logs forcibly from the memory buffer into the table, use the `SYSTEM FLUSH LOGS` query.
|
||||
By default, logs are added to the table at intervals of 7.5 seconds. You can set this interval in the [query\_log](server_configuration_parameters/settings.md#server_configuration_parameters-query-log) server setting (see the `flush_interval_milliseconds` parameter). To flush the logs forcibly from the memory buffer into the table, use the `SYSTEM FLUSH LOGS` query.
|
||||
|
||||
When the table is deleted manually, it will be automatically created on the fly. Note that all the previous logs will be deleted.
|
||||
|
||||
!!! note "Note"
|
||||
The storage period for logs is unlimited. Logs aren’t automatically deleted from the table. You need to organize the removal of outdated logs yourself.
|
||||
|
||||
You can specify an arbitrary partitioning key for the `system.query_log` table in the [query\_log](server_settings/settings.md#server_settings-query-log) server setting (see the `partition_by` parameter).
|
||||
You can specify an arbitrary partitioning key for the `system.query_log` table in the [query\_log](server_configuration_parameters/settings.md#server_configuration_parameters-query-log) server setting (see the `partition_by` parameter).
|
||||
\#\# system.query\_thread\_log {\#system\_tables-query-thread-log}
|
||||
|
||||
Содержит информацию о каждом потоке выполняемых запросов.
|
||||
|
||||
ClickHouse создаёт таблицу только в том случае, когда установлен конфигурационный параметр сервера [query\_thread\_log](server_settings/settings.md#server_settings-query-thread-log). Параметр задаёт правила ведения лога, такие как интервал логирования или имя таблицы, в которую будут логгироваться запросы.
|
||||
ClickHouse создаёт таблицу только в том случае, когда установлен конфигурационный параметр сервера [query\_thread\_log](server_configuration_parameters/settings.md#server_configuration_parameters-query-thread-log). Параметр задаёт правила ведения лога, такие как интервал логирования или имя таблицы, в которую будут логгироваться запросы.
|
||||
|
||||
Чтобы включить логирование, задайте значение параметра [log\_query\_threads](settings/settings.md#settings-log-query-threads) равным 1. Подробности смотрите в разделе [Настройки](settings/settings.md).
|
||||
|
||||
@ -743,43 +743,43 @@ ClickHouse создаёт таблицу только в том случае, к
|
||||
- `ProfileEvents.Names` (Array(String)) — Счетчики для изменения различных метрик для данного потока. Описание метрик можно получить из таблицы [system.events](#system_tables-events)(\#system\_tables-events
|
||||
- `ProfileEvents.Values` (Array(UInt64)) — метрики для данного потока, перечисленные в столбце `ProfileEvents.Names`.
|
||||
|
||||
По умолчанию, строки добавляются в таблицу логирования с интервалом в 7,5 секунд. Можно задать интервал в конфигурационном параметре сервера [query\_thread\_log](server_settings/settings.md#server_settings-query-thread-log) (смотрите параметр `flush_interval_milliseconds`). Чтобы принудительно записать логи из буффера памяти в таблицу, используйте запрос `SYSTEM FLUSH LOGS`.
|
||||
По умолчанию, строки добавляются в таблицу логирования с интервалом в 7,5 секунд. Можно задать интервал в конфигурационном параметре сервера [query\_thread\_log](server_configuration_parameters/settings.md#server_configuration_parameters-query-thread-log) (смотрите параметр `flush_interval_milliseconds`). Чтобы принудительно записать логи из буффера памяти в таблицу, используйте запрос `SYSTEM FLUSH LOGS`.
|
||||
|
||||
Если таблицу удалить вручную, она пересоздастся автоматически «на лету». При этом все логи на момент удаления таблицы будут удалены.
|
||||
|
||||
!!! note "Примечание"
|
||||
Срок хранения логов не ограничен. Логи не удаляются из таблицы автоматически. Вам необходимо самостоятельно организовать удаление устаревших логов.
|
||||
|
||||
Можно указать произвольный ключ партиционирования для таблицы `system.query_log` в конфигурации [query\_thread\_log](server_settings/settings.md#server_settings-query-thread-log) (параметр `partition_by`).
|
||||
Можно указать произвольный ключ партиционирования для таблицы `system.query_log` в конфигурации [query\_thread\_log](server_configuration_parameters/settings.md#server_configuration_parameters-query-thread-log) (параметр `partition_by`).
|
||||
|
||||
## system.trace\_log {#system_tables-trace_log}
|
||||
|
||||
Contains stack traces collected by the sampling query profiler.
|
||||
|
||||
ClickHouse creates this table when the [trace\_log](server_settings/settings.md#server_settings-trace_log) server configuration section is set. Also the [query\_profiler\_real\_time\_period\_ns](settings/settings.md#query_profiler_real_time_period_ns) and [query\_profiler\_cpu\_time\_period\_ns](settings/settings.md#query_profiler_cpu_time_period_ns) settings should be set.
|
||||
ClickHouse creates this table when the [trace\_log](server_configuration_parameters/settings.md#server_configuration_parameters-trace_log) server configuration section is set. Also the [query\_profiler\_real\_time\_period\_ns](settings/settings.md#query_profiler_real_time_period_ns) and [query\_profiler\_cpu\_time\_period\_ns](settings/settings.md#query_profiler_cpu_time_period_ns) settings should be set.
|
||||
|
||||
To analyze logs, use the `addressToLine`, `addressToSymbol` and `demangle` introspection functions.
|
||||
|
||||
Columns:
|
||||
|
||||
- `event_date`([Date](../data_types/date.md)) — Date of sampling moment.
|
||||
- `event_date`([Date](../sql_reference/data_types/date.md)) — Date of sampling moment.
|
||||
|
||||
- `event_time`([DateTime](../data_types/datetime.md)) — Timestamp of sampling moment.
|
||||
- `event_time`([DateTime](../sql_reference/data_types/datetime.md)) — Timestamp of sampling moment.
|
||||
|
||||
- `revision`([UInt32](../data_types/int_uint.md)) — ClickHouse server build revision.
|
||||
- `revision`([UInt32](../sql_reference/data_types/int_uint.md)) — ClickHouse server build revision.
|
||||
|
||||
When connecting to server by `clickhouse-client`, you see the string similar to `Connected to ClickHouse server version 19.18.1 revision 54429.`. This field contains the `revision`, but not the `version` of a server.
|
||||
|
||||
- `timer_type`([Enum8](../data_types/enum.md)) — Timer type:
|
||||
- `timer_type`([Enum8](../sql_reference/data_types/enum.md)) — Timer type:
|
||||
|
||||
- `Real` represents wall-clock time.
|
||||
- `CPU` represents CPU time.
|
||||
|
||||
- `thread_number`([UInt32](../data_types/int_uint.md)) — Thread identifier.
|
||||
- `thread_number`([UInt32](../sql_reference/data_types/int_uint.md)) — Thread identifier.
|
||||
|
||||
- `query_id`([String](../data_types/string.md)) — Query identifier that can be used to get details about a query that was running from the [query\_log](#system_tables-query_log) system table.
|
||||
- `query_id`([String](../sql_reference/data_types/string.md)) — Query identifier that can be used to get details about a query that was running from the [query\_log](#system_tables-query_log) system table.
|
||||
|
||||
- `trace`([Array(UInt64)](../data_types/array.md)) — Stack trace at the moment of sampling. Each element is a virtual memory address inside ClickHouse server process.
|
||||
- `trace`([Array(UInt64)](../sql_reference/data_types/array.md)) — Stack trace at the moment of sampling. Each element is a virtual memory address inside ClickHouse server process.
|
||||
|
||||
**Example**
|
||||
|
||||
@ -927,13 +927,13 @@ WHERE
|
||||
|
||||
Столбцы:
|
||||
|
||||
- `name` ([String](../data_types/string.md)) — имя настройки.
|
||||
- `value` ([String](../data_types/string.md)) — значение настройки.
|
||||
- `changed` ([UInt8](../data_types/int_uint.md#uint-ranges)) — показывает, изменена ли настройка по отношению к значению по умолчанию.
|
||||
- `description` ([String](../data_types/string.md)) — краткое описание настройки.
|
||||
- `min` ([Nullable](../data_types/nullable.md)([String](../data_types/string.md))) — минимальное значение настройки, если задано [ограничение](settings/constraints_on_settings.md#constraints-on-settings). Если нет, то поле содержит [NULL](../query_language/syntax.md#null-literal).
|
||||
- `max` ([Nullable](../data_types/nullable.md)([String](../data_types/string.md))) — максимальное значение настройки, если задано [ограничение](settings/constraints_on_settings.md#constraints-on-settings). Если нет, то поле содержит [NULL](../query_language/syntax.md#null-literal).
|
||||
- `readonly` ([UInt8](../data_types/int_uint.md#uint-ranges)) — Показывает, может ли пользователь изменять настройку:
|
||||
- `name` ([String](../sql_reference/data_types/string.md)) — имя настройки.
|
||||
- `value` ([String](../sql_reference/data_types/string.md)) — значение настройки.
|
||||
- `changed` ([UInt8](../sql_reference/data_types/int_uint.md#uint-ranges)) — показывает, изменена ли настройка по отношению к значению по умолчанию.
|
||||
- `description` ([String](../sql_reference/data_types/string.md)) — краткое описание настройки.
|
||||
- `min` ([Nullable](../sql_reference/data_types/nullable.md)([String](../sql_reference/data_types/string.md))) — минимальное значение настройки, если задано [ограничение](settings/constraints_on_settings.md#constraints-on-settings). Если нет, то поле содержит [NULL](../sql_reference/syntax.md#null-literal).
|
||||
- `max` ([Nullable](../sql_reference/data_types/nullable.md)([String](../sql_reference/data_types/string.md))) — максимальное значение настройки, если задано [ограничение](settings/constraints_on_settings.md#constraints-on-settings). Если нет, то поле содержит [NULL](../sql_reference/syntax.md#null-literal).
|
||||
- `readonly` ([UInt8](../sql_reference/data_types/int_uint.md#uint-ranges)) — Показывает, может ли пользователь изменять настройку:
|
||||
- `0` — Текущий пользователь может изменять настройку.
|
||||
- `1` — Текущий пользователь не может изменять настройку.
|
||||
|
||||
@ -1013,9 +1013,9 @@ WHERE name in ('Kafka', 'MergeTree', 'ReplicatedCollapsingMergeTree')
|
||||
|
||||
**Смотрите также**
|
||||
|
||||
- [Секции движка](table_engines/mergetree/#mergetree-query-clauses) семейства MergeTree
|
||||
- [Настройки](table_engines/kafka.md#table_engine-kafka-creating-a-table) Kafka
|
||||
- [Настройки](table_engines/join/#join-limitations-and-settings) Join
|
||||
- [Секции движка](../engines/table_engines/mergetree_family/mergetree.md#mergetree-query-clauses) семейства MergeTree
|
||||
- [Настройки](../engines/table_engines/integrations/kafka.md#table_engine-kafka-creating-a-table) Kafka
|
||||
- [Настройки](../engines/table_engines/special/join.md#join-limitations-and-settings) Join
|
||||
|
||||
## system.tables {#system-tables}
|
||||
|
||||
@ -1031,7 +1031,7 @@ WHERE name in ('Kafka', 'MergeTree', 'ReplicatedCollapsingMergeTree')
|
||||
- `metadata_path` (String) — путь к табличным метаданным в файловой системе.
|
||||
- `metadata_modification_time` (DateTime) — время последней модификации табличных метаданных.
|
||||
- `dependencies_database` (Array(String)) — зависимости базы данных.
|
||||
- `dependencies_table` (Array(String)) — табличные зависимости (таблицы [MaterializedView](table_engines/materializedview.md), созданные на базе текущей таблицы).
|
||||
- `dependencies_table` (Array(String)) — табличные зависимости (таблицы [MaterializedView](../engines/table_engines/special/materializedview.md), созданные на базе текущей таблицы).
|
||||
- `create_table_query` (String) — запрос, которым создавалась таблица.
|
||||
- `engine_full` (String) — параметры табличного движка.
|
||||
- `partition_key` (String) — ключ партиционирования таблицы.
|
||||
@ -1114,7 +1114,7 @@ path: /clickhouse/tables/01-08/visits/replicas
|
||||
|
||||
## system.mutations {#system_tables-mutations}
|
||||
|
||||
Таблица содержит информацию о ходе выполнения [мутаций](../query_language/alter.md#alter-mutations) MergeTree-таблиц. Каждой команде мутации соответствует одна строка. В таблице есть следующие столбцы:
|
||||
Таблица содержит информацию о ходе выполнения [мутаций](../sql_reference/statements/alter.md#alter-mutations) MergeTree-таблиц. Каждой команде мутации соответствует одна строка. В таблице есть следующие столбцы:
|
||||
|
||||
**database**, **table** - имя БД и таблицы, к которой была применена мутация.
|
||||
|
||||
@ -1140,28 +1140,28 @@ path: /clickhouse/tables/01-08/visits/replicas
|
||||
|
||||
## system.disks {#system_tables-disks}
|
||||
|
||||
Cодержит информацию о дисках, заданных в [конфигурации сервера](table_engines/mergetree.md#table_engine-mergetree-multiple-volumes_configure).
|
||||
Cодержит информацию о дисках, заданных в [конфигурации сервера](../engines/table_engines/mergetree_family/mergetree.md#table_engine-mergetree-multiple-volumes_configure).
|
||||
|
||||
Столбцы:
|
||||
|
||||
- `name` ([String](../data_types/string.md)) — имя диска в конфигурации сервера.
|
||||
- `path` ([String](../data_types/string.md)) — путь к точке монтирования в файловой системе.
|
||||
- `free_space` ([UInt64](../data_types/int_uint.md)) — свободное место на диске в байтах.
|
||||
- `total_space` ([UInt64](../data_types/int_uint.md)) — объём диска в байтах.
|
||||
- `keep_free_space` ([UInt64](../data_types/int_uint.md)) — место, которое должно остаться свободным на диске в байтах. Задаётся значением параметра `keep_free_space_bytes` конфигурации дисков.
|
||||
- `name` ([String](../sql_reference/data_types/string.md)) — имя диска в конфигурации сервера.
|
||||
- `path` ([String](../sql_reference/data_types/string.md)) — путь к точке монтирования в файловой системе.
|
||||
- `free_space` ([UInt64](../sql_reference/data_types/int_uint.md)) — свободное место на диске в байтах.
|
||||
- `total_space` ([UInt64](../sql_reference/data_types/int_uint.md)) — объём диска в байтах.
|
||||
- `keep_free_space` ([UInt64](../sql_reference/data_types/int_uint.md)) — место, которое должно остаться свободным на диске в байтах. Задаётся значением параметра `keep_free_space_bytes` конфигурации дисков.
|
||||
|
||||
## system.storage\_policies {#system_tables-storage_policies}
|
||||
|
||||
Содержит информацию о политиках хранения и томах, заданных в [конфигурации сервера](table_engines/mergetree.md#table_engine-mergetree-multiple-volumes_configure).
|
||||
Содержит информацию о политиках хранения и томах, заданных в [конфигурации сервера](../engines/table_engines/mergetree_family/mergetree.md#table_engine-mergetree-multiple-volumes_configure).
|
||||
|
||||
Столбцы:
|
||||
|
||||
- `policy_name` ([String](../data_types/string.md)) — имя политики хранения.
|
||||
- `volume_name` ([String](../data_types/string.md)) — имя тома, который содержится в политике хранения.
|
||||
- `volume_priority` ([UInt64](../data_types/int_uint.md)) — порядковый номер тома согласно конфигурации.
|
||||
- `disks` ([Array(String)](../data_types/array.md)) — имена дисков, содержащихся в политике хранения.
|
||||
- `max_data_part_size` ([UInt64](../data_types/int_uint.md)) — максимальный размер куска данных, который может храниться на дисках тома (0 — без ограничений).
|
||||
- `move_factor` ([Float64](../data_types/float.md))\` — доля свободного места, при превышении которой данные начинают перемещаться на следующий том.
|
||||
- `policy_name` ([String](../sql_reference/data_types/string.md)) — имя политики хранения.
|
||||
- `volume_name` ([String](../sql_reference/data_types/string.md)) — имя тома, который содержится в политике хранения.
|
||||
- `volume_priority` ([UInt64](../sql_reference/data_types/int_uint.md)) — порядковый номер тома согласно конфигурации.
|
||||
- `disks` ([Array(String)](../sql_reference/data_types/array.md)) — имена дисков, содержащихся в политике хранения.
|
||||
- `max_data_part_size` ([UInt64](../sql_reference/data_types/int_uint.md)) — максимальный размер куска данных, который может храниться на дисках тома (0 — без ограничений).
|
||||
- `move_factor` ([Float64](../sql_reference/data_types/float.md))\` — доля свободного места, при превышении которой данные начинают перемещаться на следующий том.
|
||||
|
||||
Если политика хранения содержит несколько томов, то каждому тому соответствует отдельная запись в таблице.
|
||||
|
||||
|
||||
@ -1,58 +0,0 @@
|
||||
---
|
||||
en_copy: true
|
||||
---
|
||||
|
||||
# GenerateRandom {#table_engines-generate}
|
||||
|
||||
The GenerateRandom table engine produces random data for given table schema.
|
||||
|
||||
Usage examples:
|
||||
|
||||
- Use in test to populate reproducible large table.
|
||||
- Generate random input for fuzzing tests.
|
||||
|
||||
## Usage in ClickHouse Server {#usage-in-clickhouse-server}
|
||||
|
||||
``` sql
|
||||
ENGINE = GenerateRandom(random_seed, max_string_length, max_array_length)
|
||||
```
|
||||
|
||||
The `max_array_length` and `max_string_length` parameters specify maximum length of all
|
||||
array columns and strings correspondingly in generated data.
|
||||
|
||||
Generate table engine supports only `SELECT` queries.
|
||||
|
||||
It supports all [DataTypes](../../data_types/index.md) that can be stored in a table except `LowCardinality` and `AggregateFunction`.
|
||||
|
||||
**Example:**
|
||||
|
||||
**1.** Set up the `generate_engine_table` table:
|
||||
|
||||
``` sql
|
||||
CREATE TABLE generate_engine_table (name String, value UInt32) ENGINE = GenerateRandom(1, 5, 3)
|
||||
```
|
||||
|
||||
**2.** Query the data:
|
||||
|
||||
``` sql
|
||||
SELECT * FROM generate_engine_table LIMIT 3
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─name─┬──────value─┐
|
||||
│ c4xJ │ 1412771199 │
|
||||
│ r │ 1791099446 │
|
||||
│ 7#$ │ 124312908 │
|
||||
└──────┴────────────┘
|
||||
```
|
||||
|
||||
## Details of Implementation {#details-of-implementation}
|
||||
|
||||
- Not supported:
|
||||
- `ALTER`
|
||||
- `SELECT ... SAMPLE`
|
||||
- `INSERT`
|
||||
- Indices
|
||||
- Replication
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/operations/table_engines/generate/) <!--hide-->
|
||||
@ -1,5 +0,0 @@
|
||||
# MaterializedView {#materializedview}
|
||||
|
||||
Используется для реализации материализованных представлений (подробнее см. запрос [CREATE TABLE](../../query_language/create.md)). Для хранения данных, использует другой движок, который был указан при создании представления. При чтении из таблицы, просто использует этот движок.
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/operations/table_engines/materializedview/) <!--hide-->
|
||||
@ -98,7 +98,7 @@ $ sudo -u clickhouse /usr/bin/clickhouse-server --config-file /etc/clickhouse-se
|
||||
|
||||
- Параметры endpoint.
|
||||
|
||||
Проверьте настройки [listen_host](server_settings/settings.md#server_settings-listen_host) и [tcp_port](server_settings/settings.md#server_settings-tcp_port).
|
||||
Проверьте настройки [listen_host](server_configuration_parameters/settings.md#server_configuration_parameters-listen_host) и [tcp_port](server_configuration_parameters/settings.md#server_configuration_parameters-tcp_port).
|
||||
|
||||
По умолчанию, сервер ClickHouse принимает только локальные подключения.
|
||||
|
||||
|
||||
154
docs/ru/operations/utilities/clickhouse-benchmark.md
Normal file
154
docs/ru/operations/utilities/clickhouse-benchmark.md
Normal file
@ -0,0 +1,154 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 1cd5f0028d917696daf71ac1c9ee849c99c1d5c8
|
||||
---
|
||||
|
||||
# clickhouse-бенчмарк {#clickhouse-benchmark}
|
||||
|
||||
Подключается к серверу ClickHouse и повторно отправляет указанные запросы.
|
||||
|
||||
Синтаксис:
|
||||
|
||||
``` bash
|
||||
$ echo "single query" | clickhouse-benchmark [keys]
|
||||
```
|
||||
|
||||
или
|
||||
|
||||
``` bash
|
||||
$ clickhouse-benchmark [keys] <<< "single query"
|
||||
```
|
||||
|
||||
Если вы хотите отправить набор запросов, создайте текстовый файл и поместите каждый запрос в отдельную строку в этом файле. Например:
|
||||
|
||||
``` sql
|
||||
SELECT * FROM system.numbers LIMIT 10000000
|
||||
SELECT 1
|
||||
```
|
||||
|
||||
Затем передайте этот файл на стандартный вход `clickhouse-benchmark`.
|
||||
|
||||
``` bash
|
||||
clickhouse-benchmark [keys] < queries_file
|
||||
```
|
||||
|
||||
## Ключи {#clickhouse-benchmark-keys}
|
||||
|
||||
- `-c N`, `--concurrency=N` — Number of queries that `clickhouse-benchmark` посылает одновременно. Значение по умолчанию: 1.
|
||||
- `-d N`, `--delay=N` — Interval in seconds between intermediate reports (set 0 to disable reports). Default value: 1.
|
||||
- `-h WORD`, `--host=WORD` — Server host. Default value: `localhost`. Для [режим сравнения](#clickhouse-benchmark-comparison-mode) вы можете использовать несколько `-h` ключи.
|
||||
- `-p N`, `--port=N` — Server port. Default value: 9000. For the [режим сравнения](#clickhouse-benchmark-comparison-mode) вы можете использовать несколько `-p` ключи.
|
||||
- `-i N`, `--iterations=N` — Total number of queries. Default value: 0.
|
||||
- `-r`, `--randomize` — Random order of queries execution if there is more then one input query.
|
||||
- `-s`, `--secure` — Using TLS connection.
|
||||
- `-t N`, `--timelimit=N` — Time limit in seconds. `clickhouse-benchmark` прекращает отправку запросов по достижении указанного срока. Значение по умолчанию: 0 (ограничение по времени отключено).
|
||||
- `--confidence=N` — Level of confidence for T-test. Possible values: 0 (80%), 1 (90%), 2 (95%), 3 (98%), 4 (99%), 5 (99.5%). Default value: 5. In the [режим сравнения](#clickhouse-benchmark-comparison-mode) `clickhouse-benchmark` выполняет следующие функции: [Независимый двухпробный t-тест Стьюдента](https://en.wikipedia.org/wiki/Student%27s_t-test#Independent_two-sample_t-test) проверьте, не отличаются ли эти два распределения с выбранным уровнем достоверности.
|
||||
- `--cumulative` — Printing cumulative data instead of data per interval.
|
||||
- `--database=DATABASE_NAME` — ClickHouse database name. Default value: `default`.
|
||||
- `--json=FILEPATH` — JSON output. When the key is set, `clickhouse-benchmark` выводит отчет в указанный JSON-файл.
|
||||
- `--user=USERNAME` — ClickHouse user name. Default value: `default`.
|
||||
- `--password=PSWD` — ClickHouse user password. Default value: empty string.
|
||||
- `--stacktrace` — Stack traces output. When the key is set, `clickhouse-bencmark` выводит трассировки стека исключений.
|
||||
- `--stage=WORD` — Query processing stage at server. ClickHouse stops query processing and returns answer to `clickhouse-benchmark` на указанном этапе. Возможное значение: `complete`, `fetch_columns`, `with_mergeable_state`. Значение по умолчанию: `complete`.
|
||||
- `--help` — Shows the help message.
|
||||
|
||||
Если вы хотите применить некоторые из них [настройки](../../operations/settings/index.md) для запросов передайте их в качестве ключа `--<session setting name>= SETTING_VALUE`. Например, `--max_memory_usage=1048576`.
|
||||
|
||||
## Выход {#clickhouse-benchmark-output}
|
||||
|
||||
По умолчанию, `clickhouse-benchmark` отчеты для каждого из них `--delay` интервал.
|
||||
|
||||
Пример отчета:
|
||||
|
||||
``` text
|
||||
Queries executed: 10.
|
||||
|
||||
localhost:9000, queries 10, QPS: 6.772, RPS: 67904487.440, MiB/s: 518.070, result RPS: 67721584.984, result MiB/s: 516.675.
|
||||
|
||||
0.000% 0.145 sec.
|
||||
10.000% 0.146 sec.
|
||||
20.000% 0.146 sec.
|
||||
30.000% 0.146 sec.
|
||||
40.000% 0.147 sec.
|
||||
50.000% 0.148 sec.
|
||||
60.000% 0.148 sec.
|
||||
70.000% 0.148 sec.
|
||||
80.000% 0.149 sec.
|
||||
90.000% 0.150 sec.
|
||||
95.000% 0.150 sec.
|
||||
99.000% 0.150 sec.
|
||||
99.900% 0.150 sec.
|
||||
99.990% 0.150 sec.
|
||||
```
|
||||
|
||||
В отчете вы можете найти::
|
||||
|
||||
- Количество запросов в системе `Queries executed:` поле.
|
||||
|
||||
- Строка состояния, содержащая (по порядку):
|
||||
|
||||
- Конечная точка сервера ClickHouse.
|
||||
- Количество обработанных запросов.
|
||||
- QPS: QPS: сколько запросов сервер выполняет в секунду в течение периода, указанного в `--delay` аргумент.
|
||||
- RPS: сколько строк сервер читает в секунду в течение периода, указанного в `--delay` аргумент.
|
||||
- MiB/s: сколько мегабайт сервер читает в секунду в течение периода, указанного в `--delay` аргумент.
|
||||
- result RPS: сколько строк помещается сервером в результат запроса в секунду в течение периода, указанного в `--delay` аргумент.
|
||||
- результат MiB/s. сколько мебибайт помещается сервером в результат запроса в секунду в течение периода, указанного в `--delay` аргумент.
|
||||
|
||||
- Процентили времени выполнения запросов.
|
||||
|
||||
## Режим сравнения {#clickhouse-benchmark-comparison-mode}
|
||||
|
||||
`clickhouse-benchmark` можно сравнить производительность для двух запущенных серверов ClickHouse.
|
||||
|
||||
Чтобы использовать режим сравнения, укажите конечные точки обоих серверов по двум парам `--host`, `--port` ключи. Ключи, сопоставленные вместе по позиции в списке аргументов, первые `--host` сопоставляется с первым `--port` и так далее. `clickhouse-benchmark` устанавливает соединения с обоими серверами, а затем отправляет запросы. Каждый запрос адресован случайно выбранному серверу. Результаты отображаются для каждого сервера отдельно.
|
||||
|
||||
## Пример {#clickhouse-benchmark-example}
|
||||
|
||||
``` bash
|
||||
$ echo "SELECT * FROM system.numbers LIMIT 10000000 OFFSET 10000000" | clickhouse-benchmark -i 10
|
||||
```
|
||||
|
||||
``` text
|
||||
Loaded 1 queries.
|
||||
|
||||
Queries executed: 6.
|
||||
|
||||
localhost:9000, queries 6, QPS: 6.153, RPS: 123398340.957, MiB/s: 941.455, result RPS: 61532982.200, result MiB/s: 469.459.
|
||||
|
||||
0.000% 0.159 sec.
|
||||
10.000% 0.159 sec.
|
||||
20.000% 0.159 sec.
|
||||
30.000% 0.160 sec.
|
||||
40.000% 0.160 sec.
|
||||
50.000% 0.162 sec.
|
||||
60.000% 0.164 sec.
|
||||
70.000% 0.165 sec.
|
||||
80.000% 0.166 sec.
|
||||
90.000% 0.166 sec.
|
||||
95.000% 0.167 sec.
|
||||
99.000% 0.167 sec.
|
||||
99.900% 0.167 sec.
|
||||
99.990% 0.167 sec.
|
||||
|
||||
|
||||
|
||||
Queries executed: 10.
|
||||
|
||||
localhost:9000, queries 10, QPS: 6.082, RPS: 121959604.568, MiB/s: 930.478, result RPS: 60815551.642, result MiB/s: 463.986.
|
||||
|
||||
0.000% 0.159 sec.
|
||||
10.000% 0.159 sec.
|
||||
20.000% 0.160 sec.
|
||||
30.000% 0.163 sec.
|
||||
40.000% 0.164 sec.
|
||||
50.000% 0.165 sec.
|
||||
60.000% 0.166 sec.
|
||||
70.000% 0.166 sec.
|
||||
80.000% 0.167 sec.
|
||||
90.000% 0.167 sec.
|
||||
95.000% 0.170 sec.
|
||||
99.000% 0.172 sec.
|
||||
99.900% 0.172 sec.
|
||||
99.990% 0.172 sec.
|
||||
```
|
||||
@ -1,6 +1,6 @@
|
||||
# clickhouse-local {#clickhouse-local}
|
||||
|
||||
Принимает на вход данные, которые можно представить в табличном виде и выполняет над ними операции, заданные на [языке запросов](../../query_language/index.md) ClickHouse.
|
||||
Принимает на вход данные, которые можно представить в табличном виде и выполняет над ними операции, заданные на [языке запросов](../../operations/utilities/clickhouse-local.md) ClickHouse.
|
||||
|
||||
`clickhouse-local` использует движок сервера ClickHouse, т.е. поддерживает все форматы данных и движки таблиц, с которыми работает ClickHouse, при этом для выполнения операций не требуется запущенный сервер.
|
||||
|
||||
@ -1,153 +0,0 @@
|
||||
---
|
||||
en_copy: true
|
||||
---
|
||||
|
||||
# clickhouse-benchmark {#clickhouse-benchmark}
|
||||
|
||||
Connects to a ClickHouse server and repeatedly sends specified queries.
|
||||
|
||||
Syntax:
|
||||
|
||||
``` bash
|
||||
$ echo "single query" | clickhouse-benchmark [keys]
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
``` bash
|
||||
$ clickhouse-benchmark [keys] <<< "single query"
|
||||
```
|
||||
|
||||
If you want to send a set of queries, create a text file and place each query on the individual string in this file. For example:
|
||||
|
||||
``` sql
|
||||
SELECT * FROM system.numbers LIMIT 10000000
|
||||
SELECT 1
|
||||
```
|
||||
|
||||
Then pass this file to a standard input of `clickhouse-benchmark`.
|
||||
|
||||
``` bash
|
||||
clickhouse-benchmark [keys] < queries_file
|
||||
```
|
||||
|
||||
## Keys {#clickhouse-benchmark-keys}
|
||||
|
||||
- `-c N`, `--concurrency=N` — Number of queries that `clickhouse-benchmark` sends simultaneously. Default value: 1.
|
||||
- `-d N`, `--delay=N` — Interval in seconds between intermediate reports (set 0 to disable reports). Default value: 1.
|
||||
- `-h WORD`, `--host=WORD` — Server host. Default value: `localhost`. For the [comparison mode](#clickhouse-benchmark-comparison-mode) you can use multiple `-h` keys.
|
||||
- `-p N`, `--port=N` — Server port. Default value: 9000. For the [comparison mode](#clickhouse-benchmark-comparison-mode) you can use multiple `-p` keys.
|
||||
- `-i N`, `--iterations=N` — Total number of queries. Default value: 0.
|
||||
- `-r`, `--randomize` — Random order of queries execution if there is more then one input query.
|
||||
- `-s`, `--secure` — Using TLS connection.
|
||||
- `-t N`, `--timelimit=N` — Time limit in seconds. `clickhouse-benchmark` stops sending queries when the specified time limit is reached. Default value: 0 (time limit disabled).
|
||||
- `--confidence=N` — Level of confidence for T-test. Possible values: 0 (80%), 1 (90%), 2 (95%), 3 (98%), 4 (99%), 5 (99.5%). Default value: 5. In the [comparison mode](#clickhouse-benchmark-comparison-mode) `clickhouse-benchmark` performs the [Independent two-sample Student’s t-test](https://en.wikipedia.org/wiki/Student%27s_t-test#Independent_two-sample_t-test) test to determine whether the two distributions aren’t different with the selected level of confidence.
|
||||
- `--cumulative` — Printing cumulative data instead of data per interval.
|
||||
- `--database=DATABASE_NAME` — ClickHouse database name. Default value: `default`.
|
||||
- `--json=FILEPATH` — JSON output. When the key is set, `clickhouse-benchmark` outputs a report to the specified JSON-file.
|
||||
- `--user=USERNAME` — ClickHouse user name. Default value: `default`.
|
||||
- `--password=PSWD` — ClickHouse user password. Default value: empty string.
|
||||
- `--stacktrace` — Stack traces output. When the key is set, `clickhouse-bencmark` outputs stack traces of exceptions.
|
||||
- `--stage=WORD` — Query processing stage at server. ClickHouse stops query processing and returns answer to `clickhouse-benchmark` at the specified stage. Possible values: `complete`, `fetch_columns`, `with_mergeable_state`. Default value: `complete`.
|
||||
- `--help` — Shows the help message.
|
||||
|
||||
If you want to apply some [settings](../../operations/settings/index.md) for queries, pass them as a key `--<session setting name>= SETTING_VALUE`. For example, `--max_memory_usage=1048576`.
|
||||
|
||||
## Output {#clickhouse-benchmark-output}
|
||||
|
||||
By default, `clickhouse-benchmark` reports for each `--delay` interval.
|
||||
|
||||
Example of the report:
|
||||
|
||||
``` text
|
||||
Queries executed: 10.
|
||||
|
||||
localhost:9000, queries 10, QPS: 6.772, RPS: 67904487.440, MiB/s: 518.070, result RPS: 67721584.984, result MiB/s: 516.675.
|
||||
|
||||
0.000% 0.145 sec.
|
||||
10.000% 0.146 sec.
|
||||
20.000% 0.146 sec.
|
||||
30.000% 0.146 sec.
|
||||
40.000% 0.147 sec.
|
||||
50.000% 0.148 sec.
|
||||
60.000% 0.148 sec.
|
||||
70.000% 0.148 sec.
|
||||
80.000% 0.149 sec.
|
||||
90.000% 0.150 sec.
|
||||
95.000% 0.150 sec.
|
||||
99.000% 0.150 sec.
|
||||
99.900% 0.150 sec.
|
||||
99.990% 0.150 sec.
|
||||
```
|
||||
|
||||
In the report you can find:
|
||||
|
||||
- Number of queries in the `Queries executed:` field.
|
||||
|
||||
- Status string containing (in order):
|
||||
|
||||
- Endpoint of ClickHouse server.
|
||||
- Number of processed queries.
|
||||
- QPS: QPS: How many queries server performed per second during a period specified in the `--delay` argument.
|
||||
- RPS: How many rows server read per second during a period specified in the `--delay` argument.
|
||||
- MiB/s: How many mebibytes server read per second during a period specified in the `--delay` argument.
|
||||
- result RPS: How many rows placed by server to the result of a query per second during a period specified in the `--delay` argument.
|
||||
- result MiB/s. How many mebibytes placed by server to the result of a query per second during a period specified in the `--delay` argument.
|
||||
|
||||
- Percentiles of queries execution time.
|
||||
|
||||
## Comparison mode {#clickhouse-benchmark-comparison-mode}
|
||||
|
||||
`clickhouse-benchmark` can compare performances for two running ClickHouse servers.
|
||||
|
||||
To use the comparison mode, specify endpoints of both servers by two pairs of `--host`, `--port` keys. Keys matched together by position in arguments list, the first `--host` is matched with the first `--port` and so on. `clickhouse-benchmark` establishes connections to both servers, then sends queries. Each query addressed to a randomly selected server. The results are shown for each server separately.
|
||||
|
||||
## Example {#clickhouse-benchmark-example}
|
||||
|
||||
``` bash
|
||||
$ echo "SELECT * FROM system.numbers LIMIT 10000000 OFFSET 10000000" | clickhouse-benchmark -i 10
|
||||
```
|
||||
|
||||
``` text
|
||||
Loaded 1 queries.
|
||||
|
||||
Queries executed: 6.
|
||||
|
||||
localhost:9000, queries 6, QPS: 6.153, RPS: 123398340.957, MiB/s: 941.455, result RPS: 61532982.200, result MiB/s: 469.459.
|
||||
|
||||
0.000% 0.159 sec.
|
||||
10.000% 0.159 sec.
|
||||
20.000% 0.159 sec.
|
||||
30.000% 0.160 sec.
|
||||
40.000% 0.160 sec.
|
||||
50.000% 0.162 sec.
|
||||
60.000% 0.164 sec.
|
||||
70.000% 0.165 sec.
|
||||
80.000% 0.166 sec.
|
||||
90.000% 0.166 sec.
|
||||
95.000% 0.167 sec.
|
||||
99.000% 0.167 sec.
|
||||
99.900% 0.167 sec.
|
||||
99.990% 0.167 sec.
|
||||
|
||||
|
||||
|
||||
Queries executed: 10.
|
||||
|
||||
localhost:9000, queries 10, QPS: 6.082, RPS: 121959604.568, MiB/s: 930.478, result RPS: 60815551.642, result MiB/s: 463.986.
|
||||
|
||||
0.000% 0.159 sec.
|
||||
10.000% 0.159 sec.
|
||||
20.000% 0.160 sec.
|
||||
30.000% 0.163 sec.
|
||||
40.000% 0.164 sec.
|
||||
50.000% 0.165 sec.
|
||||
60.000% 0.166 sec.
|
||||
70.000% 0.166 sec.
|
||||
80.000% 0.167 sec.
|
||||
90.000% 0.167 sec.
|
||||
95.000% 0.170 sec.
|
||||
99.000% 0.172 sec.
|
||||
99.900% 0.172 sec.
|
||||
99.990% 0.172 sec.
|
||||
```
|
||||
@ -1,9 +0,0 @@
|
||||
# Справка по SQL {#spravka-po-sql}
|
||||
|
||||
- [SELECT](select.md)
|
||||
- [INSERT INTO](insert_into.md)
|
||||
- [CREATE](create.md)
|
||||
- [ALTER](alter.md#query_language_queries_alter)
|
||||
- [Прочие виды запросов](misc.md)
|
||||
|
||||
[Оригинальная статья](https://clickhouse.tech/docs/ru/query_language/) <!--hide-->
|
||||
@ -1,16 +0,0 @@
|
||||
---
|
||||
en_copy: true
|
||||
---
|
||||
|
||||
# Roadmap {#roadmap}
|
||||
|
||||
## Q1 2020 {#q1-2020}
|
||||
|
||||
- Role-based access control
|
||||
|
||||
## Q2 2020 {#q2-2020}
|
||||
|
||||
- Integration with external authentication services
|
||||
- Resource pools for more precise distribution of cluster capacity between users
|
||||
|
||||
{## [Original article](https://clickhouse.tech/docs/en/roadmap/) ##}
|
||||
@ -27,9 +27,9 @@
|
||||
|
||||
Для работы с промежуточными состояниями предназначены:
|
||||
|
||||
- Движок таблиц [AggregatingMergeTree](../../operations/table_engines/aggregatingmergetree.md).
|
||||
- Функция [finalizeAggregation](../functions/other_functions.md#function-finalizeaggregation).
|
||||
- Функция [runningAccumulate](../functions/other_functions.md#function-runningaccumulate).
|
||||
- Движок таблиц [AggregatingMergeTree](../../engines/table_engines/mergetree_family/aggregatingmergetree.md).
|
||||
- Функция [finalizeAggregation](../../sql_reference/aggregate_functions/combinators.md#function-finalizeaggregation).
|
||||
- Функция [runningAccumulate](../../sql_reference/aggregate_functions/combinators.md#function-runningaccumulate).
|
||||
- Комбинатор [-Merge](#aggregate_functions_combinators_merge).
|
||||
- Комбинатор [-MergeState](#aggregate_functions_combinators_mergestate).
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user