два кристалла по 48 ядер

а сколько стоит?)

около 300 баксов/месяц у packet.net

у scaleway можно решительно дешевле взять если поиграться, там 16ти ядерные машинки есть по 34 евро где-то

интересно

неплохо

Но оно же не для БД...

а с чем по производительности можно эту машинку сравнивать?

пару современных зеонов обойдут?

да даже не современных

пару какихнить 2680v2

у нас на работе была статья, но там квалкоммы - https://blog.cloudflare.com/arm-takes-wing/

У вас и вторая статья была https://blog.cloudflare.com/neon-is-the-new-black/

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

почему? отдельные ядра не так и плохи, в районе 2ггц частота

CH же отлично скалится по числу ядер

собственно отсюда и интерес =)

• 78K-Icache and 32K-D cache per core, 16 MB shared L2

мне кажется вот это будет узким местом для БД

А есть ли планы добавить бинарные сборки для ARM64/aarch64, пожалуйста?

если очень надо - проще собрать прямо там. Собираемость на arm64 регулярно проверяется

Ну и скорость каждого арм ядра в несколько раз ниже чем у x86

@proller а как вообще вам интересно на арм собираться? Машины под тесты раздают в ряде проектов

всмысле? Практической пользы нет, а for fun все собирается и работает на 40$ платах

я скорее про серьезные машины, что я привел выше. платы за 40 баксов, конечно, фан

ну и собирать на плате за 40 баксов - будет вечность

собственно, сборочки бинарные поэтому хочется

собственно конкретно вот эти ребята: https://www.worksonarm.com/

дают железо серьезным опенсорс проектам, кому интересна поддержка ARM64 под CI и тестовые нужды

там глядишь, и на Raspberry запустим)

почему бы и нет, CH идеален для IOT

метрики там всякие укладывать/логгировать, IOT контроллеры, огромный рынок)

ну и собирать на плате за 40 баксов - будет вечность

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

там глядишь, и на Raspberry запустим)

если есть 2г рам - то можно прямо сейчас запустить. но зачем?

просто тестовый стенд. кажется, больше незачем

вот тесты там не все проходят - есть различия с float и не только

вот это как раз плохо ?

А есть какой-то более общий аналог toUInt32OrZero? чтобы принимал аргумент вместо 0?

Добрый вечер! Подскажите, пожалуйста, есть ли в CH диспетчеризация запросов на чтение в рамках одного инстанса? Или же просто каждый запрос изолированно исполняется в отдельном треде, а там уж как получится

А есть какой-то более общий аналог toUInt32OrZero? чтобы принимал аргумент вместо 0?

есть ifNull() и toUInt32OrNull()

Спасибо

Приветствую всех! Птяница вечер, проблема с ждойнами возникла: мне нужно выполнить пару десятков разных запросов, каждый раз джойня с другой таблицей. Для этого сделал отдельную таблицу с движком join и одним полем url_hash. Выполняю запрос вида: SELECT redirect_to_url_hash AS url_hash FROM pages ANY INNER JOIN pages_uniq USING url_hash GROUP BY redirect_to_url_hash ругается Not found column url_hash in block. There are only columns: redirect_to_url_hash можно ли как то задать все таки алиас?

Есть запрос, и успешно выполняется: SELECT count() FROM t PREWHERE bububu; если добавить where (SELECT count() FROM t PREWHERE bububu WHERE row LIKE '%tututu%' запрос падает DB::Exception: Memory limit (for query) exceeded: would use 64.26 GiB (attempt to allocate chunk of 34359738368 bytes), maximum: 50.00 GiB: (while reading column row): (while reading from part ну и в общем известна причина, в некоторых строках в этом row, может лежать строка до 400МБ. При этом КХ смог это туда успешно записать, смержить, оно там давно успешно лежит. Вопрос. Можно-ли каким-то параметром уговорить select выполнится? Т.е. видимо проблема в том что select читает пачку (много строк за раз) из колонки, декомпрессит и тут ему не хватает памяти.

Приветствую всех! Птяница вечер, проблема с ждойнами возникла: мне нужно выполнить пару десятков разных запросов, каждый раз джойня с другой таблицей. Для этого сделал отдельную таблицу с движком join и одним полем url_hash. Выполняю запрос вида: SELECT redirect_to_url_hash AS url_hash FROM pages ANY INNER JOIN pages_uniq USING url_hash GROUP BY redirect_to_url_hash ругается Not found column url_hash in block. There are only columns: redirect_to_url_hash можно ли как то задать все таки алиас?

попробуйте ANY INNER JOIN pages_uniq as url_hash USING url_hash

не получилось

сейчас завел с SELECT url_hash, 1 as vtype, value FROM ( select redirect_to_url_hash as url_hash, toUInt64(COUNT(*)) AS value from pages where toStringCutToZero(redirect_to_url_hash) != '' AND status_code = 301 GROUP BY redirect_to_url_hash ) ANY INNER JOIN pages_uniq USING url_hash

точнее, непонятно откуда join из какой таблицы?

join идет с таблицей create table pages_uniq ( url_hash FixedString(40) ) ENGINE = Join(ANY, INNER, url_hash)

А ClickHouse умеет select в json'е отдавать?

А ClickHouse умеет select в json'е отдавать?

https://clickhouse.yandex/docs/ru/single/#json

yandex/ClickHouse was tagged: v1.1.54380-stable Link: https://github.comhttps://github.com/yandex/ClickHouse/releases/tag/v1.1.54380-stable Release notes: v1.1.54380-stable

Всем привет! Вопрос такой - если дефолтную партицию (месяц) уменьшить до дня, скажется ли это на скорости поиска?

Зависит от запросов - если они будут из одной патриции (дня) то будет даже быстрее за счёт меньшего размера

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

И надо ли при селектах указывать партицию как-либо?

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

Это на оба вопроса "да" или на какой-то из них?

Ключ партицирования - это date?

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

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

Всем привет! Вопрос такой - если дефолтную партицию (месяц) уменьшить до дня, скажется ли это на скорости поиска?

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

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

Спасибо!

Совсем дурацкий вопрос, но как в clickhouse-client делать перевод на следующюю строку?

коллеги, добрый день! подскажите, детерминировано ли поведение для ReplacingMergeTree CREATE TABLE Test ( date Date, key Int32, value Int32, version UInt8 ) ENGINE = ReplacingMergeTree(date, (key, value), 8192, version) вставляю строки insert into Test values(today(), 1, 1, 0); insert into Test values(today(), 1, 2, 0); дальше хочу получить значение последней вставки делаю так: select argMax(value, version) from Test; всегда ли я буду получать значение 2, или могу и на 1 "налететь"? или есть какой-то ещё способ достать заведомо последние значения из ReplacingMergeTree?

коллеги, добрый день! подскажите, детерминировано ли поведение для ReplacingMergeTree CREATE TABLE Test ( date Date, key Int32, value Int32, version UInt8 ) ENGINE = ReplacingMergeTree(date, (key, value), 8192, version) вставляю строки insert into Test values(today(), 1, 1, 0); insert into Test values(today(), 1, 2, 0); дальше хочу получить значение последней вставки делаю так: select argMax(value, version) from Test; всегда ли я буду получать значение 2, или могу и на 1 "налететь"? или есть какой-то ещё способ достать заведомо последние значения из ReplacingMergeTree?

С argMax всегда получите последнее значение

Можно сделать и с final

Но может быть медленно

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

есть большое подозрение, что date, как ключ партиционирования, лучше класть в WHERE, а не PREWHERE в PREWHERE имеет смысл помещать "маленькую" колонку, например, интовую, которой нет в индексе, и условие по которой может сильно ограничить выборку

Можно сделать и с final

с final это как именно? select * from Test final; даёт все строки таблицы, а не только последнюю

Совсем дурацкий вопрос, но как в clickhouse-client делать перевод на следующюю строку?

Там был флаг -m для поддержки многострочных запросов

Совсем дурацкий вопрос, но как в clickhouse-client делать перевод на следующюю строку?

через \

есть большое подозрение, что date, как ключ партиционирования, лучше класть в WHERE, а не PREWHERE в PREWHERE имеет смысл помещать "маленькую" колонку, например, интовую, которой нет в индексе, и условие по которой может сильно ограничить выборку

Дата и есть Int

с final это как именно? select * from Test final; даёт все строки таблицы, а не только последнюю

у вас PK (key, value), а replace идет по PK, иначе как КХ догадается какие записи надо реплейсить 1 , 2 != 1 , 1 вам надо ENGINE = ReplacingMergeTree(date, (key), 8192, version) но на самом деле разницы между final и argMax(value, version) по скорости не будет, это внутри насколько я понимаю одинаково примерно устроено.