Индекс Cassandra SASI или материализованное представление — повышение производительности

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

У меня есть таблица с 4 полями - id, user, status, entryTime.

Я записываю в эту конечную точку около 100 раз каждые 10 секунд, то есть в среднем 10 операций записи в секунду.

Первичный ключ — user, а ключ кластеризации — entryTime and id.

У меня есть конечная точка, где мне нужно получить все записи между определенным entryTime для конкретного пользователя, например, для пользователя с идентификатором 1, где entryTime больше 2019-06-04T07:58:28.000Z и меньше 2019-06-04T08:58:28.000Z.

Другая конечная точка — это то, где я должен получать определенные status для конкретного пользователя.

Лучше ли создать представление материализации для второй конечной точки (где мне нужно получить статус) с разными ключами или добавить индекс SASI?

Поскольку таблица также часто обновляется и часто записывается, из того, что я читал, запись занимает около 10% производительности, но применимо ли это ко всем таблицам, которые часто читают/записывают?

Существуют ли какие-либо контрольные точки для дальнейшего использования, которым я могу следовать, чтобы определить, следует ли мне использовать материализованное представление или индекс SASI?


cassandra express-cassandra
person Patiss    schedule 05.06.2019    source источник
comment
Если вы всегда указываете пользователя, зачем вам что-то? Вы не указываете идентификатор пользователя во втором запросе? Когда вы говорите «пользователь» в первом запросе, вы указали, что использовали id = 1, разве вы не делаете это и для своего второго запроса? Если да, то вам ничего не нужно.   -  person Jim Wartnick    schedule 05.06.2019
comment
Да, но я не могу получить записи с определенным статусом, если не использую allow_filtering. Таким образом, у меня остается два варианта: либо создать новое материализованное представление, либо индекс SASI. Что будет лучше в моем случае?   -  person Patiss    schedule 05.06.2019
comment
У меня нет опыта работы с индексами SASI, однако я могу сказать вам, что со столбцом STATUS, и я предполагаю, что статус строк изменится, если вы создадите MVIEW с этим в качестве ключа раздела (так что вы может фильтровать по нему), каждый раз, когда изменяется статус в основной таблице, MVIEW будет выполнять DELETE, за которым следует INSERT (также с использованием поиска). С вашей нагрузкой (10 записей в секунду - не знаю, сколько из них ОБНОВЛЕНИЙ), это может быть проблематично для MVIEW. Мы используем MVIEWS, но нагрузка невелика. Запросы работают очень хорошо на них. Не уверен, что это поможет...   -  person Jim Wartnick    schedule 06.06.2019
comment
@JimWartnick, это точно. Спасибо, что разъяснили это! Следует ли использовать материализованные представления для таблиц, которые не обновляются часто?   -  person Patiss    schedule 06.06.2019
comment
Я думаю, что это помогает, но не требование. Просто помните, что Cassandra сначала вносит изменения в базовую таблицу, а затем распространяет их на MVIEW. Таким образом, применяются те же проблемы репликации. Кроме того, MVIEW может пропустить изменения, что приведет к рассинхронизации. Единственный способ исправить это — перестроить MVIEW. Что хорошо в MVIEW, так это то, что он ДЕЙСТВИТЕЛЬНО позволяет вам иметь обновляемый/изменяемый столбец как часть ключа раздела, что не разрешено для отдельной таблицы. Недостатком является то, что он выполняет дополнительную операцию (опять же, удаление с последующей вставкой). Это может вызвать дополнительную нагрузку   -  person Jim Wartnick    schedule 06.06.2019
comment
Потрясающе, спасибо за объяснение. Хотите добавить ответ с приведенным выше резюме комментариев?   -  person Patiss    schedule 07.06.2019

Ответы (1)


arrow_upward
1
arrow_downward

У меня нет опыта работы с индексами SASI, однако я могу сказать вам, что со столбцом STATUS, и я предполагаю, что статус строк изменится, если вы создадите MVIEW с этим в качестве ключа раздела (так что вы может фильтровать по нему), каждый раз, когда изменяется статус в основной таблице, MVIEW будет выполнять DELETE, за которым следует INSERT (также с использованием поиска). С вашей нагрузкой (10 записей в секунду - не знаю, сколько из них ОБНОВЛЕНИЙ), это может быть проблематично для MVIEW. Мы используем MVIEWS, но нагрузка невелика. Запросы работают очень хорошо на них. Не уверен, что это помогает

@JimWartnick, это точно. Спасибо, что разъяснили это! Следует ли использовать материализованные представления для таблиц, которые не обновляются часто?

Я думаю, что это помогает, но не требование. Просто помните, что Cassandra сначала вносит изменения в базовую таблицу, а затем распространяет их на MVIEW. Таким образом, применяются те же проблемы репликации. Кроме того, MVIEW может пропустить изменения, что приведет к рассинхронизации. Единственный способ исправить это — перестроить MVIEW. Что хорошо в MVIEW, так это то, что он ДЕЙСТВИТЕЛЬНО позволяет вам иметь обновляемый/изменяемый столбец как часть ключа раздела, что не разрешено для отдельной таблицы. Недостатком является то, что он выполняет дополнительную операцию (опять же, удаление с последующей вставкой). Это может вызвать дополнительную нагрузку

person Jim Wartnick    schedule 07.06.2019