Project Tsurugi（劔）ユーザー会 兼 経過報告会のツイートまとめ
-
- いいね！0
こば -Koba as a DB engineer-
@tzkb
低遅延が前提だと、分散トランザクションにRaftやPaxosは使えない。これは以前も神林さんが言ってたやつ。
2020-10-27 14:57:08
Fujii Masao
@fujii_masao
Tsurugiのshuffle処理は、クエリのキーとパーティションキーが同じ場合は特に不要(shuffle処理がなくてもパーティションワイズジョインで並列処理できる)との理解で正しいのだろうか？パーティションキー以外のキーでパーティションワイズジョインぽいことをしたい場合は、shuffleで動的に分割すると
2020-10-27 15:55:25
Fujii Masao
@fujii_masao
カラム間の依存関係のcardinality estimationは、#PostgreSQL だと拡張統計情報でサンプリングで収集だけど、Tsurugiの方式だと機械学習で精度がより高まるイメージ？？
2020-10-27 16:02:03
Fujii Masao
@fujii_masao
Tsurugiの発見的データ分析や空間情報処理は、プラグイン的な実装になれば、将来的には #PosetgreSQL でもその他DBでも使えるようになるのかも。
2020-10-27 16:06:50
Fujii Masao
@fujii_masao
HTAPは、レプリカをカラムナにして、レプリカに専用のCPUコアを割り当てて(OLTPと割り当てを適宜調整？)、レプリカでOLAP処理という感じ？
2020-10-27 16:12:31
Fujii Masao
@fujii_masao
ロングTxがあるとOLTPは辛い気がするけど、そもそもロングTxはOLAP側に概ね追い出せていて、OLTP側ではロングTxは発生しにくい前提なのかな。もしくはアプリとのco-designで、ロングTxを発生させるようなアプリには何らかの制約を課す感じ？事前にwrite-setを指定とか。
2020-10-27 16:22:49
こば -Koba as a DB engineer-
@tzkb
@fujii_masao 今日、OLAPがカラムナとは言ってなかった気がします。OLTPからlog shippingで同期するとは聞きましたが。神林さんのバッチの話を少し聞き逃したのですが、そこではロングTxをOLTP側でやる話だったのでは？と思います。
2020-10-27 16:26:23
Fujii Masao
@fujii_masao
OLTPもスケールアウトだったら、分散Txについて参考にしたかった。。。自分も分散Txで低遅延は難しいという感覚なのだけど、TiDB事例でレスポンスは課題になっていないという声もあったので、実システム上許容できないほどの遅延でもないのかもと。
2020-10-27 17:04:44
くまぎ
@kumagi
今日のTsurugiの話聞いてて思い出したけど、MasstreeってB+treeと比べてシーケンシャルアクセスどうしても複雑になって遅そうなんだけど実用上は問題出ないんですかねぇ。
2020-10-27 21:42:57
こば -Koba as a DB engineer-
@tzkb
今日学んだのは、Project TsurugiはOLTPもOLAPも捌く分散DBを作るものではなかったということ。国産RDBを一から作るんだから、いきなりそこには行きつかないと言われればそれはそう。
2020-10-27 23:19:54
こば -Koba as a DB engineer-
@tzkb
なんか語弊のある言い方だな。 ⭕️ OLTPもOLAPも捌く(目標) ✖️ スケールアウト可能な分散DBではない
2020-10-27 23:26:38
Ryoji Kurosawa
@rjkuro
@fujii_masao 理論的にはその方向で正しいと思います。ただテーブルパーティションニングは未実装なのでまだいろいろ未定な部分もあり、最終的にどうなるかは決まっていない状況です。
2020-10-28 14:15:13