Моя команда разрабатывает приложение, которое должно быстро хранить и читать большие объемы данных. Поэтому нас попросили использовать Кассандру.
Мы записали ожидаемые запросы и разработали таблицы на их основе. В четырех самых больших таблицах хранятся данные временных рядов, где ключ разделения состоит из полей a, b и c, а в качестве ключа кластеризации используется метка времени t.
К сожалению, клиент решил, что он хочет иметь возможность фильтровать данные в этих четырех таблицах, основываясь на любой комбинации этих полей - то, что мы не разрабатывали для нашего приложения. Теперь мы задаемся вопросом, как изменить таблицы и запросы, что представляет собой небольшую проблему, так как нам не хватает кого-то со значительным опытом работы с Кассандрой.
В качестве временного решения было использовано предложение «разрешить фильтрацию», но мы боимся потерпеть значительный удар по эффективности. Мы попытались построить серию материализованных представлений на основе таблиц, в которых ключ разделения состоит только из метки времени - семь представлений для каждой таблицы, три с ключом разделения, состоящим из поля a / b / c, еще три с ключами разделения ab / ac / bc, и последний с PK abc. Это не работает, поскольку Cassandra позволяет MV расширять свой ключ разделения только на одно поле над базовой таблицей и не позволяет создавать MV на MV. Мы рассматривали возможность добавления индексов для трех полей, но это кажется плохой идеей, поскольку поля a, b и c имеют мощность в диапазоне от десятков до десятков тысяч.
Что было бы лучшим решением в этом случае? Создание двадцати восьми - семи для каждой из четырех оригинальных таблиц - похоже на кошмар согласованности. Или мы должны просто отказаться от Кассандры и бороться, чтобы перейти к какой-то другой базе данных?