我讀了下面的文章：Elements of Scale: Composing and Scaling Data platforms爲什麼直接路由不能用於具有二級索引的分佈式數據？
我卡上理解下面的句子：
的第二個指標是不是主鍵索引。這意味着數據將不會被索引中的值分區。通過哈希函數定向路由不再是一種選擇。我們必須向所有機器廣播請求。
任何人都可以解釋爲什麼這種情況？我是數據平臺的初學者，但已經得到了很多，並且理解了這篇文章。
具體來說，爲什麼我們不能在二級索引中查找主鍵的值，然後通過該主鍵上的哈希函數查找它們的位置？爲什麼要向所有機器廣播請求？
謝謝您的時間
對於他們給數據已分佈在4個節點的例子。每個節點都有一個輔助索引，但僅用於該節點上的值。二級索引不具有所有節點上的所有記錄。所以想要搜索的調用者需要發送到所有節點。
例如只用2個節點
節點1具有（1，A）（2，）（3，B）
節點2具有（100，）（105，C）
節點1有一個主索引1,2,3。並且輔助索引a，a，b
節點2具有主索引100,105。並且輔助索引a，c
想要搜索'c'的呼叫者需要向兩個節點廣播來搜索兩個二級索引。
但是，如果您維護二級索引a，a，a，b，c的完整副本，則可以查詢該索引，然後直接轉到目標節點。但是，這在實踐中比你想象的要複雜得多。
編輯6月22日。當您嘗試在第三個節點上維護輔助索引時，則需要考慮以下複雜問題。現在，所以你需要實現兩個階段提交某種協議，或替代方案
插入/編輯操作涉及2個或甚至3個節點。
隨着涉及的節點越多，MTBF越低，總體可靠性越低。
您需要考慮網絡分區會發生什麼情況。
維護操作可能會更困難。例如，如何有效驗證索引是否正確，而不會產生太多的網絡流量。
更新將如何編輯索引節點？客戶是負責這一點，還是主存儲節點更新索引節點？
一個良好的學習更是審查CAP定理，考慮2階段提交方案，並有可能看一些發表在分佈式系統期刊的IEEE論文。
以Cassandra爲例，數據被寫入由分區鍵的散列（在表模式中定義，它通常是主鍵的第一部分）確定的節點的副本中。
二級索引的數據不在該分區鍵中，假設索引寫入保存原始數據的同一節點，查詢二級索引時無法確定包含特定值的數據的節點因爲它存在於原始分區鍵（主數據）的節點上，所以該索引通過散列新的'鍵'的值。
感謝您的回答。我期待在您的回答結束時明確瞭解這些複雜情況 –
感謝您的其他信息 –