Tarantoolが最適な理由

アニキン・デニス（ danikin 、 Mail.Ru ）

レポートはタランツールに捧げられます。 私はいつもユースケース、ユーザーが見るものについて話しました。 今日は、内部についてもっと話します。



最初にTarantoolを見たとき、そのベンチマーク、パフォーマンスの種類を見つけたとき、それは私にとって疑わしいとは思えませんでした。最適なプログラミングと最適なコードを備えたハードウェア。 しかし、それでも私には疑わしいように見えました-彼がとても速いのはどうしてですか？ つまり、条件付きで、すべてのデータベースが最高で毎秒数万のクエリの速度で動作できれば、Tarantool- 最大で数十万から最大で100万までです。



したがって、本番環境、Mail.ru、およびCloudで使用を開始する前に、すべてを慎重に調査し、Tarantoolがどのように内部に配置され、何が最適なのかを見つけました。 そして、おそらく、他のTarantoolユーザーも同じ疑念を抱いているのではないかと疑っています。何かがどういうわけか速すぎて、どういうわけか疑わしいのです...





ところで、タランツールを聞いたことがない人に手を挙げてください。 ほとんどの人が聞いたことがあります。 本番環境で何人使用していますか？ あまりありません。 実際、彼がどのように速いのか理解できず、他の人はすべて遅いので、あなたは適用しません。それが理由です。 これが本当にあなたがまだそれを使うことを恐れている理由であるならば、あなたは正しい場所に来ました、そして私が今日あなたに言ってあなたに説明することを望みます。 もちろん、すべてではありません。データベースは巨大な製品であるため、多くの機能、機能を備えており、40分ですべてについて話すことはほとんど不可能です。 したがって、私は主なことについてお話します。 行こう







また、レポートから何を期待し、何を期待しないかを簡単に伝えたいと思いました。 期待-詳細、つまり Tarantoolが非常に高速である理由、高速で読み取り、書き込み、高速で起動する理由など、Mail.ruで高速にした理由は何ですか。







予期しないこと-聖戦、すなわち すべてのデータベースは良好であり、各データベースはそれぞれ独自のケースのためのものであり、一般的なすべてのデータベースとしてユニバーサルデータベースであるとは主張していません。 また、Tarantoolの主な強みは、以前は誰も知らなかった新しいアルゴリズムを発明したが、既存のアルゴリズムを正しく適用および構成することではないため、新しい構造や新しいアルゴリズムを期待しないでください。アルゴリズム そして、彼らは非常に最適にコードを書きます。 あなたはすべてO（N）を知っています。 O（N）またはO（logN）と言う場合、O（N）がデータセットの2倍の場合、アルゴリズムは2倍長く動作しますが、具体的にどの程度動作するかは不明です。 最適に記述できますが、漸近的な複雑さに影響を与えず、同時に作業の速度に影響を与えるコピーやその他のものを大量に作成できます。 したがって、タランツールでは、Oの前にあるこの係数に多くの注意が払われます。 すべてが乗算されます。 これは理論であり、現在は実践に移っています。







最も重要なことから始めましょう。Tarantoolはデータのコピー全体をメモリに完全に保存します。 これは、マシンの再起動時にすべてが失われることを意味するのではなく、データのコピーがメモリにあることを意味します。 ディスク上のデータも当然ですが、同時に、すべてのデータがメモリ内にあり、そこからアンロードされることはありません。 ここでは、実際にはすべてをメモリに格納し、メモリ内にあるMemtxと呼ばれる元のTarantoolエンジンに関するものであることを予約する価値があります。 Tarantoolは最近、データのコピー全体をメモリに保存するのではなく、その一部のみを保存できるディスクエンジンを導入しました。 ここでは、元のTarantoolエンジン、つまり インメモリエンジンのみ。 明らかに、メモリはディスクよりも高速です。 すべてがメモリ内にある場合、すべてが迅速に発生します。



これを象徴するそのような写真：







Tarantoolはメモリからすべてを読み取り、ディスクデータベース（MySQL、Postgres、Oracle、SQLサーバー）はすべてディスクから読み取るため、Tarantoolは高速です。 これは明らかなようですが、微妙な違いがあります。







おそらく、このような眉をひそめている私を見てください。「しかし、キャッシュはどうでしょう。ディスクデータベースにはキャッシュがあるからです。しかし、ディスクデータベースは最も人気のあるクエリをキャッシュするので、Tarantoolは高速です。彼らは速いですか？」 メモリがある場合とキャッシュがある場合の違いは何だと思いますか？ t.zとの違いはありますか？ パフォーマンス？ 時代遅れになるかもしれません。 それでは、それについて説明します。



Tarantoolがメモリと相互作用する方法を見てみましょう。







メモリからデータを読み取ります。メモリは常に準備されており、すぐに読み取り、検索、インデックスによるクエリをすばやく実行できる理想的な形式です。



次に、ディスクベースの仕組みを見てみましょう。







もちろん、非常に原始的なスキームです。 すべてのデータベースは異なり、キャッシュも異なりますが、一般的にはロジックは同じです。 まず、ユーザーからの読み取り値があるとしましょう。SELECT* FROMなんとか何とか。 まず、キャッシュにデータがあるかどうかを確認します。 存在する場合はキャッシュに登り、存在しない場合はディスクから読み取り、読み取ったものをキャッシュに書き込みます。 キャッシュがすでにいっぱいになっている場合（定義上、キャッシュが常にいっぱいであるため、常にいっぱいになっているため、これがポイントです）、古いデータをプッシュしてからキャッシュから読み取ります。 すなわち 運が良ければ、もう1つのアクション、運が良ければ、この長いチェーン全体が発生します。これはすべて無料ではないことに注意してください。 彼らはそれをディスクからある種のバッファに数え、このバッファからそれを取り出し、キャッシュにコピーし、古いものを置き換え、メモリを解放し、新しいものを書き、メモリを割り当てました。 メモリの解放/割り当ては高価です。 これはすべてコピー、これはすべて検索、すべてが無料というわけではありません。 これは、Oの前にあるすべて同じ係数です。 多くのアクションを実行する必要があります。 ハッシュテーブルを使用すると、一定のハッシュインデックスに複雑で一定の±が可能です。または、ツリーが対数である場合、それだけです-Oを掛けると、膨大な量の作業が発生します。 データに加えて、それらは1つの形式でディスク上にあり、キャッシュ内では別の形式であり、その後多くの場合ページによってキャッシュされます。 もう少しロードします。つまり、より多くのメモリを割り当て、さらにもう少し解放します。 これらはすべて、誰もがこのビジネスで無駄にしている貴重なプロセッササイクルです。 キャッシュにヒットした場合でも、つまり 読み取りが発生し、データがすでにキャッシュにある場合、バックグラウンドのプロセッサはこのすべてを実行します。このチェーン全体は、停止することなく常にバックグラウンドで実行されます。 すなわち データが既にキャッシュにある場合でも、プロセッサまたはそのコアは何かでビジーです。 そして、他のカーネルが何かでビジーである場合、ロックが発生し、ミューテックスが発生します。 メモリーやすべてから読み取るだけの場合と比較して、非常に多くの作業が必要です。







キャッシュについてのそのようなこと。 違いを感じてください-常にメモリとキャッシュは同じものではなく、これらは少し異なります。







それでは、レコードについて話しましょう。







読み取りに関しては、すべてが多かれ少なかれ明確です-タランツールはインメモリで、メモリからすばやく読み取りますが、書き込みはどうですか？ Tarantoolは、読み取りとほぼ同じ方法で書き込みを行いますが、すべてのデータをディスクに保持します。 記録中にデータがディスクに保存されているにもかかわらず、なぜそんなに高速だと思いますか？ キーワードは連続しています。 今から見せます。







Tarantoolはトランザクションを完了したときに何をしますか？ 彼はそれをメモリで実行し、ログトランザクションに書き込みます。 トランザクションログに、彼は回復の目的、つまり すべてが上昇する場合は、ログからすべてをロールバックし、データベースを開始前と同じ状態に戻します。







ディスクへの書き込みは、次のように行われます。 ファイルに順番に書き込むだけです。 ファイルへの順次書き込みが非常に高速であることはご存知のとおりです。







質問は-遅くないですか？ 十分に速いです。 磁気ディスクでは、これは1秒あたり約100 MBであり、SSDでは1秒あたり250 MBです。 今すぐ確認できます。 SSDは通常Macbookにインストールされ、毎秒数百MBの地獄になります。 これはSSD上にあります。 磁気ディスクは少し遅いですが、それでも、毎秒100 MBです。 1秒あたり100 MBとは何ですか？ これは実際にはfigです。たとえば、トランザクションサイズが100バイトの場合、これは基本的に多く、つまり 数値を更新する何らかの種類のトランザクションは、set key = valueを更新するだけです。 キーと値を記述するだけです。 これらが数字の場合、これは文字通り数バイトです。 ただし、トランザクションが100バイトであっても、1秒あたり100万トランザクションです。 すなわち ピーク生産性-1秒あたり100万トランザクション。 これは、通常必要とされないパフォーマンスであり、非常に大きいです。 通常、ボトルネックはディスクではなく、プロセッサやメモリなどです。 すなわち 1台のマシンで非常に多くのトランザクションを実行するのに十分なデータを格納するのに十分なメモリがありません。







しかし、ディスクデータベースはどのようにディスクに書き込みますか？ なぜ彼らは同じくらい最適に書けないのですか？ 彼らはタランツールと同じことをすべて行います。 それらはメモリ内、キャッシュ内で更新され、トランザクションログも書き込みます。 トランザクションログは、クラッシュ後にデータベースを回復する唯一の方法だからです。







そして、これに加えて、彼らはまだディスク上のデータを更新します。 彼らはどうやってそれをしますか？







彼らは通常、古き良きBツリーを使用します。







これは、ディスクに保存するための最も一般的なデータ構造です。 ただし、LSMツリーなどの新しいデータ構造はすでに存在していると言わざるを得ません。 これらはTarantoolディスクエンジンで使用され、FacebookのRocksDBで使用され、GoogleでLevelDBで使用されます。 基本的に、すべての従来のランインデータベースはBツリーまたはB +ツリーを使用します。 MySQLまたはPostgres、Oracle-すべてがBツリー上に構築されています。 Bツリーはツリーのようなもので、価格はnのみで、各ノードにデータブロックがあり、その後のブロックへのリンクが多数あります。 そして、n-narcityのため、非常に短いです。 ただし、ここに保存されているデータを読み取るには、ディスクから3回読み取りを行う必要があります。 そして、これらのディスク読み取りは遅いです。 ここで最も重要な質問...ディスクデータベースのBツリーは、後でデータを読み取るためにのみ必要であると正しく言われました。 ディスクデータベースが、Tarantoolのように、データのコピー全体をメモリに保存する場合、つまり 彼らがタランツールなら、読む必要はないでしょう。 そして、読む必要がないときは、書く必要はありません。 彼らはこの構造に書き込みますが、それは後で数えるためだけです。 これは回復用ではありません。 リカバリには、Tarantoolのようにトランザクションログを使用します。 そして、これは単に彼らがディスクであるという理由だけでなく、悪いプログラマーがいるからではなく、彼らが書くのを遅くします。 そして、単にディスクであるためです。







さらに、そのようなデータ構造は優れています-線形検索にはつながりませんが、一方で、ディスクへのランダムアクセスにつながります。 磁気ディスクでは、これは1秒あたり最大100ヒットです。 なぜ磁気ディスクを使用すると、データを100 MB /秒で連続して読み書きでき、誤って100回/秒しかアクセスできないと思いますか？ これはディスクヘッドの物理的な動きにつながり、ディスクヘッドは非常に速く動くことができないためです。 1秒間に100回-これは非常に多く、想像してみてください。 しかし、ディスク全体に散らばっている100バイトを読み取ると、1秒あたり100バイトの速度で書き込みまたは読み取りが行われます。 単純なテストも実行します。単純なCプログラムを作成し、いくつかのギグのファイルを取得してページキャッシュに収まらないようにし、誤ってそこからいくつかのバイトを読み書きすることができます。 せいぜい100回/秒になります。 断片化すると、さらに悪化します。なぜなら、さらに数回のsikがあるたびに、これは毎秒数十回になるからです。 これは、これらのファイルも断片化されている別の問題です。 しかし、データベースはこれに対処できるようです。実際、データベースは事前にそこにある種の大きなファイルを作成し、その断片を編集しますが、断片化しないように時々圧縮します。 SSDでは、少し高速ですが、同じことです。1秒間に1000回です。 繰り返しますが、違いを感じてください-トランザクションログでは毎秒100万トランザクション、テーブルスペースではBツリーでSSDに数十回、100回、1000回-わずか3-4桁の差で書き込みます。



それでは先に進みましょう。 開始について。







私は読み書きについて話しました。 Tarantoolは、キャッシュ、キャッシュ、割り当て、解放、データ構造の変更、コピーなどよりも作業量がはるかに少ないため、すべてのインメモリおよびインメモリがキャッシュではないため、読み取りが速くなります。 また、Tarantoolは、トランザクション用ではなく回復専用のドライブを備えているため、表スペースを更新する必要がないため、より高速に書き込みます。



それでは、始めましょう。 Tarantoolはどのように起動しますか？ Tarantoolにはトランザクションログがあり、スナップショットがあります。まだ説明していませんが、後で説明します。 スナップショットは、ある時点でのデータベースの状態です。 Tarantoolは定期的にすべての状態をディスクにフラッシュし、ログトランザクションが大きくならないようにして、後で簡単に復元できるようにします。 したがって、Tarantoolの起動は2つのファイルを読み取るだけであり、ファイルは断片化されておらず、線形ではありません。 それらからの読み取りは線形です。 スナップショットを最初から最後まで読み、ログを最初から最後まで読み、この読み取り中にすべてをメモリに適用します。 Tarantoolの発売は次のとおりです。



どれくらい速い？







これも、磁気ディスク上で-100 MB /秒、SSD上で-200-250 MB /秒。







そして、これはディスクデータベースでどうなりますか？ 質問は非常に興味深いものです。ディスクデータベースに期限を設定する必要があり、スナップショットをメモリに読み込む必要がないため、ほぼ瞬時に開始されるためです。







しかし、その後はどうなりますか？ PostgresまたはMySQLがあるとしましょう。 彼らは始めました、次は何ですか？ すぐに動作しますか？ キャッシュはウォームアップ中です-それは錫です。 現在、私たちはHighLoadにいます-これは高負荷に特化した会議です。 負荷が高い場合は、キャッシュを完全に使用します。これは、キャッシュがないとデータベースが正常であり、原則として機能せず、負荷に対応できないことを意味します。 経験豊富なDBA、彼らはウォームアップ、さまざまなテクニックなどを強制する方法を知っています。 しかし、事実は残っています。 通常はどのようにウォームアップしますか？







キャッシュはどのようにウォームアップしますか？ これがウォームアップ方法です。 速くない。







ユーザーはデータベースにアクセスし、何かを要求しますが、データベースは誤ってディスクから何かを読み取って（データがキャッシュにないため）、それを与えてキャッシュします。 その後、次のリクエストが到着し、ディスクの別の場所で偶然に発生します。 はい、ウォームアップでき、catインデックスファイルを作成でき、たくさんのことができますが、大量のデータがある場合、ディスク上のキャッシュにあるはずのホットデータを誰も知りません。 調べる方法は？ ユーザーがリクエストを開始するまで、これはわかりません。 インデックスはホットデータであることは知っていますが、データは既にそのフォーマットでディスク上にあり、ホットデータは誤ってどこかにあるという考え方です。 キャッシュをウォームアップするには、このランダムなデータを最適なアルゴリズムで読み取る必要があります。これは、2つのファイルを直線的に読み取るよりもはるかに遅いです。 ここで、それらはホットデータです。Tarantoolには他にデータがありません。 ホットデータの場合と同じです。

ところで、高負荷システムHighLoad ++の開発者の会議の過去5年間の公開ビデオを公開しました。 YouTubeチャンネルを視聴、学習、共有、購読します 。

ディスクデータベースでは、これらのホットデータをどこかの穀物のように探す必要があります。 実際には、MySQLから絞り出せるすべての優れた管理者であるMail.ruは、1〜2 MB /秒です。 ボリュームには100 GB、1 TBのデータベースがあり、この速度を超えると、すべての手法で起動、ウォームアップできません。ホットデータはさまざまな場所のディスクに散在しているため、驚くことではありません。 シキをする必要があり、頭を動かす必要があります。 条件付きで、10キロバイトのデータを読み取り、頭を動かして1ミリ秒費やし、さらに数キロバイトを読み取ります。また、1ミリ秒費やしました。 したがって、10 Kバイトごとに1ミリ秒を費やすと、1 MB /秒になります。 あなたは単にI / Oに遭遇します。 そのような状況。 ウォームアップのこの違いは、キャッシュと「常にメモリ」が2つの異なるものであるという事実の結果であることに注意してください。 すなわち Tarantoolは必要なものを常にメモリに保持し、すぐに起動し、すばやく読み書きできます。







また、ディスクデータベースの配置は異なります。データはディスク上にあり、キャッシュに何かがある場合があるために設計されており、このデータはディスクデータの中に散らばっていて、どこか別の場所にあるため、スロースタートが発生します。 違いはどこかで100倍です。







これは、Tarantoolがすべてのホットデータを単に設計によって1か所にグループ化するということです。







次に、遅延について説明します。 レイテンシは、リクエストの開始から結果の受信までの時間です。 Tarantoolについて話すときは、ディスクデータベースとは比較しません。すべてが明確であるため、他のインメモリデータベースと比較します。







どのようにすべてが始まりましたか？ むかしむかし、毎晩Mail.ruで、このようなレイテンシのピーク、つまり 何らかの理由で、クエリの実行時間が定期的に1000倍に増加しました。 すなわち ミリ秒ではありませんでしたが、1秒でした。







私たちはなぜこれが起こっているのか考え始めました。 さらに、これは夜に起こります。明らかに、ユーザーがこれを責めるのではなく、それは私たちの中にあるものです。 私たちはこれに対処し始め、その理由は簡単であることがわかりました-これはスナップショットです。







インメモリデータベースは、ディスクデータベースとは異なり、マイナスであることが非常に有名であり、時々スナップショットを作成する必要があります。 すなわち ディスクデータベースがスナップショットされない場合、自動的に動作し、Bツリー内のデータを変更し、トランザクションをログに書き込みます。ディスクにすべての状態を定期的にフラッシュする必要はありません。読み取り可能な形式。 インメモリデータベースにはありません。 スナップショットをたまに作成する必要があります。これを行わないと、巨大なトランザクションログが蓄積され、非常に長い間使用されるためです。 トランザクションログにスナップショットよりも時間がかかる理由を理解していますか？ 同じフィールドに対して50〜100〜1000の操作を行うことができ、トランザクションログでは各操作が個別に実行されるため、これをすべてロールオーバーする必要があります。 スナップショットでは、現在の最後の値として1つになります。 したがって、インメモリデータベースは常にスナップショットを作成する必要があります。







スナップショットがすべてを遅くするのはなぜですか？ データベースはスナップショットとスナップショットであり、ディスク上でスナップショットされているように見えますが、ディスクはボトルネックであるように見えますが、メモリで動作します。なぜスナップショットはデータベース全体を遅くすることができますか？ ブロッキング。 これは非常に興味深いロックです。







データベース全体をロックしてスナップショットを作成しないようにするため、適切なタイミングで分岐させました。 Fork（）は、プロセスのコピーを作成するだけのLinuxまたはUnixシステムコールです。 すなわち .



Snapshot? fork(), . Fork() , parent, . parent . log , ? Copy-on-write.







fork()? Fork(), -, parent' child', , . 100 . 4- , , - , . copy-on-write. これは何ですか child, , parent', .. . parent child 1 , , , — 4 . T.O. ? Tarantool parent update', update' -, update , update', 4 . update - — . すなわち , . T.O. CPU, .







, in-memory , , , , Redis, Couchbase, Aerospike. - . , , .







, ? , snapshoting'?







, copy-on-write, copy-on-write, Tarantool, , . - multiview concurrency control.







, .. , , . , , , — Tarantool, , . — snapshoting' . , copy-on-write. , . , , profit. . fixed cost . snapshoting, , .







. , . - , . , . , snapshoting'. すなわち . , , , , , , , , , .







. . — 1.6.6. 9 . Snapshot , , .



, , latency. — .







, , , , « ».







C++, Java , . , ++, std::unordered_map — , . , .. , , , , (1), . , , . .



( ) 2 . . , , — . - /.



, , . 10 . , 20. 2 . — ++ , , , 100 , , . なぜそう , , « ».



? , - , — , , .. — .







? 5 , , . — , mutex. - . , mutex. log , , table space, log , . すなわち 5 . , Postgres, MySQL, Oracle 10, , -.



SQLite memory , .. SQLite — std::unordered_map, , . , , , , , , . , .







? . . , , , . - , read /dev/zero, , . /dev/zero, , 0, , , , 1 . . , std::unordered_map, . 1. 5, . log, , , 90%-95% — .







Tarantool? : ? すなわち , . , - , , , . write, Tarantool read, , , read. . Tarantool , , . , , , , , .. . . すなわち write, syscall write - . write .







こんな感じです。 , , thread', . , , Tarantool read', transaction-, in-memory, write, .. thread, thread write. , inter thread communication, .. , , , per , per , per . . , , , , , …



, , , . 100 — 100, . 1 — 1, . latency . , , . , , , , , ?



, , . , :







, –







: , , transaction-, thread transaction- . thread… Redis, , Redis CPU, , interthread-, thread. , thread, , , , .



: , , — .



: 2- , thread event-, thread , — event-. shared memory .



: , Tarantool , . …







, , 2-3 , , , , , , .







, . open-source, , . ( ), . すなわち -. , - , . , , , .

» anikin@corp.mail.ru

» danikin

» Mail.ru

— HighLoad++ . HighLoad++ 2017 .



, .



Tarantool?

• PgSQL Tarantool / (Calltouch);
• NoSQL Tarantool / (Mail.Ru);
• : key-value- / , (RAIDIX)
• libfpta — SQLite Tarantool / (Positive Technologies)

また、これらの資料の一部は、高負荷システムHighLoadの開発に関するオンライントレーニングコースで使用されますガイドは、特別に選択された文字、記事、資料、ビデオのチェーンです。私たちの教科書にはすでに30以上のユニークな資料があります。接続してください！