thevar1able/ClickHouse
1
0
Fork 0
mirror of https://github.com/ClickHouse/ClickHouse.git synced 2024-11-24 16:42:05 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into joins

Browse Source
This commit is contained in:
Artem Zuikov 2020-04-16 19:00:04 +03:00
commit 47cb670213
493 changed files with 43086 additions and 1268 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.gitignore vendored
View File

@ -16,8 +16,8 @@
/docs/publish
/docs/edit
/docs/website
/docs/venv/
/docs/tools/venv/
/docs/venv
/docs/tools/venv
/docs/tools/translate/venv
/docs/tools/translate/output.md
/docs/en/single.md

2
.gitmodules vendored
View File

@ -13,7 +13,7 @@
url = https://github.com/edenhill/librdkafka.git
[submodule "contrib/cctz"]
path = contrib/cctz
url = https://github.com/google/cctz.git
url = https://github.com/ClickHouse-Extras/cctz.git
[submodule "contrib/zlib-ng"]
path = contrib/zlib-ng
url = https://github.com/ClickHouse-Extras/zlib-ng.git

18
CHANGELOG.md
View File

@ -1,5 +1,23 @@
## ClickHouse release v20.3
### ClickHouse release v20.3.5.21, 2020-03-27
#### Bug Fix
* Fix 'Different expressions with the same alias' error when query has PREWHERE and WHERE on distributed table and `SET distributed_product_mode = 'local'`. [#9871](https://github.com/ClickHouse/ClickHouse/pull/9871) ([Artem Zuikov](https://github.com/4ertus2)).
* Fix mutations excessive memory consumption for tables with a composite primary key. This fixes [#9850](https://github.com/ClickHouse/ClickHouse/issues/9850). [#9860](https://github.com/ClickHouse/ClickHouse/pull/9860) ([alesapin](https://github.com/alesapin)).
* Fix 'COMMA to CROSS JOIN rewriter is not enabled or cannot rewrite query' error in case of subqueries with COMMA JOIN out of tables lists (i.e. in WHERE). Fixes [#9782](https://github.com/ClickHouse/ClickHouse/issues/9782). [#9830](https://github.com/ClickHouse/ClickHouse/pull/9830) ([Artem Zuikov](https://github.com/4ertus2)).
* Fix possible exception `Got 0 in totals chunk, expected 1` on client. It happened for queries with `JOIN` in case if right joined table had zero rows. Example: `select * from system.one t1 join system.one t2 on t1.dummy = t2.dummy limit 0 FORMAT TabSeparated;`. Fixes [#9777](https://github.com/ClickHouse/ClickHouse/issues/9777). [#9823](https://github.com/ClickHouse/ClickHouse/pull/9823) ([Nikolai Kochetov](https://github.com/KochetovNicolai)).
* Fix SIGSEGV with optimize_skip_unused_shards when type cannot be converted. [#9804](https://github.com/ClickHouse/ClickHouse/pull/9804) ([Azat Khuzhin](https://github.com/azat)).
* Fix broken `ALTER TABLE DELETE COLUMN` query for compact parts. [#9779](https://github.com/ClickHouse/ClickHouse/pull/9779) ([alesapin](https://github.com/alesapin)).
* Fix max_distributed_connections (w/ and w/o Processors). [#9673](https://github.com/ClickHouse/ClickHouse/pull/9673) ([Azat Khuzhin](https://github.com/azat)).
* Fixed a few cases when timezone of the function argument wasn't used properly. [#9574](https://github.com/ClickHouse/ClickHouse/pull/9574) ([Vasily Nemkov](https://github.com/Enmk)).
#### Improvement
* Remove order by stage from mutations because we read from a single ordered part in a single thread. Also add check that the order of rows in mutation is ordered in sorting key order and this order is not violated. [#9886](https://github.com/ClickHouse/ClickHouse/pull/9886) ([alesapin](https://github.com/alesapin)).
### ClickHouse release v20.3.4.10, 2020-03-20
#### Bug Fix

3
README.md
View File

@ -11,10 +11,9 @@ ClickHouse is an open-source column-oriented database management system that all
* [Slack](https://join.slack.com/t/clickhousedb/shared_invite/zt-d2zxkf9e-XyxDa_ucfPxzuH4SJIm~Ng) and [Telegram](https://telegram.me/clickhouse_en) allow to chat with ClickHouse users in real-time.
* [Blog](https://clickhouse.yandex/blog/en/) contains various ClickHouse-related articles, as well as announces and reports about events.
* [Contacts](https://clickhouse.tech/#contacts) can help to get your questions answered if there are any.
* You can also [fill this form](https://forms.yandex.com/surveys/meet-yandex-clickhouse-team/) to meet Yandex ClickHouse team in person.
* You can also [fill this form](https://clickhouse.tech/#meet) to meet Yandex ClickHouse team in person.
## Upcoming Events
* [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.

6
cmake/tools.cmake
View File

@ -6,18 +6,18 @@ endif ()
if (COMPILER_GCC)
# Require minimum version of gcc
set (GCC_MINIMUM_VERSION 8)
set (GCC_MINIMUM_VERSION 9)
if (CMAKE_CXX_COMPILER_VERSION VERSION_LESS ${GCC_MINIMUM_VERSION} AND NOT CMAKE_VERSION VERSION_LESS 2.8.9)
message (FATAL_ERROR "GCC version must be at least ${GCC_MINIMUM_VERSION}. For example, if GCC ${GCC_MINIMUM_VERSION} is available under gcc-${GCC_MINIMUM_VERSION}, g++-${GCC_MINIMUM_VERSION} names, do the following: export CC=gcc-${GCC_MINIMUM_VERSION} CXX=g++-${GCC_MINIMUM_VERSION}; rm -rf CMakeCache.txt CMakeFiles; and re run cmake or ./release.")
endif ()
elseif (COMPILER_CLANG)
# Require minimum version of clang
set (CLANG_MINIMUM_VERSION 7)
set (CLANG_MINIMUM_VERSION 8)
if (CMAKE_CXX_COMPILER_VERSION VERSION_LESS ${CLANG_MINIMUM_VERSION})
message (FATAL_ERROR "Clang version must be at least ${CLANG_MINIMUM_VERSION}.")
endif ()
else ()
message (WARNING "You are using an unsupported compiler. Compilation has only been tested with Clang 6+ and GCC 7+.")
message (WARNING "You are using an unsupported compiler. Compilation has only been tested with Clang and GCC.")
endif ()
STRING(REGEX MATCHALL "[0-9]+" COMPILER_VERSION_LIST ${CMAKE_CXX_COMPILER_VERSION})

2
contrib/cctz vendored

@ -1 +1 @@
Subproject commit 4f9776a310f4952454636363def82c2bf6641d5f
Subproject commit 5a3f785329cecdd2b68cd950e0647e9246774ef2

3
docker/images.json
View File

@ -1,10 +1,10 @@
{
"docker/packager/deb": "yandex/clickhouse-deb-builder",
"docker/packager/binary": "yandex/clickhouse-binary-builder",
"docker/test/coverage": "yandex/clickhouse-coverage",
"docker/test/compatibility/centos": "yandex/clickhouse-test-old-centos",
"docker/test/compatibility/ubuntu": "yandex/clickhouse-test-old-ubuntu",
"docker/test/integration": "yandex/clickhouse-integration-test",
"docker/test/performance": "yandex/clickhouse-performance-test",
"docker/test/performance-comparison": "yandex/clickhouse-performance-comparison",
"docker/test/pvs": "yandex/clickhouse-pvs-test",
"docker/test/stateful": "yandex/clickhouse-stateful-test",
@ -14,5 +14,6 @@
"docker/test/unit": "yandex/clickhouse-unit-test",
"docker/test/stress": "yandex/clickhouse-stress-test",
"docker/test/split_build_smoke_test": "yandex/clickhouse-split-build-smoke-test",
"docker/test/codebrowser": "yandex/clickhouse-codebrowser",
"tests/integration/image": "yandex/clickhouse-integration-tests-runner"
}

4
docker/test/performance-comparison/compare.sh
View File

@ -42,9 +42,11 @@ function configure
rm db0/metadata/system/* -rf ||:
# Make copies of the original db for both servers. Use hardlinks instead
# of copying.
# of copying. Be careful to remove preprocessed configs or it can lead to
# weird effects.
rm -r left/db ||:
rm -r right/db ||:
rm -r db0/preprocessed_configs ||:
cp -al db0/ left/db/
cp -al db0/ right/db/
}

1
docker/test/stateless/Dockerfile
View File

@ -70,6 +70,7 @@ CMD dpkg -i package_folder/clickhouse-common-static_*.deb; \
ln -s /usr/share/clickhouse-test/config/disks.xml /etc/clickhouse-server/config.d/; \
ln -s /usr/share/clickhouse-test/config/secure_ports.xml /etc/clickhouse-server/config.d/; \
ln -s /usr/share/clickhouse-test/config/clusters.xml /etc/clickhouse-server/config.d/; \
ln -s /usr/share/clickhouse-test/config/graphite.xml /etc/clickhouse-server/config.d/; \
ln -s /usr/share/clickhouse-test/config/server.key /etc/clickhouse-server/; \
ln -s /usr/share/clickhouse-test/config/server.crt /etc/clickhouse-server/; \
ln -s /usr/share/clickhouse-test/config/dhparam.pem /etc/clickhouse-server/; \

6
docker/test/stateless_with_coverage/run.sh
View File

@ -14,6 +14,11 @@ kill_clickhouse () {
sleep 10
fi
done
echo "Will try to send second kill signal for sure"
kill `pgrep -u clickhouse` 2>/dev/null
sleep 5
echo "clickhouse pids" `ps aux | grep clickhouse` | ts '%Y-%m-%d %H:%M:%S'
}
start_clickhouse () {
@ -50,6 +55,7 @@ ln -s /usr/share/clickhouse-test/config/zookeeper.xml /etc/clickhouse-server/con
ln -s /usr/share/clickhouse-test/config/disks.xml /etc/clickhouse-server/config.d/; \
ln -s /usr/share/clickhouse-test/config/secure_ports.xml /etc/clickhouse-server/config.d/; \
ln -s /usr/share/clickhouse-test/config/clusters.xml /etc/clickhouse-server/config.d/; \
ln -s /usr/share/clickhouse-test/config/graphite.xml /etc/clickhouse-server/config.d/; \
ln -s /usr/share/clickhouse-test/config/server.key /etc/clickhouse-server/; \
ln -s /usr/share/clickhouse-test/config/server.crt /etc/clickhouse-server/; \
ln -s /usr/share/clickhouse-test/config/dhparam.pem /etc/clickhouse-server/; \

5
docs/en/commercial/cloud.md
View File

@ -1,3 +1,8 @@
---
toc_title: Cloud
toc_priority: 1
---
# ClickHouse Cloud Service Providers {#clickhouse-cloud-service-providers}
!!! info "Info"

21
docs/en/commercial/support.md Normal file
View File

@ -0,0 +1,21 @@
---
toc_title: Support
toc_priority: 3
---
# ClickHouse Commercial Support Service Providers {#clickhouse-commercial-support-service-providers}
!!! info "Info"
If you have launched a ClickHouse commercial support service, feel free to [open a pull-request](https://github.com/ClickHouse/ClickHouse/edit/master/docs/en/commercial/support.md) adding it to the following list.
## Altinity {#altinity}
[Service description](https://www.altinity.com/24x7-support)
## Mafiree {#mafiree}
[Service description](http://mafiree.com/clickhouse-analytics-services.php)
## MinervaDB {#minervadb}
[Service description](https://minervadb.com/index.php/clickhouse-consulting-and-support-by-minervadb/)

4
docs/en/development/browse_code.md
View File

@ -1,11 +1,11 @@
---
toc_priority: 63
toc_title: Browse ClickHouse Source Code
toc_title: Browse Source Code
---
# Browse ClickHouse Source Code {#browse-clickhouse-source-code}
You can use **Woboq** online code browser available [here](https://clickhouse.tech/codebrowser/html_report///ClickHouse/src/index.html). It provides code navigation and semantic highlighting, search and indexing. The code snapshot is updated daily.
You can use **Woboq** online code browser available [here](https://clickhouse.tech/codebrowser/html_report/ClickHouse/src/index.html). It provides code navigation and semantic highlighting, search and indexing. The code snapshot is updated daily.
Also, you can browse sources on [GitHub](https://github.com/ClickHouse/ClickHouse) as usual.

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

@ -1,5 +1,5 @@
---
toc_folder_title: Development
toc_folder_title: Разработка
toc_hidden: true
toc_priority: 58
toc_title: hidden

4
docs/en/getting_started/install.md
View File

@ -38,7 +38,7 @@ sudo apt-get update
sudo apt-get install clickhouse-client clickhouse-server
```
You can also download and install packages manually from here: https://repo.yandex.ru/clickhouse/deb/stable/main/.
You can also download and install packages manually from [here](https://repo.yandex.ru/clickhouse/deb/stable/main/).
#### Packages {#packages}
@ -67,7 +67,7 @@ Then run these commands to install packages:
sudo yum install clickhouse-server clickhouse-client
```
You can also download and install packages manually from here: https://repo.clickhouse.tech/rpm/stable/x86\_64.
You can also download and install packages manually from [here](https://repo.clickhouse.tech/rpm/stable/x86_64).
### From Tgz Archives {#from-tgz-archives}

8
docs/en/interfaces/third-party/integrations.md vendored
View File

@ -24,7 +24,10 @@ toc_title: Integrations
- [ClickHouseMigrator](https://github.com/zlzforever/ClickHouseMigrator)
- Message queues
- [Kafka](https://kafka.apache.org)
- [clickhouse\_sinker](https://github.com/housepower/clickhouse_sinker) (uses [Go client](https://github.com/kshvakov/clickhouse/))
- [clickhouse\_sinker](https://github.com/housepower/clickhouse_sinker) (uses [Go client](https://github.com/ClickHouse/clickhouse-go/))
- Stream processing
- [Flink](https://flink.apache.org)
- [flink-clickhouse-sink](https://github.com/ivi-ru/flink-clickhouse-sink)
- Object storages
- [S3](https://en.wikipedia.org/wiki/Amazon_S3)
- [clickhouse-backup](https://github.com/AlexAkulov/clickhouse-backup)
@ -72,6 +75,9 @@ toc_title: Integrations
- [sqlalchemy-clickhouse](https://github.com/cloudflare/sqlalchemy-clickhouse) (uses [infi.clickhouse\_orm](https://github.com/Infinidat/infi.clickhouse_orm))
- [pandas](https://pandas.pydata.org)
- [pandahouse](https://github.com/kszucs/pandahouse)
- PHP
- [Doctrine](https://www.doctrine-project.org/)
- [dbal-clickhouse](https://packagist.org/packages/friendsofdoctrine/dbal-clickhouse)
- R
- [dplyr](https://db.rstudio.com/dplyr/)
- [RClickHouse](https://github.com/IMSMWU/RClickHouse) (uses [clickhouse-cpp](https://github.com/artpaul/clickhouse-cpp))

4
docs/en/introduction/adopters.md
View File

@ -77,5 +77,9 @@ toc_title: Adopters
| [МКБ](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) |
| [Instana](https://www.instana.com) | APM Platform | Main product | — | — | [Twitter post](https://twitter.com/mieldonkers/status/1248884119158882304) |
| [Wargaming](https://wargaming.com/en/) | Games | | — | — | [Interview](https://habr.com/en/post/496954/) |
| [Crazypanda](https://crazypanda.ru/en/) | Games | | — | — | Live session on ClickHouse meetup |
| [FunCorp](https://fun.co/rp) | Games | | — | — | [Article](https://www.altinity.com/blog/migrating-from-redshift-to-clickhouse) |
[Original article](https://clickhouse.tech/docs/en/introduction/adopters/) <!--hide-->

35
docs/en/operations/settings/settings.md
View File

@ -220,21 +220,28 @@ Ok.
## input\_format\_values\_deduce\_templates\_of\_expressions {#settings-input_format_values_deduce_templates_of_expressions}
Enables or disables template deduction for an SQL expressions in [Values](../../interfaces/formats.md#data-format-values) format. It allows to parse and interpret expressions in `Values` much faster if expressions in consecutive rows have the same structure. ClickHouse will try to deduce template of an expression, parse the following rows using this template and evaluate the expression on a batch of successfully parsed rows. For the following query:
Enables or disables template deduction for SQL expressions in [Values](../../interfaces/formats.md#data-format-values) format. It allows parsing and interpreting expressions in `Values` much faster if expressions in consecutive rows have the same structure. ClickHouse tries to deduce template of an expression, parse the following rows using this template and evaluate the expression on a batch of successfully parsed rows.
Possible values:
- 0 — Disabled.
- 1 — Enabled.
Default value: 1.
For the following query:
``` sql
INSERT INTO test VALUES (lower('Hello')), (lower('world')), (lower('INSERT')), (upper('Values')), ...
```
- if `input_format_values_interpret_expressions=1` and `format_values_deduce_templates_of_expressions=0` expressions will be interpreted separately for each row (this is very slow for large number of rows)
- if `input_format_values_interpret_expressions=0` and `format_values_deduce_templates_of_expressions=1` expressions in the first, second and third rows will be parsed using template `lower(String)` and interpreted together, expression is the forth row will be parsed with another template (`upper(String)`)
- if `input_format_values_interpret_expressions=1` and `format_values_deduce_templates_of_expressions=1` - the same as in previous case, but also allows fallback to interpreting expressions separately if it’s not possible to deduce template.
Enabled by default.
- If `input_format_values_interpret_expressions=1` and `format_values_deduce_templates_of_expressions=0`, expressions are interpreted separately for each row (this is very slow for large number of rows).
- If `input_format_values_interpret_expressions=0` and `format_values_deduce_templates_of_expressions=1`, expressions in the first, second and third rows are parsed using template `lower(String)` and interpreted together, expression in the forth row is parsed with another template (`upper(String)`).
- If `input_format_values_interpret_expressions=1` and `format_values_deduce_templates_of_expressions=1`, the same as in previous case, but also allows fallback to interpreting expressions separately if it’s not possible to deduce template.
## input\_format\_values\_accurate\_types\_of\_literals {#settings-input-format-values-accurate-types-of-literals}
This setting is used only when `input_format_values_deduce_templates_of_expressions = 1`. It can happen, that expressions for some column have the same structure, but contain numeric literals of different types, e.g
This setting is used only when `input_format_values_deduce_templates_of_expressions = 1`. It can happen, that expressions for some column have the same structure, but contain numeric literals of different types, e.g.
``` sql
(..., abs(0), ...), -- UInt64 literal
@ -242,9 +249,17 @@ This setting is used only when `input_format_values_deduce_templates_of_expressi
(..., abs(-1), ...), -- Int64 literal
```
When this setting is enabled, ClickHouse will check the actual type of literal and will use an expression template of the corresponding type. In some cases, it may significantly slow down expression evaluation in `Values`.
When disabled, ClickHouse may use more general type for some literals (e.g. `Float64` or `Int64` instead of `UInt64` for `42`), but it may cause overflow and precision issues.
Enabled by default.
Possible values:
- 0 — Disabled.
In this case, ClickHouse may use a more general type for some literals (e.g., `Float64` or `Int64` instead of `UInt64` for `42`), but it may cause overflow and precision issues.
- 1 — Enabled.
In this case, ClickHouse checks the actual type of literal and uses an expression template of the corresponding type. In some cases, it may significantly slow down expression evaluation in `Values`.
Default value: 1.
## input\_format\_defaults\_for\_omitted\_fields {#session_settings-input_format_defaults_for_omitted_fields}

18
docs/en/operations/system_tables.md
View File

@ -709,7 +709,7 @@ When the table is deleted manually, it will be automatically created on the fly.
You can specify an arbitrary partitioning key for the `system.query_thread_log` table in the [query\_thread\_log](server_configuration_parameters/settings.md#server_configuration_parameters-query-thread-log) server setting (see the `partition_by` parameter).
## system.trace\_log {#system_tables-trace_log}
## system.trace_log {#system_tables-trace_log}
Contains stack traces collected by the sampling query profiler.
@ -719,24 +719,26 @@ To analyze logs, use the `addressToLine`, `addressToSymbol` and `demangle` intro
Columns:
- `event_date`([Date](../sql_reference/data_types/date.md)) — Date of sampling moment.
- `event_date` ([Date](../sql_reference/data_types/date.md)) — Date of sampling moment.
- `event_time`([DateTime](../sql_reference/data_types/datetime.md)) — Timestamp of sampling moment.
- `event_time` ([DateTime](../sql_reference/data_types/datetime.md)) — Timestamp of the sampling moment.
- `revision`([UInt32](../sql_reference/data_types/int_uint.md)) — ClickHouse server build revision.
- `timestamp_ns` ([UInt64](../sql_reference/data_types/int_uint.md)) — Timestamp of the sampling moment in nanoseconds.
- `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](../sql_reference/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](../sql_reference/data_types/int_uint.md)) — Thread identifier.
- `thread_number` ([UInt32](../sql_reference/data_types/int_uint.md)) — Thread identifier.
- `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.
- `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)](../sql_reference/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**

2
docs/en/sql_reference/data_types/special_data_types/set.md
View File

@ -5,6 +5,6 @@ toc_title: Set
# Set {#set}
Used for the right half of an [IN](../../../sql_reference/statements/select.md#select-in-operators) expression.
Used for the right half of an [IN](../../statements/select.md#select-in-operators) expression.
[Original article](https://clickhouse.tech/docs/en/data_types/special_data_types/set/) <!--hide-->

19
docs/en/sql_reference/functions/array_functions.md
View File

@ -989,7 +989,7 @@ Result:
## arrayZip {#arrayzip}
Combine multiple Array type columns into one Array\[Tuple(…)\] column
Combines multiple arrays into a single array. The resulting array contains the corresponding elements of the source arrays grouped into tuples in the listed order of arguments.
**Syntax**
@ -999,28 +999,33 @@ arrayZip(arr1, arr2, ..., arrN)
**Parameters**
`arr` — Any number of [array](../../sql_reference/data_types/array.md) type columns to combine.
- `arrN` — [Array](../data_types/array.md).
The function can take any number of arrays of different types. All the input arrays must be of equal size.
**Returned value**
The result of Array\[Tuple(…)\] type after the combination of these arrays
- Array with elements from the source arrays grouped into [tuples](../data_types/tuple.md). Data types in the tuple are the same as types of the input arrays and in the same order as arrays are passed.
Type: [Array](../data_types/array.md).
**Example**
Query:
``` sql
SELECT arrayZip(['a', 'b', 'c'], ['d', 'e', 'f']);
SELECT arrayZip(['a', 'b', 'c'], [5, 2, 1])
```
Result:
``` text
┌─arrayZip(['a', 'b', 'c'], ['d', 'e', 'f'])─┐
│ [('a','d'),('b','e'),('c','f')] │
└────────────────────────────────────────────┘
┌─arrayZip(['a', 'b', 'c'], [5, 2, 1])─┐
│ [('a',5),('b',2),('c',1)] │
└──────────────────────────────────────┘
```
## arrayAUC {#arrayauc}
Calculate AUC (Area Under the Curve, which is a concept in machine learning, see more details: https://en.wikipedia.org/wiki/Receiver_operating_characteristic#Area_under_the_curve).

1
docs/en/sql_reference/statements/alter.md
View File

@ -204,7 +204,6 @@ The following operations with [partitions](../../engines/table_engines/mergetree
- [DETACH PARTITION](#alter_detach-partition) – Moves a partition to the `detached` directory and forget it.
- [DROP PARTITION](#alter_drop-partition) – Deletes a partition.
- [ATTACH PART\|PARTITION](#alter_attach-partition) – Adds a part or partition from the `detached` directory to the table.
- [REPLACE PARTITION](#alter_replace-partition) - Copies the data partition from one table to another.
- [ATTACH PARTITION FROM](#alter_attach-partition-from) – Copies the data partition from one table to another and adds.
- [REPLACE PARTITION](#alter_replace-partition) - Copies the data partition from one table to another and replaces.
- [MOVE PARTITION TO TABLE](#alter_move_to_table-partition) (\#alter\_move\_to\_table-partition) - Move the data partition from one table to another.

778
docs/en/sql_reference/statements/select.md
View File

@ -248,7 +248,7 @@ Here, a sample of 10% is taken from the second half of the data.
### ARRAY JOIN Clause {#select-array-join-clause}
Allows executing `JOIN` with an array or nested data structure. The intent is similar to the [arrayJoin](../../sql_reference/functions/array_join.md#functions_arrayjoin) function, but its functionality is broader.
Allows executing `JOIN` with an array or nested data structure. The intent is similar to the [arrayJoin](../functions/array_join.md#functions_arrayjoin) function, but its functionality is broader.
``` sql
SELECT <expr_list>
@ -602,7 +602,777 @@ USING (equi_column1, ... equi_columnN, asof_column)
For example, consider the following tables:
\`\`\` text
table\_1 table\_2
table_1 table_2
event | ev_time | user_id event | ev_time | user_id
----------|---------|---------- ----------|---------|----------
... ...
event_1_1 | 12:00 | 42 event_2_1 | 11:59 | 42
... event_2_2 | 12:30 | 42
event_1_2 | 13:00 | 42 event_2_3 | 13:00 | 42
... ...
event \| ev\_time \| user\_id event \| ev\_time \| user\_id
`ASOF JOIN` can take the timestamp of a user event from `table_1` and find an event in `table_2` where the timestamp is closest to the timestamp of the event from `table_1` corresponding to the closest match condition. Equal timestamp values are the closest if available. Here, the `user_id` column can be used for joining on equality and the `ev_time` column can be used for joining on the closest match. In our example, `event_1_1` can be joined with `event_2_1` and `event_1_2` can be joined with `event_2_3`, but `event_2_2` can’t be joined.
!!! note "Note"
`ASOF` join is **not** supported in the [Join](../../engines/table_engines/special/join.md) table engine.
To set the default strictness value, use the session configuration parameter [join\_default\_strictness](../../operations/settings/settings.md#settings-join_default_strictness).
#### GLOBAL JOIN {#global-join}
When using a normal `JOIN`, the query is sent to remote servers. Subqueries are run on each of them in order to make the right table, and the join is performed with this table. In other words, the right table is formed on each server separately.
When using `GLOBAL ... JOIN`, first the requestor server runs a subquery to calculate the right table. This temporary table is passed to each remote server, and queries are run on them using the temporary data that was transmitted.
Be careful when using `GLOBAL`. For more information, see the section [Distributed subqueries](#select-distributed-subqueries).
#### Usage Recommendations {#usage-recommendations}
When running a `JOIN`, there is no optimization of the order of execution in relation to other stages of the query. The join (a search in the right table) is run before filtering in `WHERE` and before aggregation. In order to explicitly set the processing order, we recommend running a `JOIN` subquery with a subquery.
Example:
``` sql
SELECT
CounterID,
hits,
visits
FROM
(
SELECT
CounterID,
count() AS hits
FROM test.hits
GROUP BY CounterID
) ANY LEFT JOIN
(
SELECT
CounterID,
sum(Sign) AS visits
FROM test.visits
GROUP BY CounterID
) USING CounterID
ORDER BY hits DESC
LIMIT 10
```
``` text
┌─CounterID─┬───hits─┬─visits─┐
│ 1143050 │ 523264 │ 13665 │
│ 731962 │ 475698 │ 102716 │
│ 722545 │ 337212 │ 108187 │
│ 722889 │ 252197 │ 10547 │
│ 2237260 │ 196036 │ 9522 │
│ 23057320 │ 147211 │ 7689 │
│ 722818 │ 90109 │ 17847 │
│ 48221 │ 85379 │ 4652 │
│ 19762435 │ 77807 │ 7026 │
│ 722884 │ 77492 │ 11056 │
└───────────┴────────┴────────┘
```
Subqueries don’t allow you to set names or use them for referencing a column from a specific subquery.
The columns specified in `USING` must have the same names in both subqueries, and the other columns must be named differently. You can use aliases to change the names of columns in subqueries (the example uses the aliases `hits` and `visits`).
The `USING` clause specifies one or more columns to join, which establishes the equality of these columns. The list of columns is set without brackets. More complex join conditions are not supported.
The right table (the subquery result) resides in RAM. If there isn’t enough memory, you can’t run a `JOIN`.
Each time a query is run with the same `JOIN`, the subquery is run again because the result is not cached. To avoid this, use the special [Join](../../engines/table_engines/special/join.md) table engine, which is a prepared array for joining that is always in RAM.
In some cases, it is more efficient to use `IN` instead of `JOIN`.
Among the various types of `JOIN`, the most efficient is `ANY LEFT JOIN`, then `ANY INNER JOIN`. The least efficient are `ALL LEFT JOIN` and `ALL INNER JOIN`.
If you need a `JOIN` for joining with dimension tables (these are relatively small tables that contain dimension properties, such as names for advertising campaigns), a `JOIN` might not be very convenient due to the fact that the right table is re-accessed for every query. For such cases, there is an “external dictionaries” feature that you should use instead of `JOIN`. For more information, see the section [External dictionaries](../dictionaries/external_dictionaries/external_dicts.md).
**Memory Limitations**
ClickHouse uses the [hash join](https://en.wikipedia.org/wiki/Hash_join) algorithm. ClickHouse takes the `<right_subquery>` and creates a hash table for it in RAM. If you need to restrict join operation memory consumption use the following settings:
- [max\_rows\_in\_join](../../operations/settings/query_complexity.md#settings-max_rows_in_join) — Limits number of rows in the hash table.
- [max\_bytes\_in\_join](../../operations/settings/query_complexity.md#settings-max_bytes_in_join) — Limits size of the hash table.
When any of these limits is reached, ClickHouse acts as the [join\_overflow\_mode](../../operations/settings/query_complexity.md#settings-join_overflow_mode) setting instructs.
#### Processing of Empty or NULL Cells {#processing-of-empty-or-null-cells}
While joining tables, the empty cells may appear. The setting [join\_use\_nulls](../../operations/settings/settings.md#join_use_nulls) define how ClickHouse fills these cells.
If the `JOIN` keys are [Nullable](../data_types/nullable.md) fields, the rows where at least one of the keys has the value [NULL](../syntax.md#null-literal) are not joined.
#### Syntax Limitations {#syntax-limitations}
For multiple `JOIN` clauses in a single `SELECT` query:
- Taking all the columns via `*` is available only if tables are joined, not subqueries.
- The `PREWHERE` clause is not available.
For `ON`, `WHERE`, and `GROUP BY` clauses:
- Arbitrary expressions cannot be used in `ON`, `WHERE`, and `GROUP BY` clauses, but you can define an expression in a `SELECT` clause and then use it in these clauses via an alias.
### WHERE Clause {#select-where}
If there is a WHERE clause, it must contain an expression with the UInt8 type. This is usually an expression with comparison and logical operators.
This expression will be used for filtering data before all other transformations.
If indexes are supported by the database table engine, the expression is evaluated on the ability to use indexes.
### PREWHERE Clause {#prewhere-clause}
This clause has the same meaning as the WHERE clause. The difference is in which data is read from the table.
When using PREWHERE, first only the columns necessary for executing PREWHERE are read. Then the other columns are read that are needed for running the query, but only those blocks where the PREWHERE expression is true.
It makes sense to use PREWHERE if there are filtration conditions that are used by a minority of the columns in the query, but that provide strong data filtration. This reduces the volume of data to read.
For example, it is useful to write PREWHERE for queries that extract a large number of columns, but that only have filtration for a few columns.
PREWHERE is only supported by tables from the `*MergeTree` family.
A query may simultaneously specify PREWHERE and WHERE. In this case, PREWHERE precedes WHERE.
If the ‘optimize\_move\_to\_prewhere’ setting is set to 1 and PREWHERE is omitted, the system uses heuristics to automatically move parts of expressions from WHERE to PREWHERE.
### GROUP BY Clause {#select-group-by-clause}
This is one of the most important parts of a column-oriented DBMS.
If there is a GROUP BY clause, it must contain a list of expressions. Each expression will be referred to here as a “key”.
All the expressions in the SELECT, HAVING, and ORDER BY clauses must be calculated from keys or from aggregate functions. In other words, each column selected from the table must be used either in keys or inside aggregate functions.
If a query contains only table columns inside aggregate functions, the GROUP BY clause can be omitted, and aggregation by an empty set of keys is assumed.
Example:
``` sql
SELECT
count(),
median(FetchTiming > 60 ? 60 : FetchTiming),
count() - sum(Refresh)
FROM hits
```
However, in contrast to standard SQL, if the table doesn’t have any rows (either there aren’t any at all, or there aren’t any after using WHERE to filter), an empty result is returned, and not the result from one of the rows containing the initial values of aggregate functions.
As opposed to MySQL (and conforming to standard SQL), you can’t get some value of some column that is not in a key or aggregate function (except constant expressions). To work around this, you can use the ‘any’ aggregate function (get the first encountered value) or ‘min/max’.
Example:
``` sql
SELECT
domainWithoutWWW(URL) AS domain,
count(),
any(Title) AS title -- getting the first occurred page header for each domain.
FROM hits
GROUP BY domain
```
For every different key value encountered, GROUP BY calculates a set of aggregate function values.
GROUP BY is not supported for array columns.
A constant can’t be specified as arguments for aggregate functions. Example: sum(1). Instead of this, you can get rid of the constant. Example: `count()`.
#### NULL processing {#null-processing}
For grouping, ClickHouse interprets [NULL](../syntax.md) as a value, and `NULL=NULL`.
Here’s an example to show what this means.
Assume you have this table:
``` text
┌─x─┬────y─┐
│ 1 │ 2 │
│ 2 │ ᴺᵁᴸᴸ │
│ 3 │ 2 │
│ 3 │ 3 │
│ 3 │ ᴺᵁᴸᴸ │
└───┴──────┘
```
The query `SELECT sum(x), y FROM t_null_big GROUP BY y` results in:
``` text
┌─sum(x)─┬────y─┐
│ 4 │ 2 │
│ 3 │ 3 │
│ 5 │ ᴺᵁᴸᴸ │
└────────┴──────┘
```
You can see that `GROUP BY` for `y = NULL` summed up `x`, as if `NULL` is this value.
If you pass several keys to `GROUP BY`, the result will give you all the combinations of the selection, as if `NULL` were a specific value.
#### WITH TOTALS Modifier {#with-totals-modifier}
If the WITH TOTALS modifier is specified, another row will be calculated. This row will have key columns containing default values (zeros or empty lines), and columns of aggregate functions with the values calculated across all the rows (the “total” values).
This extra row is output in JSON\*, TabSeparated\*, and Pretty\* formats, separately from the other rows. In the other formats, this row is not output.
In JSON\* formats, this row is output as a separate ‘totals’ field. In TabSeparated\* formats, the row comes after the main result, preceded by an empty row (after the other data). In Pretty\* formats, the row is output as a separate table after the main result.
`WITH TOTALS` can be run in different ways when HAVING is present. The behavior depends on the ‘totals\_mode’ setting.
By default, `totals_mode = 'before_having'`. In this case, ‘totals’ is calculated across all rows, including the ones that don’t pass through HAVING and ‘max\_rows\_to\_group\_by’.
The other alternatives include only the rows that pass through HAVING in ‘totals’, and behave differently with the setting `max_rows_to_group_by` and `group_by_overflow_mode = 'any'`.
`after_having_exclusive` – Don’t include rows that didn’t pass through `max_rows_to_group_by`. In other words, ‘totals’ will have less than or the same number of rows as it would if `max_rows_to_group_by` were omitted.
`after_having_inclusive` – Include all the rows that didn’t pass through ‘max\_rows\_to\_group\_by’ in ‘totals’. In other words, ‘totals’ will have more than or the same number of rows as it would if `max_rows_to_group_by` were omitted.
`after_having_auto` – Count the number of rows that passed through HAVING. If it is more than a certain amount (by default, 50%), include all the rows that didn’t pass through ‘max\_rows\_to\_group\_by’ in ‘totals’. Otherwise, do not include them.
`totals_auto_threshold` – By default, 0.5. The coefficient for `after_having_auto`.
If `max_rows_to_group_by` and `group_by_overflow_mode = 'any'` are not used, all variations of `after_having` are the same, and you can use any of them (for example, `after_having_auto`).
You can use WITH TOTALS in subqueries, including subqueries in the JOIN clause (in this case, the respective total values are combined).
#### GROUP BY in External Memory {#select-group-by-in-external-memory}
You can enable dumping temporary data to the disk to restrict memory usage during `GROUP BY`.
The [max\_bytes\_before\_external\_group\_by](../../operations/settings/settings.md#settings-max_bytes_before_external_group_by) setting determines the threshold RAM consumption for dumping `GROUP BY` temporary data to the file system. If set to 0 (the default), it is disabled.
When using `max_bytes_before_external_group_by`, we recommend that you set `max_memory_usage` about twice as high. This is necessary because there are two stages to aggregation: reading the date and forming intermediate data (1) and merging the intermediate data (2). Dumping data to the file system can only occur during stage 1. If the temporary data wasn’t dumped, then stage 2 might require up to the same amount of memory as in stage 1.
For example, if [max\_memory\_usage](../../operations/settings/settings.md#settings_max_memory_usage) was set to 10000000000 and you want to use external aggregation, it makes sense to set `max_bytes_before_external_group_by` to 10000000000, and max\_memory\_usage to 20000000000. When external aggregation is triggered (if there was at least one dump of temporary data), maximum consumption of RAM is only slightly more than `max_bytes_before_external_group_by`.
With distributed query processing, external aggregation is performed on remote servers. In order for the requester server to use only a small amount of RAM, set `distributed_aggregation_memory_efficient` to 1.
When merging data flushed to the disk, as well as when merging results from remote servers when the `distributed_aggregation_memory_efficient` setting is enabled, consumes up to `1/256 * the_number_of_threads` from the total amount of RAM.
When external aggregation is enabled, if there was less than `max_bytes_before_external_group_by` of data (i.e. data was not flushed), the query runs just as fast as without external aggregation. If any temporary data was flushed, the run time will be several times longer (approximately three times).
If you have an `ORDER BY` with a `LIMIT` after `GROUP BY`, then the amount of used RAM depends on the amount of data in `LIMIT`, not in the whole table. But if the `ORDER BY` doesn’t have `LIMIT`, don’t forget to enable external sorting (`max_bytes_before_external_sort`).
### LIMIT BY Clause {#limit-by-clause}
A query with the `LIMIT n BY expressions` clause selects the first `n` rows for each distinct value of `expressions`. The key for `LIMIT BY` can contain any number of [expressions](../syntax.md#syntax-expressions).
ClickHouse supports the following syntax:
- `LIMIT [offset_value, ]n BY expressions`
- `LIMIT n OFFSET offset_value BY expressions`
During query processing, ClickHouse selects data ordered by sorting key. The sorting key is set explicitly using an [ORDER BY](#select-order-by) clause or implicitly as a property of the table engine. Then ClickHouse applies `LIMIT n BY expressions` and returns the first `n` rows for each distinct combination of `expressions`. If `OFFSET` is specified, then for each data block that belongs to a distinct combination of `expressions`, ClickHouse skips `offset_value` number of rows from the beginning of the block and returns a maximum of `n` rows as a result. If `offset_value` is bigger than the number of rows in the data block, ClickHouse returns zero rows from the block.
`LIMIT BY` is not related to `LIMIT`. They can both be used in the same query.
**Examples**
Sample table:
``` sql
CREATE TABLE limit_by(id Int, val Int) ENGINE = Memory;
INSERT INTO limit_by values(1, 10), (1, 11), (1, 12), (2, 20), (2, 21);
```
Queries:
``` sql
SELECT * FROM limit_by ORDER BY id, val LIMIT 2 BY id
```
``` text
┌─id─┬─val─┐
│ 1 │ 10 │
│ 1 │ 11 │
│ 2 │ 20 │
│ 2 │ 21 │
└────┴─────┘
```
``` sql
SELECT * FROM limit_by ORDER BY id, val LIMIT 1, 2 BY id
```
``` text
┌─id─┬─val─┐
│ 1 │ 11 │
│ 1 │ 12 │
│ 2 │ 21 │
└────┴─────┘
```
The `SELECT * FROM limit_by ORDER BY id, val LIMIT 2 OFFSET 1 BY id` query returns the same result.
The following query returns the top 5 referrers for each `domain, device_type` pair with a maximum of 100 rows in total (`LIMIT n BY + LIMIT`).
``` sql
SELECT
domainWithoutWWW(URL) AS domain,
domainWithoutWWW(REFERRER_URL) AS referrer,
device_type,
count() cnt
FROM hits
GROUP BY domain, referrer, device_type
ORDER BY cnt DESC
LIMIT 5 BY domain, device_type
LIMIT 100
```
### HAVING Clause {#having-clause}
Allows filtering the result received after GROUP BY, similar to the WHERE clause.
WHERE and HAVING differ in that WHERE is performed before aggregation (GROUP BY), while HAVING is performed after it.
If aggregation is not performed, HAVING can’t be used.
### ORDER BY Clause {#select-order-by}
The ORDER BY clause contains a list of expressions, which can each be assigned DESC or ASC (the sorting direction). If the direction is not specified, ASC is assumed. ASC is sorted in ascending order, and DESC in descending order. The sorting direction applies to a single expression, not to the entire list. Example: `ORDER BY Visits DESC, SearchPhrase`
For sorting by String values, you can specify collation (comparison). Example: `ORDER BY SearchPhrase COLLATE 'tr'` - for sorting by keyword in ascending order, using the Turkish alphabet, case insensitive, assuming that strings are UTF-8 encoded. COLLATE can be specified or not for each expression in ORDER BY independently. If ASC or DESC is specified, COLLATE is specified after it. When using COLLATE, sorting is always case-insensitive.
We only recommend using COLLATE for final sorting of a small number of rows, since sorting with COLLATE is less efficient than normal sorting by bytes.
Rows that have identical values for the list of sorting expressions are output in an arbitrary order, which can also be nondeterministic (different each time).
If the ORDER BY clause is omitted, the order of the rows is also undefined, and may be nondeterministic as well.
`NaN` and `NULL` sorting order:
- With the modifier `NULLS FIRST` — First `NULL`, then `NaN`, then other values.
- With the modifier `NULLS LAST` — First the values, then `NaN`, then `NULL`.
- Default — The same as with the `NULLS LAST` modifier.
Example:
For the table
``` text
┌─x─┬────y─┐
│ 1 │ ᴺᵁᴸᴸ │
│ 2 │ 2 │
│ 1 │ nan │
│ 2 │ 2 │
│ 3 │ 4 │
│ 5 │ 6 │
│ 6 │ nan │
│ 7 │ ᴺᵁᴸᴸ │
│ 6 │ 7 │
│ 8 │ 9 │
└───┴──────┘
```
Run the query `SELECT * FROM t_null_nan ORDER BY y NULLS FIRST` to get:
``` text
┌─x─┬────y─┐
│ 1 │ ᴺᵁᴸᴸ │
│ 7 │ ᴺᵁᴸᴸ │
│ 1 │ nan │
│ 6 │ nan │
│ 2 │ 2 │
│ 2 │ 2 │
│ 3 │ 4 │
│ 5 │ 6 │
│ 6 │ 7 │
│ 8 │ 9 │
└───┴──────┘
```
When floating point numbers are sorted, NaNs are separate from the other values. Regardless of the sorting order, NaNs come at the end. In other words, for ascending sorting they are placed as if they are larger than all the other numbers, while for descending sorting they are placed as if they are smaller than the rest.
Less RAM is used if a small enough LIMIT is specified in addition to ORDER BY. Otherwise, the amount of memory spent is proportional to the volume of data for sorting. For distributed query processing, if GROUP BY is omitted, sorting is partially done on remote servers, and the results are merged on the requestor server. This means that for distributed sorting, the volume of data to sort can be greater than the amount of memory on a single server.
If there is not enough RAM, it is possible to perform sorting in external memory (creating temporary files on a disk). Use the setting `max_bytes_before_external_sort` for this purpose. If it is set to 0 (the default), external sorting is disabled. If it is enabled, when the volume of data to sort reaches the specified number of bytes, the collected data is sorted and dumped into a temporary file. After all data is read, all the sorted files are merged and the results are output. Files are written to the /var/lib/clickhouse/tmp/ directory in the config (by default, but you can use the ‘tmp\_path’ parameter to change this setting).
Running a query may use more memory than ‘max\_bytes\_before\_external\_sort’. For this reason, this setting must have a value significantly smaller than ‘max\_memory\_usage’. As an example, if your server has 128 GB of RAM and you need to run a single query, set ‘max\_memory\_usage’ to 100 GB, and ‘max\_bytes\_before\_external\_sort’ to 80 GB.
External sorting works much less effectively than sorting in RAM.
### SELECT Clause {#select-select}
[Expressions](../syntax.md#syntax-expressions) specified in the `SELECT` clause are calculated after all the operations in the clauses described above are finished. These expressions work as if they apply to separate rows in the result. If expressions in the `SELECT` clause contain aggregate functions, then ClickHouse processes aggregate functions and expressions used as their arguments during the [GROUP BY](#select-group-by-clause) aggregation.
If you want to include all columns in the result, use the asterisk (`*`) symbol. For example, `SELECT * FROM ...`.
To match some columns in the result with a [re2](https://en.wikipedia.org/wiki/RE2_(software)) regular expression, you can use the `COLUMNS` expression.
``` sql
COLUMNS('regexp')
```
For example, consider the table:
``` sql
CREATE TABLE default.col_names (aa Int8, ab Int8, bc Int8) ENGINE = TinyLog
```
The following query selects data from all the columns containing the `a` symbol in their name.
``` sql
SELECT COLUMNS('a') FROM col_names
```
``` text
┌─aa─┬─ab─┐
│ 1 │ 1 │
└────┴────┘
```
The selected columns are returned not in the alphabetical order.
You can use multiple `COLUMNS` expressions in a query and apply functions to them.
For example:
``` sql
SELECT COLUMNS('a'), COLUMNS('c'), toTypeName(COLUMNS('c')) FROM col_names
```
``` text
┌─aa─┬─ab─┬─bc─┬─toTypeName(bc)─┐
│ 1 │ 1 │ 1 │ Int8 │
└────┴────┴────┴────────────────┘
```
Each column returned by the `COLUMNS` expression is passed to the function as a separate argument. Also you can pass other arguments to the function if it supports them. Be careful when using functions. If a function doesn’t support the number of arguments you have passed to it, ClickHouse throws an exception.
For example:
``` sql
SELECT COLUMNS('a') + COLUMNS('c') FROM col_names
```
``` text
Received exception from server (version 19.14.1):
Code: 42. DB::Exception: Received from localhost:9000. DB::Exception: Number of arguments for function plus doesn't match: passed 3, should be 2.
```
In this example, `COLUMNS('a')` returns two columns: `aa` and `ab`. `COLUMNS('c')` returns the `bc` column. The `+` operator can’t apply to 3 arguments, so ClickHouse throws an exception with the relevant message.
Columns that matched the `COLUMNS` expression can have different data types. If `COLUMNS` doesn’t match any columns and is the only expression in `SELECT`, ClickHouse throws an exception.
### DISTINCT Clause {#select-distinct}
If DISTINCT is specified, only a single row will remain out of all the sets of fully matching rows in the result.
The result will be the same as if GROUP BY were specified across all the fields specified in SELECT without aggregate functions. But there are several differences from GROUP BY:
- DISTINCT can be applied together with GROUP BY.
- When ORDER BY is omitted and LIMIT is defined, the query stops running immediately after the required number of different rows has been read.
- Data blocks are output as they are processed, without waiting for the entire query to finish running.
DISTINCT is not supported if SELECT has at least one array column.
`DISTINCT` works with [NULL](../syntax.md) as if `NULL` were a specific value, and `NULL=NULL`. In other words, in the `DISTINCT` results, different combinations with `NULL` only occur once.
ClickHouse supports using the `DISTINCT` and `ORDER BY` clauses for different columns in one query. The `DISTINCT` clause is executed before the `ORDER BY` clause.
Example table:
``` text
┌─a─┬─b─┐
│ 2 │ 1 │
│ 1 │ 2 │
│ 3 │ 3 │
│ 2 │ 4 │
└───┴───┘
```
When selecting data with the `SELECT DISTINCT a FROM t1 ORDER BY b ASC` query, we get the following result:
``` text
┌─a─┐
│ 2 │
│ 1 │
│ 3 │
└───┘
```
If we change the sorting direction `SELECT DISTINCT a FROM t1 ORDER BY b DESC`, we get the following result:
``` text
┌─a─┐
│ 3 │
│ 1 │
│ 2 │
└───┘
```
Row `2, 4` was cut before sorting.
Take this implementation specificity into account when programming queries.
### LIMIT Clause {#limit-clause}
`LIMIT m` allows you to select the first `m` rows from the result.
`LIMIT n, m` allows you to select the first `m` rows from the result after skipping the first `n` rows. The `LIMIT m OFFSET n` syntax is also supported.
`n` and `m` must be non-negative integers.
If there isn’t an `ORDER BY` clause that explicitly sorts results, the result may be arbitrary and nondeterministic.
### UNION ALL Clause {#union-all-clause}
You can use UNION ALL to combine any number of queries. Example:
``` sql
SELECT CounterID, 1 AS table, toInt64(count()) AS c
FROM test.hits
GROUP BY CounterID
UNION ALL
SELECT CounterID, 2 AS table, sum(Sign) AS c
FROM test.visits
GROUP BY CounterID
HAVING c > 0
```
Only UNION ALL is supported. The regular UNION (UNION DISTINCT) is not supported. If you need UNION DISTINCT, you can write SELECT DISTINCT from a subquery containing UNION ALL.
Queries that are parts of UNION ALL can be run simultaneously, and their results can be mixed together.
The structure of results (the number and type of columns) must match for the queries. But the column names can differ. In this case, the column names for the final result will be taken from the first query. Type casting is performed for unions. For example, if two queries being combined have the same field with non-`Nullable` and `Nullable` types from a compatible type, the resulting `UNION ALL` has a `Nullable` type field.
Queries that are parts of UNION ALL can’t be enclosed in brackets. ORDER BY and LIMIT are applied to separate queries, not to the final result. If you need to apply a conversion to the final result, you can put all the queries with UNION ALL in a subquery in the FROM clause.
### INTO OUTFILE Clause {#into-outfile-clause}
Add the `INTO OUTFILE filename` clause (where filename is a string literal) to redirect query output to the specified file.
In contrast to MySQL, the file is created on the client side. The query will fail if a file with the same filename already exists.
This functionality is available in the command-line client and clickhouse-local (a query sent via HTTP interface will fail).
The default output format is TabSeparated (the same as in the command-line client batch mode).
### FORMAT Clause {#format-clause}
Specify ‘FORMAT format’ to get data in any specified format.
You can use this for convenience, or for creating dumps.
For more information, see the section “Formats”.
If the FORMAT clause is omitted, the default format is used, which depends on both the settings and the interface used for accessing the DB. For the HTTP interface and the command-line client in batch mode, the default format is TabSeparated. For the command-line client in interactive mode, the default format is PrettyCompact (it has attractive and compact tables).
When using the command-line client, data is passed to the client in an internal efficient format. The client independently interprets the FORMAT clause of the query and formats the data itself (thus relieving the network and the server from the load).
### IN Operators {#select-in-operators}
The `IN`, `NOT IN`, `GLOBAL IN`, and `GLOBAL NOT IN` operators are covered separately, since their functionality is quite rich.
The left side of the operator is either a single column or a tuple.
Examples:
``` sql
SELECT UserID IN (123, 456) FROM ...
SELECT (CounterID, UserID) IN ((34, 123), (101500, 456)) FROM ...
```
If the left side is a single column that is in the index, and the right side is a set of constants, the system uses the index for processing the query.
Don’t list too many values explicitly (i.e. millions). If a data set is large, put it in a temporary table (for example, see the section “External data for query processing”), then use a subquery.
The right side of the operator can be a set of constant expressions, a set of tuples with constant expressions (shown in the examples above), or the name of a database table or SELECT subquery in brackets.
If the right side of the operator is the name of a table (for example, `UserID IN users`), this is equivalent to the subquery `UserID IN (SELECT * FROM users)`. Use this when working with external data that is sent along with the query. For example, the query can be sent together with a set of user IDs loaded to the ‘users’ temporary table, which should be filtered.
If the right side of the operator is a table name that has the Set engine (a prepared data set that is always in RAM), the data set will not be created over again for each query.
The subquery may specify more than one column for filtering tuples.
Example:
``` sql
SELECT (CounterID, UserID) IN (SELECT CounterID, UserID FROM ...) FROM ...
```
The columns to the left and right of the IN operator should have the same type.
The IN operator and subquery may occur in any part of the query, including in aggregate functions and lambda functions.
Example:
``` sql
SELECT
EventDate,
avg(UserID IN
(
SELECT UserID
FROM test.hits
WHERE EventDate = toDate('2014-03-17')
)) AS ratio
FROM test.hits
GROUP BY EventDate
ORDER BY EventDate ASC
```
``` text
┌──EventDate─┬────ratio─┐
│ 2014-03-17 │ 1 │
│ 2014-03-18 │ 0.807696 │
│ 2014-03-19 │ 0.755406 │
│ 2014-03-20 │ 0.723218 │
│ 2014-03-21 │ 0.697021 │
│ 2014-03-22 │ 0.647851 │
│ 2014-03-23 │ 0.648416 │
└────────────┴──────────┘
```
For each day after March 17th, count the percentage of pageviews made by users who visited the site on March 17th.
A subquery in the IN clause is always run just one time on a single server. There are no dependent subqueries.
#### NULL processing {#null-processing-1}
During request processing, the IN operator assumes that the result of an operation with [NULL](../syntax.md) is always equal to `0`, regardless of whether `NULL` is on the right or left side of the operator. `NULL` values are not included in any dataset, do not correspond to each other and cannot be compared.
Here is an example with the `t_null` table:
``` text
┌─x─┬────y─┐
│ 1 │ ᴺᵁᴸᴸ │
│ 2 │ 3 │
└───┴──────┘
```
Running the query `SELECT x FROM t_null WHERE y IN (NULL,3)` gives you the following result:
``` text
┌─x─┐
│ 2 │
└───┘
```
You can see that the row in which `y = NULL` is thrown out of the query results. This is because ClickHouse can’t decide whether `NULL` is included in the `(NULL,3)` set, returns `0` as the result of the operation, and `SELECT` excludes this row from the final output.
``` sql
SELECT y IN (NULL, 3)
FROM t_null
```
``` text
┌─in(y, tuple(NULL, 3))─┐
│ 0 │
│ 1 │
└───────────────────────┘
```
#### Distributed Subqueries {#select-distributed-subqueries}
There are two options for IN-s with subqueries (similar to JOINs): normal `IN` / `JOIN` and `GLOBAL IN` / `GLOBAL JOIN`. They differ in how they are run for distributed query processing.
!!! attention "Attention"
Remember that the algorithms described below may work differently depending on the [settings](../../operations/settings/settings.md) `distributed_product_mode` setting.
When using the regular IN, the query is sent to remote servers, and each of them runs the subqueries in the `IN` or `JOIN` clause.
When using `GLOBAL IN` / `GLOBAL JOINs`, first all the subqueries are run for `GLOBAL IN` / `GLOBAL JOINs`, and the results are collected in temporary tables. Then the temporary tables are sent to each remote server, where the queries are run using this temporary data.
For a non-distributed query, use the regular `IN` / `JOIN`.
Be careful when using subqueries in the `IN` / `JOIN` clauses for distributed query processing.
Let’s look at some examples. Assume that each server in the cluster has a normal **local\_table**. Each server also has a **distributed\_table** table with the **Distributed** type, which looks at all the servers in the cluster.
For a query to the **distributed\_table**, the query will be sent to all the remote servers and run on them using the **local\_table**.
For example, the query
``` sql
SELECT uniq(UserID) FROM distributed_table
```
will be sent to all remote servers as
``` sql
SELECT uniq(UserID) FROM local_table
```
and run on each of them in parallel, until it reaches the stage where intermediate results can be combined. Then the intermediate results will be returned to the requestor server and merged on it, and the final result will be sent to the client.
Now let’s examine a query with IN:
``` sql
SELECT uniq(UserID) FROM distributed_table WHERE CounterID = 101500 AND UserID IN (SELECT UserID FROM local_table WHERE CounterID = 34)
```
- Calculation of the intersection of audiences of two sites.
This query will be sent to all remote servers as
``` sql
SELECT uniq(UserID) FROM local_table WHERE CounterID = 101500 AND UserID IN (SELECT UserID FROM local_table WHERE CounterID = 34)
```
In other words, the data set in the IN clause will be collected on each server independently, only across the data that is stored locally on each of the servers.
This will work correctly and optimally if you are prepared for this case and have spread data across the cluster servers such that the data for a single UserID resides entirely on a single server. In this case, all the necessary data will be available locally on each server. Otherwise, the result will be inaccurate. We refer to this variation of the query as “local IN”.
To correct how the query works when data is spread randomly across the cluster servers, you could specify **distributed\_table** inside a subquery. The query would look like this:
``` sql
SELECT uniq(UserID) FROM distributed_table WHERE CounterID = 101500 AND UserID IN (SELECT UserID FROM distributed_table WHERE CounterID = 34)
```
This query will be sent to all remote servers as
``` sql
SELECT uniq(UserID) FROM local_table WHERE CounterID = 101500 AND UserID IN (SELECT UserID FROM distributed_table WHERE CounterID = 34)
```
The subquery will begin running on each remote server. Since the subquery uses a distributed table, the subquery that is on each remote server will be resent to every remote server as
``` sql
SELECT UserID FROM local_table WHERE CounterID = 34
```
For example, if you have a cluster of 100 servers, executing the entire query will require 10,000 elementary requests, which is generally considered unacceptable.
In such cases, you should always use GLOBAL IN instead of IN. Let’s look at how it works for the query
``` sql
SELECT uniq(UserID) FROM distributed_table WHERE CounterID = 101500 AND UserID GLOBAL IN (SELECT UserID FROM distributed_table WHERE CounterID = 34)
```
The requestor server will run the subquery
``` sql
SELECT UserID FROM distributed_table WHERE CounterID = 34
```
and the result will be put in a temporary table in RAM. Then the request will be sent to each remote server as
``` sql
SELECT uniq(UserID) FROM local_table WHERE CounterID = 101500 AND UserID GLOBAL IN _data1
```
and the temporary table `_data1` will be sent to every remote server with the query (the name of the temporary table is implementation-defined).
This is more optimal than using the normal IN. However, keep the following points in mind:
1. When creating a temporary table, data is not made unique. To reduce the volume of data transmitted over the network, specify DISTINCT in the subquery. (You don’t need to do this for a normal IN.)
2. The temporary table will be sent to all the remote servers. Transmission does not account for network topology. For example, if 10 remote servers reside in a datacenter that is very remote in relation to the requestor server, the data will be sent 10 times over the channel to the remote datacenter. Try to avoid large data sets when using GLOBAL IN.
3. When transmitting data to remote servers, restrictions on network bandwidth are not configurable. You might overload the network.
4. Try to distribute data across servers so that you don’t need to use GLOBAL IN on a regular basis.
5. If you need to use GLOBAL IN often, plan the location of the ClickHouse cluster so that a single group of replicas resides in no more than one data center with a fast network between them, so that a query can be processed entirely within a single data center.
It also makes sense to specify a local table in the `GLOBAL IN` clause, in case this local table is only available on the requestor server and you want to use data from it on remote servers.
### Extreme Values {#extreme-values}
In addition to results, you can also get minimum and maximum values for the results columns. To do this, set the **extremes** setting to 1. Minimums and maximums are calculated for numeric types, dates, and dates with times. For other columns, the default values are output.
An extra two rows are calculated – the minimums and maximums, respectively. These extra two rows are output in `JSON*`, `TabSeparated*`, and `Pretty*` [formats](../../interfaces/formats.md), separate from the other rows. They are not output for other formats.
In `JSON*` formats, the extreme values are output in a separate ‘extremes’ field. In `TabSeparated*` formats, the row comes after the main result, and after ‘totals’ if present. It is preceded by an empty row (after the other data). In `Pretty*` formats, the row is output as a separate table after the main result, and after `totals` if present.
Extreme values are calculated for rows before `LIMIT`, but after `LIMIT BY`. However, when using `LIMIT offset, size`, the rows before `offset` are included in `extremes`. In stream requests, the result may also include a small number of rows that passed through `LIMIT`.
### Notes {#notes}
The `GROUP BY` and `ORDER BY` clauses do not support positional arguments. This contradicts MySQL, but conforms to standard SQL.
For example, `GROUP BY 1, 2` will be interpreted as grouping by constants (i.e. aggregation of all rows into one).
You can use synonyms (`AS` aliases) in any part of a query.
You can put an asterisk in any part of a query instead of an expression. When the query is analyzed, the asterisk is expanded to a list of all table columns (excluding the `MATERIALIZED` and `ALIAS` columns). There are only a few cases when using an asterisk is justified:
- When creating a table dump.
- For tables containing just a few columns, such as system tables.
- For getting information about what columns are in a table. In this case, set `LIMIT 1`. But it is better to use the `DESC TABLE` query.
- When there is strong filtration on a small number of columns using `PREWHERE`.
- In subqueries (since columns that aren’t needed for the external query are excluded from subqueries).
In all other cases, we don’t recommend using the asterisk, since it only gives you the drawbacks of a columnar DBMS instead of the advantages. In other words using the asterisk is not recommended.
[Original article](https://clickhouse.tech/docs/en/query_language/select/) <!--hide-->

8
docs/es/interfaces/third-party/integrations.md vendored
View File

@ -26,7 +26,10 @@ toc_title: "Integraci\xF3n"
- [Método de codificación de datos:](https://github.com/zlzforever/ClickHouseMigrator)
- Colas de mensajes
- [Kafka](https://kafka.apache.org)
- [Método de codificación de datos:](https://github.com/housepower/clickhouse_sinker) (utilizar [Ir cliente](https://github.com/kshvakov/clickhouse/))
- [clickhouse\_sinker](https://github.com/housepower/clickhouse_sinker) (usos [Go client](https://github.com/ClickHouse/clickhouse-go/))
- Procesamiento de flujo
- [Flink](https://flink.apache.org)
- [flink-clickhouse-sink](https://github.com/ivi-ru/flink-clickhouse-sink)
- Almacenamiento de objetos
- [S3](https://en.wikipedia.org/wiki/Amazon_S3)
- [Haga clic en el botón de copia de seguridad](https://github.com/AlexAkulov/clickhouse-backup)
@ -74,6 +77,9 @@ toc_title: "Integraci\xF3n"
- [sqlalchemy-clickhouse](https://github.com/cloudflare/sqlalchemy-clickhouse) (utilizar [InformaciónSistema abierto.](https://github.com/Infinidat/infi.clickhouse_orm))
- [pandas](https://pandas.pydata.org)
- [Pandahouse](https://github.com/kszucs/pandahouse)
- PHP
- [Doctrine](https://www.doctrine-project.org/)
- [dbal-clickhouse](https://packagist.org/packages/friendsofdoctrine/dbal-clickhouse)
- R
- [Dplyr](https://db.rstudio.com/dplyr/)
- [Bienvenidos al Portal de Licitación Electrónica de Licitación Electrónica](https://github.com/IMSMWU/RClickhouse) (utilizar [Bienvenidos](https://github.com/artpaul/clickhouse-cpp))

3
docs/fa/interfaces/third-party/integrations.md vendored
View File

@ -74,6 +74,9 @@ toc_title: "\u06CC\u06A9\u067E\u0627\u0631\u0686\u06AF\u06CC"
- [sqlalchemy-clickhouse](https://github.com/cloudflare/sqlalchemy-clickhouse) (استفاده [اطالعات.کلیک \_شورم](https://github.com/Infinidat/infi.clickhouse_orm))
- [پانداها](https://pandas.pydata.org)
- [پانداهاوس](https://github.com/kszucs/pandahouse)
- PHP
- [Doctrine](https://www.doctrine-project.org/)
- [dbal-clickhouse](https://packagist.org/packages/friendsofdoctrine/dbal-clickhouse)
- R
- [هواپیمای دوباله](https://db.rstudio.com/dplyr/)
- [خانه روستایی](https://github.com/IMSMWU/RClickhouse) (استفاده [صفحه اصلی](https://github.com/artpaul/clickhouse-cpp))

3
docs/fr/interfaces/third-party/integrations.md vendored
View File

@ -74,6 +74,9 @@ toc_title: "Int\xE9gration"
- [sqlalchemy-clickhouse](https://github.com/cloudflare/sqlalchemy-clickhouse) (utiliser [infi.clickhouse\_orm](https://github.com/Infinidat/infi.clickhouse_orm))
- [Panda](https://pandas.pydata.org)
- [pandahouse](https://github.com/kszucs/pandahouse)
- PHP
- [Doctrine](https://www.doctrine-project.org/)
- [dbal-clickhouse](https://packagist.org/packages/friendsofdoctrine/dbal-clickhouse)
- R
- [dplyr](https://db.rstudio.com/dplyr/)
- [RClickhouse](https://github.com/IMSMWU/RClickhouse) (utiliser [clickhouse-cpp](https://github.com/artpaul/clickhouse-cpp))

3
docs/ja/interfaces/third-party/integrations.md vendored
View File

@ -74,6 +74,9 @@ toc_title: "\u7D71\u5408"
- [sqlalchemy-clickhouse](https://github.com/cloudflare/sqlalchemy-clickhouse) (用途 [infi.clickhouse\_orm](https://github.com/Infinidat/infi.clickhouse_orm))
- [パンダ](https://pandas.pydata.org)
- [パンダハウス](https://github.com/kszucs/pandahouse)
- PHP
- [Doctrine](https://www.doctrine-project.org/)
- [dbal-clickhouse](https://packagist.org/packages/friendsofdoctrine/dbal-clickhouse)
- R
- [dplyr](https://db.rstudio.com/dplyr/)
- [Rクリックハウス](https://github.com/IMSMWU/RClickhouse) (用途 [クリックハウス-cpp](https://github.com/artpaul/clickhouse-cpp))

1
docs/redirects.txt
View File

@ -43,6 +43,7 @@ dicts/external_dicts_dict_sources.md query_language/dicts/external_dicts_dict_so
dicts/external_dicts_dict_structure.md query_language/dicts/external_dicts_dict_structure.md
dicts/index.md query_language/dicts/index.md
dicts/internal_dicts.md query_language/dicts/internal_dicts.md
extended_roadmap.md whats_new/extended_roadmap.md
formats.md interfaces/formats.md
formats/capnproto.md interfaces/formats.md
formats/csv.md interfaces/formats.md

4
docs/ru/commercial/index.md
View File

@ -1,7 +1,7 @@
---
toc_folder_title: Commercial
toc_folder_title: Коммерческие услуги
toc_priority: 70
toc_title: Commercial
toc_title: Коммерческие услуги
---

2
docs/ru/engines/index.md
View File

@ -1,5 +1,5 @@
---
toc_folder_title: Engines
toc_folder_title: Движки
toc_priority: 25
---

5
docs/ru/getting_started/example_datasets/index.md
View File

@ -1,3 +1,8 @@
---
toc_folder_title: Тестовые массивы данных
toc_priority: 12
toc_title: Обзор
---
# Тестовые массивы данных
Этот раздел описывает как получить тестовые массивы данных и загрузить их в ClickHouse.

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

@ -1,3 +1,10 @@
---
toc_folder_title: Начало работы
toc_hidden: true
toc_priority: 8
toc_title: hidden
---
# Начало работы {#nachalo-raboty}
Если вы новичок в ClickHouse и хотите вживую оценить его производительность, прежде всего нужно пройти через [процесс установки](install.md).

6
docs/ru/guides/index.md
View File

@ -1,3 +1,9 @@
---
toc_folder_title: Руководства
toc_priority: 38
toc_title: Обзор
---
# Руководства {#rukovodstva}
Подробные пошаговые инструкции, которые помогут вам решать различные задачи с помощью ClickHouse.

5
docs/ru/index.md
View File

@ -1,3 +1,8 @@
---
toc_priority: 0
toc_title: Обзор
---
# Что такое ClickHouse {#chto-takoe-clickhouse}
ClickHouse - столбцовая система управления базами данных (СУБД) для онлайн обработки аналитических запросов (OLAP).

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

@ -1,3 +1,9 @@
---
toc_folder_title: Интерфейсы
toc_priority: 14
toc_title: Введение
---
# Интерфейсы {#interfaces}
ClickHouse предоставляет два сетевых интерфейса (оба могут быть дополнительно обернуты в TLS для дополнительной безопасности):

2
docs/ru/interfaces/third-party/index.md vendored
View File

@ -1,5 +1,5 @@
---
toc_folder_title: Third-Party
toc_folder_title: От сторонних разработчиков
toc_priority: 24
---

70
docs/ru/interfaces/third-party/integrations.md vendored
View File

@ -7,66 +7,72 @@
- Реляционные системы управления базами данных
- [MySQL](https://www.mysql.com)
- [ProxySQL](https://github.com/sysown/proxysql/wiki/ClickHouse-Support)
- [clickhouse-mysql-data-reader](https://github.com/Altinity/clickhouse-mysql-data-reader)
- [horgh-replicator](https://github.com/larsnovikov/horgh-replicator)
- [ProxySQL](https://github.com/sysown/proxysql/wiki/ClickHouse-Support)
- [clickhouse-mysql-data-reader](https://github.com/Altinity/clickhouse-mysql-data-reader)
- [horgh-replicator](https://github.com/larsnovikov/horgh-replicator)
- [PostgreSQL](https://www.postgresql.org)
- [clickhousedb\_fdw](https://github.com/Percona-Lab/clickhousedb_fdw)
- [infi.clickhouse\_fdw](https://github.com/Infinidat/infi.clickhouse_fdw) (использует [infi.clickhouse\_orm](https://github.com/Infinidat/infi.clickhouse_orm))
- [pg2ch](https://github.com/mkabilov/pg2ch)
- [clickhouse\_fdw](https://github.com/adjust/clickhouse_fdw)
- [clickhousedb\_fdw](https://github.com/Percona-Lab/clickhousedb_fdw)
- [infi.clickhouse\_fdw](https://github.com/Infinidat/infi.clickhouse_fdw) (использует [infi.clickhouse\_orm](https://github.com/Infinidat/infi.clickhouse_orm))
- [pg2ch](https://github.com/mkabilov/pg2ch)
- [clickhouse\_fdw](https://github.com/adjust/clickhouse_fdw)
- [MSSQL](https://en.wikipedia.org/wiki/Microsoft_SQL_Server)
- [ClickHouseMightrator](https://github.com/zlzforever/ClickHouseMigrator)
- [ClickHouseMightrator](https://github.com/zlzforever/ClickHouseMigrator)
- Очереди сообщений
- [Kafka](https://kafka.apache.org)
- [clickhouse\_sinker](https://github.com/housepower/clickhouse_sinker) (использует [Go client](https://github.com/kshvakov/clickhouse/))
- [clickhouse\_sinker](https://github.com/housepower/clickhouse_sinker) (использует [Go client](https://github.com/ClickHouse/clickhouse-go/))
- Потоковая обработка
- [Flink](https://flink.apache.org)
- [flink-clickhouse-sink](https://github.com/ivi-ru/flink-clickhouse-sink)
- Хранилища объектов
- [S3](https://en.wikipedia.org/wiki/Amazon_S3)
- [clickhouse-backup](https://github.com/AlexAkulov/clickhouse-backup)
- [clickhouse-backup](https://github.com/AlexAkulov/clickhouse-backup)
- Оркестрация контейнеров
- [Kubernetes](https://kubernetes.io)
- [clickhouse-operator](https://github.com/Altinity/clickhouse-operator)
- [clickhouse-operator](https://github.com/Altinity/clickhouse-operator)
- Системы управления конфигурацией
- [puppet](https://puppet.com)
- [innogames/clickhouse](https://forge.puppet.com/innogames/clickhouse)
- [mfedotov/clickhouse](https://forge.puppet.com/mfedotov/clickhouse)
- [innogames/clickhouse](https://forge.puppet.com/innogames/clickhouse)
- [mfedotov/clickhouse](https://forge.puppet.com/mfedotov/clickhouse)
- Мониторинг
- [Graphite](https://graphiteapp.org)
- [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](../../engines/table_engines/mergetree_family/graphitemergetree.md#graphitemergetree) согласно правилам в [конфигурации rollup](../../engines/table_engines/mergetree_family/graphitemergetree.md#rollup-configuration)
- [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](../../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)
- [clickhouse-grafana](https://github.com/Vertamedia/clickhouse-grafana)
- [Prometheus](https://prometheus.io/)
- [clickhouse\_exporter](https://github.com/f1yegor/clickhouse_exporter)
- [PromHouse](https://github.com/Percona-Lab/PromHouse)
- [clickhouse\_exporter](https://github.com/hot-wifi/clickhouse_exporter) (использует [Go client](https://github.com/kshvakov/clickhouse/))
- [clickhouse\_exporter](https://github.com/f1yegor/clickhouse_exporter)
- [PromHouse](https://github.com/Percona-Lab/PromHouse)
- [clickhouse\_exporter](https://github.com/hot-wifi/clickhouse_exporter) (использует [Go client](https://github.com/kshvakov/clickhouse/))
- [Nagios](https://www.nagios.org/)
- [check\_clickhouse](https://github.com/exogroup/check_clickhouse/)
- [check\_clickhouse.py](https://github.com/innogames/igmonplugins/blob/master/src/check_clickhouse.py)
- [check\_clickhouse](https://github.com/exogroup/check_clickhouse/)
- [check\_clickhouse.py](https://github.com/innogames/igmonplugins/blob/master/src/check_clickhouse.py)
- [Zabbix](https://www.zabbix.com)
- [clickhouse-zabbix-template](https://github.com/Altinity/clickhouse-zabbix-template)
- [clickhouse-zabbix-template](https://github.com/Altinity/clickhouse-zabbix-template)
- [Sematext](https://sematext.com/)
- [clickhouse интеграция](https://github.com/sematext/sematext-agent-integrations/tree/master/clickhouse)
- [clickhouse интеграция](https://github.com/sematext/sematext-agent-integrations/tree/master/clickhouse)
- Логирование
- [rsyslog](https://www.rsyslog.com/)
- [omclickhouse](https://www.rsyslog.com/doc/master/configuration/modules/omclickhouse.html)
- [omclickhouse](https://www.rsyslog.com/doc/master/configuration/modules/omclickhouse.html)
- [fluentd](https://www.fluentd.org)
- [loghouse](https://github.com/flant/loghouse) (для [Kubernetes](https://kubernetes.io))
- [logagent](https://www.sematext.com/logagent)
- [logagent output-plugin-clickhouse](https://sematext.com/docs/logagent/output-plugin-clickhouse/)
- [loghouse](https://github.com/flant/loghouse) (для [Kubernetes](https://kubernetes.io))
- [Sematext](https://www.sematext.com/logagent)
- [logagent output-plugin-clickhouse](https://sematext.com/docs/logagent/output-plugin-clickhouse/)
- Гео
- [MaxMind](https://dev.maxmind.com/geoip/)
- [clickhouse-maxmind-geoip](https://github.com/AlexeyKupershtokh/clickhouse-maxmind-geoip)
- [clickhouse-maxmind-geoip](https://github.com/AlexeyKupershtokh/clickhouse-maxmind-geoip)
## Экосистемы вокруг языков программирования {#ekosistemy-vokrug-iazykov-programmirovaniia}
- Python
- [SQLAlchemy](https://www.sqlalchemy.org)
- [sqlalchemy-clickhouse](https://github.com/cloudflare/sqlalchemy-clickhouse) (использует [infi.clickhouse\_orm](https://github.com/Infinidat/infi.clickhouse_orm))
- [sqlalchemy-clickhouse](https://github.com/cloudflare/sqlalchemy-clickhouse) (использует [infi.clickhouse\_orm](https://github.com/Infinidat/infi.clickhouse_orm))
- [pandas](https://pandas.pydata.org)
- [pandahouse](https://github.com/kszucs/pandahouse)
- [pandahouse](https://github.com/kszucs/pandahouse)
- PHP
- [Doctrine](https://www.doctrine-project.org/)
- [dbal-clickhouse](https://packagist.org/packages/friendsofdoctrine/dbal-clickhouse)
- R
- [dplyr](https://db.rstudio.com/dplyr/)
- [RClickhouse](https://github.com/IMSMWU/RClickhouse) (использует [clickhouse-cpp](https://github.com/artpaul/clickhouse-cpp))

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

@ -1,5 +1,5 @@
---
toc_folder_title: Introduction
toc_folder_title: Введение
toc_priority: 1
---

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

@ -1,3 +1,9 @@
---
toc_folder_title: Эксплуатация
toc_priority: 41
toc_title: Введение
---
# Эксплуатация {#ekspluatatsiia}
Руководство по эксплуатации ClickHouse состоит из следующих основных разделов:

43
docs/ru/operations/settings/settings.md
View File

@ -213,6 +213,49 @@ INSERT INTO datetime_t SELECT now()
Ok.
```
## input\_format\_values\_deduce\_templates\_of\_expressions {#settings-input_format_values_deduce_templates_of_expressions}
Включает или отключает попытку вычисления шаблона для выражений SQL в формате [Values](../../interfaces/formats.md#data-format-values). Это позволяет гораздо быстрее парсить и интерпретировать выражения в `Values`, если выражения в последовательных строках имеют одинаковую структуру. ClickHouse пытается вычислить шаблон выражения, распарсить следующие строки с помощью этого шаблона и вычислить выражение в пачке успешно проанализированных строк.
Возможные значения:
- 0 — Выключена.
- 1 — Включена.
Значение по умолчанию: 1.
Для следующего запроса:
``` sql
INSERT INTO test VALUES (lower('Hello')), (lower('world')), (lower('INSERT')), (upper('Values')), ...
```
- Если `input_format_values_interpret_expressions=1` и `format_values_deduce_templates_of_expressions=0`, выражения интерпретируются отдельно для каждой строки (это очень медленно для большого количества строк).
- Если `input_format_values_interpret_expressions=0` и `format_values_deduce_templates_of_expressions=1`, выражения в первой, второй и третьей строках парсятся с помощью шаблона `lower(String)` и интерпретируется вместе, выражение в четвертой строке парсится с другим шаблоном (`upper(String)`).
- Если `input_format_values_interpret_expressions=1` и `format_values_deduce_templates_of_expressions=1`, то же самое, что и в предыдущем случае, но также позволяет выполнять резервную интерпретацию выражений отдельно, если невозможно вычислить шаблон.
## input\_format\_values\_accurate\_types\_of\_literals {#settings-input-format-values-accurate-types-of-literals}
Эта настройка используется, только когда `input_format_values_deduce_templates_of_expressions = 1`. Выражения для некоторых столбцов могут иметь одинаковую структуру, но содержат числовые литералы разных типов, например:
``` sql
(..., abs(0), ...), -- UInt64 literal
(..., abs(3.141592654), ...), -- Float64 literal
(..., abs(-1), ...), -- Int64 literal
```
Возможные значения:
- 0 — Выключена.
В этом случае, ClickHouse может использовать более общий тип для некоторых литералов (например, `Float64` или `Int64` вместо `UInt64` для `42`), но это может привести к переполнению и проблемам с точностью.
- 1 — Включена.
В этом случае, ClickHouse проверяет фактический тип литерала и использует шаблон выражения соответствующего типа. В некоторых случаях это может значительно замедлить оценку выажения в `Values`.
Значение по умолчанию: 1.
## input\_format\_defaults\_for\_omitted\_fields {#session_settings-input_format_defaults_for_omitted_fields}
При вставке данных запросом `INSERT`, заменяет пропущенные поля значениям по умолчанию для типа данных столбца.

6
docs/ru/sql_reference/aggregate_functions/index.md
View File

@ -1,3 +1,9 @@
---
toc_folder_title: Агрегатные функции
toc_priority: 33
toc_title: Введение
---
# Агрегатные функции {#aggregate-functions}
Агрегатные функции работают в [привычном](http://www.sql-tutorial.com/sql-aggregate-functions-sql-tutorial) для специалистов по базам данных смысле.

5
docs/ru/sql_reference/aggregate_functions/reference.md
View File

@ -723,10 +723,13 @@ uniqExact(x[, ...])
В некоторых случаях, вы всё же можете рассчитывать на порядок выполнения запроса. Это — случаи, когда `SELECT` идёт из подзапроса, в котором используется `ORDER BY`.
## groupArrayInsertAt(x) {#grouparrayinsertatx}
## groupArrayInsertAt(value, position) {#grouparrayinsertatvalue-position}
Вставляет в массив значение в заданную позицию.
!!! note "Примечание"
Эта функция использует нумерацию массивов с нуля, в отличие от принятой в SQL нумерации с единицы.
Принимает на вход значение и позицию. Если на одну и ту же позицию вставляется несколько значений, в результирующем массиве может оказаться любое (первое в случае однопоточного выполнения). Если в позицию не вставляется ни одного значения, то позиции присваивается значение по умолчанию.
Опциональные параметры:

6
docs/ru/sql_reference/data_types/index.md
View File

@ -1,3 +1,9 @@
---
toc_folder_title: Типы данных
toc_priority: 37
toc_title: Введение
---
# Типы данных {#data_types}
ClickHouse может сохранять в ячейках таблиц данные различных типов.

38
docs/ru/sql_reference/functions/array_functions.md
View File

@ -931,4 +931,42 @@ SELECT arrayCompact([1, 1, nan, nan, 2, 3, 3, 3])
└────────────────────────────────────────────┘
```
## arrayZip {#arrayzip}
Объединяет несколько массивов в один. Результирующий массив содержит соответственные элементы исходных массивов, сгруппированные в кортежи в указанном порядке аргументов.
**Синтаксис**
``` sql
arrayZip(arr1, arr2, ..., arrN)
```
**Параметры**
- `arrN` — [Массив](../data_types/array.md).
Функция принимает любое количество массивов, которые могут быть различных типов. Все массивы должны иметь одинаковую длину.
**Возвращаемое значение**
- Массив с элементами исходных массивов, сгруппированными в [кортежи](../data_types/tuple.md). Типы данных в кортежах соответствуют типам данных входных массивов и следуют в том же порядке, в котором переданы массивы.
Тип: [Массив](../data_types/array.md).
**Пример**
Запрос:
``` sql
SELECT arrayZip(['a', 'b', 'c'], [5, 2, 1])
```
Ответ:
``` text
┌─arrayZip(['a', 'b', 'c'], [5, 2, 1])─┐
│ [('a',5),('b',2),('c',1)] │
└──────────────────────────────────────┘
```
[Оригинальная статья](https://clickhouse.tech/docs/ru/query_language/functions/array_functions/) <!--hide-->

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

@ -1,3 +1,10 @@
---
toc_folder_title: Справка по SQL
toc_hidden: true
toc_priority: 28
toc_title: hidden
---
# Справка по SQL {#spravka-po-sql}
- [SELECT](statements/select.md)

5
docs/ru/sql_reference/statements/alter.md
View File

@ -1,3 +1,8 @@
---
toc_priority: 36
toc_title: ALTER
---
## ALTER {#query_language_queries_alter}
Запрос `ALTER` поддерживается только для таблиц типа `*MergeTree`, а также `Merge` и `Distributed`. Запрос имеет несколько вариантов.

5
docs/ru/sql_reference/statements/create.md
View File

@ -1,3 +1,8 @@
---
toc_priority: 35
toc_title: CREATE
---
## CREATE DATABASE {#query-language-create-database}
Создает базу данных.

2
docs/ru/sql_reference/statements/index.md
View File

@ -1,5 +1,5 @@
---
toc_folder_title: Statements
toc_folder_title: Выражения
toc_priority: 31
---

5
docs/ru/sql_reference/statements/insert_into.md
View File

@ -1,3 +1,8 @@
---
toc_priority: 34
toc_title: INSERT INTO
---
## INSERT {#insert}
Добавление данных.

5
docs/ru/sql_reference/statements/select.md
View File

@ -1,3 +1,8 @@
---
toc_priority: 33
toc_title: SELECT
---
# Синтаксис запросов SELECT {#sintaksis-zaprosov-select}
`SELECT` осуществляет выборку данных.

6
docs/ru/sql_reference/table_functions/index.md
View File

@ -1,3 +1,9 @@
---
toc_folder_title: Табличные функции
toc_priority: 34
toc_title: Введение
---
# Табличные функции {#tablichnye-funktsii}
Табличные функции — это метод создания таблиц.

179
docs/ru/extended_roadmap.md → docs/ru/whats_new/extended_roadmap.md
View File

@ -39,18 +39,20 @@ Upd. Большая часть задачи реализована и добав
Требует 1.3. Будет делать [Александр Сапин](https://github.com/alesapin). Ура, сделано.
### 1.5. ALTER RENAME COLUMN. {#alter-rename-column}
### 1.5. + ALTER RENAME COLUMN. {#alter-rename-column}
[\#6861](https://github.com/ClickHouse/ClickHouse/issues/6861)
Требует 1.3. Будет делать [Александр Сапин](https://github.com/alesapin).
### 1.6. Полиморфные куски данных. {#polimorfnye-kuski-dannykh}
### 1.6. + Полиморфные куски данных. {#polimorfnye-kuski-dannykh}
Компактные куски - Q1, куски в оперативке Q1/Q2.
Компактные куски - Q1, куски в оперативке Q1/Q2 - пункт 1.7.
Компактные куски реализованы, ещё не включены по-умолчанию. Первым шагом включаем по-умолчанию для системных таблиц.
Upd. Включено для системных таблиц.
Делает [Антон Попов](https://github.com/CurtizJ), первый рабочий вариант в декабре. Пререквизит чтобы снизить сложность мелких INSERT, что в свою очередь нужно для 1.12, иначе задача 1.12 не сможет нормально работать. Особенно нужно для Яндекс.Облака.
Данные в таблицах типа MergeTree в ClickHouse хранятся в виде набора независимых «кусков». Внутри куска, каждый столбец, а также индекс, хранится в отдельных файлах. Это сделано для возможности быстрых манипуляций со столбцами (пример - запрос ALTER DROP COLUMN). При вставке данных (INSERT), создаётся новый кусок. Для таблиц с большим количеством столбцов, запросы INSERT с маленьким количеством строк являются неэффективными, так как требуют создания большого количества файлов в файловой системе. Это является врождённой особенностью ClickHouse - одной из первой проблем, с которыми сталкиваются пользователи. Пользователям приходится буферизовывать данные и собирать их в более крупные пачки перед вставкой в ClickHouse.
@ -61,7 +63,7 @@ Upd. Большая часть задачи реализована и добав
### 1.7. Буферизация и WAL в MergeTree. {#buferizatsiia-i-wal-v-mergetree}
Требует 1.6.
Требует 1.6. Антон Попов. Задача взята в работу. Q2.
### 1.8. + Перенос между разделами по TTL. {#perenos-mezhdu-razdelami-po-ttl}
@ -74,7 +76,7 @@ Q1. Закоммичено, но есть технический долг, ко
Будет делать Сорокин Николай, ВШЭ и Яндекс.
Сейчас пользователь может задать в таблице выражение, которое определяет, сколько времени хранятся данные. Обычно это выражение задаётся относительно значения столбца с датой - например: удалять данные через три месяца. https://clickhouse.tech/docs/ru/operations/table\_engines/mergetree/\#table\_engine-mergetree-ttl
Сейчас пользователь может задать в таблице выражение, которое определяет, сколько времени хранятся данные. Обычно это выражение задаётся относительно значения столбца с датой - например: удалять данные через три месяца. https://clickhouse.tech/docs/ru/operations/table_engines/mergetree/\#table_engine-mergetree-ttl
Это может быть задано для всей таблицы (тогда строки целиком удаляются после указанного времени) или для отдельных столбцов (тогда данные столбца физически удаляются с диска, а строки в таблице остаются; при чтении значений столбца, они читаются как значения по-умолчанию).
@ -88,7 +90,7 @@ Q1. Закоммичено, но есть технический долг, ко
А вот пункт 2 требуется продумать. Не очевидно даже, какой лучше использовать синтаксис для этого при создании таблицы. Но мы придумаем - сразу видно несколько вариантов.
Частный случай такой задачи уже есть в https://clickhouse.tech/docs/ru/operations/table\_engines/graphitemergetree/ Но это было сделано для конкретной задачи. А надо обобщить.
Частный случай такой задачи уже есть в https://clickhouse.tech/docs/ru/operations/table_engines/graphitemergetree/ Но это было сделано для конкретной задачи. А надо обобщить.
### 1.10. Пережатие старых данных в фоне. {#perezhatie-starykh-dannykh-v-fone}
@ -100,17 +102,15 @@ Q1. Закоммичено, но есть технический долг, ко
Предлагается добавить в ClickHouse настройки по пережатию данных и фоновые потоки, выполняющие эту задачу.
### 1.11. Виртуальная файловая система. {#virtualnaia-failovaia-sistema}
### 1.11. + Виртуальная файловая система. {#virtualnaia-failovaia-sistema}
В процессе реализации, сейчас на VFS переведены Log, TinyLog, StripeLog, готовится MergeTree.
На VFS переведены Log, TinyLog, StripeLog, а также MergeTree, что доказывает состоятельность реализации.
Q2.
Нужно для Яндекс.Облака. Делает Александр, Яндекс.Облако, а также Олег Ершов, ВШЭ и Яндекс.
Нужно для Яндекс.Облака. Делает Александр, Яндекс.Облако.
ClickHouse использует для хранения данных локальную файловую систему. Существует сценарий работы, в котором размещение старых (архивных) данных было бы выгодно на удалённой файловой системе. Если файловая система POSIX совместимая, то это не составляет проблем: ClickHouse успешно работает с Ceph, GlusterFS, MooseFS. Также востребованным является сценарий использования S3 (из-за доступности в облаке) или HDFS (для интеграции с Hadoop). Но эти файловые системы не являются POSIX совместимыми. Хотя для них существуют FUSE драйверы, но скорость работы сильно страдает и поддержка неполная.
ClickHouse использует небольшое подмножество функций ФС, но в то же время, и некоторые специфические части: симлинки и хардлинки, O\_DIRECT. Предлагается выделить всё взаимодействие с файловой системой в отдельный интерфейс.
ClickHouse использует небольшое подмножество функций ФС, но в то же время, и некоторые специфические части: симлинки и хардлинки, O_DIRECT. Предлагается выделить всё взаимодействие с файловой системой в отдельный интерфейс.
### 1.12. Экспериментальная реализация VFS поверх S3 и HDFS. {#eksperimentalnaia-realizatsiia-vfs-poverkh-s3-i-hdfs}
@ -121,13 +121,15 @@ Q2.
Upd. Олег будет делать только часть про HDFS.
Upd. Реализация поверх S3 является рабочей на уровне PoC.
### 1.13. Ускорение запросов с FINAL. {#uskorenie-zaprosov-s-final}
Требует 2.1. Делает [Николай Кочетов](https://github.com/KochetovNicolai). Нужно для Яндекс.Метрики.
Требует 2.1. Делает [Николай Кочетов](https://github.com/KochetovNicolai). Нужно для Яндекс.Метрики. Q2.
### 1.14. Не писать столбцы, полностью состоящие из нулей. {#ne-pisat-stolbtsy-polnostiu-sostoiashchie-iz-nulei}
Антон Попов. Q1/Q2.
Антон Попов. Q2.
В очереди. Простая задача, является небольшим пререквизитом для потенциальной поддержки полуструктурированных данных.
### 1.15. Возможность иметь разный первичный ключ в разных кусках. {#vozmozhnost-imet-raznyi-pervichnyi-kliuch-v-raznykh-kuskakh}
@ -146,6 +148,7 @@ Upd. Олег будет делать только часть про HDFS.
Требует 1.3 и 1.6. Полная замена hard links на sym links, что будет лучше для 1.12.
## 2. Крупные рефакторинги. {#krupnye-refaktoringi}
Для обоснования необходимости смотрите ссылки в описании других задач.
@ -161,6 +164,8 @@ Upd. Включили по-умолчанию. Удаление старого
Upd. Уже есть первый релиз, в котором это включено по-умолчанию.
Upd. Всё ещё ждём удаление старого кода, которое должно случиться после релиза 20.4.
### 2.2. Инфраструктура событий/метрик/ограничений/квот/трассировки. {#infrastruktura-sobytiimetrikogranicheniikvottrassirovki}
В очереди. https://gist.github.com/alexey-milovidov/d62d73222d83b9319dc519cbb13aeff6
@ -193,6 +198,8 @@ Upd. Каталог БД вынесен из Context.
Средний приоритет. Нужно для YQL.
Upd. В очереди. Иван Лежанкин.
### 2.9. Логгировние в format-стиле. {#loggirovnie-v-format-stile}
Делает [Иван Лежанкин](https://github.com/abyss7). Низкий приоритет.
@ -212,10 +219,14 @@ Upd. Каталог БД вынесен из Context.
Задачу делает Алексей Миловидов. Прогресс 50% и разработка временно приостановлена.
Upd. Разработка всё ещё приостановлена.
### 2.13. Каждая функция в отдельном файле. {#kazhdaia-funktsiia-v-otdelnom-faile}
Задачу делает Алексей Миловидов. Прогресс 80%. Потребуется помощь других разработчиков.
Upd. Поползновения наблюдаются.
### 2.14. Все функции с состоянием переделать на FunctionBuilder. {#vse-funktsii-s-sostoianiem-peredelat-na-functionbuilder}
Долг [Николай Кочетов](https://github.com/KochetovNicolai). Сейчас код находится в переходном состоянии, что неприемлемо.
@ -224,13 +235,14 @@ Upd. Каталог БД вынесен из Context.
Для нормализации работы materialized views поверх Merge, Distributed, Kafka.
## 3. Документация. {#dokumentatsiia}
Здесь задачи только по инфраструктуре документации.
### 3.1. Перенос документации по функциям в код. {#perenos-dokumentatsii-po-funktsiiam-v-kod}
Требует 2.12 и 2.13. Хотим в Q1/Q2, средний приоритет.
Требует 2.12 и 2.13. Хотим в Q2, средний приоритет.
### 3.2. Перенос однородных частей документации в код. {#perenos-odnorodnykh-chastei-dokumentatsii-v-kod}
@ -246,11 +258,12 @@ Upd. Иван Блинков сделал эту задачу путём зам
Эту задачу сделает [Иван Блинков](https://github.com/blinkov/), до конца декабря 2019. Сделано.
## 4. Сетевое взаимодействие. {#setevoe-vzaimodeistvie}
### 4.1. Уменьшение числа потоков при распределённых запросах. {#umenshenie-chisla-potokov-pri-raspredelionnykh-zaprosakh}
[Никита Лапков](https://github.com/laplab), весна 2020. Upd. Есть прототип. Upd. Он не работает.
Весна 2020. Upd. Есть прототип. Upd. Он не работает. Upd. Человек отказался от задачи, теперь сроки не определены.
### 4.2. Спекулятивное выполнение запросов на нескольких репликах. {#spekuliativnoe-vypolnenie-zaprosov-na-neskolkikh-replikakh}
@ -262,6 +275,8 @@ Upd. Иван Блинков сделал эту задачу путём зам
Сейчас для распределённых запросов используется по потоку на соединение. Это позволяет хорошо распараллелить вычисления над полученными данными и утилизировать сеть, но становится сильно избыточным для больших кластеров. Для примера, создание 1000 потоков для чтения данных из 1000 серверов кластера - лишь расходует ресурсы и увеличивает время выполнения запроса. Вместо этого необходимо использовать количество потоков не большее количества процессорных ядер, и мультиплексировать в одном потоке общение с серверами. Реализация нетривиальна, так как мультиплексировать необходимо каждую стадию общения по сети, включая установку соединения и обмен handshake.
Upd. Сейчас обсуждается, как сделать другую задачу вместо этой.
### 4.3. Ограничение числа одновременных скачиваний с реплик. {#ogranichenie-chisla-odnovremennykh-skachivanii-s-replik}
Дмитрий Григорьев, ВШЭ.
@ -284,14 +299,16 @@ Upd. Иван Блинков сделал эту задачу путём зам
Дмитрий Григорьев, ВШЭ.
В очереди. Исправить проблему, что восстанавливающаяся реплика перестаёт мержить. Частично компенсируется 4.3.
## 5. Операции. {#operatsii}
### 5.1. Разделение задач на более мелкие куски в clickhouse-copier. {#razdelenie-zadach-na-bolee-melkie-kuski-v-clickhouse-copier}
### 5.1. + Разделение задач на более мелкие куски в clickhouse-copier. {#razdelenie-zadach-na-bolee-melkie-kuski-v-clickhouse-copier}
[\#9075](https://github.com/ClickHouse/ClickHouse/pull/9075)
Q1. Нужно для Метрики, в очереди. Никита Михайлов.
Upd. Задача на финальной стадии разработки.
Upd. Сделано. Эффективность работы под вопросом. Есть варианты, как сделать лучше.
### 5.2. Автонастройка лимита на оперативку и размера кэшей. {#avtonastroika-limita-na-operativku-i-razmera-keshei}
@ -305,6 +322,8 @@ Upd. Задача на финальной стадии разработки.
Требует 7.5. Задачу хочет Метрика, Облако, БК, Маркет и Altinity. Первой LTS версией уже стала версия 19.14.
Метрика, БК, Маркет, Altinity уже используют более свежие версии чем LTS.
Upd. Появилась вторая версия LTS - 20.3.
## 6. Инструментирование. {#instrumentirovanie}
@ -321,7 +340,7 @@ Upd. Задача на финальной стадии разработки.
### 6.3. Учёт оперативки total расширить не только на запросы. {#uchiot-operativki-total-rasshirit-ne-tolko-na-zaprosy}
Исправление долгоживущей проблемы с дрифтом учёта оперативки. Нужна для Метрики и БК. Иван Лежанкин. Q1.
Исправление долгоживущей проблемы с дрифтом учёта оперативки. Нужна для Метрики и БК. Иван Лежанкин. Q1. Странно, как будто не сделано.
### 6.4. Поддержка perf events как метрик запроса. {#podderzhka-perf-events-kak-metrik-zaprosa}
@ -339,7 +358,7 @@ Upd. Задача на финальной стадии разработки.
Сейчас есть стек трейс для почти всех, но не всех исключений. Требует 7.4.
### 6.7. + Таблица system.stack\_trace. {#tablitsa-system-stack-trace}
### 6.7. + Таблица system.stack_trace. {#tablitsa-system-stack-trace}
Сравнительно простая задача, но только для опытных разработчиков.
@ -351,6 +370,7 @@ Upd. Задача на финальной стадии разработки.
### 6.10. Сбор общих системных метрик. {#sbor-obshchikh-sistemnykh-metrik}
## 7. Сопровождение разработки. {#soprovozhdenie-razrabotki}
### 7.1. + ICU в submodules. {#icu-v-submodules}
@ -361,7 +381,7 @@ Upd. Задача на финальной стадии разработки.
Сделал Алексей Миловидов.
### 7.3. Обновление Poco. {#obnovlenie-poco}
### 7.3. + Обновление Poco. {#obnovlenie-poco}
Алексанр Кузьменков.
@ -383,13 +403,18 @@ Upd. Задача на финальной стадии разработки.
Уже есть ASan, TSan, UBSan. Не хватает тестов под MSan. Они уже добавлены в CI, но не проходят.
[Александр Кузьменков](https://github.com/akuzm) и [Александр Токмаков](https://github.com/tavplubix).
### 7.8. Добавить clang-tidy. {#dobavit-clang-tidy}
Upd. Задача всё ещё медленно тащится.
### 7.8. + Добавить clang-tidy. {#dobavit-clang-tidy}
Уже есть PVS-Studio. Мы очень довольны, но этого недостаточно.
Upd. Алексей Миловидов. Добавлено некоторое множество проверок, но нужно рассмотреть все проверки подряд и добавить всё, что можно.
Upd. Рассмотрели все проверки подряд.
### 7.9. Проверки на стиль имён с помощью clang-tidy. {#proverki-na-stil-imion-s-pomoshchiu-clang-tidy}
### 7.9. + Проверки на стиль имён с помощью clang-tidy. {#proverki-na-stil-imion-s-pomoshchiu-clang-tidy}
Сделано. Только в .cpp файлах и только для имён локальных переменных. Остальное слишком сложно.
### 7.10. Включение UBSan и MSan в интеграционных тестах. {#vkliuchenie-ubsan-i-msan-v-integratsionnykh-testakh}
@ -399,6 +424,8 @@ UBSan включен в функциональных тестах, но не в
У нас мало unit тестов по сравнению с функциональными тестами и их использование не обязательно. Но они всё-равно важны и нет причин не запускать их под всеми видами sanitizers.
Илья Яцишин.
### 7.12. Показывать тестовое покрытие нового кода в PR. {#pokazyvat-testovoe-pokrytie-novogo-koda-v-pr}
Пока есть просто показ тестового покрытия всего кода.
@ -413,6 +440,8 @@ UBSan включен в функциональных тестах, но не в
Подключение replxx вместо readline сделал Иван Лежанкин.
Есть технический долг с лицензиями файлов консорциума Unicode.
### 7.14.1. Улучшение возможностей интерактивного режима clickhouse-client. {#uluchshenie-vozmozhnostei-interaktivnogo-rezhima-clickhouse-client}
Тагир Кускаров, ВШЭ.
@ -476,7 +505,7 @@ https://github.com/ClickHouse/ClickHouse/issues/8027\#issuecomment-566670282
Проверили на настоящем сервере Huawei, а также в специальном Docker контейнере, который содержит внутри qemu-user-static.
Также можно проверить на Cavium, на Raspberry Pi а также на твоём Android телефоне.
### 7.20. Автосборка для FreeBSD x86\_64. {#avtosborka-dlia-freebsd-x86-64}
### 7.20. Автосборка для FreeBSD x86_64. {#avtosborka-dlia-freebsd-x86-64}
[Иван Лежанкин](https://github.com/abyss7).
@ -535,6 +564,8 @@ Fuzzing тестирование - это тестирование случай
Также можно сделать функции с детерминированным генератором случайных чисел (аргументом передаётся seed) для воспроизводимости тестовых кейсов.
Upd. Сергей Штыков сделал функцию `randomPrintableASCII`.
Upd. Илья Яцишин сделал табличную функцию `generateRandom`.
Upd. Эльдар Заитов добавляет OSS Fuzz.
### 7.24. Fuzzing лексера и парсера запросов; кодеков и форматов. {#fuzzing-leksera-i-parsera-zaprosov-kodekov-i-formatov}
@ -557,10 +588,12 @@ Upd. Сергей Штыков сделал функцию `randomPrintableASCII
Нужно для CHYT и YQL.
UPD: Все патчи Максима отправлены в master. Задача взята в работу.
Upd: Все патчи Максима отправлены в master. Задача взята в работу.
Upd: Задача в процессе реализации. Синхронизироваться будет master. Делает [Иван Лежанкин](https://github.com/abyss7)
Upd: Есть собирающийся прототип, но сборка как будто ещё не в trunk Аркадии.
### 7.26. Побайтовая идентичность репозитория с Аркадией. {#pobaitovaia-identichnost-repozitoriia-s-arkadiei}
Команда DevTools. Прогресс по задаче под вопросом.
@ -617,6 +650,7 @@ Upd: Задача в процессе реализации. Синхронизи
Upd. Иван Блинков настроил CDN repo.clickhouse.tech, что решает проблему с доступностью зарубежом.
Вопрос с operations, visibility пока актуален.
## 8. Интеграция с внешними системами. {#integratsiia-s-vneshnimi-sistemami}
### 8.1. Поддержка ALTER MODIFY SETTING для Kafka. {#podderzhka-alter-modify-setting-dlia-kafka}
@ -629,11 +663,11 @@ Altinity. Никто не делает эту задачу.
[Александр Кузьменков](https://github.com/akuzm).
### 8.3. Доработки globs (правильная поддержка диапазонов, уменьшение числа одновременных stream-ов). {#dorabotki-globs-pravilnaia-podderzhka-diapazonov-umenshenie-chisla-odnovremennykh-stream-ov}
### 8.3. + Доработки globs (правильная поддержка диапазонов, уменьшение числа одновременных stream-ов). {#dorabotki-globs-pravilnaia-podderzhka-diapazonov-umenshenie-chisla-odnovremennykh-stream-ov}
[Ольга Хвостикова](https://github.com/stavrolia).
Уменьшение числа stream-ов сделано, а вот правильная поддержка диапазонов - нет. Будем надеяться на Q1/Q2.
Уменьшение числа stream-ов сделано, а вот правильная поддержка диапазонов - нет. Будем надеяться на Q1/Q2. Сделано.
### 8.4. Унификация File, HDFS, S3 под URL. {#unifikatsiia-file-hdfs-s3-pod-url}
@ -690,19 +724,21 @@ Andrew Onyshchuk. Есть pull request. Q1. Сделано.
Павел Круглов, ВШЭ и Яндекс. Есть pull request.
### 8.16.2. Поддержка формата Thrift. {#podderzhka-formata-thrift}
### 8.16.2. - Поддержка формата Thrift. {#podderzhka-formata-thrift}
Павел Круглов, ВШЭ и Яндекс.
Павел Круглов, ВШЭ и Яндекс. Задача отменена.
### 8.16.3. Поддержка формата MsgPack. {#podderzhka-formata-msgpack}
Павел Круглов, ВШЭ и Яндекс.
Задача взята в работу.
### 8.16.4. Формат Regexp. {#format-regexp}
Upd. Почти готово - есть лишь небольшой технический долг.
### 8.16.4. + Формат Regexp. {#format-regexp}
Павел Круглов, ВШЭ и Яндекс.
Есть pull request.
Есть pull request. Готово.
### 8.17. ClickHouse как MySQL реплика. {#clickhouse-kak-mysql-replika}
@ -735,6 +771,7 @@ Maxim Fedotov, Wargaming + Yuri Baranov, Яндекс.
Нужно для БК. Декабрь 2019.
В декабре для БК сделан минимальный вариант этой задачи.
Максимальный вариант, вроде, никому не нужен.
Upd. Всё ещё кажется, что задача не нужна.
### 8.22. Поддержка синтаксиса для переменных в стиле MySQL. {#podderzhka-sintaksisa-dlia-peremennykh-v-stile-mysql}
@ -746,6 +783,7 @@ Upd. Юрий Баранов работает в Google, там запрещен
Желательно 2.15.
## 9. Безопасность. {#bezopasnost}
### 9.1. + Ограничение на хосты в запросах ко внешним системам. {#ogranichenie-na-khosty-v-zaprosakh-ko-vneshnim-sistemam}
@ -761,7 +799,12 @@ ClickHouse предоставляет возможность обратитьс
Вместо этого предлагается описывать необходимые данные в конфигурационном файле сервера или в отдельном сервисе и ссылаться на них по именам.
### 9.3. Поддержка TLS для ZooKeeper. {#podderzhka-tls-dlia-zookeeper}
[#10174](https://github.com/ClickHouse/ClickHouse/issues/10174)
Есть pull request.
## 10. Внешние словари. {#vneshnie-slovari}
### 10.1. + Исправление зависания в библиотеке доступа к YT. {#ispravlenie-zavisaniia-v-biblioteke-dostupa-k-yt}
@ -777,6 +820,7 @@ ClickHouse предоставляет возможность обратитьс
Нужно для БК и Метрики. Поиск причин - [Александр Сапин](https://github.com/alesapin). Дальшейшее исправление возможно на стороне YT.
Upd. Одну причину устранили, но ещё что-то неизвестное осталось.
Upd. Нас заставляют переписать эту библиотеку с одного API на другое, так как старое внезапно устарело. Кажется, что переписывание случайно исправит все проблемы.
### 10.3. Возможность чтения данных из статических таблиц в YT словарях. {#vozmozhnost-chteniia-dannykh-iz-staticheskikh-tablits-v-yt-slovariakh}
@ -802,7 +846,7 @@ Upd. Одну причину устранили, но ещё что-то неи
Артём Стрельцов, Николай Дегтеринский, Наталия Михненко, ВШЭ.
### 10.9. Уменьшение блокировок для cache словарей за счёт одновременных запросов одного и того же. {#umenshenie-blokirovok-dlia-cache-slovarei-za-schiot-odnovremennykh-zaprosov-odnogo-i-togo-zhe}
### 10.9. - Уменьшение блокировок для cache словарей за счёт одновременных запросов одного и того же. {#umenshenie-blokirovok-dlia-cache-slovarei-za-schiot-odnovremennykh-zaprosov-odnogo-i-togo-zhe}
Заменено в пользу 10.10, 10.11.
@ -825,7 +869,7 @@ Upd. Одну причину устранили, но ещё что-то неи
### 10.14. Поддержка всех типов в функции transform. {#podderzhka-vsekh-tipov-v-funktsii-transform}
Задачу взяла Ольга Хвостикова.
Задачу взяла Ольга Хвостикова. Upd. Статус неизвестен.
### 10.15. Использование словарей как специализированного layout для Join. {#ispolzovanie-slovarei-kak-spetsializirovannogo-layout-dlia-join}
@ -843,6 +887,7 @@ Upd. Одну причину устранили, но ещё что-то неи
### 10.19. Возможность зарегистрировать некоторые функции, использующие словари, под пользовательскими именами. {#vozmozhnost-zaregistrirovat-nekotorye-funktsii-ispolzuiushchie-slovari-pod-polzovatelskimi-imenami}
## 11. Интерфейсы. {#interfeisy}
### 11.1. Вставка состояний агрегатных функций в виде кортежа аргументов или массива кортежей аргументов. {#vstavka-sostoianii-agregatnykh-funktsii-v-vide-kortezha-argumentov-ili-massiva-kortezhei-argumentov}
@ -851,6 +896,8 @@ Upd. Одну причину устранили, но ещё что-то неи
Нужно разобраться, как упаковывать Java в статический бинарник, возможно AppImage. Или предоставить максимально простую инструкцию по установке jdbc-bridge. Может быть будет заинтересован Александр Крашенинников, Badoo, так как он разработал jdbc-bridge.
Upd. Александр Крашенинников перешёл в другую компанию и больше не занимается этим.
### 11.3. + Интеграционные тесты ODBC драйвера путём подключения ClickHouse к самому себе через ODBC. {#integratsionnye-testy-odbc-draivera-putiom-podkliucheniia-clickhouse-k-samomu-sebe-cherez-odbc}
Михаил Филимонов, Altinity. Готово.
@ -881,12 +928,13 @@ zhang2014, есть pull request.
Возможность описать в конфигурационном файле handler (путь в URL) для HTTP запросов к серверу, которому соответствует некоторый параметризованный запрос. Пользователь может вызвать этот обработчик и не должен передавать SQL запрос.
## 12. Управление пользователями и доступом. {#upravlenie-polzovateliami-i-dostupom}
### 12.1. Role Based Access Control. {#role-based-access-control}
### 12.1. + Role Based Access Control. {#role-based-access-control}
[Виталий Баранов](https://github.com/vitlibar). Финальная стадия разработки, рабочая версия в начале февраля 2019.
Q1. Сейчас сделаны все интерфейсы в коде и запросы, но не сделаны варианты хранения прав кроме прототипа.
[Виталий Баранов](https://github.com/vitlibar). Финальная стадия разработки, рабочая версия в начале апреля 2019.
Q2. Сейчас сделаны все интерфейсы в коде и запросы, но не сделаны варианты хранения прав кроме прототипа.
Upd. Сделано хранение прав. До готового к использованию состояния осталось несколько доработок.
### 12.2. + Управление пользователями и правами доступа с помощью SQL запросов. {#upravlenie-polzovateliami-i-pravami-dostupa-s-pomoshchiu-sql-zaprosov}
@ -897,7 +945,7 @@ Q1. Сделано управление правами полностью, но
### 12.3. Подключение справочника пользователей и прав доступа из LDAP. {#podkliuchenie-spravochnika-polzovatelei-i-prav-dostupa-iz-ldap}
[Виталий Баранов](https://github.com/vitlibar). Требует 12.1.
Q1/Q2.
Q2.
### 12.4. Подключение IDM системы Яндекса как справочника пользователей и прав доступа. {#podkliuchenie-idm-sistemy-iandeksa-kak-spravochnika-polzovatelei-i-prav-dostupa}
@ -911,6 +959,7 @@ Q1/Q2.
[Виталий Баранов](https://github.com/vitlibar). Требует 12.1.
## 13. Разделение ресурсов, multi-tenancy. {#razdelenie-resursov-multi-tenancy}
### 13.1. Overcommit запросов по памяти и вытеснение. {#overcommit-zaprosov-po-pamiati-i-vytesnenie}
@ -926,6 +975,8 @@ Q1/Q2.
Требует 13.2 или сможем сделать более неудобную реализацию раньше.
Обсуждается вариант неудобной реализации. Пока средний приоритет, целимся на Q1/Q2.
Вариант реализации выбрал Александр Казаков.
Upd. Не уследили, и задачу стали обсуждать менеджеры.
## 14. Диалект SQL. {#dialekt-sql}
@ -936,8 +987,6 @@ Q1/Q2.
### 14.2. Поддержка WITH для подзапросов. {#podderzhka-with-dlia-podzaprosov}
Михаил Коротов.
### 14.3. Поддержка подстановок для множеств в правой части IN. {#podderzhka-podstanovok-dlia-mnozhestv-v-pravoi-chasti-in}
### 14.4. Поддержка подстановок для идентификаторов (имён) в SQL запросе. {#podderzhka-podstanovok-dlia-identifikatorov-imion-v-sql-zaprose}
@ -993,7 +1042,7 @@ zhang2014
### 14.16. Синонимы для функций из MySQL. {#sinonimy-dlia-funktsii-iz-mysql}
### 14.17. Ввести понятие stateful функций. {#vvesti-poniatie-stateful-funktsii}
### 14.17. + Ввести понятие stateful функций. {#vvesti-poniatie-stateful-funktsii}
zhang2014.
Для runningDifference, neighbour - их учёт в оптимизаторе запросов.
@ -1018,13 +1067,15 @@ zhang2014.
Павел Потёмкин, ВШЭ.
## 15. Улучшение поддержки JOIN. {#uluchshenie-podderzhki-join}
### 15.1. Доведение merge JOIN до продакшена. {#dovedenie-merge-join-do-prodakshena}
### 15.1. + Доведение merge JOIN до продакшена. {#dovedenie-merge-join-do-prodakshena}
Артём Зуйков. Сейчас merge JOIN включается вручную опцией и всегда замедляет запросы. Хотим, чтобы он замедлял запросы только когда это неизбежно.
Кстати, смысл merge JOIN появляется только совместно с 15.2 и 15.3.
Q1. Сделали адаптивный вариант, но вроде он что-то всё-ещё замедляет.
Задача сделана, но всё работает слишком медленно.
### 15.1.1. Алгоритм two-level merge JOIN. {#algoritm-two-level-merge-join}
@ -1052,6 +1103,7 @@ Q1. Сделали адаптивный вариант, но вроде он ч
Артём Зуйков.
## 16. Типы данных и функции. {#tipy-dannykh-i-funktsii}
### 16.1. + DateTime64. {#datetime64}
@ -1073,6 +1125,7 @@ Upd. Секретного изменения в работе не будет, з
### 16.6. Функции нормализации и хэширования SQL запросов. {#funktsii-normalizatsii-i-kheshirovaniia-sql-zaprosov}
## 17. Работа с географическими данными. {#rabota-s-geograficheskimi-dannymi}
### 17.1. Гео-словари для определения региона по координатам. {#geo-slovari-dlia-opredeleniia-regiona-po-koordinatam}
@ -1105,6 +1158,7 @@ Upd. Андрей сделал прототип более оптимально
Сейчас функция тихо не работает в случае полигонов с самопересечениями, надо кидать исключение.
## 18. Машинное обучение и статистика. {#mashinnoe-obuchenie-i-statistika}
### 18.1. Инкрементальная кластеризация данных. {#inkrementalnaia-klasterizatsiia-dannykh}
@ -1123,6 +1177,7 @@ Upd. Андрей сделал прототип более оптимально
В очереди. Возможно, Александр Кожихов. У него сначала идёт задача 24.26.
## 19. Улучшение работы кластера. {#uluchshenie-raboty-klastera}
### 19.1. Параллельные кворумные вставки без линеаризуемости. {#parallelnye-kvorumnye-vstavki-bez-linearizuemosti}
@ -1153,7 +1208,7 @@ Upd. Алексей сделал какой-то вариант, но борет
Hold. Полезно для заказчиков внутри Яндекса, но есть риски. Эту задачу никто не будет делать.
### 19.4. internal\_replication = ‘auto’. {#internal-replication-auto}
### 19.4. internal_replication = ‘auto’. {#internal-replication-auto}
### 19.5. Реплицируемые базы данных. {#replitsiruemye-bazy-dannykh}
@ -1177,18 +1232,20 @@ Hold. Полезно для заказчиков внутри Яндекса, н
Требует 1.6, 19.1, 19.6, 19.7, 19.8, 19.9.
## 20. Мутации данных. {#mutatsii-dannykh}
Пока все задачи по точечным UPDATE/DELETE имеют низкий приоритет, но ожидаем взять в работу в середине 2020.
### 20.1. Поддержка DELETE путём запоминания множества затронутых кусков и ключей. {#podderzhka-delete-putiom-zapominaniia-mnozhestva-zatronutykh-kuskov-i-kliuchei}
### 20.2. Поддержка DELETE путём преобразования множества ключей в множество row\_numbers на реплике, столбца флагов и индекса по диапазонам. {#podderzhka-delete-putiom-preobrazovaniia-mnozhestva-kliuchei-v-mnozhestvo-row-numbers-na-replike-stolbtsa-flagov-i-indeksa-po-diapazonam}
### 20.2. Поддержка DELETE путём преобразования множества ключей в множество row_numbers на реплике, столбца флагов и индекса по диапазонам. {#podderzhka-delete-putiom-preobrazovaniia-mnozhestva-kliuchei-v-mnozhestvo-row-numbers-na-replike-stolbtsa-flagov-i-indeksa-po-diapazonam}
### 20.3. Поддержка ленивых DELETE путём запоминания выражений и преобразования к множеству ключей в фоне. {#podderzhka-lenivykh-delete-putiom-zapominaniia-vyrazhenii-i-preobrazovaniia-k-mnozhestvu-kliuchei-v-fone}
### 20.4. Поддержка UPDATE с помощью преобразования в DELETE и вставок. {#podderzhka-update-s-pomoshchiu-preobrazovaniia-v-delete-i-vstavok}
## 21. Оптимизации производительности. {#optimizatsii-proizvoditelnosti}
### 21.1. + Параллельный парсинг форматов. {#parallelnyi-parsing-formatov}
@ -1201,7 +1258,7 @@ Hold. Полезно для заказчиков внутри Яндекса, н
После 21.1, предположительно Никита Михайлов. Задача сильно проще чем 21.1.
### 21.3. Исправление низкой производительности анализа индекса в случае большого множества в секции IN. {#ispravlenie-nizkoi-proizvoditelnosti-analiza-indeksa-v-sluchae-bolshogo-mnozhestva-v-sektsii-in}
### 21.3. + Исправление низкой производительности анализа индекса в случае большого множества в секции IN. {#ispravlenie-nizkoi-proizvoditelnosti-analiza-indeksa-v-sluchae-bolshogo-mnozhestva-v-sektsii-in}
Нужно всем (Zen, БК, DataLens, TestEnv…). Антон Попов, Q1/Q2.
@ -1309,23 +1366,23 @@ Constraints позволяют задать выражение, истиннос
В ClickHouse используется неоптимальный вариант top sort. Суть его в том, что из каждого блока достаётся top N записей, а затем, все блоки мержатся. Но доставание top N записей у каждого следующего блока бессмысленно, если мы знаем, что из них в глобальный top N войдёт меньше. Конечно нужно реализовать вариацию на тему priority queue (heap) с быстрым пропуском целых блоков, если ни одна строка не попадёт в накопленный top.
1. Рекурсивный вариант сортировки по кортежам.
2. Рекурсивный вариант сортировки по кортежам.
Для сортировки по кортежам используется обычная сортировка с компаратором, который в цикле по элементам кортежа делает виртуальные вызовы `IColumn::compareAt`. Это неоптимально - как из-за короткого цикла по неизвестному в compile-time количеству элементов, так и из-за виртуальных вызовов. Чтобы обойтись без виртуальных вызовов, есть метод `IColumn::getPermutation`. Он используется в случае сортировки по одному столбцу. Есть вариант, что в случае сортировки по кортежу, что-то похожее тоже можно применить… например, сделать метод `updatePermutation`, принимающий аргументы offset и limit, и допереставляющий перестановку в диапазоне значений, в которых предыдущий столбец имел равные значения.
1. RadixSort для сортировки.
3. RadixSort для сортировки.
Один наш знакомый начал делать задачу по попытке использования RadixSort для сортировки столбцов. Был сделан вариант indirect сортировки (для `getPermutation`), но не оптимизирован до конца - есть лишние ненужные перекладывания элементов. Для того, чтобы его оптимизировать, придётся добавить немного шаблонной магии (на последнем шаге что-то не копировать, вместо перекладывания индексов - складывать их в готовое место). Также этот человек добавил метод MSD Radix Sort для реализации radix partial sort. Но даже не проверил производительность.
Наиболее содержательная часть задачи может состоять в применении Radix Sort для сортировки кортежей, расположенных в оперативке в виде Structure Of Arrays неизвестного в compile-time размера. Это может работать хуже, чем то, что описано в пункте 2… Но попробовать не помешает.
1. Three-way comparison sort.
4. Three-way comparison sort.
Виртуальный метод `compareAt` возвращает -1, 0, 1. Но алгоритмы сортировки сравнениями обычно рассчитаны на `operator<` и не могут получить преимущества от three-way comparison. А можно ли написать так, чтобы преимущество было?
1. pdq partial sort
5. pdq partial sort
Хороший алгоритм сортировки сравнениями `pdqsort` не имеет варианта partial sort. Заметим, что на практике, почти все сортировки в запросах ClickHouse являются partial\_sort, так как `ORDER BY` почти всегда идёт с `LIMIT`. Кстати, Данила Кутенин уже попробовал это и показал, что в тривиальном случае преимущества нет. Но не очевидно, что нельзя сделать лучше.
Хороший алгоритм сортировки сравнениями `pdqsort` не имеет варианта partial sort. Заметим, что на практике, почти все сортировки в запросах ClickHouse являются partial_sort, так как `ORDER BY` почти всегда идёт с `LIMIT`. Кстати, Данила Кутенин уже попробовал это и показал, что в тривиальном случае преимущества нет. Но не очевидно, что нельзя сделать лучше.
### 21.20. Использование материализованных представлений для оптимизации запросов. {#ispolzovanie-materializovannykh-predstavlenii-dlia-optimizatsii-zaprosov}
@ -1344,6 +1401,7 @@ Constraints позволяют задать выражение, истиннос
zhang2014.
Есть pull request.
## 22. Долги и недоделанные возможности. {#dolgi-i-nedodelannye-vozmozhnosti}
### 22.1. + Исправление неработающих таймаутов, если используется TLS. {#ispravlenie-nerabotaiushchikh-taimautov-esli-ispolzuetsia-tls}
@ -1362,6 +1420,7 @@ N.Vartolomei.
Александр Казаков. Нужно для Яндекс.Метрики и Datalens. Задача постепенно тащится и исправлениями в соседних местах стала менее актуальна.
В Q1 будет сделана или отменена с учётом 1.2. и 1.3.
Upd. Добавили таймауты.
### 22.5. + Исправление редких срабатываний TSan в stress тестах в CI. {#ispravlenie-redkikh-srabatyvanii-tsan-v-stress-testakh-v-ci}
@ -1470,18 +1529,19 @@ Altinity.
[Александр Сапин](https://github.com/alesapin)
## 23. Default Festival. {#default-festival}
### 23.1. + Включение minimalistic\_part\_header в ZooKeeper. {#vkliuchenie-minimalistic-part-header-v-zookeeper}
### 23.1. + Включение minimalistic_part_header в ZooKeeper. {#vkliuchenie-minimalistic-part-header-v-zookeeper}
Сильно уменьшает объём данных в ZooKeeper. Уже год в продакшене в Яндекс.Метрике.
Алексей Миловидов, ноябрь 2019.
### 23.2. Включение distributed\_aggregation\_memory\_efficient. {#vkliuchenie-distributed-aggregation-memory-efficient}
### 23.2. Включение distributed_aggregation_memory_efficient. {#vkliuchenie-distributed-aggregation-memory-efficient}
Есть риски меньшей производительности лёгких запросов, хотя производительность тяжёлых запросов всегда увеличивается.
### 23.3. Включение min\_bytes\_to\_external\_sort и min\_bytes\_to\_external\_group\_by. {#vkliuchenie-min-bytes-to-external-sort-i-min-bytes-to-external-group-by}
### 23.3. Включение min_bytes_to_external_sort и min_bytes_to_external_group_by. {#vkliuchenie-min-bytes-to-external-sort-i-min-bytes-to-external-group-by}
Желательно 5.2. и 13.1.
@ -1489,7 +1549,7 @@ Altinity.
Есть гипотеза, что плохо работает на очень больших кластерах.
### 23.5. Включение compile\_expressions. {#vkliuchenie-compile-expressions}
### 23.5. Включение compile_expressions. {#vkliuchenie-compile-expressions}
Требует 7.2. Задачу изначально на 99% сделал Денис Скоробогатов, ВШЭ и Яндекс. Остальной процент доделывал Алексей Миловидов, а затем [Александр Сапин](https://github.com/alesapin).
@ -1514,6 +1574,7 @@ Q1. [Николай Кочетов](https://github.com/KochetovNicolai).
Возможность mlock бинарника сделал Олег Алексеенков [\#3553](https://github.com/ClickHouse/ClickHouse/pull/3553)
. Поможет, когда на серверах кроме ClickHouse работает много посторонних программ (мы иногда называем их в шутку «треш-программами»).
## 24. Экспериментальные задачи. {#eksperimentalnye-zadachi}
### 24.1. Веб-интерфейс для просмотра состояния кластера и профилирования запросов. {#veb-interfeis-dlia-prosmotra-sostoianiia-klastera-i-profilirovaniia-zaprosov}
@ -1553,7 +1614,7 @@ ClickHouse поддерживает LZ4 и ZSTD для сжатия данных
Смотрите также 24.5.
1. Шифрование отдельных значений.
2. Шифрование отдельных значений.
Для этого требуется реализовать функции шифрования и расшифрования, доступные из SQL. Для шифрования реализовать возможность добавления нужного количества случайных бит для исключения одинаковых зашифрованных значений на одинаковых данных. Это позволит реализовать возможность «забывания» данных без удаления строк таблицы: можно шифровать данные разных клиентов разными ключами, и для того, чтобы забыть данные одного клиента, потребуется всего лишь удалить ключ.
### 24.6. Userspace RAID. {#userspace-raid}
@ -1586,7 +1647,7 @@ RAID позволяет одновременно увеличить надёжн
Дмитрий Ковальков, ВШЭ и Яндекс.
Подавляющее большинство кода ClickHouse написана для x86\_64 с набором инструкций до SSE 4.2 включительно. Лишь отдельные редкие функции поддерживают AVX/AVX2/AVX512 с динамической диспетчеризацией.
Подавляющее большинство кода ClickHouse написана для x86_64 с набором инструкций до SSE 4.2 включительно. Лишь отдельные редкие функции поддерживают AVX/AVX2/AVX512 с динамической диспетчеризацией.
В первой части задачи, следует добавить в ClickHouse реализации некоторых примитивов, оптимизированные под более новый набор инструкций. Например, AVX2 реализацию генератора случайных чисел pcg: https://github.com/lemire/simdpcg
@ -1598,6 +1659,8 @@ RAID позволяет одновременно увеличить надёжн
Продолжение 24.8.
Upd. Есть pull request.
### 24.10. Поддержка типов half/bfloat16/unum. {#podderzhka-tipov-halfbfloat16unum}
[\#7657](https://github.com/ClickHouse/ClickHouse/issues/7657)
@ -1633,6 +1696,7 @@ ClickHouse предоставляет достаточно богатый наб
В компании nVidia сделали прототип offloading вычисления GROUP BY с некоторыми из агрегатных функций в ClickHouse и обещат предоставить исходники в публичный доступ для дальнейшего развития. Предлагается изучить этот прототип и расширить его применимость для более широкого сценария использования. В качестве альтернативы, предлагается изучить исходные коды системы `OmniSci` или `Alenka` или библиотеку `CUB` https://nvlabs.github.io/cub/ и применить некоторые из алгоритмов в ClickHouse.
Upd. В компании nVidia выложили прототип, теперь нужна интеграция в систему сборки.
Upd. Интеграция в систему сборки - Иван Лежанкин.
### 24.13. Stream запросы. {#stream-zaprosy}
@ -1791,7 +1855,7 @@ Amos Bird, но его решение слишком громоздкое и п
### 25.10. Митапы в России и Беларуси: Москва x2 + митап для разработчиков или хакатон, Санкт-Петербург, Минск, Нижний Новгород, Екатеринбург, Новосибирск и/или Академгородок, Иннополис или Казань. {#mitapy-v-rossii-i-belarusi-moskva-x2-mitap-dlia-razrabotchikov-ili-khakaton-sankt-peterburg-minsk-nizhnii-novgorod-ekaterinburg-novosibirsk-iili-akademgorodok-innopolis-ili-kazan}
Екатерина - организация
Екатерина - организация. Upd. Проведено два онлайн митапа на русском.
### 25.11. Митапы зарубежные: восток США (Нью Йорк, возможно Raleigh), возможно северо-запад (Сиэтл), Китай (Пекин снова, возможно митап для разработчиков или хакатон), Лондон. {#mitapy-zarubezhnye-vostok-ssha-niu-iork-vozmozhno-raleigh-vozmozhno-severo-zapad-sietl-kitai-pekin-snova-vozmozhno-mitap-dlia-razrabotchikov-ili-khakaton-london}
@ -1807,7 +1871,8 @@ Amos Bird, но его решение слишком громоздкое и п
### 25.14. Конференции в России: все HighLoad, возможно CodeFest, DUMP или UWDC, возможно C++ Russia. {#konferentsii-v-rossii-vse-highload-vozmozhno-codefest-dump-ili-uwdc-vozmozhno-c-russia}
Алексей Миловидов и все подготовленные докладчики
Алексей Миловидов и все подготовленные докладчики.
Upd. Есть Saint HighLoad online.
### 25.15. Конференции зарубежные: Percona, DataOps, попытка попасть на более крупные. {#konferentsii-zarubezhnye-percona-dataops-popytka-popast-na-bolee-krupnye}
@ -1848,7 +1913,7 @@ Amos Bird, но его решение слишком громоздкое и п
### 25.22. On-site помощь с ClickHouse компаниям в дни рядом с мероприятиями. {#on-site-pomoshch-s-clickhouse-kompaniiam-v-dni-riadom-s-meropriiatiiami}
[Иван Блинков](https://github.com/blinkov/) - организация
[Иван Блинков](https://github.com/blinkov/) - организация. Проверил мероприятие для турецкой компании.
### 25.23. Новый мерч для ClickHouse. {#novyi-merch-dlia-clickhouse}

2
docs/ru/whats_new/index.md
View File

@ -1,5 +1,5 @@
---
toc_folder_title: What's New
toc_folder_title: Что нового?
toc_priority: 72
---

2
docs/tools/README.md
View File

@ -38,5 +38,5 @@ The easiest way to see the result is to use `--livereload=8888` argument of buil
At the moment there’s no easy way to do just that, but you can consider:
- To hit the “Watch” button on top of GitHub web interface to know as early as possible, even during pull request. Alternative to this is `#github-activity` channel of [public ClickHouse Slack](https://join.slack.com/t/clickhousedb/shared_invite/zt-d2zxkf9e-XyxDa_ucfPxzuH4SJIm~Ng).
- To hit the “Watch” button on top of GitHub web interface to know as early as possible, even during pull request. Alternative to this is `#github-activity` channel of [public ClickHouse Slack](https://join.slack.com/t/clickhousedb/shared_invite/enQtOTUzMjM4ODQwNTc5LWJmMjE3Yjc2YmI1ZDBlZmI4ZTc3OWY3ZTIwYTljYzY4MzBlODM3YzBjZTc1YmYyODRlZTJkYTgzYzBiNTA2Yjk).
- Some search engines allow to subscribe on specific website changes via email and you can opt-in for that for https://clickhouse.tech.

7
docs/tools/build.py
View File

@ -82,6 +82,7 @@ def build_for_lang(lang, args):
'fr': 'Français',
'ru': 'Русский',
'ja': '日本語',
'tr': 'Türkçe',
'fa': 'فارسی'
}
@ -92,6 +93,7 @@ def build_for_lang(lang, args):
'fr': 'Documentation ClickHouse %s',
'ru': 'Документация ClickHouse %s',
'ja': 'ClickHouseドキュメント %s',
'tr': 'ClickHouse Belgeleri %s',
'fa': 'مستندات %sClickHouse'
}
@ -375,13 +377,14 @@ if __name__ == '__main__':
os.chdir(os.path.join(os.path.dirname(__file__), '..'))
website_dir = os.path.join('..', 'website')
arg_parser = argparse.ArgumentParser()
arg_parser.add_argument('--lang', default='en,es,fr,ru,zh,ja,fa')
arg_parser.add_argument('--lang', default='en,es,fr,ru,zh,ja,tr,fa')
arg_parser.add_argument('--docs-dir', default='.')
arg_parser.add_argument('--theme-dir', default=website_dir)
arg_parser.add_argument('--website-dir', default=website_dir)
arg_parser.add_argument('--output-dir', default='build')
arg_parser.add_argument('--enable-stable-releases', action='store_true')
arg_parser.add_argument('--stable-releases-limit', type=int, default='10')
arg_parser.add_argument('--stable-releases-limit', type=int, default='4')
arg_parser.add_argument('--lts-releases-limit', type=int, default='2')
arg_parser.add_argument('--version-prefix', type=str, default='')
arg_parser.add_argument('--is-stable-release', action='store_true')
arg_parser.add_argument('--skip-single-page', action='store_true')

54
docs/tools/github.py
View File

@ -11,38 +11,58 @@ import requests
import util
def yield_candidates():
for page in range(1, 100):
url = 'https://api.github.com/repos/ClickHouse/ClickHouse/tags?per_page=100&page=%d' % page
for candidate in requests.get(url).json():
yield candidate
def choose_latest_releases(args):
logging.info('Collecting release candidates')
seen = collections.OrderedDict()
candidates = []
for page in range(1, args.stable_releases_limit):
url = 'https://api.github.com/repos/ClickHouse/ClickHouse/tags?per_page=100&page=%d' % page
candidates += requests.get(url).json()
logging.info('Collected all release candidates')
stable_count = 0
lts_count = 0
for tag in candidates:
for tag in yield_candidates():
if isinstance(tag, dict):
name = tag.get('name', '')
is_unstable = ('stable' not in name) and ('lts' not in name)
is_stable = 'stable' in name
is_lts = 'lts' in name
is_unstable = not (is_stable or is_lts)
is_in_blacklist = ('v18' in name) or ('prestable' in name) or ('v1.1' in name)
if is_unstable or is_in_blacklist:
continue
major_version = '.'.join((name.split('.', 2))[:2])
if major_version not in seen:
seen[major_version] = (name, tag.get('tarball_url'),)
if len(seen) > args.stable_releases_limit:
if (stable_count >= args.stable_releases_limit) and (lts_count >= args.lts_releases_limit):
break
payload = (name, tag.get('tarball_url'), is_lts,)
if is_lts:
if lts_count < args.lts_releases_limit:
seen[major_version] = payload
lts_count += 1
else:
if stable_count < args.stable_releases_limit:
seen[major_version] = payload
stable_count += 1
logging.debug(
f'Stables: {stable_count}/{args.stable_releases_limit} LTS: {lts_count}/{args.lts_releases_limit}'
)
else:
logging.fatal('Unexpected GitHub response: %s', str(candidates))
sys.exit(1)
logging.info('Found stable releases: %s', str(seen.keys()))
logging.info('Found stable releases: %s', ', '.join(seen.keys()))
return seen.items()
def process_release(args, callback, release):
name, (full_name, tarball_url,) = release
logging.info('Building docs for %s', full_name)
name, (full_name, tarball_url, is_lts,) = release
logging.info(f'Building docs for {full_name}')
buf = io.BytesIO(requests.get(tarball_url).content)
tar = tarfile.open(mode='r:gz', fileobj=buf)
with util.temp_dir() as base_dir:
@ -79,3 +99,15 @@ def get_events(args):
'event_date': tail[1].replace('on ', '').replace('.', '')
})
return events
if __name__ == '__main__':
class DummyArgs(object):
lts_releases_limit = 1
stable_releases_limit = 3
logging.basicConfig(
level=logging.DEBUG,
stream=sys.stderr
)
for item in choose_latest_releases(DummyArgs()):
print(item)

2
docs/tools/make_links.sh
View File

@ -6,7 +6,7 @@
function do_make_links()
{
langs=(en es zh fr ru ja fa)
langs=(en es zh fr ru ja tr fa)
src_file="$1"
for lang in "${langs[@]}"
do

2
docs/tools/release.sh
View File

@ -44,7 +44,7 @@ then
if [[ ! -z "${CLOUDFLARE_TOKEN}" ]]
then
sleep 1m
git diff --stat="9999,9999" --diff-filter=M HEAD~1 | grep '|' | awk '$1 ~ /\.html$/ { if ($3>4) { url="https://'${BASE_DOMAIN}'/"$1; sub(/\/index.html/, "/", url); print "\""url"\""; }}' | split -l 25 /dev/stdin PURGE
git diff --stat="9999,9999" --diff-filter=M HEAD~1 | grep '|' | awk '$1 ~ /\.html$/ { if ($3>4) { url="https://clickhouse.tech/"$1; sub(/\/index.html/, "/", url); print "\""url"\""; }}' | split -l 25 /dev/stdin PURGE
for FILENAME in $(ls PURGE*)
do
POST_DATA=$(cat "${FILENAME}" | sed -n -e 'H;${x;s/\n/,/g;s/^,//;p;}' | awk '{print "{\"files\":["$0"]}";}')

3
docs/tools/requirements.txt
View File

@ -10,11 +10,10 @@ cssmin==0.2.0
future==0.18.2
htmlmin==0.1.12
idna==2.9
Jinja2==2.11.1
Jinja2==2.11.2
jinja2-highlight==0.6.1
jsmin==2.2.2
livereload==2.6.1
lunr==0.5.6
Markdown==3.2.1
MarkupSafe==1.1.1
mkdocs==1.1

2
docs/tools/translate/requirements.txt
View File

@ -3,7 +3,7 @@ certifi==2020.4.5.1
chardet==3.0.4
googletrans==2.4.0
idna==2.9
Jinja2==2.11.1
Jinja2==2.11.2
pandocfilters==1.4.2
python-slugify==4.0.0
PyYAML==5.3.1

4
docs/tools/translate/translate.py
View File

@ -63,8 +63,8 @@ def translate_toc(root, lang):
def translate_po():
import babel.messages.pofile
base_dir = os.path.join(os.path.dirname(__file__), '..', '..', 'website', 'locale')
for lang in ['en', 'zh', 'es', 'fr', 'ru', 'ja', 'fa']:
base_dir = os.path.join(os.path.dirname(__file__), '..', '..', '..', 'website', 'locale')
for lang in ['en', 'zh', 'es', 'fr', 'ru', 'ja', 'tr', 'fa']:
po_path = os.path.join(base_dir, lang, 'LC_MESSAGES', 'messages.po')
with open(po_path, 'r') as f:
po_file = babel.messages.pofile.read_po(f, locale=lang, domain='messages')

4
docs/tools/translate/update-po.sh
View File

@ -2,11 +2,11 @@
# Usage: update-po.sh
set -ex
BASE_DIR=$(dirname $(readlink -f $0))
WEBSITE_DIR="${BASE_DIR}/../../website"
WEBSITE_DIR="${BASE_DIR}/../../../website"
LOCALE_DIR="${WEBSITE_DIR}/locale"
MESSAGES_POT="${LOCALE_DIR}/messages.pot"
BABEL_INI="${BASE_DIR}/babel-mapping.ini"
LANGS="en zh es fr ru ja fa"
LANGS="en zh es fr ru ja tr fa"
source "${BASE_DIR}/venv/bin/activate"
cd "${WEBSITE_DIR}"
pybabel extract "." -o "${MESSAGES_POT}" -F "${BABEL_INI}"

21
docs/tr/commercial/cloud.md Normal file
View File

@ -0,0 +1,21 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
---
# ClickHouse Bulut Servis Sağlayıcıları {#clickhouse-cloud-service-providers}
!!! info "Bilgin"
Yönetilen ClickHouse hizmeti ile genel bir bulut başlattıysanız, çekinmeyin [çekme isteği aç](https://github.com/ClickHouse/ClickHouse/edit/master/docs/en/commercial/cloud.md) aşağıdaki listeye ekleyerek.
## Yandex Bulut {#yandex-cloud}
[Yandex Clickhouse için yönetilen hizmet](https://cloud.yandex.com/services/managed-clickhouse?utm_source=referrals&utm_medium=clickhouseofficialsite&utm_campaign=link3) aşağıdaki temel özellikleri sağlar:
- İçin tamamen yönetilen ZooKeeper hizmeti [ClickHouse çoğaltma](../engines/table_engines/mergetree_family/replication.md)
- Çoklu depolama tipi seçenekleri
- Farklı kullanılabilirlik bölgelerinde yinelemeler
- Şifreleme ve izolasyon
- Otomatik bakım
{## [Orijinal makale](https://clickhouse.tech/docs/en/commercial/cloud/) ##}

9
docs/tr/commercial/index.md Normal file
View File

@ -0,0 +1,9 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_folder_title: Ticari
toc_priority: 70
toc_title: Ticari
---

203
docs/tr/development/architecture.md Normal file
View File

@ -0,0 +1,203 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 62
toc_title: "ClickHouse mimarisine genel bak\u0131\u015F"
---
# ClickHouse mimarisine genel bakış {#overview-of-clickhouse-architecture}
ClickHouse gerçek bir sütun yönelimli DBMS olduğunu. Veriler sütunlar tarafından ve dizilerin yürütülmesi sırasında (vektörler veya sütun parçaları) saklanır. Mümkün olduğunda, işlemler tek tek değerler yerine dizilere gönderilir. Buna denir “vectorized query execution,” ve gerçek veri işleme maliyetini düşürmeye yardımcı olur.
> Bu fikir yeni bir şey değil. Bu kadar uzanır `APL` programlama dili ve Tor andunları: `A +`, `J`, `K`, ve `Q`. Dizi programlama bilimsel veri işlemede kullanılır. Bu fikir ilişkisel veritabanlarında yeni bir şey değildir: örneğin, `Vectorwise` sistem.
Sorgu işlemeyi hızlandırmak için iki farklı yaklaşım vardır: vektörize sorgu yürütme ve çalışma zamanı kodu oluşturma. İkincisi, tüm Yönlendirme ve dinamik gönderimi kaldırır. Bu yaklaşımların hiçbiri diğerinden kesinlikle daha iyi değildir. Çalışma zamanı kodu üretimi, birçok işlemi birleştirdiğinde daha iyi olabilir, böylece CPU yürütme birimlerini ve boru hattını tam olarak kullanır. Vectorized sorgu yürütme daha az pratik olabilir, çünkü önbelleğe yazılması ve geri okunması gereken geçici vektörler içerir. Geçici veri L2 önbelleğinde uymuyorsa, bu bir sorun haline gelir. Ancak vektörize sorgu yürütme, CPU'nun SIMD yeteneklerini daha kolay kullanır. Bir [araştırma öd paperevi](http://15721.courses.cs.cmu.edu/spring2016/papers/p5-sompolski.pdf) arkadaşlarımız tarafından yazıldı, her iki yaklaşımı birleştirmenin daha iyi olduğunu gösteriyor. ClickHouse vectorized sorgu yürütme kullanır ve çalışma zamanı kodu üretimi için başlangıç desteği sınırlıdır.
## Sütun {#columns}
`IColumn` arabirim, bellekteki sütunları temsil etmek için kullanılır (aslında, sütunların parçaları). Bu arayüz, çeşitli ilişkisel operatörlerin uygulanması için yardımcı yöntemler sağlar. Hemen hemen tüm işlemler değişmez: orijinal sütunu değiştirmezler, ancak yeni bir değiştirilmiş bir tane oluştururlar. Örneğin, `IColumn :: filter` yöntem bir filtre bayt maskesi kabul eder. Bu için kullanılır `WHERE` ve `HAVING` ilişkisel operatörler. Ek örnekler: `IColumn :: permute` desteklemek için yöntem `ORDER BY`, bu `IColumn :: cut` desteklemek için yöntem `LIMIT`.
Çeşitli `IColumn` uygulanışlar (`ColumnUInt8`, `ColumnString` ve benzeri) sütunların bellek düzeninden sorumludur. Bellek düzeni genellikle bitişik bir dizidir. Sütunların tamsayı türü için, sadece bir bitişik dizidir, örneğin `std :: vector`. İçin `String` ve `Array` sütunlar, iki vektördür: biri bitişik olarak yerleştirilmiş tüm dizi elemanları için ve her dizinin başlangıcına ait ofsetler için ikinci bir tane. Ayrıca var `ColumnConst` bu bellekte sadece bir değer depolar, ancak bir sütuna benziyor.
## Alan {#field}
Bununla birlikte, bireysel değerlerle de çalışmak mümkündür. Bireysel bir değeri temsil etmek için, `Field` kullanılır. `Field` sadece ayrımcılığa uğramış bir birlik mi `UInt64`, `Int64`, `Float64`, `String` ve `Array`. `IColumn` has the `operator[]` n - inci değerini bir olarak alma yöntemi `Field` ve... `insert` bir ekleme yöntemi `Field` bir sütunun sonuna. Bu yöntemler çok verimli değildir, çünkü geçici olarak uğraşmayı gerektirirler `Field` tek bir değeri temsil eden nesneler. Daha etkili yöntemleri vardır, mesela: `insertFrom`, `insertRangeFrom` ve bu yüzden.
`Field` bir tablo için belirli bir veri türü hakkında yeterli bilgiye sahip değildir. Mesela, `UInt8`, `UInt16`, `UInt32`, ve `UInt64` hepsi olarak temsil edilir `UInt64` in a `Field`.
## Sızdıran Soyutlamalar {#leaky-abstractions}
`IColumn` verilerin ortak ilişkisel dönüşümleri için yöntemler vardır, ancak tüm ihtiyaçları karşılamazlar. Mesela, `ColumnUInt64` iki sütunun toplamını hesaplamak için bir yöntem yoktur ve `ColumnString` bir alt dize araması çalıştırmak için bir yöntem yok. Bu sayısız rutinleri dışında uygulanmaktadır `IColumn`.
Sütunlar üzerinde çeşitli işlevler kullanarak genel, verimli olmayan bir şekilde uygulanabilir `IColumn` çıkarma yöntemleri `Field` değerleri veya belirli bir veri iç bellek düzeni bilgisini kullanarak özel bir şekilde `IColumn` uygulanış. Döküm fonksiyonları ile belirli bir `IColumn` yazın ve doğrudan iç temsil ile anlaşma. Mesela, `ColumnUInt64` has the `getData` bir iç diziye başvuru döndüren yöntem, daha sonra ayrı bir yordam okur veya bu diziyi doğrudan doldurur. Sahibiz “leaky abstractions” çeşitli rutinlerin verimli uzmanlıklarına izin vermek.
## Veri Türleri {#data_types}
`IDataType` seri hale getirme ve serileştirmeden sorumludur: ikili veya metin biçiminde sütunların veya bireysel değerlerin parçalarını okumak ve yazmak için. `IDataType` tablolardaki veri türlerine doğrudan karşılık gelir. Örneğin, `DataTypeUInt32`, `DataTypeDateTime`, `DataTypeString` ve böyle devam eder.
`IDataType` ve `IColumn` sadece gevşek birbirleriyle ilişkilidir. Farklı veri türleri bellekte aynı tarafından temsil edilebilir `IColumn` uygulanışlar. Mesela, `DataTypeUInt32` ve `DataTypeDateTime` her ikisi de tarafından temsil edilir `ColumnUInt32` veya `ColumnConstUInt32`. Buna ek olarak, aynı veri türü farklı tarafından temsil edilebilir `IColumn` uygulanışlar. Mesela, `DataTypeUInt8` tarafından temsil edilebilir `ColumnUInt8` veya `ColumnConstUInt8`.
`IDataType` yalnızca meta verileri depolar. Mesela, `DataTypeUInt8` hiçbir şey saklamıyor (vptr hariç) ve `DataTypeFixedString` mağazalar sadece `N` (sabit boyutlu dizelerin boyutu).
`IDataType` çeşitli veri formatları için yardımcı yöntemlere sahiptir. Örnekler, Olası Alıntı ile bir değeri serileştirmek, json için bir değeri serileştirmek ve XML formatının bir parçası olarak bir değeri serileştirmek için kullanılan yöntemlerdir. Veri formatlarına doğrudan yazışma yoktur. Örneğin, farklı veri biçimleri `Pretty` ve `TabSeparated` aynı kullanabilirsiniz `serializeTextEscaped` hel methodper yöntemi `IDataType` Arabirim.
## Blok {#block}
A `Block` bellekteki bir tablonun bir alt kümesini (yığın) temsil eden bir kapsayıcıdır. Bu sadece üçlü bir dizi: `(IColumn, IDataType, column name)`. Sorgu yürütme sırasında veri tarafından işlenir `Block`s. Eğer bir `Block`(bu yaptığımız verileri `IColumn` nesne), biz onun türü hakkında bilgi var (içinde `IDataType`) bu bize bu sütunla nasıl başa çıkacağımızı söyler ve sütun adına sahibiz. Tablodan orijinal sütun adı veya hesaplamaların geçici sonuçlarını almak için atanan bazı yapay ad olabilir.
Bir bloktaki sütunlar üzerinde bazı işlevleri hesapladığımızda, bloğa sonucu olan başka bir sütun ekleriz ve işlemler değişmez olduğu için işlevin argümanları için sütunlara dokunmayız. Daha sonra, gereksiz sütunlar bloktan kaldırılabilir, ancak değiştirilemez. Ortak alt ifadelerin ortadan kaldırılması için uygundur.
İşlenen her veri yığını için bloklar oluşturulur. Aynı hesaplama türü için, sütun adları ve türleri farklı bloklar için aynı kalır ve yalnızca sütun verileri değişir unutmayın. Küçük blok boyutları shared\_ptrs ve sütun adlarını kopyalamak için geçici dizeleri yüksek bir ek yükü olduğundan blok üstbilgisinden blok verileri bölmek daha iyidir.
## Blok Akışları {#block-streams}
Blok akışları veri işleme içindir. Bir yerden veri okumak, veri dönüşümleri gerçekleştirmek veya bir yere veri yazmak için blok akışları kullanıyoruz. `IBlockInputStream` has the `read` mevcut iken bir sonraki bloğu getirme yöntemi. `IBlockOutputStream` has the `write` bloğu bir yere itmek için yöntem.
Akar responsibles areular sorumludur:
1. Bir tabloya okuma veya yazma. Tablo sadece okuma veya yazma blokları için bir akış döndürür.
2. Veri formatlarının uygulanması. Örneğin, bir terminale veri çıkışı yapmak istiyorsanız `Pretty` biçim, blokları ittiğiniz bir blok çıkış akışı oluşturursunuz ve bunları biçimlendirir.
3. Veri dönüşümleri gerçekleştirme. Diyelim ki var `IBlockInputStream` ve filtrelenmiş bir akış oluşturmak istiyorum. Yarat createtığınız `FilterBlockInputStream` ve akışı ile başlatın. Sonra bir blok çektiğinizde `FilterBlockInputStream`, akışınızdan bir blok çeker, filtreler ve filtrelenmiş bloğu size döndürür. Sorgu yürütme boru hatları bu şekilde temsil edilir.
Daha sofistike dönüşümler var. Örneğin, çektiğiniz zaman `AggregatingBlockInputStream`, kaynağındaki tüm verileri okur, toplar ve sizin için toplanmış bir veri akışı döndürür. Başka bir örnek: `UnionBlockInputStream` yapıcıdaki birçok giriş kaynağını ve ayrıca bir dizi iş parçacığını kabul eder. Birden çok iş parçacığı başlatır ve paralel olarak birden fazla kaynaktan okur.
> Blok akışları “pull” akışı kontrol etme yaklaşımı: ilk akıştan bir blok çektiğinizde, gerekli blokları iç içe geçmiş akışlardan çeker ve tüm yürütme boru hattı çalışır. Ne “pull” ne “push” en iyi çözümdür, çünkü kontrol akışı örtükdür ve bu, birden fazla sorgunun eşzamanlı yürütülmesi (birçok boru hattının birlikte birleştirilmesi) gibi çeşitli özelliklerin uygulanmasını sınırlar. Bu sınırlama, coroutines ile veya sadece birbirlerini bekleyen ekstra iş parçacıkları çalıştırarak aşılabilir. Kontrol akışını açık hale getirirsek daha fazla olasılığa sahip olabiliriz: verileri bir hesaplama biriminden diğerine bu hesaplama birimlerinin dışında geçirme mantığını bulursak. Re thisad this [makale](http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-out/) daha fazla düşünce için.
Sorgu yürütme boru hattının her adımda geçici veri oluşturduğuna dikkat etmeliyiz. Blok boyutunu yeterince küçük tutmaya çalışıyoruz, böylece geçici veriler CPU önbelleğine sığıyor. Bu varsayımla, geçici veri yazmak ve okumak, diğer hesaplamalarla karşılaştırıldığında neredeyse ücretsizdir. Boru hattındaki birçok operasyonu bir araya getirmek için bir alternatif düşünebiliriz. Boru hattını mümkün olduğunca kısa hale getirebilir ve geçici verilerin çoğunu kaldırabilir, bu da bir avantaj olabilir, ancak dezavantajları da vardır. Örneğin, bölünmüş bir boru hattı, Ara verileri önbelleğe almayı, aynı anda çalışan benzer sorgulardan Ara verileri çalmayı ve benzer sorgular için boru hatlarını birleştirmeyi kolaylaştırır.
## Biçimliler {#formats}
Veri formatları blok akışları ile uygulanır. Var “presentational” sadece müşteriye veri çıkışı için uygun biçimler, örneğin `Pretty` sadece sağlayan biçim `IBlockOutputStream`. Ve gibi giriş / çıkış biçimleri vardır `TabSeparated` veya `JSONEachRow`.
Satır akışları da vardır: `IRowInputStream` ve `IRowOutputStream`. Verileri bloklarla değil, tek tek satırlarla çekmenize/itmenize izin verirler. Ve sadece satır yönelimli formatların uygulanmasını basitleştirmek için gereklidir. Sarıcı `BlockInputStreamFromRowInputStream` ve `BlockOutputStreamFromRowOutputStream` satır yönelimli akışları normal blok yönelimli akışlara dönüştürmenize izin verin.
## I/O {#io}
Bayt yönelimli giriş / çıkış için, `ReadBuffer` ve `WriteBuffer` soyut sınıflar. C++yerine kullanılırlar `iostream`s. merak etmeyin: her olgun C++ projesi başka bir şey kullanıyor `iostream`s iyi nedenlerden dolayı.
`ReadBuffer` ve `WriteBuffer` sadece bitişik bir tampon ve bu tampondaki konuma işaret eden bir imleç. Uygulamalar, arabellek belleğine sahip olabilir veya sahip olmayabilir. Arabelleği aşağıdaki verilerle doldurmak için sanal bir yöntem vardır (for `ReadBuffer`) veya tamponu bir yere yıkamak için (için `WriteBuffer`). Sanal yöntemler nadiren denir.
Uygulamaları `ReadBuffer`/`WriteBuffer` sıkıştırma uygulamak için dosyalar ve dosya tanımlayıcıları ve ağ soketleri ile çalışmak için kullanılır (`CompressedWriteBuffer` is initialized with another WriteBuffer and performs compression before writing data to it), and for other purposes – the names `ConcatReadBuffer`, `LimitReadBuffer`, ve `HashingWriteBuffer` kendileri için konuşuyoruz.
Read / WriteBuffers sadece baytlarla ilgilenir. Fonksiyonları vardır `ReadHelpers` ve `WriteHelpers` başlık dosyaları biçimlendirme giriş/çıkış ile yardımcı olmak için. Örneğin, ondalık biçimde bir sayı yazmak için yardımcılar vardır.
Bir sonuç kümesi yazmak istediğinizde neler olduğuna bakalım `JSON` stdout için biçimlendirin. Eğer bir sonuç getirilecek hazır set var `IBlockInputStream`. Yarat createtığınız `WriteBufferFromFileDescriptor(STDOUT_FILENO)` STDOUT için bayt yazmak için. Yarat createtığınız `JSONRowOutputStream` bununla başlatıldı `WriteBuffer`, satır yazmak için `JSON` stdout. Yarat createtığınız `BlockOutputStreamFromRowOutputStream` bu da yetmiyormuş gibi göstermek için `IBlockOutputStream`. Sonra Ara `copyData` veri aktarmak için `IBlockInputStream` -e doğru `IBlockOutputStream` ve her şey çalışıyor. İçten, `JSONRowOutputStream` çeşitli json sınırlayıcıları yazacak ve `IDataType::serializeTextJSON` bir referans ile yöntem `IColumn` ve satır numarası argüman olarak. Sonuç olarak, `IDataType::serializeTextJSON` bir yöntem çağırır `WriteHelpers.h`: mesela, `writeText` sayısal türler ve `writeJSONString` için `DataTypeString`.
## Tablolar {#tables}
Bu `IStorage` arayüz tabloları temsil eder. Bu arayüzün farklı uygulamaları farklı tablo motorlarıdır. Örnekler şunlardır `StorageMergeTree`, `StorageMemory` ve bu yüzden. Bu sınıfların örnekleri sadece tablolardır.
Anahtar `IStorage` yöntemler şunlardır `read` ve `write`. Ayrıca vardır `alter`, `rename`, `drop` ve bu yüzden. Bu `read` yöntem aşağıdaki bağımsız değişkenleri kabul eder: bir tablodan okunacak sütun kümesi, `AST` dikkate alınması gereken sorgu ve döndürülmesi gereken akış sayısı. Bir veya birden fazla döndürür `IBlockInputStream` nesneler ve sorgu yürütme sırasında bir tablo altyapısı içinde tamamlanan veri işleme aşaması hakkında bilgi.
Çoğu durumda, read yöntemi yalnızca belirtilen sütunları bir tablodan okumaktan sorumludur, daha fazla veri işleme için değil. Tüm diğer veri işleme sorgu yorumlayıcısı tarafından yapılır ve sorumluluk dışında `IStorage`.
Ancak önemli istisnalar var:
- AST sorgusu için geçirilir `read` yöntemi ve tablo altyapısı dizin kullanımını türetmek ve bir tablodan daha az veri okumak için kullanabilirsiniz.
- Bazen tablo motoru verileri belirli bir aşamaya kadar işleyebilir. Mesela, `StorageDistributed` uzak sunuculara sorgu gönderebilir, farklı uzak sunuculardan gelen verilerin birleştirilebileceği bir aşamaya veri işlemelerini isteyebilir ve bu önceden işlenmiş verileri döndürebilir. Sorgu yorumlayıcısı daha sonra verileri işlemeyi tamamlar.
Tablo `read` yöntem birden çok döndürebilir `IBlockInputStream` nesneleri paralel veri işleme izin vermek için. Bu çoklu blok giriş akışları bir tablodan paralel olarak okuyabilir. Ardından, bu akışları bağımsız olarak hesaplanabilen çeşitli dönüşümlerle (ifade değerlendirme veya filtreleme gibi) sarabilir ve bir `UnionBlockInputStream` bunların üzerine, paralel olarak birden fazla akıştan okumak için.
Ayrıca vardır `TableFunction`s. bunlar geçici olarak dönen işlevlerdir `IStorage` içinde kullanılacak nesne `FROM` bir sorgu yan tümcesi.
Tablo motorunuzu nasıl uygulayacağınıza dair hızlı bir fikir edinmek için, basit bir şeye bakın `StorageMemory` veya `StorageTinyLog`.
> Bu sonucu `read` yöntem, `IStorage` dönüşler `QueryProcessingStage` – information about what parts of the query were already calculated inside storage.
## Ayrıştırıcılar {#parsers}
Elle yazılmış özyinelemeli iniş ayrıştırıcı bir sorgu ayrıştırır. Mesela, `ParserSelectQuery` sorgunun çeşitli bölümleri için temel ayrıştırıcıları yinelemeli olarak çağırır. Ayrıştırıcılar bir `AST`. Bu `AST` örnekleri olan düğüm bylerle temsil edilir `IAST`.
> Ayrıştırıcı jeneratörler tarihsel nedenlerle kullanılmaz.
## Tercümanlar {#interpreters}
Sorgu yürütme kanalının oluşturulmasından tercümanlar sorumludur. `AST`. Gibi basit tercümanlar vardır `InterpreterExistsQuery` ve `InterpreterDropQuery` veya daha sofistike `InterpreterSelectQuery`. Sorgu yürütme boru hattı, blok giriş veya çıkış akışlarının birleşimidir. Örneğin, yorumlama sonucu `SELECT` sorgu olduğunu `IBlockInputStream` sonuç kümesini okumak için; INSERT sorgusunun sonucu `IBlockOutputStream` ekleme için veri yazmak ve yorumlama sonucu `INSERT SELECT` sorgu olduğunu `IBlockInputStream` bu, ilk okumada boş bir sonuç kümesi döndürür, ancak verileri kopyalar `SELECT` -e doğru `INSERT` aynı zamanda.
`InterpreterSelectQuery` kullanma `ExpressionAnalyzer` ve `ExpressionActions` sorgu analizi ve dönüşümler için makine. Bu, kural tabanlı sorgu iyileştirmelerinin çoğunun yapıldığı yerdir. `ExpressionAnalyzer` oldukça dağınık ve yeniden yazılmalıdır: modüler dönüşümlere veya sorguya izin vermek için ayrı sınıflara çeşitli sorgu dönüşümleri ve optimizasyonlar çıkarılmalıdır.
## İşlevler {#functions}
Sıradan fonksiyonlar ve toplam fonksiyonlar vardır. Toplama işlevleri için bir sonraki bölüme bakın.
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 vectorized sorgu yürütme uygulamak için veri.
Gibi bazı çeşitli fonksiyonlar vardır [blockSize](../sql_reference/functions/other_functions.md#function-blocksize), [rowNumberİnBlock](../sql_reference/functions/other_functions.md#function-rownumberinblock), ve [runningAccumulate](../sql_reference/functions/other_functions.md#function-runningaccumulate), blok işlemeyi istismar eden ve satırların bağımsızlığını ihlal eden.
Clickhouse'un güçlü yazımı var, bu yüzden örtük tür dönüşümü yok. Bir işlev belirli bir tür kombinasyonunu desteklemiyorsa, bir istisna atar. Ancak, birçok farklı tür kombinasyonu için işlevler çalışabilir (aşırı yüklenebilir). Örneğin, `plus` fonksiyonu (uygulamak için `+` operatör) sayısal türlerin herhangi bir kombinasyonu için çalışır: `UInt8` + `Float32`, `UInt16` + `Int8` ve bu yüzden. Ayrıca, bazı variadic işlevleri gibi bağımsız değişkenlerin herhangi bir sayıda kabul edebilir `concat` işlev.
Bir işlev açıkça desteklenen veri türlerini gönderir ve desteklenen çünkü bir işlev uygulamak biraz rahatsız edici olabilir `IColumns`. Örneğin, `plus` işlev, sayısal türlerin ve sabit veya sabit olmayan sol ve sağ bağımsız değişkenlerin her birleşimi için bir C++ şablonunun örneklendirilmesiyle oluşturulan koda sahiptir.
Bu şablon kodu kabartmak önlemek için çalışma zamanı kodu nesil uygulamak için mükemmel bir yerdir. Ayrıca, kaynaşmış çarpma-ekleme gibi kaynaşmış işlevler eklemeyi veya bir döngü yinelemesinde birden fazla karşılaştırma yapmayı mümkün kılar.
Vektörize sorgu yürütme nedeniyle, işlevler kısa devre değildir. Örneğin, yazarsanız `WHERE f(x) AND g(y)`, her iki taraf da satırlar için bile hesaplanır `f(x)` sıfırdır (hariç `f(x)` sıfır sabit bir ifadedir). Ama eğer seçicilik `f(x)` durum yüksek ve hesaplama `f(x)` çok daha ucuzdur `g(y)`, çok geçişli hesaplama uygulamak daha iyidir. İlk önce hesaplayacaktı `f(x)`, daha sonra sonucu sütunları süzün ve sonra hesaplayın `g(y)` sadece daha küçük, filtrelenmiş veri parçaları için.
## Toplama Fonksiyonları {#aggregate-functions}
Toplama işlevleri durumsal işlevlerdir. Geçirilen değerleri bir duruma biriktirir ve bu durumdan sonuç almanıza izin verir. İle Yönet theyil theirler. `IAggregateFunction` Arabirim. Devletler oldukça basit olabilir (devlet `AggregateFunctionCount` sadece bir tek `UInt64` değeri) veya oldukça karmaşık (devlet `AggregateFunctionUniqCombined` doğrusal bir dizi, bir karma tablo ve bir kombinasyonudur `HyperLogLog` olasılıksal veri yapısı).
Devletler tahsis edilir `Arena` (bir bellek havuzu) yüksek önemlilik yürütürken birden çok durumla başa çıkmak için `GROUP BY` sorgu. Devletler önemsiz olmayan bir yapıcı ve yıkıcı olabilir: örneğin, karmaşık toplama durumları ek belleği kendileri tahsis edebilir. Devletlerin yaratılmasına ve yok edilmesine ve mülkiyet ve yıkım düzeninin doğru bir şekilde geçmesine biraz dikkat gerektirir.
Toplama durumları serileştirilmiş ve dağıtılmış sorgu yürütme sırasında ağ üzerinden geçmek veya bunları yeterli RAM olmadığı diskte yazmak için serileştirilmiş. Hatta bir tablo ile saklanabilir `DataTypeAggregateFunction` verilerin artımlı toplanmasına izin vermek için.
> Toplu işlev durumları için seri hale getirilmiş veri biçimi şu anda sürümlendirilmemiş. Toplama durumları yalnızca geçici olarak saklanırsa sorun olmaz. Ama biz var `AggregatingMergeTree` artan toplama için tablo motoru ve insanlar zaten üretimde kullanıyor. Gelecekte herhangi bir toplama işlevi için seri hale getirilmiş biçimi değiştirirken geriye dönük uyumluluğun gerekli olmasının nedeni budur.
## Hizmetçi {#server}
Sunucu birkaç farklı arayüz uygular:
- Herhangi bir yabancı istemciler için bir HTTP arabirimi.
- Dağıtılmış sorgu yürütme sırasında yerel ClickHouse istemcisi ve sunucular arası iletişim için bir TCP arabirimi.
- Çoğaltma için veri aktarımı için bir arabirim.
DAHİLİ olarak, coroutines veya lifler olmadan sadece ilkel bir çok iş parçacıklı sunucudur. Sunucu, yüksek oranda basit sorguları işlemek için değil, nispeten düşük oranda karmaşık sorguları işlemek için tasarlandığından, her biri analitik için çok miktarda veri işleyebilir.
Sunucu başlatır `Context` sorgu yürütme için gerekli ortama sahip sınıf: kullanılabilir veritabanlarının, kullanıcıların ve erişim haklarının, ayarların, kümelerin, işlem listesinin, sorgu günlüğünün vb. listesi. Tercümanlar bu ortamı kullanır.
Sunucu TCP protokolü için tam geriye ve ileriye dönük uyumluluk sağlıyoruz: eski istemciler yeni sunucularla konuşabilir ve yeni istemciler eski sunucularla konuşabilir. Ancak sonsuza dek korumak istemiyoruz ve yaklaşık bir yıl sonra eski sürümler için destek kaldırıyoruz.
!!! note "Not"
Çoğu harici uygulama için, HTTP arayüzünü kullanmanızı öneririz, çünkü basit ve kullanımı kolaydır. TCP protokolü, iç veri yapılarına daha sıkı bir şekilde bağlanır: veri bloklarını geçirmek için bir iç biçim kullanır ve sıkıştırılmış veriler için özel çerçeveleme kullanır. Bu protokol için bir C kütüphanesi yayınlamadık çünkü pratik olmayan ClickHouse kod tabanının çoğunu bağlamayı gerektiriyor.
## Dağıtılmış Sorgu Yürütme {#distributed-query-execution}
Bir küme kurulumundaki sunucular çoğunlukla bağımsızdır. Sen-ebilmek yaratmak a `Distributed` bir kümedeki bir veya tüm sunucularda tablo. Bu `Distributed` table does not store data itself – it only provides a “view” Bir kümenin birden çok düğümündeki tüm yerel tablolara. Bir seçtiğinizde `Distributed` tablo, bu sorguyu yeniden yazar, Yük Dengeleme ayarlarına göre uzak düğümleri seçer ve sorguyu onlara gönderir. Bu `Distributed` tablo, farklı sunuculardan gelen Ara sonuçların birleştirilebileceği bir aşamaya kadar bir sorguyu işlemek için uzak sunuculardan ister. Sonra Ara sonuçları alır ve onları birleştirir. Dağıtılmış tablo, uzak sunuculara mümkün olduğunca fazla çalışma dağıtmaya çalışır ve ağ üzerinden çok fazla ara veri göndermez.
In veya JOIN yan tümcelerinde alt sorgular olduğunda işler daha karmaşık hale gelir ve her biri bir `Distributed` Tablo. Bu sorguların yürütülmesi için farklı stratejilerimiz var.
Dağıtılmış sorgu yürütme için genel bir sorgu planı yoktur. Her düğüm, işin kendi kısmı için yerel sorgu planına sahiptir. Biz sadece basit tek geçişli dağıtılmış sorgu yürütme var: biz uzak düğümler için sorgular göndermek ve sonra sonuçları birleştirmek. Ancak bu, yüksek önemlilik grubu BYs ile veya JOIN için büyük miktarda geçici veri içeren karmaşık sorgular için mümkün değildir. Bu gibi durumlarda, gerek “reshuffle” ek koordinasyon gerektiren sunucular arasındaki veriler. ClickHouse bu tür bir sorgu yürütülmesini desteklemiyor ve üzerinde çalışmamız gerekiyor.
## Ağaç Birleştirme {#merge-tree}
`MergeTree` birincil anahtarla dizin oluşturmayı destekleyen bir depolama altyapısı ailesidir. Birincil anahtar, isteğe bağlı bir sütun veya ifade kümesi olabilir. Veri `MergeTree` tablo saklanır “parts”. Her bölüm verileri birincil anahtar sırasına göre saklar, böylece veriler birincil anahtar tuple tarafından lexicographically sıralanır. Tüm tablo sütunları ayrı olarak saklanır `column.bin` bu kısımlardaki dosyalar. Dosyalar sıkıştırılmış bloklardan oluşur. Her blok, ortalama değer boyutuna bağlı olarak genellikle 64 KB ila 1 MB sıkıştırılmamış veridir. Bloklar, birbiri ardına bitişik olarak yerleştirilmiş sütun değerlerinden oluşur. Sütun değerleri her sütun için aynı sıradadır (birincil anahtar siparişi tanımlar), bu nedenle birçok sütun tarafından yineleme yaptığınızda, karşılık gelen satırlar için değerler alırsınız.
Birincil anahtarın kendisi “sparse”. Her satır Adres yok ama verilerin sadece biraz değişir. Ayıran `primary.idx` dosya, n'nin çağrıldığı her N-inci satır için birincil anahtarın değerine sahiptir `index_granularity` (genellikle, n = 8192). Ayrıca, her sütun için, biz var `column.mrk` dosyaları ile “marks,” veri dosyasındaki her N-inci satıra ofset olan. Her işaret bir çifttir: dosyadaki ofset sıkıştırılmış bloğun başlangıcına ve sıkıştırılmış bloktaki ofset verilerin başlangıcına. Genellikle, sıkıştırılmış bloklar işaretlerle hizalanır ve sıkıştırılmış bloktaki ofset sıfırdır. İçin veri `primary.idx` her zaman bellekte bulunur ve veri `column.mrk` dosyalar önbelleğe alınır.
Bir kısm aından bir şey okuy readacağımız zaman `MergeTree` bak biz `primary.idx` veri ve istenen verileri içerebilecek aralıkları bulun, ardından `column.mrk` veri ve bu aralıkları okumaya başlamak için nerede için uzaklıklar hesaplayın. Çünkü seyrek, fazla veri okunabilir. ClickHouse, basit nokta sorgularının yüksek bir yükü için uygun değildir, çünkü tüm Aralık `index_granularity` her anahtar için satırlar okunmalı ve her sütun için sıkıştırılmış bloğun tamamı sıkıştırılmalıdır. Dizin için fark edilebilir bellek tüketimi olmadan tek bir sunucu başına trilyonlarca satır tutabilmemiz gerektiğinden dizini seyrek yaptık. Ayrıca, birincil anahtar seyrek olduğundan, benzersiz değildir: ekleme zamanında tablodaki anahtarın varlığını denetleyemez. Bir tabloda aynı anahtara sahip birçok satır olabilir.
Ne zaman sen `INSERT` içine veri bir demet `MergeTree`, bu grup birincil anahtar sırasına göre sıralanır ve yeni bir bölüm oluşturur. Bazı parçaları periyodik olarak seçen ve parça sayısını nispeten düşük tutmak için bunları tek bir sıralanmış parçaya birleştiren arka plan iş parçacıkları vardır. Bu yüzden denir `MergeTree`. Tabii ki, birleştirme yol açar “write amplification”. Tüm parçalar değişmez: sadece oluşturulur ve silinir, ancak değiştirilmez. SELECT yürütüldüğünde, tablonun bir anlık görüntüsünü (bir parça kümesi) tutar. Birleştirildikten sonra, arızadan sonra iyileşmeyi kolaylaştırmak için eski parçaları bir süre tutuyoruz, bu nedenle birleştirilmiş bir parçanın muhtemelen kırıldığını görürsek, kaynak parçalarıyla değiştirebiliriz.
`MergeTree` içermediği için bir lsm ağacı değildir “memtable” ve “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 tabloları yalnızca bir (birincil) dizine sahip olabilir: herhangi bir ikincil dizin yoktur. Bir mantıksal tablo altında birden fazla fiziksel gösterime izin vermek, örneğin verileri birden fazla fiziksel sırayla depolamak veya hatta orijinal verilerle birlikte önceden toplanmış verilerle gösterimlere izin vermek güzel olurdu.
Arka plan birleştirmeleri sırasında ek iş yapan MergeTree motorları vardır. Örnekler şunlardır `CollapsingMergeTree` ve `AggregatingMergeTree`. Bu, güncellemeler için özel destek olarak kabul edilebilir. Kullanıcıların genellikle arka plan birleştirmeleri yürütüldüğünde zaman üzerinde hiçbir kontrole sahip çünkü bu gerçek güncellemeler olmadığını unutmayın, ve bir veri `MergeTree` tablo hemen hemen her zaman tamamen birleştirilmiş formda değil, birden fazla bölümde saklanır.
## Çoğalma {#replication}
Clickhouse çoğaltma başına tablo bazında yapılandırılabilir. Aynı sunucuda bazı çoğaltılmış ve bazı çoğaltılmamış tablolar olabilir. Ayrıca, iki faktörlü çoğaltmaya sahip bir tablo ve üç faktörlü bir tablo gibi farklı şekillerde çoğaltılmış tablolar da olabilir.
Çoğaltma uygulanır `ReplicatedMergeTree` depolama motoru. The path in `ZooKeeper` depolama altyapısı için bir parametre olarak belirtilir. Aynı yolu olan tüm tablolar `ZooKeeper` birbirlerinin kopyaları haline gelir: verilerini senkronize eder ve tutarlılığı korurlar. Yinelemeler, bir tablo oluşturarak veya bırakarak dinamik olarak eklenebilir ve kaldırılabilir.
Çoğaltma, zaman uyumsuz bir çoklu ana düzeni kullanır. Bir oturum olan herhangi bir yinelemeye veri ekleyebilirsiniz. `ZooKeeper` ve veriler diğer tüm yinelemelere zaman uyumsuz olarak çoğaltılır. ClickHouse güncelleştirmeleri desteklemediğinden, çoğaltma çakışmaz. Eklerin çekirdek onayı olmadığından, bir düğüm başarısız olursa, yalnızca eklenen veriler kaybolabilir.
Çoğaltma için meta veri zookeeper saklanır. Hangi eylemlerin yapılacağını listeleyen bir çoğaltma günlüğü vardır. Eylemler şunlardır: parça al; parçaları Birleştir; bir bölüm bırak vb. Her çoğaltma, çoğaltma günlüğünü kendi kuyruğuna kopyalar ve sonra da sıradaki eylemleri yürütür. Örneğin, ekleme, “get the part” eylem günlüğüne oluşturulur ve her çoğaltma bu bölümü indirir. Birleştirmeler, baytla aynı sonuçları elde etmek için yinelemeler arasında koordine edilir. Tüm parçalar tüm kopyalarda aynı şekilde birleştirilir. Bir kopyayı lider olarak seçerek elde edilir ve bu çoğaltma birleştirir ve yazar “merge parts” günlük eylemler.
Çoğaltma fiziksel: yalnızca sıkıştırılmış parçalar sorgular değil düğümler arasında aktarılır. Birleştirmeler, çoğu durumda ağ amplifikasyonundan kaçınarak ağ maliyetlerini düşürmek için her yinelemede bağımsız olarak işlenir. Büyük birleştirilmiş parçalar, yalnızca önemli çoğaltma gecikmesi durumunda ağ üzerinden gönderilir.
Ayrıca, her bir kopya, ZooKeeper içindeki durumunu parça seti ve sağlama toplamı olarak depolar. Yerel dosya sistemindeki durum ZooKeeper referans durumundan ayrıldığında, kopya diğer kopyalardan eksik ve bozuk parçaları indirerek tutarlılığını geri yükler. Yerel dosya sisteminde beklenmeyen veya bozuk bazı veriler olduğunda, ClickHouse onu kaldırmaz, ancak ayrı bir dizine taşır ve unutur.
!!! note "Not"
ClickHouse kümesi bağımsız parçalardan oluşur ve her parça kopyalardan oluşur. Küme **elastik değil**, böylece yeni bir parça ekledikten sonra, veriler otomatik olarak kırıklar arasında yeniden dengelenmez. Bunun yerine, küme yükünün eşit olmayan şekilde ayarlanması gerekiyor. Bu uygulama size daha fazla kontrol sağlar ve onlarca düğüm gibi nispeten küçük kümeler için uygundur. Ancak üretimde kullandığımız yüzlerce düğüm içeren kümeler için bu yaklaşım önemli bir dezavantaj haline gelir. Kümeler arasında otomatik olarak bölünebilen ve dengelenebilen dinamik olarak çoğaltılmış bölgelerle kümeye yayılan bir tablo altyapısı uygulamalıyız.
{## [Orijinal makale](https://clickhouse.tech/docs/en/development/architecture/) ##}

14
docs/tr/development/browse_code.md Normal file
View File

@ -0,0 +1,14 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 63
toc_title: "ClickHouse Kaynak Koduna G\xF6z At\u0131n"
---
# ClickHouse Kaynak Koduna Göz Atın {#browse-clickhouse-source-code}
Kullanabilirsiniz **Woboq** online kod tarayıcı mevcut [burada](https://clickhouse.tech/codebrowser/html_report///ClickHouse/src/index.html). Bu kod navigasyon ve semantik vurgulama, arama ve indeksleme sağlar. Kod anlık görüntüsü günlük olarak güncellenir.
Ayrıca, kaynaklara göz atabilirsiniz [GitHub](https://github.com/ClickHouse/ClickHouse) herzamanki.
IDE'NİN ne kullanacağı ile ilgileniyorsanız, CLion, QT Creator, vs Code ve KDevelop (uyarılar ile) öneririz. Herhangi bir favori IDE kullanabilirsiniz. Vim ve Emacs da sayılır.

141
docs/tr/development/build.md Normal file
View File

@ -0,0 +1,141 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 64
toc_title: "Linux \xFCzerinde ClickHouse nas\u0131l olu\u015Fturulur"
---
# Geliştirme için ClickHouse nasıl inşa edilir {#how-to-build-clickhouse-for-development}
Aşağıdaki öğretici Ubuntu Linux sistemine dayanmaktadır.
Uygun değişikliklerle, başka herhangi bir Linux dağıtımı üzerinde de çalışması gerekir.
Desteklenen platformlar: x86\_64 ve AArch64. Power9 için destek deneyseldir.
## Git, Cmake, Python ve Ninja'yı yükleyin {#install-git-cmake-python-and-ninja}
``` bash
$ sudo apt-get install git cmake python ninja-build
```
Veya eski sistemlerde cmake yerine cmake3.
## Gcc 9'u yükle {#install-gcc-9}
Bunu yapmak için çeşitli yollar vardır.
### Bir PPA paketinden yükleme {#install-from-a-ppa-package}
``` bash
$ sudo apt-get install software-properties-common
$ sudo apt-add-repository ppa:ubuntu-toolchain-r/test
$ sudo apt-get update
$ sudo apt-get install gcc-9 g++-9
```
### Kaynaklardan yükleyin {#install-from-sources}
Bakmak [utils/ci/build-gcc-from-sources.sh](https://github.com/ClickHouse/ClickHouse/blob/master/utils/ci/build-gcc-from-sources.sh)
## Yapılar için GCC 9 kullanın {#use-gcc-9-for-builds}
``` bash
$ export CC=gcc-9
$ export CXX=g++-9
```
## Checkout ClickHouse Kaynakları {#checkout-clickhouse-sources}
``` bash
$ git clone --recursive git@github.com:ClickHouse/ClickHouse.git
```
veya
``` bash
$ git clone --recursive https://github.com/ClickHouse/ClickHouse.git
```
## ClickHouse İnşa {#build-clickhouse}
``` bash
$ cd ClickHouse
$ mkdir build
$ cd build
$ cmake ..
$ ninja
$ cd ..
```
Bir yürütülebilir dosya oluşturmak için çalıştırın `ninja clickhouse`.
Bu yaratacak `programs/clickhouse` ile kullanılabilecek çalıştırılabilir `client` veya `server` değişkenler.
# Herhangi bir Linux üzerinde ClickHouse nasıl oluşturulur {#how-to-build-clickhouse-on-any-linux}
Yapı aşağıdaki bileşenleri gerektirir:
- Git (yalnızca kaynakları kontrol etmek için kullanılır, yapı için gerekli değildir)
- Cmake 3.10 veya daha yeni
- Ninja (önerilir) veya yapmak
- C ++ derleyici: gcc 9 veya clang 8 veya daha yeni
- Linker :lld veya altın (klasik GNU ld çalışmaz)
- Python (sadece LLVM yapısında kullanılır ve isteğe bağlıdır)
Tüm bileşenler yüklüyse, yukarıdaki adımlarla aynı şekilde oluşturabilirsiniz.
Ubuntu Eoan için örnek:
sudo apt update
sudo apt install git cmake ninja-build g++ python
git clone --recursive https://github.com/ClickHouse/ClickHouse.git
mkdir build && cd build
cmake ../ClickHouse
ninja
OpenSUSE Tumbleweed için örnek:
sudo zypper install git cmake ninja gcc-c++ python lld
git clone --recursive https://github.com/ClickHouse/ClickHouse.git
mkdir build && cd build
cmake ../ClickHouse
ninja
Fedora Rawhide için örnek:
sudo yum update
yum --nogpg install git cmake make gcc-c++ python2
git clone --recursive https://github.com/ClickHouse/ClickHouse.git
mkdir build && cd build
cmake ../ClickHouse
make -j $(nproc)
# ClickHouse inşa etmek zorunda değilsiniz {#you-dont-have-to-build-clickhouse}
ClickHouse önceden oluşturulmuş ikili ve paketlerde mevcuttur. İkili dosyalar taşınabilir ve herhangi bir Linux lezzet üzerinde çalıştırılabilir.
Onlar sürece her Master taahhüt ve her çekme isteği için kararlı, prestable ve test bültenleri için inşa edilmiştir.
En taze yapıyı bulmak için `master`, go to [taahhüt sayfası](https://github.com/ClickHouse/ClickHouse/commits/master), commit yakınındaki ilk yeşil onay işaretini veya kırmızı çarpı işaretini tıklayın ve “Details” hemen sonra bağlantı “ClickHouse Build Check”.
# ClickHouse Debian paketi nasıl oluşturulur {#how-to-build-clickhouse-debian-package}
## Git ve Pbuilder'ı yükleyin {#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 Kaynakları {#checkout-clickhouse-sources-1}
``` bash
$ git clone --recursive --branch master https://github.com/ClickHouse/ClickHouse.git
$ cd ClickHouse
```
## Run Release Script {#run-release-script}
``` bash
$ ./release
```
[Orijinal makale](https://clickhouse.tech/docs/en/development/build/) <!--hide-->

43
docs/tr/development/build_cross_arm.md Normal file
View File

@ -0,0 +1,43 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 67
toc_title: "AARCH64 (ARM64) i\xE7in Linux'ta ClickHouse nas\u0131l olu\u015Fturulur)"
---
# AARCH64 (ARM64) mimarisi için Linux'ta ClickHouse nasıl oluşturulur {#how-to-build-clickhouse-on-linux-for-aarch64-arm64-architecture}
Bu, Linux makineniz olduğunda ve onu oluşturmak için kullanmak istediğinizde geçerlidir `clickhouse` AARCH64 CPU mimarisi ile başka bir Linux makinede çalışacak ikili. Bu, Linux sunucularında çalışan sürekli entegrasyon kontrolleri için tasarlanmıştır.
AARCH64 için çapraz yapı, [Inşa talimatları](build.md) önce onları takip et.
# Clang-8'i Yükle {#install-clang-8}
Yönergeleri izleyin https://apt.llvm.org / Ubuntu veya Debian kurulumunuz için.
Örneğin, Ubuntu Bionic'te aşağıdaki komutları kullanabilirsiniz:
``` bash
echo "deb [trusted=yes] http://apt.llvm.org/bionic/ llvm-toolchain-bionic-8 main" | sudo tee /etc/apt/sources.list.d/llvm.list
sudo apt-get update
sudo apt-get install clang-8
```
# Çapraz Derleme Araç Setini Yükle {#install-cross-compilation-toolset}
``` bash
cd ClickHouse
mkdir -p build-aarch64/cmake/toolchain/linux-aarch64
wget 'https://developer.arm.com/-/media/Files/downloads/gnu-a/8.3-2019.03/binrel/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu.tar.xz?revision=2e88a73f-d233-4f96-b1f4-d8b36e9bb0b9&la=en' -O gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu.tar.xz
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
```
# ClickHouse İnşa {#build-clickhouse}
``` bash
cd ClickHouse
mkdir build-arm64
CC=clang-8 CXX=clang++-8 cmake . -Bbuild-arm64 -DCMAKE_TOOLCHAIN_FILE=cmake/linux/toolchain-aarch64.cmake
ninja -C build-arm64
```
Ortaya çıkan ikili, yalnızca AARCH64 CPU mimarisi ile Linux'ta çalışacaktır.

64
docs/tr/development/build_cross_osx.md Normal file
View File

@ -0,0 +1,64 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 66
toc_title: "Mac OS X i\xE7in Linux'ta ClickHouse nas\u0131l olu\u015Fturulur"
---
# Mac OS X için Linux'ta ClickHouse nasıl oluşturulur {#how-to-build-clickhouse-on-linux-for-mac-os-x}
Bu, Linux makineniz olduğunda ve onu oluşturmak için kullanmak istediğinizde geçerlidir `clickhouse` OS X üzerinde çalışacak ikili. bu, Linux sunucularında çalışan sürekli entegrasyon kontrolleri için tasarlanmıştır. Clickhouse'u doğrudan Mac OS X'te oluşturmak istiyorsanız, devam edin [başka bir talimat](build_osx.md).
Mac OS X için çapraz yapı, [Inşa talimatları](build.md) önce onları takip et.
# Clang-8'i Yükle {#install-clang-8}
Yönergeleri izleyin https://apt.llvm.org / Ubuntu veya Debian kurulumunuz için.
Örneğin biyonik için komutlar gibidir:
``` 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
```
# Çapraz Derleme Araç Setini Yükle {#install-cross-compilation-toolset}
Yüklediğimiz yolu hatırlayalım `cctools` olarak $ {CCTOOLS}
``` bash
mkdir ${CCTOOLS}
git clone https://github.com/tpoechtrager/apple-libtapi.git
cd apple-libtapi
INSTALLPREFIX=${CCTOOLS} ./build.sh
./install.sh
cd ..
git clone https://github.com/tpoechtrager/cctools-port.git
cd cctools-port/cctools
./configure --prefix=${CCTOOLS} --with-libtapi=${CCTOOLS} --target=x86_64-apple-darwin
make install
```
Ayrıca, MacOS X SDK'YI çalışma ağacına indirmemiz gerekiyor.
``` bash
cd ClickHouse
wget 'https://github.com/phracker/MacOSX-SDKs/releases/download/10.14-beta4/MacOSX10.14.sdk.tar.xz'
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
```
# ClickHouse İnşa {#build-clickhouse}
``` bash
cd ClickHouse
mkdir build-osx
CC=clang-8 CXX=clang++-8 cmake . -Bbuild-osx -DCMAKE_TOOLCHAIN_FILE=cmake/darwin/toolchain-x86_64.cmake \
-DCMAKE_AR:FILEPATH=${CCTOOLS}/bin/x86_64-apple-darwin-ar \
-DCMAKE_RANLIB:FILEPATH=${CCTOOLS}/bin/x86_64-apple-darwin-ranlib \
-DLINKER_NAME=${CCTOOLS}/bin/x86_64-apple-darwin-ld
ninja -C build-osx
```
Ortaya çıkan ikili bir Mach-O yürütülebilir biçimine sahip olacak ve Linux üzerinde çalıştırılamaz.

93
docs/tr/development/build_osx.md Normal file
View File

@ -0,0 +1,93 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 65
toc_title: "Mac OS X \xFCzerinde ClickHouse nas\u0131l olu\u015Fturulur"
---
# Mac OS X üzerinde ClickHouse nasıl oluşturulur {#how-to-build-clickhouse-on-mac-os-x}
Build Mac OS X 10.15 (Catalina) üzerinde çalışmalıdır)
## Homebrew Yüklemek {#install-homebrew}
``` bash
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
```
## Gerekli derleyicileri, araçları ve kitaplıkları yükleyin {#install-required-compilers-tools-and-libraries}
``` bash
$ brew install cmake ninja libtool gettext
```
## Checkout ClickHouse Kaynakları {#checkout-clickhouse-sources}
``` bash
$ git clone --recursive git@github.com:ClickHouse/ClickHouse.git
```
veya
``` bash
$ git clone --recursive https://github.com/ClickHouse/ClickHouse.git
$ cd ClickHouse
```
## ClickHouse İnşa {#build-clickhouse}
``` bash
$ mkdir build
$ cd build
$ cmake .. -DCMAKE_CXX_COMPILER=`which clang++` -DCMAKE_C_COMPILER=`which clang`
$ ninja
$ cd ..
```
## Uyarılar {#caveats}
Clickhouse-server çalıştırmak istiyorsanız, sistemin maxfiles değişken artırmak için emin olun.
!!! info "Not"
Sudo kullanmanız gerekecek.
Bunu yapmak için aşağıdaki dosyayı oluşturun:
/ Kütüphane / LaunchDaemons / sınırı.maxfiles.plist:
``` xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>limit.maxfiles</string>
<key>ProgramArguments</key>
<array>
<string>launchctl</string>
<string>limit</string>
<string>maxfiles</string>
<string>524288</string>
<string>524288</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>ServiceIPC</key>
<false/>
</dict>
</plist>
```
Aşağıdaki komutu çalıştırın:
``` bash
$ sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist
```
Başlatmak.
Çalışıp çalışmadığını kontrol etmek için şunları kullanabilirsiniz `ulimit -n` komut.
[Orijinal makale](https://clickhouse.tech/docs/en/development/build_osx/) <!--hide-->

42
docs/tr/development/contrib.md Normal file
View File

@ -0,0 +1,42 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 70
toc_title: "Kullan\u0131lan \xDC\xE7\xFCnc\xFC Taraf K\xFCt\xFCphaneleri"
---
# Kullanılan Üçüncü Taraf Kütüphaneleri {#third-party-libraries-used}
| Kitaplık | Lisans |
|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------|
| base64 | [BSD 2-Clause Lisansı](https://github.com/aklomp/base64/blob/a27c565d1b6c676beaf297fe503c4518185666f7/LICENSE) |
| artırmak | [Bo Boostost Software Lic 1.0ense 1.0](https://github.com/ClickHouse-Extras/boost-extra/blob/6883b40449f378019aec792f9983ce3afc7ff16e/LICENSE_1_0.txt) |
| brotli | [MIT](https://github.com/google/brotli/blob/master/LICENSE) |
| capnproto | [MIT](https://github.com/capnproto/capnproto/blob/master/LICENSE) |
| cctz | [Apache Lic 2.0ense 2.0](https://github.com/google/cctz/blob/4f9776a310f4952454636363def82c2bf6641d5f/LICENSE.txt) |
| çift dönüşüm | [BSD 3-Clause Lisansı](https://github.com/google/double-conversion/blob/cf2f0f3d547dc73b4612028a155b80536902ba02/LICENSE) |
| FastMemcpy | [MIT](https://github.com/ClickHouse/ClickHouse/blob/master/libs/libmemcpy/impl/LICENSE) |
| googletest | [BSD 3-Clause Lisansı](https://github.com/google/googletest/blob/master/LICENSE) |
| h33 | [Apache Lic 2.0ense 2.0](https://github.com/uber/h3/blob/master/LICENSE) |
| hyperscan | [BSD 3-Clause Lisansı](https://github.com/intel/hyperscan/blob/master/LICENSE) |
| libbtrie | [BSD 2-Clause Lisansı](https://github.com/ClickHouse/ClickHouse/blob/master/contrib/libbtrie/LICENSE) |
| libcxxabi | [BSD + MIT](https://github.com/ClickHouse/ClickHouse/blob/master/libs/libglibc-compatibility/libcxxabi/LICENSE.TXT) |
| libdivide | [Zlib Lisansı](https://github.com/ClickHouse/ClickHouse/blob/master/contrib/libdivide/LICENSE.txt) |
| libgsasl | [LGPL v2. 1](https://github.com/ClickHouse-Extras/libgsasl/blob/3b8948a4042e34fb00b4fb987535dc9e02e39040/LICENSE) |
| libhdfs3 | [Apache Lic 2.0ense 2.0](https://github.com/ClickHouse-Extras/libhdfs3/blob/bd6505cbb0c130b0db695305b9a38546fa880e5a/LICENSE.txt) |
| libmetrohash | [Apache Lic 2.0ense 2.0](https://github.com/ClickHouse/ClickHouse/blob/master/contrib/libmetrohash/LICENSE) |
| libpcg-rastgele | [Apache Lic 2.0ense 2.0](https://github.com/ClickHouse/ClickHouse/blob/master/contrib/libpcg-random/LICENSE-APACHE.txt) |
| libressl | [OpenSSL Lisansı](https://github.com/ClickHouse-Extras/ssl/blob/master/COPYING) |
| librdkafka | [BSD 2-Clause Lisansı](https://github.com/edenhill/librdkafka/blob/363dcad5a23dc29381cc626620e68ae418b3af19/LICENSE) |
| libwidechar\_width | [CC0 1.0 Evrensel](https://github.com/ClickHouse/ClickHouse/blob/master/libs/libwidechar_width/LICENSE) |
| llvm | [BSD 3-Clause Lisansı](https://github.com/ClickHouse-Extras/llvm/blob/163def217817c90fb982a6daf384744d8472b92b/llvm/LICENSE.TXT) |
| lz4 | [BSD 2-Clause Lisansı](https://github.com/lz4/lz4/blob/c10863b98e1503af90616ae99725ecd120265dfb/LICENSE) |
| mariadb-bağlayıcı-c | [LGPL v2. 1](https://github.com/ClickHouse-Extras/mariadb-connector-c/blob/3.1/COPYING.LIB) |
| murmurhash | [Kamu Malı](https://github.com/ClickHouse/ClickHouse/blob/master/contrib/murmurhash/LICENSE) |
| pdqsort | [Zlib Lisansı](https://github.com/ClickHouse/ClickHouse/blob/master/contrib/pdqsort/license.txt) |
| az | [Boost Yazılım Lisansı-Sürüm 1.0](https://github.com/ClickHouse-Extras/poco/blob/fe5505e56c27b6ecb0dcbc40c49dc2caf4e9637f/LICENSE) |
| protobuf | [BSD 3-Clause Lisansı](https://github.com/ClickHouse-Extras/protobuf/blob/12735370922a35f03999afff478e1c6d7aa917a4/LICENSE) |
| re2 | [BSD 3-Clause Lisansı](https://github.com/google/re2/blob/7cf8b88e8f70f97fd4926b56aa87e7f53b2717e0/LICENSE) |
| UnixODBC | [LGPL v2. 1](https://github.com/ClickHouse-Extras/UnixODBC/tree/b0ad30f7f6289c12b76f04bfb9d466374bb32168) |
| zlib-ng | [Zlib Lisansı](https://github.com/ClickHouse-Extras/zlib-ng/blob/develop/LICENSE.md) |
| zstd | [BSD 3-Clause Lisansı](https://github.com/facebook/zstd/blob/dev/LICENSE) |

285
docs/tr/development/developer_instruction.md Normal file
View File

@ -0,0 +1,285 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 61
toc_title: "Acemi ClickHouse Geli\u015Ftirici Talimat"
---
ClickHouse binası Linux, FreeBSD ve Mac OS X üzerinde desteklenmektedir.
# Windows Kullanıyorsanız {#if-you-use-windows}
Windows kullanıyorsanız, Ubuntu ile bir sanal makine oluşturmanız gerekir. Bir sanal makine ile çalışmaya başlamak için VirtualBox yükleyin. UB :unt :u'yu web sitesinden indirebilirsiniz: https://www.ubuntu.com/\#download. lütfen indirilen görüntüden bir sanal makine oluşturun (bunun için en az 4GB RAM ayırmalısınız). Ubuntu'da bir komut satırı terminali çalıştırmak için lütfen kelimeyi içeren bir program bulun “terminal” adına (gnome-terminal, konsole vb.)) veya sadece Ctrl+Alt+T tuşlarına basın.
# 32 bit sistem kullanıyorsanız {#if-you-use-a-32-bit-system}
ClickHouse çalışamaz veya 32-bit bir sistem üzerinde oluşturun. 64-bit bir sisteme erişim kazanmanız gerekir ve okumaya devam edebilirsiniz.
# Github'da bir depo oluşturma {#creating-a-repository-on-github}
ClickHouse repository ile çalışmaya başlamak için bir GitHub hesabına ihtiyacınız olacaktır.
Muhtemelen zaten bir tane var, ama yapmazsanız, lütfen kayıt olun https://github.com. SSH anahtarlarınız yoksa, bunları üretmeli ve daha sonra Github'a yüklemelisiniz. Bu yamalar üzerinden göndermek için gereklidir. Diğer SSH sunucularıyla kullandığınız aynı SSH anahtarlarını kullanmak da mümkündür - muhtemelen zaten bunlara sahipsiniz.
ClickHouse deposunun bir çatalı oluşturun. Bunu yapmak için lütfen tıklayın “fork” sağ üst köşedeki düğme https://github.com/ClickHouse/ClickHouse. bu hesabınıza ClickHouse / ClickHouse kendi kopyasını çatal olacaktır.
Geliştirme süreci ilk ClickHouse sizin çatal içine amaçlanan değişiklikleri işlemekle ve daha sonra bir oluşturma oluşur “pull request” bu değişikliklerin ana depoya kabul edilmesi için (ClickHouse/ClickHouse).
Git depoları ile çalışmak için lütfen yükleyin `git`.
Bunu Ubuntu'da yapmak için komut satırı terminalinde çalışırsınız:
sudo apt update
sudo apt install git
Git kullanımı ile ilgili kısa bir el kitabı burada bulunabilir: https://services.github.com/on-demand/downloads/github-git-cheat-sheet.pdf.
Git ile ilgili ayrıntılı bir el kitabı için bkz. https://git-scm.com/book/en/v2.
# Geliştirme Makinenize bir depo klonlama {#cloning-a-repository-to-your-development-machine}
Ardından, kaynak dosyaları çalışma makinenize indirmeniz gerekir. Bu denir “to clone a repository” çünkü çalışma makinenizde deponun yerel bir kopyasını oluşturur.
Komut satırında terminal Çalıştır:
git clone --recursive git@guthub.com:your_github_username/ClickHouse.git
cd ClickHouse
Not: lütfen, yerine *your\_github\_username* uygun olanı ile!
Bu komut bir dizin oluşturacaktır `ClickHouse` projenin çalışma kopyasını içeren.
Yapı sistemini çalıştırmakla ilgili sorunlara yol açabileceğinden, çalışma dizininin yolunun hiçbir boşluk içermemesi önemlidir.
ClickHouse deposunun kullandığını lütfen unutmayın `submodules`. That is what the references to additional repositories are called (i.e. external libraries on which the project depends). It means that when cloning the repository you need to specify the `--recursive` yukarıdaki örnekte olduğu gibi bayrak. Depo alt modüller olmadan klonlanmışsa, bunları indirmek için aşağıdakileri çalıştırmanız gerekir:
git submodule init
git submodule update
Komutu ile durumunu kontrol edebilirsiniz: `git submodule status`.
Aşağıdaki hata iletisini alırsanız:
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Genellikle Github'a bağlanmak için SSH anahtarlarının eksik olduğu anlamına gelir. Bu anahtarlar normalde `~/.ssh`. SSH anahtarlarının kabul edilmesi için bunları GitHub kullanıcı arayüzünün ayarlar bölümüne yüklemeniz gerekir.
Depoyu https protokolü aracılığıyla da klonlayabilirsiniz:
git clone https://github.com/ClickHouse/ClickHouse.git
Ancak bu, değişikliklerinizi sunucuya göndermenize izin vermez. Yine de geçici olarak kullanabilir ve SSH anahtarlarını daha sonra deponun uzak adresini değiştirerek ekleyebilirsiniz `git remote` komut.
Oradan güncellemeleri çekmek için orijinal ClickHouse repo'nun adresini yerel deponuza da ekleyebilirsiniz:
git remote add upstream git@github.com:ClickHouse/ClickHouse.git
Başarıyla bu komutu çalıştırdıktan sonra çalıştırarak ana ClickHouse repo güncellemeleri çekmek mümkün olacak `git pull upstream master`.
## Alt modüllerle çalışma {#working-with-submodules}
Git'teki alt modüllerle çalışmak acı verici olabilir. Sonraki komutlar onu yönetmeye yardımcı olacaktır:
# ! each command accepts --recursive
# Update remote URLs for submodules. Barely rare case
git submodule sync
# Add new submodules
git submodule init
# Update existing submodules to the current state
git submodule update
# Two last commands could be merged together
git submodule update --init
Bir sonraki komutlar, tüm alt modülleri başlangıç durumuna sıfırlamanıza yardımcı olacaktır (!UYARI! - herhangi bir değişiklik içinde silinecektir):
# Synchronizes submodules' remote URL with .gitmodules
git submodule sync --recursive
# Update the registered submodules with initialize not yet initialized
git submodule update --init --recursive
# Reset all changes done after HEAD
git submodule foreach git reset --hard
# Clean files from .gitignore
git submodule foreach git clean -xfd
# Repeat last 4 commands for all submodule
git submodule foreach git submodule sync --recursive
git submodule foreach git submodule update --init --recursive
git submodule foreach git submodule foreach git reset --hard
git submodule foreach git submodule foreach git clean -xfd
# Yapı Sistemi {#build-system}
ClickHouse bina için Cmake ve Ninja kullanır.
Cmake-ninja dosyaları (yapı görevleri) üretebilir bir meta-yapı sistemi.
Ninja-bu cmake oluşturulan görevleri yürütmek için kullanılan hıza odaklanarak daha küçük bir yapı sistemi.
Ubuntu, Debian veya Mint run'a yüklemek için `sudo apt install cmake ninja-build`.
Centos'ta, RedHat koşusu `sudo yum install cmake ninja-build`.
Arch veya Gentoo kullanıyorsanız, muhtemelen cmake'i nasıl kuracağınızı kendiniz biliyorsunuz.
Mac OS X üzerinde cmake ve Ninja yüklemek için ilk homebrew yüklemek ve daha sonra demlemek yoluyla her şeyi yüklemek:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install cmake ninja
Ardından, cmake sürümünü kontrol edin: `cmake --version`. 3.3'ün altındaysa, web sitesinden daha yeni bir sürüm yüklemelisiniz: https://cmake.org/download/.
# İsteğe Bağlı Harici Kütüphaneler {#optional-external-libraries}
ClickHouse, bina için birkaç dış kütüphane kullanır. Alt modüllerde bulunan kaynaklardan ClickHouse ile birlikte oluşturuldukları için hepsinin ayrı olarak kurulması gerekmez. Listeyi kontrol edebilirsiniz `contrib`.
# C++ Derleyici {#c-compiler}
Derleyiciler gcc sürüm 9 ve Clang sürüm 8 veya üzeri başlayarak ClickHouse bina için desteklenmektedir.
Resmi Yandex şu anda GCC'Yİ kullanıyor çünkü biraz daha iyi performansa sahip makine kodu üretiyor (kriterlerimize göre yüzde birkaçına kadar bir fark yaratıyor). Ve Clang genellikle geliştirme için daha uygundur. Yine de, sürekli entegrasyon (CI) platformumuz yaklaşık bir düzine yapı kombinasyonunu denetler.
Ubuntu run GCC yüklemek için: `sudo apt install gcc g++`
Gcc sürümünü kontrol edin: `gcc --version`. 9'un altındaysa, buradaki talimatları izleyin: https://clickhouse.tech / docs/TR/development / build / \#ınstall-gcc-9.
Mac OS X build sadece Clang için desteklenir. Sadece koş `brew install llvm`
Eğer Clang kullanmaya karar verirseniz, ayrıca yükleyebilirsiniz `libc++` ve `lld` eğer ne olduğunu biliyorsan. Kullanım `ccache` ayrıca tavsiye edilir.
# İnşaat Süreci {#the-building-process}
Artık ClickHouse oluşturmaya hazır olduğunuza göre ayrı bir dizin oluşturmanızı öneririz `build` için `ClickHouse` bu, tüm yapı eserlerini içerecek:
mkdir build
cd build
Birkaç farklı dizine (build\_release, build\_debug, vb.) sahip olabilirsiniz.) farklı yapı türleri için.
İçinde iken `build` dizin, cmake çalıştırarak yapı yapılandırın. İlk çalıştırmadan önce, derleyici belirten ortam değişkenlerini tanımlamanız gerekir (bu örnekte sürüm 9 gcc derleyicisi).
Linux:
export CC=gcc-9 CXX=g++-9
cmake ..
Mac OS X:
export CC=clang CXX=clang++
cmake ..
Bu `CC` değişken C için derleyiciyi belirtir (C derleyicisi için kısa) ve `CXX` değişken, hangi C++ derleyicisinin bina için kullanılacağını bildirir.
Daha hızlı bir yapı için, `debug` yapı türü-hiçbir optimizasyonları ile bir yapı. Bunun için aşağıdaki parametreyi sağlayın `-D CMAKE_BUILD_TYPE=Debug`:
cmake -D CMAKE_BUILD_TYPE=Debug ..
Bu komutu çalıştırarak yapı türünü değiştirebilirsiniz. `build` dizin.
İnşa etmek için ninja çalıştırın:
ninja clickhouse-server clickhouse-client
Bu örnekte yalnızca gerekli ikili dosyalar oluşturulacaktır.
Tüm ikili dosyaları (Yardımcı Programlar ve testler) oluşturmanız gerekiyorsa, ninja'yı parametre olmadan çalıştırmalısınız:
ninja
Tam yapı, ana ikili dosyaları oluşturmak için yaklaşık 30GB boş disk alanı veya 15GB gerektirir.
Yapı makinesinde büyük miktarda RAM mevcut olduğunda, paralel olarak çalışan yapı görevlerinin sayısını sınırlamanız gerekir `-j` param:
ninja -j 1 clickhouse-server clickhouse-client
4GB RAM'Lİ makinelerde, 8GB RAM için 1 belirtmeniz önerilir `-j 2` tavsiye edilir.
Mesajı alırsanız: `ninja: error: loading 'build.ninja': No such file or directory` bu, bir yapı yapılandırması oluşturmanın başarısız olduğu ve yukarıdaki mesajı incelemeniz gerektiği anlamına gelir.
Bina işleminin başarılı bir şekilde başlatılmasının ardından, yapı ilerlemesini görürsünüz-işlenmiş görevlerin sayısı ve toplam görev sayısı.
Libhdfs2 kütüphanesinde protobuf dosyaları hakkında mesajlar oluştururken `libprotobuf WARNING` ortaya çıkabilir. Hiçbir şeyi etkilemezler ve göz ardı edilmeleri güvenlidir.
Başarılı bir yapı üzerine yürütülebilir bir dosya alırsınız `ClickHouse/<build_dir>/programs/clickhouse`:
ls -l programs/clickhouse
# Clickhouse'un yerleşik yürütülebilir dosyasını çalıştırma {#running-the-built-executable-of-clickhouse}
Sunucuyu geçerli kullanıcı altında çalıştırmak için aşağıdakilere gitmeniz gerekir `ClickHouse/programs/server/` (dışında bulunan `build`) ve koş:
../../../build/programs/clickhouse server
Bu durumda, ClickHouse geçerli dizinde bulunan yapılandırma dosyalarını kullanır. Koş youabilirsiniz `clickhouse server` komut satırı parametresi olarak bir yapılandırma dosyasının yolunu belirten herhangi bir dizinden `--config-file`.
Başka bir terminalde clickhouse-client ile Clickhouse'a bağlanmak için `ClickHouse/build/programs/` ve koş `clickhouse client`.
Eğer alırsanız `Connection refused` Mac OS X veya Freebsd'de mesaj, ana bilgisayar adresi 127.0.0.1 belirtmeyi deneyin:
clickhouse client --host 127.0.0.1
Sisteminizde yüklü olan ClickHouse binary'nin üretim sürümünü özel olarak oluşturulmuş ClickHouse binaryinizle değiştirebilirsiniz. Bunu yapmak için resmi web sitesinden talimatları izleyerek Makinenize ClickHouse yükleyin. Ardından, aşağıdakileri çalıştırın:
sudo service clickhouse-server stop
sudo cp ClickHouse/build/programs/clickhouse /usr/bin/
sudo service clickhouse-server start
Not thate that `clickhouse-client`, `clickhouse-server` ve diğerleri yaygın olarak paylaşılan sembolik bağlardır `clickhouse` ikilik.
Ayrıca sisteminizde yüklü ClickHouse paketinden yapılandırma dosyası ile özel inşa ClickHouse ikili çalıştırabilirsiniz:
sudo service clickhouse-server stop
sudo -u clickhouse ClickHouse/build/programs/clickhouse server --config-file /etc/clickhouse-server/config.xml
# IDE (entegre geliştirme ortamı) {#ide-integrated-development-environment}
Hangi IDE kullanmak bilmiyorsanız, clion kullanmanızı öneririz. CLion ticari bir yazılımdır, ancak 30 günlük ücretsiz deneme süresi sunar. Öğrenciler için de ücretsizdir. CLion Linux ve Mac OS X hem de kullanılabilir.
KDevelop ve QTCreator, ClickHouse geliştirmek için bir IDE'NİN diğer harika alternatifleridir. KDevelop kararsız olmasına rağmen çok kullanışlı bir IDE olarak geliyor. KDevelop projeyi açtıktan sonra bir süre sonra çökerse, tıklamanız gerekir “Stop All” proje dosyalarının listesini açar açmaz düğme. Bunu yaptıktan sonra KDevelop ile çalışmak iyi olmalıdır.
Basit kod editörleri olarak, Yüce metin veya Visual Studio kodunu veya Kate'i (hepsi Linux'ta kullanılabilir) kullanabilirsiniz.
Her ihtimale karşı, Clion'un yarattığını belirtmek gerekir `build` kendi başına yol, aynı zamanda kendi seçtikleri `debug` yapı türü için, yapılandırma için Clion'da tanımlanan ve sizin tarafınızdan yüklenmeyen bir cmake sürümünü kullanır ve son olarak CLion kullanacaktır `make` yerine yapı görevlerini çalıştırmak için `ninja`. Bu normal bir davranıştır, sadece karışıklığı önlemek için bunu aklınızda bulundurun.
# Kod Yazma {#writing-code}
Açıklaması ClickHouse mimarisi burada bulabilirsiniz: https://clickhouse.tech / doscs/TR / development / Arch /it /ec /ture/
Kod stili Kılavuzu: https://clickhouse.tech / doscs / TR / development / style/
Yazma testleri: https://clickhouse.teknoloji / doscs / TR / geliştirme / testler/
Görevlerin listesi: https://github.com/ClickHouse/ClickHouse/blob/master/testsructions/easy\_tasks\_sorted\_en.md
# Test Verileri {#test-data}
Clickhouse'un geliştirilmesi genellikle gerçekçi veri kümelerinin yüklenmesini gerektirir. Performans testi için özellikle önemlidir. Yandex'ten özel olarak hazırlanmış anonim veri setimiz var.Metrica. Ayrıca bazı 3GB boş disk alanı gerektirir. Bu verilerin geliştirme görevlerinin çoğunu gerçekleştirmek için gerekli olmadığını unutmayın.
sudo apt install wget xz-utils
wget https://clickhouse-datasets.s3.yandex.net/hits/tsv/hits_v1.tsv.xz
wget https://clickhouse-datasets.s3.yandex.net/visits/tsv/visits_v1.tsv.xz
xz -v -d hits_v1.tsv.xz
xz -v -d visits_v1.tsv.xz
clickhouse-client
CREATE TABLE test.hits ( WatchID UInt64, JavaEnable UInt8, Title String, GoodEvent Int16, EventTime DateTime, EventDate Date, CounterID UInt32, ClientIP UInt32, ClientIP6 FixedString(16), RegionID UInt32, UserID UInt64, CounterClass Int8, OS UInt8, UserAgent UInt8, URL String, Referer String, URLDomain String, RefererDomain String, Refresh UInt8, IsRobot UInt8, RefererCategories Array(UInt16), URLCategories Array(UInt16), URLRegions Array(UInt32), RefererRegions Array(UInt32), ResolutionWidth UInt16, ResolutionHeight UInt16, ResolutionDepth UInt8, FlashMajor UInt8, FlashMinor UInt8, FlashMinor2 String, NetMajor UInt8, NetMinor UInt8, UserAgentMajor UInt16, UserAgentMinor FixedString(2), CookieEnable UInt8, JavascriptEnable UInt8, IsMobile UInt8, MobilePhone UInt8, MobilePhoneModel String, Params String, IPNetworkID UInt32, TraficSourceID Int8, SearchEngineID UInt16, SearchPhrase String, AdvEngineID UInt8, IsArtifical UInt8, WindowClientWidth UInt16, WindowClientHeight UInt16, ClientTimeZone Int16, ClientEventTime DateTime, SilverlightVersion1 UInt8, SilverlightVersion2 UInt8, SilverlightVersion3 UInt32, SilverlightVersion4 UInt16, PageCharset String, CodeVersion UInt32, IsLink UInt8, IsDownload UInt8, IsNotBounce UInt8, FUniqID UInt64, HID UInt32, IsOldCounter UInt8, IsEvent UInt8, IsParameter UInt8, DontCountHits UInt8, WithHash UInt8, HitColor FixedString(1), UTCEventTime DateTime, Age UInt8, Sex UInt8, Income UInt8, Interests UInt16, Robotness UInt8, GeneralInterests Array(UInt16), RemoteIP UInt32, RemoteIP6 FixedString(16), WindowName Int32, OpenerName Int32, HistoryLength Int16, BrowserLanguage FixedString(2), BrowserCountry FixedString(2), SocialNetwork String, SocialAction String, HTTPError UInt16, SendTiming Int32, DNSTiming Int32, ConnectTiming Int32, ResponseStartTiming Int32, ResponseEndTiming Int32, FetchTiming Int32, RedirectTiming Int32, DOMInteractiveTiming Int32, DOMContentLoadedTiming Int32, DOMCompleteTiming Int32, LoadEventStartTiming Int32, LoadEventEndTiming Int32, NSToDOMContentLoadedTiming Int32, FirstPaintTiming Int32, RedirectCount Int8, SocialSourceNetworkID UInt8, SocialSourcePage String, ParamPrice Int64, ParamOrderID String, ParamCurrency FixedString(3), ParamCurrencyID UInt16, GoalsReached Array(UInt32), OpenstatServiceName String, OpenstatCampaignID String, OpenstatAdID String, OpenstatSourceID String, UTMSource String, UTMMedium String, UTMCampaign String, UTMContent String, UTMTerm String, FromTag String, HasGCLID UInt8, RefererHash UInt64, URLHash UInt64, CLID UInt32, YCLID UInt64, ShareService String, ShareURL String, ShareTitle String, `ParsedParams.Key1` Array(String), `ParsedParams.Key2` Array(String), `ParsedParams.Key3` Array(String), `ParsedParams.Key4` Array(String), `ParsedParams.Key5` Array(String), `ParsedParams.ValueDouble` Array(Float64), IslandID FixedString(16), RequestNum UInt32, RequestTry UInt8) ENGINE = MergeTree PARTITION BY toYYYYMM(EventDate) SAMPLE BY intHash32(UserID) ORDER BY (CounterID, EventDate, intHash32(UserID), EventTime);
CREATE TABLE test.visits ( CounterID UInt32, StartDate Date, Sign Int8, IsNew UInt8, VisitID UInt64, UserID UInt64, StartTime DateTime, Duration UInt32, UTCStartTime DateTime, PageViews Int32, Hits Int32, IsBounce UInt8, Referer String, StartURL String, RefererDomain String, StartURLDomain String, EndURL String, LinkURL String, IsDownload UInt8, TraficSourceID Int8, SearchEngineID UInt16, SearchPhrase String, AdvEngineID UInt8, PlaceID Int32, RefererCategories Array(UInt16), URLCategories Array(UInt16), URLRegions Array(UInt32), RefererRegions Array(UInt32), IsYandex UInt8, GoalReachesDepth Int32, GoalReachesURL Int32, GoalReachesAny Int32, SocialSourceNetworkID UInt8, SocialSourcePage String, MobilePhoneModel String, ClientEventTime DateTime, RegionID UInt32, ClientIP UInt32, ClientIP6 FixedString(16), RemoteIP UInt32, RemoteIP6 FixedString(16), IPNetworkID UInt32, SilverlightVersion3 UInt32, CodeVersion UInt32, ResolutionWidth UInt16, ResolutionHeight UInt16, UserAgentMajor UInt16, UserAgentMinor UInt16, WindowClientWidth UInt16, WindowClientHeight UInt16, SilverlightVersion2 UInt8, SilverlightVersion4 UInt16, FlashVersion3 UInt16, FlashVersion4 UInt16, ClientTimeZone Int16, OS UInt8, UserAgent UInt8, ResolutionDepth UInt8, FlashMajor UInt8, FlashMinor UInt8, NetMajor UInt8, NetMinor UInt8, MobilePhone UInt8, SilverlightVersion1 UInt8, Age UInt8, Sex UInt8, Income UInt8, JavaEnable UInt8, CookieEnable UInt8, JavascriptEnable UInt8, IsMobile UInt8, BrowserLanguage UInt16, BrowserCountry UInt16, Interests UInt16, Robotness UInt8, GeneralInterests Array(UInt16), Params Array(String), `Goals.ID` Array(UInt32), `Goals.Serial` Array(UInt32), `Goals.EventTime` Array(DateTime), `Goals.Price` Array(Int64), `Goals.OrderID` Array(String), `Goals.CurrencyID` Array(UInt32), WatchIDs Array(UInt64), ParamSumPrice Int64, ParamCurrency FixedString(3), ParamCurrencyID UInt16, ClickLogID UInt64, ClickEventID Int32, ClickGoodEvent Int32, ClickEventTime DateTime, ClickPriorityID Int32, ClickPhraseID Int32, ClickPageID Int32, ClickPlaceID Int32, ClickTypeID Int32, ClickResourceID Int32, ClickCost UInt32, ClickClientIP UInt32, ClickDomainID UInt32, ClickURL String, ClickAttempt UInt8, ClickOrderID UInt32, ClickBannerID UInt32, ClickMarketCategoryID UInt32, ClickMarketPP UInt32, ClickMarketCategoryName String, ClickMarketPPName String, ClickAWAPSCampaignName String, ClickPageName String, ClickTargetType UInt16, ClickTargetPhraseID UInt64, ClickContextType UInt8, ClickSelectType Int8, ClickOptions String, ClickGroupBannerID Int32, OpenstatServiceName String, OpenstatCampaignID String, OpenstatAdID String, OpenstatSourceID String, UTMSource String, UTMMedium String, UTMCampaign String, UTMContent String, UTMTerm String, FromTag String, HasGCLID UInt8, FirstVisit DateTime, PredLastVisit Date, LastVisit Date, TotalVisits UInt32, `TraficSource.ID` Array(Int8), `TraficSource.SearchEngineID` Array(UInt16), `TraficSource.AdvEngineID` Array(UInt8), `TraficSource.PlaceID` Array(UInt16), `TraficSource.SocialSourceNetworkID` Array(UInt8), `TraficSource.Domain` Array(String), `TraficSource.SearchPhrase` Array(String), `TraficSource.SocialSourcePage` Array(String), Attendance FixedString(16), CLID UInt32, YCLID UInt64, NormalizedRefererHash UInt64, SearchPhraseHash UInt64, RefererDomainHash UInt64, NormalizedStartURLHash UInt64, StartURLDomainHash UInt64, NormalizedEndURLHash UInt64, TopLevelDomain UInt64, URLScheme UInt64, OpenstatServiceNameHash UInt64, OpenstatCampaignIDHash UInt64, OpenstatAdIDHash UInt64, OpenstatSourceIDHash UInt64, UTMSourceHash UInt64, UTMMediumHash UInt64, UTMCampaignHash UInt64, UTMContentHash UInt64, UTMTermHash UInt64, FromHash UInt64, WebVisorEnabled UInt8, WebVisorActivity UInt32, `ParsedParams.Key1` Array(String), `ParsedParams.Key2` Array(String), `ParsedParams.Key3` Array(String), `ParsedParams.Key4` Array(String), `ParsedParams.Key5` Array(String), `ParsedParams.ValueDouble` Array(Float64), `Market.Type` Array(UInt8), `Market.GoalID` Array(UInt32), `Market.OrderID` Array(String), `Market.OrderPrice` Array(Int64), `Market.PP` Array(UInt32), `Market.DirectPlaceID` Array(UInt32), `Market.DirectOrderID` Array(UInt32), `Market.DirectBannerID` Array(UInt32), `Market.GoodID` Array(String), `Market.GoodName` Array(String), `Market.GoodQuantity` Array(Int32), `Market.GoodPrice` Array(Int64), IslandID FixedString(16)) ENGINE = CollapsingMergeTree(Sign) PARTITION BY toYYYYMM(StartDate) SAMPLE BY intHash32(UserID) ORDER BY (CounterID, StartDate, intHash32(UserID), VisitID);
clickhouse-client --max_insert_block_size 100000 --query "INSERT INTO test.hits FORMAT TSV" < hits_v1.tsv
clickhouse-client --max_insert_block_size 100000 --query "INSERT INTO test.visits FORMAT TSV" < visits_v1.tsv
# Çekme İsteği Oluşturma {#creating-pull-request}
Github'un kullanıcı arayüzünde çatal deposuna gidin. Bir dalda gelişiyorsanız, o Dalı seçmeniz gerekir. Bir olacak “Pull request” ekranda bulunan düğme. Özünde, bu demektir “create a request for accepting my changes into the main repository”.
Çalışma henüz tamamlanmamış olsa bile bir çekme isteği oluşturulabilir. Bu durumda lütfen kelimeyi koyun “WIP” (devam eden çalışma) başlığın başında, daha sonra değiştirilebilir. Bu, kooperatif Gözden geçirme ve değişikliklerin tartışılması ve mevcut tüm testlerin çalıştırılması için kullanışlıdır. Değişikliklerinizin kısa bir açıklamasını sağlamanız önemlidir, daha sonra sürüm değişiklikleri oluşturmak için kullanılacaktır.
Yandex çalışanları PR'NİZİ bir etiketle etiketlediğinde testler başlayacaktır “can be tested”. The results of some first checks (e.g. code style) will come in within several minutes. Build check results will arrive within half an hour. And the main set of tests will report itself within an hour.
Sistem, çekme isteğiniz için ayrı ayrı ClickHouse ikili yapıları hazırlayacaktır. Bu yapıları almak için tıklayın “Details” yanındaki bağlantı “ClickHouse build check” çekler listesinde giriş. Orada inşa doğrudan bağlantılar bulacaksınız .eğer üretim sunucularında bile dağıtabilirsiniz ClickHouse DEB paketleri (eğer hiçbir korku varsa).
Büyük olasılıkla bazı yapılar ilk kez başarısız olur. Bunun nedeni, hem gcc hem de clang ile, hemen hemen tüm mevcut uyarılarla (her zaman `-Werror` bayrak) clang için etkin. Aynı sayfada, tüm yapı günlüklerini bulabilirsiniz, böylece tüm olası yollarla ClickHouse oluşturmak zorunda kalmazsınız.

12
docs/tr/development/index.md Normal file
View File

@ -0,0 +1,12 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_folder_title: "Geli\u015Fme"
toc_hidden: true
toc_priority: 58
toc_title: "gizlenmi\u015F"
---
# ClickHouse Geliştirme {#clickhouse-development}
[Orijinal makale](https://clickhouse.tech/docs/en/development/) <!--hide-->

841
docs/tr/development/style.md Normal file
View File

@ -0,0 +1,841 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 68
toc_title: "C++ kodu nas\u0131l yaz\u0131l\u0131r"
---
# C++ kodu nasıl yazılır {#how-to-write-c-code}
## Genel Öneriler {#general-recommendations}
**1.** Aşağıdakiler önerilerdir, gereksinimler değildir.
**2.** Kod düzenliyorsanız, varolan kodun biçimlendirmesini takip etmek mantıklıdır.
**3.** Kod stili tutarlılık için gereklidir. Tutarlılık, kodu okumayı kolaylaştırır ve aynı zamanda kodu aramayı da kolaylaştırır.
**4.** Kuralların çoğunun mantıklı nedenleri yoktur, yerleşik uygulamalar tarafından belirlenir.
## Biçimlendirir {#formatting}
**1.** Biçimlendirme çoğu tarafından otomatik olarak yapılacaktır `clang-format`.
**2.** Girintiler 4 boşluk vardır. Bir sekme dört boşluk ekleyecek şekilde geliştirme ortamınızı yapılandırın.
**3.** Kıvırcık parantezlerin açılması ve kapatılması ayrı bir satırda olmalıdır.
``` cpp
inline void readBoolText(bool & x, ReadBuffer & buf)
{
char tmp = '0';
readChar(tmp, buf);
x = tmp != '0';
}
```
**4.** Tüm fonksiyon gövdesi tek ise `statement`, tek bir satır üzerine yerleştirilebilir. Yer (satır sonunda boşluk dışında) etrafında ayraç boşluk.
``` cpp
inline size_t mask() const { return buf_size() - 1; }
inline size_t place(HashValue x) const { return x & mask(); }
```
**5.** Fonksiyonlar için. Parantezlerin etrafına boşluk koymayın.
``` cpp
void reinsert(const Value & x)
```
``` cpp
memcpy(&buf[place_value], &x, sizeof(x));
```
**6.** İçinde `if`, `for`, `while` ve diğer ifadeler, açılış braketinin önüne bir boşluk yerleştirilir (işlev çağrılarının aksine).
``` cpp
for (size_t i = 0; i < rows; i += storage.index_granularity)
```
**7.** İkili operatörlerin etrafına boşluk Ekle (`+`, `-`, `*`, `/`, `%`, …) and the ternary operator `?:`.
``` cpp
UInt16 year = (s[0] - '0') * 1000 + (s[1] - '0') * 100 + (s[2] - '0') * 10 + (s[3] - '0');
UInt8 month = (s[5] - '0') * 10 + (s[6] - '0');
UInt8 day = (s[8] - '0') * 10 + (s[9] - '0');
```
**8.** Bir satır beslemesi girilirse, operatörü yeni bir satıra koyun ve girintiyi ondan önce artırın.
``` cpp
if (elapsed_ns)
message << " ("
<< rows_read_on_server * 1000000000 / elapsed_ns << " rows/s., "
<< bytes_read_on_server * 1000.0 / elapsed_ns << " MB/s.) ";
```
**9.** İsterseniz, bir çizgi içinde hizalama için boşluk kullanabilirsiniz.
``` cpp
dst.ClickLogID = click.LogID;
dst.ClickEventID = click.EventID;
dst.ClickGoodEvent = click.GoodEvent;
```
**10.** Operatörler etrafında boşluk kullanmayın `.`, `->`.
Gerekirse, operatör bir sonraki satıra sarılabilir. Bu durumda, önündeki ofset artar.
**11.** Tekli operatörleri ayırmak için boşluk kullanmayın (`--`, `++`, `*`, `&`, …) from the argument.
**12.** Virgülden sonra bir boşluk koyun, ancak ondan önce değil. Aynı kural, bir içindeki noktalı virgül için de geçerlidir `for` ifade.
**13.** Ayırmak için boşluk kullanmayın `[]` operatör.
**14.** İn a `template <...>` ifade, arasında bir boşluk kullanın `template` ve `<`; sonra boşluk yok `<` ya da önce `>`.
``` cpp
template <typename TKey, typename TValue>
struct AggregatedStatElement
{}
```
**15.** Sınıflarda ve yapılarda, yazın `public`, `private`, ve `protected` aynı seviyede `class/struct` ve kodun geri kalanını girinti.
``` cpp
template <typename T>
class MultiVersion
{
public:
/// Version of object for usage. shared_ptr manage lifetime of version.
using Version = std::shared_ptr<const T>;
...
}
```
**16.** Eğer aynı `namespace` tüm dosya için kullanılır ve başka önemli bir şey yoktur, içinde bir ofset gerekli değildir `namespace`.
**17.** Eğer blok için bir `if`, `for`, `while` veya başka bir ifade tek bir `statement`, kıvırcık parantez isteğe bağlıdır. Place the `statement` bunun yerine ayrı bir satırda. Bu kural iç içe geçmiş için de geçerlidir `if`, `for`, `while`, …
Ama eğer iç `statement` kıvırcık parantez içerir veya `else`, dış blok kıvırcık parantez içinde yazılmalıdır.
``` cpp
/// Finish write.
for (auto & stream : streams)
stream.second->finalize();
```
**18.** Çizgilerin uçlarında boşluk olmamalıdır.
**19.** Kaynak dosyalar UTF-8 kodlanmıştır.
**20.** ASCII olmayan karakterler dize değişmezlerinde kullanılabilir.
``` cpp
<< ", " << (timer.elapsed() / chunks_stats.hits) << " μsec/hit.";
```
**21.** Tek bir satırda birden çok ifade yazmayın.
**22.** Fonksiyonların içindeki kod bölümlerini gruplandırın ve bunları birden fazla boş satırla ayırın.
**23.** Bir veya iki boş satırla ayrı işlevler, sınıflar vb.
**24.** `A const` (bir değerle ilgili) tür adından önce yazılmalıdır.
``` cpp
//correct
const char * pos
const std::string & s
//incorrect
char const * pos
```
**25.** Bir işaretçi veya başvuru bildirirken, `*` ve `&` semboller her iki taraftaki boşluklarla ayrılmalıdır.
``` cpp
//correct
const char * pos
//incorrect
const char* pos
const char *pos
```
**26.** Şablon türlerini kullanırken, `using` anahtar kelime (en basit durumlar hariç).
Başka bir deyişle, şablon parametreleri yalnızca `using` ve kodda tekrarlanmıyor.
`using` bir işlevin içinde olduğu gibi yerel olarak bildirilebilir.
``` cpp
//correct
using FileStreams = std::map<std::string, std::shared_ptr<Stream>>;
FileStreams streams;
//incorrect
std::map<std::string, std::shared_ptr<Stream>> streams;
```
**27.** Bir ifadede farklı türde birkaç değişken bildirmeyin.
``` cpp
//incorrect
int x, *y;
```
**28.** C tarzı yayınları kullanmayın.
``` cpp
//incorrect
std::cerr << (int)c <<; std::endl;
//correct
std::cerr << static_cast<int>(c) << std::endl;
```
**29.** Sınıflarda ve yapılarda, grup üyeleri ve işlevleri her görünürlük kapsamı içinde ayrı ayrı.
**30.** Küçük sınıflar ve yapılar için, yöntem bildirimini uygulamadan ayırmak gerekli değildir.
Aynı şey, herhangi bir sınıf veya yapıdaki küçük yöntemler için de geçerlidir.
Templated sınıflar ve yapılar için, yöntem bildirimlerini uygulamadan ayırmayın(aksi takdirde aynı çeviri biriminde tanımlanmaları gerekir).
**31.** Satırları 80 yerine 140 karakterle sarabilirsiniz.
**32.** Postfix gerekli değilse, her zaman önek artış / azaltma işleçlerini kullanın.
``` cpp
for (Names::const_iterator it = column_names.begin(); it != column_names.end(); ++it)
```
## Yorumlar {#comments}
**1.** Kodun önemsiz olmayan tüm bölümleri için yorum eklediğinizden emin olun.
Bu çok önemli. Yorumu yazmak, kodun gerekli olmadığını veya yanlış tasarlandığını anlamanıza yardımcı olabilir.
``` cpp
/** Part of piece of memory, that can be used.
* For example, if internal_buffer is 1MB, and there was only 10 bytes loaded to buffer from file for reading,
* then working_buffer will have size of only 10 bytes
* (working_buffer.end() will point to position right after those 10 bytes available for read).
*/
```
**2.** Yorumlar gerektiği kadar ayrıntılı olabilir.
**3.** Açıklama yaptıkları koddan önce yorumları yerleştirin. Nadir durumlarda, yorumlar aynı satırda koddan sonra gelebilir.
``` cpp
/** Parses and executes the query.
*/
void executeQuery(
ReadBuffer & istr, /// Where to read the query from (and data for INSERT, if applicable)
WriteBuffer & ostr, /// Where to write the result
Context & context, /// DB, tables, data types, engines, functions, aggregate functions...
BlockInputStreamPtr & query_plan, /// Here could be written the description on how query was executed
QueryProcessingStage::Enum stage = QueryProcessingStage::Complete /// Up to which stage process the SELECT query
)
```
**4.** Yorumlar sadece İngilizce olarak yazılmalıdır.
**5.** Bir kitaplık yazıyorsanız, ana başlık dosyasına açıklayan ayrıntılı yorumları ekleyin.
**6.** Ek bilgi vermeyen yorumlar eklemeyin. Özellikle, bu gibi boş yorumlar bırakmayın:
``` cpp
/*
* Procedure Name:
* Original procedure name:
* Author:
* Date of creation:
* Dates of modification:
* Modification authors:
* Original file name:
* Purpose:
* Intent:
* Designation:
* Classes used:
* Constants:
* Local variables:
* Parameters:
* Date of creation:
* Purpose:
*/
```
Örnek kaynaktan ödünç alınmıştır http://home.tamk.fi / ~ jaalto / kurs / kodlama stili / doc/ulaşılamaz-kod/.
**7.** Çöp yorum yazmayın (yazar, oluşturma tarihi ..) her dosyanın başında.
**8.** Tek satırlı yorumlar üç eğik çizgi ile başlar: `///` ve çok satırlı yorumlar ile başlar `/**`. Bu yorumlar dikkate alınır “documentation”.
Not: bu yorumlardan belgeler oluşturmak için Doxygen kullanabilirsiniz. Ancak DOXYGEN genellikle kullanılmaz, çünkü IDE'DEKİ kodda gezinmek daha uygundur.
**9.** Çok satırlı açıklamaların başında ve sonunda (çok satırlı bir açıklamayı kapatan satır hariç) boş satırları olmamalıdır.
**10.** Kodu yorumlamak için temel yorumları kullanın, değil “documenting” yorumlar.
**11.** İşlem yapmadan önce kodun yorumlanan kısımlarını silin.
**12.** Yorumlarda veya kodda küfür kullanmayın.
**13.** Büyük harf kullanmayın. Aşırı noktalama kullanmayın.
``` cpp
/// WHAT THE FAIL???
```
**14.** Sınırlayıcılar yapmak için yorum kullanmayın.
``` cpp
///******************************************************
```
**15.** Yorumlarda tartışmalara başlamayın.
``` cpp
/// Why did you do this stuff?
```
**16.** Ne hakkında olduğunu açıklayan bir bloğun sonunda bir yorum yazmaya gerek yok.
``` cpp
/// for
```
## Adlar {#names}
**1.** Değişkenlerin ve sınıf üyelerinin adlarında alt çizgi içeren küçük harfler kullanın.
``` cpp
size_t max_block_size;
```
**2.** İşlevlerin (yöntemlerin) adları için, küçük harfle başlayan camelCase kullanın.
``` cpp
std::string getName() const override { return "Memory"; }
```
**3.** Sınıfların (yapıların) adları için büyük harfle başlayan CamelCase kullanın. Ben dışındaki önekler arayüzler için kullanılmaz.
``` cpp
class StorageMemory : public IStorage
```
**4.** `using` sınıf aslarla aynı şekilde adlandırılır veya `_t` ucunda.
**5.** Şablon Türü argümanlarının isimleri: basit durumlarda, kullanın `T`; `T`, `U`; `T1`, `T2`.
Daha karmaşık durumlar için, sınıf adları için kuralları izleyin veya öneki ekleyin `T`.
``` cpp
template <typename TKey, typename TValue>
struct AggregatedStatElement
```
**6.** Şablon sabit argümanlarının adları: değişken adları için kurallara uyun veya kullanın `N` basit durumlarda.
``` cpp
template <bool without_www>
struct ExtractDomain
```
**7.** Soyut sınıflar (arayüzler) için şunları ekleyebilirsiniz `I` önek.
``` cpp
class IBlockInputStream
```
**8.** Yerel olarak bir değişken kullanırsanız, kısa adı kullanabilirsiniz.
Diğer tüm durumlarda, anlamı açıklayan bir isim kullanın.
``` cpp
bool info_successfully_loaded = false;
```
**9.** İsimleri `define`s ve genel sabitler alt çizgi ile ALL\_CAPS kullanın.
``` cpp
#define MAX_SRC_TABLE_NAMES_TO_STORE 1000
```
**10.** Dosya adları, içerikleriyle aynı stili kullanmalıdır.
Bir dosya tek bir sınıf içeriyorsa, dosyayı sınıfla aynı şekilde adlandırın (CamelCase).
Dosya tek bir işlev içeriyorsa, dosyayı işlevle aynı şekilde adlandırın (camelCase).
**11.** İsim bir kısaltma içeriyorsa, o zaman:
- Değişken adları için kısaltma küçük harfler kullanmalıdır `mysql_connection` (değil `mySQL_connection`).
- Sınıfların ve işlevlerin adları için, büyük harfleri kısaltmada tutun`MySQLConnection` (değil `MySqlConnection`).
**12.** Yalnızca sınıf üyelerini başlatmak için kullanılan yapıcı bağımsız değişkenleri, sınıf üyeleri ile aynı şekilde, ancak sonunda bir alt çizgi ile adlandırılmalıdır.
``` cpp
FileQueueProcessor(
const std::string & path_,
const std::string & prefix_,
std::shared_ptr<FileHandler> handler_)
: path(path_),
prefix(prefix_),
handler(handler_),
log(&Logger::get("FileQueueProcessor"))
{
}
```
Bağımsız değişken yapıcı gövdesinde kullanılmazsa, alt çizgi soneki atlanabilir.
**13.** Yerel değişkenlerin ve sınıf üyelerinin adlarında fark yoktur (önek gerekmez).
``` cpp
timer (not m_timer)
```
**14.** Bir de SAB theitler için `enum`, büyük harfle CamelCase kullanın. ALL\_CAPS da kabul edilebilir. Eğer... `enum` yerel olmayan, bir `enum class`.
``` cpp
enum class CompressionMethod
{
QuickLZ = 0,
LZ4 = 1,
};
```
**15.** Tüm isimler İngilizce olmalıdır. Rusça kelimelerin çevirisi izin verilmez.
not Stroka
**16.** Kısaltmalar iyi biliniyorsa kabul edilebilir (kısaltmanın anlamını Wikipedia'da veya bir arama motorunda kolayca bulabilirsiniz).
`AST`, `SQL`.
Not `NVDH` (some random letters)
Kısaltılmış versiyon ortak kullanım ise eksik kelimeler kabul edilebilir.
Yorumlarda tam ad yanında yer alıyorsa bir kısaltma da kullanabilirsiniz.
**17.** C++ kaynak kodu ile dosya adları olmalıdır `.cpp` uzantı. Başlık dosyaları olmalıdır `.h` uzantı.
## Kod nasıl yazılır {#how-to-write-code}
**1.** Bellek yönetimi.
El ile bellek ayırma (`delete`) sadece kütüphane kodunda kullanılabilir.
Kütüphane kod inunda, `delete` operatör yalnızca yıkıcılarda kullanılabilir.
Uygulama kodunda, bellek sahibi olan nesne tarafından serbest bırakılmalıdır.
Örnekler:
- En kolay yol, bir nesneyi yığına yerleştirmek veya onu başka bir sınıfın üyesi yapmaktır.
- Çok sayıda küçük nesne için kapları kullanın.
- Öbekte bulunan az sayıda nesnenin otomatik olarak ayrılması için şunları kullanın `shared_ptr/unique_ptr`.
**2.** Kaynak yönetimi.
Kullanmak `RAII` ve yukarıya bakın.
**3.** Hata işleme.
İstisnaları kullanın. Çoğu durumda, yalnızca bir istisna atmanız gerekir ve onu yakalamanız gerekmez (çünkü `RAII`).
Çevrimdışı veri işleme uygulamalarında, istisnaları yakalamamak genellikle kabul edilebilir.
Kullanıcı isteklerini işleyen sunucularda, bağlantı işleyicisinin en üst düzeyindeki istisnaları yakalamak genellikle yeterlidir.
İş parçacığı işlevlerinde, bunları ana iş parçacığında yeniden taramak için tüm istisnaları yakalamalı ve tutmalısınız `join`.
``` cpp
/// If there weren't any calculations yet, calculate the first block synchronously
if (!started)
{
calculate();
started = true;
}
else /// If calculations are already in progress, wait for the result
pool.wait();
if (exception)
exception->rethrow();
```
İşleme olmadan istisnaları asla gizlemeyin. Sadece körü körüne log tüm istisnaları koymak asla.
``` cpp
//Not correct
catch (...) {}
```
Eğer bazı özel durumlar göz ardı etmek gerekiyorsa, sadece özel olanlar için bunu yapmak ve diğerleri yeniden oluşturma.
``` cpp
catch (const DB::Exception & e)
{
if (e.code() == ErrorCodes::UNKNOWN_AGGREGATE_FUNCTION)
return nullptr;
else
throw;
}
```
Yanıt kodlarıyla işlevleri kullanırken veya `errno`, her zaman sonucu kontrol edin ve hata durumunda bir istisna atın.
``` cpp
if (0 != close(fd))
throwFromErrno("Cannot close file " + file_name, ErrorCodes::CANNOT_CLOSE_FILE);
```
`Do not use assert`.
**4.** İstisna türleri.
Uygulama kodunda karmaşık özel durum hiyerarşisini kullanmaya gerek yoktur. Özel durum metni bir sistem yöneticisi için anlaşılabilir olmalıdır.
**5.** Yıkıcılardan istisnalar atmak.
Bu tavsiye edilmez, ancak izin verilir.
Aşağıdaki seçenekleri kullanın:
- Bir işlev oluşturma (`done()` veya `finalize()`) bu, bir istisnaya yol açabilecek tüm işleri önceden yapacaktır. Bu işlev çağrıldıysa, daha sonra yıkıcıda istisna olmamalıdır.
- Çok karmaşık olan görevler (ağ üzerinden ileti gönderme gibi), sınıf kullanıcısının imha edilmeden önce çağırması gereken ayrı bir yöntemle yerleştirilebilir.
- Yıkıcıda bir istisna varsa, onu gizlemek yerine günlüğe kaydetmek daha iyidir (logger mevcutsa).
- Basit uygulamalarda, güvenmek kabul edilebilir `std::terminate` bu (vakaların `noexcept` varsayılan olarak C++11) istisnaları işlemek için.
**6.** Anonim kod blokları.
Belirli değişkenleri yerel hale getirmek için tek bir işlevin içinde ayrı bir kod bloğu oluşturabilirsiniz, böylece bloktan çıkarken yıkıcılar çağrılır.
``` cpp
Block block = data.in->read();
{
std::lock_guard<std::mutex> lock(mutex);
data.ready = true;
data.block = block;
}
ready_any.set();
```
**7.** Multithreading.
Çevrimdışı veri işleme programlarında:
- Tek bir CPU çekirdeğinde mümkün olan en iyi performansı elde etmeye çalışın. Daha sonra gerekirse kodunuzu parallelize edebilirsiniz.
Sunucu uygulamalarında:
- İstekleri işlemek için iş parçacığı havuzunu kullanın. Bu noktada, userspace bağlam değiştirme gerektiren herhangi bir görevimiz olmadı.
Çatal paralelleştirme için kullanılmaz.
**8.** İş parçacıklarını senkronize etme.
Genellikle farklı iş parçacıklarının farklı bellek hücreleri kullanmasını sağlamak mümkündür (daha da iyisi: farklı önbellek çizgileri) ve herhangi bir iş parçacığı senkronizasyonu kullanmamak (hariç `joinAll`).
Senkronizasyon gerekiyorsa, çoğu durumda, mutex altında kullanmak yeterlidir `lock_guard`.
Diğer durumlarda sistem senkronizasyonu ilkellerini kullanın. Meşgul bekleme kullanmayın.
Atomik işlemler sadece en basit durumlarda kullanılmalıdır.
Birincil uzmanlık alanınız olmadığı sürece kilitsiz veri yapılarını uygulamaya çalışmayın.
**9.** İşaretçiler vs referanslar.
Çoğu durumda, referansları tercih edin.
**10.** const.
Sabit referanslar, sabitler için işaretçiler kullanın, `const_iterator` ve const yöntemleri.
Düşünmek `const` varsayılan olmak ve olmayan kullanmak-`const` sadece gerektiğinde.
Değişkenleri değere göre geçirirken, `const` genellikle mantıklı değil.
**11.** imzasız.
Kullanmak `unsigned` gerekirse.
**12.** Sayısal türleri.
Türleri kullanın `UInt8`, `UInt16`, `UInt32`, `UInt64`, `Int8`, `Int16`, `Int32`, ve `Int64` gibi `size_t`, `ssize_t`, ve `ptrdiff_t`.
Bu türleri sayılar için kullanmayın: `signed/unsigned long`, `long long`, `short`, `signed/unsigned char`, `char`.
**13.** Argümanları geçmek.
Karmaşık değerleri referansla geçirin (dahil `std::string`).
Bir işlev öbekte oluşturulan bir nesnenin sahipliğini yakalarsa, bağımsız değişken türünü yapın `shared_ptr` veya `unique_ptr`.
**14.** Değerleri döndürür.
Çoğu durumda, sadece kullanın `return`. Yaz domayın `[return std::move(res)]{.strike}`.
İşlev öbek üzerinde bir nesne ayırır ve döndürürse, şunları kullanın `shared_ptr` veya `unique_ptr`.
Nadir durumlarda, değeri bir argüman aracılığıyla döndürmeniz gerekebilir. Bu durumda, argüman bir referans olmalıdır.
``` cpp
using AggregateFunctionPtr = std::shared_ptr<IAggregateFunction>;
/** Allows creating an aggregate function by its name.
*/
class AggregateFunctionFactory
{
public:
AggregateFunctionFactory();
AggregateFunctionPtr get(const String & name, const DataTypes & argument_types) const;
```
**15.** ad.
Ayrı bir kullanmaya gerek yoktur `namespace` uygulama kodu için.
Küçük kütüphanelerin de buna ihtiyacı yok.
Orta ve büyük kütüphaneler için her şeyi bir `namespace`.
Kütüphan theede `.h` dosya, kullanabilirsiniz `namespace detail` uygulama kodu için gerekli olmayan uygulama ayrıntılarını gizlemek için.
İn a `.cpp` dosya, bir kullanabilirsiniz `static` veya sembolleri gizlemek için anonim ad alanı.
Ayrıca, bir `namespace` bir için kullanılabilir `enum` ilgili isimlerin harici bir yere düşmesini önlemek için `namespace` (ama kullanmak daha iyidir `enum class`).
**16.** Ertelenmiş başlatma.
Başlatma için bağımsız değişkenler gerekiyorsa, normalde varsayılan bir yapıcı yazmamalısınız.
Daha sonra başlatmayı geciktirmeniz gerekiyorsa, geçersiz bir nesne oluşturacak varsayılan bir yapıcı ekleyebilirsiniz. Veya, az sayıda nesne için şunları kullanabilirsiniz `shared_ptr/unique_ptr`.
``` cpp
Loader(DB::Connection * connection_, const std::string & query, size_t max_block_size_);
/// For deferred initialization
Loader() {}
```
**17.** Sanal fonksiyonlar.
Sınıf polimorfik kullanım için tasarlanmamışsa, işlevleri sanal hale getirmeniz gerekmez. Bu aynı zamanda yıkıcı için de geçerlidir.
**18.** Kodlamalar.
Her yerde UTF-8 kullanın. Kullanmak `std::string`ve`char *`. Kullanmayın `std::wstring`ve`wchar_t`.
**19.** Günlük.
Koddaki her yerde örneklere bakın.
Taahhütte bulunmadan önce, tüm anlamsız ve hata ayıklama günlüğünü ve diğer hata ayıklama çıktı türlerini silin.
İzleme düzeyinde bile döngülerde oturum açmaktan kaçınılmalıdır.
Günlükleri herhangi bir günlük düzeyinde okunabilir olmalıdır.
Günlük kaydı yalnızca uygulama kodunda, çoğunlukla kullanılmalıdır.
Günlük mesajları İngilizce olarak yazılmalıdır.
Günlük, tercihen Sistem Yöneticisi için anlaşılabilir olmalıdır.
Günlüğünde küfür kullanmayın.
Günlüğünde UTF-8 kodlamasını kullanın. Nadir durumlarda, günlüğünde ASCII olmayan karakterler kullanabilirsiniz.
**20.** Giriş-çıkış.
Kullanmayın `iostreams` uygulama performansı için kritik olan iç döngülerde (ve asla kullanmayın `stringstream`).
Kullan... `DB/IO` kütüphane yerine.
**21.** Tarih ve zaman.
Görmek `DateLUT` kitaplık.
**22.** içermek.
Her zaman kullanın `#pragma once` korumaları dahil etmek yerine.
**23.** kullanım.
`using namespace` kullanılmaz. Kullanabilirsiniz `using` özel bir şeyle. Ancak bir sınıf veya işlev içinde yerel yapın.
**24.** Kullanmayın `trailing return type` gerekli olmadıkça fonksiyonlar için.
``` cpp
[auto f() -&gt; void;]{.strike}
```
**25.** Değişkenlerin bildirimi ve başlatılması.
``` cpp
//right way
std::string s = "Hello";
std::string s{"Hello"};
//wrong way
auto s = std::string{"Hello"};
```
**26.** Sanal işlevler için yaz `virtual` temel sınıfta, ama yaz `override` yerine `virtual` soyundan gelen sınıflarda.
## C++ ' ın kullanılmayan özellikleri {#unused-features-of-c}
**1.** Sanal devralma kullanılmaz.
**2.** C++03 özel durum belirteçleri kullanılmaz.
## Platform {#platform}
**1.** Belirli bir platform için kod yazıyoruz.
Ama diğer şeyler eşit olmak, çapraz platform veya taşınabilir kod tercih edilir.
**2.** Dil: C++17.
**3.** Derleyici: `gcc`. Şu anda (Aralık 2017), kod sürüm 7.2 kullanılarak derlenmiştir. (Ayrıca kullanılarak derlenebilir `clang 4`.)
Standart kütüphane kullanılır (`libstdc++` veya `libc++`).
**4.**OS: Linux UB .untu, daha eski değil.
**5.**Kod x86\_64 CPU mimarisi için yazılmıştır.
CPU komut seti, sunucularımız arasında desteklenen minimum kümedir. Şu anda, sse 4.2.
**6.** Kullanmak `-Wall -Wextra -Werror` derleme bayrakları.
**7.** Statik olarak bağlanması zor olanlar hariç tüm kitaplıklarla statik bağlantı kullanın (bkz. `ldd` komut).
**8.** Kod geliştirilmiş ve yayın ayarları ile ayıklanır.
## Araçlar {#tools}
**1.** KDevelop iyi bir IDE.
**2.** Hata ayıklama için kullanın `gdb`, `valgrind` (`memcheck`), `strace`, `-fsanitize=...`, veya `tcmalloc_minimal_debug`.
**3.** Profilleme için kullanın `Linux Perf`, `valgrind` (`callgrind`), veya `strace -cf`.
**4.** Kaynaklar Git'te.
**5.** Montaj kullanımları `CMake`.
**6.** Programlar kullanılarak serbest bırakılır `deb` paketler.
**7.** Ana taahhüt yapı kırmak gerekir.
Sadece seçilen revizyonlar uygulanabilir olarak kabul edilir.
**8.** Kod yalnızca kısmen hazır olsa bile, mümkün olduğunca sık taahhüt yapın.
Bu amaçla dalları kullanın.
Eğer kod inunuz `master` şube henüz imara değil, önce inşa onu hariç `push`. Bunu bitirmek veya birkaç gün içinde kaldırmak gerekir.
**9.** Non-önemsiz değişiklik, kullanım şubeleri ve sunucu bunları yayımlamak.
**10.** Kullanılmayan kod depodan kaldırılır.
## Kitaplık {#libraries}
**1.** C++14 standart Kütüphanesi kullanılır (deneysel uzantılara izin verilir) ve `boost` ve `Poco` çerçeveler.
**2.** Gerekirse, OS paketinde bulunan iyi bilinen kütüphaneleri kullanabilirsiniz.
Zaten mevcut olan iyi bir çözüm varsa, başka bir kütüphane yüklemeniz gerektiği anlamına gelse bile kullanın.
(Ancak kötü kütüphaneleri koddan kaldırmaya hazır olun .)
**3.** Paketlerde ihtiyacınız olan şey yoksa veya eski bir sürüme veya yanlış derleme türüne sahip değilseniz, paketlerde olmayan bir kitaplık yükleyebilirsiniz.
**4.** Kütüphane küçükse ve kendi karmaşık yapı sistemine sahip değilse, kaynak dosyaları `contrib` klasör.
**5.** Tercih her zaman zaten kullanımda olan kütüphanelere verilir.
## Genel Öneriler {#general-recommendations-1}
**1.** Mümkün olduğunca az kod yazın.
**2.** En basit çözümü deneyin.
**3.** Nasıl çalışacağını ve iç döngünün nasıl çalışacağını bilene kadar kod yazmayın.
**4.** En basit durumlarda, kullanın `using` sınıflar veya yapılar yerine.
**5.** Mümkünse, kopya oluşturucuları, atama işleçleri, yıkıcılar (sınıf en az bir sanal işlev içeriyorsa, sanal bir işlev dışında) yazmayın, oluşturucuları taşıyın veya atama işleçlerini taşıyın. Başka bir deyişle, derleyici tarafından oluşturulan işlevleri düzgün çalışması gerekir. Kullanabilirsiniz `default`.
**6.** Kod sadeleştirme teşvik edilir. Mümkünse kodunuzun boyutunu azaltın.
## Ek Öneriler {#additional-recommendations}
**1.** Açıkça belirtme `std::` türleri için `stddef.h`
tavsiye edilmez. Başka bir deyişle, yazmanızı öneririz `size_t` yerine `std::size_t` daha kısa olduğu için.
Eklemek kabul edilebilir `std::`.
**2.** Açıkça belirtme `std::` standart C kitap fromlığından fonksiyonlar için
tavsiye edilmez. Başka bir deyişle, yazın `memcpy` yerine `std::memcpy`.
Bunun nedeni, aşağıdaki gibi benzer standart dışı işlevlerin olmasıdır `memmem`. Bu işlevleri zaman zaman kullanıyoruz. Bu işlevler mevcut değil `namespace std`.
Yazar yousan `std::memcpy` yerine `memcpy` her yerde, o zaman `memmem` olarak `std::` garip görünecek.
Yine de, hala kullanabilirsiniz `std::` eğer tercih ederseniz edin.
**3.** Aynı olanlar standart C++ kütüphanesinde mevcut olduğunda C'den işlevleri kullanma.
Daha verimli ise bu kabul edilebilir.
Örneğin, kullanın `memcpy` yerine `std::copy` büyük bellek parçalarını kopyalamak için.
**4.** Çok satırlı fonksiyon argümanları.
Aşağıdaki sarma stillerinden herhangi birine izin verilir:
``` cpp
function(
T1 x1,
T2 x2)
```
``` cpp
function(
size_t left, size_t right,
const & RangesInDataParts ranges,
size_t limit)
```
``` cpp
function(size_t left, size_t right,
const & RangesInDataParts ranges,
size_t limit)
```
``` cpp
function(size_t left, size_t right,
const & RangesInDataParts ranges,
size_t limit)
```
``` cpp
function(
size_t left,
size_t right,
const & RangesInDataParts ranges,
size_t limit)
```
[Orijinal makale](https://clickhouse.tech/docs/en/development/style/) <!--hide-->

252
docs/tr/development/tests.md Normal file
View File

@ -0,0 +1,252 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 69
toc_title: "ClickHouse testleri nas\u0131l \xE7al\u0131\u015Ft\u0131r\u0131l\u0131\
r"
---
# ClickHouse Testi {#clickhouse-testing}
## Fonksiyonel Testler {#functional-tests}
Fonksiyonel testler en basit ve kullanımı kolay olanlardır. ClickHouse özelliklerinin çoğu fonksiyonel testlerle test edilebilir ve bu şekilde test edilebilecek ClickHouse kodundaki her değişiklik için kullanılması zorunludur.
Her işlevsel test, çalışan ClickHouse sunucusuna bir veya birden çok sorgu gönderir ve sonucu referansla karşılaştırır.
Testler bulunur `queries` dizin. İki alt dizin var: `stateless` ve `stateful`. Durumsuz testler, önceden yüklenmiş test verileri olmadan sorguları çalıştırır - genellikle testin kendisinde anında küçük sentetik veri kümeleri oluştururlar. Durum bilgisi testleri, Yandex'ten önceden yüklenmiş test verileri gerektirir.Metrica ve halka açık değil. Biz sadece kullanmak eğilimindedir `stateless` testler ve yeni eklemekten kaçının `stateful` testler.
Her test iki tipten biri olabilir: `.sql` ve `.sh`. `.sql` test için borulu basit SQL komut dosyasıdır `clickhouse-client --multiquery --testmode`. `.sh` test kendisi tarafından çalıştırılan bir komut dosyasıdır.
Tüm testleri çalıştırmak için şunları kullanın `clickhouse-test` aracı. Bak `--help` Olası seçeneklerin listesi için. Sadece tüm testleri çalıştırmak veya test adı alt dize tarafından süzülmüş testlerin alt kümesini çalıştırabilirsiniz: `./clickhouse-test substring`.
Fonksiyonel testleri çağırmanın en basit yolu kopyalamaktır `clickhouse-client` -e doğru `/usr/bin/`, çalıştırmak `clickhouse-server` ve sonra koş `./clickhouse-test` kendi dizininden.
Yeni test eklemek için, bir `.sql` veya `.sh` dosya içinde `queries/0_stateless` dizin, elle kontrol edin ve sonra oluşturun `.reference` aşağıdaki şekilde dosya: `clickhouse-client -n --testmode < 00000_test.sql > 00000_test.reference` veya `./00000_test.sh > ./00000_test.reference`.
Testler yalnızca tabloları (create, drop, vb.) kullanmalıdır `test` önceden oluşturulduğu varsayılır veritabanı; ayrıca testler geçici tablolar kullanabilirsiniz.
İşlevsel testlerde dağıtılmış sorgular kullanmak istiyorsanız, kaldıraç `remote` tablo fonksiyonu ile `127.0.0.{1..2}` sunucunun kendisini sorgulaması için adresler; veya sunucu yapılandırma dosyasında önceden tanımlanmış test kümelerini kullanabilirsiniz `test_shard_localhost`.
Bazı testler ile işaretlenir `zookeeper`, `shard` veya `long` kendi adlarına.
`zookeeper` ZooKeeper kullanan testler içindir. `shard` testler içindir
dinlemek için sunucu gerektirir `127.0.0.*`; `distributed` veya `global` aynı var
anlama. `long` bir saniye biraz daha uzun süren testler içindir. Yapabilirsin
kullanarak bu test gruplarını devre dışı bırakın `--no-zookeeper`, `--no-shard` ve
`--no-long` sırasıyla seçenekler.
## Bilinen Hatalar {#known-bugs}
Fonksiyonel testlerle kolayca çoğaltılabilen bazı hatalar biliyorsak, hazırlanmış fonksiyonel testleri `tests/queries/bugs` dizin. Bu testler taşınacaktır `tests/queries/0_stateless` hatalar düzeltildiğinde.
## Entegrasyon Testleri {#integration-tests}
Entegrasyon testleri, kümelenmiş konfigürasyonda Clickhouse'u ve MySQL, Postgres, MongoDB gibi diğer sunucularla ClickHouse etkileşimini test etmeyi sağlar. Ağ bölmelerini, paket damlalarını vb. taklit etmek için kullanışlıdırlar. Bu testler Docker altında çalıştırılır ve çeşitli yazılımlarla birden fazla konteyner oluşturur.
Görmek `tests/integration/README.md` bu testlerin nasıl çalıştırılacağı hakkında.
Clickhouse'un üçüncü taraf sürücülerle entegrasyonunun sınanmadığını unutmayın. Ayrıca şu anda JDBC ve ODBC sürücülerimizle entegrasyon testlerimiz yok.
## Ünite Testleri {#unit-tests}
Birim testleri, Clickhouse'u bir bütün olarak değil, tek bir yalıtılmış kitaplık veya sınıfı test etmek istediğinizde kullanışlıdır. Etkinleştirebilir veya devre dışı bırakma ile testlerin yapı `ENABLE_TESTS` Cmake seçeneği. Birim testleri (ve diğer test programları) bulunur `tests` kodun alt dizinleri. Birim testlerini çalıştırmak için şunları yazın `ninja test`. Bazı testler kullanın `gtest`, ancak bazıları test başarısızlığında sıfır olmayan çıkış kodunu döndüren programlardır.
Kodun zaten işlevsel testler tarafından kapsanması durumunda birim testlerine sahip olmak zorunlu değildir (ve işlevsel testler genellikle kullanımı çok daha basittir).
## Performans Testleri {#performance-tests}
Performans testleri ölçmek ve sentetik sorguları ClickHouse bazı izole kısmının performansını karşılaştırmak için izin verir. Testler bulunur `tests/performance`. Her test ile temsil edilir `.xml` test durumunun açıklaması ile dosya. Testler ile çalıştırılır `clickhouse performance-test` Aracı (Bu gömülü `clickhouse` ikilik). Görmek `--help` çağırma için.
Her test, durdurma için bazı koşullarla (örneğin, bir döngüde bir veya birden fazla sorgu (muhtemelen parametre kombinasyonlarıyla) çalıştırır “maximum execution speed is not changing in three seconds”) ve sorgu performansı ile ilgili bazı metrikleri ölçün (örneğin “maximum execution speed”). Bazı testler önceden yüklenmiş test veri kümesinde Önkoşullar içerebilir.
Bazı senaryoda Clickhouse'un performansını artırmak istiyorsanız ve basit sorgularda iyileştirmeler gözlemlenebiliyorsa, bir performans testi yazmanız önerilir. Her zaman kullanmak mantıklı `perf top` testleriniz sırasında veya diğer perf araçları.
## Test araçları ve komut dosyaları {#test-tools-and-scripts}
Bazı programlar `tests` dizin testleri hazırlanmış değil, ancak test araçlarıdır. Örneğin, için `Lexer` bir araç var `src/Parsers/tests/lexer` bu sadece stdin'in tokenizasyonunu yapar ve renklendirilmiş sonucu stdout'a yazar. Bu tür araçları kod örnekleri olarak ve keşif ve manuel test için kullanabilirsiniz.
Ayrıca Çift Dosya yerleştirebilirsiniz `.sh` ve `.reference` aracı ile birlikte bazı önceden tanımlanmış giriş üzerinde çalıştırmak için-daha sonra komut sonucu karşılaştırılabilir `.reference` Dosya. Bu tür testler otomatik değildir.
## Çeşitli Testler {#miscellaneous-tests}
Bulunan dış sözlükler için testler vardır `tests/external_dictionaries` ve makine öğrenilen modeller için `tests/external_models`. Bu testler güncelleştirilmez ve tümleştirme testlerine aktarılmalıdır.
Çekirdek ekler için ayrı bir test var. Bu test, ayrı sunucularda ClickHouse kümesini çalıştırır ve çeşitli arıza durumlarını taklit eder: ağ bölünmesi, paket bırakma (ClickHouse düğümleri arasında, ClickHouse ve ZooKeeper arasında, ClickHouse sunucusu ve istemci arasında, vb.), `kill -9`, `kill -STOP` ve `kill -CONT` , istemek [Jepsen](https://aphyr.com/tags/Jepsen). Daha sonra test, kabul edilen tüm eklerin yazıldığını ve reddedilen tüm eklerin olmadığını kontrol eder.
Clickhouse açık kaynaklı önce çekirdek testi ayrı ekip tarafından yazılmıştır. Bu takım artık ClickHouse ile çalışmıyor. Test yanlışlıkla Java ile yazılmıştır. Bu nedenlerden dolayı, çekirdek testi yeniden yazılmalı ve entegrasyon testlerine taşınmalıdır.
## Manuel Test {#manual-testing}
Yeni bir özellik geliştirdiğinizde, el ile de test etmek mantıklıdır. Bunu aşağıdaki adımlarla yapabilirsiniz:
ClickHouse Oluşturun. Terminalden Clickhouse'u çalıştırın: dizini değiştir `programs/clickhouse-server` ve ile çalıştırın `./clickhouse-server`. Bu yapılandırma kullanacak (`config.xml`, `users.xml` ve içindeki dosyalar `config.d` ve `users.d` dizinler) geçerli dizinden varsayılan olarak. ClickHouse sunucusuna bağlanmak için, çalıştırın `programs/clickhouse-client/clickhouse-client`.
Tüm clickhouse araçlarının (sunucu, istemci, vb.) sadece tek bir ikili için symlinks olduğunu unutmayın `clickhouse`. Bu ikili bulabilirsiniz `programs/clickhouse`. Tüm araçlar olarak da çağrılabilir `clickhouse tool` yerine `clickhouse-tool`.
Alternatif olarak ClickHouse paketini yükleyebilirsiniz: Yandex deposundan kararlı sürüm veya kendiniz için paket oluşturabilirsiniz `./release` ClickHouse kaynakları kökünde. Ardından sunucuyu şu şekilde başlatın `sudo service clickhouse-server start` (veya sunucuyu durdurmak için durdurun). Günlükleri arayın `/etc/clickhouse-server/clickhouse-server.log`.
ClickHouse sisteminizde zaten yüklü olduğunda, yeni bir `clickhouse` ikili ve mevcut ikili değiştirin:
``` bash
$ sudo service clickhouse-server stop
$ sudo cp ./clickhouse /usr/bin/
$ sudo service clickhouse-server start
```
Ayrıca sistem clickhouse-server durdurmak ve aynı yapılandırma ile ancak terminale günlüğü ile kendi çalıştırabilirsiniz:
``` bash
$ sudo service clickhouse-server stop
$ sudo -u clickhouse /usr/bin/clickhouse server --config-file /etc/clickhouse-server/config.xml
```
Gdb ile örnek:
``` bash
$ sudo -u clickhouse gdb --args /usr/bin/clickhouse server --config-file /etc/clickhouse-server/config.xml
```
Sistem clickhouse-sunucu zaten çalışıyorsa ve bunu durdurmak istemiyorsanız, sizin port numaralarını değiştirebilirsiniz `config.xml` (veya bunları bir dosyada geçersiz kılma `config.d` dizin), uygun veri yolu sağlayın ve çalıştırın.
`clickhouse` ikili neredeyse hiçbir bağımlılıkları vardır ve Linux dağıtımları geniş genelinde çalışır. Hızlı ve kirli bir sunucuda değişikliklerinizi test etmek için, sadece yapabilirsiniz `scp` taze inşa `clickhouse` sunucunuza ikili ve daha sonra yukarıdaki örneklerde olduğu gibi çalıştırın.
## Test Ortamı {#testing-environment}
Kararlı olarak yayınlamadan önce test ortamında dağıtın. Test ortamı, 1/39 bölümünü işleyen bir kümedir [Üye.Metrica](https://metrica.yandex.com/) veriler. Test ortamımızı Yandex ile paylaşıyoruz.Metrica takımı. ClickHouse mevcut verilerin üstünde kesinti olmadan yükseltilir. İlk önce verilerin gerçek zamanlı olarak gecikmeden başarıyla işlendiğine bakıyoruz, çoğaltma çalışmaya devam ediyor ve Yandex tarafından görülebilen herhangi bir sorun yok.Metrica takımı. İlk kontrol aşağıdaki şekilde yapılabilir:
``` 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;
```
Bazı durumlarda yandex'teki arkadaş ekiplerimizin test ortamına da dağıtım yapıyoruz: Pazar, Bulut, vb. Ayrıca geliştirme amacıyla kullanılan bazı donanım sunucularımız var.
## Yük Testi {#load-testing}
Test ortamına dağıtıldıktan sonra, üretim kümesinden gelen sorgularla yük testini çalıştırıyoruz. Bu elle yapılır.
Etkinleştirdiğinizden emin olun `query_log` üretim kümenizde.
Bir gün veya daha fazla sorgu günlüğü toplayın:
``` 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
```
Bu şekilde karmaşık bir örnektir. `type = 2` başarıyla yürütülen sorguları süzer. `query LIKE '%ym:%'` yandex'ten ilgili sorguları seçmektir.Metrica. `is_initial_query` yalnızca istemci tarafından başlatılan sorguları seçmektir, Clickhouse'un kendisi tarafından değil (dağıtılmış sorgu işlemenin parçaları olarak).
`scp` bu test kümenize günlük ve aşağıdaki gibi çalıştırın:
``` bash
$ clickhouse benchmark --concurrency 16 < queries.tsv
```
(muhtemelen de belirtmek istiyorum `--user`)
Sonra bir gece ya da hafta sonu için bırakın ve dinlenin.
Kontrol etmelisiniz `clickhouse-server` çökmez, bellek ayak izi sınırlıdır ve performans zamanla aşağılayıcı değildir.
Kesin sorgu yürütme zamanlamaları kaydedilmez ve sorguların ve ortamın yüksek değişkenliği nedeniyle karşılaştırılmaz.
## Yapı Testleri {#build-tests}
Yapı testleri, yapının çeşitli alternatif konfigürasyonlarda ve bazı yabancı sistemlerde bozulmadığını kontrol etmeyi sağlar. Testler bulunur `ci` dizin. Docker, Vagrant ve bazen de `qemu-user-static` Docker'ın içinde. Bu testler geliştirme aşamasındadır ve test çalıştırmaları otomatik değildir.
Motivasyon:
Normalde tüm testleri ClickHouse yapısının tek bir varyantında serbest bırakırız ve çalıştırırız. Ancak, iyice test edilmeyen alternatif yapı varyantları vardır. Örnekler:
- FreeBSD üzerine inşa;
- sistem paketlerinden kütüphaneler ile Debian üzerine inşa;
- kütüphanelerin paylaşılan bağlantısı ile oluşturun;
- AArch64 platformunda oluşturun;
- PowerPc platformunda oluşturun.
Örneğin, sistem paketleri ile oluştur kötü bir uygulamadır, çünkü bir sistemin hangi paketlerin tam sürümüne sahip olacağını garanti edemeyiz. Ancak bu gerçekten Debian bakıcılarına ihtiyaç duyuyor. Bu nedenle en azından bu yapı varyantını desteklemeliyiz. Başka bir örnek: paylaşılan bağlantı ortak bir sorun kaynağıdır, ancak bazı Meraklılar için gereklidir.
Tüm yapı varyantlarında tüm testleri çalıştıramasak da, en azından çeşitli yapı varyantlarının bozulmadığını kontrol etmek istiyoruz. Bu amaçla yapı testlerini kullanıyoruz.
## Protokol uyumluluğu testi {#testing-for-protocol-compatibility}
ClickHouse ağ protokolünü genişlettiğimizde, eski clickhouse istemcisinin yeni clickhouse sunucusu ile çalıştığını ve yeni clickhouse istemcisinin eski clickhouse sunucusu ile çalıştığını (sadece ilgili paketlerden ikili dosyaları çalıştırarak) manuel olarak test ediyoruz.
## Derleyiciden yardım {#help-from-the-compiler}
Ana ClickHouse kodu (bu `dbms` dizin) ile inşa edilmiştir `-Wall -Wextra -Werror` ve bazı ek etkin uyarılar ile. Bu seçenekler üçüncü taraf kitaplıkları için etkin olmasa da.
Clang daha yararlı uyarılar vardır-Sen ile onları arayabilirsiniz `-Weverything` ve varsayılan oluşturmak için bir şey seçin.
Üretim yapıları için gcc kullanılır (hala clang'dan biraz daha verimli kod üretir). Geliştirme için, clang genellikle kullanımı daha uygundur. Hata ayıklama modu ile kendi makinenizde inşa edebilirsiniz (dizüstü bilgisayarınızın pilinden tasarruf etmek için), ancak derleyicinin daha fazla uyarı üretebileceğini lütfen unutmayın `-O3` daha iyi kontrol akışı ve prosedürler arası analiz nedeniyle. Clang ile inşa ederken, `libc++` yerine kullanılır `libstdc++` ve hata ayıklama modu ile oluştururken, hata ayıklama sürümü `libc++` çalışma zamanında daha fazla hata yakalamak için izin verir kullanılır.
## Dezenfektanlar {#sanitizers}
**Adres dezenfektanı**.
Biz başına taahhüt bazında ASan altında fonksiyonel ve entegrasyon testleri çalıştırın.
**Valgrind (Memcheck)**.
Bir gecede valgrind altında fonksiyonel testler yapıyoruz. Birden fazla saat sürer. Şu anda bilinen bir yanlış pozitif var `re2` kütüphane, bkz [bu makale](https://research.swtch.com/sparse).
**Tanımsız davranış dezenfektanı.**
Biz başına taahhüt bazında ASan altında fonksiyonel ve entegrasyon testleri çalıştırın.
**İplik dezenfektanı**.
Biz başına taahhüt bazında tsan altında fonksiyonel testler çalıştırın. Tsan altında hala taahhüt bazında entegrasyon testleri yapmıyoruz.
**Bellek temizleyici**.
Şu anda hala MSan kullanmıyoruz.
**Hata ayıklama ayırıcısı.**
Hata ayıklama sürümü `jemalloc` hata ayıklama oluşturmak için kullanılır.
## Fuzzing {#fuzzing}
Rastgele SQL sorguları oluşturmak ve sunucunun ölmediğini kontrol etmek için basit fuzz testi kullanıyoruz. Fuzz testi Adres dezenfektanı ile yapılır. İçinde bulabilirsiniz `00746_sql_fuzzy.pl`. Bu test sürekli olarak (gece ve daha uzun) çalıştırılmalıdır.
Aralık 2018 itibariyle, hala kütüphane kodunun izole fuzz testini kullanmıyoruz.
## Güvenlik Denetimi {#security-audit}
Yandex Bulut departmanından insanlar, güvenlik açısından ClickHouse yeteneklerine bazı temel genel bakışlar yaparlar.
## Statik Analizörler {#static-analyzers}
Koş weuyoruz `PVS-Studio` taahhüt bazında. Değerlendir havedik `clang-tidy`, `Coverity`, `cppcheck`, `PVS-Studio`, `tscancode`. Sen kullanım talimatları bulacaksınız `tests/instructions/` dizin. Ayrıca okuyabilirsiniz [Rusça makale](https://habr.com/company/yandex/blog/342018/).
Kullanıyorsanız `CLion` bir IDE olarak, bazı kaldıraç `clang-tidy` kutudan kontrol eder.
## Sertleşme {#hardening}
`FORTIFY_SOURCE` varsayılan olarak kullanılır. Neredeyse işe yaramaz, ancak nadir durumlarda hala mantıklı ve bunu devre dışı bırakmıyoruz.
## Kod Stili {#code-style}
Kod stili kuralları açıklanmıştır [burada](https://clickhouse.tech/docs/en/development/style/).
Bazı ortak stil ihlallerini kontrol etmek için şunları kullanabilirsiniz `utils/check-style` komut.
Kodunuzun uygun stilini zorlamak için şunları kullanabilirsiniz `clang-format`. Dosya `.clang-format` kaynak rootlarında yer almaktadır. Çoğunlukla gerçek kod stilimizle karşılık gelir. Ancak uygulanması tavsiye edilmez `clang-format` varolan dosyalara biçimlendirmeyi daha da kötüleştirdiği için. Kullanabilirsiniz `clang-format-diff` eğer clang kaynak deposunda bulabilirsiniz aracı.
Alternatif olarak deneyebilirsiniz `uncrustify` kodunuzu yeniden biçimlendirmek için bir araç. Yapılandırma içinde `uncrustify.cfg` kaynaklarda kök. Daha az test edilmiştir `clang-format`.
`CLion` kod stilimiz için ayarlanması gereken kendi kod biçimlendiricisine sahiptir.
## Metrica B2B testleri {#metrica-b2b-tests}
Her ClickHouse sürümü Yandex Metrica ve AppMetrica motorları ile test edilir. Clickhouse'un Test ve kararlı sürümleri Vm'lerde dağıtılır ve Giriş verilerinin sabit örneğini işleyen Metrica motorunun küçük bir kopyasıyla çalışır. Daha sonra Metrica motorunun iki örneğinin sonuçları birlikte karşılaştırılır.
Bu testler ayrı ekip tarafından otomatikleştirilir. Yüksek sayıda hareketli parça nedeniyle, testler çoğu zaman tamamen ilgisiz nedenlerle başarısız olur, bu da anlaşılması çok zordur. Büyük olasılıkla bu testlerin bizim için negatif değeri var. Bununla birlikte, bu testlerin yüzlerce kişiden yaklaşık bir veya iki kez yararlı olduğu kanıtlanmıştır.
## Test Kapsamı {#test-coverage}
Temmuz 2018 itibariyle test kapsamını takip etmiyoruz.
## Test Otomasyonu {#test-automation}
Yandex dahili CI ve iş otomasyon sistemi ile testler yapıyoruz “Sandbox”.
Yapı işleri ve testler, taahhüt bazında sanal alanda çalıştırılır. Ortaya çıkan paketler ve test sonuçları Github'da yayınlanır ve doğrudan bağlantılar tarafından indirilebilir. Eserler sonsuza dek saklanır. Eğer GitHub bir çekme isteği gönderdiğinizde, biz olarak etiketlemek “can be tested” ve bizim CI sistemi sizin için ClickHouse paketleri (yayın, hata ayıklama, Adres dezenfektanı ile, vb) inşa edecek.
Travis CI, zaman ve hesaplama gücü sınırı nedeniyle kullanmıyoruz.
Jenkins'i kullanmayız. Daha önce kullanıldı ve şimdi Jenkins kullanmadığımız için mutluyuz.
[Orijinal makale](https://clickhouse.tech/docs/en/development/tests/) <!--hide-->

21
docs/tr/engines/database_engines/index.md Normal file
View File

@ -0,0 +1,21 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_folder_title: "Veritaban\u0131 Motorlar\u0131"
toc_priority: 27
toc_title: "Giri\u015F"
---
# Veritabanı Motorları {#database-engines}
Veritabanı motorları, tablolarla çalışmanıza izin verir.
Varsayılan olarak, ClickHouse yapılandırılabilir sağlayan yerel veritabanı altyapısını kullanır [masa motorları](../../engines/table_engines/index.md) ve bir [SQL lehçesi](../../sql_reference/syntax.md).
Aşağıdaki veritabanı altyapılarını da kullanabilirsiniz:
- [MySQL](mysql.md)
- [Tembel](lazy.md)
[Orijinal makale](https://clickhouse.tech/docs/en/database_engines/) <!--hide-->

18
docs/tr/engines/database_engines/lazy.md Normal file
View File

@ -0,0 +1,18 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 31
toc_title: Tembel
---
# Tembel {#lazy}
Tabloları yalnızca RAM'de tutar `expiration_time_in_seconds` son erişimden saniyeler sonra. Sadece \* Log tabloları ile kullanılabilir.
Erişimler arasında uzun bir zaman aralığı olan birçok küçük \* günlük tablosunu saklamak için optimize edilmiştir.
## Veritabanı oluşturma {#creating-a-database}
CREATE DATABASE testlazy ENGINE = Lazy(expiration_time_in_seconds);
[Orijinal makale](https://clickhouse.tech/docs/en/database_engines/lazy/) <!--hide-->

135
docs/tr/engines/database_engines/mysql.md Normal file
View File

@ -0,0 +1,135 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 30
toc_title: MySQL
---
# MySQL {#mysql}
Uzak bir MySQL sunucusunda veritabanlarına bağlanmak ve gerçekleştirmek için izin verir `INSERT` ve `SELECT` ClickHouse ve MySQL arasında veri alışverişi için sorgular.
Bu `MySQL` veritabanı motoru sorguları MySQL sunucusuna çevirir, böylece aşağıdaki gibi işlemleri gerçekleştirebilirsiniz `SHOW TABLES` veya `SHOW CREATE TABLE`.
Aşağıdaki sorguları gerçekleştiremiyor:
- `RENAME`
- `CREATE TABLE`
- `ALTER`
## Veritabanı oluşturma {#creating-a-database}
``` sql
CREATE DATABASE [IF NOT EXISTS] db_name [ON CLUSTER cluster]
ENGINE = MySQL('host:port', ['database' | database], 'user', 'password')
```
**Motor Parametreleri**
- `host:port` — MySQL server address.
- `database` — Remote database name.
- `user` — MySQL user.
- `password` — User password.
## Veri Türleri Desteği {#data_types-support}
| MySQL | ClickHouse |
|----------------------------------|--------------------------------------------------------------|
| UNSIGNED TINYINT | [Uİnt8](../../sql_reference/data_types/int_uint.md) |
| TINYINT | [Int8](../../sql_reference/data_types/int_uint.md) |
| UNSIGNED SMALLINT | [Uınt16](../../sql_reference/data_types/int_uint.md) |
| SMALLINT | [Int16](../../sql_reference/data_types/int_uint.md) |
| UNSIGNED INT, UNSIGNED MEDIUMINT | [Uİnt32](../../sql_reference/data_types/int_uint.md) |
| INT, MEDIUMINT | [Int32](../../sql_reference/data_types/int_uint.md) |
| UNSIGNED BIGINT | [Uİnt64](../../sql_reference/data_types/int_uint.md) |
| BIGINT | [Int64](../../sql_reference/data_types/int_uint.md) |
| FLOAT | [Float32](../../sql_reference/data_types/float.md) |
| DOUBLE | [Float64](../../sql_reference/data_types/float.md) |
| DATE | [Tarihli](../../sql_reference/data_types/date.md) |
| DATETIME, TIMESTAMP | [DateTime](../../sql_reference/data_types/datetime.md) |
| BINARY | [FixedString](../../sql_reference/data_types/fixedstring.md) |
Diğer tüm MySQL veri türleri dönüştürülür [Dize](../../sql_reference/data_types/string.md).
[Nullable](../../sql_reference/data_types/nullable.md) desteklenir.
## Kullanım Örnekleri {#examples-of-use}
MySQL tablo:
``` text
mysql> USE test;
Database changed
mysql> CREATE TABLE `mysql_table` (
-> `int_id` INT NOT NULL AUTO_INCREMENT,
-> `float` FLOAT NOT NULL,
-> PRIMARY KEY (`int_id`));
Query OK, 0 rows affected (0,09 sec)
mysql> insert into mysql_table (`int_id`, `float`) VALUES (1,2);
Query OK, 1 row affected (0,00 sec)
mysql> select * from mysql_table;
+------+-----+
| int_id | value |
+------+-----+
| 1 | 2 |
+------+-----+
1 row in set (0,00 sec)
```
Clickhouse'daki veritabanı, MySQL sunucusu ile veri alışverişi:
``` sql
CREATE DATABASE mysql_db ENGINE = MySQL('localhost:3306', 'test', 'my_user', 'user_password')
```
``` sql
SHOW DATABASES
```
``` text
┌─name─────┐
│ default │
│ mysql_db │
│ system │
└──────────┘
```
``` sql
SHOW TABLES FROM mysql_db
```
``` text
┌─name─────────┐
│ mysql_table │
└──────────────┘
```
``` sql
SELECT * FROM mysql_db.mysql_table
```
``` text
┌─int_id─┬─value─┐
│ 1 │ 2 │
└────────┴───────┘
```
``` sql
INSERT INTO mysql_db.mysql_table VALUES (3,4)
```
``` sql
SELECT * FROM mysql_db.mysql_table
```
``` text
┌─int_id─┬─value─┐
│ 1 │ 2 │
│ 3 │ 4 │
└────────┴───────┘
```
[Orijinal makale](https://clickhouse.tech/docs/en/database_engines/mysql/) <!--hide-->

8
docs/tr/engines/index.md Normal file
View File

@ -0,0 +1,8 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_folder_title: Motorlar
toc_priority: 25
---

85
docs/tr/engines/table_engines/index.md Normal file
View File

@ -0,0 +1,85 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_folder_title: "Masa Motorlar\u0131"
toc_priority: 26
toc_title: "Giri\u015F"
---
# Masa Motorları {#table_engines}
Tablo motoru (tablo türü) belirler:
- Verilerin nasıl ve nerede depolandığı, nereye yazılacağı ve nereden okunacağı.
- Hangi sorgular desteklenir ve nasıl.
- Eşzamanlı veri erişimi.
- Varsa indeks uselerin kullanımı.
- Çok iş parçacıklı istek yürütme mümkün olup olmadığı.
- Veri çoğaltma parametreleri.
## Motor Aileleri {#engine-families}
### MergeTree {#mergetree}
Yüksek yük görevleri için en evrensel ve fonksiyonel masa motorları. Bu motorlar tarafından paylaşılan özellik, sonraki arka plan veri işleme ile hızlı veri ekleme ' dir. `MergeTree` aile motorları destek veri çoğaltma (ile [Çoğaltıyordu\*](mergetree_family/replication.md) sürümleri), bölümleme ve diğer özellikler diğer motorlarda desteklenmez.
Ailede motorlar:
- [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)
- [Graphıtemergetree](mergetree_family/graphitemergetree.md)
### Günlük {#log}
Hafiflik [motorlar](log_family/index.md) minimum işlevsellik ile. Birçok küçük tabloyu (yaklaşık 1 milyon satıra kadar) hızlı bir şekilde yazmanız ve daha sonra bir bütün olarak okumanız gerektiğinde en etkili olanlardır.
Ailede motorlar:
- [TinyLog](log_family/tinylog.md)
- [StripeLog](log_family/stripelog.md)
- [Günlük](log_family/log.md)
### Entegrasyon Motorları {#integration-engines}
Diğer veri depolama ve işleme sistemleri ile iletişim kurmak için motorlar.
Ailede motorlar:
- [Kafka](integrations/kafka.md)
- [MySQL](integrations/mysql.md)
- [ODBC](integrations/odbc.md)
- [JDBC](integrations/jdbc.md)
- [HDFS](integrations/hdfs.md)
### Özel Motorlar {#special-engines}
Ailede motorlar:
- [Dağılı](special/distributed.md)
- [MaterializedView](special/materializedview.md)
- [Sözlük](special/dictionary.md)
- [Birleştirmek](special/merge.md)
- [Dosya](special/file.md)
- [Boş](special/null.md)
- [Koymak](special/set.md)
- [Katmak](special/join.md)
- [URL](special/url.md)
- [Görünüm](special/view.md)
- [Bellek](special/memory.md)
- [Arabellek](special/buffer.md)
## Sanal Sütunlar {#table_engines-virtual-columns}
Sanal sütun, motor kaynak kodunda tanımlanan ayrılmaz bir tablo altyapısı özniteliğidir.
Sanal sütunları belirtmemelisiniz `CREATE TABLE` sorgula ve onları göremezsin `SHOW CREATE TABLE` ve `DESCRIBE TABLE` sorgu sonuçları. Sanal sütunlar da salt okunur, bu nedenle sanal sütunlara veri ekleyemezsiniz.
Sanal bir sütundan veri seçmek için, adını `SELECT` sorgu. `SELECT *` sanal sütunlardan değerler döndürmez.
Tablo sanal sütunlarından biriyle aynı ada sahip bir sütuna sahip bir tablo oluşturursanız, sanal sütuna erişilemez hale gelir. Bunu yapmayı önermiyoruz. Çakışmaları önlemek için, sanal sütun adları genellikle bir alt çizgi ile öneki.
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/) <!--hide-->

123
docs/tr/engines/table_engines/integrations/hdfs.md Normal file
View File

@ -0,0 +1,123 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 36
toc_title: HDFS
---
# HDFS {#table_engines-hdfs}
Bu motor ile entegrasyon sağlar [Apache Hadoop](https://en.wikipedia.org/wiki/Apache_Hadoop) üzerinde veri Yönet allowingilmesine izin vererek ekosist dataem [HDFS](https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html)ClickHouse aracılığıyla. Bu motor benzer
to the [Dosya](../special/file.md) ve [URL](../special/url.md) motorlar, ancak hadoop özgü özellikleri sağlar.
## Kullanma {#usage}
``` sql
ENGINE = HDFS(URI, format)
```
Bu `URI` parametre, HDFS'DEKİ tüm dosya URI'SIDIR.
Bu `format` parametre kullanılabilir dosya biçimlerinden birini belirtir. Gerçekleştirmek
`SELECT` sorgular, biçim giriş için desteklenmeli ve gerçekleştirmek için
`INSERT` queries – for output. The available formats are listed in the
[Biçimliler](../../../interfaces/formats.md#formats) bölme.
Yol kısmı `URI` globs içerebilir. Bu durumda tablo salt okunur olurdu.
**Örnek:**
**1.** Set up the `hdfs_engine_table` Tablo:
``` sql
CREATE TABLE hdfs_engine_table (name String, value UInt32) ENGINE=HDFS('hdfs://hdfs1:9000/other_storage', 'TSV')
```
**2.** Fil filel file:
``` sql
INSERT INTO hdfs_engine_table VALUES ('one', 1), ('two', 2), ('three', 3)
```
**3.** Verileri sorgula:
``` sql
SELECT * FROM hdfs_engine_table LIMIT 2
```
``` text
┌─name─┬─value─┐
│ one │ 1 │
│ two │ 2 │
└──────┴───────┘
```
## Uygulama Detayları {#implementation-details}
- Okuma ve yazma paralel olabilir
- Desteklenmiyor:
- `ALTER` ve `SELECT...SAMPLE` harekat.
- Dizinler.
- Çoğalma.
**Yolda Globs**
Birden çok yol bileşenleri globs olabilir. İşlenmek için dosya var olmalı ve tüm yol deseniyle eşleşmelidir. Sırasında dosyaların listelen ofmesini belirler `SELECT` (not at `CREATE` an).
- `*` — Substitutes any number of any characters except `/` boş dize dahil.
- `?` — Substitutes any single character.
- `{some_string,another_string,yet_another_one}` — Substitutes any of strings `'some_string', 'another_string', 'yet_another_one'`.
- `{N..M}` — Substitutes any number in range from N to M including both borders.
İle yapılar `{}` benzer olan [uzak](../../../sql_reference/table_functions/remote.md) tablo işlevi.
**Örnek**
1. HDFS'DE aşağıdaki Urı'lerle TSV formatında birkaç dosyamız olduğunu varsayalım:
- ‘hdfs://hdfs1:9000/some\_dir/some\_file\_1’
- ‘hdfs://hdfs1:9000/some\_dir/some\_file\_2’
- ‘hdfs://hdfs1:9000/some\_dir/some\_file\_3’
- ‘hdfs://hdfs1:9000/another\_dir/some\_file\_1’
- ‘hdfs://hdfs1:9000/another\_dir/some\_file\_2’
- ‘hdfs://hdfs1:9000/another\_dir/some\_file\_3’
1. Altı dosyadan oluşan bir tablo oluşturmanın birkaç yolu vardır:
<!-- -->
``` sql
CREATE TABLE table_with_range (name String, value UInt32) ENGINE = HDFS('hdfs://hdfs1:9000/{some,another}_dir/some_file_{1..3}', 'TSV')
```
Başka bir yol:
``` sql
CREATE TABLE table_with_question_mark (name String, value UInt32) ENGINE = HDFS('hdfs://hdfs1:9000/{some,another}_dir/some_file_?', 'TSV')
```
Tablo, her iki dizindeki tüm dosyalardan oluşur (tüm dosyalar, sorguda açıklanan biçimi ve şemayı karşılamalıdır):
``` sql
CREATE TABLE table_with_asterisk (name String, value UInt32) ENGINE = HDFS('hdfs://hdfs1:9000/{some,another}_dir/*', 'TSV')
```
!!! warning "Uyarıcı"
Dosyaların listelenmesi, önde gelen sıfırlarla sayı aralıkları içeriyorsa, her basamak için parantez içeren yapıyı ayrı ayrı kullanın veya kullanın `?`.
**Örnek**
Adlı dosyaları içeren tablo oluşturma `file000`, `file001`, … , `file999`:
``` sql
CREARE TABLE big_table (name String, value UInt32) ENGINE = HDFS('hdfs://hdfs1:9000/big_dir/file{0..9}{0..9}{0..9}', 'CSV')
```
## Sanal Sütunlar {#virtual-columns}
- `_path` — Path to the file.
- `_file` — Name of the file.
**Ayrıca Bakınız**
- [Sanal sütunlar](../index.md#table_engines-virtual_columns)
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/hdfs/) <!--hide-->

8
docs/tr/engines/table_engines/integrations/index.md Normal file
View File

@ -0,0 +1,8 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_folder_title: Entegrasyonlar
toc_priority: 30
---

90
docs/tr/engines/table_engines/integrations/jdbc.md Normal file
View File

@ -0,0 +1,90 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 34
toc_title: JDBC
---
# JDBC {#table-engine-jdbc}
ClickHouse üzerinden harici veritabanlarına bağlanmak için izin verir [JDBC](https://en.wikipedia.org/wiki/Java_Database_Connectivity).
JDBC bağlantısını uygulamak için ClickHouse ayrı programı kullanır [clickhouse-JDBC-köprü](https://github.com/alex-krash/clickhouse-jdbc-bridge) bu bir daemon olarak çalışmalıdır.
Bu motor destekler [Nullable](../../../sql_reference/data_types/nullable.md) veri türü.
## Tablo oluşturma {#creating-a-table}
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name
(
columns list...
)
ENGINE = JDBC(dbms_uri, external_database, external_table)
```
**Motor Parametreleri**
- `dbms_uri` — URI of an external DBMS.
Biçimli: `jdbc:<driver_name>://<host_name>:<port>/?user=<username>&password=<password>`.
MySQL örneği: `jdbc:mysql://localhost:3306/?user=root&password=root`.
- `external_database` — Database in an external DBMS.
- `external_table` — Name of the table in `external_database`.
## Kullanım Örneği {#usage-example}
Doğrudan konsol istemcisine bağlanarak MySQL sunucusunda bir tablo oluşturma:
``` text
mysql> CREATE TABLE `test`.`test` (
-> `int_id` INT NOT NULL AUTO_INCREMENT,
-> `int_nullable` INT NULL DEFAULT NULL,
-> `float` FLOAT NOT NULL,
-> `float_nullable` FLOAT NULL DEFAULT NULL,
-> PRIMARY KEY (`int_id`));
Query OK, 0 rows affected (0,09 sec)
mysql> insert into test (`int_id`, `float`) VALUES (1,2);
Query OK, 1 row affected (0,00 sec)
mysql> select * from test;
+------+----------+-----+----------+
| int_id | int_nullable | float | float_nullable |
+------+----------+-----+----------+
| 1 | NULL | 2 | NULL |
+------+----------+-----+----------+
1 row in set (0,00 sec)
```
ClickHouse Server'da bir tablo oluşturma ve ondan veri seçme:
``` sql
CREATE TABLE jdbc_table
(
`int_id` Int32,
`int_nullable` Nullable(Int32),
`float` Float32,
`float_nullable` Nullable(Float32)
)
ENGINE JDBC('jdbc:mysql://localhost:3306/?user=root&password=root', 'test', 'test')
```
``` sql
SELECT *
FROM jdbc_table
```
``` text
┌─int_id─┬─int_nullable─┬─float─┬─float_nullable─┐
│ 1 │ ᴺᵁᴸᴸ │ 2 │ ᴺᵁᴸᴸ │
└────────┴──────────────┴───────┴────────────────┘
```
## Ayrıca Bakınız {#see-also}
- [JDBC tablo işlevi](../../../sql_reference/table_functions/jdbc.md).
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/jdbc/) <!--hide-->

176
docs/tr/engines/table_engines/integrations/kafka.md Normal file
View File

@ -0,0 +1,176 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 32
toc_title: Kafka
---
# Kafka {#kafka}
Bu motor ile çalışır [Apache Kafka](http://kafka.apache.org/).
Kafka sağlar:
- Veri akışlarını yayınlayın veya abone olun.
- Hataya dayanıklı depolama düzenlemek.
- Kullanılabilir hale geldikçe akışları işleyin.
## Tablo oluşturma {#table_engine-kafka-creating-a-table}
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE = Kafka()
SETTINGS
kafka_broker_list = 'host:port',
kafka_topic_list = 'topic1,topic2,...',
kafka_group_name = 'group_name',
kafka_format = 'data_format'[,]
[kafka_row_delimiter = 'delimiter_symbol',]
[kafka_schema = '',]
[kafka_num_consumers = N,]
[kafka_skip_broken_messages = N]
```
Gerekli parametreler:
- `kafka_broker_list` – A comma-separated list of brokers (for example, `localhost:9092`).
- `kafka_topic_list` – A list of Kafka topics.
- `kafka_group_name` – A group of Kafka consumers. Reading margins are tracked for each group separately. If you don't want messages to be duplicated in the cluster, use the same group name everywhere.
- `kafka_format` – Message format. Uses the same notation as the SQL `FORMAT` fonksiyon gibi `JSONEachRow`. Daha fazla bilgi için, bkz: [Biçimliler](../../../interfaces/formats.md) bölme.
İsteğe bağlı parametreler:
- `kafka_row_delimiter` – Delimiter character, which ends the message.
- `kafka_schema` – Parameter that must be used if the format requires a schema definition. For example, [Cap'n Proto](https://capnproto.org/) şema dosyasının yolunu ve kök adını gerektirir `schema.capnp:Message` nesne.
- `kafka_num_consumers` – The number of consumers per table. Default: `1`. Bir tüketicinin verimi yetersizse daha fazla tüketici belirtin. Bölüm başına yalnızca bir tüketici atanabileceğinden, toplam tüketici sayısı konudaki bölüm sayısını geçmemelidir.
- `kafka_skip_broken_messages` – Kafka message parser tolerance to schema-incompatible messages per block. Default: `0`. Eğer `kafka_skip_broken_messages = N` sonra motor atlar *N* Ayrıştırılamayan Kafka iletileri (bir ileti bir veri satırına eşittir).
Örnekler:
``` sql
CREATE TABLE queue (
timestamp UInt64,
level String,
message String
) ENGINE = Kafka('localhost:9092', 'topic', 'group1', 'JSONEachRow');
SELECT * FROM queue LIMIT 5;
CREATE TABLE queue2 (
timestamp UInt64,
level String,
message String
) ENGINE = Kafka SETTINGS kafka_broker_list = 'localhost:9092',
kafka_topic_list = 'topic',
kafka_group_name = 'group1',
kafka_format = 'JSONEachRow',
kafka_num_consumers = 4;
CREATE TABLE queue2 (
timestamp UInt64,
level String,
message String
) ENGINE = Kafka('localhost:9092', 'topic', 'group1')
SETTINGS kafka_format = 'JSONEachRow',
kafka_num_consumers = 4;
```
<details markdown="1">
<summary>Bir tablo oluşturmak için kullanımdan kaldırılan yöntem</summary>
!!! attention "Dikkat"
Bu yöntemi yeni projelerde kullanmayın. Mümkünse, eski projeleri yukarıda açıklanan yönteme geçin.
``` sql
Kafka(kafka_broker_list, kafka_topic_list, kafka_group_name, kafka_format
[, kafka_row_delimiter, kafka_schema, kafka_num_consumers, kafka_skip_broken_messages])
```
</details>
## Açıklama {#description}
Teslim edilen mesajlar otomatik olarak izlenir, bu nedenle bir gruptaki her mesaj yalnızca bir kez sayılır. Verileri iki kez almak istiyorsanız, tablonun başka bir grup adıyla bir kopyasını oluşturun.
Gruplar esnek ve kümede senkronize edilir. Örneğin, bir kümede 10 konu ve bir tablonun 5 kopyası varsa, her kopya 2 konu alır. Kopya sayısı değişirse, konular kopyalar arasında otomatik olarak yeniden dağıtılır. Bu konuda daha fazla bilgi edinin http://kafka.apache.org/intro.
`SELECT` mesajları okumak için özellikle yararlı değildir (hata ayıklama hariç), çünkü her mesaj yalnızca bir kez okunabilir. Hayata görünümler kullanarak gerçek zamanlı iş parçacıkları oluşturmak daha pratiktir. Bunu yapmak için :
1. Bir Kafka tüketici oluşturmak için motoru kullanın ve bir veri akışı düşünün.
2. İstenen yapıya sahip bir tablo oluşturun.
3. Verileri motordan dönüştüren ve daha önce oluşturulmuş bir tabloya koyan materyalleştirilmiş bir görünüm oluşturun.
Ne zaman `MATERIALIZED VIEW` motora katılır, arka planda veri toplamaya başlar. Bu, kafka'dan sürekli olarak mesaj almanızı ve bunları kullanarak gerekli biçime dönüştürmenizi sağlar `SELECT`.
Bir kafka tablosu istediğiniz kadar materialized görüşe sahip olabilir, kafka tablosundan doğrudan veri okumazlar, ancak yeni kayıtlar (bloklar halinde) alırlar, bu şekilde farklı ayrıntı seviyesine sahip birkaç tabloya yazabilirsiniz (gruplama-toplama ve olmadan).
Örnek:
``` sql
CREATE TABLE queue (
timestamp UInt64,
level String,
message String
) ENGINE = Kafka('localhost:9092', 'topic', 'group1', 'JSONEachRow');
CREATE TABLE daily (
day Date,
level String,
total UInt64
) ENGINE = SummingMergeTree(day, (day, level), 8192);
CREATE MATERIALIZED VIEW consumer TO daily
AS SELECT toDate(toDateTime(timestamp)) AS day, level, count() as total
FROM queue GROUP BY day, level;
SELECT level, sum(total) FROM daily GROUP BY level;
```
Performansı artırmak için, alınan iletiler bloklar halinde gruplandırılır [max\_ınsert\_block\_size](../../../operations/server_configuration_parameters/settings.md#settings-max_insert_block_size). İçinde blok oluş ifma ifdıysa [stream\_flush\_interval\_ms](../../../operations/server_configuration_parameters/settings.md) milisaniye, veri blok bütünlüğü ne olursa olsun tabloya temizlendi.
Konu verilerini almayı durdurmak veya dönüşüm mantığını değiştirmek için, hayata geçirilmiş görünümü ayırın:
``` sql
DETACH TABLE consumer;
ATTACH MATERIALIZED VIEW consumer;
```
Kullanarak hedef tabloyu değiştirmek istiyorsanız `ALTER` hedef tablo ile görünümdeki veriler arasındaki tutarsızlıkları önlemek için malzeme görünümünü devre dışı bırakmanızı öneririz.
## Yapılandırma {#configuration}
GraphiteMergeTree benzer şekilde, Kafka motoru ClickHouse yapılandırma dosyasını kullanarak genişletilmiş yapılandırmayı destekler. Kullanabileceğiniz iki yapılandırma anahtarı vardır: global (`kafka`) ve konu düzeyinde (`kafka_*`). Genel yapılandırma önce uygulanır ve sonra konu düzeyinde yapılandırma uygulanır (varsa).
``` xml
<!-- Global configuration options for all tables of Kafka engine type -->
<kafka>
<debug>cgrp</debug>
<auto_offset_reset>smallest</auto_offset_reset>
</kafka>
<!-- Configuration specific for topic "logs" -->
<kafka_logs>
<retry_backoff_ms>250</retry_backoff_ms>
<fetch_min_bytes>100000</fetch_min_bytes>
</kafka_logs>
```
Olası yapılandırma seçeneklerinin listesi için bkz. [librdkafka yapılandırma referansı](https://github.com/edenhill/librdkafka/blob/master/CONFIGURATION.md). Alt çizgiyi kullan (`_`) ClickHouse yapılandırmasında bir nokta yerine. Mesela, `check.crcs=true` olacak `<check_crcs>true</check_crcs>`.
## Sanal Sütunlar {#virtual-columns}
- `_topic` — Kafka topic.
- `_key` — Key of the message.
- `_offset` — Offset of the message.
- `_timestamp` — Timestamp of the message.
- `_partition` — Partition of Kafka topic.
**Ayrıca Bakınız**
- [Sanal sütunlar](../index.md#table_engines-virtual_columns)
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/kafka/) <!--hide-->

105
docs/tr/engines/table_engines/integrations/mysql.md Normal file
View File

@ -0,0 +1,105 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 33
toc_title: MySQL
---
# Mysql {#mysql}
MySQL motoru gerçekleştirmek için izin verir `SELECT` uzak bir MySQL sunucusunda depolanan veriler üzerinde sorgular.
## Tablo oluşturma {#creating-a-table}
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1] [TTL expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2] [TTL expr2],
...
) ENGINE = MySQL('host:port', 'database', 'table', 'user', 'password'[, replace_query, 'on_duplicate_clause']);
```
Ayrıntılı bir açıklamasını görmek [CREATE TABLE](../../../sql_reference/statements/create.md#create-table-query) sorgu.
Tablo yapısı orijinal MySQL tablo yapısından farklı olabilir:
- Sütun adları orijinal MySQL tablosundaki ile aynı olmalıdır, ancak bu sütunların sadece bazılarını ve herhangi bir sırada kullanabilirsiniz.
- Sütun türleri orijinal MySQL tablosundakilerden farklı olabilir. ClickHouse çalışır [döküm](../../../sql_reference/functions/type_conversion_functions.md#type_conversion_function-cast) ClickHouse veri türleri için değerler.
**Motor Parametreleri**
- `host:port` — MySQL server address.
- `database` — Remote database name.
- `table` — Remote table name.
- `user` — MySQL user.
- `password` — User password.
- `replace_query` — Flag that converts `INSERT INTO` için sorgular `REPLACE INTO`. Eğer `replace_query=1`, sorgu değiştirilir.
- `on_duplicate_clause` — The `ON DUPLICATE KEY on_duplicate_clause` eklenen ifade `INSERT` sorgu.
Örnek: `INSERT INTO t (c1,c2) VALUES ('a', 2) ON DUPLICATE KEY UPDATE c2 = c2 + 1`, nere `on_duplicate_clause` oluyor `UPDATE c2 = c2 + 1`. Görmek [MySQL dökü documentationmanları](https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) bulmak için hangi `on_duplicate_clause` ile kullanabilirsiniz `ON DUPLICATE KEY` yan.
Belirtmek `on_duplicate_clause` sen geçmek gerekir `0` to the `replace_query` parametre. Aynı anda geçerseniz `replace_query = 1` ve `on_duplicate_clause`, ClickHouse bir özel durum oluşturur.
Basit `WHERE` gibi maddeler `=, !=, >, >=, <, <=` MySQL sunucusunda yürütülür.
Geri kalan şartlar ve `LIMIT` örnekleme kısıtlaması, yalnızca MySQL sorgusu bittikten sonra Clickhouse'da yürütülür.
## Kullanım Örneği {#usage-example}
MySQL tablo:
``` text
mysql> CREATE TABLE `test`.`test` (
-> `int_id` INT NOT NULL AUTO_INCREMENT,
-> `int_nullable` INT NULL DEFAULT NULL,
-> `float` FLOAT NOT NULL,
-> `float_nullable` FLOAT NULL DEFAULT NULL,
-> PRIMARY KEY (`int_id`));
Query OK, 0 rows affected (0,09 sec)
mysql> insert into test (`int_id`, `float`) VALUES (1,2);
Query OK, 1 row affected (0,00 sec)
mysql> select * from test;
+------+----------+-----+----------+
| int_id | int_nullable | float | float_nullable |
+------+----------+-----+----------+
| 1 | NULL | 2 | NULL |
+------+----------+-----+----------+
1 row in set (0,00 sec)
```
Clickhouse'daki tablo, yukarıda oluşturulan MySQL tablosundan veri alma:
``` sql
CREATE TABLE mysql_table
(
`float_nullable` Nullable(Float32),
`int_id` Int32
)
ENGINE = MySQL('localhost:3306', 'test', 'test', 'bayonet', '123')
```
``` sql
SELECT * FROM mysql_table
```
``` text
┌─float_nullable─┬─int_id─┐
│ ᴺᵁᴸᴸ │ 1 │
└────────────────┴────────┘
```
## Ayrıca Bakınız {#see-also}
- [Bu ‘mysql’ tablo fonksiyonu](../../../sql_reference/table_functions/mysql.md)
- [Harici sözlük kaynağı olarak MySQL kullanma](../../../sql_reference/dictionaries/external_dictionaries/external_dicts_dict_sources.md#dicts-external_dicts_dict_sources-mysql)
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/mysql/) <!--hide-->

132
docs/tr/engines/table_engines/integrations/odbc.md Normal file
View File

@ -0,0 +1,132 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 35
toc_title: ODBC
---
# ODBC {#table-engine-odbc}
ClickHouse üzerinden harici veritabanlarına bağlanmak için izin verir [ODBC](https://en.wikipedia.org/wiki/Open_Database_Connectivity).
ODBC bağlantılarını güvenli bir şekilde uygulamak için ClickHouse ayrı bir program kullanır `clickhouse-odbc-bridge`. ODBC sürücüsü doğrudan yüklenmişse `clickhouse-server`, sürücü sorunları ClickHouse sunucu çökmesine neden olabilir. ClickHouse otomatik olarak başlar `clickhouse-odbc-bridge` gerekli olduğunda. ODBC Köprüsü programı aynı paketten yüklenir `clickhouse-server`.
Bu motor destekler [Nullable](../../../sql_reference/data_types/nullable.md) veri türü.
## Tablo oluşturma {#creating-a-table}
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1],
name2 [type2],
...
)
ENGINE = ODBC(connection_settings, external_database, external_table)
```
Ayrıntılı bir açıklamasını görmek [CREATE TABLE](../../../sql_reference/statements/create.md#create-table-query) sorgu.
Tablo yapısı kaynak tablo yapısından farklı olabilir:
- Sütun adları kaynak tablodaki ile aynı olmalıdır, ancak yalnızca bu sütunlardan bazılarını ve herhangi bir sırada kullanabilirsiniz.
- Sütun türleri kaynak tablodakilerden farklı olabilir. ClickHouse çalışır [döküm](../../../sql_reference/functions/type_conversion_functions.md#type_conversion_function-cast) ClickHouse veri türleri için değerler.
**Motor Parametreleri**
- `connection_settings` — Name of the section with connection settings in the `odbc.ini` Dosya.
- `external_database` — Name of a database in an external DBMS.
- `external_table` — Name of a table in the `external_database`.
## Kullanım Örneği {#usage-example}
**ODBC üzerinden yerel MySQL kurulumundan veri alma**
Bu örnek Ubuntu Linux 18.04 ve MySQL server 5.7 için kontrol edilir.
UnixODBC ve MySQL Connector yüklü olduğundan emin olun.
Varsayılan olarak (paketlerden yüklüyse), ClickHouse kullanıcı olarak başlar `clickhouse`. Bu nedenle, bu kullanıcıyı MySQL sunucusunda oluşturmanız ve yapılandırmanız gerekir.
``` bash
$ sudo mysql
```
``` sql
mysql> CREATE USER 'clickhouse'@'localhost' IDENTIFIED BY 'clickhouse';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'clickhouse'@'clickhouse' WITH GRANT OPTION;
```
Sonra bağlantıyı yapılandırın `/etc/odbc.ini`.
``` bash
$ cat /etc/odbc.ini
[mysqlconn]
DRIVER = /usr/local/lib/libmyodbc5w.so
SERVER = 127.0.0.1
PORT = 3306
DATABASE = test
USERNAME = clickhouse
PASSWORD = clickhouse
```
Kullanarak bağlantıyı kontrol edebilirsiniz `isql` unixodbc yüklemesinden yardımcı program.
``` bash
$ isql -v mysqlconn
+-------------------------+
| Connected! |
| |
...
```
MySQL tablo:
``` text
mysql> CREATE TABLE `test`.`test` (
-> `int_id` INT NOT NULL AUTO_INCREMENT,
-> `int_nullable` INT NULL DEFAULT NULL,
-> `float` FLOAT NOT NULL,
-> `float_nullable` FLOAT NULL DEFAULT NULL,
-> PRIMARY KEY (`int_id`));
Query OK, 0 rows affected (0,09 sec)
mysql> insert into test (`int_id`, `float`) VALUES (1,2);
Query OK, 1 row affected (0,00 sec)
mysql> select * from test;
+------+----------+-----+----------+
| int_id | int_nullable | float | float_nullable |
+------+----------+-----+----------+
| 1 | NULL | 2 | NULL |
+------+----------+-----+----------+
1 row in set (0,00 sec)
```
Clickhouse'daki tablo, MySQL tablosundan veri alma:
``` sql
CREATE TABLE odbc_t
(
`int_id` Int32,
`float_nullable` Nullable(Float32)
)
ENGINE = ODBC('DSN=mysqlconn', 'test', 'test')
```
``` sql
SELECT * FROM odbc_t
```
``` text
┌─int_id─┬─float_nullable─┐
│ 1 │ ᴺᵁᴸᴸ │
└────────┴────────────────┘
```
## Ayrıca Bakınız {#see-also}
- [ODBC harici sözlükler](../../../sql_reference/dictionaries/external_dictionaries/external_dicts_dict_sources.md#dicts-external_dicts_dict_sources-odbc)
- [ODBC tablo işlevi](../../../sql_reference/table_functions/odbc.md)
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/odbc/) <!--hide-->

8
docs/tr/engines/table_engines/log_family/index.md Normal file
View File

@ -0,0 +1,8 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_folder_title: "G\xFCnl\xFCk Aile"
toc_priority: 29
---

16
docs/tr/engines/table_engines/log_family/log.md Normal file
View File

@ -0,0 +1,16 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 33
toc_title: "G\xFCnl\xFCk"
---
# Günlük {#log}
Motor günlük motorları ailesine aittir. Günlük motorlarının ortak özelliklerini ve farklılıklarını görün [Log Engine Ailesi](log_family.md) makale.
Log differsar differsit fromma [TinyLog](tinylog.md) bu küçük bir dosyada “marks” sütun dosyaları ile bulunur. Bu işaretler her veri bloğuna yazılır ve belirtilen satır sayısını atlamak için dosyayı okumaya nereden başlayacağınızı gösteren uzaklıklar içerir. Bu, tablo verilerini birden çok iş parçacığında okumayı mümkün kılar.
Eşzamanlı veri erişimi için, okuma işlemleri aynı anda gerçekleştirilebilirken, yazma işlemleri okur ve birbirlerini engeller.
Günlük altyapısı dizinleri desteklemez. Benzer şekilde, bir tabloya yazma başarısız olursa, tablo bozulur ve Okuma bir hata döndürür. Günlük altyapısı, geçici veriler, bir kez yazma tabloları ve sınama veya gösteri amaçları için uygundur.
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/log/) <!--hide-->

46
docs/tr/engines/table_engines/log_family/log_family.md Normal file
View File

@ -0,0 +1,46 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 31
toc_title: "Giri\u015F"
---
# Log Engine Ailesi {#log-engine-family}
Bu motorlar, birçok küçük tabloyu (yaklaşık 1 milyon satıra kadar) hızlı bir şekilde yazmanız ve daha sonra bir bütün olarak okumanız gerektiğinde senaryolar için geliştirilmiştir.
Ailenin motorları:
- [StripeLog](stripelog.md)
- [Günlük](log.md)
- [TinyLog](tinylog.md)
## Ortak Özellikler {#common-properties}
Motorlar:
- Verileri bir diskte saklayın.
- Yazarken dosyanın sonuna veri ekleyin.
- Eşzamanlı veri erişimi için destek kilitleri.
Sırasında `INSERT` sorgular, tablo kilitlenir ve veri okumak ve yazmak için diğer sorgular hem tablonun kilidini açmak için bekler. Veri yazma sorguları varsa, herhangi bir sayıda veri okuma sorguları aynı anda gerçekleştirilebilir.
- Destek yok [mutasyon](../../../sql_reference/statements/alter.md#alter-mutations) harekat.
- Dizinleri desteklemez.
Bu demektir ki `SELECT` veri aralıkları için sorgular verimli değildir.
- Atomik veri yazmayın.
Bir şey yazma işlemini bozarsa, örneğin anormal sunucu kapatma gibi bozuk verilerle bir tablo alabilirsiniz.
## Farklılıklar {#differences}
Bu `TinyLog` motor, ailenin en basitidir ve en fakir işlevselliği ve en düşük verimliliği sağlar. Bu `TinyLog` motor, birkaç iş parçacığı tarafından paralel veri okumayı desteklemez. Paralel okumayı destekleyen ailedeki diğer motorlardan daha yavaş veri okur ve neredeyse birçok tanımlayıcı kullanır `Log` motor, her sütunu ayrı bir dosyada sakladığı için. Basit düşük yük senaryolarında kullanın.
Bu `Log` ve `StripeLog` motorlar paralel veri okumayı destekler. Veri okurken, ClickHouse birden çok iş parçacığı kullanır. Her iş parçacığı ayrı bir veri bloğu işler. Bu `Log` engine, tablonun her sütunu için ayrı bir dosya kullanır. `StripeLog` tüm verileri tek bir dosyada saklar. Sonuç olarak, `StripeLog` motor işletim sisteminde daha az tanımlayıcı kullanır, ancak `Log` motor veri okurken daha yüksek verimlilik sağlar.
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/log_family/) <!--hide-->

95
docs/tr/engines/table_engines/log_family/stripelog.md Normal file
View File

@ -0,0 +1,95 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 32
toc_title: StripeLog
---
# Stripelog {#stripelog}
Bu motor günlük motor ailesine aittir. Günlük motorlarının ortak özelliklerini ve farklılıklarını görün [Log Engine Ailesi](log_family.md) makale.
Az miktarda veri içeren (1 milyondan az satır) birçok tablo yazmanız gerektiğinde, bu altyapıyı senaryolarda kullanın.
## Tablo oluşturma {#table_engines-stripelog-creating-a-table}
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
column1_name [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
column2_name [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE = StripeLog
```
Ayrıntılı açıklamasına bakın [CREATE TABLE](../../../sql_reference/statements/create.md#create-table-query) sorgu.
## Veri yazma {#table_engines-stripelog-writing-the-data}
Bu `StripeLog` motor tüm sütunları tek bir dosyada saklar. Her biri için `INSERT` sorgu, ClickHouse veri bloğunu bir tablo dosyasının sonuna ekler, sütunları tek tek yazar.
Her tablo için ClickHouse dosyaları yazar:
- `data.bin` — Data file.
- `index.mrk` — File with marks. Marks contain offsets for each column of each data block inserted.
Bu `StripeLog` motor desteklemiyor `ALTER UPDATE` ve `ALTER DELETE` harekat.
## Verileri okuma {#table_engines-stripelog-reading-the-data}
İşaretli dosya, Clickhouse'un verilerin okunmasını paralelleştirmesine izin verir. Bu demektir `SELECT` sorgu satırları öngörülemeyen bir sırayla döndürür. Kullan... `ORDER BY` satırları sıralamak için yan tümce.
## Kullanım Örneği {#table_engines-stripelog-example-of-use}
Tablo oluşturma:
``` sql
CREATE TABLE stripe_log_table
(
timestamp DateTime,
message_type String,
message String
)
ENGINE = StripeLog
```
Veri ekleme:
``` sql
INSERT INTO stripe_log_table VALUES (now(),'REGULAR','The first regular message')
INSERT INTO stripe_log_table VALUES (now(),'REGULAR','The second regular message'),(now(),'WARNING','The first warning message')
```
İki kullandık `INSERT` içinde iki veri bloğu oluşturmak için sorgular `data.bin` Dosya.
ClickHouse veri seçerken birden çok iş parçacığı kullanır. Her iş parçacığı ayrı bir veri bloğu okur ve sonuç olarak satırları bağımsız olarak döndürür. Sonuç olarak, çıktıdaki satır bloklarının sırası, çoğu durumda girişteki aynı blokların sırasına uymuyor. Mesela:
``` sql
SELECT * FROM stripe_log_table
```
``` text
┌───────────timestamp─┬─message_type─┬─message────────────────────┐
│ 2019-01-18 14:27:32 │ REGULAR │ The second regular message │
│ 2019-01-18 14:34:53 │ WARNING │ The first warning message │
└─────────────────────┴──────────────┴────────────────────────────┘
┌───────────timestamp─┬─message_type─┬─message───────────────────┐
│ 2019-01-18 14:23:43 │ REGULAR │ The first regular message │
└─────────────────────┴──────────────┴───────────────────────────┘
```
Sonuçları sıralama (varsayılan olarak artan sipariş):
``` sql
SELECT * FROM stripe_log_table ORDER BY timestamp
```
``` text
┌───────────timestamp─┬─message_type─┬─message────────────────────┐
│ 2019-01-18 14:23:43 │ REGULAR │ The first regular message │
│ 2019-01-18 14:27:32 │ REGULAR │ The second regular message │
│ 2019-01-18 14:34:53 │ WARNING │ The first warning message │
└─────────────────────┴──────────────┴────────────────────────────┘
```
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/stripelog/) <!--hide-->

16
docs/tr/engines/table_engines/log_family/tinylog.md Normal file
View File

@ -0,0 +1,16 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 34
toc_title: TinyLog
---
# TinyLog {#tinylog}
Motor log engine ailesine aittir. Görmek [Log Engine Ailesi](log_family.md) günlük motorlarının ortak özellikleri ve farklılıkları için.
Bu tablo motoru genellikle write-once yöntemi ile kullanılır: verileri bir kez yazın, ardından gerektiği kadar okuyun. Örneğin, kullanabilirsiniz `TinyLog`- küçük gruplar halinde işlenen Ara veriler için tablolar yazın. Çok sayıda küçük tabloda veri depolamanın verimsiz olduğunu unutmayın.
Sorgular tek bir akışta yürütülür. Başka bir deyişle, bu motor nispeten küçük tablolar için tasarlanmıştır (yaklaşık 1.000.000 satıra kadar). Çok sayıda küçük tablonuz varsa, bu tablo motorunu kullanmak mantıklıdır, çünkü [Günlük](log.md) motor (daha az dosya açılması gerekir).
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/tinylog/) <!--hide-->

102
docs/tr/engines/table_engines/mergetree_family/aggregatingmergetree.md Normal file
View File

@ -0,0 +1,102 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 35
toc_title: AggregatingMergeTree
---
# Aggregatingmergetree {#aggregatingmergetree}
Motor devralır [MergeTree](mergetree.md#table_engines-mergetree), veri parçaları birleştirme mantığı değiştirme. ClickHouse, tüm satırları aynı birincil anahtarla değiştirir (veya daha doğru olarak, aynı [sıralama anahtarı](mergetree.md)) tek bir satırla (bir veri parçası içinde), toplama işlevlerinin durumlarının bir kombinasyonunu saklar.
Kullanabilirsiniz `AggregatingMergeTree` artımlı veri toplama, toplanan materialized görünümleri de dahil olmak üzere tablolar.
Motor tüm sütunları ile işler [AggregateFunction](../../../sql_reference/data_types/aggregatefunction.md) tür.
Kullanmak uygundur `AggregatingMergeTree` siparişlere göre satır sayısını azaltırsa.
## Tablo oluşturma {#creating-a-table}
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE = AggregatingMergeTree()
[PARTITION BY expr]
[ORDER BY expr]
[SAMPLE BY expr]
[TTL expr]
[SETTINGS name=value, ...]
```
İstek parametrelerinin açıklaması için bkz. [istek açıklaması](../../../sql_reference/statements/create.md).
**Sorgu yan tümceleri**
Oluştururken bir `AggregatingMergeTree` tablo aynı [yanlar](mergetree.md) oluşturul ,urken olduğu gibi gerekli `MergeTree` Tablo.
<details markdown="1">
<summary>Bir tablo oluşturmak için kullanımdan kaldırılan yöntem</summary>
!!! attention "Dikkat"
Bu yöntemi yeni projelerde kullanmayın ve mümkünse eski projeleri yukarıda açıklanan yönteme geçin.
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE [=] AggregatingMergeTree(date-column [, sampling_expression], (primary, key), index_granularity)
```
Tüm parametreler, aşağıdaki gibi aynı anlama sahiptir `MergeTree`.
</details>
## Seç ve Ekle {#select-and-insert}
Veri eklemek için şunları kullanın [INSERT SELECT](../../../sql_reference/statements/insert_into.md) agrega-Devlet-fonksiyonları ile sorgu.
Veri seçerken `AggregatingMergeTree` tablo kullanın `GROUP BY` yan tümce ve veri eklerken aynı toplama işlevleri, ancak kullanarak `-Merge` sonek.
Sonuç inlarında `SELECT` sorgu, değerleri `AggregateFunction` türü, Tüm ClickHouse çıktı biçimleri için uygulamaya özgü ikili gösterime sahiptir. Örneğin, veri dökümü, `TabSeparated` ile format `SELECT` sorgu daha sonra bu dökümü kullanarak geri yüklenebilir `INSERT` sorgu.
## Toplu bir Somutlaştırılmış Görünüm örneği {#example-of-an-aggregated-materialized-view}
`AggregatingMergeTree` saatler hayata görünüm `test.visits` Tablo:
``` sql
CREATE MATERIALIZED VIEW test.basic
ENGINE = AggregatingMergeTree() PARTITION BY toYYYYMM(StartDate) ORDER BY (CounterID, StartDate)
AS SELECT
CounterID,
StartDate,
sumState(Sign) AS Visits,
uniqState(UserID) AS Users
FROM test.visits
GROUP BY CounterID, StartDate;
```
Veri ekleme `test.visits` Tablo.
``` sql
INSERT INTO test.visits ...
```
Veriler hem tablo hem de görünümde eklenir `test.basic` toplama işlemini gerçekleştir .ecektir.
Toplanan verileri almak için, aşağıdaki gibi bir sorgu yürütmemiz gerekir `SELECT ... GROUP BY ...` görünüm fromden `test.basic`:
``` sql
SELECT
StartDate,
sumMerge(Visits) AS Visits,
uniqMerge(Users) AS Users
FROM test.basic
GROUP BY StartDate
ORDER BY StartDate;
```
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/aggregatingmergetree/) <!--hide-->

309
docs/tr/engines/table_engines/mergetree_family/collapsingmergetree.md Normal file
View File

@ -0,0 +1,309 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 36
toc_title: CollapsingMergeTree
---
# CollapsingMergeTree {#table_engine-collapsingmergetree}
Motor devralır [MergeTree](mergetree.md) ve veri parçaları birleştirme algoritmasına çöken satırların mantığını ekler.
`CollapsingMergeTree` sıralama anahtarındaki tüm alanlar zaman uyumsuz olarak siler (daraltır) satır çiftleri (`ORDER BY`) belirli alan hariç eşdeğerdir `Sign` hangi olabilir `1` ve `-1` değerler. Çift olmayan satırlar tutulur. Daha fazla bilgi için bkz: [Çökme](#table_engine-collapsingmergetree-collapsing) belgenin bölümü.
Motor depolama hacmini önemli ölçüde azaltabilir ve `SELECT` sonuç olarak sorgu.
## Tablo oluşturma {#creating-a-table}
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE = CollapsingMergeTree(sign)
[PARTITION BY expr]
[ORDER BY expr]
[SAMPLE BY expr]
[SETTINGS name=value, ...]
```
Sorgu parametrelerinin açıklaması için bkz. [sorgu açıklaması](../../../sql_reference/statements/create.md).
**CollapsingMergeTree Parametreleri**
- `sign` — Name of the column with the type of row: `1` is a “state” satır, `-1` is a “cancel” satır.
Column data type — `Int8`.
**Sorgu yan tümceleri**
Oluştururken bir `CollapsingMergeTree` tablo, aynı [sorgu yan tümceleri](mergetree.md#table_engine-mergetree-creating-a-table) oluşturul ,urken olduğu gibi gerekli `MergeTree` Tablo.
<details markdown="1">
<summary>Bir tablo oluşturmak için kullanımdan kaldırılan yöntem</summary>
!!! attention "Dikkat"
Bu yöntemi yeni projelerde kullanmayın ve mümkünse eski projeleri yukarıda açıklanan yönteme geçin.
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE [=] CollapsingMergeTree(date-column [, sampling_expression], (primary, key), index_granularity, sign)
```
Hariç tüm parametreler `sign` içinde olduğu gibi aynı anlama sahip `MergeTree`.
- `sign` — Name of the column with the type of row: `1` — “state” satır, `-1` — “cancel” satır.
Column Data Type — `Int8`.
</details>
## Çökme {#table_engine-collapsingmergetree-collapsing}
### Veriler {#data}
Bazı nesneler için sürekli değişen verileri kaydetmeniz gereken durumu düşünün. Bir nesne için bir satıra sahip olmak ve herhangi bir değişiklikte güncellemek mantıklı geliyor, ancak güncelleme işlemi dbms için pahalı ve yavaş çünkü depolama alanındaki verilerin yeniden yazılmasını gerektiriyor. Verileri hızlı bir şekilde yazmanız gerekiyorsa, güncelleme kabul edilemez, ancak bir nesnenin değişikliklerini sırayla aşağıdaki gibi yazabilirsiniz.
Belirli sütunu kullanın `Sign`. Eğer `Sign = 1` bu, satırın bir nesnenin durumu olduğu anlamına gelir, diyelim ki “state” satır. Eğer `Sign = -1` aynı özelliklere sahip bir nesnenin durumunun iptali anlamına gelir, diyelim ki “cancel” satır.
Örneğin, kullanıcıların bazı sitelerde ne kadar sayfa kontrol ettiğini ve ne kadar süre orada olduklarını hesaplamak istiyoruz. Bir anda kullanıcı etkinliği durumu ile aşağıdaki satırı yazıyoruz:
``` text
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │ 5 │ 146 │ 1 │
└─────────────────────┴───────────┴──────────┴──────┘
```
Bir an sonra kullanıcı aktivitesinin değişikliğini kaydedip aşağıdaki iki satırla yazıyoruz.
``` text
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │ 5 │ 146 │ -1 │
│ 4324182021466249494 │ 6 │ 185 │ 1 │
└─────────────────────┴───────────┴──────────┴──────┘
```
İlk satır, nesnenin (kullanıcı) önceki durumunu iptal eder. İptal edilen durumun sıralama anahtar alanlarını kopyalamalıdır `Sign`.
İkinci satır geçerli durumu içerir.
Sadece kullanıcı etkinliğinin son durumuna ihtiyacımız olduğu için, satırlar
``` text
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │ 5 │ 146 │ 1 │
│ 4324182021466249494 │ 5 │ 146 │ -1 │
└─────────────────────┴───────────┴──────────┴──────┘
```
bir nesnenin geçersiz (eski) durumunu daraltarak silinebilir. `CollapsingMergeTree` veri parçalarının birleştirilmesi sırasında bunu yapar.
Neden her değişiklik için 2 satıra ihtiyacımız var [Algoritma](#table_engine-collapsingmergetree-collapsing-algorithm) paragraf.
**Bu yaklaşımın kendine özgü özellikleri**
1. Verileri yazan program, iptal edebilmek için bir nesnenin durumunu hatırlamalıdır. “Cancel” dize, sıralama anahtar alanlarının kopyalarını içermelidir. “state” dize ve tersi `Sign`. Bu depolama başlangıç boyutunu artırır ama hızlı bir şekilde veri yazmak için izin verir.
2. Sütunlardaki uzun büyüyen diziler, yazma yükü nedeniyle motorun verimliliğini azaltır. Daha basit veriler, verimlilik o kadar yüksek olur.
3. Bu `SELECT` sonuçlara itiraz değişiklikler tarihin tutarlılık bağlıdır. Ekleme için veri hazırlarken doğru olun. Tutarsız verilerde öngörülemeyen sonuçlar elde edebilirsiniz, örneğin, oturum derinliği gibi negatif olmayan metrikler için negatif değerler.
### Algoritma {#table_engine-collapsingmergetree-collapsing-algorithm}
ClickHouse veri parçalarını birleştirdiğinde, her ardışık satır grubu aynı sıralama anahtarıyla (`ORDER BY`) en fazla iki satır reduceda indir isgen ,ir, biri `Sign = 1` (“state” satır) ve başka bir `Sign = -1` (“cancel” satır). Başka bir deyişle, girişler çöker.
Elde edilen her veri parçası için ClickHouse kaydeder:
1. Birincilik “cancel” ve son “state” satır sayısı ise “state” ve “cancel” satırlar eşleşir ve son satır bir “state” satır.
2. Son “state” satır, daha varsa “state” satırlar daha “cancel” satırlar.
3. Birincilik “cancel” satır, daha varsa “cancel” satırlar daha “state” satırlar.
4. Diğer tüm durumlarda satırların hiçbiri.
Ayrıca en az 2 tane daha olduğunda “state” satırlar daha “cancel” satırlar veya en az 2 tane daha “cancel” r rowsows th thenen “state” satırlar, birleştirme devam eder, ancak ClickHouse bu durumu mantıksal bir hata olarak değerlendirir ve sunucu günlüğüne kaydeder. Aynı veriler birden çok kez eklendiğinde, bu hata oluşabilir.
Bu nedenle, çöken istatistik hesaplama sonuçlarını değiştirmemelidir.
Değişiklikler yavaş yavaş çöktü, böylece sonunda hemen hemen her nesnenin sadece son durumu kaldı.
Bu `Sign` birleştirme algoritması, aynı sıralama anahtarına sahip tüm satırların aynı sonuçtaki veri bölümünde ve hatta aynı fiziksel sunucuda olacağını garanti etmediğinden gereklidir. ClickHouse süreci `SELECT` birden çok iş parçacığına sahip sorgular ve sonuçtaki satırların sırasını tahmin edemez. Tamamen almak için bir ihtiyaç varsa toplama gereklidir “collapsed” veri `CollapsingMergeTree` Tablo.
Daraltmayı sonuçlandırmak için bir sorgu yazın `GROUP BY` yan tümce ve işareti için hesap toplama işlevleri. Örneğin, miktarı hesaplamak için kullanın `sum(Sign)` yerine `count()`. Bir şeyin toplamını hesaplamak için şunları kullanın `sum(Sign * x)` yerine `sum(x)`, ve böylece, ve ayrıca ekleyin `HAVING sum(Sign) > 0`.
Toplanan `count`, `sum` ve `avg` bu şekilde hesaplanmış olabilir. Toplanan `uniq` bir nesnenin en az bir durumu çökmüş değilse hesaplanabilir. Toplanan `min` ve `max` hesaplan becauseamadı çünkü `CollapsingMergeTree` daraltılmış durumların değerleri geçmişini kaydetmez.
Toplama olmadan veri ayıklamanız gerekiyorsa (örneğin, en yeni değerleri belirli koşullarla eşleşen satırların mevcut olup olmadığını kontrol etmek için) `FINAL` değiştirici için `FROM` yan. Bu yaklaşım önemli ölçüde daha az etkilidir.
## Kullanım Örneği {#example-of-use}
Örnek veriler:
``` text
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │ 5 │ 146 │ 1 │
│ 4324182021466249494 │ 5 │ 146 │ -1 │
│ 4324182021466249494 │ 6 │ 185 │ 1 │
└─────────────────────┴───────────┴──────────┴──────┘
```
Tablonun oluşturulması:
``` sql
CREATE TABLE UAct
(
UserID UInt64,
PageViews UInt8,
Duration UInt8,
Sign Int8
)
ENGINE = CollapsingMergeTree(Sign)
ORDER BY UserID
```
Veri ekleme:
``` sql
INSERT INTO UAct VALUES (4324182021466249494, 5, 146, 1)
```
``` sql
INSERT INTO UAct VALUES (4324182021466249494, 5, 146, -1),(4324182021466249494, 6, 185, 1)
```
Biz iki kullanın `INSERT` iki farklı veri parçası oluşturmak için sorgular. Verileri bir sorgu ile eklersek ClickHouse bir veri parçası oluşturur ve hiç bir birleştirme gerçekleştirmez.
Veri alma:
``` sql
SELECT * FROM UAct
```
``` text
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │ 5 │ 146 │ -1 │
│ 4324182021466249494 │ 6 │ 185 │ 1 │
└─────────────────────┴───────────┴──────────┴──────┘
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │ 5 │ 146 │ 1 │
└─────────────────────┴───────────┴──────────┴──────┘
```
Ne görüyoruz ve nerede çöküyor?
İki ile `INSERT` sorgular, 2 Veri parçası oluşturduk. Bu `SELECT` sorgu 2 iş parçacığında yapıldı ve rastgele bir satır sırası aldık. Veri parçalarının henüz birleştirilmediği için çökme gerçekleşmedi. ClickHouse biz tahmin edemez bilinmeyen bir anda veri kısmını birleştirir.
Böylece toplama ihtiyacımız var:
``` sql
SELECT
UserID,
sum(PageViews * Sign) AS PageViews,
sum(Duration * Sign) AS Duration
FROM UAct
GROUP BY UserID
HAVING sum(Sign) > 0
```
``` text
┌──────────────UserID─┬─PageViews─┬─Duration─┐
│ 4324182021466249494 │ 6 │ 185 │
└─────────────────────┴───────────┴──────────┘
```
Toplamaya ihtiyacımız yoksa ve çökmeyi zorlamak istiyorsak, şunları kullanabiliriz `FINAL` değiştirici için `FROM` yan.
``` sql
SELECT * FROM UAct FINAL
```
``` text
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │ 6 │ 185 │ 1 │
└─────────────────────┴───────────┴──────────┴──────┘
```
Verileri seçmenin bu yolu çok verimsizdir. Büyük masalar için kullanmayın.
## Başka Bir Yaklaşım Örneği {#example-of-another-approach}
Örnek veriler:
``` text
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │ 5 │ 146 │ 1 │
│ 4324182021466249494 │ -5 │ -146 │ -1 │
│ 4324182021466249494 │ 6 │ 185 │ 1 │
└─────────────────────┴───────────┴──────────┴──────┘
```
Fikir, birleştirmelerin yalnızca anahtar alanları hesaba katmasıdır. Ve içinde “Cancel” satır işareti sütununu kullanmadan toplanırken satırın önceki sürümünü eşitleyen negatif değerleri belirtebiliriz. Bu yaklaşım için veri türünü değiştirmek gerekir `PageViews`,`Duration` uint8 -\> Int16 negatif değerlerini saklamak için.
``` sql
CREATE TABLE UAct
(
UserID UInt64,
PageViews Int16,
Duration Int16,
Sign Int8
)
ENGINE = CollapsingMergeTree(Sign)
ORDER BY UserID
```
Yaklaşımı test edelim:
``` sql
insert into UAct values(4324182021466249494, 5, 146, 1);
insert into UAct values(4324182021466249494, -5, -146, -1);
insert into UAct values(4324182021466249494, 6, 185, 1);
select * from UAct final; // avoid using final in production (just for a test or small tables)
```
``` text
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │ 6 │ 185 │ 1 │
└─────────────────────┴───────────┴──────────┴──────┘
```
``` sql
SELECT
UserID,
sum(PageViews) AS PageViews,
sum(Duration) AS Duration
FROM UAct
GROUP BY UserID
```text
┌──────────────UserID─┬─PageViews─┬─Duration─┐
│ 4324182021466249494 │ 6 │ 185 │
└─────────────────────┴───────────┴──────────┘
```
``` sqk
select count() FROM UAct
```
``` text
┌─count()─┐
│ 3 │
└─────────┘
```
``` sql
optimize table UAct final;
select * FROM UAct
```
``` text
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │ 6 │ 185 │ 1 │
└─────────────────────┴───────────┴──────────┴──────┘
```
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/collapsingmergetree/) <!--hide-->

127
docs/tr/engines/table_engines/mergetree_family/custom_partitioning_key.md Normal file
View File

@ -0,0 +1,127 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 32
toc_title: "\xD6zel B\xF6l\xFCmleme Anahtar\u0131"
---
# Özel Bölümleme Anahtarı {#custom-partitioning-key}
Bölümleme için kullanılabilir [MergeTree](mergetree.md) aile tabloları (dahil [çoğaltıyordu](replication.md) Tablolar). [Hayata görünümler](../special/materializedview.md) MergeTree tablolarına dayanarak bölümlemeyi de destekler.
Bir bölüm, bir tablodaki kayıtların belirtilen bir kritere göre mantıksal bir birleşimidir. Bir bölümü, ay, gün veya olay türü gibi rasgele bir ölçütle ayarlayabilirsiniz. Bu verilerin manipülasyonlarını basitleştirmek için her bölüm ayrı ayrı saklanır. Verilere erişirken, ClickHouse mümkün olan en küçük bölüm alt kümesini kullanır.
Bölüm belirtilen `PARTITION BY expr` fık whenra ne zaman [tablo oluşturma](mergetree.md#table_engine-mergetree-creating-a-table). Bölüm anahtarı tablo sütunlarından herhangi bir ifade olabilir. Örneğin, aya göre bölümleme belirtmek için ifadeyi kullanın `toYYYYMM(date_column)`:
``` sql
CREATE TABLE visits
(
VisitDate Date,
Hour UInt8,
ClientID UUID
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(VisitDate)
ORDER BY Hour;
```
Bölüm anahtarı ayrıca bir ifade kümesi olabilir ( [birincil anahtar](mergetree.md#primary-keys-and-indexes-in-queries)). Mesela:
``` sql
ENGINE = ReplicatedCollapsingMergeTree('/clickhouse/tables/name', 'replica1', Sign)
PARTITION BY (toMonday(StartDate), EventType)
ORDER BY (CounterID, StartDate, intHash32(UserID));
```
Bu örnekte, bölümlemeyi geçerli hafta boyunca meydana gelen olay türlerine göre ayarladık.
Bir tabloya yeni veri eklerken, bu veriler birincil anahtara göre sıralanmış ayrı bir parça (yığın) olarak depolanır. Taktıktan 10-15 dakika sonra, aynı bölümün parçaları tüm parçaya birleştirilir.
!!! info "Bilgin"
Birleştirme yalnızca bölümleme ifadesi için aynı değere sahip veri parçaları için çalışır. Bu demektir **aşırı granüler bölümler yapmamalısınız** (yaklaşık binden fazla bölüm). Aksi takdirde, `SELECT` sorgu, dosya sistemindeki ve açık dosya tanımlayıcılarındaki makul olmayan sayıda dosya nedeniyle yetersiz performans gösterir.
Kullan... [sistem.parçalar](../../../operations/system_tables.md#system_tables-parts) tablo tablo parçaları ve bölümleri görüntülemek için. Örneğin, bir var varsayalım `visits` aya göre bölümleme ile tablo. Hadi gerçekleştirelim `SELECT` sorgu için `system.parts` Tablo:
``` sql
SELECT
partition,
name,
active
FROM system.parts
WHERE table = 'visits'
```
``` text
┌─partition─┬─name───────────┬─active─┐
│ 201901 │ 201901_1_3_1 │ 0 │
│ 201901 │ 201901_1_9_2 │ 1 │
│ 201901 │ 201901_8_8_0 │ 0 │
│ 201901 │ 201901_9_9_0 │ 0 │
│ 201902 │ 201902_4_6_1 │ 1 │
│ 201902 │ 201902_10_10_0 │ 1 │
│ 201902 │ 201902_11_11_0 │ 1 │
└───────────┴────────────────┴────────┘
```
Bu `partition` sütun bölümlerin adlarını içerir. Bu örnekte iki bölüm vardır: `201901` ve `201902`. Bölüm adını belirtmek için bu sütun değerini kullanabilirsiniz [ALTER … PARTITION](#alter_manipulations-with-partitions) sorgular.
Bu `name` sütun, bölüm veri parçalarının adlarını içerir. Bölümün adını belirtmek için bu sütunu kullanabilirsiniz. [ALTER ATTACH PART](#alter_attach-partition) sorgu.
İlk bölümün adını kıralım: `201901_1_3_1`:
- `201901` bölüm adıdır.
- `1` en az veri bloğu sayısıdır.
- `3` veri bloğunun maksimum sayısıdır.
- `1` yığın düzeyidir (oluşturduğu birleştirme ağacının derinliği).
!!! info "Bilgin"
Eski tip tabloların parçaları adı vardır: `20190117_20190123_2_2_0` (minimum tarih - maksimum tarih - minimum blok numarası - maksimum blok numarası - seviye).
Bu `active` sütun, parçanın durumunu gösterir. `1` aktif istir; `0` etkin değil. Etkin olmayan parçalar, örneğin, daha büyük bir parçaya birleştirildikten sonra kalan kaynak parçalarıdır. Bozuk veri parçaları da etkin olarak gösterilir.
Örnekte gördüğünüz gibi, aynı bölümün birkaç ayrı parçası vardır (örneğin, `201901_1_3_1` ve `201901_1_9_2`). Bu, bu parçaların henüz birleştirilmediği anlamına gelir. ClickHouse, eklendikten yaklaşık 15 dakika sonra eklenen veri parçalarını periyodik olarak birleştirir. Buna ek olarak, kullanarak zamanlanmış olmayan birleştirme gerçekleştirebilirsiniz [OPTIMIZE](../../../sql_reference/statements/misc.md#misc_operations-optimize) sorgu. Örnek:
``` sql
OPTIMIZE TABLE visits PARTITION 201902;
```
``` text
┌─partition─┬─name───────────┬─active─┐
│ 201901 │ 201901_1_3_1 │ 0 │
│ 201901 │ 201901_1_9_2 │ 1 │
│ 201901 │ 201901_8_8_0 │ 0 │
│ 201901 │ 201901_9_9_0 │ 0 │
│ 201902 │ 201902_4_6_1 │ 0 │
│ 201902 │ 201902_4_11_2 │ 1 │
│ 201902 │ 201902_10_10_0 │ 0 │
│ 201902 │ 201902_11_11_0 │ 0 │
└───────────┴────────────────┴────────┘
```
Etkin olmayan parçalar birleştirildikten yaklaşık 10 dakika sonra silinecektir.
Bir parça ve bölüm kümesini görüntülemenin başka bir yolu da tablonun dizinine gitmektir: `/var/lib/clickhouse/data/<database>/<table>/`. Mesela:
``` bash
/var/lib/clickhouse/data/default/visits$ ls -l
total 40
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 1 16:48 201901_1_3_1
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 16:17 201901_1_9_2
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 15:52 201901_8_8_0
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 15:52 201901_9_9_0
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 16:17 201902_10_10_0
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 16:17 201902_11_11_0
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 16:19 201902_4_11_2
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 5 12:09 201902_4_6_1
drwxr-xr-x 2 clickhouse clickhouse 4096 Feb 1 16:48 detached
```
Klasör ‘201901\_1\_1\_0’, ‘201901\_1\_7\_1’ ve böylece parçaların dizinleri vardır. Her bölüm karşılık gelen bir bölümle ilgilidir ve yalnızca belirli bir ay için veri içerir (Bu örnekteki tabloda aylara göre bölümleme vardır).
Bu `detached` dizin kullanarak tablodan ayrılmış parçaları içerir [DETACH](#alter_detach-partition) sorgu. Bozuk parçalar da silinmek yerine bu dizine taşınır. Sunucu parçaları kullanmaz `detached` directory. You can add, delete, or modify the data in this directory at any time – the server will not know about this until you run the [ATTACH](../../../sql_reference/statements/alter.md#alter_attach-partition) sorgu.
İşletim sunucusunda, sunucu bunu bilmediğinden, dosya sistemindeki parça kümesini veya verilerini el ile değiştiremeyeceğinizi unutmayın. Çoğaltılmamış tablolar için, sunucu durdurulduğunda bunu yapabilirsiniz, ancak önerilmez. Çoğaltılmış tablolar için, parça kümesi her durumda değiştirilemez.
ClickHouse, bölümlerle işlemleri gerçekleştirmenize izin verir: bunları silin, bir tablodan diğerine kopyalayın veya bir yedek oluşturun. Bölümdeki tüm işlemlerin listesine bakın [Bölümler ve parçalar ile manipülasyonlar](../../../sql_reference/statements/alter.md#alter_manipulations-with-partitions).
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/custom_partitioning_key/) <!--hide-->

174
docs/tr/engines/table_engines/mergetree_family/graphitemergetree.md Normal file
View File

@ -0,0 +1,174 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 38
toc_title: "Graph\u0131temergetree"
---
# Graphıtemergetree {#graphitemergetree}
Bu motor inceltme ve toplama/ortalama (toplaması) için tasarlanmıştır) [Grafit](http://graphite.readthedocs.io/en/latest/index.html) veriler. Clickhouse'u Grafit için bir veri deposu olarak kullanmak isteyen geliştiriciler için yararlı olabilir.
Toplamaya ihtiyacınız yoksa Grafit verilerini depolamak için herhangi bir ClickHouse tablo motorunu kullanabilirsiniz, ancak bir toplamaya ihtiyacınız varsa `GraphiteMergeTree`. Motor, depolama hacmini azaltır ve grafitten gelen sorguların verimliliğini arttırır.
Motor özellikleri devralır [MergeTree](mergetree.md).
## Tablo oluşturma {#creating-table}
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
Path String,
Time DateTime,
Value <Numeric_type>,
Version <Numeric_type>
...
) ENGINE = GraphiteMergeTree(config_section)
[PARTITION BY expr]
[ORDER BY expr]
[SAMPLE BY expr]
[SETTINGS name=value, ...]
```
Ayrıntılı bir açıklamasını görmek [CREATE TABLE](../../../sql_reference/statements/create.md#create-table-query) sorgu.
Grafit verileri için bir tablo aşağıdaki veriler için aşağıdaki sütunlara sahip olmalıdır:
- Metrik adı (Grafit sensörü). Veri türü: `String`.
- Metrik ölçme zamanı. Veri türü: `DateTime`.
- Metrik değeri. Veri türü: herhangi bir sayısal.
- Metrik sürümü. Veri türü: herhangi bir sayısal.
ClickHouse en yüksek sürümü veya sürümleri aynı ise son yazılan satırları kaydeder. Veri parçalarının birleştirilmesi sırasında diğer satırlar silinir.
Bu sütunların adları toplaması yapılandırmasında ayarlanmalıdır.
**Graphıtemergetree parametreleri**
- `config_section` — Name of the section in the configuration file, where are the rules of rollup set.
**Sorgu yan tümceleri**
Oluştururken bir `GraphiteMergeTree` tablo, aynı [yanlar](mergetree.md#table_engine-mergetree-creating-a-table) oluşturul ,urken olduğu gibi gerekli `MergeTree` Tablo.
<details markdown="1">
<summary>Bir tablo oluşturmak için kullanımdan kaldırılan yöntem</summary>
!!! attention "Dikkat"
Bu yöntemi yeni projelerde kullanmayın ve mümkünse eski projeleri yukarıda açıklanan yönteme geçin.
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
EventDate Date,
Path String,
Time DateTime,
Value <Numeric_type>,
Version <Numeric_type>
...
) ENGINE [=] GraphiteMergeTree(date-column [, sampling_expression], (primary, key), index_granularity, config_section)
```
Hariç tüm parametreler `config_section` içinde olduğu gibi aynı anlama sahip `MergeTree`.
- `config_section` — Name of the section in the configuration file, where are the rules of rollup set.
</details>
## Toplaması Yapılandırması {#rollup-configuration}
Toplaması için ayarları tarafından tanımlanan [graphite\_rollup](../../../operations/server_configuration_parameters/settings.md#server_configuration_parameters-graphite_rollup) sunucu yapılandırmasında parametre. Parametrenin adı herhangi biri olabilir. Birkaç yapılandırma oluşturabilir ve bunları farklı tablolar için kullanabilirsiniz.
Toplaması yapılandırma yapısı:
required-columns
patterns
### Gerekli Sütunlar {#required-columns}
- `path_column_name` — The name of the column storing the metric name (Graphite sensor). Default value: `Path`.
- `time_column_name` — The name of the column storing the time of measuring the metric. Default value: `Time`.
- `value_column_name` — The name of the column storing the value of the metric at the time set in `time_column_name`. Varsayılan değer: `Value`.
- `version_column_name` — The name of the column storing the version of the metric. Default value: `Timestamp`.
### Desenler {#patterns}
Bu yapı `patterns` bölme:
``` text
pattern
regexp
function
pattern
regexp
age + precision
...
pattern
regexp
function
age + precision
...
pattern
...
default
function
age + precision
...
```
!!! warning "Dikkat"
Desenler kesinlikle sipariş edilmelidir:
1. Patterns without `function` or `retention`.
1. Patterns with both `function` and `retention`.
1. Pattern `default`.
Bir satır işlerken, ClickHouse kuralları denetler `pattern` bölmeler. Tüm `pattern` (içeren `default`) bölümler içerebilir `function` toplama için parametre, `retention` parametreler veya her ikisi. Metrik adı eşleşirse `regexp` gelen kuralları `pattern` bölüm (veya bölümler) uygulanır; aksi takdirde, kurallar `default` bölüm kullanılır.
Alanlar için `pattern` ve `default` bölmeler:
- `regexp`– A pattern for the metric name.
- `age` – The minimum age of the data in seconds.
- `precision`– How precisely to define the age of the data in seconds. Should be a divisor for 86400 (seconds in a day).
- `function` – The name of the aggregating function to apply to data whose age falls within the range `[age, age + precision]`.
### Yapılandırma Örneği {#configuration-example}
``` xml
<graphite_rollup>
<version_column_name>Version</version_column_name>
<pattern>
<regexp>click_cost</regexp>
<function>any</function>
<retention>
<age>0</age>
<precision>5</precision>
</retention>
<retention>
<age>86400</age>
<precision>60</precision>
</retention>
</pattern>
<default>
<function>max</function>
<retention>
<age>0</age>
<precision>60</precision>
</retention>
<retention>
<age>3600</age>
<precision>300</precision>
</retention>
<retention>
<age>86400</age>
<precision>3600</precision>
</retention>
</default>
</graphite_rollup>
```
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/graphitemergetree/) <!--hide-->

8
docs/tr/engines/table_engines/mergetree_family/index.md Normal file
View File

@ -0,0 +1,8 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_folder_title: MergeTree Ailesi
toc_priority: 28
---

654
docs/tr/engines/table_engines/mergetree_family/mergetree.md Normal file
View File

@ -0,0 +1,654 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 30
toc_title: MergeTree
---
# MergeTree {#table_engines-mergetree}
Bu `MergeTree` bu ailenin motoru ve diğer motorları (`*MergeTree`) en sağlam ClickHouse masa motorlarıdır.
Motor inlarda `MergeTree` aile, bir tabloya çok büyük miktarda veri eklemek için tasarlanmıştır. Veriler hızlı bir şekilde tabloya kısmen yazılır, daha sonra parçaları arka planda birleştirmek için kurallar uygulanır. Bu yöntem, ınsert sırasında depolama alanındaki verileri sürekli olarak yeniden yazmaktan çok daha etkilidir.
Ana özellikler:
- Birincil anahtara göre sıralanmış verileri saklar.
Bu, verileri daha hızlı bulmanıza yardımcı olan küçük bir seyrek dizin oluşturmanıza olanak sağlar.
- Bölümler eğer kullanılabilir [bölümleme anahtarı](custom_partitioning_key.md) belirt .ilmektedir.
ClickHouse, aynı sonuçla aynı veriler üzerindeki genel işlemlerden daha etkili olan bölümlerle belirli işlemleri destekler. ClickHouse, bölümleme anahtarının sorguda belirtildiği bölüm verilerini de otomatik olarak keser. Bu da sorgu performansını artırır.
- Veri çoğaltma desteği.
The family of `ReplicatedMergeTree` tablolar veri çoğaltma sağlar. Daha fazla bilgi için, bkz. [Veri çoğaltma](replication.md).
- Veri örnekleme desteği.
Gerekirse, tabloda veri örnekleme yöntemini ayarlayabilirsiniz.
!!! info "Bilgin"
Bu [Birleştirmek](../special/merge.md) motor ait değil `*MergeTree` aile.
## Tablo oluşturma {#table_engine-mergetree-creating-a-table}
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1] [TTL expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2] [TTL expr2],
...
INDEX index_name1 expr1 TYPE type1(...) GRANULARITY value1,
INDEX index_name2 expr2 TYPE type2(...) GRANULARITY value2
) ENGINE = MergeTree()
[PARTITION BY expr]
[ORDER BY expr]
[PRIMARY KEY expr]
[SAMPLE BY expr]
[TTL expr [DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'], ...]
[SETTINGS name=value, ...]
```
Parametrelerin açıklaması için bkz. [Sorgu açıklaması oluştur](../../../sql_reference/statements/create.md).
!!! note "Not"
`INDEX` deneysel bir özelliktir, bkz [Veri Atlama Dizinleri](#table_engine-mergetree-data_skipping-indexes).
### Sorgu Yan Tümceleri {#mergetree-query-clauses}
- `ENGINE` — Name and parameters of the engine. `ENGINE = MergeTree()`. Bu `MergeTree` motor parametreleri yok.
- `PARTITION BY` — The [bölümleme anahtarı](custom_partitioning_key.md).
Aylara göre bölümleme için `toYYYYMM(date_column)` ifade, nerede `date_column` türün tarihi olan bir sütun mu [Tarihli](../../../sql_reference/data_types/date.md). Burada bölüm isimleri var `"YYYYMM"` biçimli.
- `ORDER BY` — The sorting key.
Sütun veya keyfi ifadeler bir tuple. Örnek: `ORDER BY (CounterID, EventDate)`.
- `PRIMARY KEY` — The primary key if it [sıralama anahtarından farklıdır](mergetree.md).
Varsayılan olarak, birincil anahtar sıralama anahtarıyla aynıdır (bu anahtar tarafından belirtilir). `ORDER BY` yan). Bu nedenle çoğu durumda ayrı bir belirtmek gereksizdir `PRIMARY KEY` yan.
- `SAMPLE BY` — An expression for sampling.
Bir örnekleme ifadesi kullanılırsa, birincil anahtar onu içermelidir. Örnek: `SAMPLE BY intHash32(UserID) ORDER BY (CounterID, EventDate, intHash32(UserID))`.
- `TTL` — A list of rules specifying storage duration of rows and defining logic of automatic parts movement [diskler ve birimler arasında](#table_engine-mergetree-multiple-volumes).
İfade bir olmalıdır `Date` veya `DateTime` sonuç olarak sütun. Örnek:
`TTL date + INTERVAL 1 DAY`
Kuralın türü `DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'` ifade tatmin edildiyse (geçerli zamana ulaşırsa) parça ile yapılacak bir eylemi belirtir: süresi dolmuş satırların kaldırılması, bir parçanın (bir parçadaki tüm satırlar için ifade tatmin edildiyse) belirtilen diske taşınması (`TO DISK 'xxx'`) veya hacim (`TO VOLUME 'xxx'`). Kuralın varsayılan türü kaldırma (`DELETE`). Birden fazla kural listesi belirtilebilir, ancak birden fazla olmamalıdır `DELETE` kural.
Daha fazla ayrıntı için bkz. [Sütunlar ve tablolar için TTL](#table_engine-mergetree-ttl)
- `SETTINGS` — Additional parameters that control the behavior of the `MergeTree`:
- `index_granularity` — Maximum number of data rows between the marks of an index. Default value: 8192. See [Veri Depolama](#mergetree-data-storage).
- `index_granularity_bytes` — Maximum size of data granules in bytes. Default value: 10Mb. To restrict the granule size only by number of rows, set to 0 (not recommended). See [Veri Depolama](#mergetree-data-storage).
- `enable_mixed_granularity_parts` — Enables or disables transitioning to control the granule size with the `index_granularity_bytes` ayar. 19.11 sürümünden önce, sadece `index_granularity` granül boyutunu kısıtlamak için ayar. Bu `index_granularity_bytes` büyük satırlar (onlarca ve megabayt yüzlerce) ile tablolardan veri seçerken ayarı ClickHouse performansını artırır. Büyük satırlara sahip tablolarınız varsa, tabloların verimliliğini artırmak için bu ayarı etkinleştirebilirsiniz. `SELECT` sorgular.
- `use_minimalistic_part_header_in_zookeeper` — Storage method of the data parts headers in ZooKeeper. If `use_minimalistic_part_header_in_zookeeper=1`, daha sonra ZooKeeper daha az veri depolar. Daha fazla bilgi için, bkz: [ayar açıklaması](../../../operations/server_configuration_parameters/settings.md#server-settings-use_minimalistic_part_header_in_zookeeper) içinde “Server configuration parameters”.
- `min_merge_bytes_to_use_direct_io` — The minimum data volume for merge operation that is required for using direct I/O access to the storage disk. When merging data parts, ClickHouse calculates the total storage volume of all the data to be merged. If the volume exceeds `min_merge_bytes_to_use_direct_io` bayt, ClickHouse okur ve doğrudan I/O arabirimi kullanarak depolama diskine veri yazar (`O_DIRECT` seçenek). Eğer `min_merge_bytes_to_use_direct_io = 0`, sonra doğrudan g / Ç devre dışı bırakılır. Varsayılan değer: `10 * 1024 * 1024 * 1024` baytlar.
<a name="mergetree_setting-merge_with_ttl_timeout"></a>
- `merge_with_ttl_timeout` — Minimum delay in seconds before repeating a merge with TTL. Default value: 86400 (1 day).
- `write_final_mark` — Enables or disables writing the final index mark at the end of data part (after the last byte). Default value: 1. Don't turn it off.
- `merge_max_block_size` — Maximum number of rows in block for merge operations. Default value: 8192.
- `storage_policy` — Storage policy. See [Veri depolama için birden fazla blok cihazı kullanma](#table_engine-mergetree-multiple-volumes).
**Bölüm ayarı örneği**
``` sql
ENGINE MergeTree() PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDate, intHash32(UserID)) SAMPLE BY intHash32(UserID) SETTINGS index_granularity=8192
```
Örnekte, aylara göre bölümleme ayarladık.
Biz de kullanıcı kimliği ile karma olarak örnekleme için bir ifade ayarlayın. Bu, her biri için tablodaki verileri pseudorandomize etmenizi sağlar `CounterID` ve `EventDate`. Tanım yoularsanız bir [SAMPLE](../../../sql_reference/statements/select.md#select-sample-clause) yan tümcesi verileri seçerken, ClickHouse kullanıcıların bir alt kümesi için eşit pseudorandom veri örneği döndürür.
Bu `index_granularity` 8192 varsayılan değer olduğundan ayarı atlanabilir.
<details markdown="1">
<summary>Bir tablo oluşturmak için kullanımdan kaldırılan yöntem</summary>
!!! attention "Dikkat"
Bu yöntemi yeni projelerde kullanmayın. Mümkünse, eski projeleri yukarıda açıklanan yönteme geçin.
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE [=] MergeTree(date-column [, sampling_expression], (primary, key), index_granularity)
```
**MergeTree () Parametreleri**
- `date-column` — The name of a column of the [Tarihli](../../../sql_reference/data_types/date.md) tür. ClickHouse otomatik olarak bu sütuna göre ay bölümleri oluşturur. Bölüm adları `"YYYYMM"` biçimli.
- `sampling_expression` — An expression for sampling.
- `(primary, key)` — Primary key. Type: [Demet()](../../../sql_reference/data_types/tuple.md)
- `index_granularity` — The granularity of an index. The number of data rows between the “marks” bir dizinin. 8192 değeri çoğu görev için uygundur.
**Örnek**
``` sql
MergeTree(EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID)), 8192)
```
Bu `MergeTree` motor, Ana motor yapılandırma yöntemi için yukarıdaki örnekte olduğu gibi yapılandırılır.
</details>
## Veri Depolama {#mergetree-data-storage}
Bir tabloda birincil anahtar tarafından sıralanmış verileri bölümden oluşmaktadır.
Veri bir tabloya eklendiğinde, ayrı veri parçaları oluşturulur ve bunların her biri birincil anahtara göre lexicographically sıralanır. Örneğin, birincil anahtar `(CounterID, Date)`, parçadaki veriler şu şekilde sıralanır `CounterID` ve içinde her `CounterID` tarafından sipariş edilir `Date`.
Farklı bölümlere ait veriler farklı parçalara ayrılır. Arka planda, ClickHouse daha verimli depolama için veri parçalarını birleştirir. Farklı bölümlere ait parçalar birleştirilmez. Birleştirme mekanizması, aynı birincil anahtara sahip tüm satırların aynı veri bölümünde olacağını garanti etmez.
Her veri parçası mantıksal olarak granüllere ayrılmıştır. Bir granül, Clickhouse'un veri seçerken okuduğu en küçük bölünmez veri kümesidir. ClickHouse satırları veya değerleri bölmez, bu nedenle her granül her zaman bir tamsayı satır içerir. Bir granülün ilk satırı, satır için birincil anahtarın değeri ile işaretlenir. Her veri bölümü için ClickHouse işaretleri depolayan bir dizin dosyası oluşturur. Her sütun için, birincil anahtarda olsun ya da olmasın, ClickHouse aynı işaretleri de saklar. Bu işaretler, verileri doğrudan sütun dosyalarında bulmanızı sağlar.
Granül boyutu ile sınırlıdır `index_granularity` ve `index_granularity_bytes` tablo motorunun ayarları. Bir granüldeki satır sayısı `[1, index_granularity]` Aralık, satırların boyutuna bağlı olarak. Bir granülün boyutu aşabilir `index_granularity_bytes` tek bir satırın boyutu ayarın değerinden büyükse. Bu durumda, granülün boyutu satırın boyutuna eşittir.
## Sorgularda birincil anahtarlar ve dizinler {#primary-keys-and-indexes-in-queries}
Tak thee the `(CounterID, Date)` örnek olarak birincil anahtar. Bu durumda, sıralama ve dizin aşağıdaki gibi gösterilebilir:
Whole data: [---------------------------------------------]
CounterID: [aaaaaaaaaaaaaaaaaabbbbcdeeeeeeeeeeeeefgggggggghhhhhhhhhiiiiiiiiikllllllll]
Date: [1111111222222233331233211111222222333211111112122222223111112223311122333]
Marks: | | | | | | | | | | |
a,1 a,2 a,3 b,3 e,2 e,3 g,1 h,2 i,1 i,3 l,3
Marks numbers: 0 1 2 3 4 5 6 7 8 9 10
Veri sorgusu belirtirse:
- `CounterID in ('a', 'h')`, sunucu işaretleri aralıklarında verileri okur `[0, 3)` ve `[6, 8)`.
- `CounterID IN ('a', 'h') AND Date = 3`, sunucu işaretleri aralıklarında verileri okur `[1, 3)` ve `[7, 8)`.
- `Date = 3`, sunucu işaretleri aralığında veri okur `[1, 10]`.
Yukarıdaki örnekler, her zaman bir dizin tam taramadan daha etkili olduğunu göstermektedir.
Seyrek bir dizin, ekstra verilerin okunmasına izin verir. Birincil anahtarın tek bir aralığını okurken, `index_granularity * 2` her veri bloğundaki ekstra satırlar okunabilir.
Seyrek dizinler, çok sayıda tablo satırı ile çalışmanıza izin verir, çünkü çoğu durumda, bu tür dizinler bilgisayarın RAM'İNE sığar.
ClickHouse benzersiz bir birincil anahtar gerektirmez. Aynı birincil anahtar ile birden çok satır ekleyebilirsiniz.
### Birincil anahtar seçme {#selecting-the-primary-key}
Birincil anahtardaki sütun sayısı açıkça sınırlı değildir. Veri yapısına bağlı olarak, birincil anahtara daha fazla veya daha az sütun ekleyebilirsiniz. Bu Mayıs:
- Bir dizin performansını artırın.
Birincil anahtar ise `(a, b)`, sonra başka bir sütun ekleyerek `c` aşağıdaki koşullar yerine getirilirse performansı artıracaktır:
- Sütun üzerinde bir koşulu olan sorgular var `c`.
- Uzun veri aralıkları (birkaç kat daha uzun `index_granularity`) için aynı değer withlerle `(a, b)` yaygındır. Başka bir deyişle, başka bir sütun eklerken oldukça uzun veri aralıklarını atlamanıza izin verir.
- Veri sıkıştırmasını geliştirin.
ClickHouse verileri birincil anahtarla sıralar, bu nedenle tutarlılık ne kadar yüksek olursa sıkıştırma o kadar iyi olur.
- Veri parçalarını birleştirirken ek mantık sağlayın [CollapsingMergeTree](collapsingmergetree.md#table_engine-collapsingmergetree) ve [SummingMergeTree](summingmergetree.md) motorlar.
Bu durumda belirtmek mantıklı *sıralama anahtarı* bu birincil anahtardan farklıdır.
Uzun bir birincil anahtar, ekleme performansını ve bellek tüketimini olumsuz yönde etkiler, ancak birincil anahtardaki ek sütunlar, ClickHouse performansını etkilemez `SELECT` sorgular.
### Sıralama anahtarından farklı bir birincil anahtar seçme {#choosing-a-primary-key-that-differs-from-the-sorting-key}
Sıralama anahtarından (veri bölümlerindeki satırları sıralamak için bir ifade) farklı bir birincil anahtar (her işaret için dizin dosyasında yazılan değerlere sahip bir ifade) belirtmek mümkündür. Bu durumda, birincil anahtar ifadesi tuple, sıralama anahtarı ifadesi tuple'ın bir öneki olmalıdır.
Bu özellik kullanırken yararlıdır [SummingMergeTree](summingmergetree.md) ve
[AggregatingMergeTree](aggregatingmergetree.md) masa motorları. Bu motorları kullanırken yaygın bir durumda, tablonun iki tür sütunu vardır: *boyutlular* ve *ölçümler*. Tipik sorgular, rasgele ölçü sütunlarının değerlerini toplar `GROUP BY` ve boyutlara göre filtreleme. Çünkü SummingMergeTree ve AggregatingMergeTree sıralama anahtarının aynı değere sahip satırları toplamak, tüm boyutları eklemek doğaldır. Sonuç olarak, anahtar ifadesi uzun bir sütun listesinden oluşur ve bu liste yeni eklenen boyutlarla sık sık güncelleştirilmelidir.
Bu durumda, birincil anahtarda verimli Aralık taramaları sağlayacak ve kalan boyut sütunlarını sıralama anahtarı kümesine ekleyecek yalnızca birkaç sütun bırakmak mantıklıdır.
[ALTER](../../../sql_reference/statements/alter.md) yeni bir sütun aynı anda tabloya ve sıralama anahtarı eklendiğinde, varolan veri parçaları değiştirilmesi gerekmez, çünkü sıralama anahtarının hafif bir işlemdir. Eski sıralama anahtarı yeni sıralama anahtarının bir öneki olduğundan ve yeni eklenen sütunda veri olmadığından, veriler tablo değişikliği anında hem eski hem de yeni sıralama anahtarlarına göre sıralanır.
### Sorgularda dizin ve bölümlerin kullanımı {#use-of-indexes-and-partitions-in-queries}
İçin `SELECT` sorgular, ClickHouse bir dizin kullanılabilir olup olmadığını analiz eder. Eğer bir dizin kullanılabilir `WHERE/PREWHERE` yan tümce, bir eşitlik veya eşitsizlik karşılaştırma işlemini temsil eden bir ifadeye (bağlantı öğelerinden biri olarak veya tamamen) sahiptir veya varsa `IN` veya `LIKE` sütun veya birincil anahtar veya bölümleme anahtar veya bu sütunların belirli kısmen tekrarlayan işlevleri veya bu ifadelerin mantıksal ilişkileri olan ifadeler üzerinde sabit bir önek ile.
Bu nedenle, birincil anahtarın bir veya daha fazla aralığındaki sorguları hızlı bir şekilde çalıştırmak mümkündür. Bu örnekte, belirli bir izleme etiketi, belirli bir etiket ve tarih aralığı, belirli bir etiket ve tarih için, tarih aralığına sahip birden çok etiket için vb. çalıştırıldığında sorgular hızlı olacaktır.
Aşağıdaki gibi yapılandırılmış motora bakalım:
ENGINE MergeTree() PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDate) SETTINGS index_granularity=8192
Bu durumda, sorgularda:
``` sql
SELECT count() FROM table WHERE EventDate = toDate(now()) AND CounterID = 34
SELECT count() FROM table WHERE EventDate = toDate(now()) AND (CounterID = 34 OR CounterID = 42)
SELECT count() FROM table WHERE ((EventDate >= toDate('2014-01-01') AND EventDate <= toDate('2014-01-31')) OR EventDate = toDate('2014-05-01')) AND CounterID IN (101500, 731962, 160656) AND (CounterID = 101500 OR EventDate != toDate('2014-05-01'))
```
ClickHouse, uygun olmayan verileri kırpmak için birincil anahtar dizinini ve uygun olmayan tarih aralıklarındaki bölümleri kırpmak için aylık bölümleme anahtarını kullanır.
Yukarıdaki sorgular, dizinin karmaşık ifadeler için bile kullanıldığını göstermektedir. Tablodan okuma, dizini kullanarak tam taramadan daha yavaş olamayacak şekilde düzenlenmiştir.
Aşağıdaki örnekte, dizin kullanılamaz.
``` sql
SELECT count() FROM table WHERE CounterID = 34 OR URL LIKE '%upyachka%'
```
Clickhouse'un bir sorgu çalıştırırken dizini kullanıp kullanamayacağını kontrol etmek için ayarları kullanın [force\_index\_by\_date](../../../operations/settings/settings.md#settings-force_index_by_date) ve [force\_primary\_key](../../../operations/settings/settings.md).
Aylara göre bölümleme anahtarı, yalnızca uygun aralıktaki tarihleri içeren veri bloklarını okumanıza izin verir. Bu durumda, veri bloğu birçok tarih için veri içerebilir (bir aya kadar). Bir blok içinde veriler, ilk sütun olarak tarihi içermeyen birincil anahtara göre sıralanır. Bu nedenle, birincil anahtar önekini belirtmeyen yalnızca bir tarih koşulu ile bir sorgu kullanarak tek bir tarih için okunacak daha fazla veri neden olur.
### Kısmen monotonik birincil anahtarlar için Endeks kullanımı {#use-of-index-for-partially-monotonic-primary-keys}
Örneğin, Ayın günlerini düşünün. Onlar formu bir [monotonik dizisi](https://en.wikipedia.org/wiki/Monotonic_function) bir ay boyunca, ancak daha uzun süreler için monotonik değil. Bu kısmen monotonik bir dizidir. Bir kullanıcı kısmen monoton birincil anahtar ile tablo oluşturursa, ClickHouse her zamanki gibi seyrek bir dizin oluşturur. Bir kullanıcı bu tür bir tablodan veri seçtiğinde, ClickHouse sorgu koşullarını analiz eder. Kullanıcı, dizinin iki işareti arasında veri almak isterse ve bu işaretlerin her ikisi de bir ay içinde düşerse, ClickHouse bu özel durumda dizini kullanabilir, çünkü sorgu parametreleri ile dizin işaretleri arasındaki mesafeyi hesaplayabilir.
Sorgu parametresi aralığındaki birincil anahtarın değerleri monotonik bir sırayı temsil etmiyorsa, ClickHouse bir dizin kullanamaz. Bu durumda, ClickHouse Tam Tarama yöntemini kullanır.
ClickHouse bu mantığı yalnızca ay dizilerinin günleri için değil, kısmen monotonik bir diziyi temsil eden herhangi bir birincil anahtar için kullanır.
### Veri atlama indeksleri (deneysel) {#table_engine-mergetree-data_skipping-indexes}
Dizin bildirimi sütunlar bölümünde `CREATE` sorgu.
``` sql
INDEX index_name expr TYPE type(...) GRANULARITY granularity_value
```
Tablolar için `*MergeTree` aile, veri atlama endeksleri belirtilebilir.
Bu endeksler, bloklarda belirtilen ifade hakkında bazı bilgileri toplar ve bunlardan oluşur `granularity_value` granüller (granül boyutu kullanılarak belirtilir `index_granularity` tablo motoru ayarı). Daha sonra bu agregalar `SELECT` büyük veri bloklarını atlayarak diskten okunacak veri miktarını azaltmak için sorgular `where` sorgu tatmin edilemez.
**Örnek**
``` sql
CREATE TABLE table_name
(
u64 UInt64,
i32 Int32,
s String,
...
INDEX a (u64 * i32, s) TYPE minmax GRANULARITY 3,
INDEX b (u64 * length(s)) TYPE set(1000) GRANULARITY 4
) ENGINE = MergeTree()
...
```
Örneğin endeksleri aşağıdaki sorgularda diskten okunacak veri miktarını azaltmak için ClickHouse tarafından kullanılabilir:
``` sql
SELECT count() FROM table WHERE s < 'z'
SELECT count() FROM table WHERE u64 * i32 == 10 AND u64 * length(s) >= 1234
```
#### Mevcut Endeks Türleri {#available-types-of-indices}
- `minmax`
Belirtilen ifad (eyi saklar (ifad (enin `tuple`, sonra her eleman için aşırı depolar `tuple`), birincil anahtar gibi veri bloklarını atlamak için saklanan bilgileri kullanır.
- `set(max_rows)`
Belirtilen ifadenin benzersiz değerlerini depolar (en fazla `max_rows` satırlar, `max_rows=0` anlama “no limits”). Kontrol etmek için değerleri kullanır `WHERE` ifade, bir veri bloğu üzerinde tatmin edilemez değildir.
- `ngrambf_v1(n, size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed)`
Mağazalar a [Blo filterom filtre](https://en.wikipedia.org/wiki/Bloom_filter) bu, bir veri bloğundaki tüm ngramları içerir. Sadece dizeleri ile çalışır. Optimizasyonu için kullanılabilir `equals`, `like` ve `in` ifadeler.
- `n` — ngram size,
- `size_of_bloom_filter_in_bytes` — Bloom filter size in bytes (you can use large values here, for example, 256 or 512, because it can be compressed well).
- `number_of_hash_functions` — The number of hash functions used in the Bloom filter.
- `random_seed` — The seed for Bloom filter hash functions.
- `tokenbf_v1(size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed)`
Olarak aynı `ngrambf_v1`, ancak ngrams yerine simgeleri saklar. Belirteçler alfasayısal olmayan karakterlerle ayrılmış dizilerdir.
- `bloom_filter([false_positive])` — Stores a [Blo filterom filtre](https://en.wikipedia.org/wiki/Bloom_filter) belirtilen sütunlar için.
Opsiyonel `false_positive` parametre, filtreden yanlış pozitif yanıt alma olasılığıdır. Olası değerler: (0, 1). Varsayılan değer: 0.025.
Desteklenen veri türleri: `Int*`, `UInt*`, `Float*`, `Enum`, `Date`, `DateTime`, `String`, `FixedString`, `Array`, `LowCardinality`, `Nullable`.
Aşağıdaki işlevleri kullanabilirsiniz: [eşitlikler](../../../sql_reference/functions/comparison_functions.md), [notEquals](../../../sql_reference/functions/comparison_functions.md), [içinde](../../../sql_reference/functions/in_functions.md), [notİn](../../../sql_reference/functions/in_functions.md), [var](../../../sql_reference/functions/array_functions.md).
<!-- -->
``` sql
INDEX sample_index (u64 * length(s)) TYPE minmax GRANULARITY 4
INDEX sample_index2 (u64 * length(str), i32 + f64 * 100, date, str) TYPE set(100) GRANULARITY 4
INDEX sample_index3 (lower(str), str) TYPE ngrambf_v1(3, 256, 2, 0) GRANULARITY 4
```
#### Fonksiyonları Destek {#functions-support}
Koşulları `WHERE` yan tümcesi, sütunlarla çalışan işlevlerin çağrılarını içerir. Sütun bir dizinin bir parçasıysa, ClickHouse işlevleri gerçekleştirirken bu dizini kullanmaya çalışır. ClickHouse, dizinleri kullanmak için farklı işlev alt kümelerini destekler.
Bu `set` dizin tüm fonksiyonları ile kullanılabilir. Diğer dizinler için işlev alt kümeleri aşağıdaki tabloda gösterilmiştir.
| Fonksiyon (operatör) / dizin | birincil anahtar | minmax | ngrambf\_v1 | tokenbf\_v1 | bloom\_filter |
|------------------------------------------------------------------------------------------------------------|------------------|--------|-------------|-------------|---------------|
| [eşitlikler (=, ==)](../../../sql_reference/functions/comparison_functions.md#function-equals) | ✔ | ✔ | ✔ | ✔ | ✔ |
| [notEquals(!=, \<\>)](../../../sql_reference/functions/comparison_functions.md#function-notequals) | ✔ | ✔ | ✔ | ✔ | ✔ |
| [hoşlanmak](../../../sql_reference/functions/string_search_functions.md#function-like) | ✔ | ✔ | ✔ | ✗ | ✗ |
| [notLike](../../../sql_reference/functions/string_search_functions.md#function-notlike) | ✔ | ✔ | ✔ | ✗ | ✗ |
| [startsWith](../../../sql_reference/functions/string_functions.md#startswith) | ✔ | ✔ | ✔ | ✔ | ✗ |
| [endsWith](../../../sql_reference/functions/string_functions.md#endswith) | ✗ | ✗ | ✔ | ✔ | ✗ |
| [multiSearchAny](../../../sql_reference/functions/string_search_functions.md#function-multisearchany) | ✗ | ✗ | ✔ | ✗ | ✗ |
| [içinde](../../../sql_reference/functions/in_functions.md#in-functions) | ✔ | ✔ | ✔ | ✔ | ✔ |
| [notİn](../../../sql_reference/functions/in_functions.md#in-functions) | ✔ | ✔ | ✔ | ✔ | ✔ |
| [daha az (\<)](../../../sql_reference/functions/comparison_functions.md#function-less) | ✔ | ✔ | ✗ | ✗ | ✗ |
| [büyük (\>)](../../../sql_reference/functions/comparison_functions.md#function-greater) | ✔ | ✔ | ✗ | ✗ | ✗ |
| [lessOrEquals (\<=)](../../../sql_reference/functions/comparison_functions.md#function-lessorequals) | ✔ | ✔ | ✗ | ✗ | ✗ |
| [greaterOrEquals (\>=)](../../../sql_reference/functions/comparison_functions.md#function-greaterorequals) | ✔ | ✔ | ✗ | ✗ | ✗ |
| [boş](../../../sql_reference/functions/array_functions.md#function-empty) | ✔ | ✔ | ✗ | ✗ | ✗ |
| [notEmpty](../../../sql_reference/functions/array_functions.md#function-notempty) | ✔ | ✔ | ✗ | ✗ | ✗ |
| hasToken | ✗ | ✗ | ✗ | ✔ | ✗ |
Ngram boyutundan daha az olan sabit bir argümana sahip işlevler tarafından kullanılamaz `ngrambf_v1` sorgu optimizasyonu için.
Bloom filtreleri yanlış pozitif eşleşmelere sahip olabilir, bu yüzden `ngrambf_v1`, `tokenbf_v1`, ve `bloom_filter` dizinler, örneğin bir işlevin sonucunun false olması beklenen sorguları en iyi duruma getirmek için kullanılamaz:
- Optimize edilebilir:
- `s LIKE '%test%'`
- `NOT s NOT LIKE '%test%'`
- `s = 1`
- `NOT s != 1`
- `startsWith(s, 'test')`
- Optimize edilemez:
- `NOT s LIKE '%test%'`
- `s NOT LIKE '%test%'`
- `NOT s = 1`
- `s != 1`
- `NOT startsWith(s, 'test')`
## Eşzamanlı Veri Erişimi {#concurrent-data-access}
Eşzamanlı tablo erişimi için çoklu sürüm kullanıyoruz. Başka bir deyişle, bir tablo aynı anda okunup güncelleştirildiğinde, sorgu sırasında geçerli olan bir parça kümesinden veri okunur. Uzun kilitler yok. Ekler okuma işlemlerinin yoluna girmez.
Bir tablodan okuma otomatik olarak paralelleştirilir.
## Sütunlar ve tablolar için TTL {#table_engine-mergetree-ttl}
Değerlerin ömrünü belirler.
Bu `TTL` yan tümcesi tüm tablo ve her sütun için ayarlanabilir. Tablo düzeyinde TTL ayrıca diskler ve birimler arasında otomatik veri taşıma mantığını belirtebilirsiniz.
İfadeleri değerlendirmek gerekir [Tarihli](../../../sql_reference/data_types/date.md) veya [DateTime](../../../sql_reference/data_types/datetime.md) veri türü.
Örnek:
``` sql
TTL time_column
TTL time_column + interval
```
Tanımlamak `interval`, kullanma [zaman aralığı](../../../sql_reference/operators.md#operators-datetime) operatörler.
``` sql
TTL date_time + INTERVAL 1 MONTH
TTL date_time + INTERVAL 15 HOUR
```
### Sütun TTL {#mergetree-column-ttl}
Sütundaki değerler sona erdiğinde, ClickHouse bunları sütun veri türü için varsayılan değerlerle değiştirir. Veri bölümündeki tüm sütun değerleri sona ererse, ClickHouse bu sütunu bir dosya sistemindeki veri bölümünden siler.
Bu `TTL` yan tümcesi anahtar sütunlar için kullanılamaz.
Örnekler:
TTL ile tablo oluşturma
``` sql
CREATE TABLE example_table
(
d DateTime,
a Int TTL d + INTERVAL 1 MONTH,
b Int TTL d + INTERVAL 1 MONTH,
c String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(d)
ORDER BY d;
```
Varolan bir tablonun sütununa TTL ekleme
``` sql
ALTER TABLE example_table
MODIFY COLUMN
c String TTL d + INTERVAL 1 DAY;
```
Sütun TTL değiştirme
``` sql
ALTER TABLE example_table
MODIFY COLUMN
c String TTL d + INTERVAL 1 MONTH;
```
### Tablo TTL {#mergetree-table-ttl}
Tablo, süresi dolmuş satırların kaldırılması için bir ifadeye ve parçaların arasında otomatik olarak taşınması için birden fazla ifadeye sahip olabilir [diskler veya birimler](#table_engine-mergetree-multiple-volumes). Tablodaki satırların süresi dolduğunda, ClickHouse ilgili tüm satırları siler. Parça taşıma özelliği için, bir parçanın tüm satırları hareket ifadesi ölçütlerini karşılaması gerekir.
``` sql
TTL expr [DELETE|TO DISK 'aaa'|TO VOLUME 'bbb'], ...
```
TTL kuralı türü her TTL ifadesini takip edebilir. İfade tatmin edildikten sonra yapılacak bir eylemi etkiler (şimdiki zamana ulaşır):
- `DELETE` - süresi dolmuş satırları sil (varsayılan eylem);
- `TO DISK 'aaa'` - parçayı diske taşı `aaa`;
- `TO VOLUME 'bbb'` - parçayı diske taşı `bbb`.
Örnekler:
TTL ile tablo oluşturma
``` sql
CREATE TABLE example_table
(
d DateTime,
a Int
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(d)
ORDER BY d
TTL d + INTERVAL 1 MONTH [DELETE],
d + INTERVAL 1 WEEK TO VOLUME 'aaa',
d + INTERVAL 2 WEEK TO DISK 'bbb';
```
Tablonun TTL değiştirme
``` sql
ALTER TABLE example_table
MODIFY TTL d + INTERVAL 1 DAY;
```
**Verileri Kaldırma**
ClickHouse veri parçalarını birleştirdiğinde süresi dolmuş bir TTL ile veri kaldırılır.
ClickHouse, verilerin süresi dolduğunu gördüğünde, zamanlama dışı bir birleştirme gerçekleştirir. Bu tür birleştirmelerin sıklığını kontrol etmek için şunları ayarlayabilirsiniz [merge\_with\_ttl\_timeout](#mergetree_setting-merge_with_ttl_timeout). Değer çok düşükse, çok fazla kaynak tüketebilecek birçok zamanlama dışı birleştirme gerçekleştirir.
Gerçekleştir theirseniz `SELECT` birleştirme arasında sorgu, süresi dolmuş veri alabilirsiniz. Bunu önlemek için, [OPTIMIZE](../../../sql_reference/statements/misc.md#misc_operations-optimize) önce sorgu `SELECT`.
## Veri Depolama İçin Birden Fazla Blok Cihazı Kullanma {#table_engine-mergetree-multiple-volumes}
### Giriş {#introduction}
`MergeTree` aile tablo motorları birden fazla blok cihazlarda veri saklayabilirsiniz. Örneğin, belirli bir tablonun verileri örtük olarak bölündüğünde yararlı olabilir “hot” ve “cold”. En son veriler düzenli olarak talep edilir, ancak yalnızca az miktarda alan gerektirir. Aksine, yağ kuyruklu tarihsel veriler nadiren talep edilir. Birkaç disk varsa, “hot” veriler hızlı disklerde (örneğin, NVMe SSD'ler veya bellekte) bulunabilir; “cold” veri-nispeten yavaş olanlar (örneğin, HDD).
Veri kısmı için minimum hareketli birimdir `MergeTree`- motor masaları. Bir parçaya ait veriler bir diskte saklanır. Veri parçaları arka planda diskler arasında (kullanıcı ayarlarına göre) ve aynı zamanda [ALTER](../../../sql_reference/statements/alter.md#alter_move-partition) sorgular.
### Şartlar {#terms}
- Disk — Block device mounted to the filesystem.
- Default disk — Disk that stores the path specified in the [yol](../../../operations/server_configuration_parameters/settings.md#server_configuration_parameters-path) sunucu ayarı.
- Volume — Ordered set of equal disks (similar to [JBOD](https://en.wikipedia.org/wiki/Non-RAID_drive_architectures)).
- Storage policy — Set of volumes and the rules for moving data between them.
Açıklanan varlıklara verilen isimler sistem tablolarında bulunabilir, [sistem.storage\_policies](../../../operations/system_tables.md#system_tables-storage_policies) ve [sistem.diskler](../../../operations/system_tables.md#system_tables-disks). Bir tablo için yapılandırılmış depolama ilkelerinden birini uygulamak için `storage_policy` ayarı `MergeTree`- motor aile tabloları.
### Yapılandırma {#table_engine-mergetree-multiple-volumes-configure}
Diskler, birimler ve depolama politikaları içinde bildirilmelidir `<storage_configuration>` ana dosyada ya etiket `config.xml` veya farklı bir dosyada `config.d` dizin.
Yapılandırma yapısı:
``` xml
<storage_configuration>
<disks>
<disk_name_1> <!-- disk name -->
<path>/mnt/fast_ssd/clickhouse</path>
</disk_name_1>
<disk_name_2>
<path>/mnt/hdd1/clickhouse</path>
<keep_free_space_bytes>10485760</keep_free_space_bytes>
</disk_name_2>
<disk_name_3>
<path>/mnt/hdd2/clickhouse</path>
<keep_free_space_bytes>10485760</keep_free_space_bytes>
</disk_name_3>
...
</disks>
...
</storage_configuration>
```
Etiketler:
- `<disk_name_N>` — Disk name. Names must be different for all disks.
- `path` — path under which a server will store data (`data` ve `shadow` klasörler) ile Sonlandır shouldılmalıdır ‘/’.
- `keep_free_space_bytes` — the amount of free disk space to be reserved.
Disk tanımının sırası önemli değildir.
Depolama ilkeleri yapılandırma biçimlendirme:
``` xml
<storage_configuration>
...
<policies>
<policy_name_1>
<volumes>
<volume_name_1>
<disk>disk_name_from_disks_configuration</disk>
<max_data_part_size_bytes>1073741824</max_data_part_size_bytes>
</volume_name_1>
<volume_name_2>
<!-- configuration -->
</volume_name_2>
<!-- more volumes -->
</volumes>
<move_factor>0.2</move_factor>
</policy_name_1>
<policy_name_2>
<!-- configuration -->
</policy_name_2>
<!-- more policies -->
</policies>
...
</storage_configuration>
```
Etiketler:
- `policy_name_N` — Policy name. Policy names must be unique.
- `volume_name_N` — Volume name. Volume names must be unique.
- `disk` — a disk within a volume.
- `max_data_part_size_bytes` — the maximum size of a part that can be stored on any of the volume's disks.
- `move_factor` — when the amount of available space gets lower than this factor, data automatically start to move on the next volume if any (by default, 0.1).
Cofiguration örnekleri:
``` xml
<storage_configuration>
...
<policies>
<hdd_in_order> <!-- policy name -->
<volumes>
<single> <!-- volume name -->
<disk>disk1</disk>
<disk>disk2</disk>
</single>
</volumes>
</hdd_in_order>
<moving_from_ssd_to_hdd>
<volumes>
<hot>
<disk>fast_ssd</disk>
<max_data_part_size_bytes>1073741824</max_data_part_size_bytes>
</hot>
<cold>
<disk>disk1</disk>
</cold>
</volumes>
<move_factor>0.2</move_factor>
</moving_from_ssd_to_hdd>
</policies>
...
</storage_configuration>
```
Verilen örnekte, `hdd_in_order` politika uygular [Ro -und-robin](https://en.wikipedia.org/wiki/Round-robin_scheduling) yaklaşma. Böylece bu politika yalnızca bir birim tanımlar (`single`), veri parçaları tüm disklerinde dairesel sırayla saklanır. Bu tür bir politika, sisteme birkaç benzer disk takılıysa, ancak RAID yapılandırılmamışsa oldukça yararlı olabilir. Her bir disk sürücüsünün güvenilir olmadığını ve bunu 3 veya daha fazla çoğaltma faktörü ile telafi etmek isteyebileceğinizi unutmayın.
Sistemde farklı türde diskler varsa, `moving_from_ssd_to_hdd` politika yerine kullanılabilir. Birim `hot` bir SSD disk oluşur (`fast_ssd`) ve bu birimde saklanabilecek bir parçanın maksimum boyutu 1GB. Tüm parçaları ile boyutu daha büyük 1 GB üzerinde doğrudan saklanır `cold` bir HDD diski içeren birim `disk1`.
Ayrıca, bir kez disk `fast_ssd` 80'den fazla % tarafından doldurulur, veri transfer edilecektir `disk1` bir arka plan işlemi ile.
Depolama ilkesi içindeki birim numaralandırma sırası önemlidir. Bir birim aşırı doldurulduktan sonra, veriler bir sonrakine taşınır. Disk numaralandırma sırası da önemlidir, çünkü veriler sırayla depolanır.
Bir tablo oluştururken, yapılandırılmış depolama ilkelerinden birini ona uygulayabilirsiniz:
``` sql
CREATE TABLE table_with_non_default_policy (
EventDate Date,
OrderID UInt64,
BannerID UInt64,
SearchPhrase String
) ENGINE = MergeTree
ORDER BY (OrderID, BannerID)
PARTITION BY toYYYYMM(EventDate)
SETTINGS storage_policy = 'moving_from_ssd_to_hdd'
```
Bu `default` depolama ilkesi, Yalnızca verilen bir diskten oluşan yalnızca bir birim kullanmayı ima eder `<path>`. Bir tablo oluşturulduktan sonra, depolama ilkesi değiştirilemez.
### Ayrıntı {#details}
Bu durumda `MergeTree` tablolar, veriler diske farklı şekillerde giriyor:
- Bir ekleme sonucunda (`INSERT` sorgu).
- Arka plan birleştirmeleri sırasında ve [mutasyonlar](../../../sql_reference/statements/alter.md#alter-mutations).
- Başka bir kopyadan indirirken.
- Bölüm Don ofması sonucu [ALTER TABLE … FREEZE PARTITION](../../../sql_reference/statements/alter.md#alter_freeze-partition).
Mutasyonlar ve bölüm dondurma hariç tüm bu durumlarda, bir parça verilen depolama politikasına göre bir birim ve bir diskte saklanır:
1. Bir parçayı depolamak için yeterli disk alanına sahip olan ilk birim (tanım sırasına göre) (`unreserved_space > current_part_size`) ve belirli bir boyuttaki parçaların saklanmasına izin verir (`max_data_part_size_bytes > current_part_size`) seçilir.
2. Bu birimde, önceki veri yığınını depolamak için kullanılan ve parça boyutundan daha fazla boş alana sahip olan diski izleyen disk seçilir (`unreserved_space - keep_free_space_bytes > current_part_size`).
Kap hoodut underun altında, [sabit linkler](https://en.wikipedia.org/wiki/Hard_link). Farklı diskler arasındaki sabit bağlantılar desteklenmez, bu nedenle bu gibi durumlarda ortaya çıkan parçalar ilk disklerle aynı disklerde saklanır.
Arka planda, parçalar boş alan miktarına göre hacimler arasında taşınır (`move_factor` parametre) sırasına göre birimler yapılandırma dosyasında beyan edilir.
Veriler asla sonuncudan ve birincisine aktarılmaz. Bir sistem tabloları kullanabilirsiniz [sistem.part\_log](../../../operations/system_tables.md#system_tables-part-log) (alan `type = MOVE_PART`) ve [sistem.parçalar](../../../operations/system_tables.md#system_tables-parts) (alanlar `path` ve `disk`) arka plan hareketlerini izlemek için. Ayrıca, ayrıntılı bilgi sunucu günlüklerinde bulunabilir.
Kullanıcı, sorguyu kullanarak bir bölümü veya bölümü bir birimden diğerine taşımaya zorlayabilir [ALTER TABLE … MOVE PART\|PARTITION … TO VOLUME\|DISK …](../../../sql_reference/statements/alter.md#alter_move-partition), arka plan işlemleri için tüm kısıtlamalar dikkate alınır. Sorgu, kendi başına bir hareket başlatır ve tamamlanması için arka plan işlemleri beklemez. Yeterli boş alan yoksa veya gerekli koşullardan herhangi biri karşılanmazsa kullanıcı bir hata mesajı alır.
Veri taşıma veri çoğaltma ile müdahale etmez. Bu nedenle, farklı depolama ilkeleri aynı tablo için farklı yinelemeler üzerinde belirtilebilir.
Arka plan birleşimlerinin ve mutasyonlarının tamamlanmasından sonra, eski parçalar yalnızca belirli bir süre sonra çıkarılır (`old_parts_lifetime`).
Bu süre zarfında, diğer birimlere veya disklere taşınmazlar. Bu nedenle, parçalar nihayet çıkarılıncaya kadar, işgal edilen disk alanının değerlendirilmesi için hala dikkate alınır.
[Orijinal makale](https://clickhouse.tech/docs/ru/operations/table_engines/mergetree/) <!--hide-->

69
docs/tr/engines/table_engines/mergetree_family/replacingmergetree.md Normal file
View File

@ -0,0 +1,69 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 33
toc_title: ReplacingMergeTree
---
# ReplacingMergeTree {#replacingmergetree}
Motor farklıdır [MergeTree](mergetree.md#table_engines-mergetree) aynı birincil anahtar değerine sahip yinelenen girdileri kaldırır (veya daha doğru bir şekilde, aynı [sıralama anahtarı](mergetree.md) değer).
Veri tekilleştirme yalnızca birleştirme sırasında oluşur. Birleştirme, arka planda bilinmeyen bir zamanda gerçekleşir, bu nedenle bunu planlayamazsınız. Bazı veriler işlenmemiş kalabilir. Kullanarak programsız bir birleştirme çalıştırabilirsiniz, ancak `OPTIMIZE` sorgu, kullanmaya güvenmeyin, çünkü `OPTIMIZE` sorgu büyük miktarda veri okuyacak ve yazacaktır.
Böyle, `ReplacingMergeTree` yerden tasarruf etmek için arka planda yinelenen verileri temizlemek için uygundur, ancak kopyaların yokluğunu garanti etmez.
## Tablo oluşturma {#creating-a-table}
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE = ReplacingMergeTree([ver])
[PARTITION BY expr]
[ORDER BY expr]
[PRIMARY KEY expr]
[SAMPLE BY expr]
[SETTINGS name=value, ...]
```
İstek parametrelerinin açıklaması için bkz. [istek açıklaması](../../../sql_reference/statements/create.md).
**ReplacingMergeTree Parametreleri**
- `ver` — column with version. Type `UInt*`, `Date` veya `DateTime`. İsteğe bağlı parametre.
Birleş whenirken, `ReplacingMergeTree` aynı birincil anahtara sahip tüm satırlardan sadece bir tane bırakır:
- Seç inimde son, eğer `ver` set değil.
- Maksimum sürümü ile, eğer `ver` belirtilen.
**Sorgu yan tümceleri**
Oluştururken bir `ReplacingMergeTree` tablo aynı [yanlar](mergetree.md) oluşturul ,urken olduğu gibi gerekli `MergeTree` Tablo.
<details markdown="1">
<summary>Bir tablo oluşturmak için kullanımdan kaldırılan yöntem</summary>
!!! attention "Dikkat"
Bu yöntemi yeni projelerde kullanmayın ve mümkünse eski projeleri yukarıda açıklanan yönteme geçin.
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE [=] ReplacingMergeTree(date-column [, sampling_expression], (primary, key), index_granularity, [ver])
```
Hariç tüm parametreler `ver` içinde olduğu gibi aynı anlama sahip `MergeTree`.
- `ver` - sürümü ile sütun. İsteğe bağlı parametre. Bir açıklama için yukarıdaki metne bakın.
</details>
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/replacingmergetree/) <!--hide-->

218
docs/tr/engines/table_engines/mergetree_family/replication.md Normal file
View File

@ -0,0 +1,218 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 31
toc_title: "Veri \xC7o\u011Faltma"
---
# Veri Çoğaltma {#table_engines-replication}
Çoğaltma yalnızca mergetree ailesindeki tablolar için desteklenir:
- ReplicatedMergeTree
- ReplicatedSummingMergeTree
- ReplicatedReplacingMergeTree
- ReplicatedAggregatingMergeTree
- ReplicatedCollapsingMergeTree
- ReplicatedVersionedCollapsingMergetree
- ReplicatedGraphiteMergeTree
Çoğaltma, tüm sunucu değil, tek bir tablo düzeyinde çalışır. Bir sunucu hem çoğaltılmış hem de çoğaltılmamış tabloları aynı anda depolayabilir.
Çoğaltma, parçaya bağlı değildir. Her parçanın kendi bağımsız çoğaltması vardır.
İçin sıkıştırılmış veri `INSERT` ve `ALTER` sorgular çoğaltılır (daha fazla bilgi için bkz. [ALTER](../../../sql_reference/statements/alter.md#query_language_queries_alter)).
`CREATE`, `DROP`, `ATTACH`, `DETACH` ve `RENAME` sorgular tek bir sunucuda yürütülür ve çoğaltılmaz:
- Bu `CREATE TABLE` sorgu sorgu çalıştırıldığı sunucuda yeni bir replicatable tablo oluşturur. Bu tablo diğer sunucularda zaten varsa, yeni bir yineleme ekler.
- Bu `DROP TABLE` sorgu, sorgunun çalıştırıldığı sunucuda bulunan yinelemeyi siler.
- Bu `RENAME` sorgu yinelemeler birinde tabloyu yeniden adlandırır. Başka bir deyişle, çoğaltılmış tablolar farklı yinelemeler üzerinde farklı adlara sahip olabilir.
ClickHouse kullanır [Apache ZooKeeper](https://zookeeper.apache.org) kopyaları meta bilgilerini saklamak için. ZooKeeper sürüm 3.4.5 veya daha yeni kullanın.
Çoğaltma kullanmak için, parametreleri [zookeeper](../../../operations/server_configuration_parameters/settings.md#server-settings_zookeeper) sunucu yapılandırma bölümü.
!!! attention "Dikkat"
Güvenlik ayarını ihmal etmeyin. ClickHouse destekler `digest` [ACLL şeması](https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#sc_ZooKeeperAccessControl) ZooKeeper Güvenlik alt sisteminin.
ZooKeeper kümesinin adreslerini ayarlama örneği:
``` xml
<zookeeper>
<node index="1">
<host>example1</host>
<port>2181</port>
</node>
<node index="2">
<host>example2</host>
<port>2181</port>
</node>
<node index="3">
<host>example3</host>
<port>2181</port>
</node>
</zookeeper>
```
Varolan herhangi bir ZooKeeper kümesini belirtebilirsiniz ve sistem kendi verileri için bir dizin kullanır (replicatable tablo oluştururken dizin belirtilir).
Zookeeper yapılandırma dosyasında ayarlanmamışsa, çoğaltılmış tablolar oluşturamazsınız ve varolan çoğaltılmış tablolar salt okunur olacaktır.
ZooKeeper kullanılmaz `SELECT` çoğaltma performansını etkilemez çünkü sorgular `SELECT` ve sorgular, çoğaltılmamış tablolar için yaptıkları kadar hızlı çalışır. Dağıtılmış çoğaltılmış tabloları sorgularken, ClickHouse davranışı ayarlar tarafından denetlenir [max\_replica\_delay\_for\_distributed\_queries](../../../operations/settings/settings.md#settings-max_replica_delay_for_distributed_queries) ve [fallback\_to\_stale\_replicas\_for\_distributed\_queries](../../../operations/settings/settings.md#settings-fallback_to_stale_replicas_for_distributed_queries).
Her biri için `INSERT` sorgu, yaklaşık on girişleri zookeeper birkaç işlemler aracılığıyla eklenir. (Daha kesin olmak gerekirse, bu eklenen her veri bloğu içindir; bir ekleme sorgusu her bir blok veya bir blok içerir `max_insert_block_size = 1048576` satırlar.) Bu, biraz daha uzun gecikmelere yol açar `INSERT` çoğaltılmamış tablolarla karşılaştırıldığında. Ancak, birden fazla olmayan gruplar halinde veri eklemek için önerileri izlerseniz `INSERT` saniyede, herhangi bir sorun yaratmaz. Bir ZooKeeper kümesini koordine etmek için kullanılan tüm ClickHouse kümesinin toplam birkaç yüzü vardır `INSERTs` saniyede. Veri eklerindeki verim (saniyede satır sayısı), çoğaltılmamış veriler için olduğu kadar yüksektir.
Çok büyük kümeler için, farklı kırıklar için farklı ZooKeeper kümelerini kullanabilirsiniz. Ancak, bu Yandex'de gerekli değildir.Metrica küme (yaklaşık 300 sunucu).
Çoğaltma zaman uyumsuz ve çok ana. `INSERT` sorgular (yanı sıra `ALTER`) mevcut herhangi bir sunucuya gönderilebilir. Veri sorgu çalıştırıldığı sunucuda eklenir ve sonra diğer sunuculara kopyalanır. Zaman uyumsuz olduğundan, son eklenen veriler bazı gecikme ile diğer yinelemeler görünür. Yinelemelerin bir kısmı mevcut değilse, veriler kullanılabilir olduklarında yazılır. Bir çoğaltma varsa, gecikme, sıkıştırılmış veri bloğunu ağ üzerinden aktarmak için gereken süredir.
Varsayılan olarak, bir INSERT sorgusu yalnızca bir yinelemeden veri yazma onayı bekler. Verileri başarıyla yalnızca bir yineleme için yazılmıştır ve bu yineleme ile sunucu varolmaya sona erer, depolanan veriler kaybolur. Birden çok yinelemeden veri yazma onayını almayı etkinleştirmek için `insert_quorum` seçenek.
Her veri bloğu atomik olarak yazılır. Ekle sorgusu kadar bloklara ayrılmıştır `max_insert_block_size = 1048576` satırlar. Diğer bir deyişle, `INSERT` sorgu 1048576 satırdan daha az, atomik olarak yapılır.
Veri blokları tekilleştirilmiştir. Aynı veri bloğunun (aynı sırayla aynı satırları içeren aynı boyuttaki veri blokları) birden fazla yazımı için, blok yalnızca bir kez yazılır. Bunun nedeni, istemci uygulaması verilerin DB'YE yazılıp yazılmadığını bilmediğinde ağ arızaları durumunda, `INSERT` sorgu sadece tekrar edilebilir. Hangi çoğaltma eklerinin aynı verilerle gönderildiği önemli değildir. `INSERTs` idempotent vardır. Tekilleştirme parametreleri tarafından kontrol edilir [merge\_tree](../../../operations/server_configuration_parameters/settings.md#server_configuration_parameters-merge_tree) sunucu ayarları.
Çoğaltma sırasında, yalnızca eklenecek kaynak veriler ağ üzerinden aktarılır. Daha fazla veri dönüşümü (birleştirme), tüm kopyalarda aynı şekilde koordine edilir ve gerçekleştirilir. Bu, ağ kullanımını en aza indirir; bu, çoğaltmaların farklı veri merkezlerinde bulunduğu zaman çoğaltmanın iyi çalıştığı anlamına gelir. (Farklı veri merkezlerinde çoğaltmanın çoğaltmanın ana hedefi olduğunu unutmayın .)
Aynı verilerin çoğaltmaları herhangi bir sayıda olabilir. Üye.Metrica üretimde çift çoğaltma kullanır. Her sunucu, bazı durumlarda RAID-5 veya RAID-6 ve RAID-10 kullanır. Bu nispeten güvenilir ve kullanışlı bir çözümdür.
Sistem, yinelemelerdeki veri senkronizasyonunu izler ve bir hatadan sonra kurtarabilir. Yük devretme otomatik (verilerde küçük farklılıklar için) veya yarı otomatik (veriler çok fazla farklılık gösterdiğinde, bu da bir yapılandırma hatasını gösterebilir).
## Çoğaltılmış Tablolar Oluşturma {#creating-replicated-tables}
Bu `Replicated` önek tablo motoru adına eklenir. Mesela:`ReplicatedMergeTree`.
**Çoğaltılan \* MergeTree parametreleri**
- `zoo_path` — The path to the table in ZooKeeper.
- `replica_name` — The replica name in ZooKeeper.
Örnek:
``` sql
CREATE TABLE table_name
(
EventDate DateTime,
CounterID UInt32,
UserID UInt32
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/table_name', '{replica}')
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID))
SAMPLE BY intHash32(UserID)
```
<details markdown="1">
<summary>Kullanımdan kaldırılmış sözdizimi örneği</summary>
``` sql
CREATE TABLE table_name
(
EventDate DateTime,
CounterID UInt32,
UserID UInt32
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/table_name', '{replica}', EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID), EventTime), 8192)
```
</details>
Örnekte gösterildiği gibi, bu parametreler kıvırcık köşeli ayraçlarda ikameler içerebilir. İkame edilen değerler ‘macros’ yapılandırma dosyasının bölümü. Örnek:
``` xml
<macros>
<layer>05</layer>
<shard>02</shard>
<replica>example05-02-1.yandex.ru</replica>
</macros>
```
Zookeeper tablonun yolunu her çoğaltılmış tablo için benzersiz olmalıdır. Farklı parçalardaki tabloların farklı yolları olmalıdır.
Bu durumda, yol aşağıdaki parçalardan oluşur:
`/clickhouse/tables/` ortak önek. Tam olarak bunu kullanmanızı öneririz.
`{layer}-{shard}` shard tanımlayıcısıdır. Bu örnekte Yandex'den beri iki bölümden oluşmaktadır.Metrica küme iki seviyeli sharding kullanır. Çoğu görev için, yalnızca shard tanımlayıcısına genişletilecek olan {shard} ikamesini bırakabilirsiniz.
`table_name` ZooKeeper tablo için düğüm adıdır. Tablo adı ile aynı yapmak için iyi bir fikirdir. Açıkça tanımlanır, çünkü tablo adının aksine, bir yeniden adlandırma sorgusundan sonra değişmez.
*HINT*: önüne bir veritabanı adı ekleyebilirsiniz `table_name` yanında. E. g. `db_name.table_name`
Çoğaltma adı, aynı tablonun farklı yinelemelerini tanımlar. Örnekte olduğu gibi bunun için sunucu adını kullanabilirsiniz. Adın sadece her parça içinde benzersiz olması gerekir.
Değiştirmeleri kullanmak yerine parametreleri açıkça tanımlayabilirsiniz. Bu, test etmek ve küçük kümeleri yapılandırmak için uygun olabilir. Ancak, dağıtılmış DDL sorguları kullanamazsınız (`ON CLUSTER` bu durumda).
Büyük kümelerle çalışırken, hata olasılığını azalttıkları için değiştirmeleri kullanmanızı öneririz.
Run the `CREATE TABLE` her yineleme üzerinde sorgu. Bu sorgu, yeni bir çoğaltılmış tablo oluşturur veya varolan bir yeni bir yineleme ekler.
Tablo zaten diğer yinelemeler üzerinde bazı veriler içerdikten sonra yeni bir yineleme eklerseniz, verileri diğer yinelemeler için yeni bir sorgu çalıştırdıktan sonra kopyalanır. Başka bir deyişle, yeni çoğaltma kendisini diğerleriyle eşitler.
Bir yineleme silmek için çalıştırın `DROP TABLE`. However, only one replica is deleted – the one that resides on the server where you run the query.
## Arızalardan Sonra Kurtarma {#recovery-after-failures}
Bir sunucu başlatıldığında ZooKeeper kullanılamıyorsa, çoğaltılmış tablolar salt okunur moda geçer. Sistem periyodik olarak ZooKeeper bağlanmaya çalışır.
ZooKeeper sırasında kullanılamıyorsa bir `INSERT`, veya ZooKeeper ile etkileşimde bulunurken bir hata oluşur, bir istisna atılır.
ZooKeeper bağlandıktan sonra, sistem yerel dosya sistemindeki veri kümesinin beklenen veri kümesiyle eşleşip eşleşmediğini kontrol eder (ZooKeeper bu bilgileri saklar). Küçük tutarsızlıklar varsa, sistem verileri kopyalarla senkronize ederek bunları çözer.
Sistem bozuk veri parçalarını (yanlış dosya boyutu ile) veya tanınmayan parçaları (dosya sistemine yazılmış ancak Zookeeper'da kaydedilmemiş parçalar) tespit ederse, bunları `detached` alt dizin (silinmez). Eksik parçalar kopyalardan kopyalanır.
Clickhouse'un büyük miktarda veriyi otomatik olarak silme gibi yıkıcı eylemler gerçekleştirmediğini unutmayın.
Sunucu başlatıldığında (veya ZooKeeper ile yeni bir oturum kurduğunda), yalnızca tüm dosyaların miktarını ve boyutlarını kontrol eder. Dosya boyutları eşleşirse, ancak bayt ortasında bir yerde değiştirilmişse, bu hemen algılanmaz, ancak yalnızca bir dosya için verileri okumaya çalışırken algılanmaz. `SELECT` sorgu. Sorgu, eşleşen olmayan bir sağlama toplamı veya sıkıştırılmış bir bloğun boyutu hakkında bir özel durum atar. Bu durumda, veri parçaları doğrulama kuyruğuna eklenir ve gerekirse kopyalardan kopyalanır.
Yerel veri kümesi beklenenden çok fazla farklıysa, bir güvenlik mekanizması tetiklenir. Sunucu bunu günlüğe girer ve başlatmayı reddeder. Bunun nedeni, bu durumda, bir parçadaki bir kopya yanlışlıkla farklı bir parçadaki bir kopya gibi yapılandırılmışsa gibi bir yapılandırma hatası gösterebilir. Ancak, bu mekanizma için eşikleri oldukça düşük ayarlanır ve bu durum normal hata kurtarma sırasında ortaya çıkabilir. Bu durumda, veriler yarı otomatik olarak geri yüklenir “pushing a button”.
Kurtarma işlemini başlatmak için düğümü oluşturun `/path_to_table/replica_name/flags/force_restore_data` herhangi bir içerik ile ZooKeeper veya tüm çoğaltılmış tabloları geri yüklemek için komutu çalıştırın:
``` bash
sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data
```
Sunucuyu yeniden başlatın. Başlangıçta, sunucu bu bayrakları siler ve kurtarma işlemini başlatır.
## Tam Veri Kaybından Sonra Kurtarma {#recovery-after-complete-data-loss}
Tüm veriler ve meta veriler sunuculardan birinden kaybolduysa, kurtarma için şu adımları izleyin:
1. Clickhouse'u sunucuya yükleyin. Bunları kullanırsanız, shard tanımlayıcısı ve yinelemeleri içeren yapılandırma dosyasında doğru değiştirmelerin tanımlayın.
2. Sunucularda el ile çoğaltılması gereken yinelenmemiş tablolar varsa, verilerini bir kopyadan kopyalayın (dizinde `/var/lib/clickhouse/data/db_name/table_name/`).
3. Bulunan tablo tanım copylarını kopyala `/var/lib/clickhouse/metadata/` bir kopyadan. Tablo tanımlarında bir parça veya çoğaltma tanımlayıcısı açıkça tanımlanmışsa, bu kopyaya karşılık gelecek şekilde düzeltin. (Alternatif olarak, sunucuyu başlatın ve tüm `ATTACH TABLE` içinde olması gereken sorgular .sql dosyaları `/var/lib/clickhouse/metadata/`.)
4. Kurtarma işlemini başlatmak için ZooKeeper düğümünü oluşturun `/path_to_table/replica_name/flags/force_restore_data` herhangi bir içerikle veya tüm çoğaltılmış tabloları geri yüklemek için komutu çalıştırın: `sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data`
Ardından sunucuyu başlatın (zaten çalışıyorsa yeniden başlatın). Veriler kopyalardan indirilecektir.
Alternatif bir kurtarma seçeneği zookeeper kayıp yineleme hakkında bilgi silmektir (`/path_to_table/replica_name`), daha sonra açıklandığı gibi yinelemeyi tekrar oluşturun “[Çoğaltılmış tablolar oluşturma](#creating-replicated-tables)”.
Kurtarma sırasında ağ bant genişliği üzerinde herhangi bir kısıtlama yoktur. Aynı anda birçok yinelemeyi geri yüklüyorsanız bunu aklınızda bulundurun.
## Mergetree'den Replicatedmergetree'ye Dönüştürme {#converting-from-mergetree-to-replicatedmergetree}
Terimi kullanıyoruz `MergeTree` tüm tablo motorlarına başvurmak için `MergeTree family` için aynı `ReplicatedMergeTree`.
Eğer olsaydı bir `MergeTree` el ile çoğaltılmış tablo, çoğaltılmış bir tabloya dönüştürebilirsiniz. Zaten büyük miktarda veri topladıysanız bunu yapmanız gerekebilir. `MergeTree` tablo ve şimdi çoğaltmayı etkinleştirmek istiyorsunuz.
Veriler çeşitli yinelemelerde farklılık gösteriyorsa, önce onu eşitleyin veya bu verileri biri dışındaki tüm yinelemelerde silin.
Varolan MergeTree tablosunu yeniden adlandırın, sonra bir `ReplicatedMergeTree` eski adı olan tablo.
Eski tablodan veri taşıma `detached` yeni tablo verileri ile dizin içindeki alt dizin (`/var/lib/clickhouse/data/db_name/table_name/`).
Sonra koş `ALTER TABLE ATTACH PARTITION` bu veri parçalarını çalışma kümesine eklemek için yinelemelerden birinde.
## Replicatedmergetree'den Mergetree'ye Dönüştürme {#converting-from-replicatedmergetree-to-mergetree}
Farklı bir adla bir MergeTree tablosu oluşturun. İle dizinden tüm verileri taşıyın `ReplicatedMergeTree` yeni tablonun veri dizinine tablo verileri. Sonra Sil `ReplicatedMergeTree` tablo ve sunucuyu yeniden başlatın.
Eğer bir kurtulmak istiyorsanız `ReplicatedMergeTree` sunucu başlatmadan tablo:
- İlgili sil `.sql` meta veri dizinindeki dosya (`/var/lib/clickhouse/metadata/`).
- ZooKeeper ilgili yolu silin (`/path_to_table/replica_name`).
Bundan sonra, sunucuyu başlatabilir, bir `MergeTree` tablo, verileri kendi dizinine taşıyın ve sonra sunucuyu yeniden başlatın.
## Zookeeper kümesindeki meta veriler kaybolduğunda veya zarar gördüğünde kurtarma {#recovery-when-metadata-in-the-zookeeper-cluster-is-lost-or-damaged}
ZooKeeper içindeki veriler kaybolduysa veya hasar gördüyse, verileri yukarıda açıklandığı gibi yinelenmemiş bir tabloya taşıyarak kaydedebilirsiniz.
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/replication/) <!--hide-->

141
docs/tr/engines/table_engines/mergetree_family/summingmergetree.md Normal file
View File

@ -0,0 +1,141 @@
---
machine_translated: true
machine_translated_rev: e8cd92bba3269f47787db090899f7c242adf7818
toc_priority: 34
toc_title: SummingMergeTree
---
# SummingMergeTree {#summingmergetree}
Motor devralır [MergeTree](mergetree.md#table_engines-mergetree). Fark, veri parçalarını birleştirirken `SummingMergeTree` tablolar ClickHouse tüm satırları aynı birincil anahtarla değiştirir (veya daha doğru olarak, aynı [sıralama anahtarı](mergetree.md)) sayısal veri türüne sahip sütunlar için özetlenen değerleri içeren bir satır ile. Sıralama anahtarı, tek bir anahtar değeri çok sayıda satıra karşılık gelecek şekilde oluşturulursa, bu, depolama birimini önemli ölçüde azaltır ve veri seçimini hızlandırır.
Motoru birlikte kullanmanızı öneririz `MergeTree`. Mağaza tam veri `MergeTree` tablo ve kullanım `SummingMergeTree` örneğin, rapor hazırlarken toplu veri depolamak için. Böyle bir yaklaşım, yanlış oluşturulmuş bir birincil anahtar nedeniyle değerli verileri kaybetmenizi önleyecektir.
## Tablo oluşturma {#creating-a-table}
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE = SummingMergeTree([columns])
[PARTITION BY expr]
[ORDER BY expr]
[SAMPLE BY expr]
[SETTINGS name=value, ...]
```
İstek parametrelerinin açıklaması için bkz. [istek açıklaması](../../../sql_reference/statements/create.md).
**SummingMergeTree parametreleri**
- `columns` - değerlerin özetleneceği sütunların adlarına sahip bir tuple. İsteğe bağlı parametre.
Sütunlar sayısal tipte olmalı ve birincil anahtarda olmamalıdır.
Eğer `columns` belirtilmemiş, ClickHouse birincil anahtarda olmayan bir sayısal veri türü ile tüm sütunlardaki değerleri özetler.
**Sorgu yan tümceleri**
Oluştururken bir `SummingMergeTree` tablo aynı [yanlar](mergetree.md) oluşturul ,urken olduğu gibi gerekli `MergeTree` Tablo.
<details markdown="1">
<summary>Bir tablo oluşturmak için kullanımdan kaldırılan yöntem</summary>
!!! attention "Dikkat"
Bu yöntemi yeni projelerde kullanmayın ve mümkünse eski projeleri yukarıda açıklanan yönteme geçin.
``` sql
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE [=] SummingMergeTree(date-column [, sampling_expression], (primary, key), index_granularity, [columns])
```
Hariç tüm parametreler `columns` içinde olduğu gibi aynı anlama sahip `MergeTree`.
- `columns` — tuple with names of columns values of which will be summarized. Optional parameter. For a description, see the text above.
</details>
## Kullanım Örneği {#usage-example}
Aşağıdaki tabloyu düşünün:
``` sql
CREATE TABLE summtt
(
key UInt32,
value UInt32
)
ENGINE = SummingMergeTree()
ORDER BY key
```
Veri Ekle:
``` sql
INSERT INTO summtt Values(1,1),(1,2),(2,1)
```
ClickHouse tüm satırları tamamen toplayabilir ([aşağıya bakın](#data-processing)), bu yüzden bir toplama işlevi kullanıyoruz `sum` ve `GROUP BY` sorguda yan tümcesi.
``` sql
SELECT key, sum(value) FROM summtt GROUP BY key
```
``` text
┌─key─┬─sum(value)─┐
│ 2 │ 1 │
│ 1 │ 3 │
└─────┴────────────┘
```
## Veri İşleme {#data-processing}
Veriler bir tabloya eklendiğinde, bunlar olduğu gibi kaydedilir. ClickHouse, verilerin eklenen bölümlerini periyodik olarak birleştirir ve bu, aynı birincil anahtara sahip satırların toplandığı ve sonuçta elde edilen her veri parçası için bir tane ile değiştirildiği zamandır.
ClickHouse can merge the data parts so that different resulting parts of data cat consist rows with the same primary key, i.e. the summation will be incomplete. Therefore (`SELECT`) bir toplama fonksiyonu [toplam()](../../../sql_reference/aggregate_functions/reference.md#agg_function-sum) ve `GROUP BY` yukarıdaki örnekte açıklandığı gibi yan tümcesi bir sorguda kullanılmalıdır.
### Toplama İçin Ortak Kurallar {#common-rules-for-summation}
Sayısal veri türüne sahip sütunlardaki değerler özetlenir. Sütun kümesi parametre tarafından tanımlanır `columns`.
Değerler toplamı için tüm sütunlarda 0 ise, satır silinir.
Sütun birincil anahtarda değilse ve özetlenmezse, mevcut olanlardan rasgele bir değer seçilir.
Değerler, birincil anahtardaki sütunlar için özetlenmez.
### Aggregatefunction Sütunlarındaki toplama {#the-summation-in-the-aggregatefunction-columns}
Sütunlar için [AggregateFunction türü](../../../sql_reference/data_types/aggregatefunction.md) ClickHouse olarak davranır [AggregatingMergeTree](aggregatingmergetree.md) işleve göre motor toplama.
### İç İçe Yapılar {#nested-structures}
Tablo, özel bir şekilde işlenen iç içe geçmiş veri yapılarına sahip olabilir.
İç içe geçmiş bir tablonun adı ile bitiyorsa `Map` ve aşağıdaki kriterleri karşılayan en az iki sütun içerir:
- ilk sütun sayısal `(*Int*, Date, DateTime)` veya bir dize `(String, FixedString)` hadi diyelim `key`,
- diğer sütunlar aritmetik `(*Int*, Float32/64)` hadi diyelim `(values...)`,
sonra bu iç içe geçmiş tablo bir eşleme olarak yorumlanır `key => (values...)` ve satırlarını birleştirirken, iki veri kümesinin öğeleri şu şekilde birleştirilir `key` karşılık gelen bir toplamı ile `(values...)`.
Örnekler:
``` text
[(1, 100)] + [(2, 150)] -> [(1, 100), (2, 150)]
[(1, 100)] + [(1, 150)] -> [(1, 250)]
[(1, 100)] + [(1, 150), (2, 150)] -> [(1, 250), (2, 150)]
[(1, 100), (2, 150)] + [(1, -100)] -> [(2, 150)]
```
Veri isterken, [sumMap (anahtar, değer)](../../../sql_reference/aggregate_functions/reference.md) toplama fonksiyonu `Map`.
İç içe geçmiş veri yapısı için, sütunlarının toplamı için sütun kümesinde belirtmeniz gerekmez.
[Orijinal makale](https://clickhouse.tech/docs/en/operations/table_engines/summingmergetree/) <!--hide-->

Some files were not shown because too many files have changed in this diff Show More