釘釘數據存儲使用阿里雲的表格存儲,如何設計資料庫?

01-13

上圖:阿里雲官網截圖. link: 表格存儲_海量數據存儲-阿里雲
我的想法是把表格存儲當成只能單表使用的MySQL來用, 問題在乎釘釘的業務很複雜, 如何用表格存儲這個只支持單表操作的資料庫來支撐類似於傳統RMDB的join操作, 很多業務耦合的後台管理功能如何實現, 我能想到的是數據冗餘, 但是數據量非常大時,業務變化非常快時,如何仍然保證低延時和高並發? 比如一段時間內某個部門下所有尚未轉正的員工的打卡記錄.

首先，如果把表格存儲當做單表的MySQL來用的話，那你就用錯了。MySQL是傳統關係型資料庫，而表格存儲是NoSQL資料庫，不直接支持SQL語法，特點是低延遲，高性能，大容量，適用於大數據量，比如單表PB級。
最終你的業務適用於使用MySQL還是表格存儲，完全取決於你的業務特點。如果你的數據量比較大，達到TB，PB級別，那這時候就需要使用類表格存儲（Tablestore）產品了。
使用表格存儲後，可以滿足你對低延遲（1ms~10ms的延遲），高並發（千萬，甚至億級TPS），高可靠性（99.99999999%的數據可靠性，由於使用了共享存儲，那麼在系統可靠性上也是高出同類產品很多），高擴展性（實時水平擴展），全託管（免運維）等大數據類的需求。
但是由於不支持join，事務等關係型資料庫的一些功能，那這時候設計系統架構的時候就需要換一種思路：將產品的複雜功能拆分成獨立的小功能模塊，如果整個系統很大，那麼拆分出來的每個小功能模塊就是一個小系統，小服務。
然後，開始單獨設計每個小系統的架構，這時候小系統的功能就比較單一，就比較好設計了。對於新手，等將所有小系統設計完後可以回頭再去抽取公共模塊，對於高手，開始就能抽象出來這些。
為了應付業務的快速變化，這裡的關鍵：1是底層存儲系統的高性能，高吞吐，2是高度抽象，平台化，設計簡單，可重複利用的中間層。這樣子的話，快速變化的業務只需要變化最外層的業務層或者說是界面，改動和變化就比較小了。
你說的數據冗餘也是一種比較常見的設計方式，是在大數據場景中的一種折中。有時候可以簡化整體系統架構，有時候會使數據膨脹，具體問題要具體分析，沒有一種確切性的銀彈可以解決所有的場景。
表格存儲也有很多高級功能，可以用來輔助系統架構，比如多版本，寬行。對於「一段時間內某個部門下所有尚未轉正的員工的打卡記錄.」這個需求，就可以使用多版本或者寬行。

如果使用多版本：建一個表：ProbationPeriod，打開多版本，版本數可以設置為200，每一行都是一個未轉正員工，主鍵列可以是：員工ID，屬性列可以是：attence。比如5月10日，小張入職，開始試用期，第一天上班打卡的時候，往ProbationPeriod表中寫入一行（UpdateRow），主鍵是小張，屬性列是attence，值是打卡位置，版本號是當前時間，如果不寫版本號，那麼再寫入表格存儲的時候，表格存儲會使用當前時間。這樣子，表ProbationPeriod中就記錄了小張在5月11日打卡的位置，時間，後面每天都可以做同樣的寫入，這樣，三個月後，可能保存30*3=90天的記錄，這時候只需要通過一個GetRow，指定主鍵值，這樣就可以讀出attence列的所有版本的值。
如果使用寬行：就是每一次寫入一個新列。如果3個月試用期，也就90個左右的列。
其他：還有其他方案，先不寫了。

表格存儲是自研的產品，在功能迭代上不僅快，而且自由度很大，對於社交場景，也做了一些功能來簡化社交產品的架構，比如去年的自增列功能，具體可以看這篇文章：高並發IM系統架構優化實踐-博客-雲棲社區-阿里雲
如果你的數據量很大，業務也很複雜，且想使用雲產品做存儲的話，可以到阿里雲官網給表格存儲提工單，讓表格存儲的專家們結合你的數據和場景設計一個適合你的解決方案。

表格存儲：基於共享存儲，百PB級別存儲，高並發、低延時、可擴展、全託管；支持多版本，寬行，增量通道，不支持 SQL，複雜事務，多表join；

可以具體從業務需求（業務API表徵業務需求，比如如何讀？如何寫？自動過期？增量到其他平台？）看看錶結構設計，性能並發一般不用擔心。

ECS也就是阿里雲伺服器，RDS提供資料庫服務，比如MSSQL或MySql等資料庫。OSS是存儲服務，一步用於存放靜態資源，網站的圖片、音樂什麼的