根據Yelp今年第二季度財報，本地廣告商數量已經約有12.8萬個。Yelp的廣告系統(tǒng)每天都要結算上一天廣告被查看的次數和點擊數，以及對應需要支付的費用。基于這樣的結算數據，Yelp要生成賬單以及各種各樣的報告。

廣告系統(tǒng)后臺團隊最近把底層數據存儲從MySQL換成了Cassandra，軟件工程師Qui N.和Shafi B.發(fā)表文章簡單介紹了改變的原因，并分享了一些向Cassandra遷移的經驗。

在Yelp公司創(chuàng)立初期，我們把廣告數據存儲在了MySQL中。伴隨著系統(tǒng)規(guī)模擴大和廣告產品的演進，我們發(fā)現(xiàn)Cassandra才是更好的選擇。我們并不需要傳統(tǒng)關系型數據庫的特性，因為我們沒有什么事務操作，也不需要對數據表進行聯(lián)合查詢。Cassandra對我們最大的好處就是方便擴展存儲、有彈性的模式定義和高寫入性能。

具體來說就是：

文章重點是與大家分享在使用Cassandra的過程中得到的經驗。

1、把查詢語句和表的模式定義放在一起綜合考慮：Cassandra本質上是結構型的鍵-值型存儲，表的主鍵選擇對后續(xù)的查詢語句性能影響非常大。Cassandra的表主鍵包括分區(qū)鍵和集合列，前者決定了數據能否均勻分散到多個節(jié)點上，后者決定了相同分區(qū)鍵的數據在同一個分區(qū)內如何排序。要根據查詢語句決定表的定義，反之也要根據表的定義來改寫查詢語句，兩者綜合才能達到最佳性能。

2、數據行定義會影響數據壓縮：Cassandra的數據壓縮就是合并對數據的更新操作的過程。業(yè)務程序更新數據的次數和方式決定著該選擇Cassandra的哪種壓縮策略。

其根本原因在于在Cassandra底層是把屬于每個分區(qū)鍵的數據以寬行存儲的。以Yelp的業(yè)務舉例，以campaign_id為分區(qū)鍵，以day為集合列，那么在底層數據其實是這樣存儲的：

　　而不是大家想當然的這樣：

Cassandra的默認策略size-tiered compaction合并操作并不頻繁，而leveled compaction會保證未合并的對相同分區(qū)鍵的更新操作不會超過一定數量，因此雖然在寫入時會造成更多的I/O，卻對統(tǒng)計查詢有比較好的性能，因此更適合Yelp的業(yè)務。

3、遷移到Cassandra會增大寫入量：使用MySQL會希望表設計遵守范式，可使用Cassandra之類的NoSQL數據庫，違反范式反而常常會獲得更好的性能。雖然Cassandra出色的寫性能在一定程度上可以彌補這一代價，但千萬不要對此掉以輕心。

4、Cassandra的批量操作語句很有用：MySQL的批量操作語句常用來提高性能，可是Cassandra的批量操作語句卻常常只是用來保證原子性的。因為Yelp選用的cqlengine在底層寫入操作是同步的，在寫入量大的情況下就性能堪憂，因此他們最終通過批量寫入來解決這個問題。批量操作上線后立刻將寫入性能提高了一倍。

5、TTL機制可能帶來的麻煩更多：Cassandra支持為每個字段設置生命期（Time To Live，TTL），如果某個字段設置了TTL，那么在過期之后就會自動刪除，不再需要用戶操心。可是對于Yelp的這種分析型業(yè)務，由于需求的不確定性，設置這種TTL數據可能還不如定期檢查刪除一遍對整個系統(tǒng)影響更小。

相對于MySQL，Yelp因為Cassandra的易擴展、有彈性的模式定義和高寫入性能等特性而選擇了后者。如果你也在構建一個寫入量很大的系統(tǒng)，或者在重構系統(tǒng)，那Yelp的經驗也許會對你有用。

感謝杜小芳對本文的審校。