fixed multiple typos in the docs, reported on Github as #105

7 files changed, 13 insertions, 13 deletions

diff --git a/ydb/docs/ru/core/best_practices/_includes/batch_upload.md b/ydb/docs/ru/core/best_practices/_includes/batch_upload.md
index 657f617518a..b1c903c7300 100644
--- a/ydb/docs/ru/core/best_practices/_includes/batch_upload.md
+++ b/ydb/docs/ru/core/best_practices/_includes/batch_upload.md
@@ -19,11 +19,11 @@
 * Если требуется залить данные в таблицу с синхронным вторичным индексом, то рекомендуется сначала залить данные в таблицу и после завершения заливки данных построить вторичный индекс.
 * Следует избегать записи последовательно в порядке возрастания или убывания первичного ключа.
   Запись в таблицу данных с монотонно возрастающим ключом приведет к тому, что все новые данные будут записываться в конец таблицы, поскольку все таблицы в YDB отсортированы по возрастанию первичного ключа. Так как YDB разделяет таблицы на шарды по диапазонам ключей, вставки будут обрабатываться одним конкретным сервером, отвечающим за "последний" шард. Сосредоточение нагрузки на одном сервере приведет к медленной загрузке данных и не эффективному использованию распределенной системы.
-* В некоторых сценариях требуется записать в таблицу первоначальные данные (зачастую большого объема) прежде чем включать OLTP-нагрузку. В таком случае не требуется транзакционность на уровне отдельных запросов и можно воспользоваться вызовом ```BulkUpsert``` в API и SDK. За счёт отказа от транзакционности такой подход  имеет значительно меньшие накладные расходы по сравнению с YQL запросами. В случае успешного ответа запрос, метод ```BulkUpsert``` гарантирует фиксацию всех данных, записанных в рамках данного запроса.
+* В некоторых сценариях требуется записать в таблицу первоначальные данные (зачастую большого объема) прежде чем включать OLTP-нагрузку. В таком случае не требуется транзакционность на уровне отдельных запросов и можно воспользоваться вызовом ```BulkUpsert``` в API и SDK. За счёт отказа от транзакционности такой подход  имеет значительно меньшие накладные расходы по сравнению с YQL запросами. В случае успешного ответа на запрос, метод ```BulkUpsert``` гарантирует фиксацию всех данных, записанных в рамках данного запроса.
 
 {% note warning %}
 
-Метод ```BulkUpsert``` не поддерживается на таблицах со вторичными индексами.
+Метод ```BulkUpsert``` не поддерживается для таблиц со вторичными индексами.
 
 {% endnote %}
 
diff --git a/ydb/docs/ru/core/best_practices/_includes/pk_scalability.md b/ydb/docs/ru/core/best_practices/_includes/pk_scalability.md
index 5d6f938c6ab..ec47b8d8311 100644
--- a/ydb/docs/ru/core/best_practices/_includes/pk_scalability.md
+++ b/ydb/docs/ru/core/best_practices/_includes/pk_scalability.md
@@ -30,7 +30,7 @@
 ( userhash, userid, timestamp, userevent, PRIMARY KEY (userhash, userid, timestamp) )
 ```
 
-При правильном выборе функции хеширования строки будут распределены достаточно равномерно по всему пространству ключей, что в приведет к более равномерной нагрузке на систему. При этом наличие полей ```userid, timestamp``` в составе ключа после поля ```userhash``` сохраняет локальность и сортировку данных по времени для конкретного пользователя.
+При правильном выборе функции хеширования строки будут распределены достаточно равномерно по всему пространству ключей, что приведет к более равномерной нагрузке на систему. При этом наличие полей ```userid, timestamp``` в составе ключа после поля ```userhash``` сохраняет локальность и сортировку данных по времени для конкретного пользователя.
 
 Расчёт значения поля ```userhash``` в описанном выше примере должен осуществляться приложением, и явно указываться как при вставке новых записей таблицы, так и при доступе к записям по первичному ключу.
 
diff --git a/ydb/docs/ru/core/best_practices/_includes/secondary_indexes.md b/ydb/docs/ru/core/best_practices/_includes/secondary_indexes.md
index f6989b83cb4..f04463964a8 100644
--- a/ydb/docs/ru/core/best_practices/_includes/secondary_indexes.md
+++ b/ydb/docs/ru/core/best_practices/_includes/secondary_indexes.md
@@ -6,7 +6,7 @@
 
 Для того, чтобы воспользоваться аналогичными возможностями для любых полей или комбинаций полей таблицы, по ним могут быть построены дополнительные индексы, называемые **вторичными индексами**.
 
-Транзакционные системы применяет индексы для того, чтобы исключить деградацию производительности и повышение стоимости выполнения запросов при росте объема хранимых данных.
+В транзакционных системах использование индексов позволяет сократить или исключить деградацию производительности и повышение стоимости выполнения запросов при росте объема хранимых данных.
 
 В данной статье описаны основные операции по работе со вторичными индексами и даны ссылки на подробные материалы по каждой операции. Информация о разных типах вторичных индексов и особенностях их устройства находится в статье [Вторичные индексы](../../concepts/secondary_indexes.md) раздела "Концепции".
 
@@ -62,7 +62,7 @@ WHERE  o.id_customer = $customer_id
 
 ```sql
 $to_update = (
-    SELECT pk_field, field1 = $f1, field2 = $f2, ...
+    SELECT pk_field, $f1 AS field1, $f2 AS field2, ...
     FROM   table1 VIEW idx_field3
     WHERE  field3 = $f3)
 
@@ -77,7 +77,7 @@ UPDATE table1 ON SELECT * FROM $to_update
 
 ```sql
 DELETE FROM series ON
-SELECT series_id,
+SELECT series_id
 FROM series VIEW views_index
 WHERE views = 0;
 ```
diff --git a/ydb/docs/ru/core/concepts/cluster/_includes/common_scheme_ydb/tablets.md b/ydb/docs/ru/core/concepts/cluster/_includes/common_scheme_ydb/tablets.md
index 4b7b11e5d46..0faf42fc6ab 100644
--- a/ydb/docs/ru/core/concepts/cluster/_includes/common_scheme_ydb/tablets.md
+++ b/ydb/docs/ru/core/concepts/cluster/_includes/common_scheme_ydb/tablets.md
@@ -12,17 +12,17 @@
 
 ### Как таблетка хранит данные и какие они {#storage}
 
-Базовая таблетка представляет собой LSM-дерево, в котором находятся все данные ее таблиц. Уровнем ниже базовой таблетки находится BlobStorage, который, грубо говоря, является KeyValue-хранилищем, в котором лежат блобы. *Блоб* -- это бинарный фрагмент размером от 1 байта до 10 мегабайт, который имеет идентификатор фиксированной структуры (обычно он называется *BlobId* и имеет тип TLogoBlobID) и связанные с ним данные. Хранилище иммутабельное, то есть каждому идентификатору соответствует только одно значение, которое не может меняться со временем. Блоб можно записать, прочитать и затем удалить, когда он станет не нужен.
+Базовая таблетка представляет собой LSM-дерево, в котором находятся все данные ее таблицы. Уровнем ниже базовой таблетки находится BlobStorage, который, грубо говоря, является KeyValue-хранилищем, в котором лежат блобы. *Блоб* -- это бинарный фрагмент размером от 1 байта до 10 мегабайт, который имеет идентификатор фиксированной структуры (обычно он называется *BlobId* и имеет тип TLogoBlobID) и связанные с ним данные. Хранилище иммутабельное, то есть каждому идентификатору соответствует только одно значение, которое не может меняться со временем. Блоб можно записать, прочитать и затем удалить, когда он станет не нужен.
 
 Подробнее о блобах и распределенном хранилище можно прочитать [здесь](../../distributed_storage.md).
 
-Для BlobStorage блобы являются непрозрачной сущностью. Таблетка может хранить несколько типов блобов. Наиболее часто записываемый блоб — блоб лога (имеется в виду recovery log, журнал восстановления). Лог таблетки устроен в списка блобов, в каждом из которых содержится информация о вносимом изменении в таблицы. При запуске таблетка находит последний блоб лога, и затем рекурсивно по ссылкам вычитывает все связанные с ним блобы. В логе могут также упоминаться блобы снимков (snapshot) — это разновидность блобов, которые содержат данные нескольких блобов лога после слияния (операция merge в LSM-дереве).
+Для BlobStorage блобы являются непрозрачной сущностью. Таблетка может хранить несколько типов блобов. Наиболее часто записываемый блоб — блоб лога (имеется в виду recovery log, журнал восстановления). Лог таблетки устроен в виде списка блобов, в каждом из которых содержится информация о вносимом изменении в таблицы. При запуске таблетка находит последний блоб лога, и затем рекурсивно по ссылкам вычитывает все связанные с ним блобы. В логе могут также содержаться ссылки на блобы снимков (snapshot), которые содержат данные нескольких блобов лога после слияния (операция merge в LSM-дереве).
 
 Блобы разных типов таблетка пишет в разные *каналы*. Канал указывает ветвь хранилища, в которой следует хранить блобы, и выполняет несколько функций, а именно:
 
 1. Выбор типа хранилища (разные каналы могут быть привязаны к разным типам устройств — SSD, HDD, NVMe).
-1. Балансировка нагрузки, т.к. каждый канал имеет лимит от IOPS, доступному месту и пропускной способности.
-1. Указание типа данных. При восстановлении лога читаются только блобы из нулевого канала, что позволяет отделить их от прочих блобов.
+2. Балансировка нагрузки, т.к. каждый канал имеет лимит от IOPS, доступному месту и пропускной способности.
+3. Указание типа данных. При восстановлении лога читаются только блобы из нулевого канала, что позволяет отделить их от прочих блобов.
 
 ### История каналов в таблетке {#history}
 
diff --git a/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/distributed_storage_interface.md b/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/distributed_storage_interface.md
index f024b59bbfb..bdd8301bf6c 100644
--- a/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/distributed_storage_interface.md
+++ b/ydb/docs/ru/core/concepts/cluster/_includes/distributed_storage/distributed_storage_interface.md
@@ -15,7 +15,7 @@
 
 Два блоба считаются различными, если у их идентификаторов отличается хотя бы один из первых пяти параметров (TabletId, Channel, Generation, Step, Cookie). Таким образом, нельзя записать два блоба, которые различаются только BlobSize и/или CrcMode.
 
-Для целей отладки существует строковое форматирование идентификатора блоба, которое имеет взаимодействия `[TabletId:Generation:Step:Channel:Cookie:BlobSize:PartId]`, например, `[12345:1:1:0:0:1000:0]`.
+Для целей отладки существует строковое представление идентификатора блоба, которое имеет формат `[TabletId:Generation:Step:Channel:Cookie:BlobSize:PartId]`, например, `[12345:1:1:0:0:1000:0]`.
 
 При выполнении записи блоба таблетка выбирает параметры Channel, Step и Cookie. TabletId фиксирован и должен указывать на ту таблетку, которая выполняет запись, а Generation — на поколение, в котором запущена таблетка, выполняющая операцию.
 
diff --git a/ydb/docs/ru/core/yql/reference/yql-core/syntax/_includes/lexer.md b/ydb/docs/ru/core/yql/reference/yql-core/syntax/_includes/lexer.md
index 8547e7ca115..62c0ad251c5 100644
--- a/ydb/docs/ru/core/yql/reference/yql-core/syntax/_includes/lexer.md
+++ b/ydb/docs/ru/core/yql/reference/yql-core/syntax/_includes/lexer.md
@@ -88,7 +88,7 @@ SQL хинты представляют собой набор настроек "
 ```sql
 --+ Name1(Value1 Value2 Value3) Name2(Value4) ...
 ```
-Имя SQL хинта является должно состоять из алфавтно-цифровых ASCII символов и начинаться с буквы. Регистр букв в имени хинта игнорируется.
+Имя SQL хинта должно состоять из алфавтно-цифровых ASCII символов и начинаться с буквы. Регистр букв в имени хинта игнорируется.
 После имени хинта в скобках задается произвольное количество значений, разделенных пробелами. В качестве значения может выступать произвольный набор символов.
 Если в наборе символов значения имеется пробел или скобка, то необходимо использовать одинарные кавычки:
 
diff --git a/ydb/docs/ru/core/yql/reference/yql-core/types/_includes/optional.md b/ydb/docs/ru/core/yql/reference/yql-core/types/_includes/optional.md
index 097c2695e5c..d54682e6d0b 100644
--- a/ydb/docs/ru/core/yql/reference/yql-core/types/_includes/optional.md
+++ b/ydb/docs/ru/core/yql/reference/yql-core/types/_includes/optional.md
@@ -11,7 +11,7 @@
 * [JUST](../../builtins/basic#optional-ops) — добавить опциональность к текущему типу, `T` преобразуется в `T?`
 * [NOTHING](../../builtins/basic.md#optional-ops) — создать пустое значение с указанным типом.
  
-`Optional` (nullable) является не свойством типа данных или колонки, а одним из видов [контейнеров](../containers.md), которые могут быть произвольным образом вложены друг в друга. Так, например, столбец с типом `Optional<Optional<Boolean>>` может принимать 4 значения - `NULL` всего контейнера, `NULL` внутреннего контейнера, `TRUE` и `FALSE`. Описанный тип отличается от `List<List<Boolean>>` тем, что роль пустого списка в нем играет `NULL` и отсутствует возможность положить больше одного содержательного элемента. Также `Optional<Optional<T>>` может использоваться в качестве [lookup](/docs/s_expressions/functions#lookup) по ключу в словаре (`Dict(k,v)`) с `Optional<T>` значениями. Такой тип данных результата позволяет отличать лежащий в словаре `NULL` от отсутствия ключа.
+`Optional` (nullable) является не свойством типа данных или колонки, а одним из видов [контейнеров](../containers.md), которые могут быть произвольным образом вложены друг в друга. Так, например, столбец с типом `Optional<Optional<Boolean>>` может принимать 4 значения - `NULL` всего контейнера, `NULL` внутреннего контейнера, `TRUE` и `FALSE`. Описанный тип отличается от `List<List<Boolean>>` тем, что роль пустого списка в нем играет `NULL` и отсутствует возможность положить больше одного содержательного элемента. Также значения типа `Optional<Optional<T>>` возвращаются в качестве результата поиска по ключу в словаре `Dict(k,v)` со значениями типа `Optional<T>`. Такой тип данных результата позволяет отличать лежащий в словаре `NULL` от ситуации отсутствия ключа.
 
 **Пример**