訂單系統存在於各行各業，如電商訂單、銀行流水、運營商話費賬單等，是乙個非常廣泛、通用的系統。對於這類系統，在過去十幾年發展中已經形成了經典的做法。但是隨著網際網路的發展，以及各企業對資料的重視，需要儲存和持久化的訂單量越來越大。資料的重視程度與資料規模的膨脹帶來了新的挑戰，原有的系統是否還能繼續滿足需求成了焦點？
某電商平台a，需要進行持久化所有平台產生的訂單資料。同時，基於所有的訂單資料，系統又需要向外提供面向多種角色：消費者、店家、平台三類人群的多元化的查詢服務。消費者可以查詢自己的歷史訂單，商家可以統計熱銷產品，平台也可以分析使用者行為、平台交易規模等。主要查詢方式涵蓋訂單的多維度檢索，以及訂單資料的分析、統計等，例如：
面向消費者：【a消費者】*【近1年】*【產品名含'電腦'字段】訂單查詢；
面向店家：【b店家】*【近1個月】*【每個產品】銷售量排名；
......
在訂單場景中，技術上通常需要考慮的技術點，主要包含如下幾個方面：
應對訂單場景，電商通常會採用mysql傳統方案。借助關係型資料庫強大的查詢能力，使用者可直接通過sql語句實現訂單資料的多維度查詢、資料統計等。所謂資料膨脹，分為橫向、縱向兩種，橫向即不斷迭代引入的新字段維度，縱向即總的儲存資料量。在面對這兩種訂單資料膨脹上，單mysql方案逐漸變得吃力。 sql + nosql的組合方案（以下稱：組合方案）便應運而生，借助兩個資料庫各自的優勢分別解決不同場景各自的需求。但組合方案同樣也帶來了新的問題，組合方案犧牲空間成本，同時也增加了開發工作量與運維複雜度。在保證資料一致性上產生額外開銷。
下面讓我們看一下如下幾個常規方案：
mysql自身擁有強大的資料查詢、分析功能，基於myqql建立訂單系統，可以應對訂單資料多維查詢、統計場景。伴隨著訂單資料量的增加，使用者會採取分庫、分表方案應對，通過這種偽分布式方案，解決資料膨脹帶來的問題。但資料一旦達到瓶頸，便需要重新建立更大規模的分庫+資料的全量遷移，麻煩就會不斷出現。資料迭代、膨脹帶來的困擾，是mysql方案難於逾越的。僅僅依靠mysql的傳統訂單方案短板凸顯。
1、資料縱向（資料規模）膨脹：採用分庫分表方案，mysql在部署時需要預估分庫規模，資料量一旦達到上限後，重新部署並做資料全量遷移；
2、資料橫向（字段維度）膨脹：schema需預定義，迭代新增新字段變更複雜。而維度到達一定量後影響資料庫效能；
引入雙資料的方案應運而生，通過實時資料、歷史資料分存的方案，可以一定程度解決資料量膨脹問題。該方案將資料歸類成兩部分儲存：實時資料、歷史資料。同時通過資料同步服務，將過期資料同步至歷史資料。
1、實時訂單資料（例如：近3個月的訂單）：將實時訂單存入mysql資料庫。實時訂單的總量膨脹的速度得到了限制，同時保證了實時資料的多維查詢、分析能力；
2、歷史訂單資料（例如：3個月以前的訂單）：將歷史訂單資料存入hbase，借助於hbase這一分布式nosql資料庫，有效應對了訂單資料膨脹困擾。也保證了歷史訂單資料的持久化；
但是，該方案犧牲了歷史訂單資料對使用者、商家、平台的使用價值，假設了歷史資料的需求頻率極低。但是一旦有需求，便需要全表掃瞄，查詢速度慢、io成本很高。而維護資料同步又帶來了資料一致性、同步運維成本飆公升等難題；
組合方案還有mysql+elasticsearch，該方案同樣是將資料分兩部分儲存，可以一定程度解決訂單索引維度增長問題。使用者自己維護資料同步服務，保證兩部分資料的一致性；
1、全量資料：將全量的訂單資料存入mysql資料庫，訂單id之外的資料整體存為乙個字段。該全量資料作為持久化儲存，也用於非索引欄位的反查；
2、查詢資料：僅將需要檢索的字段存入elasticsearch（基於lucene分布式索引資料庫），借助於elasticsearch的索引能力，提供可以應付維度膨脹的訂單資料，然後必要時反查mysql獲取訂單完整資訊；
該方案應付了資料維度膨脹帶來的困擾，但是隨著訂單量的不斷膨脹，mysql擴充套件性差的問題再次暴露出來。同時資料同步至elasticsearch的方案，開發、運維成本很高，方案選擇也存在弊端。
能力分析
mysql
hbase
elasticsearch
tablestore
儲存方式
行儲存列儲存
索引儲存
列儲存+索引儲存
擴充套件性單機、擴充套件性差
水平擴充套件
水平擴充套件
（自動）水平擴充套件
一致性強一致性
強一致性、時序一致性
強一致性、時序一致性
檢索較弱的支援
不支援支援
支援資料量
~ 1t，~億行
~10 pb，~萬億行
~1 pb，~千億行
~10 pb，~萬億行
如果使用**儲存（tablestore）研發的多元索引（searchindex）方案，則可以完美地解決以上問題。tablestore具有即開即用，按量收費等特點。多元索引隨時建立，是海量電商訂單元資料管理的優質方案。
tablestore作為阿里雲提供的一款全託管、分布式nosql型資料儲存服務，具有【海量資料儲存】、【熱點資料自動分片】、【海量資料多維檢索】等功能，天然地解決了訂單資料大**這一挑戰；
同時，searchindex功能在保證使用者資料高可用的基礎上，提供了資料多維度搜尋、統計等能力。針對多種場景建立多種索引，實現多種模式的檢索。使用者可以僅在需要的時候建立、開通索引。由tablestore來保證資料同步的一致性，這極大的降低了使用者的方案設計、服務運維、**開發等工作量。
TableStore 的注意事項
公司使用阿里的 tablestore 以下簡稱 ts 已經有些日子了。這周仔細翻閱了一下 tablestore 的官方文件。現對 tablestore 做一些總結。我們先來了解一下什麼是 tablestore。儲存 table store 是阿里雲自研的 nosql 多模型資料庫，提供海量結構化資料...
基於sersync海量檔案實時同步
基於sersync海量檔案實時同步 專案需求 最近涉及到數百萬張從本地儲存遷移到雲儲存，為了使完成遷移，並保證無缺失，業務不中斷，決定採用實時同步，同步完後再做流量切換。在實時同步方案中進行了幾種嘗試。方案1 rsync inotify同步，最先想到的是此方案，先看下指令碼 此前在多台伺服器間同步 ...
基於海量資料的關聯規則挖掘（五）
2.1基於hash的方法 首先是基於雜湊的演算法。基於雜湊的演算法仍是將所有所有資料放入記憶體的方法。只要在計算的過程中能夠滿足演算法對記憶體的大量需求，apriori 演算法能夠很好的執行。但在計算候選項集時特別是在計算候選項對 c2時需要消耗大量記憶體。針對 c2候選項對過大，一些演算法提出用來...