Перейти к основному содержимому
Перейти к основному содержимому

Хранилища данных

Что такое разделение вычислений?​

Разделение вычислений доступно для уровней Scale и Enterprise.

Каждый сервис ClickHouse Cloud включает:

  • Группу из двух и более узлов ClickHouse (или реплик), необходимую, но дочерние сервисы могут быть однерепликовыми.
  • Конечную точку (или несколько конечных точек, созданных через интерфейс ClickHouse Cloud), которая является URL сервиса, используемым для подключения к сервису (например, https://dv2fzne24g.us-east-1.aws.clickhouse.cloud:8443).
  • Папку объектного хранилища, где сервис хранит все данные и частичные метаданные:
примечание

Дочерние одиночные сервисы могут масштабироваться вертикально, в отличие от одиночных родительских сервисов.


Fig. 1 - текущий сервис в ClickHouse Cloud

Разделение вычислений позволяет пользователям создавать несколько групп узлов вычислений, каждая из которых имеет свою конечную точку и использует одну и ту же папку объектного хранилища, то есть с одинаковыми таблицами, представлениями и т.д.

Каждая группа узлов вычислений будет иметь свою конечную точку, поэтому вы можете выбрать, какой набор реплик использовать для ваших рабочих нагрузок. Некоторые из ваших рабочих нагрузок могут удовлетворяться только одной небольшой репликой, а другим может потребоваться полная высокая доступность (HA) и сотни гигабайт памяти. Разделение вычислений также позволяет вам разделять операции чтения от операций записи, чтобы они не мешали друг другу:


Fig. 2 - разделение вычислений в ClickHouse Cloud

В этой закрытой программе предварительного просмотра у вас будет возможность создавать дополнительные сервисы, которые будут разделять те же данные с вашими существующими сервисами, или создавать совершенно новую конфигурацию с несколькими сервисами, которые также разделяют те же данные.

Что такое хранилище?​

В ClickHouse Cloud хранилище — это набор сервисов, которые разделяют одни и те же данные. Каждое хранилище имеет основной сервис (этот сервис был создан первым) и вторичные сервисы. Например, на скриншоте ниже вы можете увидеть хранилище "DWH Prod" с двумя сервисами:

  • Основной сервис DWH Prod
  • Вторичный сервис DWH Prod Subservice

Fig. 3 - Пример хранилища

Все сервисы в хранилище разделяют одно и то же:

  • Регион (например, us-east1)
  • Провайдер облачных услуг (AWS, GCP или Azure)
  • Версия базы данных ClickHouse

Вы можете сортировать сервисы по хранилищу, к которому они принадлежат.

Контроль доступа​

Учетные данные базы данных​

Поскольку все в хранилище разделяют один и тот же набор таблиц, они также разделяют контроль доступа к другим сервисам. Это означает, что все пользователи базы данных, созданные в Сервисе 1, также смогут использовать Сервис 2 с теми же правами (гранты на таблицы, представления и т.д.), и наоборот. Пользователи будут использовать другую конечную точку для каждого сервиса, но будут использовать то же имя пользователя и пароль. Другими словами, пользователи разделяются между сервисами, работающими с одним и тем же хранилищем:


Fig. 4 - пользователь Алиса была создана в Сервисе 1, но она может использовать те же учетные данные для доступа ко всем сервисам, которые разделяют одни и те же данные

Контроль сетевого доступа​

Часто полезно ограничивать доступ к конкретным сервисам другими приложениями или случайными пользователями. Это можно сделать, используя сетевые ограничения, подобно тому, как это сейчас настроено для обычных сервисов (перейдите в Настройки на вкладке сервиса в конкретном сервисе в консоли ClickHouse Cloud).

Вы можете применить настройку фильтрации IP к каждому сервису отдельно, что означает, что вы можете контролировать, какое приложение может получить доступ к какому сервису. Это позволяет вам ограничивать пользователей в использовании конкретных сервисов:


Fig. 5 - Алиса ограничена в доступе к Сервису 2 из-за сетевых настроек

Чтение против чтения-записи​

Иногда полезно ограничить доступ к записи в конкретный сервис и разрешить записи только для подмножества сервисов в хранилище. Это можно сделать при создании второго и nth сервисов (первый сервис всегда должен быть с доступом на чтение-запись):


Fig. 6 - Сервисы чтения-записи и только чтения в хранилище

примечание

Сервисы только для чтения в настоящее время позволяют выполнять операции управления пользователями (создание, удаление и т.д.). Это поведение может быть изменено в будущем.

Масштабирование​

Каждый сервис в хранилище может быть настроен в соответствии с вашими рабочими нагрузками по следующим параметрам:

  • Количество узлов (реплик). Основной сервис (сервис, который был создан первым в хранилище) должен иметь 2 или более узлов. Каждый вторичный сервис может иметь 1 или более узлов.
  • Размер узлов (реплик)
  • Необходимо ли, чтобы сервис автоматически масштабировался
  • Должен ли сервис быть простым в случае бездействия (это не может быть применено к первому сервису в группе - см. раздел Ограничения)

Изменения в поведении​

После того, как для сервиса будет включено разделение вычислений (был создан хотя бы один вторичный сервис), вызов функции clusterAllReplicas() с именем кластера default будет использовать только реплики из сервиса, из которого он был вызван. Это означает, что если два сервиса подключены к одному и тому же набору данных, а clusterAllReplicas(default, system, processes) вызван из сервиса 1, будут показаны только процессы, работающие в сервисе 1. При необходимости вы по-прежнему можете вызвать clusterAllReplicas('all_groups.default', system, processes), например, чтобы достичь всех реплик.

Ограничения​

Поскольку это разделение вычислений в данный момент находится в закрытой предварительной версии, существуют некоторые ограничения на использование этой функции. Большинство из этих ограничений будут сняты после выхода функции в GA (общую доступность):

  1. Основной сервис всегда должен быть активен и не должен быть простым (ограничение будет снято некоторое время после GA). В ходе закрытой предварительной версии и некоторое время после GA основной сервис (обычно существующий сервис, который вы хотите расширить, добавив другие сервисы) всегда будет активен и будет иметь отключенную настройку простоя. Вы не сможете остановить или отключить основной сервис, если существует хотя бы один вторичный сервис. Как только все вторичные сервисы будут удалены, вы сможете снова остановить или отключить оригинальный сервис.

  2. Иногда рабочие нагрузки не могут быть изолированы. Хотя цель заключается в том, чтобы дать вам возможность изолировать рабочие нагрузки базы данных друг от друга, могут возникнуть угловые случаи, когда одна нагрузка в одном сервисе повлияет на другой сервис, разделяющий одни и те же данные. Это довольно редкие ситуации, которые в основном связаны с рабочими нагрузками, похожими на OLTP.

  3. Все сервисы чтения-записи выполняют операции фоновый слияний. При вставке данных в ClickHouse база данных сначала вставляет данные в некоторые временные партиции, а затем выполняет слияния в фоновом режиме. Эти слияния могут потреблять память и ресурсы CPU. Когда два сервиса чтения-записи разделяют одно и то же хранилище, оба выполняют операции фоновой работы. Это означает, что может возникнуть ситуация, при которой в Сервисе 1 выполняется запрос INSERT, но операция слияния завершается Сервисом 2. Обратите внимание, что сервисы только для чтения не выполняют фоновые слияния, поэтому они не тратят свои ресурсы на эту операцию.

  4. Вставки в одном сервисе чтения-записи могут предотвратить другой сервис чтения-записи от перевода в простое, если простое включено. Из-за предыдущего пункта второй сервис выполняет фоновые операции слияния для первого сервиса. Эти фоновые операции могут предотвратить переход второго сервиса в простой режим. Как только фоновые операции будут завершены, сервис будет переведен в простой режим. Сервисы только для чтения не подвержены этому и будут переведены в простой режим без задержки.

  5. Запросы CREATE/RENAME/DROP DATABASE могут быть заблокированы простыми/остановленными сервисами по умолчанию. Эти запросы могут повиснуть. Чтобы обойти это, вы можете выполнять запросы управления базами данных с settings distributed_ddl_task_timeout=0 на уровне сеанса или запроса. Например:

  1. В очень редких случаях вторичные сервисы, которые находятся в простое или остановлены в течение длительного времени (дни) без пробуждения/стартования, могут вызвать снижение производительности других сервисов в том же хранилище. Эта проблема будет решена в ближайшее время и связана с мутациями, выполняющимися в фоновом режиме. Если вы думаете, что столкнулись с этой проблемой, пожалуйста, свяжитесь с поддержкой ClickHouse Support.

  2. В настоящее время существует мягкий лимит в 5 сервисов на одно хранилище. Свяжитесь с командой поддержки, если вам нужно больше 5 сервисов в одном хранилище.

Цены​

Дополнительные сервисы, созданные в ходе закрытой предварительной версии, оплачиваются как обычно. Цены на вычисления одинаковы для всех сервисов в хранилище (основных и вторичных). Хранилище оплачивается только один раз — оно включается в первый (оригинальный) сервис.

Резервные копии​

  • Поскольку все сервисы в одном хранилище разделяют одно и то же хранилище, резервные копии создаются только для основного (инициального) сервиса. Таким образом, данные для всех сервисов в хранилище резервируются.
  • Если вы восстанавливаете резервную копию из основного сервиса хранилища, она будет восстановлена в совершенно новом сервисе, который не связан с существующим хранилищем. Вы можете затем добавить больше сервисов к новому сервису сразу после завершения восстановления.

Использование хранилищ​

Создание хранилища​

Для создания хранилища вам нужно создать второй сервис, который будет делить данные с существующим сервисом. Это можно сделать, нажав на символ плюс на любом из существующих сервисов:


Fig. 7 - Нажмите на знак плюс, чтобы создать новый сервис в хранилище

На экране создания сервиса исходный сервис будет выбран в выпадающем списке в качестве источника данных для нового сервиса. После создания эти два сервиса образуют хранилище.

Переименование хранилища​

Существует два способа переименовать хранилище:

  • Вы можете выбрать "Сортировать по хранилищу" на странице сервисов в правом верхнем углу, а затем нажать на иконку карандаша рядом с именем хранилища
  • Вы можете нажать на имя хранилища на любом из сервисов и переименовать хранилище там

Удаление хранилища​

Удаление хранилища означает удаление всех вычислительных сервисов и данных (таблиц, представлений, пользователей и т.д.). Это действие нельзя отменить. Вы можете удалить хранилище только путем удаления первого созданного сервиса. Для этого:

  1. Удалите все сервисы, созданные дополнительно к сервису, который был создан первым;
  2. Удалите первый сервис (внимание: все данные хранилища будут удалены на этом этапе).