免费久久国产&夜夜毛片&亚洲最大无码中文字幕&国产成人无码免费视频之奶水&吴家丽查理三级做爰&国产日本亚欧在线观看

舉個例子，比如說上圖中的右邊是我們的數據，左邊是我們的用戶。

成都分公司總經理能夠從級別這里看到所有的數據。但是他在目錄這個級別的話，他只能看到成都的機密級別以下的數據。同時，因為他的組里面有工程部和人力資源部，他只有這兩個，也就是說他能夠看到工程部和人力資源部的成都的數據。對于總部的人力資源總經理的話，我們就會發現他能看到北京和成都的，也就是說能看到所有歸屬地的員工的人力資源里面的數據。對于董事長來講，一般董事長的級別能夠看到所有的安全級別的數據，他能看到北京和成都兩地的數據。在組的關系上來講，董事局一般是整個公司部門里面最高級的部門，所以他在組這個級別上，他就能看到他下屬所有部門的數據，也就是說對鋼鐵俠來講，他能看到整個公司全部的數據。通過這個安全規則我們就可以做到對數據做到行級的過濾、行級的保護。

2、TBase的列級安全規則。

在TBase中是通過訪問控制列表來實現的，也就是說我們會在每一個列上加一個ACL的列表來指定這一列對誰有權限，誰沒有權限。

比如：我們在薪酬上設定說普通員工是沒有權限訪問，對蜘蛛俠或者普通員工來講的話，他看到的數據就只有他自己的數據。但是對于鋼鐵俠來講，因為鋼鐵俠是董事局的主席，他能看到這兩列所有的數據。通過行級權限控制和列級權限控制可以得出我們對表里面的數據能夠做到行和列的任意訪問的控制。

3、TBase數據脫敏和加密。

脫敏和加密面對的場景有一些差別，加密主要面對的是數據文件本身的泄露，比如我的文件被別人拖走了，然后他通過代碼可以把數據解析出來。我們現在常見的數據庫的存儲格式基本上來講是屬于半公開的狀態。也就是說大家只要拿到了數據庫的數據文件，只要有一個數據程序就可以把它解析出來，我們要通過數據中心的加密防止泄露。脫敏主要指的是我的數據在訪問的時候，有些數據的用戶是沒有權限去看到它的明文的，但是它還用一些運維的操作或者其他一些工作上的需要，他需要能訪問這些數據，但是他不需要真正看到這些數據，這兩個是完全不同的需求。加密在存儲層的時候，存儲的是密文，只有在執行這個程序的時候才會對數據進行解密和加密，然后把它反饋給用戶。對于脫敏的話，存儲的是明文，在buffer里面也是明文，只有在用戶訪問的時候，我們授權用戶、非授權用戶來進行公平的處理。對授權用戶得到的就是完整的數據，對非授權用戶得到的數據就是脫敏以后的結果。加密和脫敏可以進行混合的使用，也就是說我們既可以對存儲內容加密，也可以針對不同用戶采用用戶的一個脫敏的規則，來保證我數據訪問的一個隔離。

下面針對TBase MLS透明脫敏和透明加密舉個例子。

我們有兩個脫敏和加密的規則，也就是說我們會針對非董事長用戶進行加密的脫敏。脫敏之后的數據，我們可以指定一個任意的值來展示給這個非授權用戶。現在我們對于這個非授權用戶，也就是說對于成都的分公司總經理和總部人力資源總經理，他們看到這兩個數據，一個是0，一個是1。但是對于董事長來講，因為他是超級用戶，他是沒有受到加密和脫敏的約束的，所以他看到的數據是正常的數據。通過這種方式我們就可以很好的來隔離系統里面不同等級用戶對于同樣一些數據看到的視圖，達到一個隔離的效果。

另外，跟大家分享下TBase MLS的審計能力。

TBase具備完整的審計能力：1、語句審計，對特定的語句類型進行審計；2、對象審計，可以針對數據庫的某個對象，比如說一張表，或者一個數據庫，甚至一個索引來進行一個審計。3、記錄用戶審計，記錄用戶所有的訪問。4、還有一個比較好玩兒的功能是TBase的一個系統的審計，我們可以做一些針對用戶自定義的審計規則，比如審計的時候，我們判斷如果用戶的余額大于這個值的時候，我們就會把它的審計結果記錄下來。同時我們還會自定義它的審計的一個動作，也就是說如果這個條件被觸發了之后，我們會去做什么事情。比如說上面這個例子是我們會調用一個發文件的功能來做我們的審計。

PartⅢ TBase客戶案例

下面介紹一下TBase的客戶案例。

TBase最早是在2016年初的時候替換了微信支付原有的分庫分表的MySQL集群。當時大概每天只有500萬筆，后來支撐到每天數億筆。整個過程中我們保證了微信支付業務的連續性和穩定性。

主要有幾個策略：

第一個是大小商戶策略。微信商戶系統，商戶業務不同于個人業務，存在大商戶和小商戶的區別。大商戶像大型的網購平臺，還有電商平臺，它都屬于大商戶。小商戶就是各種各樣的小店，他們的數據量不一樣的，所以我們需要對于不同的用戶量來進行一個處理，來保證兩邊服務的質量。

第二個是冷熱分離的策略，因為對于微信支付的系統來講的話，它的冷熱存活都是我們的訂單數據，都是跟錢相關的東西。這一塊來講的話，跟我們相關法律的要求，這些數據我們需要存儲四年以上。但是，其實對于其中的數據，絕大部分來講，比如說三個月以前的數據訪問量是非常低的，我們如果都使用相同的存儲策略，我們整個集群有400多T的數據，如果都是用成本較高的SSD存儲，效率和成本之間不是最優的結果。所以我們就需要一些針對最近3－4個月的熱數據和4個月以前的冷數據采用不同的存儲策略，來幫助業務降低成本，同時來保證我們業務的訪問效率。

第三是我們還為業務提供了一個跨城容災的能力，來保證業務的連續性。

由于來訪問這個系統的業務有很多種，運維的同學也會有潛在的不同的各種各樣的應用程序，我們需要針對不同的應用程序或者不同的用戶，來提供不同的數據視圖，來保證我數據整體的可靠性。這個是前面提到的第四是MLS的安全系統。

總結一下，微信支付整個集群大概是這么一個結構。

圖中最上面是我們CLB，是騰訊內部的一個負載均衡的組件。CLB下面是我們的接入節點，我們在內部首先把數據會分為大商戶和小商戶，在下面可以看出來小商戶熱數據集群，小商戶冷是商戶冷數據集群，大商戶熱是大商戶熱數據集群，大商戶冷是大商戶冷數據集群。冷熱集群之間的差別在于說存儲設備是不一樣的。熱集群主要使用的是SSD的設備，冷集群使用的是普通的TS5的設備，降低存儲成本。整體來講的話，通過這種方式之后，我們就把我們整個集群的成本降低到了ICB存儲的四分之一左右，全部使用ICB存儲的四分之一。

在外部我們有一個比較大的保險公司，然后上線了200多個TBase實例在跑保險的核心業務，這里只展示了我們的部署架構。

我們上面分為兩個平面，一個是讀寫平面，一個是只讀平面。讀寫平面，業務通過VIP來提供讀寫能力。我們的只讀平面通過業務VIP在多個節點做負載均衡，提供一個業務的只讀能力。然后TBase的數據在生成之后，我們還需要把這個數據同步到我們其他的一些系統里面去，比如說ES、INFORMIX、MONGODB或者說MySQL，甚至同步到Oracle里面去。同步到Oracle和INFORMIX里面去主要是為了保證業務切換的可靠性，也就是我們把數據再回寫回去，來保證這個切換過程中的穩定性。需要補充一下，TBase在往這個后面同步數據的時候，其實我們是先通過自己的邏輯解析的數據，把數據解析成了Json格式，通過Kafka同步過去。

PartⅣ 國產化能力建設

下面介紹一下TBase在數據庫國產化方面的工作。第一個，在國產化平臺上面，我們支持了國內主要的平臺，包括華為的泰山，還有中標麒麟。在操作系統這一塊的話，中標麒麟已經支持和UOS也在支持中。國產芯片這一塊， X86和ARM我們是支持的比較好的。

在國產化計劃這塊，一定會提到數據庫的異構遷移，TBase現在已提供了完整的數據庫遷移服務。

主要分為兩部分，一部分是工具，在工具這一塊的話，我們有數據的遷移工具，數據遷移評估工具以及數據校驗的工具。同時我們還提供了專門的專家咨詢服務，專家咨詢的話，我們會有一些遷移評估，方案設計，改造建議，優化建議等等。通過整體的解決方案，我們會把數據從原有的商業數據庫，包括Oracle、MySQL等等可以把它很可靠的同步到TBase里面來，來解決數據庫國產化替換的一個數據遷移的問題。

在硬件這一塊的話，現在我們常見的幾種硬件進行了性能的評測，下面是評測結果。

在前面提到的X86環境下的話，我們在服務器上跑了68萬TPM。然后LinuxOne能跑127萬，測試結果跟服務器的配置有關系。說到數據庫的國產化替換，肯定是繞不開Oracle兼容的，Oracle兼容TBase做了相當多的工作，包括我們的對象的支持，數據類型的支持，函數，SQL特性和存儲過程。這一塊我們后續會進行一些增強和擴展，來提升我們的兼容度。

PartⅤ Q＆A

Q：分布式表的庫備份，所有的DN都要獨立備份一份嗎？

A：TBase每個DN是整個數據庫的數據的分片，所以說在備份的時候，至少每個DN是要備份一份出來的，但是它不是獨立的一份，因為在備份邏輯里面會控制保障整個集群的完整性，也就是各個DN之間，每個DN都會有一個相應的副本存儲到冷備里面去。

Q：冷備這塊最大一致時間戳方式，會不會因為服務器之間的時間差異造成備份不一致？

A：冷備的時間戳問題，我覺得這個不用擔心，分享中我提到有5種方式：1）分布式快照隔離；2）絕對物理時間隔離；3）硬件絕對物理時間隔離；4）本地時間隔離；5）邏輯時間戳的隔離。TBase使用的是邏輯時間戳，這個時間戳不是本地的時間戳，是TBase內部的時間戳，我們會保證它的穩定性和單向遞增，它不會發生反轉，也不會發生偏移，而且它有容災的特性。即使機器發生故障，然后再把它拉起來，它也是能保證整個穩定性的。

Q：時間戳是個全局自增值嗎？gtid？

A：至于說這個時間戳是不是一個自增值，簡單理解上，說是自增值是沒有問題的。但是核心問題是我們需要保證它，不能讓它有全局瓶頸，不能讓它因為一把鎖，把它全局吞吐量都拉下降了。

Q：安全控制方式上，select 如何輸入token？

A：TBase的安全控制方式更多的是通過用戶的接口，比如說安全管理員，他會有自己的一套接口來創建自己的密鑰，創建自己的安全規則。

Q：冷熱數據分離是通過人工方式做的還是自動方式？判斷冷熱數據的標準是啥？有沒有采用存儲分層的能力自動來判斷？

A：至于冷熱分離的轉儲是存儲層的設置策略還是在云數據庫層去做，其實冷熱轉儲這一塊，冷熱的訪問邏輯和邏輯的定義是在數據庫里面定義的，但是冷熱的轉儲，是通過TBase的管控系統來做，這個邏輯相對來講還是比較重，我們需要有一些專門的機制來保障它的可靠性和易用性，所以TBase整個把它移到了管控系統里面來。

冷熱分離的方式是人工去定義的，我們根據的業務邏輯來定義哪個數據是冷，哪個數據是熱的。但是它的判斷，它下層的遷移的邏輯是自動的，只要把這個規則定義好了之后，整個系統會自動的運行，不需要人為干預。

判斷冷熱的標準是什么，舉個例子，比如說微信支付是四個月的數據是熱數據，四個月之前的數據是冷數據，其實是按照時間來判斷的，我們取當前的時間往前面算，往前面偏移。超過了一定的閾值它就是冷數據。

關于存儲分層之后，TBase更多是從數據庫本身的能力來做。

Q：備份工具是原生內置的嗎？

A：TBase的備份工具不是數據庫內置的，是我們在管控里面做的，說句實在話，冷備這一塊東西需要打交道的周邊模塊比較多。比如需要把冷備的數據同步到一個外部存儲里面，外部存儲有可能是一個磁盤陣列，有可能是一個HDFS，也有可能是一個其他的存儲，這些東西放在數據內核里面不合適，太重了，冷備功能是我們提供的獨立工具來做的。

Q：TBase本身就是一個數據庫引擎，它不是一個數據庫中間件？

A：TBase本質上是一個數據庫引擎。今天我講的PPT里面，大家可以看到，整個過程中其實我都沒有提中間件，一直在講數據庫底層引擎的一個原理，比如說優化器的原理、執行器的原理，還有分布式優化邏輯，以及我們的分布式事務的邏輯，其實都是引擎里面的原理。中間件一般只會做SQL解析、SQL轉發和結果的返回，很少涉及到執行計劃。

Q：PUSH QUERY和PULL DATA如何選擇？

A：其實PUSH QUERY和PULL DATA這個選擇沒有一個嚴格的界限，一般PUSH QUERY在數據量相對比較大的時候會比較有效一點，因為把QUERY下推之后，下層節點的執行會過濾掉大部分數據，拉取的數據量大大的減小。然后PULL DATA在一些簡單的查詢，表非常小的時候，把它拉回來算可能更快一點。這一塊選擇沒有嚴格的標準，可以根據我們的場景決定。

Q：如果是從ORACLE轉到分布式數據庫有哪些知識需要補充？

A：說實在話， Oracle是一個發展了三四十年的數據庫產品，整體的架構和功能都非常強大了。分布式數據庫是一個新興的領域，產品架構，包括它的生態也都是一直處于建設和完善中，因此在調優、使用和數據業務的建模這一塊跟以前的Oracle還是有所區別的。從哪一塊入手，我覺得這要看你使用的是哪些分布式數據庫。如果是MPP的話，可能就需要了解一下MPP里面的關鍵點。比如數據的分片怎么分，跑SQL的時候，怎么去結合分布邏輯去很好的設計SQL，這個可能是在接觸分布式數據庫的時候需要考慮的一個比較重要的問題。

Q：兩個大表分布在不同的DN，做HASH，如何保證選擇正確的執行計劃和高效率？

A：兩個大表分布在不同的節點里面，我們要進行一個查詢，如何提升它的效率。如果兩個大表，首先第一個來講，我們得搞清楚這些表進行查詢的時候關聯的KEY有哪些。比如說如果我們都是使用這一列進行關聯，那是不是可以在設計的時候就按照性能這一列進行數據的分片，在進行查詢的時候，就可以下推到每個DN節點來執行，換句話說每個DN節點的執行層是并行的，沒有相互之間的交互，這樣效率在分布式的時候是最高的。

如果這個表查詢的SQL非常多，一張表有一兩百個字段，但是關聯的時候，有的是按照分布KEY進行關聯，有的不是按照分布KEY進行關聯，這個時候就得有一些取舍。要看一下，如果按照分布KEY進行關聯效率會最高，而且可能會比不按照分布KEY的效率高不少，那么我們會選擇優先的把我們業務里面用到的一些頻率比較高的，要求比較高的一些SQL優先的按照那些SQL來設計表的分布方式。然后對于其他的一些SQL，對于那些JOIN的列進一步建索引，提升查詢效率。

另外在寫SQL的時候，盡量做到某個節點上進行查詢的時候，能夠通過我們表達式的過濾掉一些無效的數據傳輸，這樣的話就可以保證一個相對比較好的效率。

Q：學習分布式數據庫有哪些知識要補充？從哪里開始？A：至于說這些數據庫知識有哪些需要補充，我覺得是這樣的，數據庫本身是一個比較古老的技術，如果說從哪里開始，有機會的話，從使用開始就最好了。比如說先做一些最簡單的數據庫的使用，建表、生成數據，最好有一個業務系統作為驅動，邊用邊學，這樣上手更快一些。

Q：TBase代碼開源了嗎？A：TBase的代碼已經開源，大家有興趣的話，歡迎訪問：https：／／github．com／Tencent／TBase。TBase預計今年年中左右會重新推動一個新的版本出來，大家敬請期待。

以上是今天的分享和Q＆A的解答，感謝大家的聆聽。

TBase是騰訊TEG數據庫工作組三大產品之一，是在開源的PostgreSQL基礎上研發的企業級分布式HTAP數據庫管理系統。通過單一數據庫集群同時為客戶提供高一致性的分布式數據庫服務和高性能的數據倉庫服務，形成一套融合完整的企業級解決方案。