RAM内のデータ用のDBMSの特別な点

コンスタンチンオシポフ（ kostja ）

レポートのアイデアはどのように生まれましたか？ 機能、特に将来の機能について話すことや話すことはあまり好きではありません。 人々はそれを聞くのが本当に好きではないことがわかりました。 彼らはすべてがどのように機能するかについて聞きたいです。 これは、すべてがどのように機能するかに関するレポートであり、私の意見では、最新のDBMSで動作するはずです。



マクロレベルからミクロレベルにダウンできるようにしようと思います。 最初にマクロの問題を破棄することにより、中間レベルとミクロレベルで選択できるスペースを作成する方法。







マクロレベルでは、これが最新のDBMSの配置方法です。 今日、新しいデータベースを作成する機会があるのはなぜですか。現在のデータベースを使用してそのパフォーマンスに満足できず、そのためのパッチを強化または作成できないのはなぜですか。 それが遅い場合にそれをスピードアップするパッチを取り、書いてください？ どのソリューションスペースから選択しますか？







さらに、いくつかの基本的なアーキテクチャの原則を修正した後、下に進んでエンジニアリングについて話す必要があります。 マルチバージョンのバージョン管理を使用してトランザクションを処理するデータベース、ロックを使用してトランザクションを処理するデータベースがあるという事実に加えて、このアルゴリズムを実装した方法（相対的な手がまっすぐな方法）はパフォーマンスに直接影響します。 最初の要因が数十倍の生産性向上をもたらす場合、2番目の要因は2〜3倍を与えますが、重要なこともあります。 Tuzikヒーターパッドは好きではありません。何百万もの機能がありますが、パフォーマンスが低下するなどしないからです。 これはエンジニアリングです。



レポートの2番目の部分は、アルゴリズムとデータ構造に関するものです。 基本的な工学的アプローチの修正方法、スレッドの操作方法など そして、最速であり、何よりも速く、より良いデータを処理および保存できるデータ構造をどのように実装するかを言います。



第3部と第4部が最も激怒しています。少なくとも、実装したアルゴリズムとデータ構造についてトップに話そうとしているからです。



DBMSアーキテクチャ。 どこから始めますか？ 2015年に最新のデータベースを使用する機会があるのはなぜですか。







基本的な要件を思い出させてください。これは私たちがプレイできるスペースです。 ACID要件を満たす必要があります。 私の意見では、ACIDをスキップできると考えているデータベースは、真剣に考慮されません。 遅かれ早かれ、彼らがあなたに与えるデータを失う必要はないことが明らかになり、ユーザーフレンドリーである必要があり、一貫性を保つ必要があるなどの理由で、これは膝の上の技術です。 これはアカデミックな定義ですが、実際には、このような小さなスライドのACIDにも深aがあります。 彼については2-3-4時間話すことができます。



DURABILTYとは何ですか？ 私がこれについて議論するときはいつでも、私は常に、デュラビリティが核戦争に関して何であるかを言います。 攻撃者の可能性が高い場合、データベースは耐久性がありますか？ または分離-それは何ですか？ 2つのトランザクションの可視性が互いに影響しないようにしたいのはなぜですか？ しかし、もし私がトリッキーな男なら、ラップトップを2台持っており、1台のラップトップともう1台のラップトップから接続します。 あるラップトップで始めて、挿入して、そこに挿入したものを見て、これに基づいて決定を下し、始めたラップトップで、目で見たデータをすでに挿入しました。 私はいかにunningなのか、孤立を欺いた。 ここに保証はありますか？ しかし、それにもかかわらず、これらはゲームのルールです。



そして、パフォーマンスに非常に深刻な影響を与える最も基本的なものの1つが分離です。 なんで？ トランザクションの相互分離は、一度に非常に多くのものに影響を与えるようなものだからです。 つまり 誰かに自分のバージョンのデータを読ませ、他の人の邪魔をしないようにすることができます（Postgresの仕組み、MySQLとInnoDB）。 しかし、レコーディングに関して言えば、ジレンマがあります。 同じデータを更新しようとしている2人の参加者を分離すると同時に、アルゴリズムの観点から互いに完全に分離する方法はありません。







何らかの形で、他の参加者に同時に他の誰かがこのデータを操作していることを知らせる必要があります。 これは、スケジュールの概念を通じて理論的に形式化されています（スケジュールの例を挙げました）。 データ項目、つまり XとYはデータ、1と2は参加者、rとwはオペレーションです。 参加者はデータの読み取りまたは書き込みを行い、Eは作業に応じたスケジュールです。







最終的に、分離を提供する唯一の印象的な方法は、ロックを介したものです。 20、30年前のデータベースの基礎は、2フェーズロックの定理に基づいていることでした。







つまり シリアルスケジュールを達成するには、参加者が変更するオブジェクトのロックを取得する必要があると言います。 同時に、マルチバージョンの競争力のあるコントロールがあります。これにより、場合によってはキャプチャを回避または遅らせることができます。 最後に、コミット時に、整合性が侵害されていないことを既にチェックし、何らかの方法で検証することができます。 つまり ロックは参加者に大きな影響を与えませんが、それにもかかわらず、マルチバージョンの競合制御においても、そのようなアルゴリズムは特定のシナリオで存在しないオブジェクトのロックを必要とします。 最も厳格なシリアル化モード-従来のDBMSではシリアル化可能と呼ばれますが、ロックをロックする必要があります。







これは基本的なメカニズムであり、学界では2フェーズブロッキング定理によって修正されています。 これらのロックを蓄積する必要があります。 従来のDBMSは、このスキームに基づいて構築されています。







さらに、従来のDBMSは元々ユニバースで構築されていたため、「ディスクとメモリ」の比率は現在とは異なり、完全に異なります。 比較的言えば、640 KBのメモリと100 MBのディスクを搭載することは可能でした-それは良かったです。 つまり 比率は1から100のどこかになります。 これらの関係は変更されました。 そして、速度はさらに根本的に変化しました。 以前のRAMがディスクの100倍しか高速でなかった場合、現在ではディスクの1000倍または10000倍の速度です。 選択しなければならなかった比率に根本的な変化がありました。







これが重要な理由の古典的な例は、古典的なDBMSが2層ストレージの原則に基づいて構築されていることです。 ディスク上のデータのある種の表現があり、メモリ内のデータの表現があります。 メモリは実際にビューをディスクにキャッシュします。 必然的に、ディスクを効率的に使用することとメモリを効率的に使用することの間のトレードオフが必要になります。



特に、ディスクを効果的に使用するには...スライド上の空白に注意してください。これは、行を格納する典型的なDBMSの典型的なページです。 通常、ディスク領域は高価ではなく、ディスクへの書き込みコストは書き込むサイズに比例するのではなく、ディスクアクセスの数に比例するため、ページはいっぱいになります。 したがって、ディスクに穴を開けるのは理にかなっています。怖くないので、この穴を記録します。穴を記録しても費用はかかりません。



RAMでは、ストーリーはまったく異なります。 呼び出しのコストはほぼ同じであるため、データの占有スペースをできる限り小さくすることが重要です。 RAMのランダムアクセスの価格はそれぞれほぼ同じですが、できる限りコンパクトにすることが理にかなっています。 これらの要因の1つは、RAMのDBMSをゼロから作成する場合、多かれ少なかれ基本的なアルゴリズムとデータ構造を確認することは理にかなっているということです。 これらの穴を取り除くことができます-これはほんの一例です。



ところで、この例について話すと、興味深い話が得られます。 多くの人が「なぜDBMS Xが必要なのか、DBMS Yを使用し、メモリを追加するだけです」と言います。 私は、人々が中古店向けのデータベース、つまり ディスクベース、MySQL、Postgres、Mongoには、一定量のメモリを割り当て、すべてがメモリに収まり、満足しています。 データベースをメモリ内に作成すると、典型的なメモリフットプリント、つまり 占有されているメモリの量は、ディスクへの格納に関連するすべての問題が存在するわけではないため、何倍も少なくなる可能性があります。 経済的には、DBMSを使用するのは間違っています。DBMSは、ディスクに保存し、お金を捨てて、すべてのデータをメモリに格納することを目的としています。







私のそのような製作は空の場所に基づいていません。 2008年に、DBMSがさまざまなサブシステムで実行するアクティビティの分析を含む、DBMSの世界の古典の1つによって記事が公開されました。 作業の何パーセントとDBMSが何であるか。 メインのブロックサブシステムが特定されました。ラッチは同じブロックですが、データではなく相互作用するプロセスをブロックする必要がある場合にのみ、より低いレベルでのみ行われます。 そして、この記事では、現代のDBMSのわずか12％が有用な作業に費やし、その他のすべてはこれらのマジックレターACIDおよび古いアーキテクチャとのやり取りに費やしていると結論付けられています。 時代遅れのアーキテクチャの原則に基づいて動作するように。 このグラフから、この可能性の窓が進み、機能を失うことなく、または機能を大幅に失うことなく、DBMSを数十倍高速化できます。



これらのロック、飛行などすべてをどうやって取り除くことができますか？ 個？ メモリディスクからデータを転送し、プレゼンテーション形式を変更するためのオーバーヘッドをどのように取り除くことができますか？ ここに、私が書き出した、Tarantoolアーキテクチャの基礎を形成したベースを示します。







実際、これはユニークなアーキテクチャではありません。 Meiscached、Redis、VoltDBを見ると、私たちだけではないことがわかります。 それから、私たちは比較的率直に言って、私たちのリーグで競争し始めます。 リーグに向けて出発します。

• RAMに100％のデータが保存されています。
• ロックを取得する必要がないように、トランザクションを順次実行します。 ロックの概念はまったくありません。トランザクションに割り当てたRAMの量をあきらめ、それを排他的に使用してから、次のトランザクションを実行します。

それでも同じように、データを分割する、つまり 水平スケーリングは標準であるため、1台のマシンでデータベースを効率的に動作させようとはしません。 今日の1台のマシンは、まだスーパーコンピューターです。 RAMへのアクセスのコストが異なる48コア、つまり 1つのコアから1つのサイトにアクセスする場合、1つの価格があり、別のコアから同じサイトにアクセスする場合、異なるアピール価格があります。 これはすでにスーパーコンピューターであり、1台のコンピューターでの効率的な作業は、10〜20年前には必要なかったタスクと同じであるため、この問題はまったく解決しません。



このストーリー全体に興味深い点が1つあります。 トランザクションを順次実行するDBMSがメモリにあると言います。 何が起こっているの？ トランザクション中にデータを失わないようにする必要がある場合、それらをログに書き込む必要があります。 この作業をキャンセルすることはできません。 まだジャーナルがあり、ジャーナルはディスクに保存されます。 ログに各トランザクションを次々と書き込むと、ディスクが遅いため、パフォーマンスの問題が発生します。 CPUをほとんど使用しないという事実は何も与えません。ディスクは遅いです。 一度に1000トランザクションで、100で、大量にジャーナルを書き込む方法を把握する必要があります。その後、この記録コストを多くのトランザクションに分散し、フロップを増やすことができます。 帯域幅。 この方法では、生産性は向上しません。 トランザクションごとに、レイテンシは同じままであり、ディスクへの書き込みコストに対応しますが、この方法でボリュームとスループットを増やすことができます。







問題は、ログエントリが失敗した場合のトランザクションのロールバック方法です。 原則として、私はこれらの技術を文献で見たことはありませんが、タランツールは映画に関する類推を使用しています。 既にメモリ内で完了したトランザクションがあり、それをログに書き込む必要があるとします。 このトランザクションは、低速のディスクが書き込むまで順番に待機しています。 その瞬間、同じデータを読み取りまたは更新する別のトランザクションが入りました。 彼女とどうする？ 彼女がそれをするのを防ぎますか？ 実行を禁止すると、生産性が急激に低下します。 実行を許可すると、順番を待っているトランザクションが記録されておらず、ディスク容量が不足していることがわかります。 それでは何をしましょうか？ ロールバック。 \



タランツールでのロールバックは、リバースプロモーションの原則に基づいて行われます。 すべてのトランザクションは、お互いを期待せずに、楽観的に次々に実行されます。 ある種のエラーが発生するとすぐに、トランザクションがメモリ内で実行された後、しばらくしてエラーが発生します。 コンベアを停止し、反対方向に回転させます。 「ダーティ」データを実際に見たものをすべて捨てて、パイプラインを再起動します。 これはめちゃくちゃ高価な操作です。 高負荷では10,000トランザクションが失われる可能性がありますが、 非常にまれにしか発生せず（動作中に発生することはありません）、ディスク領域を追跡するだけです。



まあ、「決して」はカテゴリー的ではありませんが、実際には、機器を追跡する場合、それは起こりません。 これは費用です。 そして一般に、一般に、システムを設計するとき、最も可能性の高いシナリオを中心に設計する必要があります。 アーキテクチャ上の決定のコストを同じにしようとする場合は、単純にリストします。ロールバックがある場合、コミットがある場合、他に何かある場合はどうなりますか？..コードがこれに一致する場合、ほとんどの場合、効果的なシステムを構築できません。最悪の場合、あなた自身を評価してください。



このように修正した これらの基本原則に基づいて、エンジニアリングの側面に進みます。 エンジニアリングについて私が言いたいこと。







会議では、ChronicleMapと呼ばれるメモリ内のデータベースに関するレポートがあります。ChronicleMapは興味深いものです。このDBMSのエンジニアが設定した目標は、DBMSを更新するためのマイクロ秒のレイテンシを達成することです。 タスクは、何よりも、更新にかかる時間を大幅に短縮することでした。 私たちの場合、状況はわずかに異なります。 そして、このトレードオフを別の好意で決定します。 私たちは何について話しているのですか？ 会議に行く必要があり、交通渋滞がないと想像してください。 あなたはタクシーに乗るし、それは高速になります。 あなたは公共交通機関を使用します-それは安いでしょう。 なぜ公共交通機関は安いのですか？ 多くの参加者に価値を広めるからです。 キャリッジが発生します。 運用コストを全員と分担します。 そして、私たちの場合、目標はまさにそれです。



他のDBMSがタスクを設定した場合、たとえば、待機時間は非常に短くなりますが、最大スループットではない可能性があります。 帯域幅、私たちの状況では、RAMが与えるレイテンシは私たちにとって十分であると言いました-たとえば、1つのリクエストを処理するのに数ミリ秒です。 これは到達したいパラメーターであり、残りについてはスループットを最適化したい、つまり 帯域幅。 リクエストの最大数がコストを共有するようにします。 これはエンジニアリングの観点からどういう意味ですか？



ネットワークが低速であり、ネットワークは本質的に高価です。 私たちは40年前の古代のオペレーティングシステムの世界に住んでいるので、交換するには費用がかかります。また、コアを見ずにオンラインに行く方法はありません。 ディスクも非常に高価であり、ディスクの記録自体は遅いですが、ディスクを書き込む必要があります。これは、データを保存して電源障害に耐えるための唯一の方法だからです。 また、1つのスレッドで動作し、トランザクションを次々に実行するトランザクションプロセッサもあります。 トランザクションプロセッサはパイプラインです。 このコンベヤを最小限のアイドル状態にする方法は？



各リクエストにパイプラインがある場合、ネットワークに行き、ディスクに行きますが、ほとんどの場合、2回行う必要があります。 彼はリクエストを読み、処理し、ディスクに書き込み、応答し、結果をクライアントに渡す必要があります。 つまり ディスクごとに1回、ネットワークに2回アクセスします。 このカタバシアはすべて非常に長い時間がかかります。 1つの要求に対して、できるだけ安く、ネットワークからできるだけ早く読み取るようにする必要があります。 これのために何をしていますか？ プロトコルは完全に非同期で、パイプラインモードで動作します。 1つの接続から多くのクライアントの要求を読み取り、すべてのクライアントに同時に応答できます。 つまり 各クライアントが独自の回答を取得し、これらすべてを1つのソケットで多重化し、すべてのレベルでパイプ処理を行います。 あらゆるレベルの作業でパイプライン化。 これは、DBMSを構築する上で非常に重要なトレードオフです。 したがって、私たちは同じスレッドで作業するため、マルチトレッドである他のソリューションよりも待ち時間が短くなりますが、それにより1つのリクエストのコストが削減されます。







実装の観点から、私たちが存在するパラダイムを並列化する方法を見つける必要があります。そのパラダイムではすべてを並列化します。 このようなパラダイムは次のいずれかです。







実際に、これらのいずれかを選択する必要があります。 競合するスレッドがあると言う場合、これらのスレッド間で何らかの方法で情報を交換するため、交換方法を選択する必要があります。



私たちの場合、これが特に重要なのはなぜですか？ スレッド間で交換する方法を選択すると、これらのコストに影響を与えるため、これらのコストは多かれ少なかれ明らかです-カーネル、ディスク、ネットワークに行くだけでなく、キャッシュ、プロセッサのキャッシュをフラッシュする頻度など、暗黙の事柄があります。つまり 私たちとキャッシュはうまく機能しますか？ そして、これが暗黙的に起こることを考えると、これは実際には霧の中の検索です。 何かが変更されました-キャッシュが少し良くなり始め、生産性がわずかに向上しました。



実際、私たちは今、どの世界に住んでいますか？ 処理しているこの大きなRAMに加えて、16〜32 MBのレベル3キャッシュがあり、これはすべてのコアで共有され、レベル3キャッシュの使用をより効率的に開始すればするほど、うまく動作します。 。 したがって、私たちのタスクは、3次キャッシュを実際に機能させ、効率的に機能させることです。



さて、このような選択肢があります（上記のスライドを参照）。パラダイムについて話している場合、これがすべてエンコードされているある種のパラダイムを選択する必要があります。



今後は、最後のパラダイムを選択したと言います-これは俳優モデルです、なぜですか？







ロックはどうですか？ 私はすべての意識的な生活の中でミューテックスを使用してプログラミングしました-素晴らしいツールです。 効果的なプログラミングのためのmutexの主要な問題の1つは、合成の問題です。 私たちは何について話しているのですか？ たとえば、競合するデータ構造に挿入するクリティカルセクションがあるとします。 データ構造は、多数のスレッドで機能します。 この重要なセクションを取り、それを何らかの方法でカプセル化します。 何らかの競合データ構造に挿入メソッドがあります。 次に、このデータ構造を使用する特定のマクロ構造があり、クリティカルセクションでも機能するはずです。 彼女も競争力がなければなりません。 ロックを使用すると、単に1つのメソッドを別のメソッドから取得して呼び出すことができません;なぜ10回以上考える必要がありますか？ これにより、デッドロックや、ここで説明した他の問題が発生することはありません。 これはどこから来たのですか？ 単に相互にロックを使用するコードを勝手に使用することはできません。カプセル化を実行し、問題をより小さなものに分解すると、メインのプログラミングプロパティが失われます。 実際、待機のないアルゴリズムは、デッドロックの問題という1つの問題を解決します。 待機なしのアルゴリズムは待機していないため、デッドロックされません。 しかし、彼らは他の問題を解決しませんか？ アルゴリズムに関連する？ ロックモデルを中心に構築されています。







デッドロックは待機サイクルです。 コード内のある場所からA、Bの順序でロックを使用し、コード内の別の場所からB、Aの順序でロックを使用します。 そして、負荷の下で、このすべてが崩壊しました-デッドロック。



護衛とホットスポットとは何ですか？ これは、待ち時間のないアルゴリズムにも適用されます。 問題は何ですか？ このクリティカルセクションが2つのスレッドで機能するという前提でプログラムを作成しました。 たとえば、彼女にはプロデューサースレッド、コンシューマスレッドがあり、これらのスレッドは平均してこのクリティカルセクションにアクセスします...毎秒1000リクエストの負荷があるとします。 したがって、彼らは1秒間に1000回クリティカルセクションを参照します。すべてがあなたのために機能します。 その後、状況が変わります。 ハードウェアが変更されているか、スレッドが実行している作業が変更されている、またはそれらが動作する環境が変更されています。 このシステムにはまだ未知のものがあります。 構成可能性、つまり システムの拡張と調整を開始すると、クリティカルセクションが突然熱くなります。 クリティカルセクションの下で実際に2つの変数を更新する小さなことを考えてみましょう。ただし、計画どおりに1秒間に1000回ではなく、1秒間に10,000回、1秒間に100,000回、痙攣し始めます。スレッドはコントロールなどから削除されます。 次に何が起こるでしょうか？



優先順位や順序、つまり 一部のリクエストは優先度が高く、一部のリクエストは優先度が低いと言います。 これにより、クリティカルセクションへの優先度の高いリクエストが優先度の低いリクエストより優先されるようになる可能性があります。 優先度が低くなることはありません-これは飢starです。



コンボイとは、大きなクリティカルセクションに小さなクリティカルセクションが埋め込まれている場合の状況であり、このため小さなクリティカルセクションに突入することはできません。



1つの結論で何らかの形で表現されるさまざまな状況があります-ロックは複合的ではありません。 システムはロックを中心に記述されており、これがプログラミングの主要なプリミティブである場合、これからスケーラブルなシステムを構築することはできません。



これは私だけでなく、30〜40年前にアーランを作ったアーランのクリエイターにとっても明らかでした。 概して、Tarantoolを記述するツールについて話す場合、このツールはおそらくErlangと呼ばれます。







一般に、合成可能性の問題を解決できるアプローチの1つは、クリティカルセクションが明示的に定義されておらず、実行中に機能の依存関係に基づいて並列処理が決定される関数型プログラミングアプローチです。 つまり、どこにもロックをかけませんが、同じ機能を持っている場合は、機能的に別のロックに依存しているため、作成者に対して透過的に実行を並列化できます。



これは、これをかなりうまく行うことができるあらゆる種類の関数型言語で使用されます。 共通のデータがないため、共通のデータに関して競合はありません。 関数型プログラミングが適しているようです。



しかし、残念ながら、システムプログラミング、つまり 機能的なアプローチとシステムプログラミングを組み合わせるために、依存する環境はありません。



このように、私は最初に私が甘やかしたモデルに来ます、そして、これはまさに我々が熟考する必要があるものです、それは我々が複雑なシステムを作り、それを安くすることを可能にします。







アクターモデルを魅力的にするもの、つまり 独立したメッセージングモデル？ シングルスレッドシステムがあります。このシステムには、すでに協調マルチタスクがあります。 1つのスレッドのレベルで、線形に実行されるマイクロフローを作成しました。共有メモリを介して相互に対話できます。問題はありませんが、メッセージを送信して相互に対話することもできます。



スレッド間の相互作用の問題を解決することは私たちに残っています。 「マスメッセージングシステム」の図に戻りましょう。







Networkスレッド、Transaction Processorスレッド、Write Ahead Loggingスレッドがあり、各スレッドのリクエストごとに、概念的にはエンティティ（アクター、アクター）があります。 ネットワークスレッド内のアクターのタスクは、リクエストを取得し、解析し、その正当性を分析し、「このリクエストを実行してください」というメッセージをトランザクションプロセッサに送信することです。 トランザクションプロセッサはリクエストを受け取り、そこに重複キーがあるかどうかを確認し、他の制約違反があるかどうかを確認し、いくつかのトリガーを実行し、どこにでも挿入し、先読みログの対応するbadiに対して「OK」-このリクエストを書き込みますドライブ。 彼はリクエストを受け取り、ディスクに書き込みます。



文字通り、私たちがやった場合、私たちは各リクエストに対してメッセージを交換します。 これを減らしたい、つまり このパラダイムでは、プログラムのエンティティにメッセージを交換してもらいたいのですが、この交換のコストは最小限です。 交換を多重化する何らかの方法が必要です。 また、アクターモデルは、メッセージの交換をカプセル化するという事実により、メッセージをバッチで送信できます。 つまり アクターモデルを使用します。何かを行うには、異なるスレッドの対応するアクター間でメッセージを送信する必要があります。メッセージが送信されるたびに、対応するアクターを偽装します。 。 コントロールからそれを削除し、コントロールを次のアクタに転送します。 したがって、コルーチンに基づいて、各スレッドで絶えず動作しますが、アクター間で絶えず切り替わります。



なぜこれが私にとって中心的な問題なのですか？ 「アクターモデル」スライド（上記参照）に美しいハイパーキューブを描きました。そこでは、まさにそのようなパラダイムの重要性を強調しています。 ハイパーキューブの特性は何ですか？ そこに結合の数がノードの数に比例して増加するという事実、すなわち 二次関数ではなく、比例的に。



Tarantoolを使用する場合、このハイパーキューブの頂点は個別のスレッドと見なすことができます。 スレッド間の接続を低くして、頂点間のリンクを介してスレッド間のリンクを形成する必要があります。 そして、私たちの仕事は、交換が安価になるように、接続の数を少なく維持することです。



Kreiaなどの古代のスーパーコンピューターを思い出して設計を見ると、実際にはハイパーキューブの原理に基づいて構築されていることがわかります。 一般に、通常の機械式電話スイッチを見ると、同じ問題を解決しようとしています-相互作用する多くのエンティティの多重化を3次元空間に適合させ、効果的に行う方法です。 これは、エンジニアリングではなく、何らかの空間的思考であることが判明しました。



4次元の超立方体が描画されるのはなぜですか？ 1つのスレッドと1つのスレッドでの相互作用についてのみ説明しましたが、シャーディング時に同じ問題が発生します。リクエストがクラスター内の任意のノードに到着し、このノードはこのリクエストを処理するためにすべてのノードと対話する必要があります。 債券の数が2次成長するという同じ問題があります。 参加者数からのn個の2乗リンクがあります。 そして、接続数を制御する唯一の方法は、何らかの方法でそのようなスペースに接続することです。



なぜ現代のシステムの観点からこのモデルが良いのですか？ 典型的なチップを使用する場合、中心にあるこの小さなものはレベル3キャッシュです。







この意味で非常に面白いのは、2015年のCISCとRISCアーキテクチャのファンの間の論争です。 私は両手でARMプロセッサを支持しています-彼らは最高の省エネなどを持っていますが、アーキテクチャに関する議論は私を笑わせます。なぜなら、概して、現代のCPUは第3レベルの巨大なキャッシュであり、他のすべてはチップ。 , – , 3- , .







Actor model , , ? 3- , , . , - , .. , , . , Intel , . . – , 1000 10000 . , latency 1-2 , , .



3 , -, – , .







1 2? , .



– , , . , , .



? , ?



, . , , ?







, , . , . , : « , ?». , , , , , – . .



. . , , , .. . , , , .. , , , multiversion concurrency control, .







, . , , .. , . , , , , – () runtime.



runtime , . . – , – . , .



. :







, 4 . . , , .. . . , , , – . , , , , , .



( , ) slab'. slab' , . , , . つまり 8 , . , , .







, - . thread local , slab_cache, buddy system.



buddy . , , , .. . , slab 4 , . Buddy slab_cache , 2 4 . , , .. , – buddy. , , .. . , , slab cache', .



, , – , , .. , , , . , - , , , . .







pool – object pool, slab cache , slab', , 2 , 4 , slab' - . – .



, connection fiber, user, – . , , mempool'. mempool', , .







mempool'e slab , . slab . , , . slab' . – 24 24 – , , slab' 4 . 32 – - slab' 4 , 40 – slab' 4 , 48 – slab' 8 . , , .



slab – , slab. つまり , , 200 , slab' 4 , – – ! – 800 -, , . , . slab – – – . , 8 , .. . 8 slab.



, tarantool. url – github.com/tarantool/small , , , , , , . , , rtfs.







? , . , – . , , - – region , , .. obj-. JCC , , open source. , . つまり region slab slab'.



string, string? : , – , , .. つまり . , , .



, , ? . ? , - . , ? , , . – , – . . , , - , .. , , - , .. . – . – , « «», , , ». つまり . , . , , .. , .



, . , , 4- . , , , . ?







, , – - . ? ( , ). small – small object allocation. – memory address translation. つまり – user space tlb. , 32- . , , , , , 8- , 32- . - , - . . . , . , , 16 , 32, 64 .. – . 32- . 彼はどのように働いていますか？



, 3- . root root extent' . extent' – 2048, root 11 32- . extent, .. , , – , .. 11 . , , .. , , .



, .. . , , free . – 10 . - . - , , l-3 , .



? , .. . , . ? , , – - extent' , , copy on write . , , .. , free . . , , , .



? , .. , . , Tarantool std::map? , , . , , std::map .







, ( 1.7), , slab . , , .. , , garbage collection, .



? , -, .. – . . , : 10 – , 15 – , , , , , , . . .



, ? , , - - extent' , .. , . 何ができますか？ extent , , , , , – .



, , , , , , .. slab , . , , – . . , , .



?







, . -? , – – . , . , , . , , , , , , , ? , .



, , ++ , , , . , , . , , , , , , .







– , . つまり . , , . どのように機能しますか？



, 16 . 8 – , , 32- – . .



. – , . つまり , 3 , 4, 4 – 4, 5 – 8. , . , , . 1 .



– , . , – 2, 0. , , , , 4 , , 4 – . 5- , . 5 , , 8-. , , 4-, 4 , 8 . 0 , , , .



– , .. , .. . , – , , , , , . 1 .



: cver , . , , , .



« ». . , MySQL, Monty Hash, MySQL. .



? , , .







. ? Tarantool 1.3 1.4 , , ? : – , , , 16 , – , . – . AVL , B , , , – , .. , 30-40% . , , .. , , , , , - , , . – B+* :







? , , – 20 , , , 40. , , , , .



, , , . , . つまり , , , . , , , , 32- .



:







, 3- , - - . , .



B+, B+* B , ..? 2/3, , , . . , 1/2, - . 1/2, 1/2 – , , , , - 1/2 . 2/3, .. , , , , . , , . , .



?







, , .. 1.1 log(N) . , , .



, , , – 1.6. 30-40% , .. , – , 40 %, 2-3- , 2 . つまり , , .

連絡先

» kostja

» Mail.ru

— HighLoad++ . 2016 — HighLoad++ , 7 8 .



— HighLoad++ . 2016 Tarantool " ".



, HighLoad++ Tarantool . () , , .



- HighLoad.Guide — , , , . 30 . !