前言
回顧過去二十年的技術發展，整個應用形态和技術架構發生了很大的更新換代，而任何技術的發展都與幾個重要的變量相關。
一，應用形态的變遷，産生更多的場景和需求。整個應用形态從企業應用、網際網路服務再到移動應用，曆經了幾個不同階段的發展。從最早企業内應用系統，到通過移動網際網路技術覆寫到每個人生活的方方面面，這個過程中産生了大量的場景和需求。而新的場景和需求，是推動産品和技術發展的主要因素。
二，更複雜的場景，更大規模的挑戰，推動技術的快速發展。新一代應用面臨更複雜的場景和更大的規模挑戰，老一代技術架構無法支撐業務的快速發展，是以急需推動新的技術的研究和發展。這是一個綜合的 ROI 的考慮，流量和資料到一定規模才能讓技術架構更新帶來更大的效率和成本的收益。
三，技術基礎設施的完善，提供了技術和産品發展的基礎。網際網路、4G/5G 等基礎設施的建立和完善，是新一代應用誕生和發展的基礎。分布式技術、雲計算、新一代硬體等技術的成熟，是技術架構變革的基礎。
本篇文章會給大家分享應用系統資料架構的演進以及雲上的架構最佳實踐，這裡先對資料系統的分類做一個定義，資料系統如果按照主體來區分的話分為以下兩類：
- 應用為主體：常見的資料架構都是以『應用』為主體，資料主要産生自應用。資料架構圍繞業務來設計，通常是先定義業務模型後設計業務流程。由于業務之間區分度很大，每個業務都有截然不同的業務模型，是以資料系統需要具備高度『抽象』的能力，是以通常會選擇關系型資料庫這類抽象能力強的元件作為核心存儲。
- 資料為主體：這類資料系統通常圍繞『特定類型資料』進行建構，比如說圍繞雲原生監控資料設計的以 Prometheus 為核心的監控資料系統，再比如圍繞日志資料分析設計的 ELK 資料系統。這類資料系統的設計過程通常是圍繞資料的收集、存儲、處理、查詢和分析等環節來設計整套資料系統，資料具備統一的『具象』的模型。不同的場景有不同的資料系統，當某個場景具備通用性以及得到一定規模的應用，通常在開源界會誕生一套成熟的、完整的解決方案，比如說雲原生 Prometheus、ELK、Hadoop 等。
本篇文章介紹的資料架構主要是第一類，即以『應用為主體』的資料架構。
應用系統資料架構
應用系統資料架構曆經了多次疊代，從傳統的單一系統資料架構，到由多元件構成的現代資料架構。現代資料架構下包含不同的計算和存儲元件，這些元件在處理不同類型資料以及負載下各有優劣。現代資料架構通過合理選擇群組合這些元件，讓各個元件能發揮最大的能力，進而讓整個資料系統能滿足更多樣化的場景需求以及能支撐更大的資料規模。
傳統資料架構（單一系統）
LAMP 架構
一個應用系統的基本構成包括：API（提供服務接口）、應用（業務處理邏輯）、資料存儲（應用資料存儲）以及運作環境（應用和資料庫的運作環境）。網際網路早期最流行的 LAMP 架構就是典型的單一系統資料架構，其中使用 Apache Server 作為 API 層、使用 PHP 開發應用，使用 MySQL 作為應用資料存儲，所有元件均運作在 Linux 系統上。
整套架構采用開源軟體建構，相比商業軟體能提供更低的成本，是以能快速在網際網路早期的各大中小站點流行起來，成為最流行的建站技術架構。但随着網際網路的流量越來越大，LAMP 架構面臨的最大的問題是可擴充性，需要解決應用和存儲的擴充問題。
如何進行擴充
關于擴充技術的幾個基本概念：
- Scale-up vs Scale-out
- Scale-up 即直接提升機器的配置規格，是最直接的擴充手段，計算和存儲均可通過 Scale-up 的方式來進行擴充，但擴充空間有限，相對成本較高。Scale-out 即增加更多的機器進來，是相對成本更低、更靈活的手段，但需要相關元件具備能 Scale-out 的能力。
- 存儲和計算分離
- 存儲和計算是兩個不同次元的資源，如果強綁定會極大限制擴充性。對資料系統來說，應用節點和存儲節點分離就是應用了存儲計算分離的設計思想，讓應用和存儲都能獨立擴充。
Scale-out 具備更好的靈活性和經濟性，計算和存儲進行 Scale-out 的常見技術手段包括：
- 存儲 Scale-out
- 通常采用資料分片技術，将資料分散到多台機器上。
- 計算 Scale-out
- 無狀态計算：計算不依賴任何狀态，可以發生在任意節點上，是以計算節點可非常容易實作 Scale-out，但需要解決計算排程問題。常見 Web 應用中的 LoadBalancer 後置一堆 Web Server 就是一個簡單的無狀态計算擴充架構。
- 有狀态計算：計算依賴狀态，計算的擴充依賴狀态的遷移。如果狀态不可遷移，那計算的擴充隻能采取 Scale-up 的方式。如果狀态可遷移，那計算就可實作 Scale-out，此時計算的可擴充性依賴于狀态遷移的靈活性。對于可 Scale-out 的計算我們分為兩類實作方式，分别是：
- 基于狀态路由計算：通常用于狀态遷移代價大的資料架構，比如資料庫的分庫分表。分庫分表的擴充需要進行資料複制，是以通常需要提前規劃，根據資料所在分片來路由計算。
- 基于計算複制狀态：如果狀态能非常靈活的複制或者是共享，那可基于計算來複制狀态，是一種更靈活的計算擴充架構。比如說基于共享存儲的大資料計算架構，可靈活排程任意計算節點對資料進行處理。
可擴充的傳統資料架構
LAMP 架構應用上面提到的擴充技術，演變成了上圖的可擴充的資料架構。應用側通常是無狀态計算，是以可以簡單采取 Scale-out 的擴充方式，前置 Load Balancer 來進行流量排程。存儲側采取分庫分表的方式來進行存儲和計算的擴充，以及隻讀庫的方式來對查詢計算進行擴充。雖然各層具備了擴充能力，但該系統還存在一些問題：
- 存儲側擴充靈活性差，擴充成本較高：計算側通常是無狀态計算節點，擴充相對靈活。但存儲側的擴充需要進行資料複制遷移，擴充周期長且靈活性差。同時 MySQL 的分庫分表每次擴充需要雙倍資源，成本也較高。
- 單一存儲系統，提供的能力有限：MySQL 作為關系模型資料庫，在業務模型抽象上提供極強的抽象能力，是以可以說是一個萬能存儲。在網際網路早期應用負載不高的情況下，MySQL 是最優選擇，且已經擁有了成熟的擴充方案。但是随着應用場景和負載不斷變化，MySQL 還是難以承載。
- 存儲成本高：簡單來說，關系資料庫是結構化資料存儲機關成本最高的存儲系統。
如何解決存儲側擴充問題
MySQL 不是萬能的，但 MySQL 對應用系統來說是不可替換的，到目前為止都是這樣。雖然現在有更多新的雲原生關系資料庫出現來取代傳統 MySQL 的位置，但本質上都脫不了 MySQL 這個殼，隻是更強大的 MySQL 而已。是以很多解決方案都是圍繞 MySQL 作為輔助方案而不是替換方案出現，比如說 Memcached/Redis 這類緩存系統，幫助 MySQL 抵禦大部分查詢流量，來解決 MySQL 容易被查詢打崩的問題。
這個設計思想是『分而治之』，将原本 MySQL 所承擔的職責進行細分，能分離解決的就分離解決。現代資料架構就是基于此思路，仍然以 MySQL 作為應用互動和業務資料存儲的核心，但是使用一些輔助方案解決 MySQL 的問題。
現代資料架構（多樣化系統）
定義問題，分而治之
前面提到 MySQL 是應用系統資料架構的核心存儲，且是不可替換的元件。MySQL 直接承載業務資料和大部分業務互動，現代資料架構的演進思路是圍繞 MySQL 提供輔助解決方案，采用『分而治之』的設計思路。是以我們首先得羅列清楚在單一系統架構中 MySQL 所承擔的職責，以及明确哪些點是可以分而治之的。分而治之的具體手段包括：
- 流量解除安裝：承載和抵禦 MySQL 的部分讀寫流量，讓 MySQL 有更多資源進行事務處理。由于讀和寫依賴 MySQL 内資料，是以在解除安裝流量的同時還會複制全部或者部分資料。
- 資料解除安裝：MySQL 内部分資料會用于事務處理，而部分資料僅存儲和查詢。不參與事務處理的資料可解除安裝，來降低表的存儲量，對降成本和減負載都是有極大好處的。
為友善了解對 MySQL 承載的職責的具體含義，我們對應到一個實際場景來解釋對應的職責，我們以『電商訂單』系統來進行舉例。
| 職責 | 職責描述 | 場景描述 | 可擴充方案 |
| 事務處理 | 要求滿足 ACID 的強事務型操作 | 交易流程和訂單生成是典型的事務處理過程 | 事務處理是關系資料庫的核心職責，不可替換。通常采用 Scale-up 或一些 Scale-out 分布式解決方案。 |
| 資料查詢 | 不需要進行事務處理的簡單查詢 | 訂單狀态查詢或者是曆史訂單查詢 | 隻讀庫（流量解除安裝）：抵禦部分流量，使用簡單。 前置緩存（流量解除安裝）：常見手段，能抵禦很大部分流量，有擊穿風險。 寬表存儲（流量解除安裝+資料解除安裝）：能抵禦大部分流量，不會被擊穿，也可承擔資料解除安裝職責。 |
| 資料檢索 | 模糊查詢、全文檢索、任意字段組合條件查詢等進階查詢特性 | 根據訂單的多條件進行組合查詢，根據訂單商品進行全文檢索等 | 隻讀庫（流量解除安裝）：檢索效率低下，但使用簡單。 搜尋引擎（流量解除安裝）：提供高效查詢，使用和運維比較複雜。 |
| 資料分析 | 對資料進行 OLAP 分析 | 報表分析 | 隻讀庫（流量解除安裝）：流量解除安裝，複制全部資料。 數倉（流量解除安裝+資料解除安裝）：分析能力強，也可承擔資料解除安裝職責。 |
| 資料存儲 | 低成本存儲全量資料 | 要求留存所有訂單，不可删除曆史訂單 | 寬表存儲（流量解除安裝+資料解除安裝）：可提供查詢來解除安裝流量，也可解除安裝資料。 備份歸檔（資料解除安裝）：不可提供查詢，僅解除安裝資料。 |
事務處理一般是需要根據資料庫内的一緻的狀态決定操作的執行，必須要有 ACID 的保證，這部分隻能由 MySQL 來承載。MySQL 的大部分查詢流量都是可被解除安裝的，最簡單的是建立隻讀庫來解除安裝查詢流量，但某些複雜查詢操作隻讀庫無法很高效的執行，必須依賴外部存儲來加速，比如說資料搜尋和資料分析。是以這部分流量需要解除安裝，并且需要複制部分或者全部資料。另外 MySQL 記憶體儲的資料并不會都用于事務處理，很大一部分資料在生成後僅提供查詢或非事務型操作，這部分資料的查詢流量和存儲都是可被解除安裝的。
我們把職責給定義清楚後，也明确了哪些職責是 MySQL 主要承擔的，哪些職責是可以被解除安裝進而得以有效的『分而治之』的。
在理清了整個解決問題的思路後，接下來才是對架構師最大的挑戰：如何選擇合适的元件來解除安裝流量或者存儲？
選擇合适的存儲元件
根據場景定義需求
準确的定義需求是選對元件的前置條件，切勿僅根據功能性需求來進行比對，還需考慮一些基礎性需求，例如存儲元件可提供的 SLA、資料可靠性、擴充性、可運維性等等。從上面的表中，我們能夠非常清晰的看到對各元件的功能性需求，那接下來我們再看看基礎性需求如何區分和選擇。
在做資料系統設計時可以把應用資料嘗試落在上圖的不同周期内，看下如何對存儲元件定義合适的基礎性需求。通常應用系統最先産生的是事務資料，事務資料會逐漸向線上資料、離線資料轉換和流動，線上性逐漸降低，從面向前台逐漸轉向背景。再看從事務資料到離線資料，基礎性要求的具體變化：
- SLA 要求逐漸從高到底，線上系統對穩定性要求極高，而背景系統相對來說要求可放低。
- 從 TP 逐漸轉向 AP，TP 對通路延遲要求更高，而 AP 對分析能力要求更高。
- 資料的更新頻率逐漸降低，逐漸歸檔為不可變資料，是以很多離線系統都是基于資料的不可變性來做存儲和計算優化。
- 存儲成本逐漸降低，資料規模逐漸增大。
存儲元件的種類和差異
先從宏觀層面比較下資料庫類存儲元件的差異：
- 資料模型和查詢語言：這兩個點仍然是不同資料庫最顯著的差別。關系模型、文檔模型和寬表模型是相對抽象的模型，而類似時序模型和圖模型等其他非關系模型是相對具象的模型。抽象模型表達力更強，而具象模型更貼近具體場景。
- SQL vs NoSQL：SQL 類更适合事務處理，包含開源或商業關系資料庫；NoSQL 類更适合非事務資料處理，基本是以開源為主；場景使用上可以與 SQL 類配合使用，提供流量解除安裝和存儲解除安裝；另外 NoSQL 類更多是具象模型，貼近場景而生。
- 資料庫 vs 資料倉庫：資料倉庫更偏離線資料分析，提供更大規模存儲，但是在 SLA 和穩定性方面相比資料庫略差。
- 雲托管 vs 雲原生：雲原生的本質是利用雲上池化資源來實作更強的彈性，是以簡單把一個開源軟體托管在雲上，并不能稱之為雲原生。雲原生帶來的優勢是更低使用成本、更低運維成本、更靈活的資料流轉以及更彈性的架構。
我們看下目前主流開源資料庫以及對應的雲原生資料庫産品的對比：
| 分類 | 存儲成本 | 資料規模 | 承擔職責 | 開源産品 | 雲原生産品 |
| 關系資料庫 | 高 | 中 | MySQL, PostgreSQL | PolarDB | |
| 記憶體鍵值資料庫 | 極高 | 低 | 高并發查詢 | Redis，Memcached | Tair |
| 搜尋引擎 | Elasticsearch，Solr | OpenSearch, Tablestore | |||
| 分布式寬表資料庫 | 高并發查詢，存儲解除安裝 | HBase, Cassandra | Tablestore | ||
| 分析型資料庫 | ClickHouse, Greenplum | ADB, Hologres |
在做存儲元件選型時，要考慮功能性需求和基礎性需求，選擇合适的存儲元件。以上表格隻是列舉了部分場景和其中推薦的産品，這些産品不是唯一選擇也不一定是最适合的選擇，因業務不同發展階段和需求而異。選擇對存儲元件是一件很難的事，是以架構師在設計資料架構時，要提前考慮到存儲元件的新增或替換，資料架構必須具備這樣的靈活性，因為『建構快速疊代能力比應對未知需求的擴充性更重要』。
在一個複雜的應用系統中，必然會存在多套存儲元件的組合，而不是單一的存儲元件來支撐所有的場景和流量，是以架構師還得面臨下一個難題：如何合理的組合這些存儲元件？
合理的進行組合
派生資料架構
在資料系統架構中，我們可以看到會存在多套存儲元件。對于這些存儲元件中的資料，有些是來自應用的直寫，有些是來自其他存儲元件的資料複制。例如業務關系資料庫的資料通常是來自業務，而高速緩存和搜尋引擎的資料，通常是來自業務資料庫的資料同步與複制。不同用途的存儲元件有不同類型的上下遊資料鍊路，我們可以大概将其歸類為主存儲和輔存儲兩類，這兩類存儲有不同的設計目标，主要特征為：
- 主存儲：資料産生自業務或者是計算，通常為資料首先落地的存儲。在應用系統資料架構中，MySQL 就是主存儲。
- 輔存儲：資料主要來自主存儲的資料同步與複制，輔存儲是主存儲的某個視圖，通常面向資料查詢、檢索和分析做優化。在應用系統資料架構中，承擔流量解除安裝或存儲解除安裝的存儲元件，就是輔存儲。
這種主與輔的存儲元件相輔相成的架構設計，我們稱之為『派生資料體系』。在這個體系下，最大的技術挑戰是資料如何在主與輔之間進行同步與複制。
上圖我們可以看到幾個常見的資料複制方式：
- 應用層多寫：這是實作最簡單、依賴最少的一種實作方式，通常采取的方式是在應用代碼中先向主存儲寫資料，後向輔存儲寫資料。這種方式不是很嚴謹，通常用在對資料可靠性要求不是很高的場景。因為存在的問題有很多，一是很難保證主與輔之間的資料一緻性，無法處理資料寫入失效問題；二是資料寫入的消耗堆積在應用層，加重應用層的代碼複雜度和計算負擔，不是一種解耦很好的架構；三是擴充性較差，資料同步邏輯固化在代碼中，比較難靈活添加輔存儲。
- 異步隊列複制：這是目前被應用比較廣的架構，應用層将派生資料的寫入通過隊列來異步化和解耦。這種架構下可将主存儲和輔存儲的資料寫入都異步化，也可僅将輔存儲的資料寫入異步化。第一種方式必須接受主存儲可異步寫入，否則隻能采取第二種方式。而如果采用第二種方式的話，也會遇到和上一種『應用層多寫』方案類似的問題，應用層也是多寫，隻不過是寫主存儲與隊列，隊列來解決多個輔存儲的寫入和擴充性問題。
- CDC（Change Data Capture）技術：這種架構下資料寫入主存儲後會由主存儲再向輔存儲進行同步，對應用層是最友好的，隻需要與主存儲打交道。主存儲到輔存儲的資料同步，則可以再利用異步隊列複制技術來做。不過這種方案對主存儲的能力有很高的要求，必須要求主存儲能支援 CDC 技術。
『派生資料體系』是一個比較重要的技術架構設計理念，其中 CDC 技術是更好的驅動資料流動的關鍵手段。具備 CDC 技術的存儲元件，才能更好的支撐資料派生體系，進而能讓整個資料系統架構更加靈活，降低了資料一緻性設計的複雜度，進而來面向高速疊代設計。MySQL 的 CDC 技術是比較成熟的，也演化出來一些中間件和雲産品，比如 Canal 以及阿裡雲的 DTS。是以在我們的現代應用系統資料架構中，也主要是基于 MySQL 的 CDC 技術來進行資料派生。
現代應用系統資料架構
上圖就是一個典型的現代應用系統資料架構，我們來系統的看下：
- 由多存儲元件構成，每個存儲元件各司其職：
- MySQL：承載事務處理，為整個資料架構的主存儲，其餘元件承擔流量解除安裝和存儲解除安裝的職責。
- Redis：作為 MySQL 的查詢結果集緩存，幫助 MySQL 來抵禦大部分的查詢流量，但 Redis 如果失效，則會有擊穿 MySQL的風險。
- Elasticsearch：反向索引和搜尋引擎技術能提供 MySQL 索引所無法支援的高效模糊查詢、全文檢索和多字段組合條件過濾的能力，是以主要是承擔複雜查詢的流量解除安裝。
- HBase：分布式 KV 存儲，提供寬表模型。可用于解除安裝 MySQL 内非事務性資料，可存儲 MySQL 内所有表的全量資料，提供低成本的存儲解除安裝。HBase 也是一個線上系統，是以也能提供簡單查詢的流量解除安裝。
- ClickHouse：MPP 架構的開源數倉，具備非常優異的分析性能，主要職責是分析流量解除安裝。
- 基于 MySQL CDC 的派生資料架構，由開源産品 Canal 來做實時資料同步。但這裡 ClickHouse 的資料同步并不一定需要是實時增量的，也可采用 T+1 的全量同步方式。
- 應用系統需要與這些不同元件分别進行互動，且互動接口各不相同。
這個架構具備一定的靈活性，通過 Canal 來解決異構存儲間的資料同步問題，通過插件機制可靈活增加新的存儲元件來應對未來的新的需求。每個元件都是開源界打磨多年的成熟産品，也有一些中間件來降低應用與這些元件的互動成本。但也存在一些明顯的問題：
- 運維成本極大：運維是一門技術活，需要對元件的原理有比較清楚的了解才能更好的運維，以及進行線上問題的排查和優化。這些開源産品已經将使用成本降的足夠低，但是運維成本還是很高，比如 HBase 元件的運維還需要額外運維 Zookeeper、HDFS 等。雲托管産品降低了一定的運維成本，但仍無法做到免運維，業務 OPS 仍需要花大量精力在性能調優、容量規劃等工作上。另外多元件會比單元件運維成本更高，因為還需要管理元件間的資料流。
- 多 API 互動複雜：每個元件都提供了不盡相同的 API，應用與不同元件的互動很難抽象和解耦。
- 成本高：每一個新的元件的引入都需要額外的存儲和計算成本，但各元件的偏向不一樣，有的更重計算有的更重存儲。如果多元件間能共享計算或存儲，那能極大的降低成本。而在目前的架構中，每個元件都是互相獨立的，需要獨享存儲和計算資源。
雲上資料架構實踐
把現代資料架構搬到雲上，可利用雲的優勢來優化整套架構：一是找到合适的雲原生産品替換開源産品，最大好處是降低運維成本，其次能獲得更強的穩定性和性能；二是用更少的元件做更多的事，來降低管理和使用成本，也能降低應用互動開發複雜度。
以上就是完整的雲上資料架構，重點講下替換開源元件的幾個雲産品：
- DTS（資料傳輸服務）：原理與 Canal 類似，能對接更多資料庫上遊和下遊，全托管的 MySQL 實時資料同步中間件。
- Tair（Redis 企業版）：阿裡自研企業級緩存，相容 Redis 協定，具備更強的性能。
- Tablestore（表格存儲）：阿裡自研 Bigtable，提供相容 HBase 的寬表引擎，以及能力和性能都優于 Elasticsearch 的索引引擎。純 Serverless 免運維能最大程度降低運維成本，同時提供 API 和 SQL 的接口降低應用開發成本。
- ADB（分析型資料庫）：阿裡自研實時數倉，具備強大的分析性能，完全相容 MySQL 協定。
接下來我們再重點提下 Tablestore，因為在應用系統線上場景，Tablestore 承載了流量解除安裝和存儲解除安裝的重要職責。Tair 的使用和定位與 Redis 完全一緻，而 Tablestore 相比 HBase 和 Elasticsearch 有更大的差異性。
表格存儲 Tablestore
表格存儲 Tablestore 是阿裡雲自研的面向海量結構化和半結構化資料存儲的 Serverless 多模型結構化資料存儲，被廣泛用于社交、物聯網、人工智能、中繼資料和大資料等業務場景。采用與 Google Bigtable 類似的寬表模型，天然的分布式架構，能支撐高吞吐的資料寫入以及 PB 級資料存儲，具體産品介紹可以參考
官網以及
權威指南。
Tablestore 提供相容 HBase 的寬表引擎，以及能力和性能都優于 Elasticsearch 的索引引擎，它的核心能力包括：
- 多模型：提供抽象模型 WideColumn 寬表模型，以及具象模型 Timeline 消息模型以及 Timestream 時序模型。具象模型更适合應用與應用系統，而具象模型是圍繞具體場景的資料架構而設計和深度優化。
- 多元化索引：提供二級索引和多元索引，不同查詢加速場景提供不同的索引實作，其中多元索引能提供全文檢索、地理位置檢索以及靈活的多條件組合查詢，功能和性能都優于 Elasticsearch。
- 存儲計算分離架構：提供計算和存儲側的靈活擴充能力，不僅展現在架構上，也展現在産品形态上。使用者可以單獨為存儲付費或為計算付費，提供更靈活的資源組合，獲得最低的成本。
- Serverless 服務：純 Serverless 服務，提供完全免運維的服務，全球部署、即開即用。零成本即可接入，最大可擴充至千萬 TPS 服務能力以及 PB 級存儲。
- 計算生态：能夠與開源計算引擎對接，融合流批一體計算能力。同時自身提供 CDC 能力，讓資料能夠更靈活的進行流轉。
- CDC 技術：Tablestore 的 CDC 技術名為 Tunnel Service，支援全量和增量的實時資料訂閱，并且能無縫對接 Flink 流計算引擎來實作表内資料的實時流計算。
- SQL 支援：提供 SQL 支援，大大降低使用和應用開發門檻。
場景實踐
為友善讀者特别是開發者更好的了解雲上應用系統資料架構的具體實作，我們特此準備了一個完整的實踐 《基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐》。在該實踐中會以訂單系統為例，從需求出發來講解本文中提到的『分而治之』設計思想的應用，以及如何實作存儲解除安裝（存儲分層）、查詢、搜尋、流批計算等，并給出具體的操作和代碼。
《
基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-架構篇》
基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-資料同步 DTS 篇 基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-資料同步 Canal 篇 基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-訂單搜尋篇 基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-SQL 查詢和分析 基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-基于 DLA 的聯邦查詢 基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-資料處理ETL篇 基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-曆史資料分析篇 基于 MySQL + Tablestore 分層存儲架構的大規模訂單系統實踐-資料流計算篇總結
技術架構的選擇沒有統一标準答案，是一個綜合的權衡考慮。本文主要介紹了應用系統資料架構的變遷，我相信随着應用場景越來越複雜、更多需求的提出，随着底層基礎設施的完善，會有更多新技術和産品出現，而資料架構也會繼續演進。但是一些經典的設計思想會保留，例如分而治之、派生資料架構、如何靈活的選擇群組合存儲和計算元件等。
希望本次分享對你設計資料架構有幫助，如果希望繼續交流，可以加入我們的開發者技術交流群，可搜尋群号『11789671』或『23307953』，亦可直接掃碼加入。