根據Yelp今年第二季度財報，本地廣告商數量已經約有12.8萬個。Yelp的廣告系統每天都要結算上一天廣告被查看的次數和點擊數，以及對應需要支付的費用。基于這樣的結算數據，Yelp要生成賬單以及各種各樣的報告。
廣告系統后臺團隊最近把底層數據存儲從MySQL換成了Cassandra，軟件工程師Qui N.和Shafi B.發表文章簡單介紹了改變的原因，并分享了一些向Cassandra遷移的經驗。
在Yelp公司創立初期，我們把廣告數據存儲在了MySQL中。伴隨著系統規模擴大和廣告產品的演進，我們發現Cassandra才是更好的選擇。我們并不需要傳統關系型數據庫的特性，因為我們沒有什么事務操作，也不需要對數據表進行聯合查詢。Cassandra對我們最大的好處就是方便擴展存儲、有彈性的模式定義和高寫入性能。
具體來說就是：
方便擴展存儲：Cassandra是分布式系統，只需要增加節點就可以擴充存儲空間； 有彈性的模式定義：業務需求會經常要求改動數據的模式定義，Cassandra很適合做這樣的事； 高寫入性能：Cassandra寫入性能是非常高的，Netflix曾經在一次測試中達到每秒超過100萬次的寫入；由于Yelp的廣告數據越來越多，寫入必須保持在有限的時間內完成；文章重點是與大家分享在使用Cassandra的過程中得到的經驗。
1、把查詢語句和表的模式定義放在一起綜合考慮：Cassandra本質上是結構型的鍵-值型存儲，表的主鍵選擇對后續的查詢語句性能影響非常大。Cassandra的表主鍵包括分區鍵和集合列，前者決定了數據能否均勻分散到多個節點上，后者決定了相同分區鍵的數據在同一個分區內如何排序。要根據查詢語句決定表的定義，反之也要根據表的定義來改寫查詢語句，兩者綜合才能達到最佳性能。
2、數據行定義會影響數據壓縮：Cassandra的數據壓縮就是合并對數據的更新操作的過程。業務程序更新數據的次數和方式決定著該選擇Cassandra的哪種壓縮策略。
其根本原因在于在Cassandra底層是把屬于每個分區鍵的數據以寬行存儲的。以Yelp的業務舉例，以campaign_id為分區鍵，以day為集合列，那么在底層數據其實是這樣存儲的：
而不是大家想當然的這樣：
Cassandra的默認策略size-tiered compaction合并操作并不頻繁，而leveled compaction會保證未合并的對相同分區鍵的更新操作不會超過一定數量，因此雖然在寫入時會造成更多的I/O，卻對統計查詢有比較好的性能，因此更適合Yelp的業務。
3、遷移到Cassandra會增大寫入量：使用MySQL會希望表設計遵守范式，可使用Cassandra之類的NoSQL數據庫，違反范式反而常常會獲得更好的性能。雖然Cassandra出色的寫性能在一定程度上可以彌補這一代價，但千萬不要對此掉以輕心。
4、Cassandra的批量操作語句很有用：MySQL的批量操作語句常用來提高性能，可是Cassandra的批量操作語句卻常常只是用來保證原子性的。因為Yelp選用的cqlengine在底層寫入操作是同步的，在寫入量大的情況下就性能堪憂，因此他們最終通過批量寫入來解決這個問題。批量操作上線后立刻將寫入性能提高了一倍。
5、TTL機制可能帶來的麻煩更多：Cassandra支持為每個字段設置生命期（Time To Live，TTL），如果某個字段設置了TTL，那么在過期之后就會自動刪除，不再需要用戶操心。可是對于Yelp的這種分析型業務，由于需求的不確定性，設置這種TTL數據可能還不如定期檢查刪除一遍對整個系統影響更小。
相對于MySQL，Yelp因為Cassandra的易擴展、有彈性的模式定義和高寫入性能等特性而選擇了后者。如果你也在構建一個寫入量很大的系統，或者在重構系統，那Yelp的經驗也許會對你有用。
感謝杜小芳對本文的審校。
京公網安備 11010502049343號