【DB吐槽大會】第14期 - 隻讀執行個體是孤島

背景

1、産品的問題點

• 隻讀執行個體是獨立的孤島執行個體, 不能聯合起來完成同一個任務(例如一個大的SQL請求, 建立索引, JOIN等)

2、問題點背後涉及的技術原理

• 業界有兩種使用隻讀執行個體的方法

• • 每個隻讀執行個體有獨立的URL, 應用程式建立多個資料源(每個資料源對應1個隻讀執行個體), 應用程式自己控制将SQL請求發給哪個資料源.
  • 使用讀寫分離的中間件, 應用隻需要連接配接1個位址(中間件位址), 中間件解析SQL, 将SQL路由到RW或RO執行個體.

3、這個問題将影響哪些行業以及業務場景

• 人類的祖先智人為什麼能幹掉腦容量更大的尼安德特人? 社交能力. 即大群體能力對抗小群體(150人)的能力.
• 既有TP(單機為主, 靈活, 低延遲高并發小事務, 全局一緻性等需求), 又有複雜分析的業務(OLAP, 多機并行計算為主).

4、會導緻什麼問題?

• 一般來說讀寫分離可以解決讀請求能力擴充的問題, 但是對于複雜的分析, 不行.
• 單一執行個體的CPU核數有限, 執行個體内并行計算的話很容易達到單機天花闆.

5、業務上應該如何避免這個坑

• 将資料同步到專門的OLAP資料庫進行處理.

6、業務上避免這個坑犧牲了什麼, 會引入什麼新的問題

• 額外的OLAP資料庫, 增加了成本.
• 增加了同步帶來的研發、軟體、維護開銷.
• 增加了管理複雜度

7、資料庫未來産品疊代如何修複這個坑

• 核心改進: 将多個RO節點聯合起來執行同一個任務, 例如一個非常複雜的SQL, JOIN, 建立索引等. 類似于Greenplum的MPP處理能力. 可以線性提升性能.