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

Отдельный ClickHouse с дисками под копию данных все же лучший вариант. Так и DDL для таблиц поменяете и данные не потеряете. Да и не долго (или не дорого арендовать под это железку)
вот гонял только вчера через весь земной шарик с не самым лучшим каналом обычный insert ... select ... from remote(old_cluster) и проблем не было. Объем данных чуть больше 1ТБ.

clickhouse1 :) 0 rows in set. Elapsed: 14037.734 sec. Processed 891.71 million rows, 493.64 GB (63.52 thousand rows/s., 35.17 MB/s.) 
clickhouse2 :) 0 rows in set. Elapsed: 39614.883 sec. Processed 2.56 billion rows, 1.47 TB (64.61 thousand rows/s., 37.09 MB/s.) 
clickhouse3 :) 0 rows in set. Elapsed: 62284.319 sec. Processed 3.95 billion rows, 2.29 TB (63.41 thousand rows/s., 36.73 MB/s.) 
clickhouse4 :) 0 rows in set. Elapsed: 67793.667 sec. Processed 4.11 billion rows, 2.39 TB (60.62 thousand rows/s., 35.32 MB/s.) 
clickhouse5 :) 0 rows in set. Elapsed: 58010.484 sec. Processed 3.98 billion rows, 2.28 TB (68.53 thousand rows/s., 39.34 MB/s.)

Привет, делаю сервис аналитики, коллеги из Data Engineers посоветовали Клик, с колоночными ни разу не работал и не знаю как проектировать базу.
В общем, паршу товары с одного сайта, их, на вскидку, с десяток миллионов, к 1 товару раз в день надо записывать цену, цену до скидки, остатки, дельту остатков (чтоб не вычислять в запросах на чтение), сумму продаж с момента прошлой записи, оценки с каждого отзыва к товару и их среднее (уже вычислено). Таких записей будут миллиарды, записываться пачками по 100к (или больше). Запросы будут чисто аналитические, требуется чтоб они работали в риалтайме.
Не знаю как это всё должно быть организовано, буду рад помощи и ссылкам, куда и что читать по теме.

Если что, работаю через infi.clickhouse_orm для питона

>но как быть с движком?
какой объем в ГБ? Репликация есть? Сколько нод КХ?

>потому как нет возможности добавлять еще диски...
что значит нет? Как у вас устроены диски и что у вас есть?

сейчас полный объем 850 гиг, репликации нет, нода одна

настроен raid10 из 4 дисков по 512 гиг, все слоты заняты, нет возможности добавлять новые диски(

ну я не знаю что у вас в массиве хранится, вы понимаете что результат разный ?

SELECT
    hasAll(x, ['кремль']) AS a,
    arrayExists(i -> (i LIKE '%кремль%'), x) AS b
FROM
(
    SELECT ['гугг, кремльб ппппэ'] AS x
)

┌─a─┬─b─┐
│ 0 │ 1 │
└───┴───┘

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

ОК и TTL куда вам данные пересет?

одна широкая таблица, партиции по месяцу от поля с датой которая будет участвовать в where, в первичный индекс (order_by) поле которое будет участвовать в where

А как с товаром связывать? Там статичные данные, которые не надо обновлять (типа описания и ссылки)

одна широкая таблица, одна, в одну

либо external dictionaries

я вообще думал подмонтировать через nfs и туда старые данные отправлять

Кажется словарь нужен, в той конфе его упоминали, и я так понимаю, он в озу работает? Можно ссылку на доку?

ясно, ну в общем не факт что это будет работать ttl+nfs и вам в общем надо думать дальше как переехать на новый движок

на самом деле способ конвертации таблиц есть, если вы c++ разработчик, вы найдете утилиту в коде КХ

Сам нашел, но спасибо)
Такой вопрос, что в него кидать, товар или инфу по нему (цены итд)?

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

но вообще как бы вы делали обновление движка? какие действия бы проводили?

А если id товара просто сохранять с его метаданными? А товар в отдельной таблице хранить (по ним редко будут запросы)

в Клике нет ФК, не знаю ок ли это или нет

>можете поделиться ссылкой на код про утилиту
принципиально нет, она для опытных c++ разработчиков, они ее за секунду найдут , тупо прочитав make

>но вообще как бы вы делали обновление движка
insert select на вашем месте

я использовал engine=Merge и натурально переехал, ничего не делая, со временем дропнув старые данные.