在沒有分區鍵的情況下查詢 Cassandra

我閱讀了 Cassandra 在查詢數據時執行的內部步驟的文件。看起來 Cassandra 依賴分區器和複製策略來處理查詢。我仍然對 Partitioner 需要知道 Partition Key 感到困惑。如果查詢具有分區鍵，則內部查詢過程看起來很簡單。但是，如果查詢需要一個結果集而不是像下面這樣的確定性行。

SELECT * FROM <table>

1. 在這種情況下，當WHERE子句中沒有指定 Primary Key 時，Coordinator 怎麼知道將請求發送到哪些節點？
2. 如果返回多行，可能分佈在不同的節點，這些行是如何聚合併返回給客戶端的？

當 WHERE 子句中沒有指定 Primary Key 時，Coordinator 如何知道將請求發送到哪些節點？

1. 它沒有。（選擇作為）協調器的（節點）必須在每個節點上掃描該表的所有行。這就是為什麼未綁定查詢在 Cassandra 中被視為反模式的原因，因為它們會佔用大量網路時間。尤其是在較大的集群中。此外，協調器將不得不做額外的工作，因為它必須組裝並返回結果集。

如果返回多行，可能分佈在不同的節點，這些行是如何聚合併返回給客戶端的？

2. 它們實際上並沒有太多聚合，因為它們是按其分區鍵的散列令牌值按順序返回的。

考慮針對名為 的表執行未綁定查詢crew，其分區鍵為crewname。當我在該鍵上執行 CQLtoken()函式時，您可以看到返回的行確實是按其標記排序的。

aploetz@cqlsh:presentation> SELECT crewname,token(crewname),firstname,lastname 
FROM crew;

crewname | token(crewname)      | firstname | lastname
----------+----------------------+-----------+-----------
   Simon | -8694467316808994943 |     Simon |       Tam
   Jayne | -3415298744707363779 |     Jayne |      Cobb
    Wash |   596395343680995623 |     Hoban | Washburne
     Mal |  4016264465811926804 |   Malcolm |  Reynolds
    Zoey |  7853923060445977899 |      Zoey | Washburne
Sheppard |  8386579365973272775 |    Derial |      Book

(6 rows)

它以這種方式工作，因為 Cassandra 使某些節點主要負責某些令牌範圍。然後，協調器按該順序返回結果集成為一項簡單的任務。如果有多行具有相同的分區鍵，則結果將另外按每個分區鍵內的集群鍵排序。

引用自：https://dba.stackexchange.com/questions/157537