ざっくり理解するNewSQL

Daily Blogging74日目

最近よく聞くNewSQLってなんだ
なんのために生まれたんだ

いつ生まれたの？

最近よく聞くとは言ったけど、Google Spannerに関しては2012年にはリリースされてた
そんな前から...!
なんだかんだもう10年経ってるんだね

NewSQLって概念が出たのはもっと前なのかもしれない

なんのために生まれた？

技術が生まれるのには理由があるよね

理由を知るにはまずDBの変遷を確認する必要がある

RDBの欠点

めちゃくちゃ普及しているし、現代のシステムに欠かすことができない存在であるRDB
そんなRDBにも欠点がある

水平方向のスケーリングが難しい

RDBの特徴といえば、ACID特性にあるが、この特性を担保しながら水平方向にスケールするのがなかなか難しい。
一応やりようはある

• シェアードエブリシング
  • 共有ストレージがシングルボトルネックになる
• レプリケーション
  • 更新処理はプライマリでしかできないので、結局書き込みで限界が来る

NoSQLで解決...!

水平方向のスケーリングを解決するために登場したのが、NoSQL
RDBのACID特性を犠牲に、水平方向のスケーリングはできるようになりました
→犠牲にというより他の特性を持ってる
でも結局整合性を保つのは難しく、またスキーマ定義ができなかったりSQLが使えなかったり他の問題もあった。

ここで登場NewSQL

RDBとNoSQLの問題をまるっと解決するために満を持して登場、NewSQLです。
NewSQLでは、RDBの良さであるACID特性を担保しつつ、NoSQLの良さである水平方向のスケーリングを実現できるようになりました

どういう仕組みなの？

NewSQLは、いわゆるシャーディングの構成をとっている。
RDBでもシャーディングは可能だけど、手動でノードを分けたりトランザクションの管理が難しい
あとはノードを跨ぐjoinなど、クエリの工夫が必要。

NewSQLの方は、ここら辺を自動でやってくれる。

データが複数のノードに分散されるが、論理的には一つのテーブルとして扱えるので、
アプリケーション側の負担が少ない

Raftアルゴリズム

そんなNewSQLを支えているのがRaftアルゴリズム
※全部のNewSQLってわけじゃない

Raftアルゴリズムでは、ノードにリーダー、フォロワーという役割を持たせることで整合性を担保できるようにしている。
リーダーは複数あるノードで、一つだけがその役割を担うことができる。

クエリが実行された時、まずはリーダーの役割を持つノードが処理を捌きます。

1. 書き込み処理の時は、リーダーノードで更新のログを書き込みます
2. リーダーノードからフォロワーノードに更新を伝播する
3. フォロワーノードでも更新のログを書き込む
4. 過半数のフォロワーノードから応答があった場合、リーダーノードで更新を確定させる

ざっくりこんな感じ
リーダーは障害時などに交代されるようになっているので、必ず一人はリーダーがいる状態になっている。