-
- いいね！347
こば -Koba as a DB engineer-
@tzkb
Write Performance等にそれぞれが適したワークロードを説明している。 - Calvin: トランザクション少ない、同一データに競合するアクセスが発生するようなワークロード - Spanner: データ競合は少なく(RandomデータへのR/W)、処理すべきトランザクションが膨大なワークロード
2020-02-12 11:30:59
こば -Koba as a DB engineer-
@tzkb
さらにExternal Consistencyに加えて、Strict Serializabilityという言葉も出てくる。頭がこんがらがって来た人はこれも読むと良いかも知れない（私はまだ読んでない）。 bailis.org/blog/lineariza…
2020-02-12 11:58:09
こば -Koba as a DB engineer-
@tzkb
Spanner派生DBで問題になるClock Skeuについても、今日ではAWS Time Sync ServiceやAzureのVMICTimeSync、Google Public NTPなどを使うことができ、YugaByteDB等の追い風となっている。
2020-02-12 16:28:31
こば -Koba as a DB engineer-
@tzkb
CockroachDBでどのようにRocksDBを使っているかについて。一般的にB-TreeはRead重視、LSM-treeはWrite重視とされるが、C8DBでは多彩な機能に注目してRocksDBを採用。TiKVもRocksDB、YugaByteはカスタマイズしたDocDBをストレージエンジンとして使っている。 #distributedsql cockroachlabs.com/blog/cockroach…
2020-02-13 08:40:30
こば -Koba as a DB engineer-
@tzkb
Prefix bloom filtersは一旦置いておいて。ノード追加時に効率的なsnapshot分離を提供するexplicit snapshotを使っているとのこと。それによってmemtableの長時間ロックを避けるということのようだ。
2020-02-13 09:01:03
こば -Koba as a DB engineer-
@tzkb
C8DBではkeyのgetよりscanが多くなる。keyがRocksDBのどのレベルにあるか(もしくは"絶対"ないか)を調べるにはBloom Filterが有用だが、scanのケースでは十分でない。keyの先頭部で構築されるprefix bloom filterが必要とのこと。同じことはTiKVのドキュメントにもある。 tikv.org/deep-dive/key-…
2020-02-13 12:18:13
こば -Koba as a DB engineer-
@tzkb
あれ？Raftわかったかも。State Machine Replicationを実装するための、リーダー選挙・ログレプリケーション(ハートビート含む)と考えたら良いのか？
2020-02-13 22:54:38
こば -Koba as a DB engineer-
@tzkb
こちらの記事、何回も読んでたつもりだけど急に腹落ちした。 qiita.com/torao@github/i…
2020-02-13 22:57:26
こば -Koba as a DB engineer-
@tzkb
これで一ネタいけるな。 (postgres互換) - replication on K8s: Zalando,CrunchyData - sharding: Citus - NewSQL: CockroachDB,YugaByteDB (MySQL互換) - replication on K8s: MySQL Operator - sharding: Vitess - NewSQL: TiDB twitter.com/tzkb/status/12…
2020-02-13 23:08:45
こば - as a DB Engineer -
@tzkb
@tomomo1015 DB神「あなたが落としたのは、postgres互換のNewSQLですか？それともMySQL互換ですか？」 ※なおOracle互換はない。
2020-02-13 22:59:19
こば -Koba as a DB engineer-
@tzkb
そしてRaftはクライアントから見るとleaderを意識しなくて良いものの、RWともにleaderが処理するように見えるので、マルチマスターというと少し違う気がする。マルチRaftでそれぞれのleaderが別ノードにスケジュールされたら、マルチマスターでスケールアウトだけれども。
2020-02-14 00:33:54
こば -Koba as a DB engineer-
@tzkb
昨日meetupで紹介したTiKVとそのエコシステムでHTAPを実現する話。TiDBは高負荷なOLTPをサポートするが、分析用途の場合、行指向で最適化されたTiKVのモデルでは限界があるケースも想定される。そこでTiFlashという列指向のストレージモデルを開発した。 #distributedsql pingcap.com/blog/deliverin…
2020-02-14 08:37:10
こば -Koba as a DB engineer-
@tzkb
TiKVとTiFlashでは異なるデータストアとなり、かつ行->列の変換が必要。これをTiFlashではRaftのlearnerプロトコルで実装している。TiKV内部のlog replicationには参加しないため、遅延があるもののOLTPトランザクションへの影響を抑えることが出来る。
2020-02-14 08:44:05
こば -Koba as a DB engineer-
@tzkb
OLTP用に行指向、OLAP用に列指向の2つのデータストアを持つのは、アーキテクチャとしてはOracle Database In-Memoryに近い。一方、SAP HANAは列指向でありながら苦手な更新ワークロードをチューニングした構成。性能を取るか、ストレージ利用効率を選ぶかなど設計思想は異なる。
2020-02-14 08:47:32
こば -Koba as a DB engineer-
@tzkb
そう考えるとWriteヘビーなワークロードを捌くSpannerクローンのNewSQLだけでなく、OLAPを並列で高速処理するNewSQLも今後登場してくるのかも知れない。
2020-02-14 09:02:15
こば -Koba as a DB engineer-
@tzkb
TiFlashでいうとカラムナストレージ側(learner)でcosistentな読込をしようとすると、leaderへの通信が発生するように見える。おそらくここはConsistencyを落としたreadという選択肢があるはずで、他のNewSQLでもcosistentでないfollowerへのreadが実装されているようだ。
2020-02-14 16:02:49
こば -Koba as a DB engineer-
@tzkb
ちなみにTiFlashはClickHouseというOSSのカラムナDBの一部に基づいているとのこと。ClickHouse自体はトランザクションをサポートしないOLAP専用のDBエンジンのようである。 en.wikipedia.org/wiki/ClickHouse
2020-02-14 16:51:53
こば -Koba as a DB engineer-
@tzkb
- MVCC - Snapshot Isolation - Serializability - State Machine Replication - Raftによるログ複製 - Multi Raftの2PCによる調停 あたりでNewSQLが語れそうな気がしてきてる。もう少し。もう少しなんだけど。
2020-02-15 00:40:59
こば -Koba as a DB engineer-
@tzkb
昨日リプライでも紹介した、グローバルなアクセスがあるシステムでレイテンシを削減する方法について。単一リージョンからスタートして、アプリのマルチリージョン化、そしてCockroachDBのfollower readを使うことでDBアクセスのレイテンシも削減している。 #distributedsql cockroachlabs.com/blog/follower-…
2020-02-15 13:34:56
こば -Koba as a DB engineer-
@tzkb
レイテンシの小さいリージョンのレプリカからreadをするのがfollower readだが、readできるデータに制限があり最新データの保証はされないし、そもそもwriteは低レイテンシに収めることは出来ない。Geo-scaleなDBがあってもレイテンシとの闘いは続く。
2020-02-15 13:40:08