ClickHouse/docs/ru/table_engines/resharding.rst

84 lines
6.9 KiB
ReStructuredText
Raw Normal View History

.. _table_engines-resharding:
Перешардирование
----------------
CLICKHOUSE-2720: progress on website and reference (#886) * update presentations * CLICKHOUSE-2936: redirect from clickhouse.yandex.ru and clickhouse.yandex.com * update submodule * lost files * CLICKHOUSE-2981: prefer sphinx docs over original reference * CLICKHOUSE-2981: docs styles more similar to main website + add flags to switch language links * update presentations * Less confusing directory structure (docs -> doc/reference/) * Minify sphinx docs too * Website release script: fail fast + pass docker hash on deploy * Do not underline links in docs * shorter * cleanup docker images * tune nginx config * CLICKHOUSE-3043: get rid of habrastorage links * Lost translation * CLICKHOUSE-2936: temporary client-side redirect * behaves weird in test * put redirect back * CLICKHOUSE-3047: copy docs txts to public too * move to proper file * remove old pages to avoid confusion * Remove reference redirect warning for now * Refresh README.md * Yellow buttons in docs * Use svg flags instead of unicode ones in docs * fix test website instance * Put flags to separate files * wrong flag * Copy Yandex.Metrica introduction from main page to docs * Yet another home page structure change, couple new blocks (CLICKHOUSE-3045) * Update Contacts section * CLICKHOUSE-2849: more detailed legal information * CLICKHOUSE-2978 preparation - split by files * More changes in Contacts block * Tune texts on index page * update presentations * One more benchmark * Add usage sections to index page, adapted from slides * Get the roadmap started, based on slides from last ClickHouse Meetup * CLICKHOUSE-2977: some rendering tuning * Get rid of excessive section in the end of getting started * Make headers linkable * CLICKHOUSE-2981: links to editing reference - https://github.com/yandex/ClickHouse/issues/849 * CLICKHOUSE-2981: fix mobile styles in docs * Ban crawling of duplicating docs * Open some external links in new tab * Ban old docs too * Lots of trivial fixes in english docs * Lots of trivial fixes in russian docs * Remove getting started copies in markdown * Add Yandex.Webmaster * Fix some sphinx warnings * More warnings fixed in english docs * More sphinx warnings fixed * Add code-block:: text * More code-block:: text * These headers look not that well * Better switch between documentation languages * merge use_case.rst into ya_metrika_task.rst * Edit the agg_functions.rst texts * Add lost empty lines * Lost blank lines * Add new logo sizes * update presentations * Next step in migrating to new documentation * Fix all warnings in en reference * Fix all warnings in ru reference * Re-arrange existing reference * Move operation tips to main reference * Fix typos noticed by milovidov@ * Get rid of zookeeper.md * Looks like duplicate of tutorial.html * Fix some mess with html tags in tutorial * No idea why nobody noticed this before, but it was completely not clear whet to get the data * Match code block styling between main and tutorial pages (in favor of the latter) * Get rid of some copypaste in tutorial * Normalize header styles * Move example_datasets to sphinx * Move presentations submodule to website * Move and update README.md * No point in duplicating articles from habrahabr here * Move development-related docs as is for now * doc/reference/ -> docs/ (to match the URL on website) * Adapt links to match the previous commit * Adapt development docs to rst (still lacks translation and strikethrough support) * clean on release * blacklist presentations in gulp * strikethrough support in sphinx * just copy development folder for now * fix weird introduction in style article * Style guide translation (WIP) * Finish style guide translation to English * gulp clean separately * Update year in LICENSE * Initial CONTRIBUTING.md * Fix remaining links to old docs in tutorial * Some tutorial fixes * Typo * Another typo * Update list of authors from yandex-team accoding to git log
2017-06-20 14:19:03 +00:00
.. code-block:: text
ALTER TABLE t RESHARD [COPY] [PARTITION partition] TO описание кластера USING ключ шардирования
Запрос работает только для Replicated-таблиц и для Distributed-таблиц, смотрящих на Replicated-таблицы.
При выполнении, запрос сначала проверяет корректность запроса, наличие свободного места на серверах и кладёт в ZooKeeper по некоторому пути задачу, которую нужно сделать. Дальнейшее выполнение делается асинхронно.
Для того, чтобы использовать перешардирование, в конфигурационном файле каждого сервера должен быть указан путь в ZooKeeper к очереди задач:
.. code-block:: xml
<resharding>
<task_queue_path>/clickhouse/task_queue</task_queue_path>
</resharding>
При выполнении запроса ``ALTER TABLE t RESHARD``, узел в ZooKeeper создаётся, если его не было.
Описание кластера - список шардов с весами, на которые нужно перераспределить указанные данные.
Шард указывается в виде адреса таблицы в ZooKeeper. Например, ``/clickhouse/tables/01-03/hits``
Относительный вес шарда (не обязательно, по умолчанию, 1) может быть указан после ключевого слова WEIGHT.
Пример:
.. code-block:: sql
ALTER TABLE merge.hits
RESHARD PARTITION 201501
TO
'/clickhouse/tables/01-01/hits' WEIGHT 1,
'/clickhouse/tables/01-02/hits' WEIGHT 2,
'/clickhouse/tables/01-03/hits' WEIGHT 1,
'/clickhouse/tables/01-04/hits' WEIGHT 1
USING UserID
Ключ шардирования (в примере: ``UserID``) имеет такой же смысл, как для Distributed таблиц. Вы можете указать rand() в качестве ключа шардирования для случайного перераспределения данных.
При выполнении запроса, сразу проверяется:
* совпадение структур таблиц локально и на всех указанных шардах.
* наличие на локальном сервере свободного места в количестве, равном размеру партиции в байтах, с запасом в 10%.
* наличие на всех репликах всех указанных шардов, кроме являющейся локальной, если такая есть, свободного места в количестве равном размеру партиции, домноженном на отношение веса шарда к суммарному весу, с запасом в 10%.
Далее, асинхронное выполнение задачи состоит из следующих шагов:
#. Нарезка партиции на кусочки на локальном сервере.
Для этого делается слияние всех кусков, входящих в партицию и, одновременно, разбиение их на несколько, согласно ключу шардирования.
Результат складывается в директорию /reshard в директории с данными таблицы.
Исходные куски никак не модифицируются и весь процесс не влияет на рабочие данные таблицы.
#. Копирование всех кусков на удалённые серверы (на каждую реплику соответствующих шардов).
#. Выполнение запроса ALTER TABLE t DROP PARTITION на локальном сервере, выполнение запросов ALTER TABLE t ATTACH PARTITION на всех шардах.
Замечание: это делается неатомарно. Есть момент времени, в течение которого пользователь может увидеть отсутствие данных партиции.
В случае указания в запросе слова COPY, исходные данные не удаляются. Это подходит для копирования данных с одного кластера на другой с одновременным изменением схемы шардирования.
#. Удаление временных данных с локального сервера.
При наличии нескольких запросов на перешардирование, соответствующие задачи будут делаться последовательно.
Указанный выше запрос предназначен для того, чтобы перешардировать одну партицию.
Если не указать партицию в запросе, то в задачи на перешардирование будут добавлены все партиции. Пример:
.. code-block:: sql
ALTER TABLE merge.hits
RESHARD
TO ...
В этом случае, последовательно вставляются задачи на перешардирование каждой партиции.
В случае перешардирования Distributed-таблицы, производится перешардирование каждого шарда (соответствующий запрос отправляется на каждый шард).
Вы можете перешардировать Distributed-таблицу как в саму себя, так и в другую таблицу.
Перешардирование предназначено для перераспределения "старых" данных: в случае, если во время работы, перешардируемая партиция была изменена, то перешардирование этой партиции отменяется.
На каждом сервере, перешардирование осуществляется в один поток, чтобы в процессе длительных операций перешардирования, не мешать другим задачам.
По состоянию на июнь 2016, перешардирование находится в состоянии "бета": тестировалось лишь на небольшом объёме данных - до 5 ТБ.