新一代Apache Cassandra索引現已在Astra和DataStax Enterprise 6.8.3中正式開放使用 (general availability or GA)，很快您也將在開源版的Apache Cassandra中看到這項全新功能。

01SAI簡介

DataStax非常高興地宣佈——具有高伸縮性且可以全域性分佈的儲存附帶索引(Storage-Attached Indexing or SAI)，現已在Astra和DataStax Enterprise(DSE)中正式面世。

開發者可以在Apache Cassandra中使用關係型WHERE的模式，從而充分利用使用者期望的資料庫索引功能。相比Cassandra現行的索引或外部擴充套件的搜尋方案，SAI賦予架構師高效且更簡單的過濾篩選能力。另外，SAI解決了Cassandra使用者面臨的資料建模、查詢靈活性以及運維方面的挑戰。

為了更好地解釋這些，我們藉助一個例子來進一步說明。假設有一個簡單的表，它的結構如下。

CREATE TABLE products (
  id int, 
  time date, 
  name text, 
  price int,   
  PRIMARY KEY (id), time
);

下面這個SELECT示例查詢語句在SAI問世之前是不可用的，因為其中沒有引用任何主鍵。

SELECT name, price
FROM products
WHERE price < 30

現在有了SAI，上面的查詢語句不僅可以使用，而且在資料規模很大時依然高速。

關鍵且現代的應用程式具有突破性的置信度、伸縮性、可用性以及效能。正在構建這些應用程式的開發者和架構師們選擇使用Cassandra，因為其伸縮能力在任何負載下都能橫跨裸機、多雲、混合環境以及其它任何介於這三者之間的環境。只用寫一次程式碼就可以大規模部署並實現自動化運維，這種靈活性改變了程式碼驅動的伸縮性的相關成本。

即使Cassandra很擅長注入資料，它嚴格的查詢模式對習慣於關係型資料庫的開發者來說仍有限制，這導致了開發週期的延長和市場交付時間的延遲。但這種情況不再會出現，因為SAI使Apache Cassandra具有了全域性索引的能力。

操作員和資料庫管理員對於支援在Cassandra上執行的至關重要的應用程式很有信心，因為Cassandra不僅沒有宕機時間，而且用來維護正常執行以及效能服務級別協議(SLAs)的時間也更少。有了SAI，操作員無需過多擔憂與伸縮、備份和修復相關的運維。因為相比之前的補充索引，SAI這種解決方案使這些運維過程更合理化也更簡單。

02SAI使用說明

DataStax不僅已經在Astra和DSE 6.8.3中開放使用SAI，同時還提交了Apache CEP（Cassandra Enhancement Proposals，即Cassandra改進提案）以便使用者可以在開源的Apache Cassandra版本中用到此項功能。

下面是已經開放使用的SAI版本所支援的功能。

03現在開始體驗吧

儲存附帶索引非常容易上手。

假設有一個這樣的表——

CREATE TABLE products (
  id int, 
  time date, 
  name text, 
  price int,   
  PRIMARY KEY (id), time
);

如何定義SAI索引？在建立完資料庫、鍵空間(keyspace)以及一個或多個表後，使用下面的DDL（Data Definition Language，即資料定義語言）命令語句在你希望索引的表格上定義一個或多個SAI索引。

CREATE CUSTOM INDEX ... USING 'StorageAttachedIndex'

一旦索引建立完成，接下來就只剩書寫查詢語句和指定索引欄位的步驟了。就是這麼簡單！

下圖中可以看到具體的查詢示例程式碼。

在系統內部，這個索引已經根據所選列的資料型別進行了優化。比如，數字型別的欄位為區間查詢做了優化。系統會選擇正確的索引執行方式，所以你無需考慮這些。

想要了解更多？點選下面的連結，跟隨SAI文件中的初學教程來學習使用這個超棒的新索引。快速上手SAI

04SAI的設計

儲存附帶索引的構建基於兩部分：一是現行的Cassandra索引的最佳實踐；二是常見的擴充套件分散式索引及搜尋解決方案中最佳的分散式索引演算法。

SAI與Apache Cassandra的儲存引擎深度整合，這也正是為什麼我們稱之為“儲存附帶索引”。

SAI並不是抽象的索引表，隨著資料的寫入，它將Cassandra記憶體中的Memtable和磁碟上的SSTable這兩個資料結構都編入索引。在讀取時，SAI可以過濾篩選記憶體中和磁碟上的多種資料結構，智慧地返回結果。

SAI幾乎沒有增加核心資料庫運維的複雜性。從快照建立到模式(schema)管理再到資料過期，SAI與核心資料庫的效能和機制緊密整合。

儲存附帶索引還與零拷貝串流完全相容。這意味著當你增加或刪除節點時，儲存附帶索引會與SStables完整同步。這樣你就無需將這些索引序列化，也無需在接收節點的一端重建索引。

SAI並不需要引入任何特別的配置或“神奇的”設定來實現高效能，標準的Cassandra調校技巧依然適用。

比如，如果你有嚴格的讀取延遲要求，調整壓實操作(compaction)引數就很重要——因為你會想要確保Cassandra持續進行壓實，從而讓SSTable的數量保持在低點。這些用於調整無索引表的壓實過程的方法，同樣適用於那些使用了SAI的表。

05總體擁有成本(TCO)

SAI所需的磁碟使用量遠遠低於其它Cassandra原生或擴充套件的索引解決方案。下圖分別展示了SAI、Cassandra SASI和二級索引的磁碟佔用空間。

與SASI不同，SAI不會為每個索引詞(term)都建立ngram，所以能節省大量的磁碟空間。與二級索引相比，SAI無需複製整張表來新增新的分割槽鍵。

06SAI的效能

在初步測試中，我們已經看到SAI相較於其他Cassandra原生索引方案，在資料的更新（增、改、刪）方面有著極大的效能提升。大致來說，使用者可以期待SAI比二級索引多出大約40%的吞吐量並減少230%的延遲時間。在讀操作方面，SAI比二級索引略快一些。

相比Cassandra其它的索引方案，使用SAI將會為你帶來更多的功能和更高的效能。

07我們的下一步計劃

我們非常努力地奠定了SAI的基礎，現在我們將集中開發新功能。在接下來的幾個月裡，我們將優先做以下兩件事：

1. 通過CEP（Cassandra改進提案）流程，使SAI加入到開源的Apache Cassandra版本中
2. 研發全域性排序、分詞、地理資料支援等功能，繼續拓寬Cassandra索引的邊界

08我們一直在這裡

儲存附帶索引是DataStax工程團隊酷愛的專案，我們以解決Cassandra使用者在資料建模、運維和查詢靈活性方面遇到的挑戰為使命。

根據查詢語句來設計表的結構是一項Cassandra通用的最佳實踐，但是它帶了來許多資料的冗餘和開發者的疑惑。而SAI可以讓使用者根據表中的任意欄位篩選資料，這意味著使用者不再需要迎合查詢語句來建構表——你只需簡單地以最自然的方式建立表，並使用SAI索引欄位靈活地查詢資料且不受主鍵的任何限制。

針對多種分散式索引引擎的經年累月的研發，加上數年來通過解決最複雜的分散式資料的問題所積累的知識，DataStax已經通過SAI這個新的分散式索引解決了從Cassandra中靈活讀取資料的挑戰。

我們希望您同我們一樣喜歡SAI。如果您有任何問題或反饋，請通過下方郵件直接與我們聯絡：

[email protected]

我們的工程團隊隨時準備著，非常樂意提供幫助、聽取反饋以及開展對話。