Запись производительности Cassandra с помощью Kundera ORM

Question

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

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

Немногие характеристики моей системы

(1) 99% от записи - 1% читают (2) высокую пропускную способность записи (примерно 30000 событий в секунду, каждое событие, имеющее примерно 100 атрибутов в нем) (3) Динамический характер данных. Не подходит для фиксированной схемы.

Эти характеристики заставляют меня думать о Apache cassandra в качестве опции либо с функцией расширения, либо с целью сохранения моих атрибутов.

Я сделал несколько выборок с единственным узлом и ORM Kundera для записи событий на карту и максимальную пропускную способность записи 1500 событий в секунду/поток. Я могу масштабировать его с большим количеством потоков и узлов кассандры.

Но, это близко к тому, что я должен получать от вашего опыта? Немногие из доступных тестов на сетях выглядят запутанными .. (Я на cassandra 2.0, с Kundra ORM 2.13)

Answer 1

Вы пытались пройти через cassandra.yaml и cassandra-env.sh? настраивая кластер узлов, это очень важно для оптимизации производительности, вы также можете взглянуть на параметры ОС, вам также необходимо убедиться, что память подкачки равна 0. Это помогло мне увеличить производительность кластера.

Answer 2

Кажется, что ваша модель данных Cassandra «использует» тип коллекции map. Если это отвечает на вашу озабоченность по поводу «Динамического характера данных. Не подходит для фиксированной схемы». Существуют и другие способы.

CREATE TABLE user_events (event_time timeuuid PRIMARY KEY, атрибуты карты, session_token текст, состояние текста, системный текст, текст пользователя)

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

CREATE TABLE user_events(
    event_time TIMEUUID, 
    session_token TEXT STATIC, 
    state TEXT STATIC, 
    system TEXT STATIC, 
    USER TEXT STATIC, 
    attribute TEXT, 
    value TEXT, 
    PRIMARY KEY(event_time, attribute) 
); 

Это делает event_time и attribute части первичного ключа, event_time ключа раздела и attribute является ключом кластеризации.

Часть STATIC делает эти данные «свойствами» событий и хранится только один раз для каждого раздела.