А что в лог ClickHouse приходит при запросе с одной версии и с другой? Одинаковые ?

что одинаковые? запросы одинаковые? select today() ?

что одинаковые? запросы одинаковые? select today() ?

В сам ClickHouse сервер такие же запросы приходят? Может драйвер что генерит не то

какой объект берете из resultSet? Если java.sql.Date, то в нем все равно хранится время. Считаем что это YYYY-MM-DD 00:00:00 по таймзоне сервера. Если таймзона приложения отличается, то милисекунды будут те же, но дата по таймзоне приложения может быть другая.

а с 0.1.14 select today() = 2017-06-29

в том же приложении

с того же сервера

учет таймзоны сервера добавлен в 0.1.18

время в таймзоне сервера на 3 часа больше, чем в таймзоне приложения. Везде 29 июня

Допустим приложение в UTC, сервер в UTC+3. today() в сервере - 2017-06-29, т.е. 2016-06-29 00:00:00 UTC+3 = 2016-06-28 21:00:00 UTC, соответственно в приложении дата будет выглядеть как 2016-06-28.

спасибо

Вопрос очередной.

У КХ свой кеш приложения (не дисковый)?

=> как понять по какому алгоритму там содержатся данные.

+ может можно в нём держать придудительного последние данные ну или типа того?

+ вопрос: в нём данные запакованные хранятся или нет? => Так как от этого зависит 100гб или 10гб памяти надо например.

ClickHouse, в основном, использует кэш файловой системы (не свой). В нём - сжатые данные. Отдельно есть возможность включить кэш разжатых блоков внутри ClickHouse. По-умолчанию, выключено. См. use_uncomressed_cache: https://clickhouse.yandex/docs/en/operations/settings/settings.html#use-uncompressed-cache

Если я поставлю use_uncompressed в 0 и дисковые кеше сброшу - я могу быть уверен что это холодные тест?

ну, тогда уж для дисков и read ahead отключать нужно

Да.

+ вопрос как use_uncompressed выкидывает данные => задача - очень быстрый доступ к последним данным. => т.е. как-то бы зафиксировать их в кеше.

На сервере, например, 1тб рам - чего простаивать.

Ещё есть вариант для теста такой: SET min_bytes_to_use_direct_io = 1, merge_tree_uniform_read_distribution = 0; Тогда данные будут читаться с O_DIRECT (без кэша). Это стоит использовать только для теста.

Ещё есть вариант для теста такой: SET min_bytes_to_use_direct_io = 1, merge_tree_uniform_read_distribution = 0; Тогда данные будут читаться с O_DIRECT (без кэша). Это стоит использовать только для теста.

Спасибо, интересно.

> + вопрос как use_uncompressed выкидывает данные LRU > - очень быстрый доступ к последним данным. => т.е. как-то бы зафиксировать их в кеше. Тут не уверен, как лучше. Вообще, недавно вставляемые данные находятся в page cache. Но при чтении будет тратиться время на разжатие. Если включить uncompressed_cache, то будет тратиться при первом запросе, а затем использоваться готовые, пока кэш не вымоется.

Ага, получается немного длинноватая цепочка. Видимо параллельная запись в memory только это решило бы. Но тут я опять к индексам скатываюсь. Тогда получается на данный момент лучший вариант по этой длинной цепочке - запись => чтение в кеш

MergeTree с хранением части данных в оперативке без сжатия - разумная идея. От реализации ограничивает несколько вещей: - низкая потребность в этой функциональности; - трудность указания табличных настроек (опций для таблиц); сложности при репликации.

MergeTree с хранением части данных в оперативке без сжатия - разумная идея. От реализации ограничивает несколько вещей: - низкая потребность в этой функциональности; - трудность указания табличных настроек (опций для таблиц); сложности при репликации.

Я видел это в гугл-группах. На 99% уверен что из той же области люди спрашивали :)

А может кто-то из Яндекса попросил бы лицензию на kx .com для внесения в бенчмарк? Думаю это было бы огромным мотиватором :)

... посмотреть возможно на основного ?серьёзного? конкурента.

Вроде бы у них с сайта можно скачать kdb+ для тестирования. По крайней мере я скачивал из любопытства, но не дошёл до создания таблиц.

Вроде бы у них с сайта можно скачать kdb+ для тестирования. По крайней мере я скачивал из любопытства, но не дошёл до создания таблиц.

Если будут какие вопросы - спрашивайте. Если я помню последнее - то там для свободного доступа только 32 версия - она смысла почти не имеет.

Я думаю все и так знают что за сайт.

Ага. Как раз там хороший пример по загрузке данных. Предлагал коллегам попробовать. Пока цели такой нет, но если будет энтузиазм, то сделаем.

А кто подскажет, выкладывали презентацию с митапа в Минске или нет?

Как раз сейчас собираюсь загрузить.

Супер! Спасибо большое!

?

Но там три штуки. Сейчас выложу свою, а остальные завтра.

https://github.com/yandex/clickhouse-presentations/tree/master/meetup7 На сайт ещё не выложили.

Хотя я понял, что у меня есть все презентации и я их сейчас выложу тоже :)

Спасибо! Сейчас сяду смотреть :)

https://github.com/yandex/clickhouse-presentations/raw/master/meetup7/netmon.pdf https://github.com/yandex/clickhouse-presentations/raw/master/meetup7/internals.pdf

Доброй ночи кто не спит) Скажите плиз как быть когда количество данных переваливает за 50 гигабайт и это дело мы архивируем и заливаем на s3. что делают в ситуациях когда есть продакшен сервер и надо его зеркальную копию, с условием если потеряется кусок данных на проде то можно быстро восстановить?

Доброй ночи кто не спит) Скажите плиз как быть когда количество данных переваливает за 50 гигабайт и это дело мы архивируем и заливаем на s3. что делают в ситуациях когда есть продакшен сервер и надо его зеркальную копию, с условием если потеряется кусок данных на проде то можно быстро восстановить?

Есть реплики, с них можно взять бекапы. По остальному, не понял вопрос.

Есть реплики, с них можно взять бекапы. По остальному, не понял вопрос.

что будет если у мастера отвалился кусок данных что будет на слейве ?

в смысле - отвалился? как отвалился?

ну зашел джун на сервер и случайно удалил партицию

(как пример)

или диск сдох

На сколько помню на реплике оно останется

Особенно если случай со сдохшим диском.

он зеркалит на основе прямых запросов?

Он зеркалит данные

вот я и боюсь что он прозеркалит удаленные данные

https://clickhouse.yandex/docs/en/query_language/queries.html#manipulations-with-partitions-and-parts > DETACH PARTITION > DROP PARTITION > The query is replicated

вот я и боюсь что он прозеркалит удаленные данные

Как удалит, через rm?

https://clickhouse.yandex/docs/en/query_language/queries.html#manipulations-with-partitions-and-parts > DETACH PARTITION > DROP PARTITION > The query is replicated

не особо знаком с репликациями. можешь разъяснить на пальцах?

Как удалит, через rm?

ну например

https://clickhouse.yandex/docs/en/query_language/queries.html#manipulations-with-partitions-and-parts > DETACH PARTITION > DROP PARTITION > The query is replicated

аа то есть эти запросы отзеркалит

Мне кажется это будет не штатная операция для CH. Если rm

https://clickhouse.yandex/docs/ru/table_engines/replication.html https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BF%D0%BB%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F_(%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D0%BA%D0%B0) у кликхауса асинхронная мастер-мастер репликация емнип т.е. слейвов нет как таковых

то есть получится две копии

две. три. сколько угодно.

это больше для распределенной нагрузки подойдет а не для варианта резервного бэкап сервера

лучше нечетное количество серваков. кажется, в таком случае зукипер, если увидит на одном из них фигню, то двое оставшихся забьют. но я не шарю, могу ошибаться.

это больше для распределенной нагрузки подойдет а не для варианта резервного бэкап сервера

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

лучше нечетное количество серваков. кажется, в таком случае зукипер, если увидит на одном из них фигню, то двое оставшихся забьют. но я не шарю, могу ошибаться.

А разве ch вообще поймёт что у него не хватает данных или целой партиции если через rm удалить?

ну в зукипере-то какая-то информация ж должна храниться

зря он что ли для репликации используется но я опять же не претендую на знание. просто это кажется логичным правда, один фиг это все будет актуально только в случае использования Replicated*MergeTree

> Количество реплик одних и тех же данных может быть произвольным. В Яндекс.Метрике в продакшене используется двухкратная репликация. На каждом сервере используется RAID-5 или RAID-6, в некоторых случаях RAID-10. Это является сравнительно надёжным и удобным для эксплуатации решением. > Система следит за синхронностью данных на репликах и умеет восстанавливаться после сбоя. Восстановление после сбоя автоматическое (в случае небольших различий в данных) или полуавтоматическое (когда данные отличаются слишком сильно, что может свидетельствовать об ошибке конфигурации). вот еще из документации

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

а что делать если партиция удалилась случайно где брать то состояние до удаления?

если репликация есть - будет докачивать файлы с реплик там раздел есть, "восстановление после сбоя"

а что делать если партиция удалилась случайно где брать то состояние до удаления?

Что то судя по характеру вопросов ты похоже не просто на будущее интересуешься))

это если DROP PARTITION не делали если делали - руки оторвать джуну и уволить, ну очевидно же!

Что то судя по характеру вопросов ты похоже не просто на будущее интересуешься))

человеческий фактор

а что делать если партиция удалилась случайно где брать то состояние до удаления?

Есть ключик force_четотам, который указывает ноде на то что надо посинкаться

а readonly и допуск только опытным админам от человеческого фактора не спасет?)

это если DROP PARTITION не делали если делали - руки оторвать джуну и уволить, ну очевидно же!

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

И я вот что-то не вспомню кейса когда бы мне пришлось шариться по data директории с rm в зубах

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

а там она не удалится тоже?

или удалится только запросом?

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

не совсем понимаю про зоокипер. ты имеешь ввиду 2 сервера мастер мастер?

Запросом удалится. Но вот ща вспомнил ещё про ограничение в сколько то гигов, после которых кликхаус будет просить особого ключика для разрешения удалять

дадада, 50 гигов кажется, офигел когда недавно увидел

на одном удалили физически, на втором данные останутся т.к. реплицируются только запросы

не совсем понимаю про зоокипер. ты имеешь ввиду 2 сервера мастер мастер?

почитайте доку, там вроде норм объясняется, я в субд не разбираюсь совсем и то вроде понял зукипер - отдельный сервак (или несколько), через который обмениваются метаданными все реплики КХ

надо настроить второй сервак и поиграться

поудалять ))

Как по мне так самое правильное решение. Дока + тестовый стенд

дадада чего гадать можно хоть в виртуалках/докере поднять на одной машине всё

ну просто очевидно что яндекс не создает архивы по 100 петабайт ))

или сколько там

ну просто очевидно что яндекс не создает архивы по 100 петабайт ))

23 триллиона строк. Алексей предпочитает выражаться так :))