TiDBの「Partitionated Raft KV」内部
※このブログは2023年2月25日に公開された英語ブログ「Inside TiDB’s “Partitioned Raft KV”」の拙訳です。 著者：Qi Xu 前回の記事では、TiDB 6.6の実験的な新機能で、パフォーマンスとスケーラビリティが大きく向上したことを紹介しました。今回は、なぜそのような利点を備えているのか、その理由を深掘りしていきましょう。 アーキテクチャ 以下は、TiKVのアーキテクチャです。 図1：TiKVアーキテクチャ – 論理的データパーティション TiKVクラスタは、多くのデータ区分 (リージョン) によって構成されています。各リージョンは、開始キーと終了キーの範囲によって決定される、データの特定の部分を担当します。そして、異なるTiKVノード上に3つ以上のレプリカを持ち、それらはRaftプロトコルによって同期されます。旧来のRaftエンジンでは、物理的にTiK
Raft Engine：TiKVにおける複数Raftログのためのログ構造化組込みストレージエンジン
重要なポイント TiDBはオープンソースの分散型NewSQLデータベースで、HTAP（Hybrid Transactional and Analytical Processing）ワークロードをサポートしています。TiKVは、TiDBのための行指向のキーバリューストレージエンジンを提供しています。 TiKVの以前のバージョンでは、Raft ログの保存にRocksDBが使用されていました。しかし、ディスクI/Oが膨大になっていき、膨大なディスクI/Oは、高いコストと不安定なパフォーマンスをもたらします。 ディスクI/Oを削減するために、BitCaskをベースにしたRaft Engineを設計・実装しています。 Raft EngineはRaftのログをディスク上に順次的に保存し、インメモリインデックスがログを指し示します。 BitCaskと比較して、Raftのログはディスクに書き込まれる前に圧
HTAPの魅力：TiDBとAlloyDBの比較・分析
何十年もの間、オンライントランザクション処理（OLTP）とオンライン分析処理 （OLAP）のワークロードは、異なるデータベースシステムによって別々に処理されてきま した。その理由は、この 2 つのワークロードは、レイテンシー、スループット、データの一貫性など、設計要素が異なるためです。このため、個々のデータベースシステムは、OLTPとOLAPのどちらかのワークロードに焦点を当てることになります。たとえば、業務用データベースは通常、非常に短いレイテンシーを必要としますが、データウェアハウスやデータレイクシステムは、はるかに長いレイテンシーを許容することができます。 しかし、そのために複雑なテクノロジースタックやデータサイロが発生し、企業の成長スピードが制限されることになります。このため、ハイブリッドなアプローチが必要とされています。 HTAP（Hybrid Transactional and
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TiKVによる読み取りと書き込みの方法