А в чем вопрос то? Механизм бекапа достаточно однозначный.

А в чем вопрос то? Механизм бекапа достаточно однозначный.

и какой?

и какой?

Freeze partition

Всем привет. В логах появилась странная ошибка

2017.06.29 09:43:36.158877 [ 19 ] <Error> ServerErrorHandler: Code: 101, e.displayText() = DB::NetException: Unexpected packet from client, e.what() = DB::NetException, Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x2969826] 1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x1f) [0x108f49f] 2. clickhouse-server(DB::TCPHandler::receiveHello()+0xc8) [0x10a34f8] 3. clickhouse-server(DB::TCPHandler::runImpl()+0x1cc) [0x10a721c] 4. clickhouse-server(DB::TCPHandler::run()+0x2b) [0x10a827b] 5. clickhouse-server(Poco::Net::TCPServerConnection::start()+0xf) [0x3274d5f] 6. clickhouse-server(Poco::Net::TCPServerDispatcher::run()+0x13b) [0x327b19b] 7. clickhouse-server(Poco::PooledThread::run()+0xb7) [0x34e6e07] 8. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0xa5) [0x34b2e45] 9. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7efc71ac56ba] 10. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7efc710e682d]

повторятеся достаточно часто

дело может быть и не в КХ, а в клиенте; как и через что пишете ?

Напрямую в шарды, http запросами

дело может быть и не в КХ, а в клиенте; как и через что пишете ?

в какую сторону хоть смотреть?)

самому интересно стало, полез исходники почитать почемупри http запросе TCPHandler

в какую сторону хоть смотреть?)

никто у вас там на 9000-й порт не шлет ерунду у всякую ? )

никто у вас там на 9000-й порт не шлет ерунду у всякую ? )

Ну тут как в анекдоте про электрика. "Не должно")

Сейчас сниму дамп, посмотрим что там

А, кажется я начинаю понимать

2017.06.29 18:16:04.011259 [ 2 ] <Error> hits_d.Distributed.DirectoryMonitor: Code: 210, e.displayText() = DB::NetException: I/O error: Broken pipe: while reading from socket (10.138.208.224:9000), e.what() = DB::NetException, Stack trace: 0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x2969826] 1. clickhouse-server(DB::WriteBufferFromPocoSocket::nextImpl()+0x5ad) [0x297de7d] 2. clickhouse-server(DB::Connection::sendData(DB::Block const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0xe5) [0x2b6f365] 3. clickhouse-server(DB::Connection::sendQuery(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned long, DB: :Settings const*, DB::ClientInfo const*, bool)+0xc35) [0x2b709b5] 4. clickhouse-server(DB::RemoteBlockOutputStream::writePrefix()+0x6a) [0x2c25eda] 5. clickhouse-server(DB::StorageDistributedDirectoryMonitor::processFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)+0x6f9) [0x2aa4cf9] 6. clickhouse-server(DB::StorageDistributedDirectoryMonitor::findFiles()+0x14c) [0x2aa680c] 7. clickhouse-server(DB::StorageDistributedDirectoryMonitor::run()+0xc5) [0x2aa6d05] 8. clickhouse-server() [0x36744ef] 9. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7f3c3ac906ba] 10. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f3c3a2b182d] на одном из серверов

это ж ведь все тот же broken pipe?

Всем привет, у нас 100 таблиц, и в каждую таблицу происходит по 50-100 записей в секунду. Как правильно настроить буферизацию на клиентах так, чтобы можно было облегчить мержи нод в кластере? Я как понимаю, одновременная вставка в несколько таблиц является плохой реализацией тоже?

Всем привет, у нас 100 таблиц, и в каждую таблицу происходит по 50-100 записей в секунду. Как правильно настроить буферизацию на клиентах так, чтобы можно было облегчить мержи нод в кластере? Я как понимаю, одновременная вставка в несколько таблиц является плохой реализацией тоже?

мне кажется что вы не совсем по назначению используете КХ, лучшим вариантом будет схлопнуть ваши 100 таблиц в несколько широких и писать в них скидывая данные раз в 1-2 секунды

это ж ведь все тот же broken pipe?

наверно, я не сталкивался с такой проблемой

мне кажется что вы не совсем по назначению используете КХ, лучшим вариантом будет схлопнуть ваши 100 таблиц в несколько широких и писать в них скидывая данные раз в 1-2 секунды

Прошу прощения, 100 БАЗ даже. Для каждого клиента у нас своя база. Это что-то меняет?) Или все равно лучше использовать одну 5-ти терабайтную базу и отутда делать выборки сложные?

сделать 1 таблицу с индексом по user_id

А в этой таблице тогда у нас будут сотни миллиардов данных (клики) - и мы разве сможем по ним делать быструю агрегацию или быструю выборку по диапазону?

индекс по id клиента +- будет отсекать из выборки чужие данные, если уперлись в 1 машину поставте 2-ю и делайте запросы через distributed table

сотни миллиардов кликов ? )

Да, в общей сложности сотни.

В яндексе меньше разве?)

как я понимаю это сырая статистика (хотя и несколько оптимистичная цифра по кликам) отсюда есть рекомендация не отдавать по ней отчеты пользователям, а как минимум обработать ее и выкинуть дубликаты и попутно сагрегировав ее до приемлимых значений (минуты/часы/дни)

Агрегировать на стороне базы можно сразу с помощью материализирвоанных вьюх?

есть https://clickhouse.yandex/docs/en/single/index.html#document-table_engines/summingmergetree но клики и показы так агрегировать нельзя

а почему клики и показы так аггрегирвоать нельзя?

дубликаты и скликивание

> но клики и показы так агрегировать нельзя А как можно? Только на уровне архитектуры самого приложения, агрерировать все в отдельные таблицы кодом?

> но клики и показы так агрегировать нельзя А как можно? Только на уровне архитектуры самого приложения, агрерировать все в отдельные таблицы кодом?

это лучший вариант

А с помощью http://clickhouse-docs.readthedocs.io/ru/latest/table_engines/aggregatingmergetree.html - мы можем группировать большие данные? Или тоже вариант плох?

Например такой вариант: CREATE MATERIALIZED VIEW test.slice_id ENGINE = AggregatingMergeTree(StartDate, (UserID, StartDate, SliceID), 8192) AS SELECT UserID, StartDate, SliceID, countState() Clicks, sumState(Host) Hosts, FROM test.clicks GROUP BY UserID, StartDate, SliceID; и батчить потом по 10к в test.clicks ? Будет вставка и мерж быстрыми?

при сотнях миллиардов лучше батчить по 100-200к

Столкнулся с проблемой при подключении внешних словарей для CH (postgresql).

При загрузке словаря создаётся лог в tmp. И CH на него держит дескриптор

При чём лог постоянно увеличивается. при каждом обновлении

Естественно что удаление файла с файловой системы не поможет отчистить место

Только ребут CH

это лучший вариант

а можно убирать дубликаты перед тем как записывать данные в CH?

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

Сегодня попозже напишу сюда краткие release notes

Наконец нашёл время :)

Изменения с версии 1.1.54236 до 1.1.54244

Новые возможности: * Распределённые DDL (например, CREATE TABLE ON CLUSTER) * Реплицируемый запрос ALTER TABLE CLEAR COLUMN IN PARTITION * Движок таблиц Dictionary (доступ к данным словаря в виде таблицы) * Движок баз данных Dictionary (в такой базе автоматически доступны Dictionary-таблицы для всех подключённых внешних словарей) * Возможность проверки необходимости обновления словаря путём отправки запроса в источник * Qualified имена столбцов * Квотирование идентификаторов двойными кавычками * Сессии в HTTP интерфейсе * Запрос OPTIMIZE Replicated таблицы теперь можно выполнять не только на лидере Обратно несовместимые изменения: * Убрана команда SET GLOBAL Мелочи: * Теперь после получения сигнала в лог печатается полный стектрейс * Ослаблена проверка на количество повреждённых/лишних кусков при старте (было слишком много ложных срабатываний) Исправления: * Исправлено залипание плохого соединения при вставке в Distributed таблицу * GLOBAL IN теперь работает при запросе из таблицы Merge, смотрящей в Distributed * Теперь правильно определяется количество ядер на виртуалках Google Compute Engine * Исправления в работе executable источника кэшируемых внешних словарей * Исправлены сравнения строк, содержащих нулевые символы * Исправлено сравнение полей первичного ключа типа Float32 с константами * Раньше неправильная оценка размера поля могла приводить к слишком большим аллокациям * Исправлено падение при запросе Nullable столбца, добавленного в таблицу ALTER-ом * Исправлено падение при сортировке по Nullable столбцу, если количество строк меньше LIMIT * Исправлен ORDER BY подзапроса, состоящего только из константных значений * Раньше Replicated таблица могла остаться в невалидном состоянии после неудавшегося DROP TABLE * Алиасы для скалярных подзапросов с пустым результатом теперь не теряются * Теперь запрос, в котором использовалась компиляция, не завершается ошибкой, если .so файл повреждается

увольнение джуна это меньшее что будет дальше - расторгнутые контракты, куча слез и убытков

недавно про это поднимались терки в англоязычном коммьюнити, в общем, если у джуна есть доступ к проду на удаление, тут не столько его косяк

согласен

а что если кто-то сделал миграцию кривую и она поломала данные

от этого никто не застрахован. нужна система бэкапов и восстановления )

ну и стейджинг-окружение желательно

оно имеется

от этого никто не застрахован. нужна система бэкапов и восстановления )

вот я и пытаюсь узнать про эту систему

Всем привет. Братцы, проблему с DIstributed не пофиксили еще? 14-го июня Alex писал: "Фикс бага со вставкой в Distributed таблицу в мастере. Постараемся на этой неделе сделать релиз". У меня ровно такая проблемка существует ... И шибко не хочется выносить distributed логику на уровень приложения ...

А может кто нибудь подсказать красивый способ как взять из массива строк только подмассив из заданных индексов? т.е. сделать следующий запрос оптимальней, без такого жуткого оверхеда: SELECT [2, 3] AS given_indices, ['str1', 'str2', 'str3'] AS original_array, arrayFilter((x, i) -> has(given_indices, i), original_array, arrayEnumerate(original_array)) ┌─given_indices─┬─original_array─────────┬─result──────────┐ │ [2,3] │ ['str1','str2','str3'] │ ['str2','str3'] │ └────────┴────────────────┴──────────────┘

чуть выше Изменения с версии 1.1.54236 до 1.1.54244 * Исправлено залипание плохого соединения при вставке в Distributed таблицу

вот я и пытаюсь узнать про эту систему

Максим, попробуйте ReplicatedMergeTree + Zookeeper хотя бы на двух серверах, и, для безопасности, отдельные аккаунты на чтение/запись и ограничение default аккаунта по ip внутри кластера. Ну и тестировать все миграции на небольших таблицах с такими же названиями в другой базе.

Наконец нашёл время :)

Спасибо.

Почему словари поддерживают индексацию только по Int64?

Всем привет. Братцы, проблему с DIstributed не пофиксили еще? 14-го июня Alex писал: "Фикс бага со вставкой в Distributed таблицу в мастере. Постараемся на этой неделе сделать релиз". У меня ровно такая проблемка существует ... И шибко не хочется выносить distributed логику на уровень приложения ...

Релиз "почти" выложен. Пакеты для версии 1.1.54244 опубликованы, но в testing ветке репозитория. Чтобы их установить, надо эту ветку добавить. Делается командами (пример для ubuntu trusty) sudo apt-add-repository "deb http://repo.yandex.ru/clickhouse/trusty testing main" sudo apt-get update

В testing-ветку планируем выкладывать релизы, которые прошли автотесты, но ещё не выложены у нас на продакшене.

Почему словари поддерживают индексацию только по Int64?

ComplexKey* словари поддерживают произвольную индексацию. https://clickhouse.yandex/docs/ru/single/index.html#complex-key-hashed

В testing-ветку планируем выкладывать релизы, которые прошли автотесты, но ещё не выложены у нас на продакшене.

А насколько часто выкатываете обновления ClikckoHouse-а в ту же Метрику?

Можете проследить по появлениям тега -stable на гитхабе.

Коллеги, привет :) У кого-то получилось без танцев с бубном прикрутить геобазу Maxmind?

Какой вообще прямой путь?

В поиске по чатику не просто танцы, а целые балеты в трёх частях :(

Maxmind актуально очень, пока вижу только содаздавать regions_hierarchy.txt из MaxMind

ComplexKey* словари поддерживают произвольную индексацию. https://clickhouse.yandex/docs/ru/single/index.html#complex-key-hashed

Аааа, не очевидно. В чём подвох? Почему есть два вида словарей? Это какая-то микрооптимизация? Кстати, в доке нет примера с odbc драйвером.

Аааа, не очевидно. В чём подвох? Почему есть два вида словарей? Это какая-то микрооптимизация? Кстати, в доке нет примера с odbc драйвером.

Да, оптимизация. Для составных ключей сложнее считается хеш. Также для UInt64 ключей flat словарь работает быстрее.

Да, оптимизация. Для составных ключей сложнее считается хеш. Также для UInt64 ключей flat словарь работает быстрее.

Под UUID ключи нет специальных оптимизаций? Любопытно, что за семейство хэш-функций используется для составных ключей? Под свой тип данных свой хэш?

Под UUID оптимизации нет

@kochetovnicolai в документации к dictGetT написано, что id должен быть обязательно Int64. Как тогда использовать словари? %)

либо UInt64, либо тупл чего угодно, в том числе из одного эелмента.

Int64 или tuple пример из документации: dictGetString('dict_name', 'attr_name', tuple('field1', 123))

Привет. @ztlpn, спасибо. Поставил и попробовал создать Distributed таблицу на отдельном сервера (раньше она была на одном из шардов), И встретил такую проблему CREATE TABLE IF NOT EXISTS logevents AS event ENGINE = Distributed(event_cluster, default, event, rand()) Received exception from server: Code: 60. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Table default.event doesn't exist.. event_cluster содержит 4 другие хоста где раполагаются два шарда и две реплики. Сервер с Distributed имеет в конфиге их адреса и включен в ZooKeeper. Таблица syste,clusters показывает эти 4 сервера. Но при попытке создать Distributed таблицу на 5-м сервере получаю сообщение (см выше). Уже теряюсь куда смотреть ... :(

@kochetovnicolai @orantius Спасибо.

Боюсь просто все 4 сервера на testing сразу перевести. Хотел на отдельном попробовать новую сборку ...

ребзя, беспричинно упал клик, в логах есть вот такое: 2017.06.30 01:00:15.383230 [ 246 ] <Warning> stat.impression_07_03 (StorageReplicatedMergeTree): Oops, a watch has leaked 2017.06.30 01:00:15.865557 [ 250 ] <Error> BaseDaemon: (from thread 249) Terminate called without an active exception 2017.06.30 01:00:15.865581 [ 250 ] <Error> BaseDaemon: ######################################## 2017.06.30 01:00:15.865600 [ 250 ] <Error> BaseDaemon: (from thread 249) Received signal Aborted (6). 2017.06.30 01:00:15.894726 [ 250 ] <Error> BaseDaemon: 1. /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38) [0x7ff9d7eb2428] 2017.06.30 01:00:15.894762 [ 250 ] <Error> BaseDaemon: 2. clickhouse-server(Poco::ThreadImpl::runnableEntry(void*)+0xa5) [0x34b2e45] 2017.06.30 01:00:15.894774 [ 250 ] <Error> BaseDaemon: 3. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7ff9d89636ba] 2017.06.30 01:00:15.894785 [ 250 ] <Error> BaseDaemon: 4. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7ff9d7f843dd] кто знает с чем может быть связанно?

Привет. @ztlpn, спасибо. Поставил и попробовал создать Distributed таблицу на отдельном сервера (раньше она была на одном из шардов), И встретил такую проблему CREATE TABLE IF NOT EXISTS logevents AS event ENGINE = Distributed(event_cluster, default, event, rand()) Received exception from server: Code: 60. DB::Exception: Received from localhost:9000, ::1. DB::Exception: Table default.event doesn't exist.. event_cluster содержит 4 другие хоста где раполагаются два шарда и две реплики. Сервер с Distributed имеет в конфиге их адреса и включен в ZooKeeper. Таблица syste,clusters показывает эти 4 сервера. Но при попытке создать Distributed таблицу на 5-м сервере получаю сообщение (см выше). Уже теряюсь куда смотреть ... :(

Решил проблему созданием локальной таблицы event. Она вероятно нужна для создания только . Потом балансировка идет на два шарда. Работает в общем. @ztlpn, еще раз спасибо за фикс Distributed-а.

Новые возможности: * Распределённые DDL (например, CREATE TABLE ON CLUSTER) * Реплицируемый запрос ALTER TABLE CLEAR COLUMN IN PARTITION * Движок таблиц Dictionary (доступ к данным словаря в виде таблицы) * Движок баз данных Dictionary (в такой базе автоматически доступны Dictionary-таблицы для всех подключённых внешних словарей) * Возможность проверки необходимости обновления словаря путём отправки запроса в источник * Qualified имена столбцов * Квотирование идентификаторов двойными кавычками * Сессии в HTTP интерфейсе * Запрос OPTIMIZE Replicated таблицы теперь можно выполнять не только на лидере Обратно несовместимые изменения: * Убрана команда SET GLOBAL Мелочи: * Теперь после получения сигнала в лог печатается полный стектрейс * Ослаблена проверка на количество повреждённых/лишних кусков при старте (было слишком много ложных срабатываний) Исправления: * Исправлено залипание плохого соединения при вставке в Distributed таблицу * GLOBAL IN теперь работает при запросе из таблицы Merge, смотрящей в Distributed * Теперь правильно определяется количество ядер на виртуалках Google Compute Engine * Исправления в работе executable источника кэшируемых внешних словарей * Исправлены сравнения строк, содержащих нулевые символы * Исправлено сравнение полей первичного ключа типа Float32 с константами * Раньше неправильная оценка размера поля могла приводить к слишком большим аллокациям * Исправлено падение при запросе Nullable столбца, добавленного в таблицу ALTER-ом * Исправлено падение при сортировке по Nullable столбцу, если количество строк меньше LIMIT * Исправлен ORDER BY подзапроса, состоящего только из константных значений * Раньше Replicated таблица могла остаться в невалидном состоянии после неудавшегося DROP TABLE * Алиасы для скалярных подзапросов с пустым результатом теперь не теряются * Теперь запрос, в котором использовалась компиляция, не завершается ошибкой, если .so файл повреждается

Что такое http-сессии? Вроде это всегда было: keepAlive

Что такое http-сессии? Вроде это всегда было: keepAlive

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

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

Понял, спасибо.

Ещё вопрос: тут выше писали, что типа не пишите в несколько таблиц одновременно - это как-то напрягло. Какие с этими могут быть особенные проблемы?

Верно, для примеров использования можете посмотреть тест: https://github.com/yandex/ClickHouse/blob/master/dbms/tests/queries/0_stateless/00463_sessions_in_http_interface.sh

Ещё вопрос: тут выше писали, что типа не пишите в несколько таблиц одновременно - это как-то напрягло. Какие с этими могут быть особенные проблемы?

Я пытался писать в несколько таблиц одновременно в несколько потоков - потом фоновый процесс CH сильно по диску ездить начинал. Скорее всего при таком механизме вставки данных создается слишком много мелких кусков данных. И тем самым операции слияния долго отрабатывают

Сейчас переделываю так, чтобы писать в один поток, кусками побольше

Я пытался писать в несколько таблиц одновременно в несколько потоков - потом фоновый процесс CH сильно по диску ездить начинал. Скорее всего при таком механизме вставки данных создается слишком много мелких кусков данных. И тем самым операции слияния долго отрабатывают

Как-то слишком страшно звучит. Бд под запись в одну таблицу? Проблемы конечно понятны, но мультитрединг, все дела. Если в диск упирается, но это не ясно проблемы кх или нет.

привет, есть запрос SELECT toDateTime(intDiv(toUInt32(ts), 60 * 60 * 6) * 60 * 60 * 6) AS time, sum(_count) AS _count FROM event GROUP BY time ORDER BY time возвращает результат ┌────────────────time─┬──_count─┐ │ 2017-06-18 03:00:00 │ 10252 │ │ 2017-06-18 09:00:00 │ 286220 │ │ 2017-06-18 15:00:00 │ 476354 │ │ 2017-06-18 21:00:00 │ 426987 │ │ 2017-06-19 03:00:00 │ 1270717 │ почему время начинаеться с 3 часов а не с 0??