Это бесплатный сервак от Гугла. Для экспериментов пока хватает.

Для кликхауса это прям мало.

Да, потом можно будет проапгрейдить, но зато на нем сразу видны потенциальные неоптимальности.

Ну окей,
в общем другая идея
делать GROUP BY  f1, f2, intDiv(myfield,1000).
Потом с помощью функций высшего порядка удалять все не граничные значения и так повторять до результата через подзапросы

Вспомнил ещё runningDifference(), которую уже использовал когда-то. Это, кажется, то, что нужно.

всем привет
я только присматриваюсь к ClickHouse, прошу не пинать
что у меня есть:
redis в которьій я пишу ключи в разньіе базьі на одном сервере и ставлю ттл, ттл - некая привязка ко времени
хочу переехать на ClickHouse, но почитав я понял, что єто скорее база боольше для записи, чем для чтения.
сейчас у меня происходит так:
* некая авторизация пользователя путем внесения ключа с ттл или обновление ттл - єто операции записи - 1kqps
* проверка наличия ключа(некая аутентификация пользователя) - єто чтение из базьі - 4kqps
зачем переезжать на ClickHouse с Redis - хранить историю, логировать все

Стоит ли заморачиватся с переездом или смотреть историю по логам сервера?

Спасибо

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

а, хранить историю. ну хранить историю можно. а k-v лучше оставить где был. только со вставками по одной строке надо будет что-то порешать.

спасибо

Кликхаус скорее про аналитические запросы

А можно мне сделать чтобы GROUP BY на огромных таблицах не ел оперативку как не в себя?

😉

можно max_bytes_before_external_group_by

Сложность по памяти всё-равно останется линейной относительно числа записей.

Вы хотите делать групбай не используя память?
Вроде была оптимизация груп бай по индексу.
Если хотите более конкретный ответ, задайте более конкретный вопрос...

Ну вот, сообщение на которое я отвечал удалили и стало не так смешно.

Проблемы возникают уже после max_bytes_before_external_group_by, когда нужно слить воедино все сброшенные на диск двухуровневые хеш-таблицы. Что само по себе может и интересная задача, но решается она тем, что в память читается 1/256 от каждой сброшенной хеш-таблицы для каждого сливающего потока. Т.е. N/256 записей, где N размер исходной таблицы.

Кто-нибудь может помочь спроектировать БД на основе кликхауса? Есть исходные данные 3 таблицы, понимание вьюшек которые должны быть на выходе. Оплачу сколько скажите) или порекомендовать кого-то) спасибо

ок, уменьшите количество потоков в этой стадии

ну даже если их уменьшить до одного, всё равно останется 1/256 исходной таблицы