mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-22 07:31:57 +00:00
Merge remote-tracking branch 'upstream/master' into polymorphic-parts
This commit is contained in:
commit
c61f1dbac8
@ -1,42 +1,62 @@
|
||||
#pragma once
|
||||
|
||||
#include <type_traits>
|
||||
#include <boost/range/counting_range.hpp>
|
||||
#include <boost/range/adaptor/transformed.hpp>
|
||||
#include <type_traits>
|
||||
|
||||
|
||||
namespace ext
|
||||
{
|
||||
/// For loop adaptor which is used to iterate through a half-closed interval [begin, end).
|
||||
template <typename BeginType, typename EndType>
|
||||
inline auto range(BeginType begin, EndType end)
|
||||
namespace internal
|
||||
{
|
||||
template <typename ResultType, typename CountingType, typename BeginType, typename EndType>
|
||||
auto rangeImpl(BeginType begin, EndType end)
|
||||
{
|
||||
using CommonType = typename std::common_type<BeginType, EndType>::type;
|
||||
return boost::counting_range<CommonType>(begin, end);
|
||||
}
|
||||
|
||||
template <typename Type>
|
||||
inline auto range(Type end)
|
||||
{
|
||||
return range<Type, Type>(static_cast<Type>(0), end);
|
||||
}
|
||||
|
||||
/// The same as range(), but every value is casted statically to a specified `ValueType`.
|
||||
/// This is useful to iterate through all constants of a enum.
|
||||
template <typename ValueType, typename BeginType, typename EndType>
|
||||
inline auto range_with_static_cast(BeginType begin, EndType end)
|
||||
{
|
||||
using CommonType = typename std::common_type<BeginType, EndType>::type;
|
||||
if constexpr (std::is_same_v<ValueType, CommonType>)
|
||||
return boost::counting_range<CommonType>(begin, end);
|
||||
if constexpr (std::is_same_v<ResultType, CountingType>)
|
||||
return boost::counting_range<CountingType>(static_cast<CountingType>(begin), static_cast<CountingType>(end));
|
||||
else
|
||||
return boost::counting_range<CommonType>(begin, end)
|
||||
| boost::adaptors::transformed([](CommonType x) -> ValueType { return static_cast<ValueType>(x); });
|
||||
}
|
||||
|
||||
template <typename ValueType, typename EndType>
|
||||
inline auto range_with_static_cast(EndType end)
|
||||
{
|
||||
return range_with_static_cast<ValueType, EndType, EndType>(static_cast<EndType>(0), end);
|
||||
return boost::counting_range<CountingType>(static_cast<CountingType>(begin), static_cast<CountingType>(end))
|
||||
| boost::adaptors::transformed([](CountingType x) { return static_cast<ResultType>(x); });
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
/// For loop adaptor which is used to iterate through a half-closed interval [begin, end).
|
||||
/// The parameters `begin` and `end` can have any integral or enum types.
|
||||
template <typename BeginType,
|
||||
typename EndType,
|
||||
typename = std::enable_if_t<
|
||||
(std::is_integral_v<BeginType> || std::is_enum_v<BeginType>) &&
|
||||
(std::is_integral_v<EndType> || std::is_enum_v<EndType>) &&
|
||||
(!std::is_enum_v<BeginType> || !std::is_enum_v<EndType> || std::is_same_v<BeginType, EndType>), void>>
|
||||
inline auto range(BeginType begin, EndType end)
|
||||
{
|
||||
if constexpr (std::is_integral_v<BeginType> && std::is_integral_v<EndType>)
|
||||
{
|
||||
using CommonType = std::common_type_t<BeginType, EndType>;
|
||||
return internal::rangeImpl<CommonType, CommonType>(begin, end);
|
||||
}
|
||||
else if constexpr (std::is_enum_v<BeginType>)
|
||||
{
|
||||
return internal::rangeImpl<BeginType, std::underlying_type_t<BeginType>>(begin, end);
|
||||
}
|
||||
else
|
||||
{
|
||||
return internal::rangeImpl<EndType, std::underlying_type_t<EndType>>(begin, end);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
/// For loop adaptor which is used to iterate through a half-closed interval [0, end).
|
||||
/// The parameter `end` can have any integral or enum type.
|
||||
/// The same as range(0, end).
|
||||
template <typename Type,
|
||||
typename = std::enable_if_t<std::is_integral_v<Type> || std::is_enum_v<Type>, void>>
|
||||
inline auto range(Type end)
|
||||
{
|
||||
if constexpr (std::is_integral_v<Type>)
|
||||
return internal::rangeImpl<Type, Type>(0, end);
|
||||
else
|
||||
return internal::rangeImpl<Type, std::underlying_type_t<Type>>(0, end);
|
||||
}
|
||||
}
|
||||
|
2
debian/control
vendored
2
debian/control
vendored
@ -28,7 +28,7 @@ Description: Client binary for ClickHouse
|
||||
|
||||
Package: clickhouse-common-static
|
||||
Architecture: any
|
||||
Depends: ${shlibs:Depends}, ${misc:Depends}
|
||||
Depends: ${shlibs:Depends}, ${misc:Depends}, tzdata
|
||||
Suggests: clickhouse-common-static-dbg
|
||||
Replaces: clickhouse-common, clickhouse-server-base
|
||||
Provides: clickhouse-common, clickhouse-server-base
|
||||
|
@ -17,6 +17,7 @@ RUN apt-get update \
|
||||
clickhouse-client=$version \
|
||||
clickhouse-common-static=$version \
|
||||
locales \
|
||||
tzdata \
|
||||
&& rm -rf /var/lib/apt/lists/* /var/cache/debconf \
|
||||
&& apt-get clean
|
||||
|
||||
|
@ -21,6 +21,7 @@ RUN apt-get update \
|
||||
locales \
|
||||
ca-certificates \
|
||||
wget \
|
||||
tzata \
|
||||
&& rm -rf \
|
||||
/var/lib/apt/lists/* \
|
||||
/var/cache/debconf \
|
||||
|
@ -104,7 +104,7 @@ ENGINE MergeTree() PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDa
|
||||
|
||||
In the example, we set partitioning by month.
|
||||
|
||||
We also set an expression for sampling as a hash by the user ID. This allows you to pseudorandomize the data in the table for each `CounterID` and `EventDate`. If you define a [SAMPLE](../../../sql-reference/statements/select.md#select-sample-clause) clause when selecting the data, ClickHouse will return an evenly pseudorandom data sample for a subset of users.
|
||||
We also set an expression for sampling as a hash by the user ID. This allows you to pseudorandomize the data in the table for each `CounterID` and `EventDate`. If you define a [SAMPLE](../../../sql-reference/statements/select/sample.md#select-sample-clause) clause when selecting the data, ClickHouse will return an evenly pseudorandom data sample for a subset of users.
|
||||
|
||||
The `index_granularity` setting can be omitted because 8192 is the default value.
|
||||
|
||||
@ -385,7 +385,7 @@ TTL time_column
|
||||
TTL time_column + interval
|
||||
```
|
||||
|
||||
To define `interval`, use [time interval](../../../sql-reference/operators.md#operators-datetime) operators.
|
||||
To define `interval`, use [time interval](../../../sql-reference/operators/index.md#operators-datetime) operators.
|
||||
|
||||
``` sql
|
||||
TTL date_time + INTERVAL 1 MONTH
|
||||
|
@ -5,7 +5,7 @@ toc_title: Join
|
||||
|
||||
# Join {#join}
|
||||
|
||||
Prepared data structure for using in [JOIN](../../../sql-reference/statements/select.md#select-join) operations.
|
||||
Prepared data structure for using in [JOIN](../../../sql-reference/statements/select/join.md#select-join) operations.
|
||||
|
||||
## Creating a Table {#creating-a-table}
|
||||
|
||||
@ -21,8 +21,8 @@ See the detailed description of the [CREATE TABLE](../../../sql-reference/statem
|
||||
|
||||
**Engine Parameters**
|
||||
|
||||
- `join_strictness` – [JOIN strictness](../../../sql-reference/statements/select.md#select-join-strictness).
|
||||
- `join_type` – [JOIN type](../../../sql-reference/statements/select.md#select-join-types).
|
||||
- `join_strictness` – [JOIN strictness](../../../sql-reference/statements/select/join.md#select-join-strictness).
|
||||
- `join_type` – [JOIN type](../../../sql-reference/statements/select/join.md#select-join-types).
|
||||
- `k1[, k2, ...]` – Key columns from the `USING` clause that the `JOIN` operation is made with.
|
||||
|
||||
Enter `join_strictness` and `join_type` parameters without quotes, for example, `Join(ANY, LEFT, col1)`. They must match the `JOIN` operation that the table will be used for. If the parameters don’t match, ClickHouse doesn’t throw an exception and may return incorrect data.
|
||||
@ -98,7 +98,7 @@ When creating a table, the following settings are applied:
|
||||
|
||||
The `Join`-engine tables can’t be used in `GLOBAL JOIN` operations.
|
||||
|
||||
The `Join`-engine allows use [join\_use\_nulls](../../../operations/settings/settings.md#join_use_nulls) setting in the `CREATE TABLE` statement. And [SELECT](../../../sql-reference/statements/select.md) query allows use `join_use_nulls` too. If you have different `join_use_nulls` settings, you can get an error joining table. It depends on kind of JOIN. When you use [joinGet](../../../sql-reference/functions/other-functions.md#joinget) function, you have to use the same `join_use_nulls` setting in `CRATE TABLE` and `SELECT` statements.
|
||||
The `Join`-engine allows use [join\_use\_nulls](../../../operations/settings/settings.md#join_use_nulls) setting in the `CREATE TABLE` statement. And [SELECT](../../../sql-reference/statements/select/index.md) query allows use `join_use_nulls` too. If you have different `join_use_nulls` settings, you can get an error joining table. It depends on kind of JOIN. When you use [joinGet](../../../sql-reference/functions/other-functions.md#joinget) function, you have to use the same `join_use_nulls` setting in `CRATE TABLE` and `SELECT` statements.
|
||||
|
||||
## Data Storage {#data-storage}
|
||||
|
||||
|
@ -27,7 +27,7 @@ NLS_LANG=RUSSIAN_RUSSIA.UTF8
|
||||
|
||||
### Using INTO OUTFILE Clause {#using-into-outfile-clause}
|
||||
|
||||
Add an [INTO OUTFILE](../sql-reference/statements/select.md#into-outfile-clause) clause to your query.
|
||||
Add an [INTO OUTFILE](../sql-reference/statements/select/into-outfile.md#into-outfile-clause) clause to your query.
|
||||
|
||||
For example:
|
||||
|
||||
@ -35,7 +35,7 @@ For example:
|
||||
SELECT * FROM table INTO OUTFILE 'file'
|
||||
```
|
||||
|
||||
By default, ClickHouse uses the [TabSeparated](../interfaces/formats.md#tabseparated) format for output data. To select the [data format](../interfaces/formats.md), use the [FORMAT clause](../sql-reference/statements/select.md#format-clause).
|
||||
By default, ClickHouse uses the [TabSeparated](../interfaces/formats.md#tabseparated) format for output data. To select the [data format](../interfaces/formats.md), use the [FORMAT clause](../sql-reference/statements/select/format.md#format-clause).
|
||||
|
||||
For example:
|
||||
|
||||
|
@ -22,9 +22,9 @@ The required volume of RAM depends on:
|
||||
- The complexity of queries.
|
||||
- The amount of data that is processed in queries.
|
||||
|
||||
To calculate the required volume of RAM, you should estimate the size of temporary data for [GROUP BY](../sql-reference/statements/select.md#select-group-by-clause), [DISTINCT](../sql-reference/statements/select.md#select-distinct), [JOIN](../sql-reference/statements/select.md#select-join) and other operations you use.
|
||||
To calculate the required volume of RAM, you should estimate the size of temporary data for [GROUP BY](../sql-reference/statements/select/group-by.md#select-group-by-clause), [DISTINCT](../sql-reference/statements/select/distinct.md#select-distinct), [JOIN](../sql-reference/statements/select/join.md#select-join) and other operations you use.
|
||||
|
||||
ClickHouse can use external memory for temporary data. See [GROUP BY in External Memory](../sql-reference/statements/select.md#select-group-by-in-external-memory) for details.
|
||||
ClickHouse can use external memory for temporary data. See [GROUP BY in External Memory](../sql-reference/statements/select/group-by.md#select-group-by-in-external-memory) for details.
|
||||
|
||||
## Swap File {#swap-file}
|
||||
|
||||
|
@ -80,11 +80,11 @@ Using the ‘any’ value lets you run an approximation of GROUP BY. The quality
|
||||
|
||||
## max\_bytes\_before\_external\_group\_by {#settings-max_bytes_before_external_group_by}
|
||||
|
||||
Enables or disables execution of `GROUP BY` clauses in external memory. See [GROUP BY in external memory](../../sql-reference/statements/select.md#select-group-by-in-external-memory).
|
||||
Enables or disables execution of `GROUP BY` clauses in external memory. See [GROUP BY in external memory](../../sql-reference/statements/select/group-by.md#select-group-by-in-external-memory).
|
||||
|
||||
Possible values:
|
||||
|
||||
- Maximum volume of RAM (in bytes) that can be used by the single [GROUP BY](../../sql-reference/statements/select.md#select-group-by-clause) operation.
|
||||
- Maximum volume of RAM (in bytes) that can be used by the single [GROUP BY](../../sql-reference/statements/select/group-by.md#select-group-by-clause) operation.
|
||||
- 0 — `GROUP BY` in external memory disabled.
|
||||
|
||||
Default value: 0.
|
||||
@ -232,7 +232,7 @@ What to do when the amount of data exceeds one of the limits: ‘throw’ or ‘
|
||||
|
||||
Limits the number of rows in the hash table that is used when joining tables.
|
||||
|
||||
This settings applies to [SELECT … JOIN](../../sql-reference/statements/select.md#select-join) operations and the [Join](../../engines/table-engines/special/join.md) table engine.
|
||||
This settings applies to [SELECT … JOIN](../../sql-reference/statements/select/join.md#select-join) operations and the [Join](../../engines/table-engines/special/join.md) table engine.
|
||||
|
||||
If a query contains multiple joins, ClickHouse checks this setting for every intermediate result.
|
||||
|
||||
@ -249,7 +249,7 @@ Default value: 0.
|
||||
|
||||
Limits the size in bytes of the hash table used when joining tables.
|
||||
|
||||
This settings applies to [SELECT … JOIN](../../sql-reference/statements/select.md#select-join) operations and [Join table engine](../../engines/table-engines/special/join.md).
|
||||
This settings applies to [SELECT … JOIN](../../sql-reference/statements/select/join.md#select-join) operations and [Join table engine](../../engines/table-engines/special/join.md).
|
||||
|
||||
If the query contains joins, ClickHouse checks this setting for every intermediate result.
|
||||
|
||||
@ -278,7 +278,7 @@ Default value: `THROW`.
|
||||
|
||||
**See Also**
|
||||
|
||||
- [JOIN clause](../../sql-reference/statements/select.md#select-join)
|
||||
- [JOIN clause](../../sql-reference/statements/select/join.md#select-join)
|
||||
- [Join table engine](../../engines/table-engines/special/join.md)
|
||||
|
||||
## max\_partitions\_per\_insert\_block {#max-partitions-per-insert-block}
|
||||
|
@ -2,7 +2,7 @@
|
||||
|
||||
## distributed\_product\_mode {#distributed-product-mode}
|
||||
|
||||
Changes the behavior of [distributed subqueries](../../sql-reference/statements/select.md).
|
||||
Changes the behavior of [distributed subqueries](../../sql-reference/operators/in.md).
|
||||
|
||||
ClickHouse applies this setting when the query contains the product of distributed tables, i.e. when the query for a distributed table contains a non-GLOBAL subquery for the distributed table.
|
||||
|
||||
@ -362,7 +362,7 @@ See also:
|
||||
|
||||
## join\_default\_strictness {#settings-join_default_strictness}
|
||||
|
||||
Sets default strictness for [JOIN clauses](../../sql-reference/statements/select.md#select-join).
|
||||
Sets default strictness for [JOIN clauses](../../sql-reference/statements/select/join.md#select-join).
|
||||
|
||||
Possible values:
|
||||
|
||||
@ -389,13 +389,13 @@ Default value: 0.
|
||||
|
||||
See also:
|
||||
|
||||
- [JOIN clause](../../sql-reference/statements/select.md#select-join)
|
||||
- [JOIN clause](../../sql-reference/statements/select/join.md#select-join)
|
||||
- [Join table engine](../../engines/table-engines/special/join.md)
|
||||
- [join\_default\_strictness](#settings-join_default_strictness)
|
||||
|
||||
## join\_use\_nulls {#join_use_nulls}
|
||||
|
||||
Sets the type of [JOIN](../../sql-reference/statements/select.md) behavior. When merging tables, empty cells may appear. ClickHouse fills them differently based on this setting.
|
||||
Sets the type of [JOIN](../../sql-reference/statements/select/join.md) behavior. When merging tables, empty cells may appear. ClickHouse fills them differently based on this setting.
|
||||
|
||||
Possible values:
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
toc_priority: 37
|
||||
toc_title: Aggregate function combinators
|
||||
toc_title: Combinators
|
||||
---
|
||||
|
||||
# Aggregate Function Combinators {#aggregate_functions_combinators}
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
toc_priority: 38
|
||||
toc_title: Parametric aggregate functions
|
||||
toc_title: Parametric
|
||||
---
|
||||
|
||||
# Parametric Aggregate Functions {#aggregate_functions_parametric}
|
||||
@ -314,7 +314,7 @@ Result:
|
||||
## retention {#retention}
|
||||
|
||||
The function takes as arguments a set of conditions from 1 to 32 arguments of type `UInt8` that indicate whether a certain condition was met for the event.
|
||||
Any condition can be specified as an argument (as in [WHERE](../../sql-reference/statements/select.md#select-where)).
|
||||
Any condition can be specified as an argument (as in [WHERE](../../sql-reference/statements/select/where.md#select-where)).
|
||||
|
||||
The conditions, except the first, apply in pairs: the result of the second will be true if the first and second are true, of the third if the first and fird are true, etc.
|
||||
|
||||
|
@ -3,7 +3,7 @@ toc_priority: 36
|
||||
toc_title: Reference
|
||||
---
|
||||
|
||||
# Function Reference {#aggregate-functions-reference}
|
||||
# Aggregate Function Reference {#aggregate-functions-reference}
|
||||
|
||||
## count {#agg_function-count}
|
||||
|
||||
@ -1259,7 +1259,7 @@ Otherwise, the result of the calculation is rounded to the nearest multiple of 1
|
||||
Type: `Float32`.
|
||||
|
||||
!!! note "Note"
|
||||
If no values are passed to the function (when using `quantileTimingIf`), [NaN](../../sql-reference/data-types/float.md#data_type-float-nan-inf) is returned. The purpose of this is to differentiate these cases from cases that result in zero. See [ORDER BY clause](../statements/select.md#select-order-by) for notes on sorting `NaN` values.
|
||||
If no values are passed to the function (when using `quantileTimingIf`), [NaN](../../sql-reference/data-types/float.md#data_type-float-nan-inf) is returned. The purpose of this is to differentiate these cases from cases that result in zero. See [ORDER BY clause](../statements/select/order-by.md#select-order-by) for notes on sorting `NaN` values.
|
||||
|
||||
**Example**
|
||||
|
||||
@ -1344,7 +1344,7 @@ Otherwise, the result of the calculation is rounded to the nearest multiple of 1
|
||||
Type: `Float32`.
|
||||
|
||||
!!! note "Note"
|
||||
If no values are passed to the function (when using `quantileTimingIf`), [NaN](../../sql-reference/data-types/float.md#data_type-float-nan-inf) is returned. The purpose of this is to differentiate these cases from cases that result in zero. See [ORDER BY clause](../statements/select.md#select-order-by) for notes on sorting `NaN` values.
|
||||
If no values are passed to the function (when using `quantileTimingIf`), [NaN](../../sql-reference/data-types/float.md#data_type-float-nan-inf) is returned. The purpose of this is to differentiate these cases from cases that result in zero. See [ORDER BY clause](../statements/select/order-by.md#select-order-by) for notes on sorting `NaN` values.
|
||||
|
||||
**Example**
|
||||
|
||||
|
@ -5,7 +5,7 @@ toc_title: AggregateFunction
|
||||
|
||||
# AggregateFunction {#data-type-aggregatefunction}
|
||||
|
||||
Aggregate functions can have an implementation-defined intermediate state that can be serialized to an AggregateFunction(…) data type and stored in a table, usually, by means of [a materialized view](../../sql-reference/statements/select.md#create-view). The common way to produce an aggregate function state is by calling the aggregate function with the `-State` suffix. To get the final result of aggregation in the future, you must use the same aggregate function with the `-Merge`suffix.
|
||||
Aggregate functions can have an implementation-defined intermediate state that can be serialized to an AggregateFunction(…) data type and stored in a table, usually, by means of [a materialized view](../../sql-reference/statements/create.md#create-view). The common way to produce an aggregate function state is by calling the aggregate function with the `-State` suffix. To get the final result of aggregation in the future, you must use the same aggregate function with the `-Merge`suffix.
|
||||
|
||||
`AggregateFunction(name, types_of_arguments…)` — parametric data type.
|
||||
|
||||
|
@ -121,7 +121,7 @@ FROM dt
|
||||
- [Functions for working with arrays](../../sql-reference/functions/array-functions.md)
|
||||
- [The `date_time_input_format` setting](../../operations/settings/settings.md#settings-date_time_input_format)
|
||||
- [The `timezone` server configuration parameter](../../operations/server-configuration-parameters/settings.md#server_configuration_parameters-timezone)
|
||||
- [Operators for working with dates and times](../../sql-reference/operators.md#operators-datetime)
|
||||
- [Operators for working with dates and times](../../sql-reference/operators/index.md#operators-datetime)
|
||||
- [The `Date` data type](date.md)
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/data_types/datetime/) <!--hide-->
|
||||
|
@ -97,6 +97,6 @@ FROM dt
|
||||
- [Functions for working with arrays](../../sql-reference/functions/array-functions.md)
|
||||
- [The `date_time_input_format` setting](../../operations/settings/settings.md#settings-date_time_input_format)
|
||||
- [The `timezone` server configuration parameter](../../operations/server-configuration-parameters/settings.md#server_configuration_parameters-timezone)
|
||||
- [Operators for working with dates and times](../../sql-reference/operators.md#operators-datetime)
|
||||
- [Operators for working with dates and times](../../sql-reference/operators/index.md#operators-datetime)
|
||||
- [`Date` data type](date.md)
|
||||
- [`DateTime` data type](datetime.md)
|
||||
|
@ -80,6 +80,6 @@ SELECT 0 / 0
|
||||
└──────────────┘
|
||||
```
|
||||
|
||||
See the rules for `NaN` sorting in the section [ORDER BY clause](../sql_reference/statements/select.md).
|
||||
See the rules for `NaN` sorting in the section [ORDER BY clause](../sql_reference/statements/select/order-by.md).
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/data_types/float/) <!--hide-->
|
||||
|
@ -5,7 +5,7 @@ toc_title: Interval
|
||||
|
||||
# Interval {#data-type-interval}
|
||||
|
||||
The family of data types representing time and date intervals. The resulting types of the [INTERVAL](../../../sql-reference/operators.md#operator-interval) operator.
|
||||
The family of data types representing time and date intervals. The resulting types of the [INTERVAL](../../../sql-reference/operators/index.md#operator-interval) operator.
|
||||
|
||||
!!! warning "Warning"
|
||||
`Interval` data type values can’t be stored in tables.
|
||||
@ -79,5 +79,5 @@ Code: 43. DB::Exception: Received from localhost:9000. DB::Exception: Wrong argu
|
||||
|
||||
## See Also {#see-also}
|
||||
|
||||
- [INTERVAL](../../../sql-reference/operators.md#operator-interval) operator
|
||||
- [INTERVAL](../../../sql-reference/operators/index.md#operator-interval) operator
|
||||
- [toInterval](../../../sql-reference/functions/type-conversion-functions.md#function-tointerval) type convertion functions
|
||||
|
@ -5,6 +5,6 @@ toc_title: Set
|
||||
|
||||
# Set {#set}
|
||||
|
||||
Used for the right half of an [IN](../../statements/select.md#select-in-operators) expression.
|
||||
Used for the right half of an [IN](../../operators/in.md#select-in-operators) expression.
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/data_types/special_data_types/set/) <!--hide-->
|
||||
|
@ -7,7 +7,7 @@ toc_title: Tuple(T1, T2, ...)
|
||||
|
||||
A tuple of elements, each having an individual [type](index.md#data_types).
|
||||
|
||||
Tuples are used for temporary column grouping. Columns can be grouped when an IN expression is used in a query, and for specifying certain formal parameters of lambda functions. For more information, see the sections [IN operators](../../sql-reference/statements/select.md) and [Higher order functions](../../sql-reference/functions/higher-order-functions.md).
|
||||
Tuples are used for temporary column grouping. Columns can be grouped when an IN expression is used in a query, and for specifying certain formal parameters of lambda functions. For more information, see the sections [IN operators](../../sql-reference/operators/in.md) and [Higher order functions](../../sql-reference/functions/higher-order-functions.md).
|
||||
|
||||
Tuples can be the result of a query. In this case, for text formats other than JSON, values are comma-separated in brackets. In JSON formats, tuples are output as arrays (in square brackets).
|
||||
|
||||
|
@ -113,7 +113,7 @@ Returns `then` if the `cond` evaluates to be true (greater than zero), otherwise
|
||||
|
||||
## multiIf {#multiif}
|
||||
|
||||
Allows you to write the [CASE](../operators.md#operator_case) operator more compactly in the query.
|
||||
Allows you to write the [CASE](../operators/index.md#operator_case) operator more compactly in the query.
|
||||
|
||||
Syntax: `multiIf(cond_1, then_1, cond_2, then_2, ..., else)`
|
||||
|
||||
|
@ -7,7 +7,7 @@ toc_title: Implementing the IN Operator
|
||||
|
||||
## in, notIn, globalIn, globalNotIn {#in-functions}
|
||||
|
||||
See the section [IN operators](../statements/select.md#select-in-operators).
|
||||
See the section [IN operators](../operators/in.md#select-in-operators).
|
||||
|
||||
## tuple(x, y, …), operator (x, y, …) {#tuplex-y-operator-x-y}
|
||||
|
||||
|
@ -7,10 +7,12 @@ toc_title: hidden
|
||||
|
||||
# SQL Reference {#sql-reference}
|
||||
|
||||
- [SELECT](statements/select.md)
|
||||
ClickHouse supports the following types of queries:
|
||||
|
||||
- [SELECT](statements/select/index.md)
|
||||
- [INSERT INTO](statements/insert-into.md)
|
||||
- [CREATE](statements/create.md)
|
||||
- [ALTER](statements/alter.md#query_language_queries_alter)
|
||||
- [Other types of queries](statements/misc.md)
|
||||
|
||||
[Original article](https://clickhouse.tech/docs/en/query_language/) <!--hide-->
|
||||
[Original article](https://clickhouse.tech/docs/en/sql-reference/) <!--hide-->
|
||||
|
199
docs/en/sql-reference/operators/in.md
Normal file
199
docs/en/sql-reference/operators/in.md
Normal file
@ -0,0 +1,199 @@
|
||||
### 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#null-literal) 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.
|
@ -59,7 +59,7 @@ ClickHouse transforms operators to their corresponding functions at the query pa
|
||||
|
||||
## Operators for Working with Data Sets {#operators-for-working-with-data-sets}
|
||||
|
||||
*See [IN operators](statements/select.md#select-in-operators).*
|
||||
*See [IN operators](in.md).*
|
||||
|
||||
`a IN ...` – The `in(a, b)` function.
|
||||
|
||||
@ -90,7 +90,7 @@ The `part` parameter specifies which part of the date to retrieve. The following
|
||||
|
||||
The `part` parameter is case-insensitive.
|
||||
|
||||
The `date` parameter specifies the date or the time to process. Either [Date](../sql-reference/data-types/date.md) or [DateTime](../sql-reference/data-types/datetime.md) type is supported.
|
||||
The `date` parameter specifies the date or the time to process. Either [Date](../../sql-reference/data-types/date.md) or [DateTime](../../sql-reference/data-types/datetime.md) type is supported.
|
||||
|
||||
Examples:
|
||||
|
||||
@ -137,7 +137,7 @@ You can see more examples in [tests](https://github.com/ClickHouse/ClickHouse/bl
|
||||
|
||||
### INTERVAL {#operator-interval}
|
||||
|
||||
Creates an [Interval](../sql-reference/data-types/special-data-types/interval.md)-type value that should be used in arithmetical operations with [Date](../sql-reference/data-types/date.md) and [DateTime](../sql-reference/data-types/datetime.md)-type values.
|
||||
Creates an [Interval](../../sql-reference/data-types/special-data-types/interval.md)-type value that should be used in arithmetical operations with [Date](../../sql-reference/data-types/date.md) and [DateTime](../../sql-reference/data-types/datetime.md)-type values.
|
||||
|
||||
Types of intervals:
|
||||
- `SECOND`
|
||||
@ -166,8 +166,8 @@ SELECT now() AS current_date_time, current_date_time + INTERVAL 4 DAY + INTERVAL
|
||||
|
||||
**See Also**
|
||||
|
||||
- [Interval](../sql-reference/data-types/special-data-types/interval.md) data type
|
||||
- [toInterval](../sql-reference/functions/type-conversion-functions.md#function-tointerval) type convertion functions
|
||||
- [Interval](../../sql-reference/data-types/special-data-types/interval.md) data type
|
||||
- [toInterval](../../sql-reference/functions/type-conversion-functions.md#function-tointerval) type convertion functions
|
||||
|
||||
## Logical Negation Operator {#logical-negation-operator}
|
||||
|
||||
@ -187,7 +187,7 @@ SELECT now() AS current_date_time, current_date_time + INTERVAL 4 DAY + INTERVAL
|
||||
|
||||
Note:
|
||||
|
||||
The conditional operator calculates the values of b and c, then checks whether condition a is met, and then returns the corresponding value. If `b` or `C` is an [arrayJoin()](../sql-reference/functions/array-join.md#functions_arrayjoin) function, each row will be replicated regardless of the “a” condition.
|
||||
The conditional operator calculates the values of b and c, then checks whether condition a is met, and then returns the corresponding value. If `b` or `C` is an [arrayJoin()](../../sql-reference/functions/array-join.md#functions_arrayjoin) function, each row will be replicated regardless of the “a” condition.
|
||||
|
||||
## Conditional Expression {#operator_case}
|
||||
|
||||
@ -236,7 +236,7 @@ ClickHouse supports the `IS NULL` and `IS NOT NULL` operators.
|
||||
|
||||
### IS NULL {#operator-is-null}
|
||||
|
||||
- For [Nullable](../sql-reference/data-types/nullable.md) type values, the `IS NULL` operator returns:
|
||||
- For [Nullable](../../sql-reference/data-types/nullable.md) type values, the `IS NULL` operator returns:
|
||||
- `1`, if the value is `NULL`.
|
||||
- `0` otherwise.
|
||||
- For other values, the `IS NULL` operator always returns `0`.
|
||||
@ -255,7 +255,7 @@ SELECT x+100 FROM t_null WHERE y IS NULL
|
||||
|
||||
### IS NOT NULL {#is-not-null}
|
||||
|
||||
- For [Nullable](../sql-reference/data-types/nullable.md) type values, the `IS NOT NULL` operator returns:
|
||||
- For [Nullable](../../sql-reference/data-types/nullable.md) type values, the `IS NOT NULL` operator returns:
|
||||
- `0`, if the value is `NULL`.
|
||||
- `1` otherwise.
|
||||
- For other values, the `IS NOT NULL` operator always returns `1`.
|
@ -219,7 +219,7 @@ Some queries by their implementation require a set of privileges. For example, t
|
||||
|
||||
### SELECT {#grant-select}
|
||||
|
||||
Allows to perform [SELECT](select.md) queries.
|
||||
Allows to perform [SELECT](select/index.md) queries.
|
||||
|
||||
Privilege level: `COLUMN`.
|
||||
|
||||
|
File diff suppressed because it is too large
Load Diff
281
docs/en/sql-reference/statements/select/array-join.md
Normal file
281
docs/en/sql-reference/statements/select/array-join.md
Normal file
@ -0,0 +1,281 @@
|
||||
---
|
||||
toc_title: ARRAY JOIN
|
||||
---
|
||||
|
||||
# ARRAY JOIN Clause {#select-array-join-clause}
|
||||
|
||||
It is a common operation for tables that contain an array column to produce a new table that has a column with each individual array element of that initial column, while values of other columns are duplicated. This is the basic case of what `ARRAY JOIN` clause does.
|
||||
|
||||
Its name comes from the fact that it can be looked at as executing `JOIN` with an array or nested data structure. The intent is similar to the [arrayJoin](../../functions/array-join.md#functions_arrayjoin) function, but the clause functionality is broader.
|
||||
|
||||
Syntax:
|
||||
|
||||
``` sql
|
||||
SELECT <expr_list>
|
||||
FROM <left_subquery>
|
||||
[LEFT] ARRAY JOIN <array>
|
||||
[WHERE|PREWHERE <expr>]
|
||||
...
|
||||
```
|
||||
|
||||
You can specify only one `ARRAY JOIN` clause in a `SELECT` query.
|
||||
|
||||
Supported types of `ARRAY JOIN` are listed below:
|
||||
|
||||
- `ARRAY JOIN` - In base case, empty arrays are not included in the result of `JOIN`.
|
||||
- `LEFT ARRAY JOIN` - The result of `JOIN` contains rows with empty arrays. The value for an empty array is set to the default value for the array element type (usually 0, empty string or NULL).
|
||||
|
||||
## Basic ARRAY JOIN Examples
|
||||
|
||||
The examples below demonstrate the usage of the `ARRAY JOIN` and `LEFT ARRAY JOIN` clauses. Let’s create a table with an [Array](../../../sql-reference/data-types/array.md) type column and insert values into it:
|
||||
|
||||
``` sql
|
||||
CREATE TABLE arrays_test
|
||||
(
|
||||
s String,
|
||||
arr Array(UInt8)
|
||||
) ENGINE = Memory;
|
||||
|
||||
INSERT INTO arrays_test
|
||||
VALUES ('Hello', [1,2]), ('World', [3,4,5]), ('Goodbye', []);
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─s───────────┬─arr─────┐
|
||||
│ Hello │ [1,2] │
|
||||
│ World │ [3,4,5] │
|
||||
│ Goodbye │ [] │
|
||||
└─────────────┴─────────┘
|
||||
```
|
||||
|
||||
The example below uses the `ARRAY JOIN` clause:
|
||||
|
||||
``` sql
|
||||
SELECT s, arr
|
||||
FROM arrays_test
|
||||
ARRAY JOIN arr;
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─s─────┬─arr─┐
|
||||
│ Hello │ 1 │
|
||||
│ Hello │ 2 │
|
||||
│ World │ 3 │
|
||||
│ World │ 4 │
|
||||
│ World │ 5 │
|
||||
└───────┴─────┘
|
||||
```
|
||||
|
||||
The next example uses the `LEFT ARRAY JOIN` clause:
|
||||
|
||||
``` sql
|
||||
SELECT s, arr
|
||||
FROM arrays_test
|
||||
LEFT ARRAY JOIN arr;
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─s───────────┬─arr─┐
|
||||
│ Hello │ 1 │
|
||||
│ Hello │ 2 │
|
||||
│ World │ 3 │
|
||||
│ World │ 4 │
|
||||
│ World │ 5 │
|
||||
│ Goodbye │ 0 │
|
||||
└─────────────┴─────┘
|
||||
```
|
||||
|
||||
## Using Aliases {#using-aliases}
|
||||
|
||||
An alias can be specified for an array in the `ARRAY JOIN` clause. In this case, an array item can be accessed by this alias, but the array itself is accessed by the original name. Example:
|
||||
|
||||
``` sql
|
||||
SELECT s, arr, a
|
||||
FROM arrays_test
|
||||
ARRAY JOIN arr AS a;
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─s─────┬─arr─────┬─a─┐
|
||||
│ Hello │ [1,2] │ 1 │
|
||||
│ Hello │ [1,2] │ 2 │
|
||||
│ World │ [3,4,5] │ 3 │
|
||||
│ World │ [3,4,5] │ 4 │
|
||||
│ World │ [3,4,5] │ 5 │
|
||||
└───────┴─────────┴───┘
|
||||
```
|
||||
|
||||
Using aliases, you can perform `ARRAY JOIN` with an external array. For example:
|
||||
|
||||
``` sql
|
||||
SELECT s, arr_external
|
||||
FROM arrays_test
|
||||
ARRAY JOIN [1, 2, 3] AS arr_external;
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─s───────────┬─arr_external─┐
|
||||
│ Hello │ 1 │
|
||||
│ Hello │ 2 │
|
||||
│ Hello │ 3 │
|
||||
│ World │ 1 │
|
||||
│ World │ 2 │
|
||||
│ World │ 3 │
|
||||
│ Goodbye │ 1 │
|
||||
│ Goodbye │ 2 │
|
||||
│ Goodbye │ 3 │
|
||||
└─────────────┴──────────────┘
|
||||
```
|
||||
|
||||
Multiple arrays can be comma-separated in the `ARRAY JOIN` clause. In this case, `JOIN` is performed with them simultaneously (the direct sum, not the cartesian product). Note that all the arrays must have the same size. Example:
|
||||
|
||||
``` sql
|
||||
SELECT s, arr, a, num, mapped
|
||||
FROM arrays_test
|
||||
ARRAY JOIN arr AS a, arrayEnumerate(arr) AS num, arrayMap(x -> x + 1, arr) AS mapped;
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─s─────┬─arr─────┬─a─┬─num─┬─mapped─┐
|
||||
│ Hello │ [1,2] │ 1 │ 1 │ 2 │
|
||||
│ Hello │ [1,2] │ 2 │ 2 │ 3 │
|
||||
│ World │ [3,4,5] │ 3 │ 1 │ 4 │
|
||||
│ World │ [3,4,5] │ 4 │ 2 │ 5 │
|
||||
│ World │ [3,4,5] │ 5 │ 3 │ 6 │
|
||||
└───────┴─────────┴───┴─────┴────────┘
|
||||
```
|
||||
|
||||
The example below uses the [arrayEnumerate](../../../sql-reference/functions/array-functions.md#array_functions-arrayenumerate) function:
|
||||
|
||||
``` sql
|
||||
SELECT s, arr, a, num, arrayEnumerate(arr)
|
||||
FROM arrays_test
|
||||
ARRAY JOIN arr AS a, arrayEnumerate(arr) AS num;
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─s─────┬─arr─────┬─a─┬─num─┬─arrayEnumerate(arr)─┐
|
||||
│ Hello │ [1,2] │ 1 │ 1 │ [1,2] │
|
||||
│ Hello │ [1,2] │ 2 │ 2 │ [1,2] │
|
||||
│ World │ [3,4,5] │ 3 │ 1 │ [1,2,3] │
|
||||
│ World │ [3,4,5] │ 4 │ 2 │ [1,2,3] │
|
||||
│ World │ [3,4,5] │ 5 │ 3 │ [1,2,3] │
|
||||
└───────┴─────────┴───┴─────┴─────────────────────┘
|
||||
```
|
||||
|
||||
## ARRAY JOIN with Nested Data Structure {#array-join-with-nested-data-structure}
|
||||
|
||||
`ARRAY JOIN` also works with [nested data structures](../../../sql-reference/data-types/nested-data-structures/nested.md):
|
||||
|
||||
``` sql
|
||||
CREATE TABLE nested_test
|
||||
(
|
||||
s String,
|
||||
nest Nested(
|
||||
x UInt8,
|
||||
y UInt32)
|
||||
) ENGINE = Memory;
|
||||
|
||||
INSERT INTO nested_test
|
||||
VALUES ('Hello', [1,2], [10,20]), ('World', [3,4,5], [30,40,50]), ('Goodbye', [], []);
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─s───────┬─nest.x──┬─nest.y─────┐
|
||||
│ Hello │ [1,2] │ [10,20] │
|
||||
│ World │ [3,4,5] │ [30,40,50] │
|
||||
│ Goodbye │ [] │ [] │
|
||||
└─────────┴─────────┴────────────┘
|
||||
```
|
||||
|
||||
``` sql
|
||||
SELECT s, `nest.x`, `nest.y`
|
||||
FROM nested_test
|
||||
ARRAY JOIN nest;
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─s─────┬─nest.x─┬─nest.y─┐
|
||||
│ Hello │ 1 │ 10 │
|
||||
│ Hello │ 2 │ 20 │
|
||||
│ World │ 3 │ 30 │
|
||||
│ World │ 4 │ 40 │
|
||||
│ World │ 5 │ 50 │
|
||||
└───────┴────────┴────────┘
|
||||
```
|
||||
|
||||
When specifying names of nested data structures in `ARRAY JOIN`, the meaning is the same as `ARRAY JOIN` with all the array elements that it consists of. Examples are listed below:
|
||||
|
||||
``` sql
|
||||
SELECT s, `nest.x`, `nest.y`
|
||||
FROM nested_test
|
||||
ARRAY JOIN `nest.x`, `nest.y`;
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─s─────┬─nest.x─┬─nest.y─┐
|
||||
│ Hello │ 1 │ 10 │
|
||||
│ Hello │ 2 │ 20 │
|
||||
│ World │ 3 │ 30 │
|
||||
│ World │ 4 │ 40 │
|
||||
│ World │ 5 │ 50 │
|
||||
└───────┴────────┴────────┘
|
||||
```
|
||||
|
||||
This variation also makes sense:
|
||||
|
||||
``` sql
|
||||
SELECT s, `nest.x`, `nest.y`
|
||||
FROM nested_test
|
||||
ARRAY JOIN `nest.x`;
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─s─────┬─nest.x─┬─nest.y─────┐
|
||||
│ Hello │ 1 │ [10,20] │
|
||||
│ Hello │ 2 │ [10,20] │
|
||||
│ World │ 3 │ [30,40,50] │
|
||||
│ World │ 4 │ [30,40,50] │
|
||||
│ World │ 5 │ [30,40,50] │
|
||||
└───────┴────────┴────────────┘
|
||||
```
|
||||
|
||||
An alias may be used for a nested data structure, in order to select either the `JOIN` result or the source array. Example:
|
||||
|
||||
``` sql
|
||||
SELECT s, `n.x`, `n.y`, `nest.x`, `nest.y`
|
||||
FROM nested_test
|
||||
ARRAY JOIN nest AS n;
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─s─────┬─n.x─┬─n.y─┬─nest.x──┬─nest.y─────┐
|
||||
│ Hello │ 1 │ 10 │ [1,2] │ [10,20] │
|
||||
│ Hello │ 2 │ 20 │ [1,2] │ [10,20] │
|
||||
│ World │ 3 │ 30 │ [3,4,5] │ [30,40,50] │
|
||||
│ World │ 4 │ 40 │ [3,4,5] │ [30,40,50] │
|
||||
│ World │ 5 │ 50 │ [3,4,5] │ [30,40,50] │
|
||||
└───────┴─────┴─────┴─────────┴────────────┘
|
||||
```
|
||||
|
||||
Example of using the [arrayEnumerate](../../../sql-reference/functions/array-functions.md#array_functions-arrayenumerate) function:
|
||||
|
||||
``` sql
|
||||
SELECT s, `n.x`, `n.y`, `nest.x`, `nest.y`, num
|
||||
FROM nested_test
|
||||
ARRAY JOIN nest AS n, arrayEnumerate(`nest.x`) AS num;
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─s─────┬─n.x─┬─n.y─┬─nest.x──┬─nest.y─────┬─num─┐
|
||||
│ Hello │ 1 │ 10 │ [1,2] │ [10,20] │ 1 │
|
||||
│ Hello │ 2 │ 20 │ [1,2] │ [10,20] │ 2 │
|
||||
│ World │ 3 │ 30 │ [3,4,5] │ [30,40,50] │ 1 │
|
||||
│ World │ 4 │ 40 │ [3,4,5] │ [30,40,50] │ 2 │
|
||||
│ World │ 5 │ 50 │ [3,4,5] │ [30,40,50] │ 3 │
|
||||
└───────┴─────┴─────┴─────────┴────────────┴─────┘
|
||||
```
|
||||
|
||||
## Implementation Details
|
||||
|
||||
The query execution order is optimized when running `ARRAY JOIN`. Although `ARRAY JOIN` must always be specified before the [WHERE](where.md)/[PREWHERE](prewhere.md) clause in a query, technically they can be performed in any order, unless result of `ARRAY JOIN` is used for filtering. The processing order is controlled by the query optimizer.
|
62
docs/en/sql-reference/statements/select/distinct.md
Normal file
62
docs/en/sql-reference/statements/select/distinct.md
Normal file
@ -0,0 +1,62 @@
|
||||
---
|
||||
toc_title: DISTINCT
|
||||
---
|
||||
|
||||
# DISTINCT Clause {#select-distinct}
|
||||
|
||||
If `SELECT DISTINCT` is specified, only unique rows will remain in a query result. Thus only a single row will remain out of all the sets of fully matching rows in the result.
|
||||
|
||||
## Null Processing
|
||||
|
||||
`DISTINCT` works with [NULL](../../syntax.md#null-literal) as if `NULL` were a specific value, and `NULL==NULL`. In other words, in the `DISTINCT` results, different combinations with `NULL` occur only once. It differs from `NULL` processing in most other contexts.
|
||||
|
||||
## Alternatives
|
||||
|
||||
It is possible to obtain the same result by applying [GROUP BY](group-by.md) across the same set of values as specified as `SELECT` clause, without using any aggregate functions. But there are few differences from `GROUP BY` approach:
|
||||
|
||||
- `DISTINCT` can be applied together with `GROUP BY`.
|
||||
- When [ORDER BY](order-by.md) is omitted and [LIMIT](limit.md) 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.
|
||||
|
||||
## Limitations
|
||||
|
||||
`DISTINCT` is not supported if `SELECT` has at least one array column.
|
||||
|
||||
## Examples
|
||||
|
||||
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.
|
17
docs/en/sql-reference/statements/select/format.md
Normal file
17
docs/en/sql-reference/statements/select/format.md
Normal file
@ -0,0 +1,17 @@
|
||||
---
|
||||
toc_title: FORMAT
|
||||
---
|
||||
|
||||
# FORMAT Clause {#format-clause}
|
||||
|
||||
ClickHouse supports a wide range of [serialization formats](../../../interfaces/formats.md) that can be used on query results among other things. There are multiple ways to choose a format for `SELECT` output, one of them is to specify `FORMAT format` at the end of query to get resulting data in any specific format.
|
||||
|
||||
Specific format might be used either for convenience, integration with other systems or performance gain.
|
||||
|
||||
## Default Format
|
||||
|
||||
If the `FORMAT` clause is omitted, the default format is used, which depends on both the settings and the interface used for accessing the ClickHouse server. For the [HTTP interface](../../../interfaces/http.md) and the [command-line client ](../../../interfaces/cli.md) in batch mode, the default format is `TabSeparated`. For the command-line client in interactive mode, the default format is `PrettyCompact` (it produces compact human-readable tables).
|
||||
|
||||
## Implementation Details
|
||||
|
||||
When using the command-line client, data is always passed over the network in an internal efficient format (`Native`). The client independently interprets the `FORMAT` clause of the query and formats the data itself (thus relieving the network and the server from the extra load).
|
43
docs/en/sql-reference/statements/select/from.md
Normal file
43
docs/en/sql-reference/statements/select/from.md
Normal file
@ -0,0 +1,43 @@
|
||||
---
|
||||
toc_title: FROM
|
||||
---
|
||||
|
||||
# FROM Clause {#select-from}
|
||||
|
||||
The `FROM` clause specifies the source to read data from:
|
||||
|
||||
- [Table](../../../engines/table-engines/index.md)
|
||||
- [Subquery](index.md) {## TODO: better link ##}
|
||||
- [Table function](../../table-functions/index.md#table-functions)
|
||||
|
||||
[JOIN](join.md) and [ARRAY JOIN](array-join.md) clauses may also be used to extend the functionality of the `FROM` clause.
|
||||
|
||||
Subquery is another `SELECT` query that may be specified in parenthesis inside `FROM` clause.
|
||||
|
||||
`FROM` clause can contain multiple data sources, separated by commas, which is equivalent of performing [CROSS JOIN](join.md) on them.
|
||||
|
||||
## FINAL Modifier {#select-from-final}
|
||||
|
||||
When `FINAL` is specified, ClickHouse fully merges the data before returning the result and thus performs all data transformations that happen during merges for the given table engine.
|
||||
|
||||
It is applicable when selecting data from tables that use the [MergeTree](../../../engines/table-engines/mergetree-family/mergetree.md)-engine family (except `GraphiteMergeTree`). Also supported for:
|
||||
|
||||
- [Replicated](../../../engines/table-engines/mergetree-family/replication.md) versions of `MergeTree` engines.
|
||||
- [View](../../../engines/table-engines/special/view.md), [Buffer](../../../engines/table-engines/special/buffer.md), [Distributed](../../../engines/table-engines/special/distributed.md), and [MaterializedView](../../../engines/table-engines/special/materializedview.md) engines that operate over other engines, provided they were created over `MergeTree`-engine tables.
|
||||
|
||||
### Drawbacks
|
||||
|
||||
Queries that use `FINAL` are executed not as fast as similar queries that don’t, because:
|
||||
|
||||
- Query is executed in a single thread and data is merged during query execution.
|
||||
- Queries with `FINAL` read primary key columns in addition to the columns specified in the query.
|
||||
|
||||
**In most cases, avoid using `FINAL`.** The common approach is to use different queries that assume the background processes of the `MergeTree` engine have't happened yet and deal with it by applying aggregation (for example, to discard duplicates). {## TODO: examples ##}
|
||||
|
||||
## Implementation Details
|
||||
|
||||
If the `FROM` clause is omitted, data will be read from the `system.one` table.
|
||||
The `system.one` table contains exactly one row (this table fulfills the same purpose as the DUAL table found in other DBMSs).
|
||||
|
||||
To execute a query, all the columns listed in the query are extracted from the appropriate table. Any columns not needed for the external query are thrown out of the subqueries.
|
||||
If a query does not list any columns (for example, `SELECT count() FROM t`), some column is extracted from the table anyway (the smallest one is preferred), in order to calculate the number of rows.
|
131
docs/en/sql-reference/statements/select/group-by.md
Normal file
131
docs/en/sql-reference/statements/select/group-by.md
Normal file
@ -0,0 +1,131 @@
|
||||
---
|
||||
toc_title: GROUP BY
|
||||
---
|
||||
|
||||
# GROUP BY Clause {#select-group-by-clause}
|
||||
|
||||
`GROUP BY` clause switches the `SELECT` query into an aggregation mode, which works as follows:
|
||||
|
||||
- `GROUP BY` clause contains a list of expressions (or a single expression, which is considered to be the list of length one). This list acts as a “grouping key”, while each individual expression will be referred to as a “key expressions”.
|
||||
- All the expressions in the [SELECT](index.md), [HAVING](having.md), and [ORDER BY](order-by.md) clauses **must** be calculated based on key expressions **or** on [aggregate functions](../../../sql-reference/aggregate-functions/index.md) over non-key expressions (including plain columns). In other words, each column selected from the table must be used either in a key expression or inside an aggregate function, but not both.
|
||||
- Result of aggregating `SELECT` query will contain as many rows as there were unique values of “grouping key” in source table. Usually this signficantly reduces the row count, often by orders of magnitude, but not necessarily: row count stays the same if all “grouping key” values were distinct.
|
||||
|
||||
!!! note "Note"
|
||||
There's an additional way to run aggregation over a table. If a query contains table columns only inside aggregate functions, the `GROUP BY clause` can be omitted, and aggregation by an empty set of keys is assumed. Such queries always return exactly one row.
|
||||
|
||||
## NULL Processing {#null-processing}
|
||||
|
||||
For grouping, ClickHouse interprets [NULL](../../syntax.md#null-literal) as a value, and `NULL==NULL`. It differs from `NULL` processing in most other contexts.
|
||||
|
||||
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 only produced in `JSON*`, `TabSeparated*`, and `Pretty*` formats, separately from the other rows:
|
||||
|
||||
- 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.
|
||||
- In the other formats it is not available.
|
||||
|
||||
`WITH TOTALS` can be run in different ways when [HAVING](having.md) is present. The behavior depends on the `totals_mode` setting.
|
||||
|
||||
### Configuring Totals Processing
|
||||
|
||||
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](join.md) clause (in this case, the respective total values are combined).
|
||||
|
||||
## Examples
|
||||
|
||||
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()`.
|
||||
|
||||
## Implementation Details
|
||||
|
||||
Aggregation is one of the most important features of a column-oriented DBMS, and thus it's implementation is one of the most heavily optimized parts of ClickHouse. By default, aggregation is done in memory using a hash-table. It has 40+ specializations that are chosen automatically depending on “grouping key” data types.
|
||||
|
||||
### 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 data 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](order-by.md) with a [LIMIT](limit.md) 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`).
|
13
docs/en/sql-reference/statements/select/having.md
Normal file
13
docs/en/sql-reference/statements/select/having.md
Normal file
@ -0,0 +1,13 @@
|
||||
---
|
||||
toc_title: HAVING
|
||||
---
|
||||
|
||||
# HAVING Clause {#having-clause}
|
||||
|
||||
Allows filtering the aggregation results produced by [GROUP BY](group-by.md). It is similar to the [WHERE](where.md) clause, but the difference is that `WHERE` is performed before aggregation, while `HAVING` is performed after it.
|
||||
|
||||
It is possible to reference aggregation results from `SELECT` clause in `HAVING` clause by their alias. Alternatively, `HAVING` clause can filter on results of additional aggregates that are not returned in query results.
|
||||
|
||||
## Limitations
|
||||
|
||||
`HAVING` can’t be used if aggregation is not performed. Use `WHERE` instead.
|
161
docs/en/sql-reference/statements/select/index.md
Normal file
161
docs/en/sql-reference/statements/select/index.md
Normal file
@ -0,0 +1,161 @@
|
||||
---
|
||||
toc_priority: 33
|
||||
toc_folder_title: SELECT
|
||||
toc_title: Queries Syntax
|
||||
---
|
||||
|
||||
# SELECT Queries Syntax {#select-queries-syntax}
|
||||
|
||||
`SELECT` performs data retrieval.
|
||||
|
||||
``` sql
|
||||
[WITH expr_list|(subquery)]
|
||||
SELECT [DISTINCT] expr_list
|
||||
[FROM [db.]table | (subquery) | table_function] [FINAL]
|
||||
[SAMPLE sample_coeff]
|
||||
[ARRAY JOIN ...]
|
||||
[GLOBAL] [ANY|ALL] [INNER|LEFT|RIGHT|FULL|CROSS] [OUTER] JOIN (subquery)|table USING columns_list
|
||||
[PREWHERE expr]
|
||||
[WHERE expr]
|
||||
[GROUP BY expr_list] [WITH TOTALS]
|
||||
[HAVING expr]
|
||||
[ORDER BY expr_list]
|
||||
[LIMIT [offset_value, ]n BY columns]
|
||||
[LIMIT [n, ]m]
|
||||
[UNION ALL ...]
|
||||
[INTO OUTFILE filename]
|
||||
[FORMAT format]
|
||||
```
|
||||
|
||||
All clauses are optional, except for the required list of expressions immediately after `SELECT` which is covered in more detail [below](#select-clause).
|
||||
|
||||
Specifics of each optional clause are covered in separate sections, which are listed in the same order as they are executed:
|
||||
|
||||
- [WITH clause](with.md)
|
||||
- [FROM clause](from.md)
|
||||
- [SAMPLE clause](sample.md)
|
||||
- [JOIN clause](join.md)
|
||||
- [PREWHERE clause](prewhere.md)
|
||||
- [WHERE clause](where.md)
|
||||
- [GROUP BY clause](group-by.md)
|
||||
- [LIMIT BY clause](limit-by.md)
|
||||
- [HAVING clause](having.md)
|
||||
- [SELECT clause](#select-clause)
|
||||
- [DISTINCT clause](distinct.md)
|
||||
- [LIMIT clause](limit.md)
|
||||
- [UNION ALL clause](union-all.md)
|
||||
- [INTO OUTFILE clause](into-outfile.md)
|
||||
- [FORMAT clause](format.md)
|
||||
|
||||
## SELECT Clause {#select-clause}
|
||||
|
||||
[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](group-by.md) 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.
|
||||
|
||||
### Asterisk
|
||||
|
||||
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.
|
||||
|
||||
### 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}
|
||||
|
||||
You can use synonyms (`AS` aliases) in any part of a query.
|
||||
|
||||
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).
|
||||
|
||||
|
||||
## Implementation Details
|
||||
|
||||
If the query omits the `DISTINCT`, `GROUP BY` and `ORDER BY` clauses and the `IN` and `JOIN` subqueries, the query will be completely stream processed, using O(1) amount of RAM. Otherwise, the query might consume a lot of RAM if the appropriate restrictions are not specified:
|
||||
|
||||
- `max_memory_usage`
|
||||
- `max_rows_to_group_by`
|
||||
- `max_rows_to_sort`
|
||||
- `max_rows_in_distinct`
|
||||
- `max_bytes_in_distinct`
|
||||
- `max_rows_in_set`
|
||||
- `max_bytes_in_set`
|
||||
- `max_rows_in_join`
|
||||
- `max_bytes_in_join`
|
||||
- `max_bytes_before_external_sort`
|
||||
- `max_bytes_before_external_group_by`
|
||||
|
||||
For more information, see the section “Settings”. It is possible to use external sorting (saving temporary tables to a disk) and external aggregation.
|
||||
|
||||
|
||||
{## [Original article](https://clickhouse.tech/docs/en/sql-reference/statements/select/) ##}
|
13
docs/en/sql-reference/statements/select/into-outfile.md
Normal file
13
docs/en/sql-reference/statements/select/into-outfile.md
Normal file
@ -0,0 +1,13 @@
|
||||
---
|
||||
toc_title: INTO OUTFILE
|
||||
---
|
||||
|
||||
# INTO OUTFILE Clause {#into-outfile-clause}
|
||||
|
||||
Add the `INTO OUTFILE filename` clause (where filename is a string literal) to `SELECT query` to redirect its output to the specified file on the client-side.
|
||||
|
||||
## Implementation Details
|
||||
|
||||
- This functionality is available in the [command-line client](../../../interfaces/cli.md) and [clickhouse-local](../../../operations/utilities/clickhouse-local.md). Thus a query sent via [HTTP interface](../../../interfaces/http.md) will fail.
|
||||
- The query will fail if a file with the same filename already exists.
|
||||
- The default [output format](../../../interfaces/formats.md) is `TabSeparated` (like in the command-line client batch mode).
|
190
docs/en/sql-reference/statements/select/join.md
Normal file
190
docs/en/sql-reference/statements/select/join.md
Normal file
@ -0,0 +1,190 @@
|
||||
---
|
||||
toc_title: JOIN
|
||||
---
|
||||
|
||||
# JOIN Clause {#select-join}
|
||||
|
||||
Join produces a new table by combining columns from one or multiple tables by using values common to each. It is a common operation in databases with SQL support, which corresponds to [relational algebra](https://en.wikipedia.org/wiki/Relational_algebra#Joins_and_join-like_operators) join. The special case of one table join is often referred to as "self-join".
|
||||
|
||||
Syntax:
|
||||
``` sql
|
||||
SELECT <expr_list>
|
||||
FROM <left_table>
|
||||
[GLOBAL] [ANY|ALL|ASOF] [INNER|LEFT|RIGHT|FULL|CROSS] [OUTER|SEMI|ANTI] JOIN <right_table>
|
||||
(ON <expr_list>)|(USING <column_list>) ...
|
||||
```
|
||||
|
||||
Expressions from `ON` clause and columns from `USING` clause are called "join keys". Unless otherwise stated, join produces a [Cartesian product](https://en.wikipedia.org/wiki/Cartesian_product) from rows with matching "join keys", which might produce results with much more rows than the source tables.
|
||||
|
||||
## Supported Types of JOIN {#select-join-types}
|
||||
|
||||
All standard [SQL JOIN](https://en.wikipedia.org/wiki/Join_(SQL)) types are supported:
|
||||
|
||||
- `INNER JOIN`, only matching rows are returned.
|
||||
- `LEFT OUTER JOIN`, non-matching rows from left table are returned in addition to matching rows.
|
||||
- `RIGHT OUTER JOIN`, non-matching rows from right table are returned in addition to matching rows.
|
||||
- `FULL OUTER JOIN`, non-matching rows from both tables are returned in addition to matching rows.
|
||||
- `CROSS JOIN`, produces cartesian product of whole tables, "join keys" are **not** specified.
|
||||
|
||||
`JOIN` without specified type implies `INNER`. Keyword `OUTER` can be safely omitted. Alternative syntax for `CROSS JOIN` is specifying multiple tables in [FROM clause](from.md) separated by commas.
|
||||
|
||||
Additional join types available in ClickHouse:
|
||||
|
||||
- `LEFT SEMI JOIN` and `RIGHT SEMI JOIN`, a whitelist on "join keys", without producing a cartesian product.
|
||||
- `LEFT ANTI JOIN` and `RIGHT ANTI JOIN`, a blacklist on "join keys", without producing a cartesian product.
|
||||
|
||||
## Strictness {#select-join-strictness}
|
||||
|
||||
Modifies how matching by "join keys" is performed
|
||||
|
||||
- `ALL` — The standard `JOIN` behavior in SQL as described above. The default.
|
||||
- `ANY` — Partially (for opposite side of `LEFT` and `RIGHT`) or completely (for `INNER` and `FULL`) disables the cartesian product for standard `JOIN` types.
|
||||
- `ASOF` — For joining sequences with a non-exact match. `ASOF JOIN` usage is described below.
|
||||
|
||||
!!! note "Note"
|
||||
The default strictness value can be overriden using [join\_default\_strictness](../../../operations/settings/settings.md#settings-join_default_strictness) setting.
|
||||
|
||||
|
||||
### ASOF JOIN Usage
|
||||
|
||||
`ASOF JOIN` is useful when you need to join records that have no exact match.
|
||||
|
||||
Tables for `ASOF JOIN` must have an ordered sequence column. This column cannot be alone in a table, and should be one of the data types: `UInt32`, `UInt64`, `Float32`, `Float64`, `Date`, and `DateTime`.
|
||||
|
||||
Syntax `ASOF JOIN ... ON`:
|
||||
|
||||
``` sql
|
||||
SELECT expressions_list
|
||||
FROM table_1
|
||||
ASOF LEFT JOIN table_2
|
||||
ON equi_cond AND closest_match_cond
|
||||
```
|
||||
|
||||
You can use any number of equality conditions and exactly one closest match condition. For example, `SELECT count() FROM table_1 ASOF LEFT JOIN table_2 ON table_1.a == table_2.b AND table_2.t <= table_1.t`.
|
||||
|
||||
Conditions supported for the closest match: `>`, `>=`, `<`, `<=`.
|
||||
|
||||
Syntax `ASOF JOIN ... USING`:
|
||||
|
||||
``` sql
|
||||
SELECT expressions_list
|
||||
FROM table_1
|
||||
ASOF JOIN table_2
|
||||
USING (equi_column1, ... equi_columnN, asof_column)
|
||||
```
|
||||
|
||||
`ASOF JOIN` uses `equi_columnX` for joining on equality and `asof_column` for joining on the closest match with the `table_1.asof_column >= table_2.asof_column` condition. The `asof_column` column always the last one in the `USING` clause.
|
||||
|
||||
For example, consider the following tables:
|
||||
|
||||
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
|
||||
... ...
|
||||
|
||||
`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.
|
||||
|
||||
## Distributed Join {#global-join}
|
||||
|
||||
There are two ways to execute join involving distributed tables:
|
||||
|
||||
- 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 [Distributed subqueries](../../operators/in.md#select-distributed-subqueries) section.
|
||||
|
||||
## Usage Recommendations {#usage-recommendations}
|
||||
|
||||
### 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](../../../sql-reference/syntax.md#null-literal) are not joined.
|
||||
|
||||
### Syntax
|
||||
|
||||
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 `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.
|
||||
|
||||
### 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.
|
||||
|
||||
### Performance
|
||||
|
||||
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.
|
||||
|
||||
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](../../operators/in.md) instead of `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 [External dictionaries](../../dictionaries/external-dictionaries/external-dicts.md) section.
|
||||
|
||||
### Memory Limitations
|
||||
|
||||
By default, ClickHouse uses the [hash join](https://en.wikipedia.org/wiki/Hash_join) algorithm. ClickHouse takes the `<right_table>` and creates a hash table for it in RAM. After some threshold of memory consumption, ClickHouse falls back to merge join algorithm.
|
||||
|
||||
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.
|
||||
|
||||
## Examples
|
||||
|
||||
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 │
|
||||
└───────────┴────────┴────────┘
|
||||
```
|
70
docs/en/sql-reference/statements/select/limit-by.md
Normal file
70
docs/en/sql-reference/statements/select/limit-by.md
Normal file
@ -0,0 +1,70 @@
|
||||
---
|
||||
toc_title: LIMIT BY
|
||||
---
|
||||
|
||||
# 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 variants:
|
||||
|
||||
- `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](order-by.md) 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.
|
||||
|
||||
!!! note "Note"
|
||||
`LIMIT BY` is not related to [LIMIT](limit.md). 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
|
||||
```
|
13
docs/en/sql-reference/statements/select/limit.md
Normal file
13
docs/en/sql-reference/statements/select/limit.md
Normal file
@ -0,0 +1,13 @@
|
||||
---
|
||||
toc_title: LIMIT
|
||||
---
|
||||
|
||||
# LIMIT Clause {#limit-clause}
|
||||
|
||||
`LIMIT m` allows to select the first `m` rows from the result.
|
||||
|
||||
`LIMIT n, m` allows to select the `m` rows from the result after skipping the first `n` rows. The `LIMIT m OFFSET n` syntax is equivalent.
|
||||
|
||||
`n` and `m` must be non-negative integers.
|
||||
|
||||
If there is no [ORDER BY](order-by.md) clause that explicitly sorts results, the choice of rows for the result may be arbitrary and non-deterministic.
|
71
docs/en/sql-reference/statements/select/order-by.md
Normal file
71
docs/en/sql-reference/statements/select/order-by.md
Normal file
@ -0,0 +1,71 @@
|
||||
---
|
||||
toc_title: ORDER BY
|
||||
---
|
||||
|
||||
# ORDER BY Clause {#select-order-by}
|
||||
|
||||
The `ORDER BY` clause contains a list of expressions, which can each be attributed with `DESC` (descending) or `ASC` (ascending) modifier which determine the sorting direction. If the direction is not specified, `ASC` is assumed, so it's usually omitted. The sorting direction applies to a single expression, not to the entire list. Example: `ORDER BY Visits DESC, SearchPhrase`
|
||||
|
||||
Rows that have identical values for the list of sorting expressions are output in an arbitrary order, which can also be non-deterministic (different each time).
|
||||
If the ORDER BY clause is omitted, the order of the rows is also undefined, and may be non-deterministic as well.
|
||||
|
||||
## Sorting of Special Values
|
||||
|
||||
There are two approaches to `NaN` and `NULL` sorting order:
|
||||
|
||||
- By default or with the `NULLS LAST` modifier: first the values, then `NaN`, then `NULL`.
|
||||
- With the `NULLS FIRST` modifier: first `NULL`, then `NaN`, then other values.
|
||||
|
||||
### 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.
|
||||
|
||||
## Collation Support
|
||||
|
||||
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.
|
||||
|
||||
## Implementation Details
|
||||
|
||||
Less RAM is used if a small enough [LIMIT](limit.md) 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](group-by.md) 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.
|
22
docs/en/sql-reference/statements/select/prewhere.md
Normal file
22
docs/en/sql-reference/statements/select/prewhere.md
Normal file
@ -0,0 +1,22 @@
|
||||
---
|
||||
toc_title: PREWHERE
|
||||
---
|
||||
|
||||
# PREWHERE Clause {#prewhere-clause}
|
||||
|
||||
Prewhere is an optimization to apply filtering more efficiently. It is enabled by default even if `PREWHERE` clause is not specified explicitly. It works by automatically moving part of [WHERE](where.md) condition to prewhere stage. The role of `PREWHERE` clause is only to control this optimization if you think that you know how to do it better than it happens by default.
|
||||
|
||||
With prewhere optimization, at first only the columns necessary for executing prewhere expression are read. Then the other columns are read that are needed for running the rest of the query, but only those blocks where the prewhere expression is "true" at least for some rows. If there are a lot of blocks where prewhere expression is "false" for all rows and prewhere needs less columns than other parts of query, this often allows to read a lot less data from disk for query execution.
|
||||
|
||||
## Controlling Prewhere Manually
|
||||
|
||||
The clause has the same meaning as the `WHERE` clause. The difference is in which data is read from the table. When manually controlling `PREWHERE` for 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.
|
||||
|
||||
A query may simultaneously specify `PREWHERE` and `WHERE`. In this case, `PREWHERE` precedes `WHERE`.
|
||||
|
||||
If the `optimize_move_to_prewhere` setting is set to 0, heuristics to automatically move parts of expressions from `WHERE` to `PREWHERE` are disabled.
|
||||
|
||||
## Limitations
|
||||
|
||||
`PREWHERE` is only supported by tables from the `*MergeTree` family.
|
||||
|
112
docs/en/sql-reference/statements/select/sample.md
Normal file
112
docs/en/sql-reference/statements/select/sample.md
Normal file
@ -0,0 +1,112 @@
|
||||
---
|
||||
toc_title: SAMPLE
|
||||
---
|
||||
|
||||
# SAMPLE Clause {#select-sample-clause}
|
||||
|
||||
The `SAMPLE` clause allows for approximated `SELECT` query processing.
|
||||
|
||||
When data sampling is enabled, the query is not performed on all the data, but only on a certain fraction of data (sample). For example, if you need to calculate statistics for all the visits, it is enough to execute the query on the 1/10 fraction of all the visits and then multiply the result by 10.
|
||||
|
||||
Approximated query processing can be useful in the following cases:
|
||||
|
||||
- When you have strict timing requirements (like \<100ms) but you can’t justify the cost of additional hardware resources to meet them.
|
||||
- When your raw data is not accurate, so approximation doesn’t noticeably degrade the quality.
|
||||
- Business requirements target approximate results (for cost-effectiveness, or to market exact results to premium users).
|
||||
|
||||
!!! note "Note"
|
||||
You can only use sampling with the tables in the [MergeTree](../../../engines/table-engines/mergetree-family/mergetree.md) family, and only if the sampling expression was specified during table creation (see [MergeTree engine](../../../engines/table-engines/mergetree-family/mergetree.md#table_engine-mergetree-creating-a-table)).
|
||||
|
||||
The features of data sampling are listed below:
|
||||
|
||||
- Data sampling is a deterministic mechanism. The result of the same `SELECT .. SAMPLE` query is always the same.
|
||||
- Sampling works consistently for different tables. For tables with a single sampling key, a sample with the same coefficient always selects the same subset of possible data. For example, a sample of user IDs takes rows with the same subset of all the possible user IDs from different tables. This means that you can use the sample in subqueries in the [IN](../../operators/in.md) clause. Also, you can join samples using the [JOIN](join.md) clause.
|
||||
- Sampling allows reading less data from a disk. Note that you must specify the sampling key correctly. For more information, see [Creating a MergeTree Table](../../../engines/table-engines/mergetree-family/mergetree.md#table_engine-mergetree-creating-a-table).
|
||||
|
||||
For the `SAMPLE` clause the following syntax is supported:
|
||||
|
||||
| SAMPLE Clause Syntax | Description |
|
||||
|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `SAMPLE k` | Here `k` is the number from 0 to 1.</br>The query is executed on `k` fraction of data. For example, `SAMPLE 0.1` runs the query on 10% of data. [Read more](#select-sample-k) |
|
||||
| `SAMPLE n` | Here `n` is a sufficiently large integer.</br>The query is executed on a sample of at least `n` rows (but not significantly more than this). For example, `SAMPLE 10000000` runs the query on a minimum of 10,000,000 rows. [Read more](#select-sample-n) |
|
||||
| `SAMPLE k OFFSET m` | Here `k` and `m` are the numbers from 0 to 1.</br>The query is executed on a sample of `k` fraction of the data. The data used for the sample is offset by `m` fraction. [Read more](#select-sample-offset) |
|
||||
|
||||
## SAMPLE K {#select-sample-k}
|
||||
|
||||
Here `k` is the number from 0 to 1 (both fractional and decimal notations are supported). For example, `SAMPLE 1/2` or `SAMPLE 0.5`.
|
||||
|
||||
In a `SAMPLE k` clause, the sample is taken from the `k` fraction of data. The example is shown below:
|
||||
|
||||
``` sql
|
||||
SELECT
|
||||
Title,
|
||||
count() * 10 AS PageViews
|
||||
FROM hits_distributed
|
||||
SAMPLE 0.1
|
||||
WHERE
|
||||
CounterID = 34
|
||||
GROUP BY Title
|
||||
ORDER BY PageViews DESC LIMIT 1000
|
||||
```
|
||||
|
||||
In this example, the query is executed on a sample from 0.1 (10%) of data. Values of aggregate functions are not corrected automatically, so to get an approximate result, the value `count()` is manually multiplied by 10.
|
||||
|
||||
## SAMPLE N {#select-sample-n}
|
||||
|
||||
Here `n` is a sufficiently large integer. For example, `SAMPLE 10000000`.
|
||||
|
||||
In this case, the query is executed on a sample of at least `n` rows (but not significantly more than this). For example, `SAMPLE 10000000` runs the query on a minimum of 10,000,000 rows.
|
||||
|
||||
Since the minimum unit for data reading is one granule (its size is set by the `index_granularity` setting), it makes sense to set a sample that is much larger than the size of the granule.
|
||||
|
||||
When using the `SAMPLE n` clause, you don’t know which relative percent of data was processed. So you don’t know the coefficient the aggregate functions should be multiplied by. Use the `_sample_factor` virtual column to get the approximate result.
|
||||
|
||||
The `_sample_factor` column contains relative coefficients that are calculated dynamically. This column is created automatically when you [create](../../../engines/table-engines/mergetree-family/mergetree.md#table_engine-mergetree-creating-a-table) a table with the specified sampling key. The usage examples of the `_sample_factor` column are shown below.
|
||||
|
||||
Let’s consider the table `visits`, which contains the statistics about site visits. The first example shows how to calculate the number of page views:
|
||||
|
||||
``` sql
|
||||
SELECT sum(PageViews * _sample_factor)
|
||||
FROM visits
|
||||
SAMPLE 10000000
|
||||
```
|
||||
|
||||
The next example shows how to calculate the total number of visits:
|
||||
|
||||
``` sql
|
||||
SELECT sum(_sample_factor)
|
||||
FROM visits
|
||||
SAMPLE 10000000
|
||||
```
|
||||
|
||||
The example below shows how to calculate the average session duration. Note that you don’t need to use the relative coefficient to calculate the average values.
|
||||
|
||||
``` sql
|
||||
SELECT avg(Duration)
|
||||
FROM visits
|
||||
SAMPLE 10000000
|
||||
```
|
||||
|
||||
## SAMPLE K OFFSET M {#select-sample-offset}
|
||||
|
||||
Here `k` and `m` are numbers from 0 to 1. Examples are shown below.
|
||||
|
||||
**Example 1**
|
||||
|
||||
``` sql
|
||||
SAMPLE 1/10
|
||||
```
|
||||
|
||||
In this example, the sample is 1/10th of all data:
|
||||
|
||||
`[++------------]`
|
||||
|
||||
**Example 2**
|
||||
|
||||
``` sql
|
||||
SAMPLE 1/10 OFFSET 1/2
|
||||
```
|
||||
|
||||
Here, a sample of 10% is taken from the second half of the data.
|
||||
|
||||
`[------++------]`
|
34
docs/en/sql-reference/statements/select/union-all.md
Normal file
34
docs/en/sql-reference/statements/select/union-all.md
Normal file
@ -0,0 +1,34 @@
|
||||
---
|
||||
toc_title: UNION ALL
|
||||
---
|
||||
|
||||
# UNION ALL Clause {#union-all-clause}
|
||||
|
||||
You can use `UNION ALL` to combine any number of `SELECT` queries by extending their results. 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
|
||||
```
|
||||
|
||||
Result columns are matched by their index (order inside `SELECT`). If column names do not match, names for the final result are 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 round brackets. [ORDER BY](order-by.md) and [LIMIT](limit.md) 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](from.md) clause.
|
||||
|
||||
## Limitations
|
||||
|
||||
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`.
|
||||
|
||||
## Implementation Details
|
||||
|
||||
Queries that are parts of `UNION ALL` can be run simultaneously, and their results can be mixed together.
|
14
docs/en/sql-reference/statements/select/where.md
Normal file
14
docs/en/sql-reference/statements/select/where.md
Normal file
@ -0,0 +1,14 @@
|
||||
---
|
||||
toc_title: WHERE
|
||||
---
|
||||
|
||||
# WHERE Clause {#select-where}
|
||||
|
||||
`WHERE` clause allows to filter the data that is coming from [FROM](from.md) clause of `SELECT`.
|
||||
|
||||
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. Rows where this expression evaluates to 0 are expluded from further transformations or result.
|
||||
|
||||
`WHERE` expression is evaluated on the ability to use indexes and partition pruning, if the underlying table engine supports that.
|
||||
|
||||
!!! note "Note"
|
||||
There's a filtering optimization called [prewhere](prewhere.md).
|
79
docs/en/sql-reference/statements/select/with.md
Normal file
79
docs/en/sql-reference/statements/select/with.md
Normal file
@ -0,0 +1,79 @@
|
||||
---
|
||||
toc_title: WITH
|
||||
---
|
||||
|
||||
# WITH Clause {#with-clause}
|
||||
|
||||
This section provides support for Common Table Expressions ([CTE](https://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL)), so the results of `WITH` clause can be used in the rest of `SELECT` query.
|
||||
|
||||
## Limitations
|
||||
|
||||
1. Recursive queries are not supported.
|
||||
2. When subquery is used inside WITH section, it’s result should be scalar with exactly one row.
|
||||
3. Expression’s results are not available in subqueries.
|
||||
|
||||
## Examples
|
||||
|
||||
**Example 1:** Using constant expression as “variable”
|
||||
|
||||
``` sql
|
||||
WITH '2019-08-01 15:23:00' as ts_upper_bound
|
||||
SELECT *
|
||||
FROM hits
|
||||
WHERE
|
||||
EventDate = toDate(ts_upper_bound) AND
|
||||
EventTime <= ts_upper_bound
|
||||
```
|
||||
|
||||
**Example 2:** Evicting sum(bytes) expression result from SELECT clause column list
|
||||
|
||||
``` sql
|
||||
WITH sum(bytes) as s
|
||||
SELECT
|
||||
formatReadableSize(s),
|
||||
table
|
||||
FROM system.parts
|
||||
GROUP BY table
|
||||
ORDER BY s
|
||||
```
|
||||
|
||||
**Example 3:** Using results of scalar subquery
|
||||
|
||||
``` sql
|
||||
/* this example would return TOP 10 of most huge tables */
|
||||
WITH
|
||||
(
|
||||
SELECT sum(bytes)
|
||||
FROM system.parts
|
||||
WHERE active
|
||||
) AS total_disk_usage
|
||||
SELECT
|
||||
(sum(bytes) / total_disk_usage) * 100 AS table_disk_usage,
|
||||
table
|
||||
FROM system.parts
|
||||
GROUP BY table
|
||||
ORDER BY table_disk_usage DESC
|
||||
LIMIT 10
|
||||
```
|
||||
|
||||
**Example 4:** Re-using expression in subquery
|
||||
|
||||
As a workaround for current limitation for expression usage in subqueries, you may duplicate it.
|
||||
|
||||
``` sql
|
||||
WITH ['hello'] AS hello
|
||||
SELECT
|
||||
hello,
|
||||
*
|
||||
FROM
|
||||
(
|
||||
WITH ['hello'] AS hello
|
||||
SELECT hello
|
||||
)
|
||||
```
|
||||
|
||||
``` text
|
||||
┌─hello─────┬─hello─────┐
|
||||
│ ['hello'] │ ['hello'] │
|
||||
└───────────┴───────────┘
|
||||
```
|
@ -101,7 +101,6 @@ SHOW DICTIONARIES FROM db LIKE '%reg%' LIMIT 2
|
||||
```
|
||||
|
||||
|
||||
|
||||
## SHOW GRANTS {#show-grants-statement}
|
||||
|
||||
Shows privileges for a user.
|
||||
|
@ -101,7 +101,7 @@ Depending on the data format (input or output), `NULL` may have a different repr
|
||||
|
||||
There are many nuances to processing `NULL`. For example, if at least one of the arguments of a comparison operation is `NULL`, the result of this operation is also `NULL`. The same is true for multiplication, addition, and other operations. For more information, read the documentation for each operation.
|
||||
|
||||
In queries, you can check `NULL` using the [IS NULL](operators.md#operator-is-null) and [IS NOT NULL](operators.md) operators and the related functions `isNull` and `isNotNull`.
|
||||
In queries, you can check `NULL` using the [IS NULL](operators/index.md#operator-is-null) and [IS NOT NULL](operators/index.md) operators and the related functions `isNull` and `isNotNull`.
|
||||
|
||||
## Functions {#functions}
|
||||
|
||||
|
@ -10,7 +10,7 @@ Table functions are methods for constructing tables.
|
||||
|
||||
You can use table functions in:
|
||||
|
||||
- [FROM](../statements/select.md#select-from) clause of the `SELECT` query.
|
||||
- [FROM](../statements/select/from.md) clause of the `SELECT` query.
|
||||
|
||||
The method for creating a temporary table that is available only in the current query. The table is deleted when the query finishes.
|
||||
|
||||
|
@ -1,14 +1,16 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 1
|
||||
toc_title: Nube
|
||||
---
|
||||
|
||||
# Proveedores De Servicios En La Nube De ClickHouse {#clickhouse-cloud-service-providers}
|
||||
# Proveedores de servicios en la nube de ClickHouse {#clickhouse-cloud-service-providers}
|
||||
|
||||
!!! info "INFO"
|
||||
Si ha lanzado una nube pública con el servicio ClickHouse administrado, no dude en [abrir una solicitud de extracción](https://github.com/ClickHouse/ClickHouse/edit/master/docs/en/commercial/cloud.md) añadiéndolo a la siguiente lista.
|
||||
|
||||
## Nube De Yandex {#yandex-cloud}
|
||||
## Nube de Yandex {#yandex-cloud}
|
||||
|
||||
[Servicio administrado de Yandex para ClickHouse](https://cloud.yandex.com/services/managed-clickhouse?utm_source=referrals&utm_medium=clickhouseofficialsite&utm_campaign=link3) proporciona las siguientes características clave:
|
||||
|
||||
|
@ -1,8 +1,9 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
toc_folder_title: Commercial
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_folder_title: Comercial
|
||||
toc_priority: 70
|
||||
toc_title: Comercial
|
||||
---
|
||||
|
||||
|
||||
|
@ -1 +0,0 @@
|
||||
../../en/commercial/support.md
|
23
docs/es/commercial/support.md
Normal file
23
docs/es/commercial/support.md
Normal file
@ -0,0 +1,23 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 3
|
||||
toc_title: Apoyo
|
||||
---
|
||||
|
||||
# Proveedores de servicios de soporte comercial ClickHouse {#clickhouse-commercial-support-service-providers}
|
||||
|
||||
!!! info "INFO"
|
||||
Si ha lanzado un servicio de soporte comercial ClickHouse, no dude en [abrir una solicitud de extracción](https://github.com/ClickHouse/ClickHouse/edit/master/docs/en/commercial/support.md) añadiéndolo a la siguiente lista.
|
||||
|
||||
## Altinidad {#altinity}
|
||||
|
||||
Altinity ha ofrecido soporte y servicios empresariales ClickHouse desde 2017. Los clientes de Altinity van desde empresas Fortune 100 hasta startups. Visitar [Más información](https://www.altinity.com/) para más información.
|
||||
|
||||
## Mafiree {#mafiree}
|
||||
|
||||
[Descripción del servicio](http://mafiree.com/clickhouse-analytics-services.php)
|
||||
|
||||
## MinervaDB {#minervadb}
|
||||
|
||||
[Descripción del servicio](https://minervadb.com/index.php/clickhouse-consulting-and-support-by-minervadb/)
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 62
|
||||
toc_title: "Descripci\xF3n general de la arquitectura ClickHouse"
|
||||
---
|
||||
|
||||
# Descripción General De La Arquitectura ClickHouse {#overview-of-clickhouse-architecture}
|
||||
# Descripción general de la arquitectura ClickHouse {#overview-of-clickhouse-architecture}
|
||||
|
||||
ClickHouse es un verdadero DBMS orientado a columnas. Los datos se almacenan por columnas y durante la ejecución de matrices (vectores o fragmentos de columnas). Siempre que sea posible, las operaciones se envían en matrices, en lugar de en valores individuales. Se llama “vectorized query execution,” y ayuda a reducir el costo del procesamiento de datos real.
|
||||
|
||||
@ -25,13 +25,13 @@ Sin embargo, también es posible trabajar con valores individuales. Para represe
|
||||
|
||||
`Field` no tiene suficiente información sobre un tipo de datos específico para una tabla. Por ejemplo, `UInt8`, `UInt16`, `UInt32`, y `UInt64` todos están representados como `UInt64` en una `Field`.
|
||||
|
||||
## Abstracciones Con Fugas {#leaky-abstractions}
|
||||
## Abstracciones con fugas {#leaky-abstractions}
|
||||
|
||||
`IColumn` tiene métodos para transformaciones relacionales comunes de datos, pero no satisfacen todas las necesidades. Por ejemplo, `ColumnUInt64` no tiene un método para calcular la suma de dos columnas, y `ColumnString` no tiene un método para ejecutar una búsqueda de subcadena. Estas innumerables rutinas se implementan fuera de `IColumn`.
|
||||
|
||||
Varias funciones en columnas se pueden implementar de una manera genérica, no eficiente utilizando `IColumn` para extraer `Field` valores, o de una manera especializada utilizando el conocimiento del diseño de la memoria interna de los datos en un `IColumn` aplicación. Se implementa mediante la conversión de funciones a un `IColumn` escriba y trate con la representación interna directamente. Por ejemplo, `ColumnUInt64` tiene el `getData` método que devuelve una referencia a una matriz interna, luego una rutina separada lee o llena esa matriz directamente. Tenemos “leaky abstractions” para permitir especializaciones eficientes de varias rutinas.
|
||||
|
||||
## Tipos De Datos {#data_types}
|
||||
## Tipos de datos {#data_types}
|
||||
|
||||
`IDataType` es responsable de la serialización y deserialización: para leer y escribir fragmentos de columnas o valores individuales en formato binario o de texto. `IDataType` corresponde directamente a los tipos de datos en las tablas. Por ejemplo, hay `DataTypeUInt32`, `DataTypeDateTime`, `DataTypeString` y así sucesivamente.
|
||||
|
||||
@ -49,7 +49,7 @@ Cuando calculamos alguna función sobre columnas en un bloque, agregamos otra co
|
||||
|
||||
Se crean bloques para cada fragmento de datos procesado. Tenga en cuenta que para el mismo tipo de cálculo, los nombres y tipos de columna siguen siendo los mismos para diferentes bloques y solo cambian los datos de columna. Es mejor dividir los datos del bloque desde el encabezado del bloque porque los tamaños de bloque pequeños tienen una gran sobrecarga de cadenas temporales para copiar shared\_ptrs y nombres de columna.
|
||||
|
||||
## Bloquear Flujos {#block-streams}
|
||||
## Bloquear flujos {#block-streams}
|
||||
|
||||
Los flujos de bloques son para procesar datos. Usamos flujos de bloques para leer datos de algún lugar, realizar transformaciones de datos o escribir datos en algún lugar. `IBlockInputStream` tiene el `read` método para buscar el siguiente bloque mientras esté disponible. `IBlockOutputStream` tiene el `write` método para empujar el bloque en alguna parte.
|
||||
|
||||
@ -120,7 +120,7 @@ Los intérpretes son responsables de crear la canalización de ejecución de con
|
||||
|
||||
Hay funciones ordinarias y funciones agregadas. Para las funciones agregadas, consulte la siguiente secció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`de datos para implementar la ejecución de consultas vectorizadas.
|
||||
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`de datos para implementar la ejecución de consultas vectorizadas.
|
||||
|
||||
Hay algunas funciones diversas, como [BlockSize](../sql-reference/functions/other-functions.md#function-blocksize), [rowNumberInBlock](../sql-reference/functions/other-functions.md#function-rownumberinblock), y [runningAccumulate](../sql-reference/functions/other-functions.md#function-runningaccumulate), que explotan el procesamiento de bloques y violan la independencia de las filas.
|
||||
|
||||
@ -132,7 +132,7 @@ Es un excelente lugar para implementar la generación de código en tiempo de ej
|
||||
|
||||
Debido a la ejecución de consultas vectorizadas, las funciones no se cortocircuitan. Por ejemplo, si escribe `WHERE f(x) AND g(y)`, ambos lados se calculan, incluso para las filas, cuando `f(x)` es cero (excepto cuando `f(x)` es una expresión constante cero). Pero si la selectividad del `f(x)` la condición es alta, y el cálculo de `f(x)` es mucho más barato que `g(y)`, es mejor implementar el cálculo de paso múltiple. Primero calcularía `f(x)`, a continuación, filtrar columnas por el resultado, y luego calcular `g(y)` solo para trozos de datos más pequeños y filtrados.
|
||||
|
||||
## Funciones Agregadas {#aggregate-functions}
|
||||
## Funciones agregadas {#aggregate-functions}
|
||||
|
||||
Las funciones agregadas son funciones con estado. Acumulan valores pasados en algún estado y le permiten obtener resultados de ese estado. Se gestionan con el `IAggregateFunction` interfaz. Los estados pueden ser bastante simples (el estado para `AggregateFunctionCount` es sólo una sola `UInt64` valor) o bastante complejo (el estado de `AggregateFunctionUniqCombined` es una combinación de una matriz lineal, una tabla hash, y un `HyperLogLog` estructura de datos probabilística).
|
||||
|
||||
@ -159,7 +159,7 @@ Mantenemos una compatibilidad total con versiones anteriores y posteriores para
|
||||
!!! note "Nota"
|
||||
Para la mayoría de las aplicaciones externas, recomendamos usar la interfaz HTTP porque es simple y fácil de usar. El protocolo TCP está más estrechamente vinculado a las estructuras de datos internas: utiliza un formato interno para pasar bloques de datos y utiliza marcos personalizados para datos comprimidos. No hemos lanzado una biblioteca C para ese protocolo porque requiere vincular la mayor parte de la base de código ClickHouse, lo cual no es práctico.
|
||||
|
||||
## Ejecución De Consultas Distribuidas {#distributed-query-execution}
|
||||
## Ejecución de consultas distribuidas {#distributed-query-execution}
|
||||
|
||||
Los servidores de una configuración de clúster son en su mayoría independientes. Puede crear un `Distributed` en uno o todos los servidores de un clúster. El `Distributed` table does not store data itself – it only provides a “view” a todas las tablas locales en varios nodos de un clúster. Cuando se SELECCIONA desde un `Distributed` tabla, reescribe esa consulta, elige nodos remotos de acuerdo con la configuración de equilibrio de carga y les envía la consulta. El `Distributed` table solicita a los servidores remotos que procesen una consulta hasta una etapa en la que se pueden fusionar resultados intermedios de diferentes servidores. Luego recibe los resultados intermedios y los fusiona. La tabla distribuida intenta distribuir tanto trabajo como sea posible a servidores remotos y no envía muchos datos intermedios a través de la red.
|
||||
|
||||
@ -167,7 +167,7 @@ Las cosas se vuelven más complicadas cuando tiene subconsultas en cláusulas IN
|
||||
|
||||
No existe un plan de consulta global para la ejecución de consultas distribuidas. Cada nodo tiene su plan de consulta local para su parte del trabajo. Solo tenemos una ejecución simple de consultas distribuidas de un solo paso: enviamos consultas para nodos remotos y luego fusionamos los resultados. Pero esto no es factible para consultas complicadas con alta cardinalidad GROUP BY o con una gran cantidad de datos temporales para JOIN. En tales casos, necesitamos “reshuffle” datos entre servidores, lo que requiere una coordinación adicional. ClickHouse no admite ese tipo de ejecución de consultas, y tenemos que trabajar en ello.
|
||||
|
||||
## Árbol De fusión {#merge-tree}
|
||||
## Árbol de fusión {#merge-tree}
|
||||
|
||||
`MergeTree` es una familia de motores de almacenamiento que admite la indexación por clave principal. La clave principal puede ser una tupla arbitraria de columnas o expresiones. Datos en un `MergeTree` se almacena en “parts”. Cada parte almacena los datos en el orden de la clave principal, por lo que la tupla de la clave principal ordena los datos lexicográficamente. Todas las columnas de la tabla se almacenan en `column.bin` archivos en estas partes. Los archivos consisten en bloques comprimidos. Cada bloque suele ser de 64 KB a 1 MB de datos sin comprimir, dependiendo del tamaño del valor promedio. Los bloques constan de valores de columna colocados contiguamente uno tras otro. Los valores de columna están en el mismo orden para cada columna (la clave principal define el orden), por lo que cuando itera por muchas columnas, obtiene valores para las filas correspondientes.
|
||||
|
||||
@ -177,7 +177,7 @@ Cuando vamos a leer algo de una parte en `MergeTree` miramos `primary.idx` datos
|
||||
|
||||
Cuando `INSERT` un montón de datos en `MergeTree`, ese grupo está ordenado por orden de clave primaria y forma una nueva parte. Hay subprocesos de fondo que seleccionan periódicamente algunas partes y las fusionan en una sola parte ordenada para mantener el número de partes relativamente bajo. Es por eso que se llama `MergeTree`. Por supuesto, la fusión conduce a “write amplification”. Todas las partes son inmutables: solo se crean y eliminan, pero no se modifican. Cuando se ejecuta SELECT, contiene una instantánea de la tabla (un conjunto de partes). Después de la fusión, también mantenemos las piezas viejas durante algún tiempo para facilitar la recuperación después de la falla, por lo que si vemos que alguna parte fusionada probablemente esté rota, podemos reemplazarla con sus partes de origen.
|
||||
|
||||
`MergeTree` no es un árbol de LSM porque no contiene “memtable” y “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` no es un árbol de LSM porque no contiene “memtable” y “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.
|
||||
|
||||
> Las tablas MergeTree solo pueden tener un índice (primario): no hay índices secundarios. Sería bueno permitir múltiples representaciones físicas bajo una tabla lógica, por ejemplo, para almacenar datos en más de un orden físico o incluso para permitir representaciones con datos preagregados junto con datos originales.
|
||||
|
||||
|
@ -1,13 +1,13 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 63
|
||||
toc_title: "Examinar el c\xF3digo fuente de ClickHouse"
|
||||
toc_title: "Buscar c\xF3digo fuente"
|
||||
---
|
||||
|
||||
# Examinar El código Fuente De ClickHouse {#browse-clickhouse-source-code}
|
||||
# Examinar el código fuente de ClickHouse {#browse-clickhouse-source-code}
|
||||
|
||||
Usted puede utilizar **Woboq** navegador de código en línea disponible [aqui](https://clickhouse.tech/codebrowser/html_report///ClickHouse/src/index.html). Proporciona navegación de código y resaltado semántico, búsqueda e indexación. La instantánea de código se actualiza diariamente.
|
||||
Usted puede utilizar **Woboq** navegador de código en línea disponible [aqui](https://clickhouse.tech/codebrowser/html_report/ClickHouse/src/index.html). Proporciona navegación de código y resaltado semántico, búsqueda e indexación. La instantánea de código se actualiza diariamente.
|
||||
|
||||
Además, puede navegar por las fuentes en [GitHub](https://github.com/ClickHouse/ClickHouse) como de costumbre.
|
||||
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 67
|
||||
toc_title: "C\xF3mo construir ClickHouse en Linux para AARCH64 (ARM64)"
|
||||
---
|
||||
|
||||
# Cómo Construir ClickHouse En Linux Para La Arquitectura AARCH64 (ARM64 {#how-to-build-clickhouse-on-linux-for-aarch64-arm64-architecture}
|
||||
# Cómo construir ClickHouse en Linux para la arquitectura AARCH64 (ARM64) {#how-to-build-clickhouse-on-linux-for-aarch64-arm64-architecture}
|
||||
|
||||
Esto es para el caso cuando tiene una máquina Linux y desea usarla para compilar `clickhouse` binario que se ejecutará en otra máquina Linux con arquitectura de CPU AARCH64. Esto está destinado a las comprobaciones de integración continua que se ejecutan en servidores Linux.
|
||||
|
||||
@ -22,7 +22,7 @@ sudo apt-get update
|
||||
sudo apt-get install clang-8
|
||||
```
|
||||
|
||||
# Instalar Conjunto De Herramientas De compilación Cruzada {#install-cross-compilation-toolset}
|
||||
# Instalar conjunto de herramientas de compilación cruzada {#install-cross-compilation-toolset}
|
||||
|
||||
``` bash
|
||||
cd ClickHouse
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 66
|
||||
toc_title: "C\xF3mo construir ClickHouse en Linux para Mac OS X"
|
||||
---
|
||||
|
||||
# Cómo Construir ClickHouse En Linux Para Mac OS X {#how-to-build-clickhouse-on-linux-for-mac-os-x}
|
||||
# Cómo construir ClickHouse en Linux para Mac OS X {#how-to-build-clickhouse-on-linux-for-mac-os-x}
|
||||
|
||||
Esto es para el caso cuando tiene una máquina Linux y desea usarla para compilar `clickhouse` Esto está destinado a las comprobaciones de integración continuas que se ejecutan en servidores Linux. Si desea crear ClickHouse directamente en Mac OS X, continúe con [otra instrucción](build-osx.md).
|
||||
|
||||
@ -21,7 +21,7 @@ sudo echo "deb [trusted=yes] http://apt.llvm.org/bionic/ llvm-toolchain-bionic-8
|
||||
sudo apt-get install clang-8
|
||||
```
|
||||
|
||||
# Instalar Conjunto De Herramientas De compilación Cruzada {#install-cross-compilation-toolset}
|
||||
# Instalar conjunto de herramientas de compilación cruzada {#install-cross-compilation-toolset}
|
||||
|
||||
Recordemos la ruta donde instalamos `cctools` como ${CCTOOLS}
|
||||
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 65
|
||||
toc_title: "C\xF3mo crear ClickHouse en Mac OS X"
|
||||
---
|
||||
|
||||
# Cómo Crear ClickHouse En Mac OS X {#how-to-build-clickhouse-on-mac-os-x}
|
||||
# Cómo crear ClickHouse en Mac OS X {#how-to-build-clickhouse-on-mac-os-x}
|
||||
|
||||
Build debería funcionar en Mac OS X 10.15 (Catalina)
|
||||
|
||||
@ -15,13 +15,13 @@ Build debería funcionar en Mac OS X 10.15 (Catalina)
|
||||
$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
|
||||
```
|
||||
|
||||
## Instalar Compiladores, Herramientas y Bibliotecas Necesarios {#install-required-compilers-tools-and-libraries}
|
||||
## Instalar compiladores, herramientas y bibliotecas necesarios {#install-required-compilers-tools-and-libraries}
|
||||
|
||||
``` bash
|
||||
$ brew install cmake ninja libtool gettext
|
||||
```
|
||||
|
||||
## Fuentes De ClickHouse De Pago {#checkout-clickhouse-sources}
|
||||
## Fuentes de ClickHouse de pago {#checkout-clickhouse-sources}
|
||||
|
||||
``` bash
|
||||
$ git clone --recursive git@github.com:ClickHouse/ClickHouse.git
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 64
|
||||
toc_title: "C\xF3mo crear ClickHouse en Linux"
|
||||
---
|
||||
|
||||
# Cómo Construir ClickHouse Para El Desarrollo {#how-to-build-clickhouse-for-development}
|
||||
# Cómo construir ClickHouse para el desarrollo {#how-to-build-clickhouse-for-development}
|
||||
|
||||
El siguiente tutorial se basa en el sistema Ubuntu Linux.
|
||||
Con los cambios apropiados, también debería funcionar en cualquier otra distribución de Linux.
|
||||
@ -23,7 +23,7 @@ O cmake3 en lugar de cmake en sistemas más antiguos.
|
||||
|
||||
Hay varias formas de hacer esto.
|
||||
|
||||
### Instalar Desde Un Paquete PPA {#install-from-a-ppa-package}
|
||||
### Instalar desde un paquete PPA {#install-from-a-ppa-package}
|
||||
|
||||
``` bash
|
||||
$ sudo apt-get install software-properties-common
|
||||
@ -32,18 +32,18 @@ $ sudo apt-get update
|
||||
$ sudo apt-get install gcc-9 g++-9
|
||||
```
|
||||
|
||||
### Instalar Desde Fuentes {#install-from-sources}
|
||||
### Instalar desde fuentes {#install-from-sources}
|
||||
|
||||
Mira [Sistema abierto.](https://github.com/ClickHouse/ClickHouse/blob/master/utils/ci/build-gcc-from-sources.sh)
|
||||
|
||||
## Usar GCC 9 Para Compilaciones {#use-gcc-9-for-builds}
|
||||
## Usar GCC 9 para compilaciones {#use-gcc-9-for-builds}
|
||||
|
||||
``` bash
|
||||
$ export CC=gcc-9
|
||||
$ export CXX=g++-9
|
||||
```
|
||||
|
||||
## Fuentes De ClickHouse De Pago {#checkout-clickhouse-sources}
|
||||
## Fuentes de ClickHouse de pago {#checkout-clickhouse-sources}
|
||||
|
||||
``` bash
|
||||
$ git clone --recursive git@github.com:ClickHouse/ClickHouse.git
|
||||
@ -69,7 +69,7 @@ $ cd ..
|
||||
Para crear un ejecutable, ejecute `ninja clickhouse`.
|
||||
Esto creará el `programs/clickhouse` ejecutable, que se puede usar con `client` o `server` argumento.
|
||||
|
||||
# Cómo Construir ClickHouse En Cualquier Linux {#how-to-build-clickhouse-on-any-linux}
|
||||
# Cómo construir ClickHouse en cualquier Linux {#how-to-build-clickhouse-on-any-linux}
|
||||
|
||||
La compilación requiere los siguientes componentes:
|
||||
|
||||
@ -108,7 +108,7 @@ Ejemplo de Fedora Rawhide:
|
||||
cmake ../ClickHouse
|
||||
make -j $(nproc)
|
||||
|
||||
# No Tienes Que Construir ClickHouse {#you-dont-have-to-build-clickhouse}
|
||||
# No tienes que construir ClickHouse {#you-dont-have-to-build-clickhouse}
|
||||
|
||||
ClickHouse está disponible en binarios y paquetes preconstruidos. Los binarios son portátiles y se pueden ejecutar en cualquier tipo de Linux.
|
||||
|
||||
@ -116,7 +116,7 @@ Están diseñados para lanzamientos estables, preestablecidos y de prueba, siemp
|
||||
|
||||
Para encontrar la construcción más fresca de `master`, ir a [se compromete página](https://github.com/ClickHouse/ClickHouse/commits/master), haga clic en la primera marca de verificación verde o cruz roja cerca de confirmar, y haga clic en “Details” enlace justo después “ClickHouse Build Check”.
|
||||
|
||||
# Cómo Construir El Paquete Debian ClickHouse {#how-to-build-clickhouse-debian-package}
|
||||
# Cómo construir el paquete Debian ClickHouse {#how-to-build-clickhouse-debian-package}
|
||||
|
||||
## Instalar Git y Pbuilder {#install-git-and-pbuilder}
|
||||
|
||||
@ -125,14 +125,14 @@ $ sudo apt-get update
|
||||
$ sudo apt-get install git python pbuilder debhelper lsb-release fakeroot sudo debian-archive-keyring debian-keyring
|
||||
```
|
||||
|
||||
## Fuentes De ClickHouse De Pago {#checkout-clickhouse-sources-1}
|
||||
## Fuentes de ClickHouse de pago {#checkout-clickhouse-sources-1}
|
||||
|
||||
``` bash
|
||||
$ git clone --recursive --branch master https://github.com/ClickHouse/ClickHouse.git
|
||||
$ cd ClickHouse
|
||||
```
|
||||
|
||||
## Ejecutar Secuencia De Comandos De Lanzamiento {#run-release-script}
|
||||
## Ejecutar secuencia de comandos de lanzamiento {#run-release-script}
|
||||
|
||||
``` bash
|
||||
$ ./release
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 70
|
||||
toc_title: Bibliotecas de terceros utilizadas
|
||||
---
|
||||
|
||||
# Bibliotecas De Terceros Utilizadas {#third-party-libraries-used}
|
||||
# Bibliotecas de terceros utilizadas {#third-party-libraries-used}
|
||||
|
||||
| Biblioteca | Licencia |
|
||||
|--------------------|--------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
|
@ -1,21 +1,21 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 61
|
||||
toc_title: "La instrucci\xF3n para desarrolladores de ClickHouse para principiantes"
|
||||
---
|
||||
|
||||
La construcción de ClickHouse es compatible con Linux, FreeBSD y Mac OS X.
|
||||
|
||||
# Si Utiliza Windows {#if-you-use-windows}
|
||||
# Si utiliza Windows {#if-you-use-windows}
|
||||
|
||||
Si usa Windows, necesita crear una máquina virtual con Ubuntu. Para comenzar a trabajar con una máquina virtual, instale VirtualBox. Puede descargar Ubuntu desde el sitio web: https://www.ubuntu.com/\#download. Por favor, cree una máquina virtual a partir de la imagen descargada (debe reservar al menos 4 GB de RAM para ello). Para ejecutar un terminal de línea de comandos en Ubuntu, busque un programa que contenga la palabra “terminal” en su nombre (gnome-terminal, konsole etc.) o simplemente presione Ctrl + Alt + T.
|
||||
|
||||
# Si Utiliza Un Sistema De 32 Bits {#if-you-use-a-32-bit-system}
|
||||
# Si utiliza un sistema de 32 bits {#if-you-use-a-32-bit-system}
|
||||
|
||||
ClickHouse no puede funcionar ni construir en un sistema de 32 bits. Debe adquirir acceso a un sistema de 64 bits y puede continuar leyendo.
|
||||
|
||||
# Crear Un Repositorio En GitHub {#creating-a-repository-on-github}
|
||||
# Creación de un repositorio en GitHub {#creating-a-repository-on-github}
|
||||
|
||||
Para comenzar a trabajar con el repositorio de ClickHouse, necesitará una cuenta de GitHub.
|
||||
|
||||
@ -35,13 +35,13 @@ Para hacer eso en Ubuntu, ejecutaría en la terminal de línea de comandos:
|
||||
Puede encontrar un breve manual sobre el uso de Git aquí: https://services.github.com/on-demand/downloads/github-git-cheat-sheet.pdf .
|
||||
Para obtener un manual detallado sobre Git, consulte https://git-scm.com/book/en/v2 .
|
||||
|
||||
# Clonación De Un Repositorio En Su máquina De Desarrollo {#cloning-a-repository-to-your-development-machine}
|
||||
# Clonación de un repositorio en su máquina de desarrollo {#cloning-a-repository-to-your-development-machine}
|
||||
|
||||
A continuación, debe descargar los archivos fuente en su máquina de trabajo. Esto se llama “to clone a repository” porque crea una copia local del repositorio en su máquina de trabajo.
|
||||
|
||||
En el terminal de línea de comandos, ejecute:
|
||||
|
||||
git clone --recursive git@guthub.com:your_github_username/ClickHouse.git
|
||||
git clone --recursive git@github.com:your_github_username/ClickHouse.git
|
||||
cd ClickHouse
|
||||
|
||||
Nota: por favor, sustituye *your\_github\_username* con lo que es apropiado!
|
||||
@ -79,7 +79,7 @@ También puede agregar la dirección original del repositorio de ClickHouse a su
|
||||
|
||||
Después de ejecutar con éxito este comando, podrá extraer actualizaciones del repositorio principal de ClickHouse ejecutando `git pull upstream master`.
|
||||
|
||||
## Trabajar Con submódulos {#working-with-submodules}
|
||||
## Trabajar con submódulos {#working-with-submodules}
|
||||
|
||||
Trabajar con submódulos en git podría ser doloroso. Los siguientes comandos ayudarán a administrarlo:
|
||||
|
||||
@ -109,7 +109,7 @@ Los siguientes comandos le ayudarían a restablecer todos los submódulos al est
|
||||
git submodule foreach git submodule foreach git reset --hard
|
||||
git submodule foreach git submodule foreach git clean -xfd
|
||||
|
||||
# Sistema De construcción {#build-system}
|
||||
# Sistema de construcción {#build-system}
|
||||
|
||||
ClickHouse utiliza CMake y Ninja para la construcción.
|
||||
|
||||
@ -129,11 +129,11 @@ Para instalar CMake y Ninja en Mac OS X, primero instale Homebrew y luego instal
|
||||
|
||||
A continuación, verifique la versión de CMake: `cmake --version`. Si está por debajo de 3.3, debe instalar una versión más reciente desde el sitio web: https://cmake.org/download/.
|
||||
|
||||
# Bibliotecas Externas Opcionales {#optional-external-libraries}
|
||||
# Bibliotecas externas opcionales {#optional-external-libraries}
|
||||
|
||||
ClickHouse utiliza varias bibliotecas externas para la construcción. Todos ellos no necesitan ser instalados por separado, ya que se construyen junto con ClickHouse a partir de las fuentes ubicadas en los submódulos. Puede consultar la lista en `contrib`.
|
||||
|
||||
# Compilador De C ++ {#c-compiler}
|
||||
# Compilador de C ++ {#c-compiler}
|
||||
|
||||
Los compiladores GCC a partir de la versión 9 y Clang versión 8 o superior son compatibles para construir ClickHouse.
|
||||
|
||||
@ -147,7 +147,7 @@ La compilación de Mac OS X solo es compatible con Clang. Sólo tiene que ejecut
|
||||
|
||||
Si decide utilizar Clang, también puede instalar `libc++` y `lld` si usted sabe lo que es. Utilizar `ccache` también se recomienda.
|
||||
|
||||
# El Proceso De construcción {#the-building-process}
|
||||
# El proceso de construcción {#the-building-process}
|
||||
|
||||
Ahora que está listo para construir ClickHouse, le recomendamos que cree un directorio separado `build` dentro `ClickHouse` que contendrá todos los de la generación de artefactos:
|
||||
|
||||
@ -204,11 +204,11 @@ Tras la compilación exitosa, obtienes un archivo ejecutable `ClickHouse/<build_
|
||||
|
||||
ls -l programs/clickhouse
|
||||
|
||||
# Ejecutando El Ejecutable Construido De ClickHouse {#running-the-built-executable-of-clickhouse}
|
||||
# Ejecución del ejecutable construido de ClickHouse {#running-the-built-executable-of-clickhouse}
|
||||
|
||||
Para ejecutar el servidor bajo el usuario actual, debe navegar hasta `ClickHouse/programs/server/` (situado fuera de `build`) y ejecutar:
|
||||
|
||||
../../../build/programs/clickhouse server
|
||||
../../build/programs/clickhouse server
|
||||
|
||||
En este caso, ClickHouse usará archivos de configuración ubicados en el directorio actual. Puede ejecutar `clickhouse server` desde cualquier directorio que especifique la ruta a un archivo de configuración como un parámetro de línea de comandos `--config-file`.
|
||||
|
||||
@ -231,7 +231,7 @@ También puede ejecutar su binario ClickHouse personalizado con el archivo de co
|
||||
sudo service clickhouse-server stop
|
||||
sudo -u clickhouse ClickHouse/build/programs/clickhouse server --config-file /etc/clickhouse-server/config.xml
|
||||
|
||||
# IDE (entorno De Desarrollo Integrado) {#ide-integrated-development-environment}
|
||||
# IDE (entorno de desarrollo integrado) {#ide-integrated-development-environment}
|
||||
|
||||
Si no sabe qué IDE usar, le recomendamos que use CLion. CLion es un software comercial, pero ofrece un período de prueba gratuito de 30 días. También es gratuito para los estudiantes. CLion se puede usar tanto en Linux como en Mac OS X.
|
||||
|
||||
@ -241,7 +241,7 @@ Como editores de código simples, puede usar Sublime Text o Visual Studio Code,
|
||||
|
||||
Por si acaso, vale la pena mencionar que CLion crea `build` por sí mismo, también por sí mismo selecciona `debug` para el tipo de compilación, para la configuración usa una versión de CMake que está definida en CLion y no la instalada por usted, y finalmente, CLion usará `make` para ejecutar tareas de compilación en lugar de `ninja`. Este es un comportamiento normal, solo tenlo en cuenta para evitar confusiones.
|
||||
|
||||
# Código De Escritura {#writing-code}
|
||||
# Código de escritura {#writing-code}
|
||||
|
||||
La descripción de la arquitectura ClickHouse se puede encontrar aquí: https://clickhouse.tech/docs/es/desarrollo/arquitectura/
|
||||
|
||||
@ -251,7 +251,7 @@ Pruebas de escritura: https://clickhouse.tech/docs/en/development/tests/
|
||||
|
||||
Lista de tareas: https://github.com/ClickHouse/ClickHouse/blob/master/testsructions/easy\_tasks\_sorted\_en.md
|
||||
|
||||
# Datos De Prueba {#test-data}
|
||||
# Datos de prueba {#test-data}
|
||||
|
||||
El desarrollo de ClickHouse a menudo requiere cargar conjuntos de datos realistas. Es particularmente importante para las pruebas de rendimiento. Tenemos un conjunto especialmente preparado de datos anónimos de Yandex.Métrica. Se requiere, además, unos 3 GB de espacio libre en disco. Tenga en cuenta que estos datos no son necesarios para realizar la mayoría de las tareas de desarrollo.
|
||||
|
||||
@ -265,6 +265,8 @@ El desarrollo de ClickHouse a menudo requiere cargar conjuntos de datos realista
|
||||
|
||||
clickhouse-client
|
||||
|
||||
CREATE DATABASE IF NOT EXISTS test
|
||||
|
||||
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);
|
||||
@ -272,7 +274,7 @@ El desarrollo de ClickHouse a menudo requiere cargar conjuntos de datos realista
|
||||
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
|
||||
|
||||
# Creación De Solicitud De extracción {#creating-pull-request}
|
||||
# Creación de solicitud de extracción {#creating-pull-request}
|
||||
|
||||
Navega a tu repositorio de fork en la interfaz de usuario de GitHub. Si ha estado desarrollando en una sucursal, debe seleccionar esa sucursal. Habrá un “Pull request” botón situado en la pantalla. En esencia, esto significa “create a request for accepting my changes into the main repository”.
|
||||
|
||||
|
@ -1,12 +1,12 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
toc_folder_title: Development
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_folder_title: Desarrollo
|
||||
toc_hidden: true
|
||||
toc_priority: 58
|
||||
toc_title: oculto
|
||||
---
|
||||
|
||||
# Desarrollo De ClickHouse {#clickhouse-development}
|
||||
# Desarrollo de ClickHouse {#clickhouse-development}
|
||||
|
||||
[Artículo Original](https://clickhouse.tech/docs/en/development/) <!--hide-->
|
||||
|
@ -1,13 +1,13 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 68
|
||||
toc_title: "C\xF3mo escribir c\xF3digo C ++"
|
||||
---
|
||||
|
||||
# Cómo Escribir código C ++ {#how-to-write-c-code}
|
||||
# Cómo escribir código C ++ {#how-to-write-c-code}
|
||||
|
||||
## Recomendaciones Generales {#general-recommendations}
|
||||
## Recomendaciones generales {#general-recommendations}
|
||||
|
||||
**1.** Las siguientes son recomendaciones, no requisitos.
|
||||
|
||||
@ -422,7 +422,7 @@ También puede usar una abreviatura si el nombre completo se incluye junto a él
|
||||
|
||||
**17.** Los nombres de archivo con código fuente de C++ deben tener `.cpp` ampliación. Los archivos de encabezado deben tener `.h` ampliación.
|
||||
|
||||
## Cómo Escribir código {#how-to-write-code}
|
||||
## Cómo escribir código {#how-to-write-code}
|
||||
|
||||
**1.** Gestión de la memoria.
|
||||
|
||||
@ -689,7 +689,7 @@ auto s = std::string{"Hello"};
|
||||
|
||||
**26.** Para funciones virtuales, escriba `virtual` en la clase base, pero escribe `override` en lugar de `virtual` en las clases descendientes.
|
||||
|
||||
## Características No Utilizadas De C ++ {#unused-features-of-c}
|
||||
## Características no utilizadas de C ++ {#unused-features-of-c}
|
||||
|
||||
**1.** La herencia virtual no se utiliza.
|
||||
|
||||
@ -763,7 +763,7 @@ Si ya hay una buena solución disponible, úsela, incluso si eso significa que d
|
||||
|
||||
**5.** Siempre se da preferencia a las bibliotecas que ya están en uso.
|
||||
|
||||
## Recomendaciones Generales {#general-recommendations-1}
|
||||
## Recomendaciones generales {#general-recommendations-1}
|
||||
|
||||
**1.** Escribe el menor código posible.
|
||||
|
||||
@ -777,7 +777,7 @@ Si ya hay una buena solución disponible, úsela, incluso si eso significa que d
|
||||
|
||||
**6.** Se fomenta la simplificación del código. Reduzca el tamaño de su código siempre que sea posible.
|
||||
|
||||
## Recomendaciones Adicionales {#additional-recommendations}
|
||||
## Recomendaciones adicionales {#additional-recommendations}
|
||||
|
||||
**1.** Especificar explícitamente `std::` para tipos de `stddef.h`
|
||||
|
||||
|
@ -1,13 +1,13 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 69
|
||||
toc_title: "C\xF3mo ejecutar pruebas de ClickHouse"
|
||||
---
|
||||
|
||||
# Pruebas De ClickHouse {#clickhouse-testing}
|
||||
# Pruebas de ClickHouse {#clickhouse-testing}
|
||||
|
||||
## Pruebas Funcionales {#functional-tests}
|
||||
## Pruebas funcionales {#functional-tests}
|
||||
|
||||
Las pruebas funcionales son las más simples y cómodas de usar. La mayoría de las características de ClickHouse se pueden probar con pruebas funcionales y son obligatorias para cada cambio en el código de ClickHouse que se puede probar de esa manera.
|
||||
|
||||
@ -38,7 +38,7 @@ deshabilitar estos grupos de pruebas utilizando `--no-zookeeper`, `--no-shard` y
|
||||
|
||||
Si conocemos algunos errores que se pueden reproducir fácilmente mediante pruebas funcionales, colocamos pruebas funcionales preparadas en `tests/queries/bugs` directorio. Estas pruebas se moverán a `tests/queries/0_stateless` cuando se corrigen errores.
|
||||
|
||||
## Pruebas De integración {#integration-tests}
|
||||
## Pruebas de integración {#integration-tests}
|
||||
|
||||
Las pruebas de integración permiten probar ClickHouse en la configuración agrupada y la interacción de ClickHouse con otros servidores como MySQL, Postgres, MongoDB. Son útiles para emular divisiones de red, caídas de paquetes, etc. Estas pruebas se ejecutan bajo Docker y crean múltiples contenedores con varios software.
|
||||
|
||||
@ -46,27 +46,27 @@ Ver `tests/integration/README.md` sobre cómo ejecutar estas pruebas.
|
||||
|
||||
Tenga en cuenta que la integración de ClickHouse con controladores de terceros no se ha probado. Además, actualmente no tenemos pruebas de integración con nuestros controladores JDBC y ODBC.
|
||||
|
||||
## Pruebas Unitarias {#unit-tests}
|
||||
## Pruebas unitarias {#unit-tests}
|
||||
|
||||
Las pruebas unitarias son útiles cuando desea probar no ClickHouse como un todo, sino una sola biblioteca o clase aislada. Puede habilitar o deshabilitar la compilación de pruebas con `ENABLE_TESTS` Opción CMake. Las pruebas unitarias (y otros programas de prueba) se encuentran en `tests` subdirectorios en todo el código. Para ejecutar pruebas unitarias, escriba `ninja test`. Algunas pruebas usan `gtest`, pero algunos son solo programas que devuelven un código de salida distinto de cero en caso de fallo de prueba.
|
||||
|
||||
No es necesariamente tener pruebas unitarias si el código ya está cubierto por pruebas funcionales (y las pruebas funcionales suelen ser mucho más simples de usar).
|
||||
|
||||
## Pruebas De Rendimiento {#performance-tests}
|
||||
## Pruebas de rendimiento {#performance-tests}
|
||||
|
||||
Las pruebas de rendimiento permiten medir y comparar el rendimiento de alguna parte aislada de ClickHouse en consultas sintéticas. Las pruebas se encuentran en `tests/performance`. Cada prueba está representada por `.xml` archivo con la descripción del caso de prueba. Las pruebas se ejecutan con `clickhouse performance-test` herramienta (que está incrustada en `clickhouse` binario). Ver `--help` para la invocación.
|
||||
|
||||
Cada prueba ejecuta una o múltiples consultas (posiblemente con combinaciones de parámetros) en un bucle con algunas condiciones para stop (como “maximum execution speed is not changing in three seconds”) y medir algunas métricas sobre el rendimiento de las consultas (como “maximum execution speed”). Algunas pruebas pueden contener condiciones previas en el conjunto de datos de pruebas precargado.
|
||||
Cada prueba ejecuta una o varias consultas (posiblemente con combinaciones de parámetros) en un bucle con algunas condiciones para detener (como “maximum execution speed is not changing in three seconds”) y medir algunas métricas sobre el rendimiento de las consultas (como “maximum execution speed”). Algunas pruebas pueden contener condiciones previas en el conjunto de datos de pruebas precargado.
|
||||
|
||||
Si desea mejorar el rendimiento de ClickHouse en algún escenario, y si se pueden observar mejoras en consultas simples, se recomienda encarecidamente escribir una prueba de rendimiento. Siempre tiene sentido usar `perf top` u otras herramientas de perf durante sus pruebas.
|
||||
|
||||
## Herramientas De Prueba y Secuencias De Comandos {#test-tools-and-scripts}
|
||||
## Herramientas de prueba y secuencias de comandos {#test-tools-and-scripts}
|
||||
|
||||
Algunos programas en `tests` directorio no son pruebas preparadas, pero son herramientas de prueba. Por ejemplo, para `Lexer` hay una herramienta `dbms/Parsers/tests/lexer` que solo hacen la tokenización de stdin y escriben el resultado coloreado en stdout. Puede usar este tipo de herramientas como ejemplos de código y para exploración y pruebas manuales.
|
||||
Algunos programas en `tests` directorio no son pruebas preparadas, pero son herramientas de prueba. Por ejemplo, para `Lexer` hay una herramienta `src/Parsers/tests/lexer` que solo hacen la tokenización de stdin y escriben el resultado coloreado en stdout. Puede usar este tipo de herramientas como ejemplos de código y para exploración y pruebas manuales.
|
||||
|
||||
También puede colocar un par de archivos `.sh` y `.reference` junto con la herramienta para ejecutarlo en alguna entrada predefinida, entonces el resultado del script se puede comparar con `.reference` file. Este tipo de pruebas no están automatizadas.
|
||||
|
||||
## Miscellanous Pruebas {#miscellanous-tests}
|
||||
## Pruebas diversas {#miscellaneous-tests}
|
||||
|
||||
Hay pruebas para diccionarios externos ubicados en `tests/external_dictionaries` y para modelos aprendidos a máquina en `tests/external_models`. Estas pruebas no se actualizan y deben transferirse a pruebas de integración.
|
||||
|
||||
@ -74,7 +74,7 @@ Hay una prueba separada para inserciones de quórum. Esta prueba ejecuta el clú
|
||||
|
||||
La prueba de quórum fue escrita por un equipo separado antes de que ClickHouse fuera de código abierto. Este equipo ya no trabaja con ClickHouse. La prueba fue escrita accidentalmente en Java. Por estas razones, la prueba de quórum debe reescribirse y trasladarse a pruebas de integración.
|
||||
|
||||
## Pruebas Manuales {#manual-testing}
|
||||
## Pruebas manuales {#manual-testing}
|
||||
|
||||
Cuando desarrolla una nueva característica, es razonable probarla también manualmente. Puede hacerlo con los siguientes pasos:
|
||||
|
||||
@ -109,7 +109,7 @@ Si el servidor de clickhouse del sistema ya se está ejecutando y no desea deten
|
||||
|
||||
`clickhouse` binary casi no tiene dependencias y funciona en una amplia gama de distribuciones de Linux. Para probar rápidamente y sucio sus cambios en un servidor, simplemente puede `scp` su fresco construido `clickhouse` binario a su servidor y luego ejecútelo como en los ejemplos anteriores.
|
||||
|
||||
## Entorno De Prueba {#testing-environment}
|
||||
## Entorno de prueba {#testing-environment}
|
||||
|
||||
Antes de publicar la versión como estable, la implementamos en el entorno de prueba. El entorno de prueba es un clúster que procesa 1/39 parte de [El Yandex.Métrica](https://metrica.yandex.com/) datos. Compartimos nuestro entorno de pruebas con Yandex.Equipo de Metrica. ClickHouse se actualiza sin tiempo de inactividad sobre los datos existentes. Nos fijamos en un primer momento que los datos se procesan con éxito sin retraso de tiempo real, la replicación continúan trabajando y no hay problemas visibles para Yandex.Equipo de Metrica. La primera comprobación se puede hacer de la siguiente manera:
|
||||
|
||||
@ -119,7 +119,7 @@ SELECT hostName() AS h, any(version()), any(uptime()), max(UTCEventTime), count(
|
||||
|
||||
En algunos casos también implementamos en el entorno de prueba de nuestros equipos de amigos en Yandex: Market, Cloud, etc. También tenemos algunos servidores de hardware que se utilizan con fines de desarrollo.
|
||||
|
||||
## Pruebas De Carga {#load-testing}
|
||||
## Pruebas de carga {#load-testing}
|
||||
|
||||
Después de implementar en el entorno de prueba, ejecutamos pruebas de carga con consultas del clúster de producción. Esto se hace manualmente.
|
||||
|
||||
@ -147,7 +147,7 @@ Usted debe comprobar que `clickhouse-server` no se bloquea, la huella de memoria
|
||||
|
||||
Los tiempos de ejecución de consultas precisos no se registran y no se comparan debido a la alta variabilidad de las consultas y el entorno.
|
||||
|
||||
## Pruebas De construcción {#build-tests}
|
||||
## Pruebas de construcción {#build-tests}
|
||||
|
||||
Las pruebas de compilación permiten verificar que la compilación no esté rota en varias configuraciones alternativas y en algunos sistemas extranjeros. Las pruebas se encuentran en `ci` directorio. Ejecutan compilación desde la fuente dentro de Docker, Vagrant y, a veces, con `qemu-user-static` dentro de Docker. Estas pruebas están en desarrollo y las ejecuciones de pruebas no están automatizadas.
|
||||
|
||||
@ -165,11 +165,11 @@ Por ejemplo, construir con paquetes del sistema es una mala práctica, porque no
|
||||
|
||||
Aunque no podemos ejecutar todas las pruebas en todas las variantes de compilaciones, queremos verificar al menos que varias variantes de compilación no estén rotas. Para este propósito utilizamos pruebas de construcción.
|
||||
|
||||
## Pruebas De Compatibilidad De Protocolos {#testing-for-protocol-compatibility}
|
||||
## Pruebas de Compatibilidad de protocolos {#testing-for-protocol-compatibility}
|
||||
|
||||
Cuando ampliamos el protocolo de red ClickHouse, probamos manualmente que el antiguo clickhouse-client funciona con el nuevo clickhouse-server y el nuevo clickhouse-client funciona con el antiguo clickhouse-server (simplemente ejecutando binarios de los paquetes correspondientes).
|
||||
|
||||
## Ayuda Del Compilador {#help-from-the-compiler}
|
||||
## Ayuda del compilador {#help-from-the-compiler}
|
||||
|
||||
Código principal de ClickHouse (que se encuentra en `dbms` directorio) se construye con `-Wall -Wextra -Werror` y con algunas advertencias habilitadas adicionales. Aunque estas opciones no están habilitadas para bibliotecas de terceros.
|
||||
|
||||
@ -199,13 +199,23 @@ Versión de depuración de `jemalloc` se utiliza para la compilación de depurac
|
||||
|
||||
## Fuzzing {#fuzzing}
|
||||
|
||||
Usamos una prueba de fuzz simple para generar consultas SQL aleatorias y verificar que el servidor no muera. Las pruebas de pelusa se realizan con el desinfectante Address. Lo puedes encontrar en `00746_sql_fuzzy.pl`. Esta prueba debe ejecutarse de forma continua (de la noche a la mañana y más).
|
||||
ClickHouse fuzzing se implementa tanto usando [LibFuzzer](https://llvm.org/docs/LibFuzzer.html) y consultas SQL aleatorias.
|
||||
Todas las pruebas de fuzz deben realizarse con desinfectantes (Dirección y Undefined).
|
||||
|
||||
A partir de diciembre de 2018, todavía no usamos pruebas de fuzz aisladas del código de la biblioteca.
|
||||
LibFuzzer se usa para pruebas de fuzz aisladas del código de la biblioteca. Fuzzers se implementan como parte del código de prueba y tienen “\_fuzzer” nombre postfixes.
|
||||
El ejemplo de Fuzzer se puede encontrar en `src/Parsers/tests/lexer_fuzzer.cpp`. Las configuraciones, diccionarios y corpus específicos de LibFuzzer se almacenan en `tests/fuzz`.
|
||||
Le recomendamos que escriba pruebas fuzz para cada funcionalidad que maneje la entrada del usuario.
|
||||
|
||||
## Auditoría De Seguridad {#security-audit}
|
||||
Fuzzers no se construyen de forma predeterminada. Para construir fuzzers ambos `-DENABLE_FUZZING=1` y `-DENABLE_TESTS=1` se deben establecer opciones.
|
||||
Recomendamos deshabilitar Jemalloc mientras se construyen fuzzers. Configuración utilizada para integrar
|
||||
Google OSS-Fuzz se puede encontrar en `docker/fuzz`.
|
||||
|
||||
La gente del departamento de Yandex Cloud hace una visión general básica de las capacidades de ClickHouse desde el punto de vista de la seguridad.
|
||||
También usamos una prueba de fuzz simple para generar consultas SQL aleatorias y verificar que el servidor no muera al ejecutarlas.
|
||||
Lo puedes encontrar en `00746_sql_fuzzy.pl`. Esta prueba debe ejecutarse de forma continua (de la noche a la mañana y más).
|
||||
|
||||
## Auditoría de seguridad {#security-audit}
|
||||
|
||||
La gente de Yandex Security Team hace una visión general básica de las capacidades de ClickHouse desde el punto de vista de la seguridad.
|
||||
|
||||
## Analizadores estáticos {#static-analyzers}
|
||||
|
||||
@ -217,7 +227,7 @@ Si usted usa `CLion` como IDE, puede aprovechar algunos `clang-tidy` comprueba f
|
||||
|
||||
`FORTIFY_SOURCE` se utiliza de forma predeterminada. Es casi inútil, pero todavía tiene sentido en casos raros y no lo desactivamos.
|
||||
|
||||
## Estilo De código {#code-style}
|
||||
## Estilo de código {#code-style}
|
||||
|
||||
Se describen las reglas de estilo de código [aqui](https://clickhouse.tech/docs/en/development/style/).
|
||||
|
||||
@ -235,11 +245,11 @@ Cada lanzamiento de ClickHouse se prueba con los motores Yandex Metrica y AppMet
|
||||
|
||||
Estas pruebas son automatizadas por un equipo separado. Debido a la gran cantidad de piezas móviles, las pruebas fallan la mayor parte del tiempo por razones completamente no relacionadas, que son muy difíciles de descubrir. Lo más probable es que estas pruebas tengan un valor negativo para nosotros. Sin embargo, se demostró que estas pruebas son útiles en aproximadamente una o dos veces de cada cientos.
|
||||
|
||||
## Cobertura De Prueba {#test-coverage}
|
||||
## Cobertura de prueba {#test-coverage}
|
||||
|
||||
A partir de julio de 2018, no realizamos un seguimiento de la cobertura de las pruebas.
|
||||
|
||||
## Automatización De Pruebas {#test-automation}
|
||||
## Automatización de pruebas {#test-automation}
|
||||
|
||||
Realizamos pruebas con el CI interno de Yandex y el sistema de automatización de trabajos llamado “Sandbox”.
|
||||
|
||||
@ -249,4 +259,3 @@ No usamos Travis CI debido al límite de tiempo y potencia computacional.
|
||||
No usamos Jenkins. Se usó antes y ahora estamos felices de no estar usando Jenkins.
|
||||
|
||||
[Artículo Original](https://clickhouse.tech/docs/en/development/tests/) <!--hide-->
|
||||
pruebas/) <!--hide-->
|
||||
|
@ -1,12 +1,12 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
toc_folder_title: Database Engines
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_folder_title: Motores de base de datos
|
||||
toc_priority: 27
|
||||
toc_title: "Implantaci\xF3n"
|
||||
---
|
||||
|
||||
# Motores De Base De Datos {#database-engines}
|
||||
# Motores de base de datos {#database-engines}
|
||||
|
||||
Los motores de bases de datos le permiten trabajar con tablas.
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 31
|
||||
toc_title: Perezoso
|
||||
---
|
||||
@ -11,7 +11,7 @@ Mantiene las tablas en RAM solamente `expiration_time_in_seconds` segundos despu
|
||||
|
||||
Está optimizado para almacenar muchas tablas pequeñas \* Log, para las cuales hay un largo intervalo de tiempo entre los accesos.
|
||||
|
||||
## Creación De Una Base De Datos {#creating-a-database}
|
||||
## Creación de una base de datos {#creating-a-database}
|
||||
|
||||
CREATE DATABASE testlazy ENGINE = Lazy(expiration_time_in_seconds);
|
||||
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 30
|
||||
toc_title: MySQL
|
||||
---
|
||||
|
||||
# Mysql {#mysql}
|
||||
# MySQL {#mysql}
|
||||
|
||||
Permite conectarse a bases de datos en un servidor MySQL remoto y realizar `INSERT` y `SELECT` consultas para intercambiar datos entre ClickHouse y MySQL.
|
||||
|
||||
@ -17,11 +17,11 @@ No puede realizar las siguientes consultas:
|
||||
- `CREATE TABLE`
|
||||
- `ALTER`
|
||||
|
||||
## Creación De Una Base De Datos {#creating-a-database}
|
||||
## Creación de una base de datos {#creating-a-database}
|
||||
|
||||
``` sql
|
||||
CREATE DATABASE [IF NOT EXISTS] db_name [ON CLUSTER cluster]
|
||||
ENGINE = MySQL('host:port', 'database', 'user', 'password')
|
||||
ENGINE = MySQL('host:port', ['database' | database], 'user', 'password')
|
||||
```
|
||||
|
||||
**Parámetros del motor**
|
||||
@ -31,7 +31,7 @@ ENGINE = MySQL('host:port', 'database', 'user', 'password')
|
||||
- `user` — MySQL user.
|
||||
- `password` — User password.
|
||||
|
||||
## Soporte De Tipos De Datos {#data_types-support}
|
||||
## Soporte de tipos de datos {#data_types-support}
|
||||
|
||||
| MySQL | Haga clic en Casa |
|
||||
|----------------------------------|--------------------------------------------------------------|
|
||||
@ -53,7 +53,7 @@ Todos los demás tipos de datos MySQL se convierten en [Cadena](../../sql-refere
|
||||
|
||||
[NULL](../../sql-reference/data-types/nullable.md) se admite.
|
||||
|
||||
## Ejemplos De Uso {#examples-of-use}
|
||||
## Ejemplos de uso {#examples-of-use}
|
||||
|
||||
Tabla en MySQL:
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
toc_folder_title: Engines
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_folder_title: Motor
|
||||
toc_priority: 25
|
||||
---
|
||||
|
||||
|
@ -1,12 +1,12 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
toc_folder_title: Table Engines
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_folder_title: Motores de mesa
|
||||
toc_priority: 26
|
||||
toc_title: "Implantaci\xF3n"
|
||||
---
|
||||
|
||||
# Motores De Mesa {#table_engines}
|
||||
# Motores de mesa {#table_engines}
|
||||
|
||||
El motor de tabla (tipo de tabla) determina:
|
||||
|
||||
@ -17,11 +17,11 @@ El motor de tabla (tipo de tabla) determina:
|
||||
- Si es posible la ejecución de solicitudes multiproceso.
|
||||
- Parámetros de replicación de datos.
|
||||
|
||||
## Familias De Motores {#engine-families}
|
||||
## Familias de motores {#engine-families}
|
||||
|
||||
### Mergetree {#mergetree}
|
||||
### Método de codificación de datos: {#mergetree}
|
||||
|
||||
Los motores de mesa más universales y funcionales para tareas de alta carga. La propiedad compartida por estos motores es la inserción rápida de datos con el posterior procesamiento de datos en segundo plano. `MergeTree` Los motores familiares admiten la replicación de datos (con [Replicado\*](mergetree-family/replication.md#replication) versiones de motores), particionamiento y otras características no admitidas en otros motores.
|
||||
Los motores de mesa más universales y funcionales para tareas de alta carga. La propiedad compartida por estos motores es la inserción rápida de datos con el posterior procesamiento de datos en segundo plano. `MergeTree` Los motores familiares admiten la replicación de datos (con [Replicado\*](mergetree-family/replication.md#table_engines-replication) versiones de motores), particionamiento y otras características no admitidas en otros motores.
|
||||
|
||||
Motores en la familia:
|
||||
|
||||
@ -43,7 +43,7 @@ Motores en la familia:
|
||||
- [StripeLog](log-family/stripelog.md#stripelog)
|
||||
- [Registro](log-family/log.md#log)
|
||||
|
||||
### Motores De integración {#integration-engines}
|
||||
### Motores de integración {#integration-engines}
|
||||
|
||||
Motores para comunicarse con otros sistemas de almacenamiento y procesamiento de datos.
|
||||
|
||||
@ -55,14 +55,14 @@ Motores en la familia:
|
||||
- [JDBC](integrations/jdbc.md#table-engine-jdbc)
|
||||
- [HDFS](integrations/hdfs.md#hdfs)
|
||||
|
||||
### Motores Especiales {#special-engines}
|
||||
### Motores especiales {#special-engines}
|
||||
|
||||
Motores en la familia:
|
||||
|
||||
- [Distribuido](special/distributed.md#distributed)
|
||||
- [Método de codificación de datos:](special/materializedview.md#materializedview)
|
||||
- [Diccionario](special/dictionary.md#dictionary)
|
||||
- [Fusionar](special/merge.md#merge
|
||||
- \[Fusión\](special/merge.md\#merge
|
||||
- [File](special/file.md#file)
|
||||
- [Nulo](special/null.md#null)
|
||||
- [Establecer](special/set.md#set)
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 36
|
||||
toc_title: HDFS
|
||||
---
|
||||
@ -50,7 +50,7 @@ SELECT * FROM hdfs_engine_table LIMIT 2
|
||||
└──────┴───────┘
|
||||
```
|
||||
|
||||
## Detalles De implementación {#implementation-details}
|
||||
## Detalles de implementación {#implementation-details}
|
||||
|
||||
- Las lecturas y escrituras pueden ser paralelas
|
||||
- No soportado:
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
toc_folder_title: Integrations
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_folder_title: "Integraci\xF3n"
|
||||
toc_priority: 30
|
||||
---
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 34
|
||||
toc_title: JDBC
|
||||
---
|
||||
@ -13,7 +13,7 @@ Para implementar la conexión JDBC, ClickHouse utiliza el programa independiente
|
||||
|
||||
Este motor soporta el [NULL](../../../sql-reference/data-types/nullable.md) tipo de datos.
|
||||
|
||||
## Creación De Una Tabla {#creating-a-table}
|
||||
## Creación de una tabla {#creating-a-table}
|
||||
|
||||
``` sql
|
||||
CREATE TABLE [IF NOT EXISTS] [db.]table_name
|
||||
@ -34,7 +34,7 @@ ENGINE = JDBC(dbms_uri, external_database, external_table)
|
||||
|
||||
- `external_table` — Name of the table in `external_database`.
|
||||
|
||||
## Ejemplo De Uso {#usage-example}
|
||||
## Ejemplo de uso {#usage-example}
|
||||
|
||||
Crear una tabla en el servidor MySQL conectándose directamente con su cliente de consola:
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 32
|
||||
toc_title: Kafka
|
||||
---
|
||||
@ -15,7 +15,7 @@ Kafka te permite:
|
||||
- Organice el almacenamiento tolerante a fallos.
|
||||
- Secuencias de proceso a medida que estén disponibles.
|
||||
|
||||
## Creación De Una Tabla {#table_engine-kafka-creating-a-table}
|
||||
## Creación de una tabla {#table_engine-kafka-creating-a-table}
|
||||
|
||||
``` sql
|
||||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
@ -32,22 +32,26 @@ SETTINGS
|
||||
[kafka_row_delimiter = 'delimiter_symbol',]
|
||||
[kafka_schema = '',]
|
||||
[kafka_num_consumers = N,]
|
||||
[kafka_skip_broken_messages = N]
|
||||
[kafka_max_block_size = 0,]
|
||||
[kafka_skip_broken_messages = N,]
|
||||
[kafka_commit_every_batch = 0]
|
||||
```
|
||||
|
||||
Parámetros requeridos:
|
||||
|
||||
- `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_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` función, tal como `JSONEachRow`. Para obtener más información, consulte [Formato](../../../interfaces/formats.md) apartado.
|
||||
|
||||
Parámetros opcionales:
|
||||
|
||||
- `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/) requiere la ruta de acceso al archivo de esquema y el nombre de la raíz `schema.capnp:Message` objeto.
|
||||
- `kafka_schema` – Parameter that must be used if the format requires a schema definition. For example, [Cap'n Proto](https://capnproto.org/) requiere la ruta de acceso al archivo de esquema y el nombre de la raíz `schema.capnp:Message` objeto.
|
||||
- `kafka_num_consumers` – The number of consumers per table. Default: `1`. Especifique más consumidores si el rendimiento de un consumidor es insuficiente. El número total de consumidores no debe exceder el número de particiones en el tema, ya que solo se puede asignar un consumidor por partición.
|
||||
- `kafka_max_block_size` - El tamaño máximo de lote (en mensajes) para la encuesta (predeterminado: `max_block_size`).
|
||||
- `kafka_skip_broken_messages` – Kafka message parser tolerance to schema-incompatible messages per block. Default: `0`. Si `kafka_skip_broken_messages = N` entonces el motor salta *N* Mensajes de Kafka que no se pueden analizar (un mensaje es igual a una fila de datos).
|
||||
- `kafka_commit_every_batch` - Confirmar cada lote consumido y manejado en lugar de una única confirmación después de escribir un bloque completo (predeterminado: `0`).
|
||||
|
||||
Ejemplos:
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 33
|
||||
toc_title: MySQL
|
||||
---
|
||||
@ -9,7 +9,7 @@ toc_title: MySQL
|
||||
|
||||
El motor MySQL le permite realizar `SELECT` consultas sobre datos almacenados en un servidor MySQL remoto.
|
||||
|
||||
## Creación De Una Tabla {#creating-a-table}
|
||||
## Creación de una tabla {#creating-a-table}
|
||||
|
||||
``` sql
|
||||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
@ -51,7 +51,7 @@ Simple `WHERE` cláusulas tales como `=, !=, >, >=, <, <=` se ejecutan en el ser
|
||||
|
||||
El resto de las condiciones y el `LIMIT` La restricción de muestreo se ejecuta en ClickHouse solo después de que finalice la consulta a MySQL.
|
||||
|
||||
## Ejemplo De Uso {#usage-example}
|
||||
## Ejemplo de uso {#usage-example}
|
||||
|
||||
Tabla en MySQL:
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 35
|
||||
toc_title: ODBC
|
||||
---
|
||||
@ -13,7 +13,7 @@ Para implementar con seguridad conexiones ODBC, ClickHouse usa un programa separ
|
||||
|
||||
Este motor soporta el [NULL](../../../sql-reference/data-types/nullable.md) tipo de datos.
|
||||
|
||||
## Creación De Una Tabla {#creating-a-table}
|
||||
## Creación de una tabla {#creating-a-table}
|
||||
|
||||
``` sql
|
||||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
@ -38,7 +38,7 @@ La estructura de la tabla puede diferir de la estructura de la tabla de origen:
|
||||
- `external_database` — Name of a database in an external DBMS.
|
||||
- `external_table` — Name of a table in the `external_database`.
|
||||
|
||||
## Ejemplo De Uso {#usage-example}
|
||||
## Ejemplo de uso {#usage-example}
|
||||
|
||||
**Recuperación de datos de la instalación local de MySQL a través de ODBC**
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
toc_folder_title: Log Family
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_folder_title: Familia de registro
|
||||
toc_priority: 29
|
||||
---
|
||||
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 31
|
||||
toc_title: "Implantaci\xF3n"
|
||||
---
|
||||
|
||||
# Familia Del Motor De Registro {#log-engine-family}
|
||||
# Familia del motor de registro {#log-engine-family}
|
||||
|
||||
Estos motores fueron desarrollados para escenarios en los que necesita escribir rápidamente muchas tablas pequeñas (hasta aproximadamente 1 millón de filas) y leerlas más tarde en su conjunto.
|
||||
|
||||
@ -15,7 +15,7 @@ Motores de la familia:
|
||||
- [Registro](log.md)
|
||||
- [TinyLog](tinylog.md)
|
||||
|
||||
## Propiedades Comunes {#common-properties}
|
||||
## Propiedades comunes {#common-properties}
|
||||
|
||||
Motor:
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 33
|
||||
toc_title: Registro
|
||||
---
|
||||
|
@ -1,17 +1,17 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 32
|
||||
toc_title: StripeLog
|
||||
---
|
||||
|
||||
# Lista De Stripelog {#stripelog}
|
||||
# Lista de Stripelog {#stripelog}
|
||||
|
||||
Este motor pertenece a la familia de motores de registro. Consulte las propiedades comunes de los motores de registro y sus diferencias en [Familia del motor de registro](log-family.md) artículo.
|
||||
|
||||
Utilice este motor en escenarios en los que necesite escribir muchas tablas con una pequeña cantidad de datos (menos de 1 millón de filas).
|
||||
|
||||
## Creación De Una Tabla {#table_engines-stripelog-creating-a-table}
|
||||
## Creación de una tabla {#table_engines-stripelog-creating-a-table}
|
||||
|
||||
``` sql
|
||||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
@ -24,7 +24,7 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
|
||||
Vea la descripción detallada del [CREATE TABLE](../../../sql-reference/statements/create.md#create-table-query) consulta.
|
||||
|
||||
## Escribir Los Datos {#table_engines-stripelog-writing-the-data}
|
||||
## Escribir los datos {#table_engines-stripelog-writing-the-data}
|
||||
|
||||
El `StripeLog` el motor almacena todas las columnas en un archivo. Para cada `INSERT` consulta, ClickHouse agrega el bloque de datos al final de un archivo de tabla, escribiendo columnas una por una.
|
||||
|
||||
@ -35,11 +35,11 @@ Para cada tabla, ClickHouse escribe los archivos:
|
||||
|
||||
El `StripeLog` el motor no soporta el `ALTER UPDATE` y `ALTER DELETE` operación.
|
||||
|
||||
## Lectura De Los Datos {#table_engines-stripelog-reading-the-data}
|
||||
## Lectura de los datos {#table_engines-stripelog-reading-the-data}
|
||||
|
||||
El archivo con marcas permite ClickHouse paralelizar la lectura de datos. Esto significa que un `SELECT` query devuelve filas en un orden impredecible. Utilice el `ORDER BY` cláusula para ordenar filas.
|
||||
|
||||
## Ejemplo De Uso {#table_engines-stripelog-example-of-use}
|
||||
## Ejemplo de uso {#table_engines-stripelog-example-of-use}
|
||||
|
||||
Creación de una tabla:
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 34
|
||||
toc_title: TinyLog
|
||||
---
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 35
|
||||
toc_title: "Agregaci\xF3nMergeTree"
|
||||
---
|
||||
@ -11,11 +11,14 @@ El motor hereda de [Método de codificación de datos:](mergetree.md#table_engin
|
||||
|
||||
Usted puede utilizar `AggregatingMergeTree` tablas para la agregación de datos incrementales, incluidas las vistas materializadas agregadas.
|
||||
|
||||
El motor procesa todas las columnas con [AggregateFunction](../../../sql-reference/data-types/aggregatefunction.md) tipo.
|
||||
El motor procesa todas las columnas con los siguientes tipos:
|
||||
|
||||
- [AggregateFunction](../../../sql-reference/data-types/aggregatefunction.md)
|
||||
- [SimpleAggregateFunction](../../../sql-reference/data-types/simpleaggregatefunction.md)
|
||||
|
||||
Es apropiado usar `AggregatingMergeTree` si reduce el número de filas por pedidos.
|
||||
|
||||
## Creación De Una Tabla {#creating-a-table}
|
||||
## Creación de una tabla {#creating-a-table}
|
||||
|
||||
``` sql
|
||||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
@ -63,7 +66,7 @@ Al seleccionar datos de `AggregatingMergeTree` mesa, uso `GROUP BY` cláusula y
|
||||
|
||||
En los resultados de `SELECT` consulta, los valores de `AggregateFunction` tipo tiene representación binaria específica de la implementación para todos los formatos de salida de ClickHouse. Si volcar datos en, por ejemplo, `TabSeparated` formato con `SELECT` consulta entonces este volcado se puede cargar de nuevo usando `INSERT` consulta.
|
||||
|
||||
## Ejemplo De Una Vista Materializada Agregada {#example-of-an-aggregated-materialized-view}
|
||||
## Ejemplo de una vista materializada agregada {#example-of-an-aggregated-materialized-view}
|
||||
|
||||
`AggregatingMergeTree` vista materializada que mira el `test.visits` tabla:
|
||||
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 36
|
||||
toc_title: ColapsarMergeTree
|
||||
---
|
||||
|
||||
# Colapsarmergetree {#table_engine-collapsingmergetree}
|
||||
# ColapsarMergeTree {#table_engine-collapsingmergetree}
|
||||
|
||||
El motor hereda de [Método de codificación de datos:](mergetree.md) y agrega la lógica de las filas que colapsan al algoritmo de fusión de partes de datos.
|
||||
|
||||
@ -13,7 +13,7 @@ El motor hereda de [Método de codificación de datos:](mergetree.md) y agrega l
|
||||
|
||||
El motor puede reducir significativamente el volumen de almacenamiento y aumentar la eficiencia de `SELECT` consulta como consecuencia.
|
||||
|
||||
## Creación De Una Tabla {#creating-a-table}
|
||||
## Creación de una tabla {#creating-a-table}
|
||||
|
||||
``` sql
|
||||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
@ -119,11 +119,8 @@ Cuando ClickHouse combina partes de datos, cada grupo de filas consecutivas tien
|
||||
Para cada parte de datos resultante, ClickHouse guarda:
|
||||
|
||||
1. El primero “cancel” y el último “state” si el número de “state” y “cancel” y la última fila es una “state” fila.
|
||||
|
||||
2. El último “state” fila, si hay más “state” filas que “cancel” filas.
|
||||
|
||||
3. El primero “cancel” fila, si hay más “cancel” filas que “state” filas.
|
||||
|
||||
4. Ninguna de las filas, en todos los demás casos.
|
||||
|
||||
También cuando hay al menos 2 más “state” filas que “cancel” filas, o al menos 2 más “cancel” filas entonces “state” fila, la fusión continúa, pero ClickHouse trata esta situación como un error lógico y la registra en el registro del servidor. Este error puede producirse si se insertan los mismos datos más de una vez.
|
||||
@ -139,7 +136,7 @@ Los agregados `count`, `sum` y `avg` podría calcularse de esta manera. El agreg
|
||||
|
||||
Si necesita extraer datos sin agregación (por ejemplo, para comprobar si hay filas presentes cuyos valores más recientes coinciden con ciertas condiciones), puede utilizar el `FINAL` modificador para el `FROM` clausula. Este enfoque es significativamente menos eficiente.
|
||||
|
||||
## Ejemplo De Uso {#example-of-use}
|
||||
## Ejemplo de uso {#example-of-use}
|
||||
|
||||
Datos de ejemplo:
|
||||
|
||||
@ -193,7 +190,7 @@ SELECT * FROM UAct
|
||||
└─────────────────────┴───────────┴──────────┴──────┘
|
||||
```
|
||||
|
||||
¿qué vemos y dónde está colapsando?
|
||||
¿Qué vemos y dónde está colapsando?
|
||||
|
||||
Con dos `INSERT` consultas, hemos creado 2 partes de datos. El `SELECT` la consulta se realizó en 2 hilos, y obtuvimos un orden aleatorio de filas. No se ha producido un colapso porque todavía no se había fusionado las partes de datos. ClickHouse fusiona parte de datos en un momento desconocido que no podemos predecir.
|
||||
|
||||
@ -229,7 +226,7 @@ SELECT * FROM UAct FINAL
|
||||
|
||||
Esta forma de seleccionar los datos es muy ineficiente. No lo use para mesas grandes.
|
||||
|
||||
## Ejemplo De Otro Enfoque {#example-of-another-approach}
|
||||
## Ejemplo de otro enfoque {#example-of-another-approach}
|
||||
|
||||
Datos de ejemplo:
|
||||
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 32
|
||||
toc_title: "Clave de partici\xF3n personalizada"
|
||||
---
|
||||
|
||||
# Clave De partición Personalizada {#custom-partitioning-key}
|
||||
# Clave de partición personalizada {#custom-partitioning-key}
|
||||
|
||||
La partición está disponible para el [Método de codificación de datos:](mergetree.md) mesas familiares (incluyendo [repetición](replication.md) tabla). [Vistas materializadas](../special/materializedview.md#materializedview) basado en tablas MergeTree soporte de particionamiento, también.
|
||||
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 38
|
||||
toc_title: GraphiteMergeTree
|
||||
---
|
||||
|
||||
# Graphitemergetree {#graphitemergetree}
|
||||
# GraphiteMergeTree {#graphitemergetree}
|
||||
|
||||
Este motor está diseñado para el adelgazamiento y la agregación / promedio (rollup) [Grafito](http://graphite.readthedocs.io/en/latest/index.html) datos. Puede ser útil para los desarrolladores que desean usar ClickHouse como almacén de datos para Graphite.
|
||||
|
||||
@ -13,7 +13,7 @@ Puede usar cualquier motor de tabla ClickHouse para almacenar los datos de Graph
|
||||
|
||||
El motor hereda propiedades de [Método de codificación de datos:](mergetree.md).
|
||||
|
||||
## Creación De Una Tabla {#creating-table}
|
||||
## Creación de una tabla {#creating-table}
|
||||
|
||||
``` sql
|
||||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
@ -79,7 +79,7 @@ Todos los parámetros excepto `config_section` el mismo significado que en `Merg
|
||||
|
||||
</details>
|
||||
|
||||
## Configuración Acumulativa {#rollup-configuration}
|
||||
## Configuración acumulativa {#rollup-configuration}
|
||||
|
||||
La configuración del paquete acumulativo está definida por [graphite\_rollup](../../../operations/server-configuration-parameters/settings.md#server_configuration_parameters-graphite) parámetro en la configuración del servidor. El nombre del parámetro podría ser cualquiera. Puede crear varias configuraciones y usarlas para diferentes tablas.
|
||||
|
||||
@ -88,7 +88,7 @@ Estructura de configuración Rollup:
|
||||
required-columns
|
||||
patterns
|
||||
|
||||
### Columnas Requeridas {#required-columns}
|
||||
### Columnas requeridas {#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`.
|
||||
@ -136,7 +136,7 @@ Campos para `pattern` y `default` apartado:
|
||||
- `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]`.
|
||||
|
||||
### Ejemplo De configuración {#configuration-example}
|
||||
### Ejemplo de configuración {#configuration-example}
|
||||
|
||||
``` xml
|
||||
<graphite_rollup>
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
toc_folder_title: MergeTree Family
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_folder_title: Familia MergeTree
|
||||
toc_priority: 28
|
||||
---
|
||||
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 30
|
||||
toc_title: "M\xE9todo de codificaci\xF3n de datos:"
|
||||
---
|
||||
|
||||
# Mergetree {#table_engines-mergetree}
|
||||
# Método de codificación de datos: {#table_engines-mergetree}
|
||||
|
||||
El `MergeTree` motor y otros motores de esta familia (`*MergeTree`) son los motores de mesa ClickHouse más robustos.
|
||||
|
||||
@ -32,7 +32,7 @@ Principales características:
|
||||
!!! info "INFO"
|
||||
El [Fusionar](../special/merge.md#merge) el motor no pertenece al `*MergeTree` familia.
|
||||
|
||||
## Creación De Una Tabla {#table_engine-mergetree-creating-a-table}
|
||||
## Creación de una tabla {#table_engine-mergetree-creating-a-table}
|
||||
|
||||
``` sql
|
||||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
@ -56,7 +56,7 @@ Para obtener una descripción de los parámetros, consulte [Descripción de la c
|
||||
!!! note "Nota"
|
||||
`INDEX` es una característica experimental, ver [Índices de saltos de datos](#table_engine-mergetree-data_skipping-indexes).
|
||||
|
||||
### Cláusulas De Consulta {#mergetree-query-clauses}
|
||||
### Cláusulas de consulta {#mergetree-query-clauses}
|
||||
|
||||
- `ENGINE` — Name and parameters of the engine. `ENGINE = MergeTree()`. El `MergeTree` el motor no tiene parámetros.
|
||||
|
||||
@ -94,7 +94,7 @@ Para obtener una descripción de los parámetros, consulte [Descripción de la c
|
||||
- `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` bytes, ClickHouse lee y escribe los datos en el disco de almacenamiento utilizando la interfaz de E / S directa (`O_DIRECT` opcion). Si `min_merge_bytes_to_use_direct_io = 0`, entonces la E/S directa está deshabilitada. Valor predeterminado: `10 * 1024 * 1024 * 1024` byte.
|
||||
<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.
|
||||
- `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 [Uso de varios dispositivos de bloque para el almacenamiento de datos](#table_engine-mergetree-multiple-volumes).
|
||||
|
||||
@ -106,7 +106,7 @@ ENGINE MergeTree() PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDa
|
||||
|
||||
En el ejemplo, configuramos la partición por mes.
|
||||
|
||||
También establecemos una expresión para el muestreo como un hash por el ID de usuario. Esto le permite pseudoaleatorizar los datos en la tabla para cada `CounterID` y `EventDate`. Si define un [SAMPLE](../../../sql-reference/statements/select.md#select-sample-clause) cláusula al seleccionar los datos, ClickHouse devolverá una muestra de datos pseudoaleatoria uniforme para un subconjunto de usuarios.
|
||||
También establecemos una expresión para el muestreo como un hash por el ID de usuario. Esto le permite pseudoaleatorizar los datos en la tabla para cada `CounterID` y `EventDate`. Si define un [SAMPLE](../../../sql-reference/statements/select/sample.md#select-sample-clause) cláusula al seleccionar los datos, ClickHouse devolverá una muestra de datos pseudoaleatoria uniforme para un subconjunto de usuarios.
|
||||
|
||||
El `index_granularity` se puede omitir porque 8192 es el valor predeterminado.
|
||||
|
||||
@ -142,7 +142,7 @@ MergeTree(EventDate, intHash32(UserID), (CounterID, EventDate, intHash32(UserID)
|
||||
El `MergeTree` engine se configura de la misma manera que en el ejemplo anterior para el método de configuración del motor principal.
|
||||
</details>
|
||||
|
||||
## Almacenamiento De Datos {#mergetree-data-storage}
|
||||
## Almacenamiento de datos {#mergetree-data-storage}
|
||||
|
||||
Una tabla consta de partes de datos ordenadas por clave principal.
|
||||
|
||||
@ -154,7 +154,7 @@ Cada parte de datos se divide lógicamente en gránulos. Un gránulo es el conju
|
||||
|
||||
El tamaño del gránulo es restringido por `index_granularity` y `index_granularity_bytes` configuración del motor de tabla. El número de filas en un gránulo se encuentra en el `[1, index_granularity]` rango, dependiendo del tamaño de las filas. El tamaño de un gránulo puede exceder `index_granularity_bytes` si el tamaño de una sola fila es mayor que el valor de la configuración. En este caso, el tamaño del gránulo es igual al tamaño de la fila.
|
||||
|
||||
## Claves e índices Principales En Consultas {#primary-keys-and-indexes-in-queries}
|
||||
## Claves e índices principales en consultas {#primary-keys-and-indexes-in-queries}
|
||||
|
||||
Tome el `(CounterID, Date)` clave primaria como ejemplo. En este caso, la clasificación y el índice se pueden ilustrar de la siguiente manera:
|
||||
|
||||
@ -179,7 +179,7 @@ Los índices dispersos le permiten trabajar con una gran cantidad de filas de ta
|
||||
|
||||
ClickHouse no requiere una clave principal única. Puede insertar varias filas con la misma clave principal.
|
||||
|
||||
### Selección De La Clave Principal {#selecting-the-primary-key}
|
||||
### Selección de la clave principal {#selecting-the-primary-key}
|
||||
|
||||
El número de columnas en la clave principal no está explícitamente limitado. Dependiendo de la estructura de datos, puede incluir más o menos columnas en la clave principal. Esto puede:
|
||||
|
||||
@ -200,7 +200,7 @@ El número de columnas en la clave principal no está explícitamente limitado.
|
||||
|
||||
Una clave principal larga afectará negativamente al rendimiento de la inserción y al consumo de memoria, pero las columnas adicionales de la clave principal no afectarán al rendimiento de ClickHouse durante `SELECT` consulta.
|
||||
|
||||
### Elegir Una Clave Principal Que Difiere De La Clave De ordenación {#choosing-a-primary-key-that-differs-from-the-sorting-key}
|
||||
### Elegir una clave principal que difiere de la clave de ordenación {#choosing-a-primary-key-that-differs-from-the-sorting-key}
|
||||
|
||||
Es posible especificar una clave principal (una expresión con valores que se escriben en el archivo de índice para cada marca) que es diferente de la clave de ordenación (una expresión para ordenar las filas en partes de datos). En este caso, la tupla de expresión de clave primaria debe ser un prefijo de la tupla de expresión de clave de ordenación.
|
||||
|
||||
@ -211,7 +211,7 @@ En este caso, tiene sentido dejar solo unas pocas columnas en la clave principal
|
||||
|
||||
[ALTER](../../../sql-reference/statements/alter.md) de la clave de ordenación es una operación ligera porque cuando se agrega una nueva columna simultáneamente a la tabla y a la clave de ordenación, las partes de datos existentes no necesitan ser cambiadas. Dado que la clave de ordenación anterior es un prefijo de la nueva clave de ordenación y no hay datos en la columna recién agregada, los datos se ordenan tanto por las claves de ordenación antiguas como por las nuevas en el momento de la modificación de la tabla.
|
||||
|
||||
### Uso De índices y Particiones En Consultas {#use-of-indexes-and-partitions-in-queries}
|
||||
### Uso de índices y particiones en consultas {#use-of-indexes-and-partitions-in-queries}
|
||||
|
||||
Para `SELECT` consultas, ClickHouse analiza si se puede usar un índice. Se puede usar un índice si el `WHERE/PREWHERE` clause tiene una expresión (como uno de los elementos de conjunción, o enteramente) que representa una operación de comparación de igualdad o desigualdad, o si tiene `IN` o `LIKE` con un prefijo fijo en columnas o expresiones que están en la clave principal o clave de partición, o en ciertas funciones parcialmente repetitivas de estas columnas, o relaciones lógicas de estas expresiones.
|
||||
|
||||
@ -243,7 +243,7 @@ Para comprobar si ClickHouse puede usar el índice al ejecutar una consulta, use
|
||||
|
||||
La clave para particionar por mes permite leer solo aquellos bloques de datos que contienen fechas del rango adecuado. En este caso, el bloque de datos puede contener datos para muchas fechas (hasta un mes). Dentro de un bloque, los datos se ordenan por clave principal, que puede no contener la fecha como la primera columna. Debido a esto, el uso de una consulta con solo una condición de fecha que no especifica el prefijo de clave principal hará que se lean más datos que para una sola fecha.
|
||||
|
||||
### Uso Del índice Para Claves Primarias Parcialmente monotónicas {#use-of-index-for-partially-monotonic-primary-keys}
|
||||
### Uso del índice para claves primarias parcialmente monótonas {#use-of-index-for-partially-monotonic-primary-keys}
|
||||
|
||||
Considere, por ejemplo, los días del mes. Ellos forman un [monótona secuencia](https://en.wikipedia.org/wiki/Monotonic_function) durante un mes, pero no monótono durante períodos más prolongados. Esta es una secuencia parcialmente monotónica. Si un usuario crea la tabla con clave primaria parcialmente monótona, ClickHouse crea un índice disperso como de costumbre. Cuando un usuario selecciona datos de este tipo de tabla, ClickHouse analiza las condiciones de consulta. Si el usuario desea obtener datos entre dos marcas del índice y ambas marcas caen dentro de un mes, ClickHouse puede usar el índice en este caso particular porque puede calcular la distancia entre los parámetros de una consulta y las marcas de índice.
|
||||
|
||||
@ -251,7 +251,7 @@ ClickHouse no puede usar un índice si los valores de la clave principal en el r
|
||||
|
||||
ClickHouse usa esta lógica no solo para secuencias de días del mes, sino para cualquier clave principal que represente una secuencia parcialmente monotónica.
|
||||
|
||||
### Índices De Saltos De Datos (experimental) {#table_engine-mergetree-data_skipping-indexes}
|
||||
### Índices de saltos de datos (experimental) {#table_engine-mergetree-data_skipping-indexes}
|
||||
|
||||
La declaración de índice se encuentra en la sección de columnas del `CREATE` consulta.
|
||||
|
||||
@ -285,7 +285,7 @@ SELECT count() FROM table WHERE s < 'z'
|
||||
SELECT count() FROM table WHERE u64 * i32 == 10 AND u64 * length(s) >= 1234
|
||||
```
|
||||
|
||||
#### Tipos De índices Disponibles {#available-types-of-indices}
|
||||
#### Tipos de índices disponibles {#available-types-of-indices}
|
||||
|
||||
- `minmax`
|
||||
|
||||
@ -297,7 +297,7 @@ SELECT count() FROM table WHERE u64 * i32 == 10 AND u64 * length(s) >= 1234
|
||||
|
||||
- `ngrambf_v1(n, size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed)`
|
||||
|
||||
Tiendas a [Bloom filter](https://en.wikipedia.org/wiki/Bloom_filter) que contiene todos los ngrams de un bloque de datos. Funciona solo con cadenas. Puede ser utilizado para la optimización de `equals`, `like` y `in` expresiones.
|
||||
Tiendas a [Filtro de floración](https://en.wikipedia.org/wiki/Bloom_filter) que contiene todos los ngrams de un bloque de datos. Funciona solo con cadenas. Puede ser utilizado para la optimización de `equals`, `like` y `in` expresiones.
|
||||
|
||||
- `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).
|
||||
@ -324,7 +324,7 @@ INDEX sample_index2 (u64 * length(str), i32 + f64 * 100, date, str) TYPE set(100
|
||||
INDEX sample_index3 (lower(str), str) TYPE ngrambf_v1(3, 256, 2, 0) GRANULARITY 4
|
||||
```
|
||||
|
||||
#### Funciones De Apoyo {#functions-support}
|
||||
#### Funciones de apoyo {#functions-support}
|
||||
|
||||
Condiciones en el `WHERE` cláusula contiene llamadas de las funciones que operan con columnas. Si la columna forma parte de un índice, ClickHouse intenta usar este índice al realizar las funciones. ClickHouse admite diferentes subconjuntos de funciones para usar índices.
|
||||
|
||||
@ -366,13 +366,13 @@ Los filtros Bloom pueden tener coincidencias falsas positivas, por lo que `ngram
|
||||
- `s != 1`
|
||||
- `NOT startsWith(s, 'test')`
|
||||
|
||||
## Acceso a Datos simultáneos {#concurrent-data-access}
|
||||
## Acceso a datos simultáneos {#concurrent-data-access}
|
||||
|
||||
Para el acceso simultáneo a tablas, usamos versiones múltiples. En otras palabras, cuando una tabla se lee y actualiza simultáneamente, los datos se leen de un conjunto de partes que está actualizado en el momento de la consulta. No hay cerraduras largas. Las inserciones no se interponen en el camino de las operaciones de lectura.
|
||||
|
||||
La lectura de una tabla se paralela automáticamente.
|
||||
|
||||
## TTL Para Columnas y Tablas {#table_engine-mergetree-ttl}
|
||||
## TTL para columnas y tablas {#table_engine-mergetree-ttl}
|
||||
|
||||
Determina la duración de los valores.
|
||||
|
||||
@ -387,7 +387,7 @@ TTL time_column
|
||||
TTL time_column + interval
|
||||
```
|
||||
|
||||
Definir `interval`, utilizar [intervalo de tiempo](../../../sql-reference/operators.md#operators-datetime) operador.
|
||||
Definir `interval`, utilizar [intervalo de tiempo](../../../sql-reference/operators/index.md#operators-datetime) operador.
|
||||
|
||||
``` sql
|
||||
TTL date_time + INTERVAL 1 MONTH
|
||||
@ -476,11 +476,11 @@ ALTER TABLE example_table
|
||||
|
||||
Los datos con un TTL caducado se eliminan cuando ClickHouse fusiona partes de datos.
|
||||
|
||||
Cuando ClickHouse ve que los datos han caducado, realiza una combinación fuera de programación. Para controlar la frecuencia de tales fusiones, puede establecer [Método de codificación de datos:](#mergetree_setting-merge_with_ttl_timeout). Si el valor es demasiado bajo, realizará muchas fusiones fuera de horario que pueden consumir muchos recursos.
|
||||
Cuando ClickHouse ve que los datos han caducado, realiza una combinación fuera de programación. Para controlar la frecuencia de tales fusiones, puede establecer `merge_with_ttl_timeout`. Si el valor es demasiado bajo, realizará muchas fusiones fuera de horario que pueden consumir muchos recursos.
|
||||
|
||||
Si realiza el `SELECT` consulta entre fusiones, puede obtener datos caducados. Para evitarlo, use el [OPTIMIZE](../../../sql-reference/statements/misc.md#misc_operations-optimize) consulta antes `SELECT`.
|
||||
|
||||
## Uso De múltiples Dispositivos De Bloque Para El Almacenamiento De Datos {#table_engine-mergetree-multiple-volumes}
|
||||
## Uso de varios dispositivos de bloque para el almacenamiento de datos {#table_engine-mergetree-multiple-volumes}
|
||||
|
||||
### Implantación {#introduction}
|
||||
|
||||
@ -495,13 +495,13 @@ La parte de datos es la unidad móvil mínima para `MergeTree`-mesas de motor. L
|
||||
- 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.
|
||||
|
||||
Los nombres dados a las entidades descritas se pueden encontrar en las tablas del sistema, [sistema.almacenamiento\_policies](../../../operations/system-tables.md#system_tables-storage_policies) y [sistema.disco](../../../operations/system-tables.md#system_tables-disks). Para aplicar una de las directivas de almacenamiento configuradas para una tabla, `storage_policy` establecimiento de `MergeTree`-motor de la familia de las tablas.
|
||||
Los nombres dados a las entidades descritas se pueden encontrar en las tablas del sistema, [sistema.almacenamiento\_policies](../../../operations/system-tables.md#system_tables-storage_policies) y [sistema.disco](../../../operations/system-tables.md#system_tables-disks). Para aplicar una de las directivas de almacenamiento configuradas para una tabla, `storage_policy` establecimiento de `MergeTree`-mesas de la familia del motor.
|
||||
|
||||
### Configuración {#table_engine-mergetree-multiple-volumes_configure}
|
||||
|
||||
Discos, volúmenes y políticas de almacenamiento deben ser declaradas dentro de la `<storage_configuration>` etiqueta ya sea en el archivo principal `config.xml` o en un archivo distinto en el `config.d` directorio.
|
||||
Los discos, los volúmenes y las políticas de almacenamiento deben declararse `<storage_configuration>` etiqueta ya sea en el archivo principal `config.xml` o en un archivo distinto en el `config.d` directorio.
|
||||
|
||||
Configuración de la estructura:
|
||||
Estructura de configuración:
|
||||
|
||||
``` xml
|
||||
<storage_configuration>
|
||||
@ -567,7 +567,7 @@ Tags:
|
||||
- `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.
|
||||
- `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 ejemplos:
|
||||
@ -602,9 +602,9 @@ Cofiguration ejemplos:
|
||||
</storage_configuration>
|
||||
```
|
||||
|
||||
En un ejemplo dado, el `hdd_in_order` implementa la política de [Ronda-robin](https://en.wikipedia.org/wiki/Round-robin_scheduling) enfoque. Por lo tanto esta política define un sólo volumen (`single`), las partes de datos se almacenan en todos sus discos en orden circular. Dicha política puede ser bastante útil si hay varios discos similares montados en el sistema, pero RAID no está configurado. Tenga en cuenta que cada unidad de disco individual no es confiable y es posible que desee compensarlo con un factor de replicación de 3 o más.
|
||||
En un ejemplo dado, el `hdd_in_order` la política implementa el [Ronda-robin](https://en.wikipedia.org/wiki/Round-robin_scheduling) enfoque. Por lo tanto, esta política define solo un volumen (`single`), las partes de datos se almacenan en todos sus discos en orden circular. Dicha política puede ser bastante útil si hay varios discos similares montados en el sistema, pero RAID no está configurado. Tenga en cuenta que cada unidad de disco individual no es confiable y es posible que desee compensarlo con un factor de replicación de 3 o más.
|
||||
|
||||
Si hay diferentes tipos de discos disponibles en el sistema, `moving_from_ssd_to_hdd` la política puede ser utilizado en su lugar. Volumen `hot` consta de un disco SSD (`fast_ssd`), y el tamaño máximo de una parte que puede ser almacenado en este volumen es de 1GB. Todas las piezas con el tamaño de más de 1GB se almacenan directamente en el `cold` volumen, que contiene un disco duro `disk1`.
|
||||
Si hay diferentes tipos de discos disponibles en el sistema, `moving_from_ssd_to_hdd` política se puede utilizar en su lugar. Volumen `hot` consta de un disco SSD (`fast_ssd`), y el tamaño máximo de una pieza que se puede almacenar en este volumen es de 1 GB. Todas las piezas con el tamaño más grande que 1GB serán almacenadas directamente en `cold` volumen, que contiene un disco duro `disk1`.
|
||||
Además, una vez que el disco `fast_ssd` se llena en más del 80%, los datos se transferirán al `disk1` por un proceso en segundo plano.
|
||||
|
||||
El orden de enumeración de volúmenes dentro de una directiva de almacenamiento es importante. Una vez que un volumen está sobrellenado, los datos se mueven al siguiente. El orden de la enumeración del disco también es importante porque los datos se almacenan en ellos por turnos.
|
||||
@ -642,13 +642,13 @@ En todos estos casos, excepto las mutaciones y la congelación de particiones, u
|
||||
Bajo el capó, las mutaciones y la congelación de particiones hacen uso de [enlaces duros](https://en.wikipedia.org/wiki/Hard_link). Los enlaces duros entre diferentes discos no son compatibles, por lo tanto, en tales casos las partes resultantes se almacenan en los mismos discos que los iniciales.
|
||||
|
||||
En el fondo, las partes se mueven entre volúmenes en función de la cantidad de espacio libre (`move_factor` parámetro) según el orden en que se declaran los volúmenes en el archivo de configuración.
|
||||
Los datos nunca se transfieren desde el último y al primero. Uno puede usar tablas del sistema [sistema.part\_log](../../../operations/system-tables.md#system_tables-part-log) (campo `type = MOVE_PART`) y [sistema.parte](../../../operations/system-tables.md#system_tables-parts) (campo `path` y `disk`) para monitorear el fondo se mueve. Además, la información detallada se puede encontrar en los registros del servidor.
|
||||
Los datos nunca se transfieren desde el último y al primero. Uno puede usar tablas del sistema [sistema.part\_log](../../../operations/system-tables.md#system_tables-part-log) (campo `type = MOVE_PART`) y [sistema.parte](../../../operations/system-tables.md#system_tables-parts) (campo `path` y `disk`) para monitorear movimientos de fondo. Además, la información detallada se puede encontrar en los registros del servidor.
|
||||
|
||||
El usuario puede forzar el movimiento de una pieza o una partición de un volumen a otro mediante la consulta [ALTER TABLE … MOVE PART\|PARTITION … TO VOLUME\|DISK …](../../../sql-reference/statements/alter.md#alter_move-partition), todas las restricciones para las operaciones en segundo plano se tienen en cuenta. La consulta inicia un movimiento por sí misma y no espera a que se completen las operaciones en segundo plano. El usuario recibirá un mensaje de error si no hay suficiente espacio libre disponible o si no se cumple alguna de las condiciones requeridas.
|
||||
|
||||
Mover datos no interfiere con la replicación de datos. Por lo tanto, se pueden especificar diferentes directivas de almacenamiento para la misma tabla en diferentes réplicas.
|
||||
|
||||
Después de la finalización de las fusiones y mutaciones de fondo, las partes viejas se eliminan solo después de un cierto período de tiempo (`old_parts_lifetime`).
|
||||
Durante este tiempo, no se mueven a otros volúmenes o discos. Por lo tanto, hasta que finalmente se retira, se tomará en cuenta para la evaluación de los ocupados de espacio en disco.
|
||||
Durante este tiempo, no se mueven a otros volúmenes o discos. Por lo tanto, hasta que las partes finalmente se eliminen, aún se tienen en cuenta para la evaluación del espacio en disco ocupado.
|
||||
|
||||
[Artículo Original](https://clickhouse.tech/docs/ru/operations/table_engines/mergetree/) <!--hide-->
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 33
|
||||
toc_title: ReplacingMergeTree
|
||||
---
|
||||
|
||||
# Replacingmergetree {#replacingmergetree}
|
||||
# ReplacingMergeTree {#replacingmergetree}
|
||||
|
||||
El motor difiere de [Método de codificación de datos:](mergetree.md#table_engines-mergetree) en que elimina las entradas duplicadas con el mismo valor de clave principal (o más exactamente, con el mismo [clave de clasificación](mergetree.md) valor).
|
||||
|
||||
@ -13,7 +13,7 @@ La desduplicación de datos solo se produce durante una fusión. La fusión ocur
|
||||
|
||||
Así, `ReplacingMergeTree` es adecuado para borrar datos duplicados en segundo plano para ahorrar espacio, pero no garantiza la ausencia de duplicados.
|
||||
|
||||
## Creación De Una Tabla {#creating-a-table}
|
||||
## Creación de una tabla {#creating-a-table}
|
||||
|
||||
``` sql
|
||||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 31
|
||||
toc_title: "Replicaci\xF3n de datos"
|
||||
---
|
||||
|
||||
# Replicación De Datos {#table_engines-replication}
|
||||
# Replicación de datos {#table_engines-replication}
|
||||
|
||||
La replicación solo se admite para tablas de la familia MergeTree:
|
||||
|
||||
@ -79,7 +79,7 @@ Puede tener cualquier número de réplicas de los mismos datos. El Yandex.Metric
|
||||
|
||||
El sistema supervisa la sincronicidad de los datos en las réplicas y puede recuperarse después de un fallo. La conmutación por error es automática (para pequeñas diferencias en los datos) o semiautomática (cuando los datos difieren demasiado, lo que puede indicar un error de configuración).
|
||||
|
||||
## Creación De Tablas Replicadas {#creating-replicated-tables}
|
||||
## Creación de tablas replicadas {#creating-replicated-tables}
|
||||
|
||||
El `Replicated` prefijo se agrega al nombre del motor de tabla. Por ejemplo:`ReplicatedMergeTree`.
|
||||
|
||||
@ -149,7 +149,7 @@ Si agrega una nueva réplica después de que la tabla ya contenga algunos datos
|
||||
|
||||
Para eliminar una réplica, ejecute `DROP TABLE`. However, only one replica is deleted – the one that resides on the server where you run the query.
|
||||
|
||||
## Recuperación después De Fallos {#recovery-after-failures}
|
||||
## Recuperación después de fallos {#recovery-after-failures}
|
||||
|
||||
Si ZooKeeper no está disponible cuando se inicia un servidor, las tablas replicadas cambian al modo de solo lectura. El sistema intenta conectarse periódicamente a ZooKeeper.
|
||||
|
||||
@ -173,7 +173,7 @@ sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data
|
||||
|
||||
A continuación, reinicie el servidor. Al iniciar, el servidor elimina estos indicadores e inicia la recuperación.
|
||||
|
||||
## Recuperación después De La pérdida Completa De Datos {#recovery-after-complete-data-loss}
|
||||
## Recuperación después de la pérdida completa de datos {#recovery-after-complete-data-loss}
|
||||
|
||||
Si todos los datos y metadatos desaparecieron de uno de los servidores, siga estos pasos para la recuperación:
|
||||
|
||||
@ -188,7 +188,7 @@ Una opción de recuperación alternativa es eliminar información sobre la répl
|
||||
|
||||
No hay restricción en el ancho de banda de la red durante la recuperación. Tenga esto en cuenta si está restaurando muchas réplicas a la vez.
|
||||
|
||||
## La Conversión De Mergetree A Replicatedmergetree {#converting-from-mergetree-to-replicatedmergetree}
|
||||
## La conversión de MergeTree a ReplicatedMergeTree {#converting-from-mergetree-to-replicatedmergetree}
|
||||
|
||||
Usamos el término `MergeTree` para referirse a todos los motores de mesa en el `MergeTree family`, lo mismo que para `ReplicatedMergeTree`.
|
||||
|
||||
@ -200,7 +200,7 @@ Cambie el nombre de la tabla MergeTree existente y, a continuación, cree un `Re
|
||||
Mueva los datos de la tabla antigua a la `detached` subdirectorio dentro del directorio con los nuevos datos de la tabla (`/var/lib/clickhouse/data/db_name/table_name/`).
|
||||
Luego ejecuta `ALTER TABLE ATTACH PARTITION` en una de las réplicas para agregar estas partes de datos al conjunto de trabajo.
|
||||
|
||||
## La Conversión De Replicatedmergetree A Mergetree {#converting-from-replicatedmergetree-to-mergetree}
|
||||
## La conversión de ReplicatedMergeTree a MergeTree {#converting-from-replicatedmergetree-to-mergetree}
|
||||
|
||||
Cree una tabla MergeTree con un nombre diferente. Mueva todos los datos del directorio con el `ReplicatedMergeTree` datos de la tabla al directorio de datos de la nueva tabla. A continuación, elimine el `ReplicatedMergeTree` y reinicie el servidor.
|
||||
|
||||
@ -211,7 +211,7 @@ Si desea deshacerse de un `ReplicatedMergeTree` sin iniciar el servidor:
|
||||
|
||||
Después de esto, puede iniciar el servidor, crear un `MergeTree` tabla, mueva los datos a su directorio y, a continuación, reinicie el servidor.
|
||||
|
||||
## Recuperación Cuando Los Metadatos En El clúster De Zookeeper Se Pierden o Se dañan {#recovery-when-metadata-in-the-zookeeper-cluster-is-lost-or-damaged}
|
||||
## Recuperación cuando se pierden o se dañan los metadatos del clúster Zookeeper {#recovery-when-metadata-in-the-zookeeper-cluster-is-lost-or-damaged}
|
||||
|
||||
Si los datos de ZooKeeper se perdieron o se dañaron, puede guardar los datos moviéndolos a una tabla no duplicada como se describió anteriormente.
|
||||
|
||||
|
@ -1,17 +1,17 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 34
|
||||
toc_title: SummingMergeTree
|
||||
---
|
||||
|
||||
# Summingmergetree {#summingmergetree}
|
||||
# SummingMergeTree {#summingmergetree}
|
||||
|
||||
El motor hereda de [Método de codificación de datos:](mergetree.md#table_engines-mergetree). La diferencia es que al fusionar partes de datos para `SummingMergeTree` ClickHouse reemplaza todas las filas con la misma clave primaria (o más exactamente, con la misma [clave de clasificación](mergetree.md)) con una fila que contiene valores resumidos para las columnas con el tipo de datos numérico. Si la clave de ordenación está compuesta de manera que un solo valor de clave corresponde a un gran número de filas, esto reduce significativamente el volumen de almacenamiento y acelera la selección de datos.
|
||||
|
||||
Recomendamos usar el motor junto con `MergeTree`. Almacenar datos completos en `MergeTree` mesa, y el uso `SummingMergeTree` para el almacenamiento de datos agregados, por ejemplo, al preparar informes. Tal enfoque evitará que pierda datos valiosos debido a una clave primaria compuesta incorrectamente.
|
||||
|
||||
## Creación De Una Tabla {#creating-a-table}
|
||||
## Creación de una tabla {#creating-a-table}
|
||||
|
||||
``` sql
|
||||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
@ -61,7 +61,7 @@ Todos los parámetros excepto `columns` el mismo significado que en `MergeTree`.
|
||||
|
||||
</details>
|
||||
|
||||
## Ejemplo De Uso {#usage-example}
|
||||
## Ejemplo de uso {#usage-example}
|
||||
|
||||
Considere la siguiente tabla:
|
||||
|
||||
@ -94,13 +94,13 @@ SELECT key, sum(value) FROM summtt GROUP BY key
|
||||
└─────┴────────────┘
|
||||
```
|
||||
|
||||
## Procesamiento De Datos {#data-processing}
|
||||
## Procesamiento de datos {#data-processing}
|
||||
|
||||
Cuando los datos se insertan en una tabla, se guardan tal cual. Clickhouse fusiona las partes insertadas de datos periódicamente y esto es cuando las filas con la misma clave principal se suman y se reemplazan con una para cada parte resultante de los datos.
|
||||
Cuando los datos se insertan en una tabla, se guardan tal cual. ClickHouse combina las partes insertadas de los datos periódicamente y esto es cuando las filas con la misma clave principal se suman y se reemplazan con una para cada parte resultante de los datos.
|
||||
|
||||
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`) una función agregada [resumir()](../../../sql-reference/aggregate-functions/reference.md#agg_function-sum) y `GROUP BY` cláusula se debe utilizar en una consulta como se describe en el ejemplo anterior.
|
||||
|
||||
### Reglas Comunes Para La Suma {#common-rules-for-summation}
|
||||
### Reglas comunes para la suma {#common-rules-for-summation}
|
||||
|
||||
Se resumen los valores de las columnas con el tipo de datos numérico. El conjunto de columnas está definido por el parámetro `columns`.
|
||||
|
||||
@ -110,11 +110,11 @@ Si la columna no está en la clave principal y no se resume, se selecciona un va
|
||||
|
||||
Los valores no se resumen para las columnas de la clave principal.
|
||||
|
||||
### La Suma En Las Columnas De función Agregada {#the-summation-in-the-aggregatefunction-columns}
|
||||
### La suma en las columnas de función agregada {#the-summation-in-the-aggregatefunction-columns}
|
||||
|
||||
Para columnas de [Tipo AggregateFunction](../../../sql-reference/data-types/aggregatefunction.md) ClickHouse se comporta como [AgregaciónMergeTree](aggregatingmergetree.md) agregación del motor según la función.
|
||||
|
||||
### Estructuras Anidadas {#nested-structures}
|
||||
### Estructuras anidadas {#nested-structures}
|
||||
|
||||
La tabla puede tener estructuras de datos anidadas que se procesan de una manera especial.
|
||||
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 37
|
||||
toc_title: VersionedCollapsingMergeTree
|
||||
---
|
||||
|
||||
# Versionedcollapsingmergetree {#versionedcollapsingmergetree}
|
||||
# VersionedCollapsingMergeTree {#versionedcollapsingmergetree}
|
||||
|
||||
Este motor:
|
||||
|
||||
@ -16,7 +16,7 @@ Vea la sección [Derrumbar](#table_engines_versionedcollapsingmergetree) para m
|
||||
|
||||
El motor hereda de [Método de codificación de datos:](mergetree.md#table_engines-mergetree) y agrega la lógica para colapsar filas al algoritmo para fusionar partes de datos. `VersionedCollapsingMergeTree` tiene el mismo propósito que [ColapsarMergeTree](collapsingmergetree.md) pero usa un algoritmo de colapso diferente que permite insertar los datos en cualquier orden con múltiples hilos. En particular, el `Version` columna ayuda a contraer las filas correctamente, incluso si se insertan en el orden incorrecto. En contraste, `CollapsingMergeTree` sólo permite la inserción estrictamente consecutiva.
|
||||
|
||||
## Creación De Una Tabla {#creating-a-table}
|
||||
## Creación de una tabla {#creating-a-table}
|
||||
|
||||
``` sql
|
||||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
@ -64,7 +64,7 @@ CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
|
||||
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
|
||||
...
|
||||
) ENGINE [=] VersionedCollapsingMergeTree(date-column [, sampling_expression], (primary, key), index_granularity, sign, version)
|
||||
) ENGINE [=] VersionedCollapsingMergeTree(date-column [, samp#table_engines_versionedcollapsingmergetreeling_expression], (primary, key), index_granularity, sign, version)
|
||||
```
|
||||
|
||||
Todos los parámetros excepto `sign` y `version` el mismo significado que en `MergeTree`.
|
||||
@ -133,7 +133,7 @@ Cuando ClickHouse combina partes de datos, elimina cada par de filas que tienen
|
||||
|
||||
Cuando ClickHouse inserta datos, ordena filas por la clave principal. Si el `Version` la columna no está en la clave principal, ClickHouse la agrega a la clave principal implícitamente como el último campo y la usa para ordenar.
|
||||
|
||||
## Selección De Datos {#selecting-data}
|
||||
## Selección de datos {#selecting-data}
|
||||
|
||||
ClickHouse no garantiza que todas las filas con la misma clave principal estén en la misma parte de datos resultante o incluso en el mismo servidor físico. Esto es cierto tanto para escribir los datos como para la posterior fusión de las partes de datos. Además, ClickHouse procesa `SELECT` consultas con múltiples subprocesos, y no puede predecir el orden de las filas en el resultado. Esto significa que la agregación es necesaria si hay una necesidad de obtener completamente “collapsed” datos de un `VersionedCollapsingMergeTree` tabla.
|
||||
|
||||
@ -143,7 +143,7 @@ Los agregados `count`, `sum` y `avg` se puede calcular de esta manera. El agrega
|
||||
|
||||
Si necesita extraer los datos con “collapsing” pero sin agregación (por ejemplo, para verificar si hay filas presentes cuyos valores más nuevos coinciden con ciertas condiciones), puede usar el `FINAL` modificador para el `FROM` clausula. Este enfoque es ineficiente y no debe usarse con tablas grandes.
|
||||
|
||||
## Ejemplo De Uso {#example-of-use}
|
||||
## Ejemplo de uso {#example-of-use}
|
||||
|
||||
Datos de ejemplo:
|
||||
|
||||
@ -198,7 +198,7 @@ SELECT * FROM UAct
|
||||
└─────────────────────┴───────────┴──────────┴──────┴─────────┘
|
||||
```
|
||||
|
||||
¿qué vemos aquí y dónde están las partes colapsadas?
|
||||
¿Qué vemos aquí y dónde están las partes colapsadas?
|
||||
Creamos dos partes de datos usando dos `INSERT` consulta. El `SELECT` la consulta se realizó en dos subprocesos, y el resultado es un orden aleatorio de filas.
|
||||
No se produjo el colapso porque las partes de datos aún no se han fusionado. ClickHouse fusiona partes de datos en un punto desconocido en el tiempo que no podemos predecir.
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 45
|
||||
toc_title: "B\xFAfer"
|
||||
---
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 35
|
||||
toc_title: Diccionario
|
||||
---
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 33
|
||||
toc_title: Distribuido
|
||||
---
|
||||
@ -39,7 +39,7 @@ Por ejemplo, para una consulta con GROUP BY, los datos se agregarán en servidor
|
||||
|
||||
En lugar del nombre de la base de datos, puede usar una expresión constante que devuelva una cadena. Por ejemplo: currentDatabase().
|
||||
|
||||
logs – The cluster name in the server’s config file.
|
||||
logs – The cluster name in the server's config file.
|
||||
|
||||
Los clústeres se establecen así:
|
||||
|
||||
@ -84,7 +84,7 @@ Las réplicas están duplicando servidores (para leer todos los datos, puede acc
|
||||
Los nombres de clúster no deben contener puntos.
|
||||
|
||||
Los parámetros `host`, `port`, y opcionalmente `user`, `password`, `secure`, `compression` se especifican para cada servidor:
|
||||
- `host` – The address of the remote server. You can use either the domain or the IPv4 or IPv6 address. If you specify the domain, the server makes a DNS request when it starts, and the result is stored as long as the server is running. If the DNS request fails, the server doesn’t start. If you change the DNS record, restart the server.
|
||||
- `host` – The address of the remote server. You can use either the domain or the IPv4 or IPv6 address. If you specify the domain, the server makes a DNS request when it starts, and the result is stored as long as the server is running. If the DNS request fails, the server doesn't start. If you change the DNS record, restart the server.
|
||||
- `port` – The TCP port for messenger activity (‘tcp\_port’ en la configuración, generalmente establecido en 9000). No lo confundas con http\_port.
|
||||
- `user` – Name of the user for connecting to a remote server. Default value: default. This user must have access to connect to the specified server. Access is configured in the users.xml file. For more information, see the section [Derechos de acceso](../../../operations/access-rights.md).
|
||||
- `password` – The password for connecting to a remote server (not masked). Default value: empty string.
|
||||
@ -103,7 +103,7 @@ Para ver los clústeres, utilice el ‘system.clusters’ tabla.
|
||||
|
||||
El motor distribuido permite trabajar con un clúster como un servidor local. Sin embargo, el clúster es inextensible: debe escribir su configuración en el archivo de configuración del servidor (mejor aún, para todos los servidores del clúster).
|
||||
|
||||
The Distributed engine requires writing clusters to the config file. Clusters from the config file are updated on the fly, without restarting the server. If you need to send a query to an unknown set of shards and replicas each time, you don’t need to create a Distributed table – use the ‘remote’ función de tabla en su lugar. Vea la sección [Funciones de tabla](../../../sql-reference/table-functions/index.md).
|
||||
The Distributed engine requires writing clusters to the config file. Clusters from the config file are updated on the fly, without restarting the server. If you need to send a query to an unknown set of shards and replicas each time, you don't need to create a Distributed table – use the ‘remote’ función de tabla en su lugar. Vea la sección [Funciones de tabla](../../../sql-reference/table-functions/index.md).
|
||||
|
||||
Hay dos métodos para escribir datos en un clúster:
|
||||
|
||||
@ -125,7 +125,7 @@ La expresión de fragmentación puede ser cualquier expresión de constantes y c
|
||||
|
||||
Un simple recordatorio de la división es una solución limitada para sharding y no siempre es apropiado. Funciona para volúmenes medianos y grandes de datos (docenas de servidores), pero no para volúmenes muy grandes de datos (cientos de servidores o más). En este último caso, use el esquema de fragmentación requerido por el área asunto, en lugar de usar entradas en Tablas distribuidas.
|
||||
|
||||
SELECT queries are sent to all the shards and work regardless of how data is distributed across the shards (they can be distributed completely randomly). When you add a new shard, you don’t have to transfer the old data to it. You can write new data with a heavier weight – the data will be distributed slightly unevenly, but queries will work correctly and efficiently.
|
||||
SELECT queries are sent to all the shards and work regardless of how data is distributed across the shards (they can be distributed completely randomly). When you add a new shard, you don't have to transfer the old data to it. You can write new data with a heavier weight – the data will be distributed slightly unevenly, but queries will work correctly and efficiently.
|
||||
|
||||
Debería preocuparse por el esquema de fragmentación en los siguientes casos:
|
||||
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 34
|
||||
toc_title: Datos externos
|
||||
---
|
||||
|
||||
# Datos Externos Para El Procesamiento De Consultas {#external-data-for-query-processing}
|
||||
# Datos externos para el procesamiento de consultas {#external-data-for-query-processing}
|
||||
|
||||
ClickHouse permite enviar a un servidor los datos necesarios para procesar una consulta, junto con una consulta SELECT. Estos datos se colocan en una tabla temporal (consulte la sección “Temporary tables”) y se puede utilizar en la consulta (por ejemplo, en operadores IN).
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 37
|
||||
toc_title: File
|
||||
---
|
||||
@ -16,7 +16,7 @@ Ejemplos de uso:
|
||||
- Convertir datos de un formato a otro.
|
||||
- Actualización de datos en ClickHouse mediante la edición de un archivo en un disco.
|
||||
|
||||
## Uso En El Servidor De Clickhouse {#usage-in-clickhouse-server}
|
||||
## Uso en el servidor ClickHouse {#usage-in-clickhouse-server}
|
||||
|
||||
``` sql
|
||||
File(Format)
|
||||
@ -67,16 +67,16 @@ SELECT * FROM file_engine_table
|
||||
└──────┴───────┘
|
||||
```
|
||||
|
||||
## Uso En Clickhouse-local {#usage-in-clickhouse-local}
|
||||
## Uso en ClickHouse-local {#usage-in-clickhouse-local}
|
||||
|
||||
En [Sistema abierto.](../../../operations/utilities/clickhouse-local.md) El motor de archivos acepta la ruta del archivo además de `Format`. Los flujos de entrada / salida predeterminados se pueden especificar utilizando nombres numéricos o legibles por humanos como `0` o `stdin`, `1` o `stdout`.
|
||||
En [Sistema abierto.](../../../operations/utilities/clickhouse-local.md#clickhouse-local) El motor de archivos acepta la ruta del archivo además de `Format`. Los flujos de entrada / salida predeterminados se pueden especificar utilizando nombres numéricos o legibles por humanos como `0` o `stdin`, `1` o `stdout`.
|
||||
**Ejemplo:**
|
||||
|
||||
``` bash
|
||||
$ echo -e "1,2\n3,4" | clickhouse-local -q "CREATE TABLE table (a Int64, b Int64) ENGINE = File(CSV, stdin); SELECT a, b FROM table; DROP TABLE table"
|
||||
```
|
||||
|
||||
## Detalles De La implementación {#details-of-implementation}
|
||||
## Detalles de la implementación {#details-of-implementation}
|
||||
|
||||
- Multiple `SELECT` las consultas se pueden realizar simultáneamente, pero `INSERT` las consultas se esperarán entre sí.
|
||||
- Apoyado la creación de nuevos archivos por `INSERT` consulta.
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 46
|
||||
toc_title: GenerateRandom
|
||||
---
|
||||
@ -14,7 +14,7 @@ Ejemplos de uso:
|
||||
- Se usa en la prueba para poblar una tabla grande reproducible.
|
||||
- Generar entrada aleatoria para pruebas de fuzzing.
|
||||
|
||||
## Uso En El Servidor De Clickhouse {#usage-in-clickhouse-server}
|
||||
## Uso en el servidor ClickHouse {#usage-in-clickhouse-server}
|
||||
|
||||
``` sql
|
||||
ENGINE = GenerateRandom(random_seed, max_string_length, max_array_length)
|
||||
@ -49,7 +49,7 @@ SELECT * FROM generate_engine_table LIMIT 3
|
||||
└──────┴────────────┘
|
||||
```
|
||||
|
||||
## Detalles De La implementación {#details-of-implementation}
|
||||
## Detalles de la implementación {#details-of-implementation}
|
||||
|
||||
- No soportado:
|
||||
- `ALTER`
|
||||
|
@ -1,7 +1,7 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
toc_folder_title: Special
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_folder_title: Especial
|
||||
toc_priority: 31
|
||||
---
|
||||
|
||||
|
@ -1,15 +1,15 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 40
|
||||
toc_title: Unir
|
||||
---
|
||||
|
||||
# Unir {#join}
|
||||
|
||||
Estructura de datos preparada para usar en [JOIN](../../../sql-reference/statements/select.md#select-join) operación.
|
||||
Estructura de datos preparada para usar en [JOIN](../../../sql-reference/statements/select/join.md#select-join) operación.
|
||||
|
||||
## Creación De Una Tabla {#creating-a-table}
|
||||
## Creación de una tabla {#creating-a-table}
|
||||
|
||||
``` sql
|
||||
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
|
||||
@ -23,13 +23,13 @@ Vea la descripción detallada del [CREATE TABLE](../../../sql-reference/statemen
|
||||
|
||||
**Parámetros del motor**
|
||||
|
||||
- `join_strictness` – [ÚNETE a la rigurosidad](../../../sql-reference/statements/select.md#select-join-strictness).
|
||||
- `join_type` – [Tipo de unión](../../../sql-reference/statements/select.md#select-join-types).
|
||||
- `join_strictness` – [ÚNETE a la rigurosidad](../../../sql-reference/statements/select/join.md#select-join-strictness).
|
||||
- `join_type` – [Tipo de unión](../../../sql-reference/statements/select/join.md#select-join-types).
|
||||
- `k1[, k2, ...]` – Key columns from the `USING` cláusula que el `JOIN` operación se hace con.
|
||||
|
||||
Entrar `join_strictness` y `join_type` parámetros sin comillas, por ejemplo, `Join(ANY, LEFT, col1)`. Deben coincidir con el `JOIN` operación para la que se utilizará la tabla. Si los parámetros no coinciden, ClickHouse no lanza una excepción y puede devolver datos incorrectos.
|
||||
|
||||
## Uso De La Tabla {#table-usage}
|
||||
## Uso de la tabla {#table-usage}
|
||||
|
||||
### Ejemplo {#example}
|
||||
|
||||
@ -79,7 +79,7 @@ SELECT joinGet('id_val_join', 'val', toUInt32(1))
|
||||
└────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Selección e inserción De Datos {#selecting-and-inserting-data}
|
||||
### Selección e inserción de datos {#selecting-and-inserting-data}
|
||||
|
||||
Usted puede utilizar `INSERT` consultas para agregar datos al `Join`-mesas de motor. Si la tabla se creó con el `ANY` estricta, se ignoran los datos de las claves duplicadas. Con el `ALL` estricta, se agregan todas las filas.
|
||||
|
||||
@ -88,7 +88,7 @@ No se puede realizar una `SELECT` consulta directamente desde la tabla. En su lu
|
||||
- Coloque la mesa hacia el lado derecho en un `JOIN` clausula.
|
||||
- Llame al [joinGet](../../../sql-reference/functions/other-functions.md#joinget) función, que le permite extraer datos de la tabla de la misma manera que de un diccionario.
|
||||
|
||||
### Limitaciones y Ajustes {#join-limitations-and-settings}
|
||||
### Limitaciones y ajustes {#join-limitations-and-settings}
|
||||
|
||||
Al crear una tabla, se aplican los siguientes valores:
|
||||
|
||||
@ -100,9 +100,9 @@ Al crear una tabla, se aplican los siguientes valores:
|
||||
|
||||
El `Join`-las tablas del motor no se pueden usar en `GLOBAL JOIN` operación.
|
||||
|
||||
El `Join`-motor permite el uso [Sistema abierto.](../../../operations/settings/settings.md#join_use_nulls) ajuste en el `CREATE TABLE` instrucción. Y [SELECT](../../../sql-reference/statements/select.md) consulta permite el uso `join_use_nulls` demasiado. Si tienes diferentes `join_use_nulls` configuración, puede obtener un error al unirse a la tabla. Depende del tipo de JOIN. Cuando se utiliza [joinGet](../../../sql-reference/functions/other-functions.md#joinget) función, usted tiene que utilizar el mismo `join_use_nulls` ajuste en `CRATE TABLE` y `SELECT` instrucción.
|
||||
El `Join`-motor permite el uso [Sistema abierto.](../../../operations/settings/settings.md#join_use_nulls) ajuste en el `CREATE TABLE` instrucción. Y [SELECT](../../../sql-reference/statements/select/index.md) consulta permite el uso `join_use_nulls` demasiado. Si tienes diferentes `join_use_nulls` configuración, puede obtener un error al unirse a la tabla. Depende del tipo de JOIN. Cuando se utiliza [joinGet](../../../sql-reference/functions/other-functions.md#joinget) función, usted tiene que utilizar el mismo `join_use_nulls` ajuste en `CRATE TABLE` y `SELECT` instrucción.
|
||||
|
||||
## Almacenamiento De Datos {#data-storage}
|
||||
## Almacenamiento de datos {#data-storage}
|
||||
|
||||
`Join` datos de la tabla siempre se encuentra en la memoria RAM. Al insertar filas en una tabla, ClickHouse escribe bloques de datos en el directorio del disco para que puedan restaurarse cuando se reinicie el servidor.
|
||||
|
||||
|
@ -1,11 +1,11 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 43
|
||||
toc_title: "M\xE9todo de codificaci\xF3n de datos:"
|
||||
---
|
||||
|
||||
# Método De codificación De Datos: {#materializedview}
|
||||
# Método de codificación de datos: {#materializedview}
|
||||
|
||||
Se utiliza para implementar vistas materializadas (para obtener más información, consulte [CREATE TABLE](../../../sql-reference/statements/create.md)). Para almacenar datos, utiliza un motor diferente que se especificó al crear la vista. Al leer desde una tabla, solo usa este motor.
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 44
|
||||
toc_title: Memoria
|
||||
---
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 36
|
||||
toc_title: Fusionar
|
||||
---
|
||||
|
@ -1,6 +1,6 @@
|
||||
---
|
||||
machine_translated: true
|
||||
machine_translated_rev: 3e185d24c9fe772c7cf03d5475247fb829a21dfa
|
||||
machine_translated_rev: 72537a2d527c63c07aa5d2361a8829f3895cf2bd
|
||||
toc_priority: 38
|
||||
toc_title: Nulo
|
||||
---
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user