Прежде чем создавать билет улучшения Cassandra, мне любопытно, какое техническое ограничение не позволяет запрашивать столбцы без вторичных индексов на них, даже если указан весь первичный ключ (partition_key и clustering_key)? С PK Cassandra уже находится в определенной строке раздела и может избежать возврата строки на основе фильтрации значений столбца на месте. Гораздо больше пользы, если это можно сделать, указав только ключ раздела, вместо того, чтобы возвращать так много широких строк и фильтровать на клиенте, он может фильтровать сами данные на сервере и возвращать только соответствующие строки напрямую с РАЗРЕШИТЬ ФИЛЬТРАЦИЯ - этот клиент знает риск?
select * from CF where partition_key = foo and clustering_key = bar and non_indexed_column = baz
Когда вы используете вторичный индекс с запросом ключа раздела, план выполнения показывает, что он сначала использует ключ раздела, чтобы добраться до строки, и только затем использует один ключ раздела сканирования индекса, если данные существуют, а затем, возможно, фильтрацию на месте, чтобы вернуть взаимно общие данные в любом случае. Когда вы используете несколько вторичных индексов, есть оптимизация, чтобы сначала выбрать наиболее оптимальный.
Я понимаю, что дерево вторичного индекса по умолчанию поддерживается в памяти, как и любая другая структура данных индекса, и индекс на самом деле является обратным поиском семейства столбцов по ключу раздела, индексирующему только локальные данные в том же узле.
Мой вопрос связан с «большими техническими накладными расходами или ограничениями», когда Cassandra не может сделать это вместо того, чтобы передавать его клиенту, когда указан весь первичный ключ?
Execution Plan summary with Primary Key and Secondary Index:
Seeking to partition beginning in data file | xyz
Executing single-partition query on indexed_column_idx
Seeking to partition indexed section in data file
Merging data from memtables and 15 sstables
Execution Plan summary with just the Secondary Index:
Executing indexed scan
Executing single-partition query on indexed_column_idx
...
Оба из них имеют смысл. Вторичные индексы ограничены столбцами с высокой кардинальностью, и тогда вы не можете создать много вторичных индексов, не злоупотребляя ими, и вы также не можете создавать новые CF обратного просмотра по индексу, не беспокоясь о пространстве и согласованности.
