ots 是open table service的簡稱，現在已更名為**儲存table store，官網對它的解釋為：ots是構建在阿里雲飛天分布式系統之上的 nosql 資料庫服務，提供海量結構化資料的儲存和實時訪問。ots 以例項和表的形式組織資料，通過資料分片和負載均衡技術，達到規模的無縫擴充套件。ots 向應用程式遮蔽底層硬體平台的故障和錯誤，能自動從各類錯誤中快速恢復，提供非常高的服務可用性。ots 管理的資料全部儲存在 ssd 中並具有多個備份，提供了快速的訪問效能和極高的資料可靠性。使用者在使用 ots 服務時，只需要按照預留和使用的資源進行付費，無需關心資料庫的軟硬體公升級維護、集群縮容擴容等複雜問題。
上面的介紹我們可以簡單的概括為：ots是乙個nosql的資料庫(你可以將它模擬為hbase)，在使用方面我們可以將ots模擬為乙個技術黑箱，它已經為我們把儲存擴容、資料備份、負載均衡等工作做了，使用過程中我們只需透明的使用其提供的高可用和高併發的特性即可。
估計很多人看了上面的介紹加上對上面提到的hbase不是很了解，現在對於ots還是有很多疑問。沒關係，接下來將它和傳統關係型資料庫mysql、sqlserver等做乙個比較，或許這下你就能更加清晰的認識ots了。
ots的資料模型也是以二維表為中心的，表有行和列的概念，但是與傳統資料庫不一樣，ots的表是稀疏的，稀疏指的是它的每一行可以有不同的列，可以動態增加或者減少屬性列，建表時不需要為表的屬性列定義嚴格的schema。相對於傳統資料庫的豐富功能（檢視、索引、事務、豐富的sql語句支援），ots提供較為基礎的功能，但是具有更好的規模擴充套件性，能夠較容易的支援更大的資料規模（百tb級別）和併發訪問（單錶10萬qps）。在程式設計方面，ots提供統一的http restful api，不支援傳統的sql語句標準。
對ots做了初步的了解後，那麼問題來了，它有什麼特性，在儲存產品如此豐富的現狀下我們有什麼理由去選用它呢？
它的主要特性我們可以大致概括為以下幾個方面：
擴充套件性
應用在建立表的時候，需要根據業務訪問的情況來配置預留讀寫吞吐量。ots 根據表
的預留讀寫吞吐量進行資源的排程和預留，從而保證應用獲得可預期的效能。在使用
過程中，應用還可以根據應用的情況動態修改預留讀寫吞吐量。
資料可靠性
高可用性
管理便捷
靈活的資料模型
監控整合
這些概括性的對ots的特點進行了描述，具體量化的服務提供標準如可用率等可以參見官網：
**儲存（table store）服務等級協議
單錶百tb級別資料規模，十萬級別qps。(傳統單機資料庫的100倍)
10毫秒級別單行讀寫延遲
分鐘級別單機故障恢復時間
ots資料模型概念包括表、行、主鍵和屬性。
表是行的集合，行由主鍵和屬性組成。主鍵列和屬性列均由名稱和值組成。表中的所有行都必須包含相同數目和名稱的主鍵列，但每行包含的屬性列的數目可以不固定，名字和資料型別也可以不同。
與主鍵列不同，每個屬性列可以包含多個版本，每個版本號(時間戳)對應乙個列值。
圖示如下：
對於接觸過資料庫的人來說，理解上面的模型不是很困難，同樣也有主鍵和屬性列之分，但需要我們注意的是復合主鍵最多只能包含4列，此外讓我們疑惑的是模型裡面出現了分割槽鍵(partition key)這個概念，這又是幹什麼的？
還記得我們在說ots特點的時候第乙個就提到了它的擴充套件性，對於ots來說擴充套件性是它很大的乙個亮點，而要實現它的擴充套件性，與分割槽鍵的關係密不可分。
在ots儲存中，一張大表會被自動的切分成很多個資料分割槽（也叫partition），這些partitions被盡量均勻的排程到不同的儲存節點上進行資料的儲存和請求的處理。當乙個partition的資料規模增長到一定大小或者這個partition上的請求過熱，可以對這個partition進行**，**成資料規模更小的兩個partition，也對落到原先這個partition上的請求進行了分攤。**之後的partition會被遷移到不同的儲存節點上，從而減小原始節點上的訪問壓力。當機器資源不足進行擴容時，也可以觸發partition的遷移從而達到資料和訪問壓力的均衡。通過partition的切分、**和遷移等機制，ots支援資料和訪問規模的動態伸縮。一般情況下，我們將組成主鍵的第乙個主鍵列作為分割槽鍵，具有相同分割槽鍵的行屬於同乙個分片，乙個分片可能包含多個分片鍵。分片的過程是自動進行的，無需使用者進行干涉。
我們需要牢記的是，分割槽鍵對於ots來說是乙個很重要的因素，我們在設計表結構的時候一定要根據應用需求設計出乙個合理的分割槽鍵，設計的一些準則和建議可以參考這篇文章——ots最佳實踐——設計良好的主鍵
ots一共支援五種型別的列值string、integer、double、boolean、binary。每種型別有如下限制：型別值
能否作為主鍵
空間占用限制
string
utf-8 字串，可以為空字串
是不超過 64kb，如果為主鍵列不超過1kb
integer
範圍為 -2ˆ63 ~ 2ˆ63-1 的 64 位整型
是固定 8byte
double
範圍為 -10ˆ308 ~ 10ˆ308 的雙精度浮點數
否固定 8byte
boolean
值為 true 或 false
否固定 1byte
binary
二進位制資料，可以為空
否不超過64kb
listtable -- 列出例項下的所有表
createtable -- 建立表
deletetable -- 刪除表
describetable -- 獲取表的屬性資訊
updatetable -- 更新表的預留讀寫吞吐量配置
在ots中開發者是通過統一的http restful api來完成上述操作的。詳細的操作說明，和資料的格式請參考官網文件：api操作概覽
看到這裡我們對於ots已經有了乙個大致的了解，它有很多特別的優點，但任何一款產品並不是萬能的，並不能適用於所有的領域。下面我們來看看根據ots的這些特性，它針對那些應用場景特別適用：
低延時、高併發，彈性資源可以讓的風控系統永遠工作在最佳狀態，牢牢控制交易風險，靈活的資料結構能夠讓業務模式跟隨市場需求快速迭代。
大量的交易訂單及物流跟蹤資訊，使用ots能夠讓使用者無需擔心資料規模，它的彈性資源，可以從容應對節日**活動。
目前阿里內部採用ots的產品有:
雲os雲空間
釘釘即時聊天、使用者關係和行為跟蹤資料
**鳥tcif
odps meta儲存
我們通過乙個例子來應用下上面的知識點，加深對ots的理解吧。
我們就拿ots典型的手機雲空間這個例子來做說明：
應用需求
基於ots的解決方案
表結構設計模型
使用者表
使用者id
簡訊數目
聯絡人數目
總容量u0001
2000
200100,000,00
u0002
1024
500100,000,00
......
......
簡訊表
使用者id
接收時間
唯一id
對方號碼
簡訊內容
簡訊型別
u0001
2016-08-09
0001
123456
hello
接收u0002
2016-08-09
0002
123445
hi傳送
......
......
......
使用者其他資訊的**設計類似於簡訊表。我們可以看到對於這些不同的表，我們可以將使用者id作為其分割槽鍵這樣同一使用者的所有資訊都會儲存在同一資料分割槽下，讀寫遍歷的同時，也可以支援對同一使用者不同表資料的事務操作。
文章為了讓大家快速認識ots有些細節東西沒有講，例如這裡提到的事務操作，在ots中同樣可以支援事務的提交和回滾操作，事務可以應用在同乙個表中，也可以應用在同一分割槽下的**中。對於這些細節部分大家可以看官文的幫助文件進行學習：ots官方幫助文件接著我們的分析，我們簡訊表中有個唯一id這個屬性列，這個列起到的作用是防止主鍵重複，我們知道在所有的資料庫中主鍵可用於唯一區分資料庫不同的行不能重複，但有些情況下當我們用幾個屬性列設定了復合主鍵後依然會有重複的可能例如這裡的簡訊表，這時候我們就可以引如乙個沒有實際意義的屬性列作為復合主鍵中的唯一區分不同行的變數因素，這就是唯一id屬性段的作用。
其他的一些分析不是很難，大家按照自己的理解即可。可以看到當我們熟悉關係型資料庫的使用後，理解和使用ots沒有多大的障礙。
OTS資料遷移驗證方案
ots在業務停寫的情況下，可以通過datax工具對ots資料的全量遷移。本文描述了在進行業務割接的情況下，ots資料的全量遷移配置方法，以及資料校驗方法。tablestore客戶端工具機 在本地安裝 儲存客戶端管理工具，提供圖形化的操作介面，用於建立 更新和刪除資料表。datax資料遷移工具機 安裝...
用實驗快速認識NIS
二.配置nis客戶端。1.機器2作為nis客戶端，檢查機器2是否安裝了下列包 portmap ypbine yp tools authconfig 缺什麼包，安裝什麼包。2.機器2確認服務端開啟portmap服務 rpcinfo p 192.168.0.1 3.機器2用authconfig工具，配置...
快速認識抽象工廠模式
抽象工廠模式 abstract factory pattern 是圍繞乙個超級工廠建立其他工廠。該超級工廠又稱為其他工廠的工廠。這種型別的設計模式屬於建立型模式，它提供了一種建立物件的最佳方式。在抽象工廠模式中，介面是負責建立乙個相關物件的工廠，不需要顯式指定它們的類。每個生成的工廠都能按照工廠模式...