Всем салют! Дано: Aerospike cluster(7 nodes) с ~1B записией. Каждая запись

имеет следующуюю структуру:
PK Bin1 Bin2 Bin3 Bin4
----------------------------------------------------------------------------------------------------
uuid {ts: ...., uuid: "..."} {ts: ...., uuid: "..."} {ts: ...., uuid: "..."} {ts: ...., uuid: "..."}
Фактически, это отображение некоторого идентификатора в нашей системе на аналогичный идентификатор в другой системе.
Bin1, Bin2 ... BinN это индентификатор систем с которым ми работает.
Каждый PK может иметь от 1 до N отображений.

Проблема:
Возникла необходимость получить различного рода статистику по данным из aerospike, например:
1. сколько уникальных идентификаторов у нас есть для BinX
2. Сколько записей имеют BinA и BinB одновременно и сколько уникальных идентификаторов имеет BinA, BinB
4. Сколько уникальных идентификаторов было добавлено за определенный день и тд
3. Нужно также делать выгрузку из aerospike данных в произвольном формате

Чтобы ответить на все эти вопросы приходится писать свои пользовательские скрипты используя sdk. Осложняется все тем, что у нас не Aerospike Enterprise и поэтому некоторая функциональность просто недоступна, например, OPERATOR.

Вообщем, хотим попробовать сделать выгрузку из Aerospike в Clickhouse и на нем уже делать аналитику.
Предварительно схема будет такой:
PK String
Bin1Id String
Bin1TsYear Int
Bin1TsDay Int
Bin1TsHour Int
Bin1Uuid
...
BinNId String
BinNTsYear Int
BinNTsDay Int
BinNTsHour Int
BinNUuid
т.е. заранее создать N колонок в CH для каждого Bin и просто не заполнять те, для которых нет данных для конкретного PK


Нашел на GitHub issue Aerospike as dictionary source/layout, но к сожалению, ее закрыли из-за low demand.
Вопросы:
1. Насколько такая схема CH оправдана?
2. Насколько CH подойдет для таких задач где 1B уникальных значений?
3. Как лучше/эффективнее сделать partition key/sort key?
4. Был ли у кого-нибудь подобные задачи? Поделитесь плз свои опытом.
5. Как вообще организовать обновление/удаление записей, так как PK обновляются время от времени: могу обновляться uuid для конкретного bin, могут добавлять/удаляться bins. Здесь есть идеи использовать ttl по записят в CH, тогда можно примерно подсчитать сколько осталось жить записи в Aerospike и поставить нужное значение ttl при записи, тогда CH сам удалить старые записи... Но это решит только проблему удаления

1. Сложно понять, по входным данным какие именно вам запросы нужны и как будут растекаться данные по столбцам. 2. Кликхаус подойдёт, но в любом случае должны быть какие то столбцы с категориями, чтобы можно сделать ORDER BY и Primary Key 3. Обычно partition key делают по времени месяц/неделя/день всё зависит от количество данных приходящих в день . ORDER BY лучше делать на основе, что используются в главных запросах к таблицам и вносить это 4. Не знаю, впервые за 6 месяцев вижу что то подобное в чатике 5. Есть движок таблицы VersionedCollapsingMergeTree

1. Да, я и сам точно пока что не понимаю, т.к. буквально три запроса от заказчика поступило на подобие тех что перечислены в примерах. Но я точно знаю, что кол-во таких запросов на получение какой-то статиситики по данных в Aerospike будет расти и чтобы сэкономить время, - т.к. сейчас приходится постоянно все на коленке реализовывавть в виде самописных etl, - хочется сделать более мене нормальное решение которое позволит делать это в привычной форме. 2. Угу, буду еще думать что лучше выделить под primary/ order by 3. "всё зависит от количество данных приходящих в день" можно подробнее? какие вообще рекомендации на этот счет? 5. дзякуй, будем посмотреть

3. Первое надо зайти сюда, понять как хранятся данные и что такое парты, партиции, гранулы https://clickhouse.com/docs/ru/engines/table-engines/mergetree-family/mergetree/ . Дальше каждый парт максимально может вмещать в себя 100 Гигабайт ифнормации (парт часть партиции для чтения). Так же кликхаус читает по умолчанию в 8 потоков с дисков информацию. Чем больше парты тем хуже (я думаю так, потому что сложней производить слияние партов, обращения к большим партов)

Как вариант, можно хранить массивы (то есть вложенные структуры), чтобы не создавать непонятное количество колонок. А в массивах можно хранить уже, что угодно, включая кортежи, например.