出典：https：//zhuanlan.zhihu.com/p/45652076
著者：Wen Positively Lake（NetEase Hangzhou Research Instituteでデータベースカーネル開発に従事）
MyRocksは、スペースと書き込みパフォーマンス用に最適化されたMySQLデータベースであり、ビジネスデータベースの選択に信頼できる選択肢を提供します。この記事では、主にMyRocksとは何か、その機能、InnoDBと比較したMyRocksの利点に焦点を当て、MyRocksが適用できるさまざまなシナリオの詳細な分析を紹介します。
RocksDBは、GoogleのオープンソースLevelDBに基づくFaceBookによって実装され、LSM（Log-Structure Merge）ツリーを使用してデータを格納します。Facebookの開発エンジニアは、MySQLのプラグインストレージエンジンフレームワークの要件を満たすために、RocksDBで多くの開発を行ってきました。これは、MySQLに移植され、MyRocksと呼ばれます。MyRocksは、SQLベースのデータの読み取りと書き込み、ロックメカニズム、MVCC、トランザクション、マスタースレーブレプリケーションなど、ほとんどのMySQL機能をサポートしています。使用習慣に関しては、MyRocksとMySQL / InnoDBのどちらを使用しても大きな違いはありません。
4年以上の開発の後、MyRocksは成熟しました。オープンソースのMySQLブランチバージョンであるPerconaとMariaDBは、MyRocksを独自のMySQLブランチに移行しました。InnoSQLはNetEaseのMySQLブランチであり、現在MyRocksをサポートしています。特定のバージョンはInnoSQL5.7.20です。 -v4、オープンソースのMyRocksコードに基づいて、機能最適化の機能強化、バグ修正、およびローカルおよびリモートのオンライン物理バックアップのサポートを行いました。MyRocksの機能を簡単に紹介して、誰もが基本的に理解できるようにします。MyRocksはInnoDBをRocksDBに置き換えるだけなので、SQLの解析と実行の計画、Binlogベースのマルチスレッドレプリケーションメカニズムなど、MySQLServerレイヤーのロジックはあまり変更されていません。私たちの議論の焦点は、主にRocksDBにあるストレージエンジンレイヤーです。
この記事は主に3つの部分で構成されています。最初に、RocksDBは、その全体的なフレームワーク、ストレージバックエンド、および機能特性を紹介するために読み取りおよび書き込みプロセスを通じて紹介されます。次に、InnoDBとの違いとこれらの違いの利点を分析するために、多次元で分析されます。最後に、分析RocksDBのこれらの利点はどのようなビジネスシナリオで使用できますか？記事が長いので、興味のある部分を選ぶことができます。
RocksDBの読み取りおよび書き込みプロセス
書き込みプロセス
上の図は、RocksDBの書き込み要求の概略図を示しています。トランザクションの変更は、送信前にトランザクションスレッド自体のWriteBatchに書き込まれます（上記の例では、トランザクションはPut操作のみを実行するため、WriteBatchにはこのPutのみがあります）。送信されると、メモリ内のRocksDBのMemTableに書き込まれます。MemTableは基本的にSkipListであり、キャッシュされたレコードは順番に並んでいます。InnoDBと同様に、トランザクション（WriteBatch）によって変更されたデータも、送信前に先読みログ（WAL）に書き込まれます。トランザクションが送信された後は、WALが永続化されていることを確認するだけでよく、MemTableのデータをディスク上のデータに書き込む必要はありません。ファイル。MemTableのサイズがしきい値（たとえば、32MB）に達すると、RocksDBは新しいMemTableを生成し、元のMemTableは読み取り専用（Immutable）になり、新しい書き込み操作を受信しなくなります。不変のMemTableは、バックグラウンドのフラッシュスレッドによってsstファイルにダンプされます。ディスク上で、RocksDBはsstファイルを介してデータを保存し、各ログファイルはWALログを保存します。ディスク上では、sstファイルが階層化されています。各レイヤーには1つ以上のsstファイルがあります。ファイルサイズは基本的に固定されています。レイヤーが大きいほど、レイヤー内のファイルが多くなります。つまり、次のように、レイヤーに許可される合計サイズが大きくなります。図のように。
一般に、メモリからダンプされたファイルはLevel0に配置され、Level0レイヤーの各sstファイルの記録された間隔は重複する場合があります。たとえば、sst1は1.4.6.9を保存し、sst2は5.6.10.20を保存します。LSMツリーテクノロジを使用してデータを格納するため、レコードには複数のバージョンがあります。たとえば、sst1とsst2の両方にレコード6がありますが、sst2のバージョンは更新されます。同様に、同じレコードの異なるバージョンが異なるレベル間に存在します。Level0とは異なり、Level1以上のレベルのsstファイルは、同じレベルのsstファイル間で同じレコードを持ちません。
圧縮メカニズム
複数の異なるレコードバージョンがあるため、バージョンをマージするメカニズムが必要であり、このメカニズムは圧縮です。
上の図は、1つ以上のLevel0ファイルをLevel1ファイルで圧縮するプロセスであるLevel0Compactationです。メモリのMemTableをsstファイルにダンプする場合でも、sstファイル間の圧縮である場合でも、IOの観点からシーケンシャルな読み取りと書き込みが行われます。これは、SSDとHDDの両方に有利です。HDDのシーケンシャルパフォーマンスは、ランダムよりもはるかに高くなります。 SSDのパフォーマンス特性により、ランダム書き込みによって引き起こされるフラッシュメディア書き込み増幅効果を回避できます。
読み取りプロセス
RocksDBの書き込みプロセスについて説明した後、読み取りに関連するコンポーネントを見てみましょう。次のように：
データベースの読み取りは、現在の読み取りとスナップショットの読み取りに分けることができます。いわゆる現在の読み取りは、レコードの最新バージョンのデータを読み取ることであり、スナップショットの読み取りは、指定されたバージョンのデータを読み取ることです。ここでは、現在の読み取りについてのみ説明し、スナップショットの読み取りも同様に分析できます。LSMツリーストレージ構造のため、RocksDBの読み取り操作はInnoDBとはまったく異なります。これは、LSMの記録されたバージョンが複数存在する可能性があり（以前のバージョンと後続のバージョンに接続されたポインターを持つInnoDBとは異なり）、渡すことができないためです（厳密な意味）上記）バイナリ検索。そのため、読み取りパスを最適化するためにBloom FilterがRocksDBに導入されています。RocksDBでは、Bloom Filterは、データブロックベース、パーティションベース、およびsstファイルベースの3つの異なる方法を選択できます。フィルタを使用して、検索するキーがブロック/パーティション/ sstに含まれていてはならないことを判別できます。RocksDBは、デフォルトでデータブロックに基づいており、粒度が最も小さくなっています。
次に、上記の2つの図に基づいて、RocksDBの読み取りプロセスを簡単に分析します。Get（key = bbb）リクエストは、最初にブルームフィルターを介して現在のMemTableで検索されます。ヒットしない場合は、読み取り専用のMemTableに移動します。ヒットしない場合は、キー値がディスクsstファイルにあるか、存在しないことを意味します。したがって、各sstファイルのメタデータ情報を検索して、キー間隔に要求されたキー値が含まれているすべてのsstファイルを見つける必要があります。そして、小さなものから大きなものへの問い合わせのレベルに応じて。次の図に示すように、各sstファイルについて、Bloom Filterをさらに検索し、ヒットした場合は、sstファイルのデータブロックをBlockCacheに読み込み、ブロック内の検索を二分法でトラバースし、最後に対応するキーまたはNotFoundを返します。
RocksDB列ファミリー
RocksDBでは、列ファミリは論理的に独立したLSMツリーです。各列ファミリには独自の独立したMemTableがあり、すべての列ファミリはWALログを共有します。sstファイルの圧縮は、列ファミリーの粒度で実行されます。
デフォルトでは、MyRocksインスタンスには2つの列ファミリが含まれています。つまり、システムメタデータを格納するための_system_と、すべてのユーザーによって作成されたテーブルデータを格納するためのデフォルトです。もちろん、ユーザーがテーブルを定義するときに、インデックスの後にコメントを追加することで、インデックスで使用される列ファミリーの名前を宣言できます。次の例では、rdbtableのプライマリキーと一意のインデックスを独立した列ファミリーcf_pkとcf_uidに配置します。 。
CREATE TABLE "rdbtable" (
"id" bigint(11) NOT NULL COMMENT '主键',
"userId" bigint(20) NOT NULL DEFAULT '0' COMMENT '用户ID',
PRIMARY KEY ("id") COMMENT 'cf_pk',
UNIQUE KEY "uid" ("userId") COMMENT 'cf_uid',
) ENGINE=ROCKSDB DEFAULT CHARSET=utf8
MyRocksの主な機能
同時実行制御
MyRocksは、行ロックに基づくトランザクション同時実行制御を実装し、ロック情報はメモリに保存されます。MyRocksは、共有および排他的な行ロックをサポートします。MyRocksは、トランザクションで更新を実行するときに、ロック管理にRocksDBライブラリを使用します。unique_check = 0を設定して、行ロックと一意のキーチェックをシールドできます。これにより、データをバッチでインポートするときのパフォーマンスが向上しますが、データキーを使用するときにデータキーが重複していないかどうかに注意する必要があります。したがって、一般的な高可用性インスタンスの一意性チェックは、ライブラリからBinlogの再生速度をスピードアップします。現在、MyRocksはギャップロックを実装しておらず、ファントム読み取りの問題があります。これは、標準のRR分離レベルと同じですが、InnoDBのRRよりも弱いです。
トランザクション分離レベル
MyRocksは現在、コミットされた読み取り（RC）と繰り返し可能な読み取り（RR）の2つのトランザクション分離レベルをサポートしています。MyRocksはスナップショットを使用して、これら2つの分離レベルを実現します。繰り返し可能な読み取りでは、スナップショットはトランザクション全体で保持され、トランザクション内のステートメントには一貫したデータが表示されます。読み取りコミット分離レベルでは、スナップショットは各ステートメントによって保持されるため、SQLステートメントは、ステートメントが実行される前にデータベースへの変更を確認できます。ほとんどのデータベース実装と同様に、スナップショットは、トランザクションの開始時（開始/開始時）ではなく、トランザクションがRR分離レベルの最初のSQLを実行するときに取得されます。
InnoDBと同様に、MyRocksはMVCCベースのスナップショット読み取りをサポートしており、スナップショット読み取りはロックを必要としません。MVCCは、InnoDBの読み取りビューと同様に、RocksDBスナップショットを介して実装されます。
バックアップと復元
InnoDBと同様に、MyRocksはオンラインの物理的および論理的バックアップをサポートします。論理バックアップは、mysqldumpやmydumperなどの既存のMySQLバックアップツールを介して行われます。物理バックアップは、MyRocksによって実装されたmyrocks_hotbackupツールを介してリモートで実行されるか、mariadbによって提供されるmariabackupツールがローカルバックアップに使用されます。
InnoDBとの比較利点
MySQLに精通している人は、InnoDBが現在MySQLの主要なストレージエンジンであることを知っています。強力で完全なトランザクションメカニズムなど、リレーショナルデータベースストレージエンジンに必要なほとんどの機能を備えています。MySQLの関係者は、InnoDBをMySQLの不可分の一部にしました。新しく追加されたMySQLシステムテーブルは、MyISAMの代わりにInnoDBを使用します。 。では、なぜFacebookはInnoDBを使用せず、RocksDBに基づいてMyRocksの開発を開始したのでしょうか。明らかに、RocksDBには独自の利点が必要です。以下では、複数の次元から比較および分析します。
小さい収納スペース
InnoDBがストレージスペースの利用で抱えている問題を見てみましょう。InnoDBはB +ツリーに基づいており、ツリーノードでのSMO操作を回避できないことがわかっています。以下はリーフノード分割の概略図です。
user_id = 31を挿入すると、リーフノードBlock1がノード分割条件をトリガーし、中央から2ブロックに分割されます。各ブロックは、元のBlock1スペースの約半分を占めます。明らかに、各ブロックの充填率は50％未満です。つまり、現時点では、内部フラグメントの半分があります。
連続して挿入されるシーンの場合、ブロックの充填率が高くなります。ただし、ランダムなシーンの場合、各ブロックのスペース使用率は急激に低下します。全体として、テーブルが占めるストレージスペースは、実際のデータに必要なスペースよりもはるかに大きくなります。
ただし、LSMツリーに基づくRocksDBにはこの問題はありません。データが挿入、更新、削除されるたびに、新しいsstファイルに追加されます。ファイル内で順番に並べる必要があるだけで、見つける必要はありません。 B +ツリーのグローバル順序の特定の移行位置を挿入または更新します。これにより、B +ツリーノードの充填率の問題が解決され、スペース使用率が向上します。
さらに、RocksDBのsstファイルは階層的であり、上位層と下位層の合計サイズ比は最大10です。データ量が多い場合、最悪の場合はスペース拡大の約10％にすぎず、InnoDBと比較して大幅に改善されています。
さらに、上の図に示すように、RocksDBは、保存時にレコード列にプレフィックスエンコーディングを使用します。同様のアプローチがメタデータの各行に採用されています。これにより、必要なストレージスペースがさらに削減されます。
より効率的な圧縮方法
前回の記事では、InnoDBのレコードベースの圧縮メカニズムを紹介しました。おおよその実装は、各レコードの一部のフィールドを16KBページ（ページ）に圧縮し、指定されたページサイズに従ってすべての圧縮レコードを保存することです。 。たとえば、key_block_sizeが8に設定されている場合、つまり圧縮後に8KBとして保存されます。圧縮後にページサイズが5KBの場合、3KBのストレージスペースが無駄になります。InnoDBはMySQL5.7で透過的なページ圧縮を導入しましたが、上記の問題は依然として存在します。
RocksDBは、レコードを圧縮するときにページベースではありません。key_block_sizeに従って整列する必要はありません。すべてのsstファイルは、圧縮後にファイルシステムのブロックサイズ（通常は4KB）に従って整列する必要があります。数MBの各sstファイルの整列オーバーヘッドは超えません。 4KB、InnoDB圧縮のアライメントオーバーヘッドよりはるかに少ない。
包括的な比較により、MyRocksはInnoDBと比較してストレージスペースの半分以上を節約できます。
古いバージョンのリサイクルの最適化
レコードが頻繁に更新されるシナリオでは、長期間一貫したスナップショットの読み取りがある場合、古いバージョンのレコードをパージできないため、InnoDBによって元に戻すスペースが急激に増加します。しかし、RocksDBは問題を効果的に軽減できます。以下は説明のための例です。
MySQLで一貫性のある論理バックアップが実行され、トランザクションが開始されたが、プライマリキーが1で値が0のレコードが、テーブルtで選択操作が実行される前に100万増分操作が実行されたとします。原則によれば、このバックアップは値0の元のレコードを読み取る必要があります。
InnoDBの場合、バックアップトランザクションIDは100万回インクリメントされるトランザクションIDよりも小さいため、100万の古いバージョンのレコード（つまり、元に戻す）はパージされません。つまり、レコードをバックアップするときに100が必要です。 10,000バージョンのバックトラック。レコードの元に戻すポインタに基づいて元に戻すページがランダムに読み取られるたびに、非常に非効率的です。
RocksDBは、古いバージョンのInnoDBのレコードパージ問題用に最適化されています。元のレコードのシーケンス番号が2であるとすると、このバージョンはバックアップトランザクションの表示バージョンです。大きいバージョンの場合は、MemTableをRocksDBのsstファイルとしてダンプするか、 sstファイルを圧縮すると、中間バージョンが削除され、現在アクティブなトランザクションの表示バージョンとレコードの最新バージョンのみが保持されます。これは、MVCC要件を満たすだけでなく、スナップショットの読み取り効率を向上させると同時に、必要なストレージスペースを削減します。
書き込み倍率が小さい
InnoDBでは、レコード更新操作で、トランザクションロールバックとMVCCの元に戻すログに現在のレコードバージョンを書き込んでから（元に戻すページを書き込む前に元に戻すやり直しを書き込む必要があります）、更新後に記録されたやり直しを書き込む必要があります。クラッシュリカバリに使用され、対応するデータページに更新操作を書き込むことができます（B +ツリーノードの分割をトリガーする可能性があります）。フラッシュ中のクラッシュによるデータページの損傷を回避するために、Doublewriteに別のコピーを書き込む必要があります。ディスクキャッシュ。
1回の更新で多くのことを書き込む必要があることがわかります。特に、ランダム更新のシナリオの場合、データページとダブルライトを書き込む場合、書き込み増幅の比率はページサイズ/レコードサイズであり、非常に驚くべきことです。
RocksDBの書き込み増幅は、そのsstファイルの合計レベルに関連しています。最悪の書き込み増幅は約（n-2）* 10です。ここで、nはレイヤーの合計数です。明らかに、InnoDBよりもはるかに優れています。
書き込み増幅の減少は、限られたストレージおよび書き込み機能をより効率的に使用できることを意味します。RocksDBは、ストレージIOパフォーマンスのボトルネックに達したときに、より多くのレコードを書き込むことができると言えます。
一方、RocksDBデータが挿入、更新、および削除されるたびに、その場で更新されるのではなく、追加で書き込まれます。このようにして、ストレージバックエンドはすべてランダムではなく順番に書き込まれます。NANDフラッシュに基づくSSDの場合、SSD内の書き込み増幅の最適化を考慮せずに、同じSSDをInnoDBよりもRocksDBで長く使用できます。
書き込みパフォーマンスの高速化
前述のように、InnoDBはその場でレコードを更新します。つまり、ランダムDMLシナリオでは、各レコード操作がランダムに書き込まれます（セカンダリインデックスが削除されてから新しいレコードに書き込まれた場合でも、ランダムに書き込まれます）。 ）、以下のように。
RocksDBとは異なり、ランダム書き込みはシーケンシャル書き込みに変換され、バックグラウンドで新旧バージョンのマージを記録するマルチスレッド圧縮もバッチシーケンシャル書き込み操作です。バッチ挿入シナリオの場合、RocksDBはレコードの一意性チェックをオフにして、データのインポート速度をさらに高速化することもできます。
HDDでは、このような最適化により、ランダムな読み取りと書き込みよりもはるかに優れたメカニカルディスクのシーケンシャルな読み取りと書き込みのパフォーマンスを利用できます。SSDでも、このような最適化はデータベースのパフォーマンスに役立ちます。
マスタースレーブの遅延が小さい
InnoDBと比較して、RocksDBはライブラリからより多くのDML最適化オプションも提供します。
スレーブデータベースで並行して再生できるトランザクションには確実に競合がないため、つまり、トランザクション間にロック待機関係がないため、RocksDBは最適化パラメーターrpl_skip_tx_apiを導入して、レコードのロックを調整し、トランザクションを確実に分離します。この操作により、トランザクションの再生速度が向上します。
同様に、データベースからのトランザクション特性については、レコード挿入操作の一意のキー制約チェックをスキップできます。更新および削除操作については、実装バグがない限り、操作レコードを満たす必要があるため、レコードルックアップ操作をスキップできます。トランザクションバウンド。
InnoDBにはないその他の機能
MyRocksは、逆順列ファミリーの実装に基づいて、MySQL 5.6 / 5.7に逆順インデックスを実装しました。明らかに、逆順インデックスはデフォルトのデフォルト列ファミリーを使用できません。MyRocksは、LSM機能に基づいて、HBaseと同様に、非常に低コストでTTLインデックスを実装します。バッチ削除のためにレコードをトラバースするMongoDBのTTL実装と比較すると、LSMストレージのTTL機能は、タイムスタンプを保存する必要があることを除いて、追加のメンテナンスパフォーマンスの損失を必要とせず、圧縮中に直接マージして処理できます。
MyRocksの該当するシナリオ
上記の説明に基づいて、MyRocksに適用可能なビジネスシナリオを要約できます。
ビッグデータビジネス
RocksDBは、InnoDBと比較して、占有するストレージスペースが少なく、圧縮効率が高いため、大量のデータを処理するビジネスに非常に適しています。下の写真は、Facebookが公開しているRocksDBとInnoDBのスペース占有率の比較を示しています。
下の写真は、インターネット上のRocksDB、InnoDB、TokuDBの圧縮データを示しています。
上図と組み合わせると、RocksDBに必要なストレージスペースはInnoDBよりもはるかに小さく、高い圧縮率で知られるTokuDBよりも優れていることがわかります。
また、NetEaseの内部ビジネステストでは、人気のあるビジネスのDDBインスタンスが、データ量の急激な増加のために頻繁なテーブル拡張操作を実行する必要があることが確認されました。MyRocksを使用してInnoDBを置き換えると、圧縮が有効になっている165GBのInnoDB単一テーブル（key_block_size = 8）は、MyRocks圧縮では51GBしかないことがわかりました。このDDBインスタンスには合計8つのMySQLの可用性の高いインスタンスがあり、各DBNには10のInnoDBテーブルが含まれています。 MyRocksを交換した後、インスタンスに必要なストレージスペースは26TBから9TB未満に減少しました。これにより、ストレージオーバーヘッドの3分の2（約17TB）が節約され、DBAがテーブルごとに拡張する必要がある期間も長くなります。DBAが四半期ごとに1回拡張する必要があるとすると、今では4分の3ごとに1回だけ拡張する必要があります。 OK。
書き込み集約型ビジネス
MyRocksは、追加のメソッドを使用してDML操作を記録し、ランダム書き込みをシーケンシャル書き込みに変換します。これは、バッチ挿入と頻繁な更新があるビジネスシナリオに非常に適しています。次の図は、Alibaba Cloudによってリリースされたバッチ挿入シナリオのパフォーマンス比較チャートを示しています。InnoDBベースのAliSQLと比較して、MyRocksはほぼ2倍のパフォーマンスの向上を達成しています。
NetEase内の特定の更新集約型ビジネスシナリオでは、パフォーマンスも向上しました。KVストレージシステムよりも劣らない書き込みパフォーマンスに加えて、読み取りパフォーマンスにおいても一定の利点があります。比較は次のとおりです。
上の図は、読み取り専用、1：1および2：1の混合読み取りおよび書き込み条件下での10分間のテストの結果であり、MyRocksはパフォーマンスとレイテンシの両方で優れたパフォーマンスを示していることがわかります。
上の図は、読み取りと書き込みが1：1で混合され、書き込みのみのシナリオでの書き込みパフォーマンスと遅延を示しています。MyRocksは、20回の書き込み同時実行の場合にも良好に機能することがわかります。
キャッシュ永続化スキーム
MyRocksは、InnoDBと比較して効率的なスペース使用率を備えているため、同じサイズのメモリでより多くのデータをキャッシュできます。pikaなどのRedisの代替手段と比較して、成熟した障害回復メカニズムとマスタースレーブレプリケーションアーキテクチャを備えています。複製の遅延により、読み取り容量の拡張が容易になります。したがって、MyRocksはRedisキャッシュのより適切な代替手段でもあります。
TokuDBを交換してください
RocksDB / LevelDBは、TokuDBと比較して、書き込みパフォーマンスと圧縮率が劣らず、読み取りパフォーマンスが優れています。ストレージエンジンとして、MySQL、MongoDB、Kudu、TiDBなどの主流のデータベースシステムで使用され、オープンソースコミュニティが優れています。サポート、問題の特定の迅速化とBugFixの可能性、より読みやすいソースコード。TokuDBの有望性が低下している場合は、MyRocksを使用して現在のオンラインTokuDBインスタンスを置き換えることができます。
低コストで低レイテンシのスレーブライブラリ
MyRocksの優れた書き込みパフォーマンスと、ライブラリからのターゲットパラメータの最適化により、InnoDBよりも低いレプリケーションレイテンシを実現できます。ストレージスペースが小さいという利点と相まって、オンラインデータの誤った削除を防ぐための遅延スレーブライブラリや、ビッグデータの統計と分析のためのスレーブライブラリなど、特別な目的のスレーブライブラリを構築するのに適しています。
総括する
一般に、MyRocksはInnoDBと比較して、占有するストレージスペースが少ないため、ストレージコストを削減し、ホットスポットキャッシングの効率を向上させることができます。書き込み増幅率が小さいため、ストレージIO帯域幅をより効率的に使用できます。また、ランダム書き込みをシーケンシャル書き込みに変更します。 、書き込みパフォーマンスを改善し、SSDの耐用年数を延ばします。パラメータを最適化して、マスタースレーブのレプリケーション遅延を減らします。したがって、大量のデータや書き込みが多いなどのビジネスシナリオに非常に適しています。さらに、同じMySQL書き込みおよびスペース最適化ソリューションとして、MyRocksはより優れたコミュニティエコロジーを備えており、TokuDBインスタンスの置き換えに適しています。MyRocksの効率的なキャッシュ使用率、成熟した障害回復、およびマスタースレーブレプリケーションメカニズムにより、Redis永続化ソリューションとしても利用できます。
参考資料：
1.RocksDB実装分析http://ks.netease.com/blog?id=10818
2、RocksDB wiki https://github.com/facebook/rocksdb/wiki
3. Facebook、Percona、Alibabaが発行したRocksDB関連のドキュメントとPPT
全文は終わりました。
LinuxとMySQLをお楽しみください:)
「MySQLコア最適化」コースがMySQL8.0にアップグレードされ、コードをスキャンしてMySQLトレーニングの旅を開始します