всем привет. я все еще мучаюсь с выбором хранилища под юзкейс.
Смысл такой - у нас есть несколько потоков событий:
- платежи
- заказы
- еще чего-нибудь
Они льются из кафки и читаются спарком.
Дальше их нужно положить в структуру по айдишнику клиента, и апдейтить если прилетают новые значения.
Пример структуры данных:

{
  “some_user_id”:
    payments: [
       {“payment_id”: 100, “payment_value”: 120}
    ],
    orders: [
       {“order_id”: 200, “order_item”: [“something”]}
    ]
 }

Прилетающий апдейт может, например, обновить данные вот так:

{“order_id”:200, “order_item”: [“something”, ”something_else”]}

А вот реквестить эти данные снаружи уже будут с агрегацией до клиента, например как-то так:

select count(orders) from data where user_id=“some_user_id”

Получается что нужно kv-хранилище со вложенными индексами, причем хорошо масштабируемое (данных прибывает много, уже >>1TB и прирост около 0.5TB в год).
Я смотрю в сторону HBase, но кажется что у него с nested index все прямо не очень. Какое хранилище подойдет под такой кейс?

Вроде обсуждали Kafka и DynamoDB для этого, чем не подошли? И я не понял зачем нестед индекс нужен.. А ещё в твоём примере можно обновлять и хранить счётчик заказов прям в строке и доставать без агрегации

В динаму не влезают записи - под одним ключом может быть до 16мб, а в динаме ограничение в 512кб(

В динаму не влезают записи - под одним ключом может быть до 16мб, а в динаме ограничение в 512кб(

А если phoenix поверх hbase? Плюсом идут вторичные индексы и jdbc

Вот этот вариант мы рассматриваем - а там можно вложенные структуры иметь?

Так себе дизайн с такими значениями, может разбить запись под скан или нормализовать?

Вот этот вариант мы рассматриваем - а там можно вложенные структуры иметь?