由螞蟻金服自主研發(fā)的數(shù)據(jù)庫超越Oracle登頂全球第一，你怎么看？讓我們看看TPC是一個什么樣的組織。寫科普太懶了。讓我們看一波人高潮。2019年，談論六年前的數(shù)據(jù)是否感到自豪？在大數(shù)據(jù)時代，關系型數(shù)

由螞蟻金服自主研發(fā)的數(shù)據(jù)庫超越Oracle登頂全球第一，你怎么看？

讓我們看看TPC是一個什么樣的組織。寫科普太懶了。讓我們看一波人高潮。

2019年，談論六年前的數(shù)據(jù)是否感到自豪？

在大數(shù)據(jù)時代，關系型數(shù)據(jù)庫有哪些缺點？

主要有四個缺點：1。無法存儲數(shù)據(jù)結構

2。按行存儲，即使只操作一列，也需要將整行讀入內存

3。表結構擴展不方便，模式固定

4。對全文搜索功能的支持較弱

針對以上四個缺點，提供了不同的數(shù)據(jù)庫來解決。

1. K-V存儲不能存儲數(shù)據(jù)結構

以redis為例，值可以是數(shù)據(jù)結構，如字符串、哈希、列表、集合、sortedset、位圖等。列存儲可以解決在操作HBase

3表示的列

時，將整行讀入內存導致的高IO問題。文檔存儲可以解決mongodb

4表示的表結構擴展不方便的問題。全文搜索引擎解決了全文搜索功能的問題

以elasticsearch為例

以上解決方案雖然解決了關系數(shù)據(jù)庫的不足，但不能很好的支持acid功能。在某些場景下，關系數(shù)據(jù)庫是一個很好的選擇，因此這些數(shù)據(jù)庫只是關系數(shù)據(jù)庫的一個很好的補充，不能替代關系數(shù)據(jù)庫。

現(xiàn)在newsql也是大數(shù)據(jù)時代的一個發(fā)展趨勢，即可以支持事務，具有良好的可擴展性來支持大數(shù)據(jù)。以oceanbase、tidb和扳手/F1為例。

國慶節(jié)當天，中國螞蟻金融自主研發(fā)的金融級分布式關系數(shù)據(jù)庫oceanbase在被稱為“數(shù)據(jù)庫世界杯”的TPC-C基準測試中，打破了美國甲骨文公司9年來的世界紀錄，成為第一個登上榜首的中文數(shù)據(jù)庫產(chǎn)品。

當數(shù)據(jù)庫扼住系統(tǒng)性能咽喉，直接分庫分表能解決嗎？

子數(shù)據(jù)庫和子表是一種相對落后的優(yōu)化方法，因為成本相對較高。

遇到數(shù)據(jù)庫瓶頸：

-首先考慮SQL優(yōu)化，這是最簡單的方法。對現(xiàn)有系統(tǒng)沒有影響。

-第二個是考慮數(shù)據(jù)庫讀寫分離，這也是一個相對簡單的方法。在數(shù)據(jù)庫級配置中，系統(tǒng)級只需要調整獲取數(shù)據(jù)庫連接的邏輯即可。讀取數(shù)據(jù)時，可以同時獲得主庫和從庫連接。寫入數(shù)據(jù)時，僅獲取主庫連接。

-考慮添加緩存層。數(shù)據(jù)緩存在緩存中，再次訪問時不再從數(shù)據(jù)庫檢索。通常，緩存層對系統(tǒng)是透明的，對系統(tǒng)本身沒有影響。但是，cache的引入也引入了相應的需要考慮的問題，如雪崩、命中率、分布式cache等]-還有一種非技術手段，就是改變需求。性能問題的原因是否不合理？還是要求太復雜？需求可以簡化嗎？這種方法對系統(tǒng)的影響相對較小。

-最后，考慮子數(shù)據(jù)庫和子表。優(yōu)先考慮子數(shù)據(jù)庫，因為它比子表簡單。將相應的表移動到新的數(shù)據(jù)庫中，并調整系統(tǒng)的邏輯以獲得數(shù)據(jù)庫連接。在這里，我們需要考慮移動哪些表。在提高性能的前提下，我們首先嘗試避免分布式事務。

-最后，考慮子表。子表的主要原因是單個表中的數(shù)據(jù)量很大。子表分為縱斷面和橫斷面。垂直剪切是按列剪切的，例如用戶表。常用信息為基本信息表，其他信息為明細表。橫切是按行切割。例如，一個有1億數(shù)據(jù)的表被分成10個有1000萬數(shù)據(jù)的表。這涉及到數(shù)據(jù)應該存儲在哪個表中或從哪個表中獲取。在表被劃分之后，可以對數(shù)據(jù)庫進行進一步的優(yōu)化。

-如果涉及分布式事務，應考慮如何保證分布式事務。理論上，2個，3個，帕克斯，帽子，底座。相應中間件的使用。

系統(tǒng)的設計和優(yōu)化不是模仿的問題，而是需要根據(jù)實際場景進行處理。

tidb數(shù)據(jù)庫和mysql的區(qū)別？

Tidb可以隨著您業(yè)務的增長而擴展。您只需添加更多的機器即可滿足業(yè)務增長的需要。可以異步調整模式。Tidb方案可根據(jù)需要隨時調整。添加列和索引不會影響正在進行的操作的一致性。您可以將tidb看作一個獨立的分布式事務RDBMS，事務可以在多個服務器之間執(zhí)行，不需要擔心一致性問題。Tidb使應用程序代碼簡單可靠。與MySQL協(xié)議兼容，您可以像使用MySQL一樣使用tidb。您可以使用tidb代替Mysql來服務您的業(yè)務。在大多數(shù)情況下，您不需要修改一行代碼。使用go語言開發(fā)

以MySQL為列：

1:支持高并發(fā)系統(tǒng)，會涉及事務，所以數(shù)據(jù)庫引擎必須選擇InnoDB，InnoDB支持事務，事務級別取決于業(yè)務，如果業(yè)務數(shù)據(jù)一致性要求很高，事務將啟動序列化級別，所以交易會被完全隔離，但會導致鎖資源的競爭。MySQL的性能在一定程度上降低了。

2:數(shù)據(jù)庫分為主數(shù)據(jù)庫和從數(shù)據(jù)庫。主數(shù)據(jù)庫負責寫入數(shù)據(jù)，集群數(shù)據(jù)庫負責讀取數(shù)據(jù)。注意主從數(shù)據(jù)庫的數(shù)據(jù)一致性。

3:冷熱數(shù)據(jù)分離，美團、饑餓部分設計采用冷熱數(shù)據(jù)分離。以訂單為例，出庫單的主要業(yè)務場景是查詢。數(shù)據(jù)查詢越向前，概率越低。這是冷數(shù)據(jù)。正在交易的訂單是熱點數(shù)據(jù)，需要隨時查詢和更新。冷數(shù)據(jù)可以放入redis緩存。這將提高查詢效率。

4：數(shù)據(jù)表設計，充分利用索引查詢。businesssql避免返回無用的行和列，禁止使用select*query，在查詢時增加限制，并盡可能返回滿足要求的行。對于復雜的SQL，請考慮拆分SQL。拆分SQL有一個優(yōu)點。對于重復查詢SQL，將第二次查詢放入MySQL緩沖區(qū)，避免重復磁盤操作，提高訪問性能。

5：子數(shù)據(jù)庫和子表。例如，業(yè)務數(shù)據(jù)按月份分類。在一定程度上，增加、刪除、修改和檢查的壓力將得到緩解。

希望對您有所幫助。謝謝您。