Try   HackMD

[DB] 分散式資料庫, SQL middleware and NewSQL

分散式資料庫

傳統系統架構模式為應用程式直接存取資料庫, 這樣的架構特點是直覺方便.
但隨著資料量不斷增大, 會遇到一些問題:

  • 單個表格資料量太大
  • 單個資料庫資料量太大
  • 單個資料庫伺服器壓力太大
  • 讀寫速度遇到瓶頸
  • …

遇到上述問題時, 增加硬體效能垂直擴展可已解決眼前的問題.

MySQL 中間層

不過當業務量不斷累積, 同樣的問題會不斷重現, 而硬體規格是有極限的.
此時只能採用水平擴展的方式來平行化服務負載.

增加新的機器, 把資料庫放在不同機器上, 在應用程式和資料庫之間加一個 Proxy 進行路由管理.
這個 Proxy 即為 MySQL 中間層.

  • Ex: Vitess (Youtube) / MySQL Proxy / MaxScale / …

NewSQL

RDS (SQL) with ACID guarantees, and NoSQL-like scalable performance for OLTP workloads.

  • 無關係資料庫的實作方式, 同時間有 NoSQL 資料庫的性能與可擴充性, 並確保事務性需求 (ACID)
  • 專注於處理 OLTP 類型的數據需求, OLAP 不是 NewSQL 主要解決的問題.
  • Ex: Google Spanner / CockroachDB / TiDB / VoltDB / MemSQL /AWS Aurora / …

Vitess

Introduction

Vitess is a database clustering system for horizontal scaling of MySQL through generalized sharding.

Features

2PC

Provide a mechanism to support atomic commits for distributed transactions across multiple Vitess databases. Transactions should either complete successfully or rollback completely.

2PC introduced the prepare protocol to defend against the above three. A database that acknowledges a prepare must give you the following guarantees:

  1. It will not abort a transaction unless requested.
  2. It will never refuse a commit.
  3. If the database crashes, it will reinstate the transaction to its prepared state upon recovery.

2PC transactions guarantee atomicity: either the whole transaction commits, or it’s rolled back entirely. It does not guarantee Isolation (in the ACID sense).

Guaranteeing ACID Isolation is very contentious and has high costs. Providing it by default would have made vitess impractical for the most common use cases.

TiDB

TiDB is an open-source, cloud-native, MySQL-compatible distributed database that handles hybrid transactional and analytical processing (HTAP) workloads.

Reference

MySQL 中間層

Vitess

TiDB

Misc

Last changed by 
 
Moo Cow
0
754
Published on HackMD