diff options
| author | Ivan Blinkov <ivan@ydb.tech> | 2023-11-15 05:16:05 +0300 |
|---|---|---|
| committer | blinkov <blinkov@yandex-team.com> | 2023-11-15 05:28:13 +0300 |
| commit | 9c491f76b3f0f697b0ca527dabd623106f3c8373 (patch) | |
| tree | 9abab5728d6f6a146f341946702e1bfb3cc6b05f | |
| parent | fb1cf50f7001c043a554a06dcdf326794c7581c6 (diff) | |
| download | ydb-9c491f76b3f0f697b0ca527dabd623106f3c8373.tar.gz | |
drop unused files
[docs] drop unused files
Pull Request resolved: https://github.com/ydb-platform/ydb/pull/418
87 files changed, 155 insertions, 1763 deletions
@@ -71,7 +71,6 @@ For development purposes we test that YDB could be built and run under latest ve 1. Run available [example application](https://ydb.tech/en/docs/reference/ydb-sdk/example/go/). 1. Develop an application using [YDB SDK](https://ydb.tech/en/docs/reference/ydb-sdk/). - ## How to Build from Source Code * Build server (ydbd) and client (ydb) binaries [from source code](BUILD.md). diff --git a/ydb/docs/en/core/administration/quickstart.md b/ydb/docs/en/core/administration/quickstart.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/ydb/docs/en/core/administration/quickstart.md +++ /dev/null diff --git a/ydb/docs/en/core/changelog.md b/ydb/docs/en/core/changelog.md deleted file mode 100644 index 1a3452d037..0000000000 --- a/ydb/docs/en/core/changelog.md +++ /dev/null @@ -1,91 +0,0 @@ -# Changelog - -## 07/03/2023 {#07-03-2023} - -### {{ ydb-short-name }} 22.5 {#ydb-22-5} - -To update to version **22.5**, select the [Downloads](downloads/index.md) section. - -**What's new:** - -* Added [changefeed configuration parameters](yql/reference/syntax/alter_table#changefeed-options) to transfer additional information about changes to a topic. -* You can now [rename tables](concepts/datamodel/table.md#rename) that have TTL enabled. -* You can now [manage the record retention period](concepts/cdc#retention-period). - -**Bug fixes and improvements:** - -* Fixed an error inserting 0 rows with a BulkUpsert. -* Fixed an error importing Date/DateTime columns from CSV. -* Fixed an error importing CSV data with line breaks. -* Fixed an error importing CSV data with NULL values. -* Improved Query Processing performance (by replacing WorkerActor with SessionActor). -* DataShard compaction now starts immediately after a split or merge. - -## 12/10/2022 {#12-10-2022} - -**What's new in version 22.4** - -To update to version **22.4**, select the [Downloads](downloads/index.md) section. - -* {{ ydb-short-name }} Topics and Change Data Capture (CDC): - * Introduced the new Topic API. {{ ydb-short-name }} [Topic](concepts/topic.md) is an entity for storing unstructured messages and delivering them to various subscribers. - * Added support for the Topic API to the [{{ ydb-short-name }} CLI](reference/ydb-cli/topic-overview.md) and [SDK](reference/ydb-sdk/topic.md). The Topic API provides methods for message streaming writes and reads as well as topic management. - * Added the ability to [capture table updates](concepts/cdc.md) and send change messages to a topic. - -* SDK: - * Added the ability to handle topics in the {{ ydb-short-name }} SDK. - * Added official support for the database/sql driver for working with {{ ydb-short-name }} in Golang. - -* Embedded UI: - * The CDC change stream and the secondary indexes are now displayed in the database schema hierarchy as separate objects. - * Improved the visualization of query explain plan graphics. - * Problem storage groups have more visibility now. - * Various improvements based on UX research. - -* Query Processing: - * Added Query Processor 2.0, a new subsystem to execute OLTP queries with significant improvements compared to the previous version. - * Improved write performance by up to 60%, and by up to 10% for reads. - * Added the ability to include a NOT NULL restriction for YDB primary keys when creating tables. - * Added support for renaming a secondary index online without shutting the service down. - * Improved the query explain view that now also includes fields for the physical operators. - -* Core: - * For read only transactions, added consistent snapshot support that does not conflict with write transactions. - * Added BulkUpsert support for tables with asynchronous secondary indexes. - * Added TTL support for tables with asynchronous secondary indexes. - * Added compression support for data export to S3. - * Added an audit log for DDL statements. - * Added support for authentication with static credentials. - * Added system tables for query performance troubleshooting. - -## 20/09/2022 {#22-09-2022} - -{{ ydb-short-name }} CLI 2.0.0: - -* Added the ability to work with topics: - * `ydb topic create`: Create a topic. - * `ydb topic alter`: Update a topic. - * `ydb topic write`: Write data to a topic. - * `ydb topic read`: Read data from a topic. - * `ydb topic drop`: Delete a topic. - -* Added a new type of load testing: - * `ydb workload kv init`: Create a table for kv load testing. - * `ydb workload kv run`: Apply one of three types of load: run multiple `UPSERT` sessions, run multiple `INSERT` sessions, or run multiple sessions of GET requests by primary key. - * `ydb workload kv clean`: Delete a test table. - -* Added the ability to disable current active profile (see the `ydb config profile deactivate` command). -* Added the ability to delete a profile non-interactively with no commit (see the `--force` parameter under the `ydb config profile remove` command). -* Added CDC support for the `ydb scheme describe` command. -* Added the ability to view the current DB status (see the `ydb monitoring healthcheck` command). -* Added the ability to view authentication information (token) to be sent with DB queries under the current authentication settings (see the `ydb auth get-token` command). -* Added the ability for the `ydb import` command to read data from stdin. -* Added the ability to import data in JSON format from a file or stdin (see the `ydb import file json` command). -* Improved command processing. Improved the accuracy of user input parsing and validation. - -## 25/06/2022 {#25-06-2022} - -{{ ydb-short-name }} CLI 1.9.1: - -* Added the ability to compress data when exporting it to S3-compatible storage (see the `--compression` parameter of the [ydb export s3](reference/ydb-cli/export_import/s3_export.md) command). -* Added the ability to manage new {{ ydb-short-name }} CLI version availability auto checks (see the `--disable-checks` and `--enable-checks` parameters of the [ydb version](reference/ydb-cli/version.md) command). diff --git a/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/01_intro.md b/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/01_intro.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/01_intro.md +++ /dev/null diff --git a/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md b/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/02_sls_pars.md +++ /dev/null diff --git a/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md b/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/ydb/docs/en/core/concepts/_includes/serverless_and_dedicated/10_arch_diff.md +++ /dev/null diff --git a/ydb/docs/en/core/concepts/datamodel.md b/ydb/docs/en/core/concepts/datamodel.md deleted file mode 100644 index 36d7fde82c..0000000000 --- a/ydb/docs/en/core/concepts/datamodel.md +++ /dev/null @@ -1,9 +0,0 @@ -{% include [Introduction](_includes/datamodel/intro.md) %} - -{% include [Table](_includes/datamodel/table.md) %} - -{% include [Folder](_includes/datamodel/dir.md) %} - -{% include [Persistent Queue](_includes/datamodel/pq.md) %} - -{% include [Block Device](_includes/datamodel/blockdevice.md) %} diff --git a/ydb/docs/en/core/concepts/datamodel/_includes/blockdevice.md b/ydb/docs/en/core/concepts/datamodel/_includes/blockdevice.md deleted file mode 100644 index a573ef7a81..0000000000 --- a/ydb/docs/en/core/concepts/datamodel/_includes/blockdevice.md +++ /dev/null @@ -1,3 +0,0 @@ -# Network Block Store Volume - -Implementing a [network block device](https://en.wikipedia.org/wiki/Network_block_device) built on {{ ydb-short-name }} is an example of how {{ ydb-short-name }} can be used as a platform for creating a wide range of data storage and processing systems. Network block devices implement an interface for a local block device, as well as ensure fault-tolerance (through redundancy) and good scalability in terms of volume size and the number of input/output operations per unit of time. The downside of a network block device is that any input/output operation on such device requires network interaction, which might increase the latency of the network device compared to the local device. You can deploy a common file system on a network block device and/or run an application directly on the block device, such as a database management system. diff --git a/ydb/docs/en/core/concepts/datamodel/blockdevice.md b/ydb/docs/en/core/concepts/datamodel/blockdevice.md deleted file mode 100644 index 8940c9e97d..0000000000 --- a/ydb/docs/en/core/concepts/datamodel/blockdevice.md +++ /dev/null @@ -1 +0,0 @@ -{% include [blockdevice.md](_includes/blockdevice.md) %}
\ No newline at end of file diff --git a/ydb/docs/en/core/concepts/serverless_and_dedicated.md b/ydb/docs/en/core/concepts/serverless_and_dedicated.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/ydb/docs/en/core/concepts/serverless_and_dedicated.md +++ /dev/null diff --git a/ydb/docs/en/core/deploy/manual/concepts.md b/ydb/docs/en/core/deploy/manual/concepts.md deleted file mode 100644 index e26c6e4df8..0000000000 --- a/ydb/docs/en/core/deploy/manual/concepts.md +++ /dev/null @@ -1,9 +0,0 @@ -## Manual deployment - -### Terms and definitions - -YDB consists of two components: - -* Static nodes that provide the data storage layer. -* Dynamic nodes that implement data access and processing. Each database requires one or more separate dynamic nodes. - diff --git a/ydb/docs/en/core/deploy/system-requirements.md b/ydb/docs/en/core/deploy/system-requirements.md deleted file mode 100644 index 1415c520a1..0000000000 --- a/ydb/docs/en/core/deploy/system-requirements.md +++ /dev/null @@ -1,45 +0,0 @@ -# System requirements and recommendations - -This section provides recommendations for deploying {{ ydb-short-name }}. - -## Hardware configuration {#hardware} - -* **CPU** - - {{ ydb-short-name }} server can be run only on x86-64 CPU with AVX2 instructions support (Intel Haswell (4th generation) and later, AMD EPYC and later). - ARM processors are not supported now. - -* **Memory** - - It is recommended to use error-correcting code (ECC) memory for data consistency. - -* **Storage** - - {{ ydb-short-name }} server can be run on servers with any storage types (HDD/SSD/NVMe/RAM). It is recommended to use SSD/NVMe drives for better performance. - - {% include [_includes/storage-device-requirements.md](../_includes/storage-device-requirements.md) %} - - {{ ydb-short-name }} does not use any filesystems to store data and works directly with disk. Don't create or mount filesystems on disks which are used in {{ ydb-short-name }} . Also it is not recommended to share block devices with other processes as this can lead to a significant performance degradation. - - -## Software configuration {#software} - -{{ ydb-short-name }} server can be run on OS Linux with kernel 4.4 or later. MacOS and Windows are not supported now. - -## Topology {#topology} - -When planning a deployment, it's important to choose the right [Blob Storage configuration](./configuration/config.md#domains-blob) based on the required fault tolerance: - - * Mode None - This mode requires 1 server without fault tolerance. It is recommended only for functional testing. - - * block-4-2: This mode requires at least 8 servers in one datacenter. To ensure maximum fault tolerance, servers must be located in 8 independent racks. In this mode cluster remains operational if 1 rack fails completely and 1 node in another rack fails. - - * Mode mirror-3dc - This mode requires at least 9 servers. To ensure maximum fault tolerance, servers must be located in three independent data centers and different server racks in each of them. In this mode cluster remains operational if 1 datacenter fails completely and 1 node fails in another datacenter. - - * Mode mirror-3dc - This mode requires at least 9 servers. To ensure maximum fault tolerance, servers must be located in three independent data centers and different server racks in each of them. In this mode cluster remains operational if 1 datacenter fails completely and 1 node fails in another datacenter. - - * Mode mirror-3dc-3-nodes - The simple variant of mirror-3dc mode. This mode requires at least 3 servers with 3 disks in each. To ensure maximum fault tolerance, each server must be located in an independent datacenter. In this mode cluster keeps running if no more than 1 node fails. It is recommended only for testing. - -The failure of the node means that the server is out of service completely or one of the disks in it fails. - -Read more about storage groups in [Terms and definitions](../concepts/databases.md#storage-groups). diff --git a/ydb/docs/en/core/faq/serverless.md b/ydb/docs/en/core/faq/serverless.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/ydb/docs/en/core/faq/serverless.md +++ /dev/null diff --git a/ydb/docs/en/core/getting_started/_includes/cli.md b/ydb/docs/en/core/getting_started/_includes/cli.md deleted file mode 100644 index 4d5bcf2ec7..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/cli.md +++ /dev/null @@ -1,111 +0,0 @@ -# {{ ydb-short-name }} CLI - Getting started - -## Prerequisites {#prerequisites} - -To run commands via the CLI, you will need database connection settings you can retrieve when [creating](../create_db.md) a connection: - -* [Endpoint](../../concepts/connect.md#endpoint) -* [Database name](../../concepts/connect.md#database) - -You may also need a token or login/password if the database requires [authentication](../auth.md). To execute the below scenario, you need to select an option for saving them in an environment variable. - -## Installing the CLI {#install} - -Install the {{ ydb-short-name }} CLI as described in [Installing the {{ ydb-short-name }} CLI](../../reference/ydb-cli/install.md). - -To check that the YDB CLI has been installed, run it with `--help`: - -```bash -{{ ydb-cli }} --help -``` - -The response includes a welcome message, a brief description of the syntax, and a list of available commands: - -```text -YDB client - -Usage: ydb [options...] <subcommand> - -Subcommands: -ydb -├─ config Manage YDB CLI configuration -│ └─ profile Manage configuration profiles -│ ├─ activate Activate specified configuration profile (aliases: set) -... -``` - -All the features of the {{ ydb-short-name }} built-in help are described in [Built-in help](../../reference/ydb-cli/commands/service.md#help) of the {{ ydb-short-name }} CLI reference. - -## Check the connection {#ping} {#scheme-ls} - -To check the connection, use the [object list get](../../reference/ydb-cli/commands/scheme-ls.md) command in the `scheme ls` database: - -```bash -{{ ydb-cli }} -e <endpoint> -d <database> scheme ls -``` - -If the command is successful, a list of objects in the database is shown in response. If you haven't created anything in the database yet, the output will only contain the `.sys` and `.sys_health` system directories with [diagnostic representations of YDB](../../troubleshooting/system_views_db.md). - -{% include [cli/ls_examples.md](cli/ls_examples.md) %} - -## Creating a connection profile {#profile} - -To avoid specifying connection parameters every time you call the YDB CLI, use the [profile](../../reference/ydb-cli/profile/index.md). Creating the profile described below will also let you copy subsequent commands through the clipboard without editing them regardless of which database you're using to complete the "Getting started" scenario. - -[Create](../../reference/ydb-cli/profile/create.md) the `quickstart` profile using the following command: - -```bash -{{ ydb-cli }} config profile create quickstart -e <endpoint> -d <database> -``` - -Use the values checked at the [previous step](#ping) as parameters. For example, to create a connection profile to a local YDB database created using the self-hosted deployment scenario [in Docker](../self_hosted/ydb_docker.md), run the following command: - -```bash -{{ ydb-cli }} config profile create quickstart -e grpc://localhost:2136 -d /local -``` - -Check that the profile is OK with the `scheme ls` command: - -```bash -{{ ydb-cli }} -p quickstart scheme ls -``` - -## Executing an YQL script {#yql} - -The {{ ydb-short-name }} CLI `yql` command lets you execute any command (both DDL and DML) in [YQL](../../yql/reference/index.md), a SQL dialect supported by {{ ydb-short-name }}: - -```bash -{{ ydb-cli }} -p <profile_name> yql -s <yql_request> -``` - -e.g.: - -* Creating a table: - - ```bash - {{ ydb-cli }} -p quickstart yql -s "create table t1( id uint64, primary key(id))" - ``` - -* Adding a record: - - ```bash - {{ ydb-cli }} -p quickstart yql -s "insert into t1(id) values (1)" - ``` - -* Data selects: - - ```bash - {{ ydb-cli }} -p quickstart yql -s "select * from t1" - ``` - -If you get the `Profile quickstart does not exist` error, this means that you failed to create a profile during the [previous step](#profile). - -## Specialized CLI commands {#ydb-api} - -Executing commands via `ydb yql` is a nice and easy way to get started. However, the YQL interface supports a part of the function set provided by the YDB API, and has to sacrifice efficiency for universality. - -The YDB CLI supports individual commands with complete sets of options for any existing YDB API. For a full list of commands, see the [YDB CLI reference](../../reference/ydb-cli/index.md). - -## Learn more about YDB {#next} - -Proceed to the [YQL - Getting started](../yql.md) article to learn more about YDB. diff --git a/ydb/docs/en/core/getting_started/_includes/cli/ls_example_generic.md b/ydb/docs/en/core/getting_started/_includes/cli/ls_example_generic.md deleted file mode 100644 index 2a385d5489..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/cli/ls_example_generic.md +++ /dev/null @@ -1,19 +0,0 @@ -For example, if: - -* Endpoint: `grpc://ydb.example.com:2136`. -* Database name: `/john/db1`. -* The database doesn't require authentication, or the proper environment variable has been set, as described [here](../../auth.md). -* A database has just been created and contains no objects. - -the command will look like this: - -```bash -{{ ydb-cli }} -e grpc://ydb.example.com:2136 -d /john/db1 scheme ls -``` - -The command execution result on the created empty database: - -```text -.sys_health .sys -``` - diff --git a/ydb/docs/en/core/getting_started/_includes/cli/ls_example_local.md b/ydb/docs/en/core/getting_started/_includes/cli/ls_example_local.md deleted file mode 100644 index bde2582ec5..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/cli/ls_example_local.md +++ /dev/null @@ -1,8 +0,0 @@ -### Connecting to a local database - -If you deployed a local YDB using a scenario for self-hosted deployment [in Docker](../../self_hosted/ydb_docker.md) with the suggested configuration, you can check a YDB connection using the command: - -```bash -{{ ydb-cli }} -e grpc://localhost:2136 -d /local scheme ls -``` - diff --git a/ydb/docs/en/core/getting_started/_includes/cli/ls_example_overlay.md b/ydb/docs/en/core/getting_started/_includes/cli/ls_example_overlay.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/cli/ls_example_overlay.md +++ /dev/null diff --git a/ydb/docs/en/core/getting_started/_includes/cli/ls_examples.md b/ydb/docs/en/core/getting_started/_includes/cli/ls_examples.md deleted file mode 100644 index 6ce3f0ea16..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/cli/ls_examples.md +++ /dev/null @@ -1,6 +0,0 @@ -{% include [ls_example_generic.md](ls_example_generic.md) %} - -{% include [ls_example_overlay.md](ls_example_overlay.md) %} - -{% include [ls_example_local.md](ls_example_local.md) %} - diff --git a/ydb/docs/en/core/getting_started/_includes/create_db.md b/ydb/docs/en/core/getting_started/_includes/create_db.md deleted file mode 100644 index de1f523844..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/create_db.md +++ /dev/null @@ -1,17 +0,0 @@ -# Creating a database: Getting started - -Detailed information about databases can be found in the article [Terms and definitions - Database](../../concepts/databases.md#database) in the "Concepts" section. - -{% include [create_db_overlay.md](create_db_overlay.md) %} - -## Simple self-hosted deployment {#self-hosted} - -One of the following methods can be used to deploy a local single-node cluster of {{ ydb-short-name }} running a single database: - -{% include [simple_options](../self_hosted/_includes/simple_options.md) %} - -Documentation on the deployment of mupltiple nodes clusters running number of databases is given in the [Cluster management](../../deploy/index.md) section. - -## Next step {#next} - -After creating your database, go to [Authentication - Getting started](../auth.md). diff --git a/ydb/docs/en/core/getting_started/_includes/index.md b/ydb/docs/en/core/getting_started/_includes/index.md deleted file mode 100644 index 077c56ab67..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/index.md +++ /dev/null @@ -1,13 +0,0 @@ -{% include [intro.md](index/intro.md) %} - -{% include [create_db.md](index/create_db.md) %} - -{% include [network_access.md](index/network.md) %} - -{% include [auth.md](index/auth.md) %} - -{% include [cli.md](index/cli.md) %} - -{% include [yql.md](index/yql.md) %} - -{% include [sdk.md](index/sdk.md) %} diff --git a/ydb/docs/en/core/getting_started/_includes/index/auth.md b/ydb/docs/en/core/getting_started/_includes/index/auth.md deleted file mode 100644 index 37886a7ad5..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/index/auth.md +++ /dev/null @@ -1,2 +0,0 @@ -* [Authentication](../../auth.md): Learn what you need to access the database. - diff --git a/ydb/docs/en/core/getting_started/_includes/index/cli.md b/ydb/docs/en/core/getting_started/_includes/index/cli.md deleted file mode 100644 index fd6d6bc205..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/index/cli.md +++ /dev/null @@ -1,2 +0,0 @@ -* [Using the command line interface (CLI)](../../cli.md): Install the {{ ydb-short-name }} CLI, connect to the DB, and view the usage examples. - diff --git a/ydb/docs/en/core/getting_started/_includes/index/create_db.md b/ydb/docs/en/core/getting_started/_includes/index/create_db.md deleted file mode 100644 index 1b57999899..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/index/create_db.md +++ /dev/null @@ -1,2 +0,0 @@ -* [Creating a database](../../create_db.md): Create your own {{ ydb-short-name }} database. - diff --git a/ydb/docs/en/core/getting_started/_includes/index/intro.md b/ydb/docs/en/core/getting_started/_includes/index/intro.md deleted file mode 100644 index 5526958d49..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/index/intro.md +++ /dev/null @@ -1,6 +0,0 @@ -# Getting started with {{ ydb-short-name }} - -The articles in this section will tell you how to quickly get started with {{ ydb-short-name }}. - -Each article provides one or more simple scenarios of doing an action, and additionally includes a link to other documents describing all the available {{ ydb-short-name }} features. - diff --git a/ydb/docs/en/core/getting_started/_includes/index/network.md b/ydb/docs/en/core/getting_started/_includes/index/network.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/index/network.md +++ /dev/null diff --git a/ydb/docs/en/core/getting_started/_includes/index/sdk.md b/ydb/docs/en/core/getting_started/_includes/index/sdk.md deleted file mode 100644 index 8f551767ed..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/index/sdk.md +++ /dev/null @@ -1,2 +0,0 @@ -* [{{ ydb-short-name }} SDK](../../sdk.md): Get familiar with {{ ydb-short-name }} SDKs for different programming languages and run simple DB queries from sample apps. - diff --git a/ydb/docs/en/core/getting_started/_includes/index/toc_network.yaml b/ydb/docs/en/core/getting_started/_includes/index/toc_network.yaml deleted file mode 100644 index 1dce705aca..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/index/toc_network.yaml +++ /dev/null @@ -1,4 +0,0 @@ -# To be supplied in overlay if needed -items: -- name: Dummy - hidden: true diff --git a/ydb/docs/en/core/getting_started/_includes/index/yql.md b/ydb/docs/en/core/getting_started/_includes/index/yql.md deleted file mode 100644 index 3e6c2991a8..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/index/yql.md +++ /dev/null @@ -1,2 +0,0 @@ -* [YQL](../../yql.md): Get familiar with YQL, the primary query language for {{ ydb-short-name }} and a SQL dialect. - diff --git a/ydb/docs/en/core/getting_started/_includes/sdk.md b/ydb/docs/en/core/getting_started/_includes/sdk.md deleted file mode 100644 index 9ae21daeba..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/sdk.md +++ /dev/null @@ -1,15 +0,0 @@ -# {{ ydb-short-name }} SDK - Getting started - -{{ ydb-short-name }} SDKs are sets of software components to support {{ ydb-short-name }} databases for apps written in different programming languages. - -Follow these steps to launch a simple app using {{ ydb-short-name }}: - -1. [Install the {{ ydb-short-name }} SDK](../../reference/ydb-sdk/install.md) for the appropriate programming language. - -1. Download and run a sample test app using the SDK for the installed programming language and study its code: - * [Python](../../reference/ydb-sdk/example/python/index.md) - * [Go](../../reference/ydb-sdk/example/go/index.md) - * [Java](../../reference/ydb-sdk/example/java/index.md) - -For more information about the {{ ydb-short-name }} SDK, see [Working with the {{ ydb-short-name }} SDK](../../reference/ydb-sdk/index.md). - diff --git a/ydb/docs/en/core/getting_started/_includes/useful_links.md b/ydb/docs/en/core/getting_started/_includes/useful_links.md deleted file mode 100644 index c32f99efb5..0000000000 --- a/ydb/docs/en/core/getting_started/_includes/useful_links.md +++ /dev/null @@ -1,12 +0,0 @@ -# Useful links - -{% if oss %} - -* [{{ ydb-short-name }} OpenSource](https://ydb.tech) - -{% endif %} - -* [{{ yandex-cloud }} management console](https://console.cloud.yandex.com) - -* [GitHub account ydb-platform](https://github.com/ydb-platform) - diff --git a/ydb/docs/en/core/getting_started/auth.md b/ydb/docs/en/core/getting_started/auth.md deleted file mode 100644 index e7f2395443..0000000000 --- a/ydb/docs/en/core/getting_started/auth.md +++ /dev/null @@ -1,2 +0,0 @@ - -{% include [auth.md](_includes/auth.md) %} diff --git a/ydb/docs/en/core/getting_started/cli.md b/ydb/docs/en/core/getting_started/cli.md deleted file mode 100644 index d737e7a176..0000000000 --- a/ydb/docs/en/core/getting_started/cli.md +++ /dev/null @@ -1 +0,0 @@ -{% include [cli.md](_includes/cli.md) %} diff --git a/ydb/docs/en/core/getting_started/create_db.md b/ydb/docs/en/core/getting_started/create_db.md deleted file mode 100644 index 51d7c75381..0000000000 --- a/ydb/docs/en/core/getting_started/create_db.md +++ /dev/null @@ -1,2 +0,0 @@ - -{% include [create_db.md](_includes/create_db.md) %} diff --git a/ydb/docs/en/core/getting_started/sdk.md b/ydb/docs/en/core/getting_started/sdk.md deleted file mode 100644 index 18bd227b1a..0000000000 --- a/ydb/docs/en/core/getting_started/sdk.md +++ /dev/null @@ -1 +0,0 @@ -{% include [sdk.md](_includes/sdk.md) %} diff --git a/ydb/docs/en/core/getting_started/useful_links.md b/ydb/docs/en/core/getting_started/useful_links.md deleted file mode 100644 index ad6685f23b..0000000000 --- a/ydb/docs/en/core/getting_started/useful_links.md +++ /dev/null @@ -1,2 +0,0 @@ - -{% include [useful_links.md](_includes/useful_links.md) %} diff --git a/ydb/docs/en/core/getting_started/ydb_docker.md b/ydb/docs/en/core/getting_started/ydb_docker.md deleted file mode 100644 index 04578fb40a..0000000000 --- a/ydb/docs/en/core/getting_started/ydb_docker.md +++ /dev/null @@ -1 +0,0 @@ -{% include [self_hosted/ydb_docker.md](self_hosted/_includes/ydb_docker.md) %} diff --git a/ydb/docs/en/core/getting_started/ydb_local.md b/ydb/docs/en/core/getting_started/ydb_local.md deleted file mode 100644 index 3c18eb0f39..0000000000 --- a/ydb/docs/en/core/getting_started/ydb_local.md +++ /dev/null @@ -1 +0,0 @@ -{% include [self_hosted/ydb_local.md](self_hosted/_includes/ydb_local.md) %} diff --git a/ydb/docs/en/core/maintenance/_includes/index.md b/ydb/docs/en/core/maintenance/_includes/index.md deleted file mode 100644 index 402705b008..0000000000 --- a/ydb/docs/en/core/maintenance/_includes/index.md +++ /dev/null @@ -1,14 +0,0 @@ -# YDB maintenance - -This section contains articles on YDB database and cluster maintenance. When using a cloud database, only articles on DB maintenance are relevant, since the maintenance of a cluster under these databases is carried out by the cloud provider team. - -## Database maintenance - -- [Backup and recovery](../backup_and_recovery.md) -- [Diagnostics](../../troubleshooting/index.md) - -## Cluster maintenance - -- [Embedded UI](../embedded_monitoring/overview.md) -- [Cluster disk subsystem](../manual/index.md) - diff --git a/ydb/docs/en/core/maintenance/index.md b/ydb/docs/en/core/maintenance/index.md deleted file mode 100644 index eb2590567d..0000000000 --- a/ydb/docs/en/core/maintenance/index.md +++ /dev/null @@ -1 +0,0 @@ -{% include [_includes/index.md](_includes/index.md) %}
\ No newline at end of file diff --git a/ydb/docs/en/core/reference/ydb-cli/commands/_includes/query.md b/ydb/docs/en/core/reference/ydb-cli/commands/_includes/query.md deleted file mode 100644 index c7e3fe0caa..0000000000 --- a/ydb/docs/en/core/reference/ydb-cli/commands/_includes/query.md +++ /dev/null @@ -1,31 +0,0 @@ -# Making a DB query - -Run the data query: - -```bash -{{ ydb-cli }} table query execute \ - --query "SELECT season_id, episode_id, title \ - FROM episodes \ - WHERE series_id = 1 AND season_id > 1 \ - ORDER BY season_id, episode_id \ - LIMIT 3" -``` - -Where: - -* `--query`: Query text. - -Result: - -```text -┌───────────┬────────────┬──────────────────────────────┐ -| season_id | episode_id | title | -├───────────┼────────────┼──────────────────────────────┤ -| 2 | 1 | "The Work Outing" | -├───────────┼────────────┼──────────────────────────────┤ -| 2 | 2 | "Return of the Golden Child" | -├───────────┼────────────┼──────────────────────────────┤ -| 2 | 3 | "Moss and the German" | -└───────────┴────────────┴──────────────────────────────┘ -``` - diff --git a/ydb/docs/en/core/reference/ydb-cli/commands/index.md b/ydb/docs/en/core/reference/ydb-cli/commands/index.md deleted file mode 100644 index 12643df073..0000000000 --- a/ydb/docs/en/core/reference/ydb-cli/commands/index.md +++ /dev/null @@ -1 +0,0 @@ -{% include [index.md](_includes/index.md) %} diff --git a/ydb/docs/en/core/reference/ydb-cli/commands/query.md b/ydb/docs/en/core/reference/ydb-cli/commands/query.md deleted file mode 100644 index a8e11b77ba..0000000000 --- a/ydb/docs/en/core/reference/ydb-cli/commands/query.md +++ /dev/null @@ -1 +0,0 @@ -{% include [query.md](_includes/query.md) %} diff --git a/ydb/docs/en/core/reference/ydb-cli/commands/scheme-mkdir.md b/ydb/docs/en/core/reference/ydb-cli/commands/scheme-mkdir.md deleted file mode 100644 index 180e27a7ca..0000000000 --- a/ydb/docs/en/core/reference/ydb-cli/commands/scheme-mkdir.md +++ /dev/null @@ -1,2 +0,0 @@ -This page has been deleted, the content has been moved to a [new section](dir.md). - diff --git a/ydb/docs/en/core/reference/ydb-cli/commands/tools/copy.md b/ydb/docs/en/core/reference/ydb-cli/commands/tools/copy.md deleted file mode 100644 index db7461732f..0000000000 --- a/ydb/docs/en/core/reference/ydb-cli/commands/tools/copy.md +++ /dev/null @@ -1 +0,0 @@ -{% include [copy.md](../../_includes/commands/tools/copy.md) %} diff --git a/ydb/docs/en/core/reference/ydb-cli/topic.md b/ydb/docs/en/core/reference/ydb-cli/topic.md deleted file mode 100644 index 8988225ef9..0000000000 --- a/ydb/docs/en/core/reference/ydb-cli/topic.md +++ /dev/null @@ -1,234 +0,0 @@ -# Working with topics - -You can use the `topic` subcommand to create, update, or delete a [topic](../../concepts/topic.md) as well as to create or delete a [consumer](../../concepts/topic.md#consumer). - -The examples use the `db1` profile. To learn more, see [{#T}](../../getting_started/cli.md#profile). - -## Creating a topic {#topic-create} - -You can use the `topic create` subcommand to create a new topic. - -General format of the command: - -```bash -{{ ydb-cli }} [global options...] topic create [options...] <topic-path> -``` - -* `global options`: [Global parameters](commands/global-options.md). -* `options`: [Parameters of the subcommand](#options). -* `topic-path`: Topic path. - -View the description of the create topic command: - -```bash -{{ ydb-cli }} topic create --help -``` - -### Parameters of the subcommand {#topic-create-options} - -| Name | Description | ----|--- -| `--partitions-count VAL` | The number of topic [partitions](../../concepts/topic.md#partitioning).<br>The default value is `1`. | -| `--retention-period-hours VAL` | Data retention time in a topic, set in hours.<br>The default value is `18`. | -| `--supported-codecs STRING` | Supported data compression methods.<br>The default value is `raw,zstd,gzip,lzop`.<br>Possible values:<ul><li>`RAW`: Without compression.</li><li>`ZSTD`: [zstd](https://ru.wikipedia.org/wiki/Zstandard) compression.</li><li>`GZIP`: [gzip](https://ru.wikipedia.org/wiki/Gzip) compression.</li><li>`LZOP`: [lzop](https://ru.wikipedia.org/wiki/Lzop) compression.</li></ul> | - -### Examples {#topic-create-examples} - -Create a topic with 2 partitions, `RAW` and `GZIP` compression methods, message retention time of 2 hours, and the `my-topic` path: - -```bash -{{ ydb-cli }} -p db1 topic create \ - --partitions-count 2 \ - --supported-codecs raw,gzip \ - --retention-period-hours 2 \ - my-topic -``` - -View parameters of the created topic: - -```bash -{{ ydb-cli }} -p db1 scheme describe my-topic -``` - -Result: - -```text -RetentionPeriod: 2 hours -PartitionsCount: 2 -SupportedCodecs: RAW, GZIP -``` - -## Updating a topic {#topic-alter} - -You can use the `topic alter` subcommand to update a [previously created](#topic-create) topic. - -General format of the command: - -```bash -{{ ydb-cli }} [global options...] topic alter [options...] <topic-path> -``` - -* `global options`: [Global parameters](commands/global-options.md). -* `options`: [Parameters of the subcommand](#options). -* `topic-path`: Topic path. - -View the description of the update topic command: - -```bash -{{ ydb-cli }} topic alter --help -``` - -### Parameters of the subcommand {#topic-alter-options} - -| Name | Description | ----|--- -| `--partitions-count VAL` | The number of topic [partitions](../../concepts/topic.md#partitioning).<br>The default value is `1`. | -| `--retention-period-hours VAL` | Data retention time in a topic, set in hours.<br>The default value is `18`. | -| `--supported-codecs STRING` | Supported data compression methods.<br>The default value is `raw,zstd,gzip,lzop`.<br>Possible values:<ul><li>`RAW`: Without compression.</li><li>`ZSTD`: [zstd](https://ru.wikipedia.org/wiki/Zstandard) compression.</li><li>`GZIP`: [gzip](https://ru.wikipedia.org/wiki/Gzip) compression.</li><li>`LZOP`: [lzop](https://ru.wikipedia.org/wiki/Lzop) compression.</li></ul> | - -### Examples {#topic-alter-examples} - -Add a partition and the `lzop` compression method to the [previously created](#topic-create) topic: - -```bash -{{ ydb-cli }} -p db1 topic alter \ - --partitions-count 3 \ - --supported-codecs raw,gzip,lzop \ - my-topic -``` - -Make sure that the topic parameters have been updated: - -```bash -{{ ydb-cli }} -p db1 scheme describe my-topic -``` - -Result: - -```text -RetentionPeriod: 2 hours -PartitionsCount: 3 -SupportedCodecs: RAW, GZIP, LZOP -``` - -## Deleting a topic {#topic-drop} - -You can use the `topic drop` subcommand to delete a [previously created](#topic-create) topic. - -General format of the command: - -```bash -{{ ydb-cli }} [global options...] topic drop <topic-path> -``` - -* `global options`: [Global parameters](commands/global-options.md). -* `topic-path`: Topic path. - -View the description of the delete topic command: - -```bash -{{ ydb-cli }} topic drop --help -``` - -### Examples {#topic-drop-examples} - -Delete the [previously created](#topic-create) topic: - -```bash -{{ ydb-cli }} -p db1 topic drop my-topic -``` - -## Creating a consumer for a topic {#consumer-add} - -You can use the `topic consumer add` subcommand to create a consumer for a [previously created](#topic-create) topic. - -General format of the command: - -```bash -{{ ydb-cli }} [global options...] topic consumer add [options...] <topic-path> -``` - -* `global options`: [Global parameters](commands/global-options.md). -* `options`: [Parameters of the subcommand](#options). -* `topic-path`: Topic path. - -View the description of the add consumer command: - -```bash -{{ ydb-cli }} topic consumer add --help -``` - -### Parameters of the subcommand {#consumer-add-options} - -| Name | Description | ----|--- -| `--consumer VAL` | Name of the consumer to be created. | -| `--starting-message-timestamp VAL` | Time in [UNIX timestamp](https://en.wikipedia.org/wiki/Unix_time) format. Consumption starts as soon as the first [message](../../concepts/topic.md#message) is received after the specified time. If the time is not specified, consumption will start from the oldest message in the topic. | - -### Examples {#consumer-add-examples} - -Create a consumer with the `my-consumer` name for the [previously created](#topic-create) `my-topic` topic. Consumption will start as soon as the first message is received after August 15, 2022 13:00:00 GMT: - -```bash -{{ ydb-cli }} -p db1 topic consumer add \ - --consumer my-consumer \ - --starting-message-timestamp 1660568400 \ - my-topic -``` - -Make sure the consumer was created: - -```bash -{{ ydb-cli }} -p db1 scheme describe my-topic -``` - -Result: - -```text -RetentionPeriod: 2 hours -PartitionsCount: 2 -SupportedCodecs: RAW, GZIP - -Consumers: -┌──────────────┬─────────────────┬───────────────────────────────┬───────────┐ -| ConsumerName | SupportedCodecs | ReadFrom | Important | -├──────────────┼─────────────────┼───────────────────────────────┼───────────┤ -| my-consumer | RAW, GZIP | Mon, 15 Aug 2022 16:00:00 MSK | 0 | -└──────────────┴─────────────────┴───────────────────────────────┴───────────┘ -``` - -## Deleting a consumer {#consumer-drop} - -You can use the `topic consumer drop` subcommand to delete a [previously created](#consumer-add) consumer. - -General format of the command: - -```bash -{{ ydb-cli }} [global options...] topic consumer drop [options...] <topic-path> -``` - -* `global options`: [Global parameters](commands/global-options.md). -* `options`: [Parameters of the subcommand](#options). -* `topic-path`: Topic path. - -View the description of the delete consumer command: - -```bash -{{ ydb-cli }} topic consumer drop --help -``` - -### Parameters of the subcommand {#consumer-drop-options} - -| Name | Description | ----|--- -| `--consumer VAL` | Name of the consumer to be deleted. | - -### Examples {#consumer-drop-examples} - -Delete the [previously created](#consumer-add) consumer with the `my-consumer` name for the `my-topic` topic: - -```bash -{{ ydb-cli }} -p db1 topic consumer drop \ - --consumer my-consumer \ - my-topic -``` diff --git a/ydb/docs/en/core/reference/ydb-sdk/topic/topic.md b/ydb/docs/en/core/reference/ydb-sdk/topic/topic.md deleted file mode 100644 index a50bd6d862..0000000000 --- a/ydb/docs/en/core/reference/ydb-sdk/topic/topic.md +++ /dev/null @@ -1,299 +0,0 @@ -# Working with topics -## Concepts -### Message -The minimum atomic unit of user information. Consists of a message body, properties, and write session attributes. - -### Message body -An arbitrary set of bytes that YDB doesn't interpret in any way. - -### Message properties -Typed message fields received beyond the main message body and having a predefined meaning. - -#### codec -Message encoding method. Usually the used compression algorithm is specified. SDK will use the respective message decompression algorithm before passing it to the client code. - -#### created_at -Message creation time, set by the producer and passed to consumers as is, without verifying it on the server side. - -#### message_group_id -Set by the producer optionally, used for message partitioning. - -#### offset -Message sequence number within a partition, assigned by the server when saving the message. The offset of the first message in a partition is equal to 0, then it increases. Some offset values may be skipped. - -#### uncompressed_size -Decompressed message size, set by the producer and passed to consumers as is, without verifying it on the server side. - -#### seq_no -Message sequence number within a single ProducerID. Set by the message author before sending it to the server. -Sequence numbers must be set within ProducerIDs in ascending order. - -#### producer_id -ID set by the producer. For each producer_id within a partition, the seq_no ascending order is guaranteed. - -#### written_at -Time when a message is written on the server. Set by the server while saving the message. - -#### write_session_meta -An array of string key/value attributes set by the producer when starting a write session. Session attributes will be the same for all messages written within a single session. - -### Message commits -Committing the fact of message processing by a consumer. Indicates that the consumer has handled the message and no longer needs it. Message commits are independent for different consumers. - -### Topic -A named set of messages. Messages are written and read using topics. - -### Partition -A topic scaling unit. Partitions within topics are numbered starting with 0. Messages are eventually saved to partitions. Within a partition, messages are ordered and numbered. - -### Consumer -A named entity that reads data from a topic. A consumer contains committed read positions that are saved on the server side. - -### Important consumer -A consumer flagged as "important". This flag indicates that a message won't be removed from a topic until an important consumer commits that it's handled, even if it's time to remove it based on the rotation rules. If it takes an important consumer too long to read a message, you can totally run out of disk space. - -## Guarantees -In general, at-least-once message delivery is guaranteed. - -### Message writes -1. After a write is committed on the server side, it's considered that a message is saved safely and will be delivered to consumers. -2. Messages with the same message_group_id get into the same partition. -3. If the message_group_id and partition are not set explicitly, messages with the same producer_id get into the same partition. -4. When writing messages to partitions, their order is maintained within a single producer_id. -5. If, when writing a message to a partition, its seq_no is less than or equal to the seq_no of a previously committed message for the same producer_id, this message is skipped and not written. - -### Message reads -1. From each partition, messages arrive in the offset ascending order. -2. From each partition, messages arrive with the seq_no ascending within the same producer_id. -3. Once the server acknowledges a message commit, it will no longer be sent to this consumer. - -## Working with topics from SDK -### Connecting to a topic -To read a message from a topic, connect to the TODO:LINK database and subscribe to the topic. - -{% list tabs %} - -- Go - - ```go - reader, err := db.Topic().StartReader("consumer", topicoptions.ReadTopic("asd")) - if err != nil { - return err - } - ``` - -{% endlist %} - -To read messages from multiple topics or set more specific read options, you can use advanced settings for creating a consumer. - -{% list tabs %} - -- Go - - ```go - reader, err := db.Topic().StartReader("consumer", []topicoptions.ReadSelector{ - { - Path: "test", - }, - { - Path: "test-2", - Partitions: []int64{1, 2, 3}, - ReadFrom: time.Date(2022, 7, 1, 10, 15, 0, 0, time.UTC), - }, - }, - ) - if err != nil { - return err - } - ``` - -{% endlist %} - - -### Message reads - -The order of messages is guaranteed by the server within a single partition. The same guarantees apply to the SDK: messages from the same partition will be ordered among each other. Messages from different partitions may arrive in an order that differs from that they were written to the server and that the server passed them to the client in. However, the initial guarantees for ordering messages within a partition are valid through the entire message delivery path: from saving it to the partition to passing it to the client code. - -Reading messages one by one: - -{% list tabs %} - -- Go - - ```go - func SimpleReadMessages(ctx context.Context, r *topicreader.Reader) error { - for { - mess, err := r.ReadMessage(ctx) - if err != nil { - return err - } - processMessage(mess) - } - } - ``` - -{% endlist %} - - -Under batch message processing, it's more convenient to receive them in batches to make sure that messages within a batch get into the same partition. - -{% list tabs %} - -- Go - - ```go - func ReadBatchesWithBatchCommit(ctx context.Context, r *topicreader.Reader) error { - for { - batch, err := r.ReadMessageBatch(ctx) - if err != nil { - return err - } - processBatch(batch) - } - } - ``` - -{% endlist %} - -### Message processing commits -The server can save the position of processed messages on its side if you send message processing commits to the server. This is an optional feature that often lets you simplify your code. - -You can commit processing messages one by one: - -{% list tabs %} - -- Go - - ```go - func SimpleReadMessages(ctx context.Context, r *topicreader.Reader) error { - for { - ... - r.Commit(mess.Context(), mess) - } - } - ``` - -{% endlist %} - -and in batch mode - -{% list tabs %} - -- Go - - ```go - func SimpleReadMessages(ctx context.Context, r *topicreader.Reader) error { - for { - ... - r.Commit(batch.Context(), batch) - } - } - ``` - -{% endlist %} - -### Working with messages without committing their processing -To read messages without saving their progress in a topic, you should save it on your side and handle service messages about starting partition reads to let the server know the point in time to continue message delivery from. Without handling messages this way, the server will send you all available messages every time. - -{% list tabs %} - -- Go - - ```go - func ReadWithExplicitPartitionStartStopHandlerAndOwnReadProgressStorage(ctx context.Context, db ydb.Connection) error { - readContext, stopReader := context.WithCancel(context.Background()) - defer stopReader() - - readStartPosition := func( - ctx context.Context, - req topicoptions.GetPartitionStartOffsetRequest, - ) (res topicoptions.GetPartitionStartOffsetResponse, err error) { - offset, err := readLastOffsetFromDB(ctx, req.Topic, req.PartitionID) - res.StartFrom(offset) - - // Reader will stop if return err != nil - return res, err - } - - r, err := db.Topic().StartReader("consumer", topicoptions.ReadTopic("asd"), - topicoptions.WithGetPartitionStartOffset(readStartPosition), - ) - if err != nil { - return err - } - - go func() { - <-readContext.Done() - _ = r.Close(ctx) - }() - - for { - batch, err := r.ReadMessageBatch(readContext) - if err != nil { - return err - } - - processBatch(batch) - _ = externalSystemCommit(batch.Context(), batch.Topic(), batch.PartitionID(), batch.EndOffset()) - } - } - ``` - -{% endlist %} - -### Selecting partitions -YDB uses server-side partition balancing across the clients connected, so the server may decide to stop sending messages to the client from some partitions. In this case, the client must terminate processing the messages it received. - -The server has two ways to block a partition: a soft one (by notifying the client in advance) and a hard one (by sending a message saying that the partition can no longer be used). - -The soft option means that the server has stopped delivering messages from this partition and will no longer send messages to it, but the client still has time to finish processing the messages received. - -Handling the soft partition blocking method -{% list tabs %} - -- Go - - In general, the SDK API doesn't send you an individual notification of softly blocking a partition. - The SDK processes a signal so that a user immediately gets the messages remaining in the buffer even if - the settings specify that a larger batch should be collected. - - ```go - r, _ := db.Topic().StartReader("consumer", nil, - topicoptions.WithBatchReadMinCount(1000), - ) - - for { - batch, _ := r.ReadMessageBatch(ctx) // <- if partition soft stop batch can be less, then 1000 - processBatch(batch) - _ = r.Commit(batch.Context(), batch) - } - - ``` -{% endlist %} - -The hard option means that the client has to stop processing the messages received, because all non-committed messages will be passed to a different reader. - -Handling the hard partition blocking method. -{% list tabs %} - -- Go - - Each message (and each batch in case of batch reads) has a message context. If a partition is no longer available, batches and messages - from this partition will have their context cancelled. - - ```go - ctx := batch.Context() // batch.Context() will cancel if partition revoke by server or connection broke - if len(batch.Messages) == 0 { - return - } - - buf := &bytes.Buffer{} - for _, mess := range batch.Messages { - buf.Reset() - _, _ = buf.ReadFrom(mess) - _, _ = io.Copy(buf, mess) - writeMessagesToDB(ctx, buf.Bytes()) - } - ``` - -{% endlist %} diff --git a/ydb/docs/en/core/troubleshooting/grafana_dashboards.md b/ydb/docs/en/core/troubleshooting/grafana_dashboards.md deleted file mode 100644 index 3c6a73ce5f..0000000000 --- a/ydb/docs/en/core/troubleshooting/grafana_dashboards.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -editable: false ---- -# Grafana dashboards - -{% include notitle [ydb_grafana_dashboards.md](_includes/grafana_dashboards.md) %} - diff --git a/ydb/docs/ru/core/administration/quickstart.md b/ydb/docs/ru/core/administration/quickstart.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/ydb/docs/ru/core/administration/quickstart.md +++ /dev/null diff --git a/ydb/docs/ru/core/administration/rolling-restart.md b/ydb/docs/ru/core/administration/rolling-restart.md deleted file mode 100644 index 2d8ccb342e..0000000000 --- a/ydb/docs/ru/core/administration/rolling-restart.md +++ /dev/null @@ -1,54 +0,0 @@ -# Роллинг рестарт - -Механизм роллинг рестарта используется для обновления версии {{ ydb-short-name }} и применения изменений в конфигурации. - -## Утилита ydb-rolling-restart {#description} - -Запуск роллинг рестарта производится утилитой ydb-rolling-restart. Контроль процесса перезагрузки со стороны перезагружаемого кластера {{ ydb-short-name }} позволяет избежать деградации. Утилита использует системный ssh-клиент для для подключения к узлам кластера и выполнения команды перезагрузки процессов {{ ydb-short-name }}. - -Пример запуска перезагрузки storage узлов: - -### Перезагрузка storage {#storage} - -Примеры перезагрузки storage узлов: - - ``` - ydb-rolling-restart --addr <node list> --service storage - ``` - -где `<node list>` - это список узлов кластера разделенных запятыми. - -### Перезагрузка динамических узлов {#dynnode} - -Примеры перезагрузки узлов базы данных: - - ``` - ydb-rolling-restart --addr <node list> --service dynnode --database <database name> - ``` - -где: - - `<node list>` - это список узлов кластера разделенных запятыми - - `<database name>` - имя рестартуемой базы данных - -### Выбор режим доступности при рестарте storage узлов {#availability-mode} - -Процесс рестарта storage узлов учитывает структуру и тип erasue blob storage групп кластера. Это позволяет перезагружать узлы в рамках модели отказа без фатальной деградации (недоступности). -С помощю опции ```--availability-mode <mode>``` возможно выбрать режим доступности. -где `<mode>` может принимать один из трех вариантов: - - `max` - разрешается рестарт узлов если он приведет к недоступность максимум одного диска из blob storage групп - - `keep` - разрешается рестарт узлов если он не приведет к недоступности blob storage групп - - `force` - рестарт с недоступностью blob storage групп - -{% note warning %} - -Использование режима ```--availability-mode force``` приведет к одновременной перезагрузке всех узлов. Используйте этот режим в случае крайней необходимости. - -{% endnote %} - - -### Параметры утилиты рестарта {#parameters} - -Есть возможность управлять запуском рестарта с помощю параметров: - - `--hosts <host list>` - перезагрузить узлы только на хостах из указанного списка - - `--exclude-hosts <host list>` - исключить из перезагрузки узлы на хостах из списка - - `--ssh-pool-size <number>` - лимит на число удаленных соединений с узлами кластера через ssh diff --git a/ydb/docs/ru/core/cluster/toc_i.yaml b/ydb/docs/ru/core/cluster/toc_i.yaml index b827e89c0e..826ec380d4 100644 --- a/ydb/docs/ru/core/cluster/toc_i.yaml +++ b/ydb/docs/ru/core/cluster/toc_i.yaml @@ -21,8 +21,6 @@ items: href: ../troubleshooting/monitoring.md - name: Обновление href: ../administration/upgrade.md -# - name: Роллинг рестарт -# href: ../administration/rolling-restart.md - name: Изменение конфигурации актор-системы href: ../maintenance/manual/change_actorsystem_configs.md - name: Управление конфигурацией кластера diff --git a/ydb/docs/ru/core/concepts/column-table.md b/ydb/docs/ru/core/concepts/column-table.md deleted file mode 100644 index 50b58e6b34..0000000000 --- a/ydb/docs/ru/core/concepts/column-table.md +++ /dev/null @@ -1,81 +0,0 @@ -# Колоночная таблица - -{% note warning %} - -Колоночные таблицы {{ ydb-short-name }} доступны в режиме Preview. - -{% endnote %} - -Колоночная таблица {{ ydb-short-name }} — это реляционная таблица, содержащая набор связанных данных, состоящий из строк и столбцов. В отличие от обычных, строковых, [таблиц {{ ydb-short-name }}](#table), предназначенных для [OLTP-нагрузки](https://ru.wikipedia.org/wiki/OLTP), колоночные таблицы оптимизированы для задач анализа данных, [OLAP-нагрузки](https://ru.wikipedia.org/wiki/OLAP). - -На данный момент основной сценарий использования колоночных таблиц — запись данных с возрастающим первичным ключом (например, время события), анализ этих данных и удаление устаревших данных по TTL. Оптимальным способом добавления данных в колоночные таблицы является пакетная запись, выполняемая блоками в единицы МБ. - -Вставка пакетов данных производится атомарно: данные будут записаны или во все партиции, или ни в одну. При чтении анализируются только полностью записанные в колоночные таблицы данные. - -В большинстве случаев работа с колоночными таблицами {{ ydb-short-name }} аналогична работе со строковыми. Имеются следующие отличия: - -* В качестве ключевых колонок можно использовать только NOT NULL колонки. -* Данные партицируются не по первичному ключу, а по Hash от колонок [партицирования](#olap-tables-partitioning). -* Поддерживается [ограниченный набор](#olap-data-types) типов данных. - -В настоящий момент не поддерживается: - -* Чтение с реплик. -* Вторичные индексы. -* Фильтры Блума. -* Change Data Capture. -* Переименование таблиц. -* Пользовательские атрибуты таблиц. -* Изменение списка колонок данных в колоночных таблицах. -* Добавление данных в колоночные таблицы с помощью SQL-оператора `INSERT`. -* Удаление данных из колоночных таблиц с помощью SQL-оператора `DELETE`. Фактически, удаление возможно только по истечению TTL времени хранения данных. - -## Поддерживаемые типы данных {#olap-data-types} - -Тип данных | Можно использовать<br>в колоночных таблицах | Можно использовать<br>в качестве первичного ключа ----|---|--- -`Bool` | ☓ | ☓ -`Date` | ✓ | ✓ -`Datetime` | ✓ | ✓ -`Decimal` | ☓ | ☓ -`Double` | ✓ | ☓ -`Float` | ✓ | ☓ -`Int16` | ✓ | ☓ -`Int32` | ✓ | ✓ -`Int64` | ✓ | ✓ -`Int8` | ✓ | ☓ -`Interval` | ☓ | ☓ -`JsonDocument` | ✓ | ☓ -`Json` | ✓ | ☓ -`String` | ✓ | ✓ -`Timestamp` | ✓ | ✓ -`Uint16` | ✓ | ✓ -`Uint32` | ✓ | ✓ -`Uint64` | ✓ | ✓ -`Uint8` | ✓ | ✓ -`Utf8` | ✓ | ✓ -`Uuid` | ☓ | ☓ -`Yson` | ✓ | ☓ - -Подробнее смотрите [{#T}](../yql/reference/types/index.md). - -## Партицирование {#olap-tables-partitioning} - -В отличие от строковых таблиц {{ ydb-short-name }}, колоночные таблицы партицируют данные не по первичным ключам, а по специально выделенным ключам — ключам партицирования. Ключи партицирования являются подмножеством первичных ключей таблицы. - -В отличие от партицирования данных в строковых таблицах {{ ydb-short-name }}, партицирование данных для колоночных таблиц выполняется не по значениям ключей, а по hash-значениям от ключей, что позволяет равномерно распределить данные во все существующие партиции. Такое партицирование позволяет избежать хотспотов при вставке и ускоряет аналитические запросы, обрабатывающие (считывающие) большие объемы данных. - -Выбор ключей партицирования существенно влияет на производительность колоночных таблиц. Подробнее смотрите [{#T}](../best_practices/pk-olap-scalability.md). - -Для управления партицированием данных используется дополнительный параметр `AUTO_PARTITIONING_MIN_PARTITIONS_COUNT`. Остальные параметры партицирования для колоночных таблиц игнорируются. - -`AUTO_PARTITIONING_MIN_PARTITIONS_COUNT` определяет минимальное физическое количество партиций для хранения данных. - -* Тип: `Uint64`. -* Значение по умолчанию: `64`. - -С учетом, что остальные параметры партицирования игнорируются, это же значение определяет и верхнее число партиций для партицирования. - -## См. также {#see-also} - -* [{#T}](../yql/reference/syntax/create_table.md#olap-tables) diff --git a/ydb/docs/ru/core/concepts/datamodel/_includes/blockdevice.md b/ydb/docs/ru/core/concepts/datamodel/_includes/blockdevice.md deleted file mode 100644 index 3cc226c9a1..0000000000 --- a/ydb/docs/ru/core/concepts/datamodel/_includes/blockdevice.md +++ /dev/null @@ -1,3 +0,0 @@ -# Том сетевого блочного устройства - -Одним из примеров применения {{ ydb-short-name }} в качестве платформы для создания широкого спектра систем хранения и обработки данных является реализация [сетевого блочного устройства](https://en.wikipedia.org/wiki/Network_block_device) на базе {{ ydb-short-name }}. Сетевые блочные устройства реализуют интерфейс локального блочного устройства, при этом являются отказоустойчивыми (за счет избыточности) и хорошо масштабируются как по размеру тома, так и по количеству операций ввода-вывода в единицу времени. К недостаткам сетевого блочного устройства можно отнести то, что любая операция ввода-вывода на таком устройстве требует сетевого взаимодействия, что может увеличить latency сетевого устройства по сравнению с локальным. На сетевом блочном устройстве можно развернуть обычную файловую систему и/или запустить приложение, напрямую работающее с блочным устройством, например СУБД. diff --git a/ydb/docs/ru/core/concepts/datamodel/blockdevice.md b/ydb/docs/ru/core/concepts/datamodel/blockdevice.md deleted file mode 100644 index 8940c9e97d..0000000000 --- a/ydb/docs/ru/core/concepts/datamodel/blockdevice.md +++ /dev/null @@ -1 +0,0 @@ -{% include [blockdevice.md](_includes/blockdevice.md) %}
\ No newline at end of file diff --git a/ydb/docs/ru/core/concepts/glossary.md b/ydb/docs/ru/core/concepts/glossary.md deleted file mode 100644 index 1a8ce0cb39..0000000000 --- a/ydb/docs/ru/core/concepts/glossary.md +++ /dev/null @@ -1,224 +0,0 @@ -# Глоссарий -### Внешние ссылки на основные понятия - -* [Strict Consistency – https://en.wikipedia.org/wiki/Consistency_model](https://en.wikipedia.org/wiki/Consistency_model) -* [Serializable isolation – https://en.wikipedia.org/wiki/Isolation_%28database_systems%29#Serializable](https://en.wikipedia.org/wiki/Isolation_%28database_systems%29#Serializable) -* [Actor model – https://en.wikipedia.org/wiki/Actor_model](https://en.wikipedia.org/wiki/Actor_model) -* [Replicated state machine – https://en.wikipedia.org/wiki/State_machine_replication](https://en.wikipedia.org/wiki/State_machine_replication) -* [Paxos - https://en.wikipedia.org/wiki/Paxos_(computer_science)](https://en.wikipedia.org/wiki/Paxos_(computer_science)) -* [Raft - https://en.wikipedia.org/wiki/Raft_(algorithm)](https://en.wikipedia.org/wiki/Raft_(algorithm)) - -### Actor Model -**Actor System** - реализация [Actor Model](https://en.wikipedia.org/wiki/Actor_model) в системе. - -**Actor (Актор)** - C++ класс реализующий абстракцию [Актора](https://en.wikipedia.org/wiki/Actor_model). - -**Actor Service (Акторный Сервис)** - актор, который имеет well-known имя, обычно запускается в единственном экземпляре на ноде. - -**ActorID** - уникальный идентификатор таблетки в кластере. - -**(Actor System) Interconnect** - сетевой программный слой а также внутренняя сеть кластера. Внутри системы акторы взаимодействуют друг с другом через Interconnect. - - - -### Tablet -**Tablet (Таблетка)** - так в системе называется абстракция, которая отвечает за относительно небольшой (до единиц гигабайт) сегмент пользовательских или системных данных. Например, пользовательская таблица представляет собой одну или несколько таблеток, каждая таблетка отвечает за непрерывный диапазон первичных ключей таблицы и данных им соответствующих. Таблетки могут отвечать за пользовательские метаданные, например, за список пользовательских таблиц, за системные метаданные и т.п. - -Таблетка представляет собой набор данных, за который отвечает эта таблетка, и конечный автомат, через который состояние таблетки (данные) меняется. Таблетка является отказоустойчивой сущностью -- данные таблетки хранятся в распределенном BlobStorage, который переживает отказ дисков и нод. Данные в таблетке меняются консистентным образом -- инфраструктура системы обеспечивает наличие не более одной сущности (лидера), через которую проводятся изменения данных таблетки. За обработку команд отвечает некоторый вышеуказанный конечный автомат. - -Таблетка решает ту же задачу, что алгоримы [Paxos](https://en.wikipedia.org/wiki/Paxos_(computer_science)) и [Raft ](https://en.wikipedia.org/wiki/Raft_(algorithm)) в ряде других систем, а именно задачу [распределенного консенсуса](https://en.wikipedia.org/wiki/Consensus_(computer_science)). С технической точки зрения реализацию таблетки проще всего описать как RSM (Replicated State Machine) over shared log - состояние таблетки полностью описывается упорядоченным логом команд, хранящимся в распределенном и отказоустойчивом хранилище. - -Во время выполнения конечный автомат таблетки обслуживают три актора: - -1. общетаблеточная часть обеспечивающая консистентность лога и восстановление при сбоях; -1. executor -- абстракция локальной базы, а именно структур данных и кода, которые обеспечивают работу с хранимыми таблеткой данными; -1. актор с пользовательским кодом, который реализует специфичную логику конкретного типа таблетки. - -Таблетка является базовым строительным блоком системы. Хранение всевозможных данных для всего спектра задач обычно реализуется через специальный тип таблетки. Обычно, в системе запущено множество (тысячи, десятки тысяч, а может быть, даже миллионы) таблеток, выполняющих различную функцию. Таблетки идентифицируются при помощи **TabeltID** -- 64-х битного числа, назначаемого при создании таблетки. - -Так как таблетка хранит свое состояние в BlobStorage, вышеуказанные акторы, через которые происходит работа с данными таблетки, могут быть запущены (технически) на любом узле кластера. Вышеуказанные акторы называют **Tablet Leader (Мастер таблетки)**. - -### Tablet Leader -**Tablet Leader (Лидер таблетки)** - текущий активный лидер таблетки, именно он принимает команды, упорядочивает их и подтверждает внешнему миру. В каждый момент времени существует не более одного лидера. - -### Tablet Candidate -**Tablet Candidate** - если таблетка осталась без лидера, то кандидат -- это один их участников выборов, желающий стать лидером. В случае успеха выборов кандидат становится лидером таблетки. - -### Tablet Follower -**Tablet Follower** или **Hot standby** - копия лидера, проигрывающая принятый лидером лог команд (с некоторым отставанием). Tаблетка может иметь 0 или более фолловеров. Фолловеры решают по большей степени две задачи: - -* в случае смерти лидера фолловеры являются предпочтительными кандидатами в лидера, т.к. могут перейти в лидера гораздо быстрее остальных кандидатов -- им потребуется проиграть меньше лога; -* фолловеры могут брать на себя некоторую нагрузку лидера на чтение (отвечая на запросы чтения с некоторым отставанием). - -### Tablet Generation -**Tablet Generation** - число, идентифицирующее реинкарнацию лидера таблетки. Меняется только при выборе нового лидера и всегда растет. - -### Tablet Local Database -**Tablet Local Database** или **локальная база** -- структуры данных и код, которые обеспечивают работу с хранимыми таблеткой данными. Очень грубо, состояние локальной базы представлено набором таблиц очень похожих на реляционные таблицы. Модификация состояния локальной базы производится локальными транзакциями таблетки, генерируемыми пользовательским актором таблетки. - -### Виды таблеток - -#### Scheme Shard -**Scheme Shard** - таблетка хранящая схему базы данных, а именно: - -* метаданные про пользовательские таблицы; -* метаданные про пользовательские топики и т.п. - -Существует такое понятие как **Root Scheme Shard (Рутовый Scheme Shard)**, который хранит информацию о созданных в кластере базах данных. - -#### KV Tablet -**KV Tablet** - таблетка реализующая простое отображение key->value, где key и value -- это строки. Также имеет ряд специфических возможностей (например, блокировки). - -#### PQ Tablet -**PQ Tablet** - таблетка реализующая понятие топика. Состоит из партиций, которые похожи на партиции [Apache Kafka](https://kafka.apache.org). Сокращение PQ -- от persistent queue. - -#### DataShard -**DataShard** - таблетка хранящая сегмент данных построчной пользовательской таблицы. Исходная построчная пользовательская таблица разбивается на сегменты по непрерывным диапазонам первичного ключа таблицы. За каждый такой диапазон называемый партицией отвечает таблетка DataShard. Таблетка DataShard хранит данные построчно, что эффективно для OLTP-нагрузки. - -#### Column Shard -**ColumnShard** - таблетка хранящая сегмент данных поколоночной пользовательской таблицы. - -#### TxAllocator -**TxAllocator** - системная таблетка, обеспечивающая выделение уникальных в рамках кластера идентификаторов транзакций. Обычно кластер имеет несколько таких таблеток, из которых TxProxy заранее выделяет и кеширует диапазоны для локальной выдачи внутри одного процесса. - -#### Coordinator -**Coordinator (Координатор)** - системная таблетка, обеспечивающая глобальную упорядоченность транзакций. Задача координатора назначить логическое время PlanStep для каждой транзакции, планируемой через этот координатор. Для каждой транзакции выбирается строго один координатор (выбирается хешированием для конкретного TxId). - -#### Mediator -**Mediator (Медиатор)** - системная таблетка, распространяющая запланированные Координатором транзакции на участников транзакций (обычно, DataShards). Медиаторы обеспечивают продвижение глобального времени. С каждым участником транзакций ассоциирован ровно один Медиатор. - -#### BlobStorage Controller -**BlobStorage Controller** - системная таблетка, которая хранит информацию о конфигурации BlobStorage. Запущена в единственном экземпляре на кластере. - -#### Hive -**Hive** - системная таблетка, позволяющая запускать и управлять другими таблетками. В системе есть ряд системных служебных таблеток, которые должны быть подняты для нормального функционирования системы. Такие таблетки поднимается при помощи **Bootstrapper**. Остальные таблетки создаются и поднимаются при помощи Hive. Например, если мы создаем (глобальную) таблицу в системе, для которой нужно создать и запустить несколько DataShards, то их созданием и запуском занимается Hive (по команде от SchemeShard). - -Hive позволяет минимизировать конфликты кандидатов в лидера таблетки при запуске. Он также занимается балансировкой нагрузки на кластер -- выбирает на какой ноде лучше запустить данную таблетку. При создании таблеток Hive взаимодействует с **BlobStorage Controller** для назначения **Blobstorage групп** каналам таблеток. Непосредственно запуск таблеток на нодах осуществляет через запущенный на каждой ноде сервис Local. - -### Infrastructure -#### Local -**Local** - акторный сервис, запущенный на каждой ноде. Непосредственно управляет таблетками на своей ноде, взаимодействует с Hive. Регистрируется в Hive и получает команды на запуск таблеток. - -#### Bootstrapper -**Bootstrapper** - базовый механизм запуска таблеток, применяется для служебных таблеток (например для Hive, BlobStorage Controller, корневого Scheme Shard). Остальные таблетки поднимаются таблеткой Hive. - -#### TabletPipe -**TabletPipe** - виртуальное соединение, которое можно установить с таблеткой. Включает в себя resolve лидера таблетки по TabletID. Рекомендуемый способ работы с таблеткой. Термин **установить pipe к таблетке** используется для описания процесса резолва (поиска) таблетки в кластере и установки виртуального канала общения с ней. - -#### StateStorage -**StateStorage** - распределенный сервис, который хранит информацию о таблетках, а именно: - -* информацию о текущем лидере таблетки или его отсутствии; -* информацию о фолловерах таблетки; -* информацию о поколении и шаге таблетки (generation:step). - -StateStorage используется как Name Service для резолва таблеток, т.е. получение ActorID по TabletID. Также StateStorage используется в процессе поднятия лидера таблетки. - -Информация в StateStorage волатильна, то есть теряется при выключении питания или рестарте процесса. Дело в том, что в State Storage (несмотря на название сервис не является хранилищем, данные на диске хранятся только в BlobStorage) содержит только информацию, которая не обязана быть durable и легко восстановима. Тем не менее, StateStorage хранит информацию на нескольких нодах для переживания сбоя конкретного узла, через этот сервис можно собирать кворум, что используется для поднятия лидера таблетки. Однако из-за своей природы сервис работает в режиме best effort, например гарантия отсутствия нескольких лидеров таблеток обеспечивается через протокол выбора лидера на BlobStorage, а не StateStorage. - -#### Compaction -**Compaction** - внутренний процесс перестройки данных хранимых в виде [LSM Tree](https://en.wikipedia.org/wiki/Log-structured_merge-tree). Данные в VDiskе и Локальной базе таблетки организованы в виде LSM Tree. Поэтому различают **VDisk compaction** и **Tablet compaction**. Процесс Compaction, обычно, достаточно ресурсоемкий, поэтому прилагаются усилия для того, чтобы минимизировать накладные расходы с ним связанные (не запускать множество параллельных процессов Compaction и т.п.). - -#### gRPC Proxy - **gRPC Proxy** - базовая клиентская прокси системы для пользовательских запросов. Клиентские запросы попадают в систему через [gRPC](https://grpc.io) Proxy, далее используются внутренние механизмы выполнения этих запросов и передачи сообщений (Interconnect). Предоставляет интерфейс в терминах request-response и bidirectional streaming. - -### Blob Storage -**Blob Storage или Distributed Storage** - это распределенное отказоустойчивое хранилище данных, обеспечивающее хранение бинарных записей, называемых LogoBlob, адресуемых по специального вида идентификаторам, называемым LogoBlobID. Фактически BlobStorage является Key-value-хранилищем, отображающим LogoBlobID в строку размером до 10MB. BlobStorage состоит из множества BS-групп (BlobStorage-групп), каждая из которых является независимым хранилищем. Наиболее близкой аналогией к BS-группе является распределенный RAID массив. - -Blob Storage хранит иммутабельные данные, то есть по конкретному ключу LogoBlobID хранится неизменяемый блоб. Интерфейс Blob Storage является весьма специфичным, он удобен только для использования таблетками, которые хранят в Blob Storage свои данные и лог изменений. Данные в Blob Storage удаляются при помощи специальных команд-барьеров. Из-за специфики своего интерфейса (нет мутаций) Blob Storage можно реализовать без имплементации **распределенного консенсуса**. Более того, Blob Storage является как раз тем кирпичиком, при помощи которого таблетка реализует распределенный консенсус. - -#### LogoBlob - **LogoBlob** - бинарные иммутабельные данные, снабженые уникальным идентификатором, имеющим специальную структуру, хранимые в Blob Storage. Размер блоба ограничен на уровне VDiskов и выше по стеку. На данный момент максимальный размер блоба, который готовы обрабатывать VDiskи составляет 10 Mb. - -#### LogoBlobID -**LogoBlobID** - идентификатор LogoBlob в Blob Storage. Имеет структуру вида ```[TabletID, Generation, Step, Channel, Cookie, BlobSize, PartId]```. Ключевыми элементами LogoblobID являются: - -* TabletID - идентификатор таблетки, которой принадлежит LogoBlob; -* Generation - поколение таблетки, в котором блоб был записан; -* Channel - канал таблетки, в который записан LogoBlob; -* Step - инкрементирующийся счетчик, обычно в рамках поколения таблетки. Можно говорить об отношении порядка между блобами одной таблетки в одном канале, следующие LogoblobID обычно больше предыдущих за счет увеличивающегося Step; -* Cookie - уникальный идентификатор блоба в рамках одного Step. Cookie обычно используется, когда необходимо написать несколько блобов в рамках одного Step; -* BlobSize - размер Logoblob; -* PartId - идентификатор куска блоба. Особенно важен когда исходный LogoBlob разбивается на куски при помощи erasure coding, и куски записываются на соответствующие VDisk-и BS-группы. - -#### Erasure Сoding -**Erasure coding** - способ кодирования данных, при котором данные дополняются избыточностью и разбиваются на несколько фрагментов, обеспечивающий возможность восстановления исходных данных при потере одного или нескольких фрагментов. Широко используется в системе в противовес популярной репликации с 3-мя репликами. Например, наиболее популярная схема 4+2 обеспечивает такую же надежность как 3 реплики, при этом избыточность составляет 1.5 против 3-х. - -#### PDisk -**PDisk (Physical Disk)**) - компонент управляющий физическим диском (устройством). Иначе говоря, PDisk - это подсистема, реализующая разновидность файловой системы поверх блочных устройств (или файлов имитирующих блочное устройство). PDisk обеспечивает контроль целостности данных (erasure кодирование групп секторов для восстановления данных при единичных bad-секторах, контроль целостности за счет checksums), прозрачное шифрование всех данных на диске, транзакционность операций с диском (подтверждение записи строго после fsync). - -PDisk содержит планировщик, который обеспечивает разделение полосы пропускания блочного устройства между несколькими клиентами (VDisk-ами). PDisk разделяет блочное устройство на чанки (размером порядка 128 мегабайт, допускаются чанки меньшего размера), каждым чанком единовременно может владеть не более 1 VDisk-а. Также PDisk поддерживает recovery-log, общий для служебных записей PDiskа и всех VDisk-ов. - -#### Yard - **Yard** - историческое название интерфейса к PDiskу. Позволяет VDisk-ам читать и писать данные в чанки и лог, резервировать чанки, удалять чанки, а также транзакционно получать и возвращать владение чанками. В некотором приближении можно считать Yard синонимом PDiskа. - -#### VDisk -**VDisk (Virtual Disk)** - компонент, который обеспечивает хранения логоблобов BS-группы на PDiskе. VDisk хранит свои данные на PDiskе. Одному VDiskу соответствует один PDisk, но к одному PDiskу, обычно, привязано несколько VDiskов. В отличие от PDiskа, который скрывает за собой чанки и лог, VDisk предоставляет интерфейс на уровне LogoBlob и LogoBlobID типа: записать LogoBlob, прочитать данные по LogoBlobID, удалить набор LogoBlob по специальной команде. VDisk входит в BS-группу. Сам VDisk локален, но множество VDiskов входящих в BS-группу обеспечивают надежное хранение данных. VDiskи в группе синхронизируют данные между собой и реплицируют данные в случае потери. Очень грубо, набор VDiskов в BS-группе образуют распределенный RAID. - -#### VDisk Skeleton -**Skeleton** - актор, обеспечивающий интерфейс к VDiskу (сам VDisk состоит из множества акторов). С некоторой погрешностью Skeleton можно считать синонимом VDiskа. - -**SkeletonFront** - актор, который является проксирующим актором к Skeleton, обеспечивает контроль потока сообщений, поступающих в Skeleton. - -#### BlobStorage Group -**BlobStorage Group** -- группа VDisk-ов на разных машинах, предназначенная для отказоустойчивого хранения данных (LogoBlob). Очень грубо - распределенный RAID. - - BS-группы бывают: - -* Статическими. Сконфигурированная при помощи конфигурационного файла группа во время первоначального разворачивания кластера. Группа предназначена строго для хранения данных системных таблеток (BlobStorage Controller, Hive и так далее). Эта группа существует на протяжении всего времени жизни кластера. Изменение конфигурации этой группы сложно, хотя и возможно. -* Динамическими. Группа, управлением конфигурацией которой осуществляет BlobStorage Controller. Динамические группы -- самый массовый сегмент BS-групп. Предназначены для хранения основного объема данных. - -#### BlobStorage Proxy -**Blob Storage Proxy (BS Proxy, DS Proxy)** - играет роль библиотеки для выполнения операций с Blob Storage. Пользователем DS Proxy являются таблетки, которые пишут в/читают из Blob Storage. DS Proxy скрывает от пользователя распределенную натуру Blob Storage, задача DS Proxy сделать запись на кворум VDiskов, при необходимости делая повторы, контролируя поток записей/чтения, чтобы не перегрузить VDiskи. - -Технически DS Proxy реализована как акторный сервис, запускаемый **Warden** на каждой ноде для каждой BS-группы, обрабатывающий все запросы к группе (запись, чтение и удаление логоблобов, блокировка группы). При записи данных DS Proxy осуществляет erasure-кодирование данных разделяя LogoBlob-ы на part-ы, которые затем рассылаются на соответствующие VDiskи. При чтении DS Proxy осуществляет обратный процесс, получая part-ы от VDisk-ов и восстанавливая LogoBlob-ы из них. - -#### Blob Storage Node Warden -**Blob Storage Node Warden** (BS_NODE) - акторный cервис на каждой ноде кластера, запускающий на старте PDisk, VDisk и BlobStorage Proxy статических групп Blob Storage, а также взаимодействующий с BlobStorage Controller для запуска PDisk, VDisk и BlobStorage Proxy динамических групп. Запуск BlobStorage Proxy динамических групп происходит по запросу: Node Warden обрабатывает "не доставленные" сообщения к DS Proxy, запуская соответствующие DS Proxy и получая конфигурацию групп от BlobStorage Controller. - -#### Fail Realm -**Fail Realm**. Группа Blob Storage представляет собой набор VDisk-ов, объединенных в один или более Fail Realm. Fail Realm содержит один или более Fail Domain. Коррелированный отказ двух VDisk-ов в рамках одного Fail Realm выше, чем отказ двух VDisk-ов из разных Fail Realm. По факту Fail Realm обычно соответствует понятию ЦОД или Availability Zone (AZ) в реальной жизни. - -#### Fail Domain -**Fail Domain**. Группа Blob Storage представляет собой набор VDisk-ов, объединенных в один или более Fail Realm. Fail Realm содержит один или более Fail Domain. Коррелированный отказ двух VDisk-ов в рамках одного Fail Domain выше, чем отказ двух VDisk-ов из разных Fail Domain. По факту Fail Domain обычно соответствует понятию стойки (rack) в реальной жизни. - -#### Availability domain -**Availability domain** - задумана как локализованная независимая сущность внутри системы. Условно - ЦОД или кросс-ЦОД инсталляция. Фактически, на данный момент не используется. - -#### Channel -**Channel** - логический мост между таблеткой и Blob Storage. Таблетка может писать данные в разные Channel, а Channel отображается на конкретную BS-группу. Наличие нескольких Channel позволяет таблетке: - -* Записать данных больше, чем может хранить одна BS-группа; -* Хранить разные LogoBlob на разных BS-группах, то есть с разным erasure encoding или на разных media (HDD, SSD). - -### Distributed Transactions -**Distributed Transactions** - в системе реализована подсистема выполнения распределенных транзакций. Распределенные транзакции реализуются поверх слоя таблеток (обычно, хранящих данные, например Data Shards). Дело в том, что реализация Локальной базы вместе с инфраструктурой таблеток позволяют выполнять Локальные транзакции с уровнем serializable на уровне данных, хранящися в одной таблетке. Однако для транзакционного изменения данных, хранящихся в разных таблетках, необходим другой механизм. - -Механизм распределенных транзакций, реализованный в системе, является вариацией на тему [Deterministic Transactions](http://cs-www.cs.yale.edu/homes/dna/papers/transactions-wodet11.pdf). Этот механизм позволяет выполнять ограниченный набор транзакций, для которых известен read и write набор ключей. Более сложные транзакции реализуются поверх Deterministic Transactions с использованием оптимистических блокировок (optimistic locks), а именно, транзакция состоит из нескольких deterministic transactions, которые берут блокировки на участниках транзакций и проверяют их на коммите. - -Далее описываются понятия, которые используются для выполнения deterministic transaction: - -* **Prepare stage** - фаза, на которой регистрируется тело транзакции на всех шардах-участниках; -* **Execute stage** - фаза, на которой происходит выполнение запланированной транзакции и формирование ответа. В некоторых случаях (например, тразнакции затрагивающие только один шард или консистентное чтение из снапшота) вместо prepare и execute проводится немедленное выполнение транзакции и формирование ответа; -* **Dirty operations** - в случае readonly транзакций - похож на read uncommitted в базах данных - можно прочитать данные, которые еще не были закоммичены на диск. В случае write транзакций - сформировать ответ сразу после планирования, а не дожидаясь коммита выполнения транзакции на диск; -* **RW set** - набор шардов, которые будут участвовать в выполнении распределенной транзакции. Состоит из объединения read-set - шардов, на которых будет проводится только чтение данных и write-set - шардов, в которых будут проводится модификации; -* **ReadSet data** - данные, которые шарды-участники пересылают в процессе выполнения транзакции (например, метаданные снапшота данных в схемной транзакции копирования таблиц), в случае data транзакций могут содержать информацию о состоянии оптимистических блокировок, готовности шарда к коммиту или решении об отмене транзакции; -* **Transaction proxy** (TX_PROXY) - сервис, который оркестрирует выполнение многих распределённых транзакций (последовательное выполнение фаз, планирование, агрегация результатов), а в случае прямой оркестрации другими акторами (например kqp data транзакций) используется для кеширования и выделения уникальных txid; -* **Transaction flags (TxFlags)** - битовая маска флагов, которые тем или иным способом модифицируют выполнение транзакции; -* **Transaction ID (txid)** - уникальный идентификатор, назначаемый каждой транзакции при её приеме; -* **Transaction order ID** - уникальная идентификатор, назначаемый каждой транзакции при её планировании; -* **PlanStep, Step** - логическое время, на которое планируется набор транзакций для выполнения; -* **Mediator time** - логическое время, до которого (включительно) шард-участник должен знать весь план выполнения, используется для продвижения времени при отсутствии транзакций на конкретном шарде, определения возможности чтения из снапшота. - - -### Data Model and User Interface -#### Global Scheme -**Global Scheme (Глобальная схема) или Схема базы данных** - схема данных хранящихся в базе данных. Система представляет собой набор таблиц и некоторых других сущностей, например топиков. Метаданные об этих сущностях и представляют собой глобальную схему. Термин используется в противовес **Local Scheme (Локальная схема)**, который используется для обозначения схемы данных внутри таблетки. Пользователь системы никогда не видит локальную схему, он работает только с глобальной схемой. - -#### MiniKQL -**MiniKQL** - язык, позволяющий выразить одну deterministic transaction системы. Представляет собой функциональный, строго типизированный язык. Концептуально, язык описывает граф чтения из базы, проведения вычислений над прочитанными данными и запись результатов в базу и/или в специальный документ представляющий результат запроса (показывается пользователю). Транзакция MiniKQL должна явно задавать свой read set (читаемые данные) и предполагает детерминированность выбора веток выполнения (например нет random). - -MiniKQL является низкоуровневым языком. Конечные пользователи системы видят только запросы на языке **YQL**, который в своей реализации опирается на MiniKQL. - -#### YQL -**YQL (YDB Query Language)** - высокоуровневый язык для работы с системой, является диалектом SQL. diff --git a/ydb/docs/ru/core/concepts/serverless_and_dedicated.md b/ydb/docs/ru/core/concepts/serverless_and_dedicated.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/ydb/docs/ru/core/concepts/serverless_and_dedicated.md +++ /dev/null diff --git a/ydb/docs/ru/core/deploy/manual/concepts.md b/ydb/docs/ru/core/deploy/manual/concepts.md deleted file mode 100644 index cdf1a6d8a7..0000000000 --- a/ydb/docs/ru/core/deploy/manual/concepts.md +++ /dev/null @@ -1,6 +0,0 @@ -## Ручная установка - -### Термины и определения -YDB состоит из двух компонентов: - * статическая нода (static node) - ноды, обеспечивающие слой хранения данных; - * динамическая нода (dynamic node) - нода, реализующие доступ к данным и их обработку. Для каждой базы данных необходима одна или более отдельная динамическая нода. diff --git a/ydb/docs/ru/core/faq/serverless.md b/ydb/docs/ru/core/faq/serverless.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/ydb/docs/ru/core/faq/serverless.md +++ /dev/null diff --git a/ydb/docs/ru/core/getting_started/_includes/auth.md b/ydb/docs/ru/core/getting_started/_includes/auth.md deleted file mode 100644 index ef2bc74c20..0000000000 --- a/ydb/docs/ru/core/getting_started/_includes/auth.md +++ /dev/null @@ -1,9 +0,0 @@ -# Аутентификация - Начало работы - -Разворачиваемая сценариями самостоятельного развертывания локальная база данных YDB не требует аутентификации, то есть работает в [анонимном режиме](../../concepts/auth.md). - -Полная информация о всех доступных способах аутентификации приведена в статье [Соединение с базой данных](../../concepts/connect.md) в разделе Концепции. - -## Продолжение знакомства с YDB {#next} - -Перейдите к статье [YDB CLI — начало работы](../cli.md) для продолжения знакомства с YDB. diff --git a/ydb/docs/ru/core/getting_started/_includes/cli.md b/ydb/docs/ru/core/getting_started/_includes/cli.md deleted file mode 100644 index 46eb7f5afa..0000000000 --- a/ydb/docs/ru/core/getting_started/_includes/cli.md +++ /dev/null @@ -1,111 +0,0 @@ -# {{ ydb-short-name }} CLI - Начало работы - -## Предварительные требования {#prerequisites} - -Для выполнения команд через CLI вам потребуются параметры соединения с базой данных, которые вы можете получить при ее [создании](../create_db.md): - -* [Эндпоинт](../../concepts/connect.md#endpoint) -* [Имя базы данных](../../concepts/connect.md#database) - -Также вам может потребоваться токен или логин/пароль, если база данных требует [аутентификации](../auth.md). Для успешного исполнения сценария ниже вам нужно выбрать вариант их сохранения в переменной окружения. - -## Установка CLI {#install} - -Установите {{ ydb-short-name }} CLI, как описано в статье [Установка {{ ydb-short-name }} CLI](../../reference/ydb-cli/install.md). - -Проверьте успешность установки YDB CLI запуском с параметром `--help`: - -```bash -{{ ydb-cli }} --help -``` - -В ответ должно быть выведено приветственное сообщение, краткое описание синтаксиса, и перечень доступных команд: - -```text -YDB client - -Usage: ydb [options...] <subcommand> - -Subcommands: -ydb -├─ config Manage YDB CLI configuration -│ └─ profile Manage configuration profiles -│ ├─ activate Activate specified configuration profile (aliases: set) -... -``` - -Все возможности работы со встроенной справкой {{ ydb-short-name }} CLI описаны в статье [Встроенная справка](../../reference/ydb-cli/commands/service.md#help) справочника по {{ ydb-short-name }} CLI. - -## Проверьте успешность соединения {#ping} {#scheme-ls} - -Для проверки успешности соединения можно использовать команду [получения перечня объектов](../../reference/ydb-cli/commands/scheme-ls.md) в базе данных `scheme ls`: - -```bash -{{ ydb-cli }} -e <endpoint> -d <database> scheme ls -``` - -При успешном выполнении команды в ответ будет выведен перечень объектов в базе данных. Если вы еще не создавали ничего в БД, то вывод будет содержать только системные каталоги `.sys` и `.sys_health`, в которых находятся [диагностические представления YDB](../../troubleshooting/system_views_db.md). - -{% include [cli/ls_examples.md](cli/ls_examples.md) %} - -## Создание профиля соединения {#profile} - -Чтобы не писать параметры соединения каждый раз при вызове YDB CLI, воспользуйтесь [профилем](../../reference/ydb-cli/profile/index.md). Создание предложенного ниже профиля позволит вам также копировать дальнейшие команды через буфер обмена без их редактирования, вне зависимости от того, на какой базе данных вы проходите сценарий начала работы. - -[Создайте профиль](../../reference/ydb-cli/profile/create.md) `quickstart` следующей командой: - -```bash -{{ ydb-cli }} config profile create quickstart -e <endpoint> -d <database> -``` - -В качестве параметров используйте проверенные на [предыдущем шаге](#ping) значения. Например, для создания профиля соединения с локальной базой данных YDB, созданной по сценарию самостоятельного развертывания [в Docker](../self_hosted/ydb_docker.md), выполните следующую команду: - -```bash -{{ ydb-cli }} config profile create quickstart -e grpc://localhost:2136 -d /local -``` - -Проверьте работоспособность профиля командой `scheme ls`: - -```bash -{{ ydb-cli }} -p quickstart scheme ls -``` - -## Исполнение YQL скрипта {#yql} - -Команда {{ ydb-short-name }} CLI `yql` позволяет выполнить любую команду (как DDL, так и DML) на [языке YQL](../../yql/reference/index.md) - диалекте SQL, поддерживаемом {{ ydb-short-name }}: - -```bash -{{ ydb-cli }} -p <profile_name> yql -s <yql_request> -``` - -Например: - -* Создание таблицы: - - ```bash - {{ ydb-cli }} -p quickstart yql -s "create table t1( id uint64, primary key(id))" - ``` - -* Добавление записи: - - ```bash - {{ ydb-cli }} -p quickstart yql -s "insert into t1(id) values (1)" - ``` - -* Выборка данных: - - ```bash - {{ ydb-cli }} -p quickstart yql -s "select * from t1" - ``` - -Если вы получаете ошибку `Profile quickstart does not exist`, значит вы не создали его на [предыдущем шаге](#profile). - -## Специализированные команды CLI {#ydb-api} - -Исполнение команд через `ydb yql` является хорошим простым способом начать работу. Однако, YQL-интерфейс поддерживает неполный набор возможных функций, доступных на YDB API, а также работает не самым эффективным образом из-за своей универсальности. - -YDB CLI поддерживает отдельные команды с полным набором опций для всех существующих YDB API. Описание полного перечня команд находится в [справочнике по YDB CLI](../../reference/ydb-cli/index.md). - -## Продолжение знакомства с YDB {#next} - -Перейдите к статье [YQL - Начало работы](../yql.md) для продолжения знакомства с YDB. diff --git a/ydb/docs/ru/core/getting_started/_includes/create_db.md b/ydb/docs/ru/core/getting_started/_includes/create_db.md deleted file mode 100644 index 117f928703..0000000000 --- a/ydb/docs/ru/core/getting_started/_includes/create_db.md +++ /dev/null @@ -1,17 +0,0 @@ -# Создание базы данных - начало работы - -Подробная информация о базах данных находится в статье [Термины и определения - База данных](../../concepts/databases.md#database) в разделе Концепции. - -{% include [create_db_overlay.md](create_db_overlay.md) %} - -## Простое самостоятельное развертывание {#self-hosted} - -Для простого самостоятельного развертывания на локальной машине одноузлового кластера YDB, обслуживающего одну базу данных, можно воспользоваться описанными ниже способами: - -{% include [simple_options](../self_hosted/_includes/simple_options.md) %} - -Документация по развертыванию многоузловых кластеров YDB, обслуживающих множество баз данных, приведена в разделе [Управление кластером](../../deploy/index.md). - -## Продолжение знакомства с YDB {#next} - -После создания базы данных перейдите к статье [Аутентификация - Начало работы](../auth.md) для продолжения знакомства с YDB. diff --git a/ydb/docs/ru/core/getting_started/_includes/create_db_overlay.md b/ydb/docs/ru/core/getting_started/_includes/create_db_overlay.md deleted file mode 100644 index e69de29bb2..0000000000 --- a/ydb/docs/ru/core/getting_started/_includes/create_db_overlay.md +++ /dev/null diff --git a/ydb/docs/ru/core/getting_started/_includes/index.md b/ydb/docs/ru/core/getting_started/_includes/index.md deleted file mode 100644 index 077c56ab67..0000000000 --- a/ydb/docs/ru/core/getting_started/_includes/index.md +++ /dev/null @@ -1,13 +0,0 @@ -{% include [intro.md](index/intro.md) %} - -{% include [create_db.md](index/create_db.md) %} - -{% include [network_access.md](index/network.md) %} - -{% include [auth.md](index/auth.md) %} - -{% include [cli.md](index/cli.md) %} - -{% include [yql.md](index/yql.md) %} - -{% include [sdk.md](index/sdk.md) %} diff --git a/ydb/docs/ru/core/getting_started/_includes/sdk.md b/ydb/docs/ru/core/getting_started/_includes/sdk.md deleted file mode 100644 index 93fe95d9cb..0000000000 --- a/ydb/docs/ru/core/getting_started/_includes/sdk.md +++ /dev/null @@ -1,15 +0,0 @@ -# {{ ydb-short-name }} SDK - начало работы - -{{ ydb-short-name }} SDK - набор программных компонентов, поддерживающих работу с базами данных {{ ydb-short-name }} для приложений на разных языках программирования. - -Выполните следующие шаги для запуска простейшего приложения, использующего {{ ydb-short-name }}: - -1. [Установите {{ ydb-short-name }} SDK](../../reference/ydb-sdk/install.md) для нужного языка программирования. - -1. Скачайте и запустите готовое тестовое приложение, использующее SDK для установленного языка программирования, и изучите его код: - - * [Python](../../reference/ydb-sdk/example/python/index.md) - * [Go](../../reference/ydb-sdk/example/go/index.md) - * [Java](../../reference/ydb-sdk/example/java/index.md) - -Полная информация о {{ ydb-short-name }} SDK находится в разделе [Работа с {{ ydb-short-name }} SDK](../../reference/ydb-sdk/index.md). diff --git a/ydb/docs/ru/core/getting_started/_includes/useful_links.md b/ydb/docs/ru/core/getting_started/_includes/useful_links.md deleted file mode 100644 index 44d291a9d8..0000000000 --- a/ydb/docs/ru/core/getting_started/_includes/useful_links.md +++ /dev/null @@ -1,11 +0,0 @@ -# Полезные ссылки - -{% if oss %} - -* [Сайт {{ ydb-short-name }} OpenSource](https://ydb.tech) - -{% endif %} - -* [Консоль управления в {{ yandex-cloud }}](https://console.cloud.yandex.ru) - -* [GitHub account ydb-platform](https://github.com/ydb-platform) diff --git a/ydb/docs/ru/core/getting_started/auth.md b/ydb/docs/ru/core/getting_started/auth.md deleted file mode 100644 index e7f2395443..0000000000 --- a/ydb/docs/ru/core/getting_started/auth.md +++ /dev/null @@ -1,2 +0,0 @@ - -{% include [auth.md](_includes/auth.md) %} diff --git a/ydb/docs/ru/core/getting_started/cli.md b/ydb/docs/ru/core/getting_started/cli.md deleted file mode 100644 index d737e7a176..0000000000 --- a/ydb/docs/ru/core/getting_started/cli.md +++ /dev/null @@ -1 +0,0 @@ -{% include [cli.md](_includes/cli.md) %} diff --git a/ydb/docs/ru/core/getting_started/create_db.md b/ydb/docs/ru/core/getting_started/create_db.md deleted file mode 100644 index 51d7c75381..0000000000 --- a/ydb/docs/ru/core/getting_started/create_db.md +++ /dev/null @@ -1,2 +0,0 @@ - -{% include [create_db.md](_includes/create_db.md) %} diff --git a/ydb/docs/ru/core/getting_started/index.md b/ydb/docs/ru/core/getting_started/index.md deleted file mode 100644 index 12643df073..0000000000 --- a/ydb/docs/ru/core/getting_started/index.md +++ /dev/null @@ -1 +0,0 @@ -{% include [index.md](_includes/index.md) %} diff --git a/ydb/docs/ru/core/getting_started/sdk.md b/ydb/docs/ru/core/getting_started/sdk.md deleted file mode 100644 index 18bd227b1a..0000000000 --- a/ydb/docs/ru/core/getting_started/sdk.md +++ /dev/null @@ -1 +0,0 @@ -{% include [sdk.md](_includes/sdk.md) %} diff --git a/ydb/docs/ru/core/getting_started/self_hosted/_includes/simple_options.md b/ydb/docs/ru/core/getting_started/self_hosted/_includes/simple_options.md index 367629a92a..d5c915e6d8 100644 --- a/ydb/docs/ru/core/getting_started/self_hosted/_includes/simple_options.md +++ b/ydb/docs/ru/core/getting_started/self_hosted/_includes/simple_options.md @@ -2,4 +2,3 @@ - [С использованием Docker](../ydb_docker.md) - [Из скачанного бинарного файла](../ydb_local.md) - [В Minikube](../ydb_minikube.md) - diff --git a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker.md b/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker.md index 041d08bf92..1fe332ba12 100644 --- a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker.md +++ b/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker.md @@ -1,13 +1,160 @@ +# Запуск {{ ydb-short-name }} в Docker -{% include [intro.md](ydb_docker/01_intro.md) %} +Для отладки или тестирования вы можете запустить [Docker](https://docs.docker.com/get-docker/)-контейнер YDB. -{% include [install.md](ydb_docker/02_install.md) %} +## Параметры соединения {#conn} -{% include [start.md](ydb_docker/03_start.md) %} +В результате выполнения описанных ниже инструкций вы получите локальную базу данных YDB, к которой можно будет обратиться по следующим реквизитам: -{% include [request.md](ydb_docker/04_request.md) %} +{% list tabs %} -{% include [stop.md](ydb_docker/05_stop.md) %} +- gRPC -{% include [license.md](ydb_docker/06_license.md) %} + - [Эндпоинт](../../../concepts/connect.md#endpoint): `grpc://localhost:2136` + - [Путь базы данных](../../../concepts/connect.md#database): `/local` + - [Аутентификация](../../../concepts/auth.md): Анонимная (без аутентификации) +- gRPCs/TLS + + - [Эндпоинт](../../../concepts/connect.md#endpoint): `grpcs://localhost:2135` + - [Путь базы данных](../../../concepts/connect.md#database): `/local` + - [Аутентификация](../../../concepts/auth.md): Анонимная (без аутентификации) + +{% endlist %} + +## Установка {#install} + +Загрузите актуальную публичную версию Docker-образа: + +```bash +docker pull {{ ydb_local_docker_image }}:{{ ydb_local_docker_image_tag }} +``` + +Проверьте, что Docker-образ успешно выгружен: + +```bash +docker image list | grep {{ ydb_local_docker_image }} +``` + +Результат выполнения: + +```bash +{{ ydb_local_docker_image }} {{ ydb_local_docker_image_tag }} b73c5c1441af 2 months ago 793MB +``` + +## Запуск {#start} + +Docker-контейнер YDB использует ресурсы хост-системы (CPU, RAM) в пределах выделенных настройками Docker. + +Docker-контейнер YDB хранит данные в файловой системе контейнера, разделы которой отражаются на директории в хост-системе. Приведенная ниже команда запуска контейнера создаст файлы в текущей директории, поэтому перед запуском создайте рабочую директорию, и выполняйте запуск из неё: + +```bash +docker run -d --rm --name ydb-local -h localhost \ + -p 2135:2135 -p 8765:8765 -p 2136:2136 \ + -v $(pwd)/ydb_certs:/ydb_certs -v $(pwd)/ydb_data:/ydb_data \ + -e YDB_DEFAULT_LOG_LEVEL=NOTICE \ + -e GRPC_TLS_PORT=2135 -e GRPC_PORT=2136 -e MON_PORT=8765 \ + {{ ydb_local_docker_image}}:{{ ydb_local_docker_image_tag }} +``` + +{% list tabs %} + +- Хранение данных на диске + + ```bash + docker run -d --rm --name ydb-local -h localhost \ + -p 2135:2135 -p 8765:8765 -p 2136:2136 \ + -v $(pwd)/ydb_certs:/ydb_certs -v $(pwd)/ydb_data:/ydb_data \ + -e YDB_DEFAULT_LOG_LEVEL=NOTICE \ + -e GRPC_TLS_PORT=2135 -e GRPC_PORT=2136 -e MON_PORT=8765 \ + {{ ydb_local_docker_image}}:{{ ydb_local_docker_image_tag }} + ``` + {% note warning %} + На данный момент хранение данных на диске не поддерживается на Apple Silicon (M1 or M2). Используйте команду с вкладки "Хранение данных в памяти", если хотите попробовать {{ ydb-short-name }} на данных процессорах. + {% endnote %} +- Хранение данных в памяти + ```bash + docker run -d --rm --name ydb-local -h localhost \ + -p 2135:2135 -p 8765:8765 -p 2136:2136 \ + -v $(pwd)/ydb_certs:/ydb_certs -v $(pwd)/ydb_data:/ydb_data \ + -e YDB_DEFAULT_LOG_LEVEL=NOTICE \ + -e GRPC_TLS_PORT=2135 -e GRPC_PORT=2136 -e MON_PORT=8765 \ + -e YDB_USE_IN_MEMORY_PDISKS=true \ + {{ ydb_local_docker_image}}:{{ ydb_local_docker_image_tag }} + ``` +{% endlist %} + +При успешном запуске будет выведен идентификатор созданного контейнера. +### Параметры запуска {#start-pars} +`-d`: Запустить Docker-контейнер в фоновом режиме. +`--rm`: Удалить контейнер после завершения его работы. +`--name`: Имя контейнера. Укажите `ydb-local`, чтобы приведенные ниже инструкции по остановке контейнера можно было выполнить копированием текста через буфер обмена. +`-h`: Имя хоста контейнера. Должно быть обязательно передано значение `localhost`, иначе контейнер будет запущен со случайным именем хоста. +`-v`: Монтировать директории хост-системы в контейнер в виде `<директория хост-системы>:<директория монтирования в контейнере>`. Контейнер YDB использует следующие директории монтирования: +- `/ydb_data`: Размещение данных. Если данная директория не смонтирована, то контейнер будет запущен без сохранения данных на диск хост-системы. +- `/ydb_certs`: Размещение сертификатов для TLS соединения. Запущенный контейнер запишет туда сертификаты, которые вам нужно использовать для клиентского подключения с использованием TLS. Если данная директория не смонтирована, то вы не сможете подключиться по TLS, так как не будете обладать информацией о сертификате. +`-e`: Задать переменные окружения в виде `<имя>=<значение>`. Контейнер YDB использует следующие переменные окружения: +- `YDB_DEFAULT_LOG_LEVEL`: Уровень логирования. Допустимые значения: `CRIT`, `ERROR`, `WARN`, `NOTICE`, `INFO`. По умолчанию `NOTICE`. +- `GRPC_PORT`: Порт для нешифрованных соединений. По умолчанию 2136. +- `GRPC_TLS_PORT`: Порт для соединений с использованием TLS. По умолчанию 2135. +- `MON_PORT`: Порт для встроенного web-ui со средствами [мониторинга и интроспекции](../../../maintenance/embedded_monitoring/ydb_monitoring.md). По умолчанию 8765. +- `YDB_PDISK_SIZE`: Размер диска для хранения данных в формате `<NUM>GB` (например, `YDB_PDISK_SIZE=128GB`). Допустимые значения: от `80GB` и выше. По умолчанию 80GB. +- `YDB_USE_IN_MEMORY_PDISKS`: Использование дисков в памяти. Допустимые значения `true`, `false`, по умолчанию `false`. Во включенном состоянии не использует файловую систему контейнера для работы с данными, все данные хранятся только в памяти процесса, и теряются при его остановке. В настоящее время запуск контейнера на процессоре Apple Silicon (M1 или M2) возможен только в этом режиме. +- `YDB_FEATURE_FLAGS`: Флаги, позволяющие включить функции, отключенные по-умолчанию. Используется для функций, находящихся в разработке (по-умолчанию они выключены). Перечисляются через запятую. +- `POSTGRES_USER` - создать пользователя с указанным логином, используется для подключения через postgres-протокол. +- `POSTGRES_PASSWORD` - задать пароль пользователя для подключения через postgres-протокол. +- `YDB_TABLE_ENABLE_PREPARED_DDL` - временная опция, нужна для запуска Postgres-слоя совместимости, в будущем будет удалена. +{% include [_includes/storage-device-requirements.md](../../../_includes/storage-device-requirements.md) %} +`-p`: Опубликовать порты контейнера на хост-системе. Все применяемые порты должны быть явно перечислены, даже если используются значения по умолчанию. +{% note info %} +Инициализация Docker-контейнера, в зависимости от выделенных ресурсов, может занять несколько минут. До окончания инициализации база данных будет недоступна. +{% endnote %} + +## Выполнение запросов {#request} + +[Установите](../../../reference/ydb-cli/install.md) YDB CLI и выполните запрос, например: + +```bash +ydb -e grpc://localhost:2136 -d /local scheme ls +``` + +Для успешного соединения с использованием TLS в параметры соединения нужно добавить имя файла с сертификатом. Запрос в примере ниже должен быть выполнен из той же рабочей директории, которую вы использовали для запуска контейнера: + +```bash +ydb -e grpcs://localhost:2135 --ca-file ydb_certs/ca.pem -d /local scheme ls +``` + +Предсобранная версия [YDB CLI](../../../reference/ydb-cli/index.md) также доступа внутри образа: + +```bash +docker exec <container_id> /ydb -e grpc://localhost:2136 -d /local scheme ls +``` + +, где + +`<container_id>`: идентификатор контейнера, выведенный при его [запуске](#start). + + +## Остановка {#stop} + +По окончании работы остановите Docker-контейнер: + +```bash +docker kill ydb-local +``` + +## Лицензия и используемые компоненты {#license} + +В корне Docker-контейнера расположены файл с текстом лицензионного соглашения (`LICENSE`) и список используемых компонентов и их лицензии (`THIRD_PARTY_LICENSES`). + +Просмотрите текст лицензионного соглашения: + +```bash +docker run --rm -it --entrypoint cat {{ ydb_local_docker_image }} LICENSE +``` + +Просмотрите все использованные при создании компоненты и их лицензии: + +```bash +docker run --rm -it --entrypoint cat {{ ydb_local_docker_image }} THIRD_PARTY_LICENSES +``` diff --git a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/01_intro.md b/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/01_intro.md deleted file mode 100644 index 07a342619c..0000000000 --- a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/01_intro.md +++ /dev/null @@ -1,23 +0,0 @@ -# Запуск {{ ydb-short-name }} в Docker - -Для отладки или тестирования вы можете запустить [Docker](https://docs.docker.com/get-docker/)-контейнер YDB. - -## Параметры соединения {#conn} - -В результате выполнения описанных ниже инструкций вы получите локальную базу данных YDB, к которой можно будет обратиться по следующим реквизитам: - -{% list tabs %} - -- gRPC - - - [Эндпоинт](../../../../concepts/connect.md#endpoint): `grpc://localhost:2136` - - [Путь базы данных](../../../../concepts/connect.md#database): `/local` - - [Аутентификация](../../../../concepts/auth.md): Анонимная (без аутентификации) - -- gRPCs/TLS - - - [Эндпоинт](../../../../concepts/connect.md#endpoint): `grpcs://localhost:2135` - - [Путь базы данных](../../../../concepts/connect.md#database): `/local` - - [Аутентификация](../../../../concepts/auth.md): Анонимная (без аутентификации) - -{% endlist %} diff --git a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/02_install.md b/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/02_install.md deleted file mode 100644 index 805ca7c73d..0000000000 --- a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/02_install.md +++ /dev/null @@ -1,19 +0,0 @@ -## Установка {#install} - -Загрузите актуальную публичную версию Docker-образа: - -```bash -docker pull {{ ydb_local_docker_image }}:{{ ydb_local_docker_image_tag }} -``` - -Проверьте, что Docker-образ успешно выгружен: - -```bash -docker image list | grep {{ ydb_local_docker_image }} -``` - -Результат выполнения: - -```bash -{{ ydb_local_docker_image }} {{ ydb_local_docker_image_tag }} b73c5c1441af 2 months ago 793MB -``` diff --git a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/03_start.md b/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/03_start.md deleted file mode 100644 index fd21386248..0000000000 --- a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/03_start.md +++ /dev/null @@ -1,86 +0,0 @@ -## Запуск {#start} - -Docker-контейнер YDB использует ресурсы хост-системы (CPU, RAM) в пределах выделенных настройками Docker. - -Docker-контейнер YDB хранит данные в файловой системе контейнера, разделы которой отражаются на директории в хост-системе. Приведенная ниже команда запуска контейнера создаст файлы в текущей директории, поэтому перед запуском создайте рабочую директорию, и выполняйте запуск из неё: - -```bash -docker run -d --rm --name ydb-local -h localhost \ - -p 2135:2135 -p 8765:8765 -p 2136:2136 \ - -v $(pwd)/ydb_certs:/ydb_certs -v $(pwd)/ydb_data:/ydb_data \ - -e YDB_DEFAULT_LOG_LEVEL=NOTICE \ - -e GRPC_TLS_PORT=2135 -e GRPC_PORT=2136 -e MON_PORT=8765 \ - {{ ydb_local_docker_image}}:{{ ydb_local_docker_image_tag }} -``` - -{% list tabs %} - -- Хранение данных на диске - - ```bash - docker run -d --rm --name ydb-local -h localhost \ - -p 2135:2135 -p 8765:8765 -p 2136:2136 \ - -v $(pwd)/ydb_certs:/ydb_certs -v $(pwd)/ydb_data:/ydb_data \ - -e YDB_DEFAULT_LOG_LEVEL=NOTICE \ - -e GRPC_TLS_PORT=2135 -e GRPC_PORT=2136 -e MON_PORT=8765 \ - {{ ydb_local_docker_image}}:{{ ydb_local_docker_image_tag }} - ``` - - {% note warning %} - - На данный момент хранение данных на диске не поддерживается на Apple Silicon (M1 or M2). Используйте команду с вкладки "Хранение данных в памяти", если хотите попробовать {{ ydb-short-name }} на данных процессорах. - - {% endnote %} - -- Хранение данных в памяти - - ```bash - docker run -d --rm --name ydb-local -h localhost \ - -p 2135:2135 -p 8765:8765 -p 2136:2136 \ - -v $(pwd)/ydb_certs:/ydb_certs -v $(pwd)/ydb_data:/ydb_data \ - -e YDB_DEFAULT_LOG_LEVEL=NOTICE \ - -e GRPC_TLS_PORT=2135 -e GRPC_PORT=2136 -e MON_PORT=8765 \ - -e YDB_USE_IN_MEMORY_PDISKS=true \ - {{ ydb_local_docker_image}}:{{ ydb_local_docker_image_tag }} - ``` - -{% endlist %} - - -При успешном запуске будет выведен идентификатор созданного контейнера. - -### Параметры запуска {#start-pars} - -`-d`: Запустить Docker-контейнер в фоновом режиме. - -`--rm`: Удалить контейнер после завершения его работы. - -`--name`: Имя контейнера. Укажите `ydb-local`, чтобы приведенные ниже инструкции по остановке контейнера можно было выполнить копированием текста через буфер обмена. - -`-h`: Имя хоста контейнера. Должно быть обязательно передано значение `localhost`, иначе контейнер будет запущен со случайным именем хоста. - -`-v`: Монтировать директории хост-системы в контейнер в виде `<директория хост-системы>:<директория монтирования в контейнере>`. Контейнер YDB использует следующие директории монтирования: -- `/ydb_data`: Размещение данных. Если данная директория не смонтирована, то контейнер будет запущен без сохранения данных на диск хост-системы. -- `/ydb_certs`: Размещение сертификатов для TLS соединения. Запущенный контейнер запишет туда сертификаты, которые вам нужно использовать для клиентского подключения с использованием TLS. Если данная директория не смонтирована, то вы не сможете подключиться по TLS, так как не будете обладать информацией о сертификате. - -`-e`: Задать переменные окружения в виде `<имя>=<значение>`. Контейнер YDB использует следующие переменные окружения: -- `YDB_DEFAULT_LOG_LEVEL`: Уровень логирования. Допустимые значения: `CRIT`, `ERROR`, `WARN`, `NOTICE`, `INFO`. По умолчанию `NOTICE`. -- `GRPC_PORT`: Порт для нешифрованных соединений. По умолчанию 2136. -- `GRPC_TLS_PORT`: Порт для соединений с использованием TLS. По умолчанию 2135. -- `MON_PORT`: Порт для встроенного web-ui со средствами [мониторинга и интроспекции](../../../../maintenance/embedded_monitoring/ydb_monitoring.md). По умолчанию 8765. -- `YDB_PDISK_SIZE`: Размер диска для хранения данных в формате `<NUM>GB` (например, `YDB_PDISK_SIZE=128GB`). Допустимые значения: от `80GB` и выше. По умолчанию 80GB. -- `YDB_USE_IN_MEMORY_PDISKS`: Использование дисков в памяти. Допустимые значения `true`, `false`, по умолчанию `false`. Во включенном состоянии не использует файловую систему контейнера для работы с данными, все данные хранятся только в памяти процесса, и теряются при его остановке. В настоящее время запуск контейнера на процессоре Apple Silicon (M1 или M2) возможен только в этом режиме. -- `YDB_FEATURE_FLAGS`: Флаги, позволяющие включить функции, отключенные по-умолчанию. Используется для функций, находящихся в разработке (по-умолчанию они выключены). Перечисляются через запятую. -- `POSTGRES_USER` - создать пользователя с указанным логином, используется для подключения через postgres-протокол. -- `POSTGRES_PASSWORD` - задать пароль пользователя для подключения через postgres-протокол. -- `YDB_TABLE_ENABLE_PREPARED_DDL` - временная опция, нужна для запуска Postgres-слоя совместимости, в будущем будет удалена. - -{% include [_includes/storage-device-requirements.md](../../../../_includes/storage-device-requirements.md) %} - -`-p`: Опубликовать порты контейнера на хост-системе. Все применяемые порты должны быть явно перечислены, даже если используются значения по умолчанию. - -{% note info %} - -Инициализация Docker-контейнера, в зависимости от выделенных ресурсов, может занять несколько минут. До окончания инициализации база данных будет недоступна. - -{% endnote %} diff --git a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/04_request.md b/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/04_request.md deleted file mode 100644 index 2c56435ec9..0000000000 --- a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/04_request.md +++ /dev/null @@ -1,23 +0,0 @@ -## Выполнение запросов {#request} - -[Установите](../../../../reference/ydb-cli/install.md) YDB CLI и выполните запрос, например: - -```bash -ydb -e grpc://localhost:2136 -d /local scheme ls -``` - -Для успешного соединения с использованием TLS в параметры соединения нужно добавить имя файла с сертификатом. Запрос в примере ниже должен быть выполнен из той же рабочей директории, которую вы использовали для запуска контейнера: - -```bash -ydb -e grpcs://localhost:2135 --ca-file ydb_certs/ca.pem -d /local scheme ls -``` - -Предсобранная версия [YDB CLI](../../../../reference/ydb-cli/index.md) также доступа внутри образа: - -```bash -docker exec <container_id> /ydb -e grpc://localhost:2136 -d /local scheme ls -``` - -, где - -`<container_id>`: идентификатор контейнера, выведенный при его [запуске](#start).
\ No newline at end of file diff --git a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/05_stop.md b/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/05_stop.md deleted file mode 100644 index ce86ccf8ed..0000000000 --- a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/05_stop.md +++ /dev/null @@ -1,9 +0,0 @@ - - -## Остановка {#stop} - -По окончании работы остановите Docker-контейнер: - -```bash -docker kill ydb-local -``` diff --git a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/06_license.md b/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/06_license.md deleted file mode 100644 index 7313fca870..0000000000 --- a/ydb/docs/ru/core/getting_started/self_hosted/_includes/ydb_docker/06_license.md +++ /dev/null @@ -1,15 +0,0 @@ -## Лицензия и используемые компоненты {#license} - -В корне Docker-контейнера расположены файл с текстом лицензионного соглашения (`LICENSE`) и список используемых компонентов и их лицензии (`THIRD_PARTY_LICENSES`). - -Просмотрите текст лицензионного соглашения: - -```bash -docker run --rm -it --entrypoint cat {{ ydb_local_docker_image }} LICENSE -``` - -Просмотрите все использованные при создании компоненты и их лицензии: - -```bash -docker run --rm -it --entrypoint cat {{ ydb_local_docker_image }} THIRD_PARTY_LICENSES -``` diff --git a/ydb/docs/ru/core/getting_started/toc_i.yaml b/ydb/docs/ru/core/getting_started/toc_i.yaml deleted file mode 100644 index 4a397b5704..0000000000 --- a/ydb/docs/ru/core/getting_started/toc_i.yaml +++ /dev/null @@ -1,16 +0,0 @@ -items: -- name: Создание базы данных - href: create_db.md -- include: { mode: link, path: _includes/index/toc_network.yaml } -- name: Аутентификация - href: auth.md -- name: Интерфейс командной строки YDB CLI - href: cli.md -- name: Язык запросов YQL - href: yql.md -- name: YDB SDK - href: sdk.md -- name: Развертывание одноузлового кластера - include: { mode: link, path: self_hosted/toc_p.yaml } -- name: Полезные ссылки - href: useful_links.md diff --git a/ydb/docs/ru/core/getting_started/toc_p.yaml b/ydb/docs/ru/core/getting_started/toc_p.yaml deleted file mode 100644 index 3e62ad228b..0000000000 --- a/ydb/docs/ru/core/getting_started/toc_p.yaml +++ /dev/null @@ -1,4 +0,0 @@ -items: -- name: Обзор - href: index.md -- include: { mode: link, path: toc_i.yaml }
\ No newline at end of file diff --git a/ydb/docs/ru/core/getting_started/useful_links.md b/ydb/docs/ru/core/getting_started/useful_links.md deleted file mode 100644 index ad6685f23b..0000000000 --- a/ydb/docs/ru/core/getting_started/useful_links.md +++ /dev/null @@ -1,2 +0,0 @@ - -{% include [useful_links.md](_includes/useful_links.md) %} diff --git a/ydb/docs/ru/core/getting_started/ydb_docker.md b/ydb/docs/ru/core/getting_started/ydb_docker.md deleted file mode 100644 index 04578fb40a..0000000000 --- a/ydb/docs/ru/core/getting_started/ydb_docker.md +++ /dev/null @@ -1 +0,0 @@ -{% include [self_hosted/ydb_docker.md](self_hosted/_includes/ydb_docker.md) %} diff --git a/ydb/docs/ru/core/getting_started/ydb_local.md b/ydb/docs/ru/core/getting_started/ydb_local.md deleted file mode 100644 index 3c18eb0f39..0000000000 --- a/ydb/docs/ru/core/getting_started/ydb_local.md +++ /dev/null @@ -1 +0,0 @@ -{% include [self_hosted/ydb_local.md](self_hosted/_includes/ydb_local.md) %} diff --git a/ydb/docs/ru/core/maintenance/_includes/index.md b/ydb/docs/ru/core/maintenance/_includes/index.md deleted file mode 100644 index 89952fabe0..0000000000 --- a/ydb/docs/ru/core/maintenance/_includes/index.md +++ /dev/null @@ -1,11 +0,0 @@ -# Обслуживание YDB - -В данном разделе собраны статьи по обслуживанию баз данных и кластеров YDB. При использовании облачной базы данных актуальны только статьи по обслуживанию баз данных, так как обслуживание кластера под этими базами осуществляется командой облачного поставщика. - -## Обслуживание баз данных -- [Резервное копирование и восстановление](../backup_and_recovery.md) -- [Диагностика](../../troubleshooting/index.md) - -## Обслуживание кластера -- [Встроенный UI](../embedded_monitoring/overview.md) -- [Дисковая подсистема кластера](../manual/index.md) diff --git a/ydb/docs/ru/core/maintenance/index.md b/ydb/docs/ru/core/maintenance/index.md deleted file mode 100644 index eb2590567d..0000000000 --- a/ydb/docs/ru/core/maintenance/index.md +++ /dev/null @@ -1 +0,0 @@ -{% include [_includes/index.md](_includes/index.md) %}
\ No newline at end of file diff --git a/ydb/docs/ru/core/reference/ydb-cli/commands/index.md b/ydb/docs/ru/core/reference/ydb-cli/commands/index.md deleted file mode 100644 index 12643df073..0000000000 --- a/ydb/docs/ru/core/reference/ydb-cli/commands/index.md +++ /dev/null @@ -1 +0,0 @@ -{% include [index.md](_includes/index.md) %} diff --git a/ydb/docs/ru/core/reference/ydb-cli/commands/scheme-mkdir.md b/ydb/docs/ru/core/reference/ydb-cli/commands/scheme-mkdir.md deleted file mode 100644 index 63c2495748..0000000000 --- a/ydb/docs/ru/core/reference/ydb-cli/commands/scheme-mkdir.md +++ /dev/null @@ -1 +0,0 @@ -Данная страница удалена, контент перемещен в [новое размещение](dir.md).
\ No newline at end of file diff --git a/ydb/docs/ru/core/toc_i.yaml b/ydb/docs/ru/core/toc_i.yaml index 3dfa49a5a8..0223a33ba3 100644 --- a/ydb/docs/ru/core/toc_i.yaml +++ b/ydb/docs/ru/core/toc_i.yaml @@ -4,20 +4,14 @@ items: href: index.yaml - name: Начало работы href: getting_started/quickstart.md -# - name: Начало работы -# hidden: true -# include: { mode: link, path: getting_started/toc_p.yaml } + # Main - { name: Концепции, include: { mode: link, path: concepts/toc_p.yaml } } - { name: Практические руководства, include: { mode: link, path: operations/toc_p.yaml } } - - { name: Рекомендации, include: { mode: link, path: best_practices/toc_p.yaml } } -# - { name: Диагностика, include: { mode: link, path: troubleshooting/toc_p.yaml } } moved into maintenance! -# - { name: Развертывание, include: { mode: link, path: deploy/toc_p.yaml } } -# - { name: Обслуживание, include: { mode: link, path: maintenance/toc_p.yaml } } - - { name: Управление базами данных, include: { mode: link, path: db/toc_p.yaml } } - { name: Управление кластером, include: { mode: link, path: cluster/toc_p.yaml } } + # References - { name: YQL, include: { mode: link, path: yql/toc_p.yaml } } - { name: Совместимость с PostgreSQL, include: { mode: link, path: postgresql/toc_p.yaml } } |