единственный способ запроса CQL всей таблицы / представления, отсортированного по полю, - сделать ключ раздела постоянным. Ровно одна машина (коэффициент репликации times) будет содержать всю таблицу. Е. Г. с partition INT ключ раздела, который всегда равен нулю, и ключ кластеризации в качестве поля, требующего сортировки. Вы должны наблюдать производительность чтения/записи/емкости, аналогичную одноузловой базе данных с индексом в отсортированном поле, даже если у вас больше узлов в кластере. Это не победить цель Кассандры, потому что она может помочь масштабировать в будущем.

если производительность недостаточна, вы можете решить масштабировать, увеличивая разнообразие разделов. Например. случайный выбор от 0, 1, 2, 3 для вставок будет до четырехкратного чтения/записи / емкости perf, когда используются 4 узла. Затем, чтобы найти "10 самых последних" элементов, вам придется вручную запросить все 4 раздела и объединить-отсортировать результаты.

теоретически Кассандра могла бы предоставить этот объект динамического node-count-max - modulo ключ раздела для вставки и слияния-сортировка для SELECT (с ALLOW FILTERING).

цели дизайна Кассандры запрещают глобальную сортировку

чтобы разрешить запись, чтение и емкость для хранения линейно масштабироваться с подсчетом узлов Cassandra требуется:

• каждая вставка земли на одном узле.
• каждый выберите землю на одном узле.
• клиенты распределяют рабочую нагрузку аналогично между всеми узлами.

Если Я поймите правильно, следствием этого является запрос с одним полем в полной таблице, который всегда требует чтения из всего кластера и сортировки слиянием.

Примечание материализованные представления эквивалентны таблицам, у них нет никаких магических свойств, которые делают их лучше в глобальной сортировке. См.http://www.datastax.com/dev/blog/we-shall-have-order где Аарон Плоец согласен с тем, что cassandra и cql не могут сортировать по одному полю без раздела и масштаб.

Пример Решения

CREATE KEYSPACE IF NOT EXISTS
    tmpsort
WITH REPLICATION =
    {'class':'SimpleStrategy', 'replication_factor' : 1};

USE tmpsort;

CREATE TABLE record_ids (
    partition int,
    last_modified_date timestamp,
    record_id int,
    PRIMARY KEY((partition), last_modified_date, record_id))
    WITH CLUSTERING ORDER BY (last_modified_date DESC);

INSERT INTO record_ids (partition, last_modified_date, record_id) VALUES ( 1, DATEOF(NOW()), 100);
INSERT INTO record_ids (partition, last_modified_date, record_id) VALUES ( 2, DATEOF(NOW()), 101);
INSERT INTO record_ids (partition, last_modified_date, record_id) VALUES ( 3, DATEOF(NOW()), 102);
INSERT INTO record_ids (partition, last_modified_date, record_id) VALUES ( 1, DATEOF(NOW()), 103);
INSERT INTO record_ids (partition, last_modified_date, record_id) VALUES ( 2, DATEOF(NOW()), 104);
INSERT INTO record_ids (partition, last_modified_date, record_id) VALUES ( 3, DATEOF(NOW()), 105);
INSERT INTO record_ids (partition, last_modified_date, record_id) VALUES ( 3, DATEOF(NOW()), 106);
INSERT INTO record_ids (partition, last_modified_date, record_id) VALUES ( 3, DATEOF(NOW()), 107);
INSERT INTO record_ids (partition, last_modified_date, record_id) VALUES ( 2, DATEOF(NOW()), 108);
INSERT INTO record_ids (partition, last_modified_date, record_id) VALUES ( 3, DATEOF(NOW()), 109);
INSERT INTO record_ids (partition, last_modified_date, record_id) VALUES ( 1, DATEOF(NOW()), 110);
INSERT INTO record_ids (partition, last_modified_date, record_id) VALUES ( 1, DATEOF(NOW()), 111);

SELECT * FROM record_ids;

-- Note the results are only sorted in their partition
-- To try again:
-- DROP KEYSPACE tmpsort;

обратите внимание, что без WHERE предложение вы получаете результаты в порядке токена (ключа раздела). Смотри https://dba.stackexchange.com/questions/157537/querying-cassandra-without-a-partition-key

другие модели распространения баз данных

если я правильно понял-CockroachDB будет аналогично производительности чтения/записи бутылки на монотонном приращении данных на один узел в любой момент времени, но емкость хранилища будет линейно масштабироваться. Также другие запросы диапазона, такие как" oldest 10 "или" между датой X и датой Y", будут распределять нагрузку на большее количество узлов в отличие от Cassandra. Это связано с тем, что база данных CockroachDB-это одно гигантское хранилище отсортированных ключей, где всякий раз, когда диапазон отсортированных данных достигает определенного размера, он перераспределяется.

есть еще одна проблема, с принятым решением я думаю. Если у вас есть несколько реплик, вставки не гарантируется в конечном итоге в порядке.

из документов datastax:

теперь() - В узле координатор генерирует новый уникальный timeuuid в миллисекундах при выполнении инструкции. Часть метки времени timeuuid соответствует стандарту UTC (Universal Time). Этот метод полезен для вставки значений. Значение, возвращаемое now() гарантированно будет уникальным.

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

вы пытаетесь получить некоторое согласованное (или единственную ссылку на правду) представление о ваших данных. К сожалению, в распределенной среде нет ни одной ссылки на правду.