Индекс Cassandra SASI или материализованное представление - улучшение производительности - PullRequest
Новая
       25

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

0 голосов
/ 05 июня 2019

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

У меня есть таблица с 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 для конкретного пользователя.

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

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

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

1 Ответ

1 голос
/ 07 июня 2019

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

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

Я думаю, что это помогает, но не является обязательным требованием.Просто помните, что Кассандра сначала вносит изменения в базовую таблицу, а затем распространяет ее в MVIEW.То же самое относится и к репликации.Кроме того, MVIEW может пропустить изменения, в результате чего он не синхронизирован.Единственный способ исправить это - восстановить MVIEW.Что приятно в MVIEW, так это то, что он позволяет вам иметь обновляемый / изменяемый столбец как часть ключа раздела, что недопустимо для отдельной таблицы.Недостатком является то, что он выполняет дополнительную операцию (снова удалите, а затем вставьте).Это может вызвать дополнительную нагрузку

...