Вылез нюанс что если писать асинхронно и стопануть одну из 2 реплик то перестает мержить

В свою очередь после Х немержей шард перестает отвечать и кластер полудоступен Хотя вроде как потеря реплики не должна к такому приводить.

Ок, сделали синхронную запись, опять 25, при остановке реплики вылезли дубликаты (видимо не только нет атомарности между таблицей и вьюхой но и между репликами)

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

insert_quorum придется вернуть в 0 от вьюх отказались, будем сами писаль в несколько таблиц. ЗЫ я не жалуюсь, я делюсь. Продукт оч быстрый, но есть нюансы при использовании как и везде. Просто эти дубликаты выглядят как серьезная проблема для серьезного использования

Да, а как иначе если батч не прошел? Replaced движок это борьба с последствиями

но вы понимаете, что дубликаты replacing может схлопнуть в отдаленном будущем а может и нет, т.е. надо писать запросы правильно к такой таблице чтобы дубликаты скрывать?

а я не понимаю, что у вас за ошибки при инсертах, из-за которых вы батчи повторяете?

>Да, а как иначе если батч не прошел? >Replaced движок это борьба с последствиями >Одна причина это вьюхи, от них со скрипом отказались и >выкручиваемся без них все это очень странно, у меня миллиард строк в день, все обвешено вьюхами, проблемы бывают ну раз в году может и то обычно я сам виноват.

ноду стопали?

постоянно и падают и стопаю, я правда не пользуюсь записью через distributed

У меня тоже все работало А как начал тустировать что будет если вдруг нода выпадет так ой

постоянно и падают и стопаю, я правда не пользуюсь записью через distributed

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

а я не понимаю, что у вас за ошибки при инсертах, из-за которых вы батчи повторяете?

тут и тут описал https://github.com/yandex/ClickHouse/issues/2765 https://github.com/yandex/ClickHouse/issues/2755

Спрашивайте если что нужно дополнительно

так а что с: но вы понимаете, что дубликаты replacing может схлопнуть в отдаленном будущем а может и нет, т.е. надо писать запросы правильно к такой таблице чтобы дубликаты скрывать?

Так я ответил что этот движок использовать не будем

тут и тут описал https://github.com/yandex/ClickHouse/issues/2765 https://github.com/yandex/ClickHouse/issues/2755

это уже последствия, а не причина

Без вьюх дубликатов нет (они есть или с вьюхами или если insest_quorum выставить в 2 например, как я написал выше причина видимо одна, неатомарность вставки со вьюхами (это подтверждено разработикми) и с репликами видимо тоже атомарности нет и в одну проходит а в другую нет)

ну все ясно мне, я ни хера не понял.

это уже последствия, а не причина

Не совсем понимаю о какой причине речь идет, я не разработчик КХ, точно указать причину мне сложно. Или вы намекаете что стопать ноду не надо и все будет хорошо? К сожалентю в реальности они постоянно ломаються (сервера я имею в виду)

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

у вас дубликаты, потому что вы вставляете по два раза почему вы вставляете по два раза?

потому что в первый раз что-то упало. что-то упало в нашем случае например отказ на вставку из-за медленных мержей, а они медленный в свою очередь потому как если одна реплика упала то на 2й какие-то танцы происходят все что я при этом вижу в системных таблицах и логах я выложил в issue

давайте по пунктам напишу?

и вы надеетесь, что дедупликация в КХ не допустит повторной вставки?

конечно

и вы вставляете второй раз теми же блоками, какими вставляли в первый?

вроде как есди блоки одинаковые а они такие то не должно проходить

Алексей мой код проверил

Вроде бы не нашел явных багов

Вставляем точно тот же кусок

блок меньше настройки

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

т.е. у вас блоки одинаковые, но их очень много, и вы не помещаетесь в 100 блоков, информацию о которых хранит КХ для дедупликации?

Я не могу ответить на вопрос о корне проблем. Если бы я знал куда мы не помещаемся то я бы постарался это исправить

Вставок около 100 в минуту

по 40-50к строк

Как я понял с вьюхами проблема известная и она не в настройках и блоках

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

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

Пример 1. Вставка в осн таблицу прошла 2. Во вьюху упала 3. Вернули исключение на клиент 4. Клиент перевставил 5. В осн прошла вставка Бинго у нас дубликаты

Мне то что я вам выше написал объяснили разработчики Если это не так то давайте с вами попробуем понять причину и главно ечто делать

100 можно увеличить как-то до 1000 и проверить?

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

так я ж без понятия что и куда вставилось а что и куда нет если в исключении например будет информация что 1-Т вставилось а Т-П не вставилось и куда (в какую вью или таблицу) то я с удовольствием обработаю а без этой информации не представляю как.

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

при какой частоте вставки можно расчитывать по вашему? попробую повоевать в этом направлении

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

так то что я по пунктам написал ложное предполажение и дубликаты не из-за этого?

пролейте свет пожалуйста

при какой частоте вставки можно расчитывать по вашему? попробую повоевать в этом направлении

Если вы вставляете раз в минуту, то КХ будет помнить про блок примерно 100 минут. Если вы вставляете раз в секунду, то КХ будет помнить про блок примерно 100 секунд. Как долго КХ должен помнить про блоки, чтобы вы с уверенностью могли повторять вставку?

идея понятно

спсб

помнит распределенная таблица или каждая локальная?

помнит нода в Зукипере, т.е. таблица RepilcatedMergeTree

но если вы вставляете в Distributed, как вы можете быть уверены, что у вас блоки одинаковые?

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

(сейчас переделываю на вставку в локальную таблицу, как я понял вставка должна быть в одну и ту же RepilcatedMergeTree таблицу? есть разница на какую реплику? )

нет, у разных реплик одной таблицы нода в Зукипере одна и та же

спсб

Но я не могу представить, как могут получиться одинаковые блоки при вставке в Distributed таблицу, которая шардирует по rand()

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

Но я не могу представить, как могут получиться одинаковые блоки при вставке в Distributed таблицу, которая шардирует по rand()

я тут некопенгаген ))

нода в ЗК - это первый параметр у ReplicatedMergeTree, по идее на разных шардах он разный должен быть

ну все ясно мне, я ни хера не понял.

Вы перевстявляете в ту же шарду или все равно куда?

я не пользуюсь дедупликацией и вставкой в distibuted поэтому мне параллельно в какой шард и в какую реплику повторять вставку.

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

если надо 100%, храните в mysql

Вроде всё-таки big data не включает в себя потерю данных. Ну т.е. у меня, к примеру, ответное непонимание. Продолбать десять лямов записей? Пф, это же биг дата. :)

Спсб за совет. У всех разные кейсы Я не вижу что хочу чего-то невероятного Просто пытаюсь разобраться Если вы уже разобрались я искренне рад Мне пока до конца не удалось, перебираю варианты

Вроде всё-таки big data не включает в себя потерю данных. Ну т.е. у меня, к примеру, ответное непонимание. Продолбать десять лямов записей? Пф, это же биг дата. :)

Я тоже не могу себе позволить такого Не всем везет

КХ не гарантирует целостность данных. Там нет Durability (в терминах ACID). Поэтому потери гарантированы самим дизайном.

Если эти потери прям фактически гарантированы, стоило бы на главной странице рядом с "Не тормозит" большими буквами добавить "и не сохраняет", раз уж ACID так сурово не соблюдается. Но мне пока думается, что всё менее трагично и D теряется в кейсах, которых можно избежать. Правда, их описания в доке поди найди.

хм, а что какая-то буква из ACID соблюдается в КХ ? кейс очень простой, делаем insert, видим OK, тут же посылаем kill -9 демону КХ, стартуем и не видим проинсерченного.

хм, а что какая-то буква из ACID соблюдается в КХ ? кейс очень простой, делаем insert, видим OK, тут же посылаем kill -9 демону КХ, стартуем и не видим проинсерченного.

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

хм, а что какая-то буква из ACID соблюдается в КХ ? кейс очень простой, делаем insert, видим OK, тут же посылаем kill -9 демону КХ, стартуем и не видим проинсерченного.

Емнип, неделю назад тут отвечали, что ответ 200 ОК означает таки сохранение на ноде.

Юзает кто-нибудь Tableau Server на линуксе в связке с ClickHouse?

У меня это говнище нивкакую не заводится

Я ОРУ!

yandex/ClickHouse was tagged: v18.6.0-stable Link: https://github.com/yandex/ClickHouse/releases/tag/v18.6.0-stable Release notes: Auto version update to [18.6.0] [54401]

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

Господа, пытаюсь получить суммарную скорость чтения с дисков: http://paste.org.ru/?b8oeay Либо я что-то не понимаю, либо runningDifference как-то странно работает.

Господа, пытаюсь получить суммарную скорость чтения с дисков: http://paste.org.ru/?b8oeay Либо я что-то не понимаю, либо runningDifference как-то странно работает.

Попробуйте в подзапросе сделать ORDER BY datetime, а уже над результатом подзапроса выполнить runningDifference

Хм... Так работает. Осталось сделать, чтоб ещё и для N хостов в IN сработало...

Привет, товарищи. Вопрос: в каком случае КХ будет быстрее искать? - поиск гуида в строке ( position("guid1,guid2,guid3", "guid2") ) - поиск гуида в массиве строк ( has(["guid1","guid2","guid3"], "guid2") )

Привет. Есть 2 реплики с таблицей ReplicatedMergeTree. Хочу выполнить удаление партиции: ALTER TABLE table ON CLUSTER cluster DROP PARTITION 'partition'. Возвращается ошибка "Password required for user default". Мне понятно что тот сервер, на котором я выполняю запрос не является лидером, но в конфигурации кластера я задал для каждой реплики user и password (к тому же user не называется default). В users.xml так же присутствует используемый пользователь. Версия Clickhouse 1.1.54388. Подскажите пожалуйста, в чем может быть проблема?

Привет, товарищи. Вопрос: в каком случае КХ будет быстрее искать? - поиск гуида в строке ( position("guid1,guid2,guid3", "guid2") ) - поиск гуида в массиве строк ( has(["guid1","guid2","guid3"], "guid2") )

Мы в таком случае заменили гуиды на инты (есть отдельный словарь) и используем второй вариант с массивами

Тяжело от гуидов уйти к сожалению, все ими пронизано.

подскажите, а есть ли какой-нибудь аналог transform, но который в качестве правил преобразовани результаты запроса? Надо заменить несколько значений

Тяжело от гуидов уйти к сожалению, все ими пронизано.

а в 2 uint64 преобразовать не получится?

Привет, товарищи. Вопрос: в каком случае КХ будет быстрее искать? - поиск гуида в строке ( position("guid1,guid2,guid3", "guid2") ) - поиск гуида в массиве строк ( has(["guid1","guid2","guid3"], "guid2") )

Второй вариант лучше.

а в 2 uint64 преобразовать не получится?

как вариант, другими словами 2 uint64 дешевле строкового гуида? Я просто помню постулаты КХ - храните строками если надо, он справится

Второй вариант лучше.

понял. предложенные преобразования guid -> int коснутся объема данных точно, а производительность сильно улучшит?

я не знаю, надо проверять. преобразование-то не бесплатное будет.