基于表格存儲Tablestore和OSS實作企業網盤

表格存儲Tablestore是阿裡雲自研的結構化資料存儲平台，提供海量結構化資料存儲以及快速的查詢和分析服務。表格存儲Tablestore的分布式存儲和強大的索引引擎能夠支援PB級存儲、千萬TPS以及毫秒級延遲的服務能力。阿裡雲對象存儲服務（Object Storage Service，簡稱 OSS），是阿裡雲提供的海量、安全、低成本、高可靠的雲存儲服務。

網盤是一種線上存儲服務，服務商為使用者提供檔案的存儲、通路、共享等檔案管理必備的基本功能。我們将其資料分為兩種：

• 檔案。

• • 使用者存放的真實檔案。早期，網盤中的檔案大多存儲在檔案系統中，如本地磁盤、HDFS、NAS等。現在網盤更多的選擇存儲在對象存儲中，如OSS，其在穩定性、安全性、成本、彈性上都會具有優勢。

• 中繼資料(Meta)。

• • 描述檔案資訊的資料，如歸屬者、目錄、大小、建立時間、檔案類型等。利用該中繼資料可以找到真實的檔案位址，也可以利用中繼資料做檔案的查詢、分享、歸類等。

檔案資料直接使用OSS存儲即可，簡單高效。最複雜的是中繼資料的存儲和查詢，接下來我們看下網盤中繼資料(Meta)的存儲和查詢解決方案。

網盤中繼資料特點

網盤類型的中繼資料非常适合存儲在Tablestore，主要是因為網盤類型中繼資料的一些特征和Tablestore比對。

資料量大

存儲海量網盤中繼資料的同時，需要滿足強一緻、高可用、低成本等要求。使用者的檔案數量巨大，比如圖檔、視訊、工作文檔是數量最多的資料，一個企業的網盤中繼資料規模通常在TB級别。傳統的Mysql方案中，資料量一旦達到瓶頸，便需要重新建立更大規模的分庫然後進行資料的全量遷移，同時資料疊代、膨脹帶來的困擾是MySql方案難于逾越的門檻。是以，如此規模的資料存儲已經不适合用單機的關系型資料庫了，也不适合分庫分表了，而需要一款分布式NoSQL資料庫，這樣可以将資料按一定的路由規則分布到不同機器上，實作自動的水準擴充，非常适合存儲海量資料。

查詢類型多樣

網盤類型中繼資料與一般中繼資料不同的是有很多的tag标簽，是以系統需要具備搜尋查詢多元度嵌套标簽的能力。以圖檔為例：使用者通過智能媒體的分析服務，分析圖檔然後為圖檔增加标簽，使用者還可提取人臉識别相關資訊，提取的資訊也需要存儲到檔案中繼資料資訊中。圖檔的中繼資料資訊量不斷增加，格式、類型也在不斷呈現多元化。是以，需要具備豐富的查詢類型，如多元度、範圍、模糊查詢、地理位置等，同時具備排序、統計等功能。比如使用者希望查找在杭州市某個商圈1km内的照片？查找2019年所有關于兒子成績單的excel檔案？這時候關系型資料庫可能在查詢功能和性能上不一定能滿足需求，需要額外使用一些查詢引擎如Solr、Elasticsearch等。

服務性能及成本

新業務需要産品快速上線，這時候既要高并發，又要保證低延遲，同時又希望兼顧成本最低。随着系統使用者的增多減少以及不可預期的熱點事件，需要能夠動态的擴容和縮容來節約成本，比如系統起步階段可以使用一款全托管的Serverless資料庫，來專注于業務研發，無需擔心軟硬體配置、故障、叢集擴充、安全等問題，在保證服務高可用性的同時，極大地減少了管理及運維成本，幫助産品快速上線。

開源解決方案

傳統的網盤中繼資料可能會采用關系資料庫Mysql的方案，借助關系型資料庫強大的查詢能力，使用者可直接通過SQL語句實作檔案的中繼資料多元度查詢、資料統計分析等。但是，Mysql等關系資料庫通常有如下一些問題：

• 随着資料量的膨脹無法水準擴充。資料庫要滿足易擴充、低成本等基本要求；
• 對檔案的多元查詢需求支援不佳。資料庫需要具備強大的查詢能力，如多類型索引、多元度組合查詢等，同時具備排序、統計等功能；
• 在數量比較大的情況下，寫入性能較差。資料庫需要應對高并發請的同時，保證低延遲、強一緻、高可用等特性。

為了解決如上問題，多種資料庫組合的方案便孕育而生，如Mysql分庫分表+Elasticsearch的方案解決寫入和查詢能力等問題，這些方案的架構可能如下：

借助多個資料庫各自的優勢可以分别解決不同場景的需求，但多個資料庫組合的方案同樣也帶來了新的問題：

1. 犧牲了空間成本，Mysql和Elasticsearch中的資料存在無用的備援資料；
2. 較難保證兩個資料庫的資料一緻性，存在資料丢失的可能性；
3. 增加了開發工作量與運維複雜度。

Tablestore雲解決方案

在現有的各種各樣的雲産品中，能滿足上述網盤中繼資料需求的産品并不多。表格存儲Tablestore是阿裡雲借鑒谷歌Bigtable論文研發的一款分布式資料庫産品，可以提供超大規模的存儲容量，天然的分布式架構也提供了易于橫向擴充的特性，理論上可以存儲的資料量是不受限制的。該資料庫10年前就開始自研，經過多年的雙十一、公有雲客戶的錘煉沉澱，保證了系統的可靠性和穩定性。

基于Tablestore存儲網盤架構方案如圖：

網盤檔案的存儲

OSS和表格存儲Tablestore一樣，都是Serverless的雲服務，其資料設計持久性不低于99.9999999999%（12 個 9），服務設計可用性（或業務連續性）不低于 99.995%。OSS按量使用且無需關心運維。使用oss進行檔案的存儲會使應用在穩定性、安全性、成本、彈性上都會具有優勢。不用自己搭建和維護檔案系統，開發人員可以把精力放在核心功能的開發上。

網盤中繼資料的存儲

• 網盤中繼資料資料存儲在Tablestore中，Tablestore可以提供10個9的資料可靠性保障，資料可靠性有保障。
• 網盤中繼資料和索引都在一個系統裡面，寫入，讀取都是通過同一套API寫入和查詢，易用性更高。
• Tablestore支援二級索引、多元索引等索引功能，完全滿足上述提出的查詢需求，包括：

• • 多字段自由組合查詢。
  • 範圍查詢。
  • 地理位置查詢。

• Tablestore是分布式系統，可以水準擴充，目前生産環境單表最大有幾十PB，每秒寫入有幾千萬行，完全能勝任任何大資料的寫入和存儲。

示例

接下來，我們通過一個網盤中繼資料的使用示例增加了解。

假設我們的産品需要給使用者提供個人相冊服務。将相冊中的圖檔和視訊存儲在對象存儲OSS中，将圖檔和視訊的中繼資料(Meta Data)存儲在表格存儲Tablestore中。一般的檔案Meta資訊包括：使用者id、檔案id、檔案類型、建立時間、照片地點、檔案大小、檔案狀态、标簽資訊、OSS連結、是否星标檔案、使用者描述資訊。

首先，我們設計Tablestore中主表結構：

主鍵列			屬性列
字段描述	使用者id	建立時間	檔案id	檔案類型	拍攝地點	檔案大小	檔案狀态	标簽資訊	OSS連結	是否星标檔案	使用者描述資訊
資料類型	String	Integer				Double				Boolean
舉例	abc	1573543009	aaaa1	image	35.8,-45.91	42.5	uploading	[{"name:"place", "tag": "北京" }, { "name": "people", "tag": "男" }, { "name": "annimal", "tag": "狗" } ]	http://abc.oss-cn-hangzhou.aliyun.com/xxxxxx/aa.png	true	考上大學
	def	1573543012	bbbb2	video		9822.34	available	[{"name:"place", "tag": "上海" }, { "name": "weather", "tag": "西北雨" } ]	http://abc.oss-cn-hangzhou.aliyun.com/xxxxxx/aa.mp4	false	和小明一起上海跨年

Tablestore的主表在查詢時候可以了解為是幾個主鍵列上的字首索引，上述主表結構中，支援的查詢包括:

• 一個使用者下的所有圖檔或視訊
• 一個使用者某一段時間内的圖檔或視訊
• 檢視使用者最近的圖檔或視訊

Tablestore支援全局二級索引。全局二級索引支援在指定列上建立索引，生成的索引表中資料按您指定的索引列進行排序，主表的每一個寫入都将自動異步同步到索引表。您隻向主表中寫入資料，根據索引表進行查詢，在許多場景下，将極大的提高查詢的效率。例如網盤場景下如果主鍵查詢不能滿足需求，對于簡單的查詢(例如單個字段查詢)我們可以直接建立全局二級索引，通過全局二級索引能夠快速的查詢資訊。

通過主表和二級索引，已經能夠完成相冊的基本功能，如檔案的上傳下載下傳等。如果想完成更加豐富和複雜的查詢功能(多個字段關聯查詢)，可以使用Tablestore的多元索引功能，其中多元索引的索引定義：

列
Keyword	Long		GeoPoint		Nested，Nested中的name和tag都是Keyword		Text，分詞采用: 單字分詞

• 使用者描述資訊采用了Text類型， 支援分詞，分詞使用了單字分詞。該字段可以進行模糊比對查詢。
• 拍攝地點采用了GeoPoint類型，這個類型支援範圍查詢。比如某個點附近幾公裡内的所有照片，同時也支援某個多邊形範圍内的所有照片資訊。
• 标簽資訊是Nested嵌套類型的，其支援的查詢和非嵌套類型一緻，隻是使用方式上有一些小差别。
• 多元索引支援多字段組合查詢，可以滿足任意幾個列與或非組合查詢，如：查詢檔案類型是圖檔且拍攝地點是上海且檔案大小超過100MB且是标星檔案且建立時間在9月份之前的所有照片？

另外，可能還有一些統計聚合需求，在營運産品和制作報表時候可能會用到。這些都可以基于多元索引完成，比如：

• 目前所有使用者的相冊中一共有多少張？通過Aggregation.Count(*)；
• 所有使用者中超過1G的檔案有多少個？GroupBy.GroupByRange(檔案大小)；
• 視訊和圖檔各有多少張？通過 GroupBy.GroupByField(檔案類型)；
• 過去三年每年相冊的上傳數量？ 通過 GroupBy.GroupByRange(建立時間)；
• 視訊檔案中最大檔案有多大？ 通過Aggregation.Max(檔案大小)；
• ...

基于上述的表、二級索引和多元索引，我們就能滿足幾乎所有的查詢需求。

總結

至此，開源解決方案和Tablestore雲解決方案都介紹完了，使用了Tablestore雲解決方案後，能帶來不少的收益。

減少運維負擔

在Tablestore雲解決方案中，使用者隻需要運維自己的應用程式，不需要運維任何的存儲系統、查詢系統和其他中間件，運維壓力大大減少，同時也減少了運維方面的成本開支。另外，Tablestore是Serverless的服務化産品，不需要關注擴容、水位等事項，隻需要關注功能開發即可。

系統架構更簡單

在開源解決方案中使用多個系統，而Tablestore解決方案中隻有1個系統，系統數減少後，系統架構會更簡單，系統可能産生的風險會更少，系統的穩定性等會更高，可以提供更優質的服務體驗。

減少時間成本

Tablestore雲架構方案相對于開源方案，系統更少，從零開始到上線需要的開發時間更少，同時，Tablestore是serverless的雲服務，全球多個區域即開即用，可以大大降低客戶的開發上線的時間，提前将産品推出，搶先争取市場領先優勢。

資料可靠性更高

在開源解決方案中，資料有可能會丢失，影響最終的業務，而在Tablestore解決方案中，可以提供更高的可靠性，可以讓資料不丢失，保障業務的準确執行。

擴充閱讀

• 表格存儲Tablestore權威指南（持續更新）
• 海量智能中繼資料管理系統實作解析
• 表格存儲資料模型和查詢操作
• Aliyun Tablestore Examples

表格存儲 (Tablestore) 提供專業的免費技術咨詢服務，歡迎加入我們的釘釘讨論群。群号 : 23307953