(account, date, id)

id порядка 2 тысяц date 5-10

data вперед

У меня сейчас в пк всего три колонки, дата в самом начале стоит, потом все остальное

дата это включая день или только месяц?

мне наверное тоже ее логично вначала поставить тк ее вариативность меньше чем у остальных

Дата включя день

Все таки рекомендую вот эту статью почитать https://groups.google.com/forum/#!topic/clickhouse/eUrsP30VtSU. Алексей тут очень подробно рассказывает как работают ПК в КХ

Это даже не статья, а ответ )

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

пошел читать, спсб

Это как напихать в мускуль 10 индексов и писать туда тонну данных и не понимать почему скорость вставки данных просела )

Так понимаете было пы понятно если бы скорость просела

меня пугает что оно умерло вовсе

вставлять не дает

мержи не идут

опримизация не помогает

что в тако случае на проде делать?

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

Я даже таблици дропнуть пол часа не мог

засыпало лог ошибками

ок

И из-за того, что там таймштамп и порядка 40 миллионов строк вставляется за минуту, то операция достаточно тяжелая )

я все понимаю, но ложиться без возможности восстановления не должно

Это безусловно так, да )

надеюсь мы поняли друг друга я возможно неправильно использовал неправильно сконфигурировал при всем при этом 1 сервер работал как часы даже с временем в ключе без вопросов неделю как только сделал кластер все поотваливалось Так что я пока очень скептически отношусь к дате в ключе И мне интересно неужели разработчикам КХ не итнересно почему 1 нода работает а 3-4 нет :)

У многих тут кластера работают на ура

"Так что я пока очень скептически отношусь к дате в ключе" - зря, это придумали разработчики CH, а им виднее

Это все хорошо но объяснить почему работал 1 а не работают 4 в кластере никто не может

Создайте в google group или на гитхабе CH описание проблемы, думаю тогда разработчики пояснят

Хорошии совет спасибо

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

А можно как-то производительность синхронизации реплик увеличить? А то вот это все время растет queue_size: 1077 inserts_in_queue: 900 merges_in_queue: 177

сеть и процессор почти не загружены

queue_size: 3228 inserts_in_queue: 2684 merges_in_queue: 544 И все сдохло опять Сейчас писал не в распределеннют таблицу а в локальные 4 через лоад балансер

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

в этом тесте нет 5 мин назад запустил с такой структурой

CREATE TABLE IF NOT EXISTS measures ( account UInt32, id UInt32, date Date, timestamp UInt32, value Float32, tags Nested ( name UInt32, value UInt32 ) ) Engine = ReplicatedMergeTree('/clickhouse/tables/01/measures', '1',date, (date, account, id), 8192);

надо подождать теперь часа 2

в прошлый раз легло где-то через 2-2.5

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

не поделитесь, как вы хотите выборки по tags делать? Это фулскан будет, т.к. они не могут быть в ключе.

так запрос же есть вверху

филскана нет вроде как

по крайней мере запросы отрабатывают быстро

и кол-во обработанных строк говорит что не фулскан

м, ну имею ввиду если в запросе вообще не будет полей из 1 pkey или если запрос по pk все равно вернет тонну данных

или такого не будет

скажем получить все уник таги

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

мне такие запросы не надо

а так да они будут фулскан

я на это сознательно иду

понял, спс

Тем кто советовал убрать время из ключа будет интересно наверное было 2400 rows in set. Elapsed: 0.043 sec. Processed 3.17 million rows, 170.50 MB (73.01 million rows/s., 3.92 GB/s.) стало 966 rows in set. Elapsed: 0.642 sec. Processed 16.49 million rows, 823.10 MB (25.67 million rows/s., 1.28 GB/s.) Видно что просяду я неплохо по производительности, я бы даже сказал неприемлемо (кратно количество строк для сканирования возросло)

А запрос какой?

SELECT (avg(value)), toInt64(timestamp/60)*60 as granularity FROM Measures_Distributed where account=169 and id=109 and arrayElement(tags.value,indexOf(tags.name,4))=11724 and date>'2017-08-01' group by granularity order by granularity

+ таймстампы

Только сейчас заметил, что в первом случае прочитано меньше строк

Попробуйте prewhere date > '2017-08-01'

и убрать date из where

ок

SELECT (avg(value)), toInt64(timestamp/60)*60 as granularity FROM Measures_Distributed where account=169 and id=109 and timestamp>1501664400 and timestamp<1501837200 and arrayElement(tags.value,indexOf(tags.name,4))=11724 and date>'2017-08-01' group by granularity order by granularity 535 rows in set. Elapsed: 0.223 sec. Processed 8.17 million rows, 519.13 MB (36.62 million rows/s., 2.33 GB/s.) SELECT (avg(value)), toInt64(timestamp/60)*60 as granularity FROM Measures_Distributed prewhere date>'2017-08-01' where account=169 and id=109 and timestamp>1501664400 and timestamp<1501837200 and arrayElement(tags.value,indexOf(tags.name,4))=11724 group by granularity order by granularity 535 rows in set. Elapsed: 0.267 sec. Processed 8.15 million rows, 518.63 MB (30.50 million rows/s., 1.94 GB/s.)

не помогло

Ну как не помогло :) В 2.5 раза быстрее заработало )

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

И не совсем понимаю профита от toInt64(timestamp/60)*60

ERROR: S client not available

это ни на что не влияет

осталось как мусор

Оооо, я вижу там timestamp в where

Пропустил

это плохо?

3 мин как остановлена вставка а колво все пляшет

ubuntu@pprod-spm-ch-3:/mnt/local$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 805047373 805047373 805047373 ubuntu@pprod-spm-ch-3:/mnt/local$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 805047373 805047373 811021532 ubuntu@pprod-spm-ch-3:/mnt/local$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 805047373 805047373 805047373 ubuntu@pprod-spm-ch-3:/mnt/local$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 811021532 805047373 805047373 ubuntu@pprod-spm-ch-3:/mnt/local$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 805047373 805047373 811021532 ubuntu@pprod-spm-ch-3:/mnt/local$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 805047373 805047373 805047373

Ппц, оно сойдетс или нет ваши ставки, ахаха ubuntu@pprod-spm-ch-3:/mnt/local$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 811021532 805047373 805047373 ubuntu@pprod-spm-ch-3:/mnt/local$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 811021532 805047373 805047373

Всем привет. Подскажите пожалуйста, в чем причина такой ошибки при установке? (ubuntu16)

Там вроде clickhouse-server-base если не ошибаюсь.

Посмотри в выводе apt search clickhouse-server

Всем привет. Подскажите пожалуйста, в чем причина такой ошибки при установке? (ubuntu16)

https://clickhouse.yandex/docs/ru/getting_started/index.html#id3

Спецы по КХ, подскажите пожалуйста. Есть данные, у данных есть два поля, по которым хочется искать независимо друг от друга (иногда по первому полю, иногда по второму), искать хочется очевидно как можно быстрее. Какую лучше использовать схему в КХ? Составной ключ врядли поможет. Делать 2 таблицы с разными primary keys и в итоге дублировать данные? Еще как-то?

Спецы по КХ, подскажите пожалуйста. Есть данные, у данных есть два поля, по которым хочется искать независимо друг от друга (иногда по первому полю, иногда по второму), искать хочется очевидно как можно быстрее. Какую лучше использовать схему в КХ? Составной ключ врядли поможет. Делать 2 таблицы с разными primary keys и в итоге дублировать данные? Еще как-то?

Поиск по составному все равно быстрее будет чем фуллскан.

если у вас два вида range запросов, то быстрее всего будет две таблицы. а вы пробовали хотя бы один вариант?

но вообще надо смотреть, какие данные, какие запросы. может вам проще две вьюхи сагрегиовать сразу.

сейчас две таблицы, всё летает, но смущает дублирование данных

Покажите пример запросов

Поиск по составному все равно быстрее будет чем фуллскан.

поэтому пока остановились на двух таблицах с разными PK

память дешевая, а геморрой дорогой.

Покажите пример запросов

SELECT ftype, count() AS c FROM ... WHERE vexists = 1 GROUP BY ftype ORDER BY c DESC такое например

в where может быть любое из двух интересующих полей

память дешевая, а геморрой дорогой.

+1. Авторы CH советую дублировать данные, если это улучшает производительность

Ззначит мы на верном пути :)

спасибо

/subscribe

Ззначит мы на верном пути :)

Так же возможно вам поможет это https://clickhouse.yandex/docs/ru/table_engines/aggregatingmergetree.html

спасибо, посмотрю

Добрый день , может есть у кого TCP коннектор для php ?

Добрый день , может есть у кого TCP коннектор для php ?

На сколько мне известно именно TCP нет. По крайней мере я не встречал

Добрый день , может есть у кого TCP коннектор для php ?

А чем вас curl не устраивает ?