[Database Lounge Tokyo #6 (2020/06/25 19:00〜)](https://database-lounge-tokyo.connpass.com/event/175805/) NewSQL その成り立ちとモチベーション @tzkb さん [https://speakerdeck.com/tzkoba/newsql-sofalsecheng-rili-titomotibesiyon](https://speakerdeck.com/tzkoba/newsql-sofalsecheng-rili-titomotibesiyon) - データストアを使い分ける時代 - Perconaの人がMultiverse(多元宇宙)と表現した。開発者にとって大変？ - ユニバーサルなデータベースが1個あればよい？ Universe指向 vs Multiverse指向 - NewSQL - Spannerの登場 2012 - Spannerクローン VoltDB NuoDB CockroachDB TiDB YugabyteDB - 強い整合性 ACIDトランザクション - YugabyteDB - SQL CQL interface k8sオーケーストレーション対応 - B+TreeではなくLSM-Tree - TiDB, CockroachDBはRocksDB - YugaByteDBはDocDB - Sharding - Spnanner: Range - CockroachDB: range/hash - ... - Raft レプリケーションのため - YugaByteDB マルチRaft グループごとにLeader - 分散トランザクション Isolation+Consistency - NewSQL 4つの要素 整合性を保ち、冗長化、分散、永続化 PayPay TiDB Vitess も検討した。 data mjigration from aurora to tidb application side ? infrastructure side? not many use cases PoC many challenges eventually fixed application side devel ID global transaction ID only migration progress online which can be big changes. How about Latency? [https://www.slideshare.net/scalar-inc/scalar-db-a-library-that-makes-nonacid-databases-acidcompliant](https://www.slideshare.net/scalar-inc/scalar-db-a-library-that-makes-nonacid-databases-acidcompliant) [https://speakerdeck.com/yito88/database-lounge-tokyo-number-6-lt-jepsen-test-introduction](https://speakerdeck.com/yito88/database-lounge-tokyo-number-6-lt-jepsen-test-introduction) Japsen Testの話 - 共通テストや評価基準があるわけではない　フレームワーク - DB開発者が使うテスト - Architecture - Node: Control Node, DB node - Control Node: - Client worker - Nemesis worker (Failure injection) - DB node 垂直スケールの果てのdb.r4.16xlargeで得た教訓 - Aurora/PostgreSQL 更新トランザクション比率高め - db.r4.16xlarge 64コア mem 488GB Nw 25Gbps - 10~100倍低速 - autovacuumが追いつかなかった。テーブルが肥大化 - autovacuum worker 増やす - Auroraはノード間で共有 - レプリケーションで詰まる - ALTER TABLE テーブルのいメタデータ書き換えだけ - pg_repack でも同じ - そのほか：水平分割、RDBMS以外