cleanup batch upload doc

ref:0bd025a472a73664235d545ccc6183470ca6afb4

1 files changed, 7 insertions, 3 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 659771d77b..ed6c03cef5 100644
--- a/ydb/docs/ru/core/best_practices/_includes/batch_upload.md
+++ b/ydb/docs/ru/core/best_practices/_includes/batch_upload.md
@@ -1,6 +1,6 @@
-# Загрузка больших объёмов данных
+# Загрузка данных в {{ ydb-short-name }}
 
-В данном разделе предоставлены рекомендации по эффективной загрузке больших объемов данных в {{ ydb-short-name }}.
+В данном разделе предоставлены рекомендации по эффективной загрузке  данных в {{ ydb-short-name }}.
 
 {% if oss == true %}
 
@@ -21,15 +21,19 @@
 * В рамках каждой транзакции вставляйте строки из отсортированного по первичному ключу набора, чтобы минимизировать количество шардов, которые затрагивает транзакция.
   В {{ ydb-short-name }} транзакции затрагивающие более, чем один шард, имеют большие накладные расходы по сравнению с транзакциями, затрагивающими ровно один шард. Кроме того, эти накладные расходы увеличиваются с ростом количества шардов таблицы, которые участвуют в транзакции.
   Рекомендуется подбирать вставляемые в конкретной транзакции строки таким образом, чтобы они были расположены в малом количестве шардов, в идеале — в одном.
+* Если требуется залить данные в несколько таблиц, то в рамках одного запроса рекомендуется заливать данные в одну таблицу.
+* Если требуется залить данные в таблицу с синхронным вторичным индексом, то рекомендуется сначала залить данные в таблицу и после завершения заливки данных построить вторичный индекс.
 * Следует избегать записи последовательно в порядке возрастания или убывания первичного ключа.
   Запись в таблицу данных с монотонно возрастающим ключом приведет к тому, что все новые данные будут записываться в конец таблицы, поскольку все таблицы в YDB отсортированы по возрастанию первичного ключа. Так как YDB разделяет таблицы на шарды по диапазонам ключей, вставки будут обрабатываться одним конкретным сервером, отвечающим за "последний" шард. Сосредоточение нагрузки на одном сервере приведет к медленной загрузке данных и не эффективному использованию распределенной системы.
+* В некоторых сценариях требуется записать в таблицу первоначальные данные (зачастую большого объема) прежде чем включать OLTP-нагрузку. В таком случае не требуется транзакционность на уровне отдельных запросов и можно воспользоваться вызовом ```BulkUpsert``` в API и SDK. За счёт отказа от транзационности такой подход  имеет значительно меньшие накладные расходы по сравнению с YQL запросами. В случае успешного ответа запрос, метод ```BulkUpsert``` гарантирует фиксацию всех данных, записанных в рамках данного запроса.
 
 {% note warning %}
 
-Настройка шардирования (Partitioning Policy) таблицы при ее создании в текущей версии возможна только через [Java](https://github.com/yandex-cloud/ydb-java-sdk) и [Python](https://github.com/yandex-cloud/ydb-python-sdk) SDK.
+Метод ```BulkUpsert``` не поддерживается на таблицах со вторичными индексами.
 
 {% endnote %}
 
+
 Исходя из данных рекомендаций можно предложить следующий алгоритм действий для эффективной загрузки данных в {{ ydb-short-name }}:
 
   1. Создайте таблицу, состоящую из желаемого количества шардов, исходя из 1 ГБ данных на шард.