-
- いいね！347
こば -Koba as a DB engineer-
@tzkb
Spannerで色々なanomalyを検証した話。external consistencyもこうした例があると腹落ちしやすい。 abort前提だと↓は分かるけど少し怖くないか？とも思う。 「Spanner のクライアントによっては abort された際にトランザクション全体をリトライするようになってるので」 medium.com/google-cloud-j…
2020-02-09 09:46:30
こば -Koba as a DB engineer-
@tzkb
「読み込みしか行わない所はRead-Only Transactionにすること、Read-Write Transactionの中身はリトライされても問題のないよう冪等にすること」は他のNew SQLでも同じなのかも知れない。 #distributedsql
2020-02-09 09:51:46
こば -Koba as a DB engineer-
@tzkb
Vitessのトランザクションについて。v2.1の頃から2phase commitをサポートしているが、下記ドキュメントにあるようにcross shardなupdateと2PCは現時点でも推奨されていない。性能が著しく劣化するから。 #distributedsql vitess.io/docs/reference…
2020-02-09 21:48:40
こば -Koba as a DB engineer-
@tzkb
対策はトランザクションを単一DB(shard)に閉じ込めるように設計するか、Best Effort Commit(BEC)を使うこと。前者はアプリケーション設計者にかなりの負担を強いる。後者はvtgateがcommit投げたときにvttabletが死んでたらデータロストということなので、殆どのケースでかなり辛い。
2020-02-09 21:56:01
こば -Koba as a DB engineer-
@tzkb
Citusも同様だが、cross shardのupdateで性能劣化というのは辛い。単一DBでパーティションを切った時でさえ、それらを跨るselectやupdateは必ず発生するし、いわんやshardingをや。完璧なデータ分割(妥協込みでも)を出来る覚悟がない人にはハードルが高い。
2020-02-09 22:02:54
こば -Koba as a DB engineer-
@tzkb
なお、cross shardのケースでベンチマーク取ったものを確認出来てないので、2PCが実用的なレスポンスを返すのかは未調査。気になる方は検証してみてください。
2020-02-09 22:10:29
こば -Koba as a DB engineer-
@tzkb
ACIDなNoSQLの老舗、FoundationDBを分析した記事。このDBはCassandraにトランザクションを付け足した形に近く、カスタマイズされたリーダレス・レプリケーションのように動く。制限はかなり厳しい。 - 5秒以上のtranは実行不可 - 1tranでデータ読書きは10MBまで blog.yugabyte.com/7-issues-to-co…
2020-02-10 08:40:01
こば -Koba as a DB engineer-
@tzkb
こちらは更にサマリ。 #distributedsql qiita.com/mokemokechicke…
2020-02-10 08:41:46
こば -Koba as a DB engineer-
@tzkb
Multi-DCモードがあるが、書込みは単一リージョンに限定され、障害発生時にMasterがF/Oする。この辺りはAurora Global Databaseと同じ構成となっている。
2020-02-10 08:47:00
こば -Koba as a DB engineer-
@tzkb
ちなみにリーダレスレプリケーションの説明は、データ指向アプリケーションデザインの5章にあるよ。
2020-02-10 09:29:38
こば -Koba as a DB engineer-
@tzkb
なんだと、、、Spanner喋れる SQLiteだと。YugaByteDBとかはpostgres喋れるけどSpannerは喋れないんだろうな、たぶん。 twitter.com/tjun/status/12…
2020-02-10 21:44:25
tjun
@tjun
go-sqlite3を使ってCloud Spannerエミュレーターを作ってみた / Cloud Spanner emulator with go-sqlite3 speakerdeck.com/kazegusuri/clo…
2020-02-10 21:38:04
こば -Koba as a DB engineer-
@tzkb
NewSQLのうち、同じGoogle派生の技術を用いるものでも、Percolator由来のもの(TiDB)とSpanner由来(C8DB、Y7DB)があるよという話。それぞれの特徴を簡単にまとめている。 #distributedsql blog.yugabyte.com/implementing-d…
2020-02-11 10:11:14
こば -Koba as a DB engineer-
@tzkb
Percolatorは元々BigTableのうえで動くように設計されたもので、その単一行のatomicityをベースに、2PCを用いてcross shardなACIDトランザクションサポートへと拡張している。しかし低レイテンシなDBには向いていないという弱点があるようだ。
2020-02-11 13:44:25
こば -Koba as a DB engineer-
@tzkb
一方SpannerはBigTableではなく、Colossusをファイルシステムとして使用する。さらに2PLベースの同時実行制御をサポートするロックテーブルとpaxosを用いて、分散トランザクションを調整する。C8DBとY7DBは調整に必要な原子時計を持たないが、替わりにHLCを用いる。
2020-02-11 19:19:53
こば -Koba as a DB engineer-
@tzkb
朝活的にdistributedsqlのサマリをtweetしているが、これ実は全てを朝にやっている訳ではない。 - 紹介して意味がありそう - 私のレベルで理解できそう 等のスクリーニングは前日までに行う。当然「うわ、これ難しくて無理！」な記事にも良く当たる。例えばこれとか。 dbmsmusings.blogspot.com/2017/04/distri…
2020-02-11 23:08:56
こば -Koba as a DB engineer-
@tzkb
今日はSpannerとCalvinの比較について。Calvinは単一Raftグループを扱うので、scalabilityでSpannerと異なると先日紹介したが、その他にもSQL インターフェースを扱えないという差がある、と述べられている。 #distributedsql blog.yugabyte.com/google-spanner…
2020-02-12 08:52:51
こば -Koba as a DB engineer-
@tzkb
Calvinはトランザクションモデルの制限が厳しく、二次インデックスやセッション単位のtranをサポートできない。また、単一Raftグループのため、リーダーが存在するノードの障害に弱くなるとも指摘されている。
2020-02-12 09:07:24