SELECT DISTINCT cql игнорирует предложение WHERE

Так происходит, потому что в Cassandra CQL DISTINCT предназначен для возврата только ключей раздела (строки) вашей таблицы (семейства столбцов) ... которые должны быть уникальными. Следовательно, предложение WHERE может работать только с ключами раздела при использовании с DISTINCT (что в вашем случае не очень полезно). Если вы уберете DISTINCT, тогда WHERE можно будет использовать для оценки ключей кластеризации (столбца) внутри каждого ключа раздела (хотя и с ALLOW FILTERING).

Я чувствую себя обязанным упомянуть, что ALLOW FILTERING - это не то, чем вы должны много заниматься ... и определенно не в производстве. Если вам нужно часто выполнять этот запрос (запрос событий для userids после определенного timestamp), я бы предложил вместо этого разделить ваши данные по event_type:

PRIMARY KEY (event_type, "timestamp", userid)

Тогда вы сможете выполнить этот запрос без ALLOW FILTERING.

SELECT userid FROM events WHERE event_type='toto' AND timestamp > '1970-01-17 09:07:17+0100'

Если вы ничего не знаете о вашем приложении или сценарии использования, это может быть вам полезно или бесполезно. Но рассмотрите это как пример и как указание на то, что может быть лучший способ построить вашу модель для удовлетворения ваших шаблонов запросов. Ознакомьтесь с статьей Патрика МакФадина о моделировании данных временных рядов, чтобы больше идей о том, как моделировать эту проблему.

Как объяснил Аарон, при использовании ключевого слова DISTINCT вы можете фильтровать только по ключам раздела. Причина этого заключается в алгоритме запросов DISTINCT и в том, как Cassandra хранит данные на диске / в памяти.

Чтобы понять это, я проведу аналогию:

Кассандра хранит информацию аналогично книжному индексу. Если вы выполняете поиск в главе под названием «Моя третья глава», вам нужно только посмотреть на первый уровень индекса, поэтому вам нужно выполнить итеративный поиск только в относительно небольшом наборе. Однако, если вы ищете подраздел под названием «Моя четвертая часть», принадлежащий «Моей второй главе», вам придется выполнить 2 итеративных поиска в 2 разных наборах, оба небольших, при условии, что в указателе есть не менее 2 уровни. Чем глубже вам нужно пройти, тем дольше это может занять (вам все равно может повезти, и вы найдете его очень быстро, если он находится в начале индекса, но в таких алгоритмах вы должны проверить среднее значение и наихудший сценарий) и тем сложнее должен быть индекс.

Кассандра делает нечто подобное: Keyspace -> Table -> Partition Key -> Clustering Key -> Column Чем глубже вам нужно углубиться, тем больше наборов вам нужно иметь в памяти, и потребуется больше времени, чтобы что-то найти. Индекс, используемый для выполнения запросов DISTINCT, может даже содержать только наборы до уровня ключа раздела, что позволяет искать только ключи раздела.

Вы должны понимать, что для поиска в любой главе, в которой есть подраздел под названием «Моя вторая часть» (что было бы аналогией с вашим запросом), по-прежнему требуется двухуровневый глубокий индекс и двухуровневый итеративный поиск.

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

Ни решение, предложенное Аароном (с использованием идентификатора пользователя в качестве ключа кластеризации после отметки времени), ни это решение (фильтрация на стороне клиента) не использует быстрый механизм DISTINCT. Его предложение не требует фильтрации на стороне клиента, поскольку оно уже выполняет это за вас, но предлагает два основных недостатка: оно не предлагает обратной совместимости, поскольку вам придется воссоздать таблицу и использовать постоянный ключ раздела и, следовательно, не позволяет Cassandra для распределения этих данных между своими узлами. Помните, что все значения одного и того же ключа раздела хранятся в одном узле.