2-韓鋒-數據庫彈性設計與性能優化.pdf

《2-韓鋒-數據庫彈性設計與性能優化.pdf》由會員分享，可在線閱讀，更多相關《2-韓鋒-數據庫彈性設計與性能優化.pdf（48頁珍藏版）》請在三個皮匠報告上搜索。

1、數據庫彈性設計與性能優化韓鋒韓鋒CCIA（中國計算機協會）常務理事，前Oracle ACE，騰訊TVP，阿里云MVP，dbaplus等多家社群創始人或專家團成員。有著豐富的一線數據庫架構、軟件研發、產品設計、團隊管理經驗。曾擔任多家公司首席DBA、數據庫架構師等職。在云、電商、金融、互聯網等行業均有涉獵，精通多種關系型數據庫，對NoSQL及大數據相關技術也有涉足，實踐經驗豐富。曾著有數據庫相關著作SQL優化最佳實踐、數據庫高效優化。數據庫資深從業者 韓鋒頻道公眾號博主目錄CONTENTS數據庫彈性設計與實踐01 數據庫優化(架構、結構、語句)02 總結&致謝 03 01數據庫彈性設計與實踐數據

2、增長迅猛彈性設計要素彈性設計數據分片分布式資源擴縮數據分片技術數據分片技術 Partition None數據分片最為樸素的原始需求，就是來自于不斷增大數據量。在早期的數據庫產品，不具備分片能力，例如早期的Oracle、MySQL數據庫。此時面對這種需求，普遍的解決方法主要來自兩種：一是數據拆分，從根本減少數據規模；二是數據清理與歸檔，減少活躍數據。前者常見的策略就是垂直拆分、水平拆分，拆分之后的數據規模減小，更好處理。上述兩種方法，直到現在仍然具備普適意義。雖然現在的數據庫已經具備各種數據分片能力，但這些能力都是功能有所妥協后的結果。Partition Disk從本質上來講，這種方式仍是將數據

3、的存儲與計算限定在指定資源內。不同的是，從邏輯上數據進行了拆分，可以在更小粒度上進行管理與訪問。典型的技術就是分區表，對用戶暴露出的仍然是單一表形式，但后臺數據是按分區獨立存儲。產品例如Oracle、MySQL等，均在后續版本中支持了分區表技術。但這種方式的缺點也很明顯，就是沒有真正意義實現數據的拆分，仍然是復用整體資源。適用場景：傳統架構、成熟穩定數據分片技術 Partition Storage本地磁盤容量有限，因而Partition Storage方式誕生了。它是從存儲角度進行拆分，可提供更大容量。比較典型的產品如Oracle RAC。云數據庫產品多采用存儲與計算分離技術，底層使用了云端的

4、分布式存儲，提供更大的承載能力，且通過對云端底層架構的深度優化及數據庫上層的適配，可提供接近傳統數據庫體驗的同時，計算與存儲能力得到大幅提升。典型產品如AWS的Aurora、Aliyun的PorlaDB等。適用場景：成熟穩定、高彈性、簡捷管理、上云 Partition Engine上述產品計算能力擴展有限，無法滿足非常高的計算需求。以2016年Google論文為理論基礎，一系列分布式數據庫涌現出來。這類產品提供了更大的存儲能力及更高的吞吐算力。架構上這些產品實現了將計算部分進行從拆分，提供計算能力的擴展。典型產品，例如Google Spanner、PingCAP的TiDB、螞蟻的OB及國外的C

5、ockroachDB等。其對外暴露的是標準的數據庫能力，只是在某些細節能力較傳統數據庫有所減低。適用場景：數據規模大、高吞吐高并發、混合負載計算、強高可用數據分片技術 Partition All作為理想狀態，采用Partition Engine的分布式數據庫，已經可以完美的解決數據分片問題，但在實際場景中還存在另一些情況。這其實來自于早期互聯網的快速發展，當時面臨著海量數據的存儲問題且沒有較為成熟的分布式數據庫可支撐。當時的做法是很多互聯網公司在內部通過應用改造支持數據分片能力，也很好地滿足自身發展。其架構特點是與應用連接更為緊密，可感知數據位置信息，從計算與存儲都進行了較為徹底的拆分。理想情

6、況下，整個數據庫的各個模塊可以全部并發執行起來。當然這種方式的弊端也很明顯，就是與應用耦合強、產品化封裝差、需要用戶側處理些原本由數據庫側完成的邏輯，如分布式事務、跨片查詢等等。后續這一方式產品也基于此進行了大量改進優化，誕生出不少產品或項目。諸如：開源的ShardingSphere、MyCAT或封裝為標準數據庫產品的如GoldenDB、TDSQL等。近些年來，隨著分布式數據庫的成熟，這兩者的對比成為頗為矚目的話題。個人看來，這兩種方式產品能力在逐步融合，發展上逐步趨同；在細分能力上各有千秋，可滿足各自擅長的場景。適用場景：數據規模巨大、極致高性能、分片定制化、異構計算數據分片技術兼容性：較單

7、機傳統數據庫功能兼容度擴展性：數據計算、存儲上的擴展能力數據規模：這一架構產品的數據存儲容量下層的單機數據庫提供存儲和執行能力，在多個單機數據庫上封裝一層中間層補充分布式能力，通過數據分片規則管理分布在不同數據庫節點的數據，并提供SQL解析，請求轉發和結果合并的能力。計算節點獨立并且共享一個不帶計算功能的存儲集群(Shared-storage)，以存算分離架構，計算層和存儲層都可以動態擴縮容，并且這些分布式數據庫都會對網絡以及存儲層的優化來保證高可用和高性能。每個節點有獨立的計算和存儲功能并且節點之間不共享數據（Shared-nothing），每個節點都是獨立節點，通過共識算法來保證多副本的可

8、用性。數據分片技術數據庫中間層實踐分布式數據庫實踐分布式數據庫實踐云數據庫實踐數據分片實踐案例02數據庫性能優化優化方法論業務架構應用架構資源優化語句優化實例優化對象優化數據庫優化業務架構優化業務流程優化：對業務流程進行分析和優化，減少重復環節和非必要的手續，簡化流程并提高效率。技術應用優化：運用先進信息技術、系統和工具，提高自動化和智能化水平，以提高效率和質量。數據分析和決策支持：建立完善的數據分析和決策支持系統，利用數據挖掘和預測分析等技術，提供有力的決策支持。應用架構優化微服務架構:應用拆分為多個獨立微服務，每個微服務負責一個特定業務功能，以提高應用的可伸縮性、可維護性和可重用性。分層架

9、構設計:應用按照功能層次進行分層，如界面層、業務邏輯層、數據訪問層等，提高應用的可維護性和可擴展性。應用容器化:應用封裝成容器，以便快速部署、移植和擴展應用，提高應用的靈活性和可靠性。事件驅動架構:基于事件的通信方式，推動應用之間的解耦合，增強應用的靈活性和可伸縮性。(分布式)數據緩存:引入緩存機制，緩解數據庫壓力，提高應用的響應速度和性能。消息隊列:使用消息隊列實現應用之間的異步通信，提高應用的可靠性和可擴展性。云平臺:將應用遷移到云平臺上，以提供彈性擴展、容災備份和更好的資源管理能力。資源優化數據庫優化數據業務架構數據邏輯架構數據物理架構 數據建模 數據治理 數據整合 數據庫架構 數據庫結

10、構 SQL質量 數據庫 數據存儲 基礎架構ApplicationDBADataArchitectProduct DBA數據庫優化Do less or not do!If must do,do it fast！數據庫優化數據庫架構結構優化ACID是指在數據庫管理系統中，事務(transaction)所具有的四個特性。BASE是一種架構的方法,稱作BASE(Basically Available,Soft-State,Eventually consistent)。BASE模型反ACID模型，完全不同ACID模型，犧牲高一致性，獲得可用性或可靠性。典型應用:讀寫分離。數據庫架構結構優化Consist

11、ency對于分布式的系統，一個數據往往會存在多份。修改操作對于一份數據的所有副本而言，是原子的操作。Availability每一個操作總是能夠在確定的時間內返回。Polerance在出現網絡分區的情況下，仍然能夠滿足一致性和可用性。數據庫架構結構優化CacheBuffer數據庫架構結構優化數據庫架構結構優化數據庫架構結構優化范式 設計逆范式設計分層分庫分表分區數據庫架構結構優化 過程函數 觸發器 序列 數據鏈接 視圖 表/分區 索引結構優化案例背景說明某大表需要按主鍵字段范圍(=)選擇出一定比例(不超過10%)的數據，但SQL只能執行全表掃描，即使強制指定索引方式依然無效。測試環境兩個表的數據

12、類型相似(只是Id字段類型不同)，各插入了320萬數據，ID字段范圍從13200000。select*from t2 where id=3199990;雖然選擇的數據量很少，只占全表的10/3200000，但對于T1表來說仍然走了全表掃描，而不是期望的索引掃描。對比組的T2表，則完全符合預期。select*from t1 where id=3199990;結構優化案例分析原因字符類型在索引中是亂序的，這是因為字符類型的排序方式與我們的預期不同。字符類型導致了聚簇因子很大，原因是插入順序與排序順序的不同。詳細點說，是按照數字類型插入（1.3200000)，按字符類型（1.32000000）排序。

13、在對字符類型使用大于運算符，導致優化器認為需要掃描索引大部分數據且聚簇因子很大，最終導致棄用索引掃描而改用全表掃描方式。解決方法select*from t1 where id between 3199990 and 3200000;將SQL語句由開放區間掃描(=)，修改為封閉區間(between xxx and max_value)。使得數據在索引局部順序是“對的”。如果采用這種方式仍然走索引掃描，還可以進一步細化分段或者采用逐條提取+批綁定的方法。數據庫語句優化SQL.Structured Query LanguageSQL.Structured Query Language 通向數據庫的一

14、把鑰匙數據庫語句優化數據庫語句優化收集報告分析問題建立優化模型提出優化方案驗證性能影響評估優化結果重復上面步驟數據庫語句優化 EXAMINE THE EXECUTION PLAN REVIEW FILTER AND ACCESS PREDICATES GATHER TABLE INFORMATION EVALUATE EXISTING INDEXES ANALYZE COLUMNS IN WHERE CLAUSE REVIEW EXISTING KEYS AND CONSTRAINTS RUN THE QUERY AND RECORD BASELINE METRICS TUNE THE QUERY RE-RUN THE QUERY CONSIDER ADJUSTING INDEXES RE-RUN THE QUERY LOOK FOR PERFORMANCE INHIBITORS語句優化案例原有做法典型的Filter型操作，如果表較大的話，執行效率可想而知。優化器沒有選擇更優的執行計劃，可以考慮人工干預了。語句優化案例改進做法利用查詢解嵌套，將子查詢部分提前，充分發揮了JOIN的能力，性能得到大幅度提高。數據庫語句優化https:/