testing_project/Documentation: concepts/sharding/vshard_architecture — Russian @ Weblate: Adding more power to a single server: using a more …

The translation is temporarily closed for contributions due to maintenance, please come back later.
The translation was automatically locked due to following alerts: Could not merge the repository.

Zen

Translation

English

Russian

Needs editing

Skip

	English	Russian	Actions
	The ``router`` keeps a persistent pool of connections to all the storages that are created at startup. This helps prevent configuration errors. Once the connection pool is created, the ``router`` caches the current state of the routing table in order to speed up routing. If a bucket migrated to another ``storage`` after rebalancing, or a failover occurred and caused one of the shards switching to another replica, the ``discovery fiber`` on the ``router`` updates the routing table automatically.	Роутер поддерживает постоянный пул соединений со всеми хранилищами, созданными при запуске, что помогает избежать ошибки конфигурации. После создания пула соединений роутер кэширует текущее состояние таблицы маршрутизации, чтобы ускорить ее. Если произошла миграция сегмента в другое хранилище после балансировки или же отказ, который вызвал переключение шарда на другую реплику, файбер обнаружения (``discovery fiber``) в роутере обновит таблицу маршрутизации автоматически.
	As the bucket id is explicitly indicated both in the data and in the mapping table on the ``router``, the data is consistent regardless of the application logic. It also makes rebalancing transparent for the application.	Поскольку идентификатор сегмента явно указан как в данных, так и в таблице отображения на роутере, данные сохраняются независимо от логики приложения. Это также обеспечивает прозрачность балансировки для приложения.
	Processing requests	Обработка запросов
	Requests to the database can be performed by the application or using stored procedures. Either way, the bucket id should be explicitly specified in the request.	Запросы в базу данных можно производить из приложения или с помощью хранимых процедур. В любом случае идентификатор сегмента следует явным образом указать в запросе.
	All requests are forwarded to the ``router`` first. The only operation supported by the ``router`` is ``call``. The operation is performed via the ``vshard.router.call()`` function:	Сначала все запросы направляются в роутер. Роутер поддерживает только операцию вызова, которая выполняется с помощью функции ``vshard.router.call()``:
	result = vshard.router.call(<bucket_id>, <mode>, <function_name>, {<argument_list>}, {<opts>})	result = vshard.router.call(<идентификатор_сегмента>, <режим>, <имя_функции>, {<список_аргументов>}, {<опции>})
	Requests are processed as follows:	Запросы обрабатываются следующим образом:
	The ``router`` uses the bucket id to search for a replica set with the corresponding bucket in the routing table.	Роутер использует идентификатор сегмента для поиска набора реплик с соответствующим сегментом в таблице маршрутизации.
	If the map of the bucket id to the replica set is not known to the ``router`` (the discovery fiber hasn’t filled the table yet), the ``router`` makes requests to all ``storages`` to find out where the bucket is located.	Если роутер не содержит информацию о соответствии идентификатора сегмента набору реплик (файбер обнаружения еще не заполнил таблицу), роутер выполняет запросы ко всем хранилищам, чтобы обнаружить местонахождение сегмента.
	Once the bucket is located, the shard checks:	После обнаружения сегмента шард проверяет:
	whether the bucket is stored in the ``_bucket`` system space of the replica set;	хранится ли сегмент в системном спейсе ``_bucket`` набора реплик;
	whether the bucket is ACTIVE or PINNED (for a read request, it can also be SENDING).	находится ли сегмент в статусе ACTIVE (активный) или PINNED (закрепленный) (если выполняется запрос на чтение, то сегмент может находиться в состоянии отправки SENDING).
	If all the checks succeed, the request is executed. Otherwise, it is terminated with the error: ``“wrong bucket”``.	Если проверка пройдена, запрос выполняется. В противном случае, выполнение запроса прекращается с ошибкой: ``“wrong bucket”`` (несоответствующий сегмент).
	Glossary	Глоссарий
	Vertical scaling	Вертикальное масштабирование
	Adding more power to a single server: using a more powerful CPU, adding more capacity to RAM, adding more storage space, etc.	Добавление мощности в отдельный сервер: использование более мощного процессора, добавление оперативной памяти, добавление хранилищ и т.д.
	Horizontal scaling	Горизонтальное масштабирование
	Adding more servers to the pool of resources, then partitioning and distributing a dataset across the servers.	Добавление дополнительных серверов в пул ресурсов, последующее секционирование и распределение набора данных по серверам.
	Sharding	Шардинг
	A database architecture that allows partitioning a dataset using a sharding key and distributing a dataset across multiple servers. Sharding is a special case of horizontal scaling.	Архитектура базы данных, которая допускает секционирование набора данных по сегментному ключу и распределение набора данных по нескольким серверам. Шардинг представляет собой частный случай горизонтального масштабирования.
	Node	Узел
	A virtual or physical server instance.	Виртуальный или физический экземпляр сервера.
	Cluster	Кластер
	A set of nodes that make up a single group.	Набор узлов, которые составляют отдельную группу.
	Storage	Хранилище
	A node storing a subset of a dataset.	Узел, который хранит подмножество данных из набора.
	Replica set	Набор реплик
	A set of storage nodes storing copies of a dataset. Each storage in a replica set has a role, master or replica.	Ряд узлов, на которых хранятся копии набора данных. У каждого хранилища в наборе реплик есть роль: мастер или реплика.
	Master	Мастер
	A storage in a replica set processing read and write requests.	Хранилище в наборе реплик, которое обрабатывает запросы на чтение и запись.
	Replica	Реплика