и есть несколько вьюх

когда я выполняю запрос show tables from database

я увижу только таблицы ? или таблицы + вьюхи ?

вьюхи тоже увидите

вьюхи тоже увидите

Спасибо большое =)

а разница между вьюхой и Merge только в том, что во втором случае запрос ваять не надо?

грубо говоря, мат.вьюха - это тоже обычная таблица, только с триггером

я про обычные, материализованные понятно

обычная вьюха это просто селект

вот я и пытаюсь понять, в чём профит Merge

Т.е. в случае реплики - запрос не бьется на части, каждая из которых обрабатывается на отдельной реплике, а потом результат "склеивается"?

Если есть ключ семплирования то можно и по репликам запрос побить

может вместо Merge селект с юнион замутить?

Меня просто попросили, составить список таблиц в базах. Я составил список, показал. А мне сказали чтобы я пересчитал еще раз. Сказали что нет некоторых вьюх. И тогда я подумал, что когда я составлял список таблиц выполнением команды "show tables from database" я получал только список таблиц, а вьюхи не получал.

Сейчас проверил, действительно, команда show tables from database отображает в том числе вьюхи

может вместо Merge селект с юнион замутить?

вот у меня есть две таблицы ReportsToday - она перезаливается раз в 10 минут, в ней сегодняшние данные, и есть ReportsDaily, в нее данные заливаются ночью за прошлые сутки. Чтобы не мутить юнион, я сделал таблу Reports с движком Merge, и просто селектирую из нее.

вот у меня есть две таблицы ReportsToday - она перезаливается раз в 10 минут, в ней сегодняшние данные, и есть ReportsDaily, в нее данные заливаются ночью за прошлые сутки. Чтобы не мутить юнион, я сделал таблу Reports с движком Merge, и просто селектирую из нее.

а не сравнивали разницу в скорости работы?

нет, таблицы небольшие

У Merge чтение автоматически распараллеливается, про унионы не в курсе

если нет, тогда Merge быстрее

уже что-то, спасибо. жаль в доке пояснений нет

это я из доки взял

Скажите пожалуйста, а вьюхи имеют свойство реплицироватся ?

то есть скажем если я создал одну вьюху, а потом отредактировал ее, то поменяется ли она на всех нодах ?

Создаёт представление. Представления бывают двух видов - обычные и материализованные (MATERIALIZED). При создании материализованного представления, нужно обязательно указать ENGINE - движок таблицы для хранения данных. Материализованное представление работает следующим образом: при вставлении данных в таблицу, указанную в SELECT, часть вставленных данных конвертируется запросом, а результат вставляется в представление. Обычные представления не хранят никаких данных, а всего лишь производят чтение из другой таблицы. То есть, обычное представление - не более чем сохранённый запрос. При чтении из представления, этот сохранённый запрос, используется в качестве подзапроса в секции FROM.

То есть чтобы создать реплицируюую вьюху нужно создать матеарилизованую вьюху ?

Вот я создал вьюху на всех четырех нодах. Потом сделал Альтер вьюхи на одной ноде. Можно ли сделать вьюху реплицируемой чтобы вручную на всех нодах не редактировать ?

можно

мат.вьюха это по сути обычная таблица

репликация будет работать также, как и для обычных таблиц

У нас создано много вьюх, но обычных, без указания engine. Их можно перевезти в реплицируемые Merge Tree ? или нужно будет пересоздать ?

Вот я создал вьюху на всех четырех нодах. Потом сделал Альтер вьюхи на одной ноде. Можно ли сделать вьюху реплицируемой чтобы вручную на всех нодах не редактировать ?

Пересоздавать руками

@Shegloff @Krashuevina Спасибо большое за оперативные ответы !

парни, если у меня новая реплика ругается Can not clone replica, because the 172.16.100.158 updated to new ClickHouse version При этом на обоих репликах select version() выдает 18.12.13 - куда мне покопать?

У меня случилось что-то похожее. Было создано несколько новых таблиц on cluster, на ноде с версией 18.1.0. Нода с версией 18.12.13 создала таблицу, но не смогла данные скачать, писала Can not clone replica, because the 'Хост-инициатор' updated to new ClickHouse version (что неправда, там как раз старее версия стояла). Причем некоторые таблицы успешно создались. А некоторые из тех, которые ругались, были пустые. Мне помог апгрейд ноды, на которой создание таблиц запущено было. После ее рестарта все само починилось

У меня случилось что-то похожее. Было создано несколько новых таблиц on cluster, на ноде с версией 18.1.0. Нода с версией 18.12.13 создала таблицу, но не смогла данные скачать, писала Can not clone replica, because the 'Хост-инициатор' updated to new ClickHouse version (что неправда, там как раз старее версия стояла). Причем некоторые таблицы успешно создались. А некоторые из тех, которые ругались, были пустые. Мне помог апгрейд ноды, на которой создание таблиц запущено было. После ее рестарта все само починилось

Мне в итоге помогло удаление из зукипера узлов со старыми нерабочими репликами. Типа /clickhouse/tables/1-1/balance/replica_name/replicas/10.10.10.10 - где последний IP - этой реплики уже не было

Вот я создал вьюху на всех четырех нодах. Потом сделал Альтер вьюхи на одной ноде. Можно ли сделать вьюху реплицируемой чтобы вручную на всех нодах не редактировать ?

Реплицируются данные, а не определение вьюх/таблиц/чего угодно. DDL или вручную на всех нодах запускать надо, или ON CLUSTER

А, то есть если таблица поменяет структуру

Придется вручную менять

На всех нодах

Так ?

Например я добавил ещё один столбец

Запрос ALTER на изменение столбцов реплицируется.

ALTER для Replicated* таблиц реплицируется ?

но его надо запустить на каждом шарде отдельно

Да, это странный момент, потому что в итоге ALTER TABLE … ON CLUSTER не работает, как ожидается

Или это уже починили?

Спасибо всем за ответы

Да, это странный момент, потому что в итоге ALTER TABLE … ON CLUSTER не работает, как ожидается

он работает как ожидается, просто разработчики ожидали то как работает, а вы ожидаете что-то свое. Причем там много факторов включая настройку internal_replication.

но вообще из-за асинхронности On Cluster работает асинхронно, поэтому на проде использовать -- как повезет

но вообще из-за асинхронности On Cluster работает асинхронно, поэтому на проде использовать -- как повезет

Плюсую. Только под пристальным присмотром и вручную выполнять :)

но вообще из-за асинхронности On Cluster работает асинхронно, поэтому на проде использовать -- как повезет

Вроде если все ноды живы, то все-таки запрос проходит синхронно. Пока что ни разу не сталкивался с обратным ?

привет. никто не в курсе, что с этим делать? 2018.09.12 15:28:20.475279 [ 45 ] DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 49, e.displayText() = DB::Exception: Part 20180907_20180912_53493_100624_10153 intersects next part 20180912_20180912_100614_100629_3 (state Committed). It is a bug., e.what() = DB::Exception, Stack trace:

версия 18.5.1, может, в новых пофикшено?

и насколько это критично для дальнейшего функционирования

если часто повторяется - может грузить сеть-cpu

последний час идет и на этой машине график replicated_part_failed_fetches_total в районе 20-25 держится

прочитал чейнджлоги, нихрена из них не понял актуальный статус типа данных UUID им уже можно пользоваться, или лучше таки не рисковать и пользовать что то из FixedString(16) или два поля ( UInt64 + UInt64 )? Что вообще лучше? (планируется использование для group by и в качестве аргумента для uniq[Exact])

пытался читать код, ничего не понял. есть шанс, что они пропадут со временем сами или нужно что-то делать?

последний час идет и на этой машине график replicated_part_failed_fetches_total в районе 20-25 держится

всмысле много и повторяются такие ошибки? тогда возможно что оно скачивает куски и сразу их удаляет в цикле

да, в логах также есть сообщения про удаление, поэтому и вопрос - стоит ждать, что оно сойдется к какой-то неподвижной точке?

если пишет its a bug и все премя одинаковое название part - не сойдется, надо найти в каком оно partition и сделать detach, attach

найти partition - :) select partition from system.parts where name='20180521_46_63_4' limit 10;

проверить потом сколько на диске - select SUM(bytes_on_disk) from system.parts where partition='\'2018-05-21\'' ;

Делаем на лидере - :) ALTER TABLE db.tbl DETACH PARTITION '2018-05-21'; :) ALTER TABLE db.tbl ATTACH PARTITION '2018-05-21'; Больше лишних скачиваний нет. Убеждаемся что в лишнем парте нет нужных данных :) ALTER TABLE db.tbl ATTACH PART '20180521_1_62_5'; :) OPTIMIZE TABLE db.tbl PARTITION '2018-05-21' DEDUPLICATE;

ого, супер

а зачем проверять место на диске?

имею в виду, какой смысл в этом числе? должно быть 0?

а, и как узнать лидера?)

имею в виду, какой смысл в этом числе? должно быть 0?

если там очень много - то процесс может занять очень долго, должно быть больше 0

а, и как узнать лидера?)

SELECT * FROM system.replicas для нужной таблицы is_leader=1

а в каком куске я заинтересован? есть несколько кусков, которые intersects previous & intersects next, где left <= PART <= right, left/right - разные, а PART - всегда один и тот же кусок - я правильно понимаю, что это он проблемный?

а, чтоб вообще такое не повторялось - обновить надо сервер , в 18.10.3 причина уже исправлена была

о, класс еще раз спасибо)

а в каком куске я заинтересован? есть несколько кусков, которые intersects previous & intersects next, где left <= PART <= right, left/right - разные, а PART - всегда один и тот же кусок - я правильно понимаю, что это он проблемный?

который после ATTACH PARTITION останется на диске в detached/

19 гигабайт, ничего себе

сделал attach/detach, прошло практически мгновенно

в detached осталось несколько десятков директорий/кусков с префиксом inactive, стоит пытаться их приаттачивать?

а время изменеиня какое? может что-то старое

cегодняшние, в районе 10 утра. но выхлоп такой: Code: 226, e.displayText() = DB::Exception: No columns in part 20180912_20180912_101361_101361_0, e.what() = DB::Exception ошибки из логов пропали, все устаканилось

(выхлоп попытки приаттачить)

Привет, может кто-то сталкивался с ошибкой при создании реплицируимой таблицы ZooKeeperImpl::Exaption: Marshalling error, path: /clickhouse/tables/01/clusterA/table_name/log ? Подозреваю что проблема с zookeepr но как пофиксить не знаю. Может можно как-то кластер пересоздать ? Пробовал удалять в zookeeper path, zkCli.sh валится с ошибкой.

Привет. а как на мак cli client поставить?

клиент это на самом деле тот же бинарь что и сервер, поэтому либо собирать, либо докер.

Всем привет! Наблюдается проблема с обновлением внешних словарей (из постгреса), проверял в версиях 18.12.5 - 18.12.13 Словари создаются/обновляются при старте кликхауса (это можно увидеть в колонке creation_time в таблице `system.dictionaries`). При следующих попытках обновления (через 5 минут, согласно настройкам) падает исключение (колонка last_exception той же таблицы): Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Host not found, e.what() = Host not found В логах:``` 2018.09.12 05:28:11.448817 [ 52 ] <Error> ExternalDictionaries: Cannot update external dictionary 'bundle_ids', leaving old version: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Host not found, e.what() = Host not found ` Доступ к БД постгреса есть - проверял из консоли клиентами psql и isql (последний с явным указанием настроек ODBC как для кликхауса). Выполнение запроса SYSTEM RELOAD DICTIONARIES; нормально обновляет словари (!), но спустя 5 минут проблема возвращается... Что я делаю не так?

Привет, а можешь побольше логов приложить? Желательно с trace-уровнем. Ну и заодно конфиг словаря, /etc/odbc.ini и /etc/odbcinst.ini.

Кажется логи не нужны, нашли баг (воспроизводится при наличии invalidate_query у odbc-словарей), скоро будет новый релиз с фиксом.

Если в ней будет несколько кусков, то будет параллелить

Если один кусок - тоже всё распараллеливается.

https://github.com/yandex/clickhouse-presentations/blob/master/meetup17/1_low_cardinality_strings.pdf

Это экспериментальная функциональность. Доступна для тестирования.

Привет, может кто-то сталкивался с ошибкой при создании реплицируимой таблицы ZooKeeperImpl::Exaption: Marshalling error, path: /clickhouse/tables/01/clusterA/table_name/log ? Подозреваю что проблема с zookeepr но как пофиксить не знаю. Может можно как-то кластер пересоздать ? Пробовал удалять в zookeeper path, zkCli.sh валится с ошибкой.

Это говорит о том, что в директории /clickhouse/tables/01/clusterA/table_name/log очень много нод. Нужно вручную удалить наиболее старые записи.

в detached осталось несколько десятков директорий/кусков с префиксом inactive, стоит пытаться их приаттачивать?

С inactive директориями ничего делать не нужно. Разве что их можно удалить.

прочитал чейнджлоги, нихрена из них не понял актуальный статус типа данных UUID им уже можно пользоваться, или лучше таки не рисковать и пользовать что то из FixedString(16) или два поля ( UInt64 + UInt64 )? Что вообще лучше? (планируется использование для group by и в качестве аргумента для uniq[Exact])

Тип данных UUID начинает полноценно поддерживаться в ClickHouse. Вы можете использовать его по прямому назначению. Любые оставшиеся недоработки будем исправлять в первую очередь.

У Merge чтение автоматически распараллеливается, про унионы не в курсе

UNION ALL тоже распараллеливается.

Кажется логи не нужны, нашли баг (воспроизводится при наличии invalidate_query у odbc-словарей), скоро будет новый релиз с фиксом.

конфиг словаря: <dictionaries> <dictionary> <name>bundle_ids</name> <source> <odbc> <connection_string>DSN=postgres_dashboard</connection_string> <table>bundle_ids</table> </odbc> </source> <lifetime> <min>300</min> <max>360</max> </lifetime> <layout> <hashed/> </layout> <structure> <id> <name>id</name> </id> <attribute> <name>content</name> <type>String</type> <null_value></null_value> </attribute> </structure> </dictionary> </dictionaries> содержимое /etc/odbc.ini: [DEFAULT] Driver = postgres_dashboard [postgres_dashboard] Description = PostgreSQL connection to dashboard Driver = PostgreSQL Unicode Database = dashboard Servername = ip-address UserName = user Password = superStrongPass Port = 5432 Protocol = 9.6 ReadOnly = Yes RowVersioning = No ShowSystemTables = No ConnSettings = [postgres_booking_tool] Description = PostgreSQL connection to booking tool Driver = PostgreSQL Unicode Database = booking_tool Servername = ip-address UserName = user Password = superStrongPass Port = 5432 Protocol = 9.6 ReadOnly = Yes RowVersioning = No ShowSystemTables = No ConnSettings = содержимое /etc/odbcinst.ini: [PostgreSQL ANSI] Description=PostgreSQL ODBC driver (ANSI version) Driver=psqlodbca.so Setup=libodbcpsqlS.so Debug=0 CommLog=1 UsageCount=1 [PostgreSQL Unicode] Description=PostgreSQL ODBC driver (Unicode version) Driver=psqlodbcw.so Setup=libodbcpsqlS.so Debug=0 CommLog=1 UsageCount=1 locate psqlodbca.so /usr/lib/x86_64-linux-gnu/odbc/psqlodbca.so Как видите, в моем случае invalidate_query не используется...

Кажется логи не нужны, нашли баг (воспроизводится при наличии invalidate_query у odbc-словарей), скоро будет новый релиз с фиксом.

По логам. Когда в логе ошибок есть 2018.09.13 05:54:32.796610 [ 150 ] <Error> ExternalDictionaries: Cannot update external dictionary 'bundle_ids', leaving old version: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Host not found, e.what() = Host not found В логе с уровнем трейс вижу следующее: 2018.09.13 05:54:32.795648 [ 150 ] <Trace> ODBCDictionarySource: SELECT id, content FROM bundle_ids; 2018.09.13 05:54:32.795671 [ 150 ] <Trace> ReadWriteBufferFromHTTP: Sending request to http://localhost:9018/ping 2018.09.13 05:54:32.796610 [ 150 ] <Error> ExternalDictionaries: Cannot update external dictionary 'bundle_ids', leaving old version: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Host not found, e.what() = Host not found остальные записи в логе, насколько я могу судить, к обновлению не относятся...

По логам. Когда в логе ошибок есть 2018.09.13 05:54:32.796610 [ 150 ] <Error> ExternalDictionaries: Cannot update external dictionary 'bundle_ids', leaving old version: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Host not found, e.what() = Host not found В логе с уровнем трейс вижу следующее: 2018.09.13 05:54:32.795648 [ 150 ] <Trace> ODBCDictionarySource: SELECT id, content FROM bundle_ids; 2018.09.13 05:54:32.795671 [ 150 ] <Trace> ReadWriteBufferFromHTTP: Sending request to http://localhost:9018/ping 2018.09.13 05:54:32.796610 [ 150 ] <Error> ExternalDictionaries: Cannot update external dictionary 'bundle_ids', leaving old version: Poco::Exception. Code: 1000, e.code() = 0, e.displayText() = Host not found, e.what() = Host not found остальные записи в логе, насколько я могу судить, к обновлению не относятся...

А localhost резолвится вообще? Если попробовать ping localhost?