本次分享的主題是阿裡巴巴海量資料場景下的olap解決方案，主要是也為大家介紹一下阿裡巴巴olap存儲的一款産品——histore。大家都知道海量資料，包括大資料和資料倉庫這些在當下都是非常熱門的話題，大家都比較關心這個領域，是以這個領域也成為了各大廠商的必争之地，為什麼？原因很簡單，就是在未來，大家的不同就在于對于資料了解的不同，換句話說就是未來屬于能夠真正地讀懂資料的人。
本次的分享将主要圍繞以下四個方面進行：
一、histore産品的由來以及它所能夠應對的場景以及能夠解決的痛點
二、結合現實已經落地的成功案例幫助大家 了解histore的應用場景以及histore能夠為業務帶來什麼樣的價值
三、histore在目前海量資料、大資料以及資料倉庫領域的定位
四、histore的核心技術、架構設計以及優化思路
一、why histore？
業界的痛點
那麼業界的痛點在哪裡呢？從傳統網際網路資料到移動網際網路資料，再到現在很熱門的iot，實際上随着每一次業界的進步，資料量而言都會出現兩到三個數量級的增長。而且現在的資料增長呈現出的是一個加速增長的趨勢，是以現在提出了一個包括移動網際網路以及物聯網在内的網際網路大資料的5大特征：volume、 velocity、 variety、 value、 veracity。同時也出現了一些問題，第一問題就是成本，成本問題是一個日益突出的問題，大家也知道，就是半年前ssd的硬碟架構飙漲了一倍，可以說已經趕上了房價的漲幅，現在的情況是硬體成本如此之高，即便是再土豪的公司也需要考慮成本的問題。另外一個問題就是在這麼大的資料量的背景下，讓資料發揮出自己應該有的價值，實際上需要高效的聚合和查詢分析。如果想要讓大資料分析出來的趨勢更加精确，能夠帶來更高的參考價值，就需要更多的次元，但是次元更多則會帶來更多技術上的困難。另外就是實時性，在某些場景下需要大資料呈現實時或者準實時的結果。另外就是遷移和學習的成本，其實很多公司也都在考慮怎樣去遷移資料以及怎樣更加友善的接入大資料的産品。
現在提到大資料，其實大家第一反應就是hadoop體系的産品非常之多，讓人眼花缭亂。在這裡也為大家簡單地梳理一下hadoop技術棧的主要産品：第一代的hdfs、mapreduce産品，可以說太慢了，逐漸引進到第二代，第二代就是通過記憶體cache等增加吞吐量的方式産生了spark等産品，這時候性能得到了進一步的提升。再往後就是如果想要實作一個複雜任務的話，使用mapreduce就會是一個比較複雜和麻煩的事情，那麼就會考慮到是不是使用腳本或者sql的方式就會更簡單呢？因為sql比較簡單，那麼就産生了hive和pig，而且現在逐漸比較流行了，到了這一步就已經引入了sql了。sql已經比較好用了，但是這時候在某些場景下實際的性能還不夠，應該怎麼辦呢？其實性能還不夠的原因在于之前的mapreduce以及spark這種模型做的太通用、太健壯、太保守了，實際上我們應該在某種程度上更激進地擷取資料，實際上這時候就産生了一些計算層的産品，比如presto，drill，impala。
實際上就是hadoop體系從下往上看就是從最底層的hdfs或者其他的一些分布式檔案系統，到上層的第一代的mapreduce、spark，在往上就是到pig或者hive；另外就是hdfs或者其他檔案系統上直接跑presto，drill，impala；那大規模資料處理的另外一個領域——大規模分布式mpp架構，比如sap的hana，hp的vertica，開源的greenplum等等。
集團内的痛點
那麼，反映到集團内是什麼樣痛點呢？以集團内的某個日志系統為例，它每天會産生幾萬億條日志，每産生的資料将近pb級别的量級，如果使用mysql可能會需要使用數千台，這個成本是不言而喻的。從公司層面看，存儲領域有數十萬台實體機，其中的大概50%用于存儲離線資料，包括曆史資料、日志、軌迹、使用者行為分析資料。其實這部分資料是符合olap的場景的，因為這部分資料的增長速度是加速增長的，是以這部分資料存儲的成本是要控制住的，也是需要關注的。另外就是在如此大的資料量的情況下，在降低成本的同時要保證資料分析的時效性和高性能。
什麼是histore
為了解決前面提到的業内以及集團内面臨的痛點，histore産品就應運而生了。histore産品的定位是分布式低成本olap分析型資料庫産品，是一款基于獨特的知識網格技術的列式資料庫，定位于海量資料高壓縮比列式存儲，是低存儲成本，低維護成本，海量資料olap存儲引擎；有效的解決了海量資料存儲的成本問題，以及在百億資料場景下支援實時高效的多元度自由組合的檢索。而且通過近兩三年的發展，histore在阿裡内部已經應用于多個核心應用，包括菜鳥、 b2b、阿裡媽媽、聚劃算、天貓等，也應用于很多外部使用者，比如在人社部，上海新能源汽車，新零售等超大資料量測試環境都取得了令人信服的結果，無論成本、性能、穩定性都表現完美。
histore提供哪些特性來解決相關問題呢？histore所具有的特性如下圖所示：
基于上面的這些特點，histore具有如下的這些優勢：
海量資料存儲: pb級資料大小，百億條記錄，資料量存儲主要依賴自己提供的高速資料加載工具（tb/小時）和高資料壓縮比（>10:1）。
高壓縮比：平均壓縮比>10:1，遠高于正常壓縮算法，甚至可以達到40:1，極大地節省了資料存儲空間。
基于列存儲：無需建索引，無需分區。即使資料量十分巨大，查詢速度也很快，用于資料倉庫、查詢性能強勁、穩定：億級記錄數條件下，同等的select查詢語句（這裡主要是聚合查詢，多元查詢等等），速度比myisam、innodb等普通的mysql存儲引擎快數十倍。
高性能資料導入：基于mysql協定的并行導入，以及專門的資料預處理入庫工具。
多元分析查詢：實時性的多元度資料檢索；海量資料聚合秒級計算；為實時業務提供保障。
線性擴充：使用者可以輕松實作存儲容量和處理能力的線性提升。
系統易用：遷移成本低，無其它依賴獨立部署，mysql工具及應用可直接無縫運作其上。
快速響應複雜的聚合類查詢：适合複雜的分析性sql查詢，如sum, count, avg, group by。
二、案例分析
接下來會借助一些成功落地的案例幫助大家深入地了解histore産品的使用場景。首先看下圖将histore産品的應用場景做了簡單的分類，這部分場景包括資料分析與商業智能、使用者畫像和使用者行為、曆史資料、分析應用與廣告資料、日志，軌迹，記錄，監控，歸檔、資料倉庫、物聯網資料、存儲成本敏感等。
而以上所有分類的場景都基本具備以下的特點：海量存儲、快速導入、低存儲成本、低接入成本、多元度檢索和複雜分析、并發通路量大、資料實時分析、響應低延遲、資料自動過期、深度挖掘、線性擴充以及生态相容等。
案例1：高德熱力圖
接下來結合幾個實際的案例來分析，第一個案例就是高德熱力圖。大家都知道高德的産品是與地理相關的，它可以拿到每個人的地理資訊，那麼通過這種人地關系以及使用者畫像相結合，就可以實作如下圖中右側所示的界面這樣的顯示出使用者的職業、性别、年齡、教育水準、資産等的使用者畫像。高德能夠将地理位置與使用者畫像結合起來，那麼就能夠迸發出很多的商業價值，比如在确定了目标人群之後，對于商鋪或者商品而言就可以通過這樣的應用分析出潛在的客戶，這樣的産品目前也是高德目前的拳頭級産品。那麼對于這樣的産品而言，在技術實作上有哪些難點呢？第一就是資料量大，萬億級别，導入速度要求高；除此之外就是想要在這麼大的資料量上進行這樣多元度聚合查詢得出趨勢和結論，傳統的mysql資料庫将無法完成，簡單來說傳統mysql資料庫的innodb引擎是b+樹的改進，b+樹實際上是磁盤不友好的資料結構，其在資料查詢和導入的時候會産生大量的随機io，而且随着資料量的增加，b+樹的分列會越來越多，就會導緻資料導入越來越慢，查詢起來也會越來越慢，甚至無法得出結果。
histore産品的引入幫助高德解決的第一個問題就是不管資料量多大，能穩定的在秒級别完成多元度adhoc查詢。其次就是實作了高性能資料導入，實際部署時的百億級别增量資料在兩小時之内就可以完成導入，而之前卻需要至少一兩天的時間，這也是一個非常明顯的優勢。還有就是高壓縮比，機器成本低，可以幫助高德将機器成本降低到原來的十分之一。
案例2：禦膳房項目
禦膳房政策中心項目是阿裡巴巴集團“品銷全營銷，unimarketing”項目中的一部分，産品定位是品牌商品牌發展政策的支援平台，通過從淘寶、天貓、聚劃算等平台收集的海量實時資料，幫助品牌商更高效，更明智地做出品牌發展相關的商業決策。
禦膳房這個項目的第一個特點就是資料量大，另外一個很明顯的特點就是需要聚合的次元非常多，在下圖中就可以看出有非常多的次元，可以到幾百個次元，而且他還需要動态地增加次元，這是什麼意思呢？也就是說可能今天隻有200個屬性，需要在這200個屬性次元上進行資料分析，而明天可能表立馬擴充成300個屬性，那就需要在這300個屬性次元上做資料分析，也就是這種動态地擴充表的次元，以前是沒有辦法實作的，次元上限也很低，一般幾十個次元就到上限了。是以禦膳房在業務上難點和痛點就是商品屬性的次元是動态的,需要支援多元查詢；另外就是查詢的資料量很大，還涉及到了一張8億條資料的表和一張1億條資料的表之間的join。還有就是目前存儲成本太高、穩定性不好且資料導入實時性不夠。
而histore引入的價值和意義就是秒級别的高效穩定的多元查詢，可以支援多達4096列，基本上可以滿足大多數的場景，另外還可以動态增删列: 标準mysql語句alter table就能夠搞定了，而不需要再進行複雜的操作。至于在動态增删列之前的那些資料，比如像null填充、以及預設值等都是可以實作的。另外就是高性能資料導入，十億資料在一個小時加載完成，相對目前方案提升十倍。最後一點就是在存儲成本上有明顯的降低，禦膳房二期全鍊路和透視項目從原來400台高配實體機叢集，替換為50台histore docker機器部署。可以看出使用histore為禦膳房解決了非常大的痛點，帶來了非常大的價值。
案例3：螞蟻體驗平台
我們再來看一個例子-螞蟻體驗平台，這個産品是為了建構一套包含“問題收集、分析、推進、協作、價值衡量”的體系，幫助螞蟻金服自己的産品做良性的改進；友善螞蟻小二對集團的資料進行分析，比如對花呗的幾千萬上億的會員進行畫像分析，進而對于産品做一些改進，這是使用者行為分析以及商業智能的又一個典型的場景。
螞蟻體驗平台所面對的業務痛點就是之前使用mysql方案，單表資料大于2000萬時，查詢經常逾時；特征列不能超過100列，查詢條件越多越慢擴充不友善，并且維護索引非常麻煩。在上圖中右邊這張表中，包含有count (*) [where]條件，有一列、五列和十列的結果，如果使用mysql的話就會随着查詢列數的增加查詢時間明顯增加，從15秒到65秒再到150秒，然而對于histore的單機或者叢集而言，卻可以随着查詢條件的增多查詢的速度反而更快，可以從一個查詢條件時的1秒到5個條件時的0.5秒，再到10個條件的時候不到0.3秒就搞定了，這是一個正好與mysql相悖的情況，這是為什麼呢？其實這與histore的存儲結構相關，簡單講histore的查詢是通過粗糙集過濾的方式實作的，也就是查詢的條件越多，在記憶體時就能夠過濾越多的資料包，最後實際上真正需要解壓做查詢的資料包就會越來越小，這就是為什麼随着查詢條件越多，查詢速度越快的原因。
案例4：全鍊路追蹤系統eagleeye
eagleeye是集團内一款應用廣泛的分布式調用跟蹤系統，主要幫助使用者友善地檢視應用的實時資料及快速定位線上問題，為全鍊路壓測、跨單元分析、鍊路梳理提供資料支撐。而eagleeye系統日志量非常之大，大到每天近萬億條，大概每天會産生數千tb的資料，這個資料量在業内也屬于頂級的一個水準了。另外就是eagleeye系統的資料峰值很高可以達到數千萬的tps，如果使用傳統的mysql成本太高，這樣是吃不消的。
而histore在如此大資料量的場景先，能夠為eagleeye系統實作秒級别的多元度adhoc查詢，做到單機支援數十萬tps寫入，并且實作高壓縮比存儲，為集團節省數千台機器的成本。
三、競品分析
接下來為大家簡單介紹一下大資料領域以及資料倉庫領域，histore産品的定位以及競品分析。
上圖的縱坐标表示的是産品的成熟度，橫坐标表示的是趨勢。從這張圖的最左邊的最傳統的olap的資料庫解決方案，一直到中間第二階段的基于列式存儲的大規模mpp架構的分布式存儲引擎，這部分主要是針對結構化資料，這部分包括惠普的vertica以及sap的hana等都是業内著名的資料倉庫解決方案。大家可以看到histore也在這一部分，但是要偏向于下面一下，因為histore的定位是一個存儲引擎，是以其産品化程度不如vertica以及hana，因為大家都知道hana在上層的資料抽取和資料展現都比較好的。再往右這部分就是big data這部分，這部分主要是解決存儲計算分離，這種半結構化資料或者非結構化資料這樣的異構源，什麼意思呢，舉個例子就是，有一部分非結構化資料存儲在hbase上，另外一部分結構化的資料存儲在mpp架構的histore上面，那如果對于這兩段資料進行join的話，實際上就會使用大資料計算層的技術（如presto，drill）解決這些問題。histore這個産品在大規模mpp架構場景下和hadoop體系以及big data體系下的這兩個方向其實都是有适用場景的，這就是histore的定位。其實大家也能夠感覺到，很多技術的邊界變得越來越模糊，很多元件之間可以互相融合或者互相組合，這也是未來技術的一個大趨勢。
以下是針對于mpp架構的同類産品分析：
但是如果拿histore與上述的這些産品進行比較，histore有什麼優勢呢？舉一個新零售行業的例子，之前它可能會使用sap的hana做資料分析和報表展現，之前的成本可能是一次性花費了500萬，成本非常高。當使用histore評估其場景後發現，其業務與之前提到的一些銷售的單據展現以及bi類似，histore對于其場景以及功能性支援都是可以的，根據資料量來看，使用兩個執行個體就搞定，每個執行個體15萬，30萬就搞定了，也就是可以将原來500萬的成本降低到50萬之内，這也是一個很典型的例子。也就是histore能夠在同樣滿足使用者資料分析需求的前提下将成本盡可能地降低，這也是histore在業内最大的優勢所在。
四、核心技術
下面簡單介紹一下histore的架構和一些核心的技術點：
列式存儲引擎
histore使用的是列存，也就是column-based，它與傳統的row-based不同。如果需要查詢資料表的某一列，傳統方式是使用row-based，也就是将每一行資料都取出來，然後取出其中的某一列，這樣做其實磁盤的效率很低。而使用column-based則可以直接取這一列，這樣可以節省很大的磁盤io，進而間接地提升磁盤性能。另外按列可以對于相同資料進行壓縮，特别是數值相同的情況，這也就是為什麼推薦使用者使用數值型的來做，因為使用數值型可以壓縮的更高。另外就是看起來可能需要使用文本，比如string類型的省份資訊，這一類看起來好像是文本類型，但是36個省份可以在内部優化轉化成為36個整型資料，實際上這個壓縮也是非常占優勢的，也就是說，重複的資料越多，壓縮就會越高效，這也是column-based資料庫的優勢。
資料組織結構
資料組織結構就是知識網格，每一列大概是64k條資料做壓縮，做壓縮之後每一列會産生兩個資料結構，一個叫做metadata，另外一個是kg。metadata存儲了這一列64k條資料裡面的最大值、最小值、和以及平均值等預統計資訊，這就是為什麼在進行預聚合的時候會非常快，因為不需要解壓資料，隻要将這些統計資訊全拿到就可以了，而且執行時間是不會随着資料量增加而增加的，因為metadata和知識節點都是記憶體裡面的，不需要跑磁盤，不需要解壓，是以速度非常快，這就是秒級聚合快的根本原因。另外一個就是查詢時候用到的知識網格kg，這也是進行高效查詢過濾壓縮包的關鍵技術，後面我們也會詳細介紹一下kg。
整體架構
下面這張圖大家可以從左上角開始看起，标準的mysql用戶端以及标準的jdbc和odbc用戶端都可以進來，其下面就是parser以及optimizer，也就是解析和優化器根據histore獨特的資料結構來進行優排。再往下就是kg manager，也就是知識網格和metadata，這塊内容也是資料結構最為核心的部分，也是高速資料導入最核心的部分，也包括succinct data。succinct也是最近比較火的一個技術，它可以實作更好的資料壓縮以及基于壓縮包的檢索，也就是說它可以在不需要解壓資料的前提下就進行檢索，histore中對于succinct data的資料結構實作了其c++版本。再往下的memery manager，也就是對于記憶體進行更加高效的加載，使得更多的資料存在記憶體裡以實作更高效的資料查詢和導入，然後右邊這部分就是一些并行計算，比如sharding，也就是一條sql語句進來之後如何實作分片，以及在分片之後進行并行處理。因為現在機器高配都是多磁盤的，那麼可以實作充分利用多核、多磁盤以及這種并行計算的硬體優勢。再往下就是壓縮、解壓，包括lz4或者是ppm這種壓縮解壓算法。到最底下的落盤，histore支援與mysql相同标準的binlog以及自己的hilog，這樣可以友善的通過drc以及阿裡内部的精衛等進行資料同步，同步到其他資料源都是沒有任何問題的。
再看一下資料的導入，這部分可以使用histore高效的導入工具從hbase、odps以及oracle db等導入資料。另外就是最右邊的運維、管控這部分内容，hidas可以實作對于資料庫的運維、監控、報警、部署等一體化操作，友善地實作對于資料庫的運維，以上這些就是histore整體的架構設計。
接下來為大家分享一下histore的核心技術點。
核心技術1：histore查詢優化器
大家可以從下圖中看到從上面的histore查詢優化器下來之後到中間有三種過濾器，也就是前面提到的kg部分，包括位圖索引，bloom filter過濾器，以及直方圖，可以更好地實作粗糙集過濾。實際上在查詢的時候最高效的就是這三個部分：位圖索引、bloom filter過濾器以及直方圖，這部分都是在記憶體裡面可以過濾大部分無效的包，真正可以被命中的壓縮包才會從磁盤中被讀取出來，然後進行解壓去尋找。
往右邊看的話，就是接下來準備做的按列索引，因為原來的時候是沒有索引的。再右邊是基于代價的關聯方法，也就是表與表之間的join，在普通的表與表之間可以使用hash join，在大表之間可以使用map join或者merge join。
核心技術2：執行優化
histore對于很多sql語句都實作了執行優化，可以了解成可以根據histore的存儲結構做一些語句上的查詢條件的優化，比如讓哪些查詢條件優先執行，其實這與sql優化的核心思想是基本一樣的，就是讓更苛刻的條件優先執行，可以過濾更多的包，這其實也是目前通用的做法。
核心技術3：壓縮資料實時檢索
這個部分主要采用succinct技術，針對不同類型的字段進行了單獨的優化處理。這個算法非常複雜，其實簡單而言就是通過原始資料的bwt變換，能夠将字典排序做的很好，更加高效地壓縮，并且通過遊程編碼以及checkpoint來加快檢索，實作不需要解壓資料就可以實作檢索。
核心技術4：高性能資料寫入
之前也有所提及，histore在資料導入這部分也做了重點的優化。簡單而言就是兩點：第一點就是cpu的每個核與每一列、每一個磁盤都進行綁定，實作了多線的并行的導入，充分利用多核和多磁盤的硬體特性進行高效導入；另外一點就是在記憶體裡基于mmap實作一個ringbuffer無鎖隊列，這個是非常高效的。大家都知道mmap在linux使用者态和核心态之間進行切換的時候可以減少一次記憶體拷貝，于是就能夠使得磁盤io更加高效。通過以上的兩個方面，單機資料導入可以達到每秒70萬條資料，除此之外，insert的功能可以達到每秒10萬+這樣的級别，并且資料是實時導入，實時生效的。
核心技術5：mvcc無鎖讀事務
這部分的技術主要是解決了資料導入的讀寫鎖對于并發查詢的阻塞，以前的并發查詢的性能不是太好，就是因為讀寫鎖會造成阻塞。其實簡單來講，histore實作了snapshot隔離級别，每個事務每次進來的時候看到的資料都是一個單獨的copy，這也就是copy-on-write，直到事務的整個生命周期結束、修改完成，下一個事務進來的時候才會看到新的copy，這就是snapshot隔離級别的mvcc。怎麼做的呢？其實還是計算機領域那句經典的話“all problems in computer science can be solved by another level of indirection”，也就是說所有的計算機問題都可以通過添加一層中間層來解決，在這裡的應用就是通過添加一個request proxy這樣一個中間層來解決問題。
核心技術6：硬體加速
目前這部分是histore在嘗試進行實作的，現在就是包括fpga、gpu等技術都在進行嘗試，在fpga方面的嘗試是基于intel的qat技術，實際上qat這個技術成功的落地場景主要有三個：編解碼、壓縮解壓以及加解密。我們就是應用intel qat的fpga闆來分擔cpu的壓縮解壓這部分，這樣就可以釋放部分cpu的能力，因為之前壓縮解壓是非常消耗cpu的工作。這樣有什麼好處呢，一個就是傳統的gzip算法的壓縮率是很高的，但是大家卻不常使用gzip壓縮，因為其壓縮解壓的效率太低，而在使用了intel qat技術之後，就可以将這部分工作放到fpga闆上去做，實際上就可以讓壓縮的吞吐量增加，那我們就可以重新啟用gzip的壓縮方式，這樣就可以在獲得更好的壓縮率的同時讓吞吐量也有明顯的提升。
核心技術7: 聚合計算(group by)查詢優化
group by的時候會将資料分片，然後每個片單獨進行計算，之後在進行聚合，這樣可以優化group by場景下的查詢，就不詳細介紹了。
核心技術8：生态相容
在這部分主要做與binlog的相容，做主備之間同步，以及與其他資料源之間打通，通過binlog方式結合精衛以及drc等已有的工具實作多資料源的同步。
技術部分就先分享到這裡，那海量資料olap産品histore也就分享到這裡。
那麼除此之外，我還想借此機會分享另外一個産品，就是高性能時序資料庫hitsdb。大家知道，目前在監控以及iot場景下，時序資料庫是一個非常熱門的話題，在這樣的背景下，阿裡也推出了一款産品叫做hitsdb，也就是hi-performance time series database，并且在7月31日在阿裡雲公網上已經開始進行公測了，大家可以在阿裡雲官網上留意一下。
hitsdb主要解決的是時序場景，那麼什麼是時序場景呢？實際上就是在時間上分布的一系列數值，其實這個場景也非常多，比如股票、氣溫變化以及網站的pv、uv、iot的工業傳感器資料以及整個伺服器監控的資料、硬體名額等等以及車聯網等基于時間次元的一系列數值。
時序資料有以下這些特點：
持續産生大量資料，每秒上百萬資料點
資料産生率平穩，無明顯的波峰谷
近期的資料關注度更高
時間久遠的資料，極少被通路，甚至不再需要
資料存在多個次元的标簽
展示或使用時往往需要對資料做聚合計算
專用的時序資料庫與傳統資料庫關注點就不太一樣了，時序資料庫非常關注寫性能的優化，hitsdb可以達到每秒千萬級别的寫入，尤其是這種順序時間寫入，另外一個就是更關注讀延遲而非qps，存儲的成本可以根據時序場景特定的算法進行優化，比如插值采樣等。
hitsdb在時序場景下做了很多的增強，包括了如下内容：
寫回方式的記憶體緩存，寫入的資料先在記憶體中壓縮和緩存，積累一段時間後寫回磁盤，極大優化了寫入性能；
高壓縮記憶體緩存可以儲存比較長時間的資料，查詢熱資料時性能大大高于磁盤，降低了讀延遲；
時間序列标簽和時間點資料分開存儲，減少資料重複，提高存儲效率；
在時間序列标簽建立反向索引，極大提升多元度查詢的性能；
磁盤資料也使用高壓縮存儲，大大降低了磁盤的效率；
hitsdb的主要應用場景
hitsdb最主要的應用場景有兩個方面，一個是應用性能監控，另外一個就是物聯網iot，包括了車聯網、智慧交通、智能制造、智慧醫療以及石油化工等領域，其中iot在時序方面要求非常突出。
這裡也給大家看兩個案例，鑒于篇幅，這裡就不一一詳述了。
案例1：應用監控&系統監控
案例2：物聯網存儲
最後，我的郵箱是[email protected]，大家有問題或者有興趣的話可以發我郵件來讨論一下，同時也熱情邀請有識之士加入我們，共同在資料庫領域開疆拓土，謝謝大家！