11238
Обсуждаем ClickHouse
Тут спецы. Но мало ли может кому интересно.
Читать полностью…
Да не вопрос. Вы пробовали использовать ну я не знаю, представьте себе в Москве надо евророзетку. Можно сделать? Можно конечно. Геморрой это? Конечно. Какое у вас будет отношение к такой гостинице? (Ну может быть вы такой человек кому нравятся хитрожопости - хызы, тогда не вопрос)
Читать полностью…
ну спокойно создают пользователи, чтобы поиграться с данными
Читать полностью…
Шард - это лишь часть. Что там будет зависит от вас. Вдруг у вас просто словари в одном шарде.
Читать полностью…
ну понятие шард, так же распроняется только на таблицу.
Читать полностью…
то есть, у вас может быть 3 реплики и 3 шарда у одной таблицы, а у другой просто 9 реплик.
Читать полностью…
это просто мета информация. У вас в одном кликхаусе он для одной таблице, может быть шардом, для другой репликой.
Читать полностью…
вы чучуть думаете, что кликхаус это кластер. по факту, то что вы описываете в xml как cluster, это вообще никак не аффектит кликхаус.
Читать полностью…
Ладно. Мне не впадлу пройтись по 1005000 шардам, грохнуть везде базы и заново создать "on cluster"
Читать полностью…
Как-то усложнили тут и вводите в мысли. То есть в рамках кластера segmented где описан еще кластер segmented_mirror вы создаете БД, таблицу, но на mirror добавляете в эту таблицу колонку ?
Читать полностью…
но вообще мне кажется КХ сам догадывается и create database on cluster делает на всех нодах кластера, не важно кто там шард, кто реплика
Читать полностью…
Соррян. Про таблицы все ясно без слов. Мы говорим про бд
Читать полностью…
ddl таблицы реплицируется , т.е. она создастся , данные не реплицируются.
в cloud engine подменяется на SharedMergeTree
Я вообще про Enterprise говорил, а не однонодовую хрень на локальном компе
Читать полностью…
а в чем проблема с if not exists?
create database test if not exists on cluster xxx
А вот это, архитектурно вызывает мега-вопросы.
Идея, почему так сделано, понятна - исторически сложилось (кстати "он кластер" появилось совсем недавно ,не мне Вам говорить).
Текущая ситуация с репликацией и понятна и алогична. Просто на ее алогичнсть особо никто не наталкивался, а те кто наталкивался считали это мелочью (да и я считаю мелочью, если честно) - какой вопрос пересоздать бд или ещё что-то.
А по сути же, интересно посмотрите статистику, кто создаёт таблицу без реплики, если у тебя 100500 шардов, по 3 реплики( да хотя бы 2 шарда) и 3 реплики для отказоустойчивости
Гляньте просто в зк и посмотрите. Вообще ничего сложного.
Читать полностью…
Я это понимаю прекрасно. Проблема в друго. Что понятие шард игнорируется. А ведь это важно. Это вопрос к архитектуре
Читать полностью…
То есть минимальная единица кластера это таблица, а не кликхаус
Читать полностью…
О нет! Не так. Или я что-то не так читаю но replicated на порядок сложнее
Читать полностью…
Для этого придумали движок базы replicated
Читать полностью…
Не на каждую году, а на каждый шард! В этом весь цимес! Предполагая что выполнив на любом шарде create database, автоматом создасться бд и на реплике.
А это не так!
Я понимаю, что ситуация не обычная. Просто потому что все пишут on cluster. Но! Для любого нормального человека существует иерархия
Кластер
|-- шард
|--Реплика
Так вот создавая БД на уровне шарда, ты автоматом создаёшь бд на уровне реплики
В текущей реализации все совсем не так (и в это есть определенная логика) - репликация идёт на уровне таблиц. Т.е. по факту можно создать в кластере! таблицу на шарде 2, реплике 3, и он нигде вообще не будет доступна, кроме как если обратишься именно к этому хосту.
Имеет ли право на жизнь такая логика? Конечно имеет. Кто-нибудь использует эту разницу внутри шарда? Очень сомневаюсь.
Реплика, имхо, не может быть на уровне таблицы (в кластере иначе это не реплика). Реплика, имхо, долга быть уровне хоста. В этом хитрость. А ReplicatedMergeTree юзать в очень и очень редких случаях
изначально в КХ не было on cluster (надо было писать собственную автоматизацию которая подключалась к каждой ноде кластера и выполняла create)
потом где-то в конце 2018 добавили on cluster, но КХ не понимал что таблица replicated и выполнял все команды избыточно на всех нодах, и пытался добавить колонку на каждой реплике в шарде
затем где-то в 2020 это исправили
Немного непонятен ваш вопрос. Вы не указали распределённый запрос изначально. Затем пошли на каждую ноду отдельно создавать базу - и она не создалась нигде ? Тогда это странный первый кейс.
Агая варианта два. Откуда клик должен знать"где" вы хотите создать базу. Это вам не потоковая репликация в пг, тут всё иначе.
create database if not exists mydatbase on cluster ...
или я не понял, у меня много кластеров
один называется segmented там все ноды КХ как шарды из одной реплики, т.е. 50 серверов, 50 шардов
другой называется segmented_mirrored там x шардов n реплик, т.е. 25 шардов * 2 реплики
я бы выполнял
create database on ... cluster segmented
create table on ... cluster segmented
alter table xxx on ... cluster segmented_mirrored add column ..
По дефолту Atomic стоит для БД. Но вот встретился с такой хренью (сейчас мне кажется что раньше такого не было, но не 100%).
Итак, кластер - несколько шардов. На каждый шард по реплике..все вроде норм. Создаю create database (коннект к шарду в целом, а не к хосту), без on cluster.
Ну бывает, мало ли. Shit happens.. далее осознав что 'on cluster' забыт коннекчусь к каждому шарду и создаю там БД (проблема-то? 😃).
И тут оказывается, что ни на одной реплике бд не создалась.
Т.е..по факту, (это пример) если у тебя 50 шардов с 2мя репликами, и ты хочешь создать бд на 25 шардах, то у тебя два варианта:
1) создать БД on cluster и потом на на 50= 25*2 удалить
2) сразу не тупить и создавать бд на каждом хосте?
То есть например я разработчик, база данных replicated, но я создаю там внутри MergeTree. По логике вещей резработчика он хочет видеть ее и на других репликах, но получается на одной только оно создается 🤔
Читать полностью…
а если внутри этой базы создашь не ReplicatedMergeTree, а просто MergeTree, то таблица не реплицируется, ведь так же получается?
Читать полностью…