Моделирование анализа финансовых данных в Apache Cassandra?

Question

Мне нужно смоделировать и хранить финансовые данные в Apache Cassandra.

Доступ к данным осуществляется по дате и бизнес-единицам, поэтому в настоящее время моя модель использует идентификатор даты и бизнес-единицы в качестве составной строки.

Я хочу использовать широкие ряды, чтобы я мог потянуть фигуры на целый день (и единицу) в одном запросе.

В любой день, для конкретного бизнес-единицы, мне нужно хранить серию более гранулированных срывов, как и (игнорировать цифры, они чисто иллюстративный):

| rowkey  | USD | GBP | JPY | etc ....  
|-------------|-------|------|------|----------  
| 31122014-1 | 112 | 3006 | 234 |  
| 31122014-2 | 3378 | -12.4| 998 |  
| 31122014-3 | -456 | 2034 | 127 | 

, а затем более подробная разбивка, используя соединение колонки:

| rowkey  | USD-D1 | USD-D2 | GBP-D1 | GBP-D2 | etc ....  
|-------------|--------|--------|--------|------------------  
| 31122014-1 | 65 | 54  | 175 | 29  | 
| 31122014-2 | 2003 | -6.4 | 603 | 349 | 
| 31122014-3 | -230 | -198 | -53 | 217 | 

А потом еще более подробную разбивку:

| rowkey  | USD-D1-X1 | USD-D1-X2 | USD-D1-X3 | USD-D2-X1 | etc ....  
|-------------|-----------|-----------|-----------|-----------|-------  
| 31122014-1 | 23  | 16  | 98  | 29  | 
| 31122014-2 | 389  | -3.2  | 237  | 119  | 
| 31122014-3 | -105  | -67  | -28  | 178  | 

Это лучший способ моделирования этих сбоев с использованием трех отдельных семейств столбцов (как показано здесь)?

Или имеет смысл хранить только наиболее гранулированную разбивку, а затем использовать некоторую форму агрегации столбцов (если она существует) для извлечения менее гранулированных наборов данных?

Я знаю, что агрегация Cassandra ограничена/не существует, я не нашел ничего в API, чтобы предложить, как я могу заполнить столбцы, подобные этому.

Я знаю, что мог бы выполнить агрегацию в уровне приложения, но тогда возникает вопрос о компрометации между получением ненужных данных, перемещением вычислительных издержек и сохранением дополнительных семейств столбцов. Я надеюсь, что Cassandra предоставит некоторый способ решения этого вопроса на уровне данных.

Answer 1

В зависимости от того, как вы хотите, вы хотите, чтобы данные были смоделированы вы можете

1. Используйте свое решение. В этом случае вы создаете семейство столбцов для получения более подробной информации.

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

Например: Если в соответствии с моделью данных, если строка ключ доступа всегда будет включать в себя валюту можно смоделировать его как этот

| rowkey  |currency|  
|---------------|--------| 
| 31122014-1,GBP| 112 | 

Obviou sly это значительно увеличит ваши данные для одного rowkey, но увеличит количество клавиш строки.

3. Вы можете использовать агрегацию, а также настраиваемые типы, которые позволяет использовать cassandra.

Рассмотрим следующий пример, прежде чем выбрать один из stategies

a. Distribution of the rows across nodes 
b. Sparse columns vs wide columns 
c. Effects on row cache (if you are going to turn it on) and key cache 
d. And the most important, your selection queries 

Answer 2

Я думаю, ваше решение может быть эффективным. Для Cassandra обычно лучше хранить данные в нескольких местах в зависимости от того, какие запросы вы ожидаете от него.

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

Для чего это стоит, это случай использования очень хорошо играет на сильные CQL, которые бы смоделировать его следующим образом:

CREATE TABLE finance0 (
    day DATE, 
    unit INT, 
    currency TEXT, 
    amount BIGINT, 
    PRIMARY KEY ((day, unit) currency) 
); 

CREATE TABLE finance1 (
    day DATE, 
    unit INT, 
    currency TEXT, 
    sorter1 TEXT, 
    amount BIGINT, 
    PRIMARY KEY ((day, unit) currency, sorter1) 
); 

CREATE TABLE finance2 (
    day DATE, 
    unit INT, 
    currency TEXT, 
    sorter1 TEXT, 
    sorter2 TEXT, 
    amount BIGINT, 
    PRIMARY KEY ((day, unit) currency, sorter1, sorter2) 
);