メモリ内のDBMSでのクエリの非同期処理、またはシングルコアで毎秒100万のトランザクションを処理する方法

こんにちは 前回の2回の記事では、RAM内のDBMSがデータの安全性をどのように提供するかについて説明しました。 こことここで見つけることができます。



この記事では、RAMのDBMSパフォーマンスの問題に触れたいと思います。 指定されたキーに従って値が単純に変化する場合、最も単純なユースケースからパフォーマンスの議論を始めましょう。 さらに簡単にするために、サーバー部分が存在しない、つまり ネットワーク上でクライアントとサーバーの対話は発生しません（これを行った理由はさらに明確になります）。 したがって、DBMS（それを呼び出すことができる場合）は、アプリケーションのRAMに完全にあります。



データベースサーバーがない場合は、アプリケーションのメモリ内のハッシュテーブルにキーと値のペアを保存している可能性があります。 C / C ++では、このデータ構造は次のようになります。



std::unordered_map







この構造の速度を確認するために、次の内容の1.cpp



ファイルを作成しました。

 #include <map> #include <unordered_map> #include <iostream> const int SIZE = 1000000; int main() { std::unordered_map<int,int> m; m.reserve(1000000); long long c = 0; for (int i = 0; i < SIZE;++i) c += m[i*i] += i; std::cout << c << std::endl; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それからコンパイルして実行しました：

 g++ -std=c++11 -O3 1.cpp -o 1 MacBook-Air-anikin:Downloads anikin$ time ./1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、次の結果を得ました：

 real 0m0.465s user 0m0.422s sys 0m0.032s
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これから何を学ぶことができますか？ 私の調査結果は次のとおりです。

1. 私はC / C ++が大好きです。
2. 私は古き良きMacBook Airが大好きです（実際、動作は遅くなりますが、それは別の話です）。
3. -O3
   
   
   
   最適化フラグを使用し-O3
   
   
   
   。 使用するのを恐れる人もいますが、無駄です。そうしないと、パフォーマンスが低下するからです。 これを実証するために、次のようなコマンドを実行しましょう。
   
   
   
   

    MacBook-Air-anikin:Downloads anikin$ g++ -std=c++11 1.cpp -o 1 MacBook-Air-anikin:Downloads anikin$ time ./1
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   そして、 -O3
   
   
   
   なしの結果-O3
   
   
   
   2倍悪いことを確認してください：
   
   
   
   

    real 0m0.883s user 0m0.835s sys 0m0.033s
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

4. ほとんどの場合、アプリケーションはユーザーモードで機能しました。 カーネルモードで費やされた短い時間は、おそらくハッシュテーブル用のページの事前割り当て（そして-O3
   
   
   
   、この時間を最適化しませんでした）、 mmapシステムコールの実行、および実行可能ファイルのダウンロードに費やされたと考えられます。
5. このアプリケーションは、約100万のキーをハッシュテーブルに挿入します。 ここで、単語とは、乗算i * i中のオーバーフローによって引き起こされる繰り返しのために、実際にはハッシュテーブルに100万未満のキーが存在する可能性があることを意味します。 したがって、新しいデータを挿入すると、既存のデータが更新されます。 ただし、ハッシュテーブルには正確に100万の操作があります。
6. アプリケーションは100万個のキーを挿入し、約0.5秒でシャットダウンします。 1秒あたり約200万回のキーと値のペアの挿入が生成されます。

後者の観察は特に興味深い。 std::unordered_map



で表されるRAMにキーと値のペア用のストレージエンジンが既にあり、そのような古き良きMacBook Airの1つのコアで毎秒200万回の操作を実行できると仮定できます。

 MacBook-Air-anikin:Downloads anikin$ uname -a Darwin MacBook-Air-anikin.local 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

整数のキーと値を使用したことに注意してください。 文字列を使用することはできましたが、割り当てとコピーがテスト結果に影響を与えたくないという理由だけで実行しませんでした。 文字列に対する別の引数： std::unordered_map<std::string, …>



場合、衝突の可能性が高くなり、パフォーマンスが低下します。



RAMのハッシュテーブルは、1つのコアで1秒あたり200万の操作を実行できることがわかりますが、RAMのDBMSについて話していたことを思い出します。 RAM内のDBMSとRAM内のハッシュテーブルの違いは何ですか？ DBMSはサーバーアプリケーションであり、ハッシュテーブルはライブラリです。 DBMSは、ハッシュテーブルとその他のものです。 そして、これには、少なくともサーバー自体のストラップが含まれます。



std::unordered_map<int, int>



基づいてサーバーアプリケーションを作成しましょう。 素朴なアプローチは次のようになります。

1. メインストリームの接続を受け入れます。
2. 受信した接続ごとに新しいスレッドを作成します（または事前作成されたスレッドのプールを開始します）。
3. 同期プリミティブ（ミューテックスなど）を使用して、 std::unordered_map
   
   
   
   を保護します。
4. データの安全性を忘れないでください-各更新操作をトランザクションログに記録します。

アプリケーションコードを書くことに飽き飽きしたくないので、すでにこれを行っていると想像してみましょう。 「接続ごとに個別のスレッド」（MySQL、MariaDB、Postgresなど）の原則に基づいて配置された任意のデータベースサーバーを使用します。1コアで最大で数万のクエリを実行できます（16または32で）核サーバーにとっては、1秒あたり100万回の操作になります）。 これはさまざまなベンチマークでよく知られています。 ネットワークで見つけることができた従来のDBMSの中で最高のパフォーマンスインジケーターは、1秒あたり約100万のリクエストであり、20コアのコンピューターで実行されるMariaDBに属します。 詳細な計算については、 こちらをご覧ください 。 簡単な計算により、コアあたり1秒あたり5万のリクエストを取得します。 おそらく世界最高のスペシャリストによって最適化された市場で最高のDBMSの1つは、1つのコアで1秒あたり50,000件の単純なクエリ（実際にはキー検索）のみを処理します。



50,000および200万std::unordered_map



と比較した場合、40倍の差があります。 どうですか？ データ構造にサーバーを追加して、他のアプリケーションにリモートアクセスできるようにしました。パフォーマンスが40倍低下しました。 （繰り返しますが、これは最も単純な操作のベンチマークであり、すべてがキャッシュ内にあり、DBMSは世界最高のスペシャリストによって調整され、最大スループットに設定されており、DBMSのオーバーヘッドを最小限に抑えています。）マルチレベルアーキテクチャを忘れて、すべてのビジネスロジックとDBMSロジックを1つのプロセス内の1つのアプリケーションに記述する方が適切です。 もちろん、これは冗談でした。 データベースサーバーを最適化することをお勧めします。



上記のアーキテクチャを備えたサーバーがトランザクションを処理するときに何が起こるかについてのシステムコールのプリズムを見てみましょう。

1. ネットワークからリクエストを読み取ります。
2. ハッシュテーブルロック。
3. ハッシュテーブルのロックを解除します。
4. トランザクションログに書き込みます。
5. ネットワークへの記録。

要求ごとに、少なくとも5つのDBMSへのシステムコールを受け取ります。 各呼び出しを行うには、カーネルモードを開始および終了する必要があります。



カーネルモードを開始および終了すると、モードが切り替わり、ある程度の作業が必要になります。 詳細は、たとえばここで読むことができます 。 さらに、モードの切り替えによりコンテキストの切り替えが発生し、コピーと遅延がさらに大きくなる可能性があります。 詳細については、 こちらをご覧ください 。



システムコールのすべての悪を示すために（私は正しい、私はシステムコールが大好きですが、遅いので悪用しないようにしています）、別のプログラムを作成しました（Cで）：

 #include <stdio.h> #include <fcntl.h> #include <unistd.h> int main() { int fd = open(“/dev/zero”, O_RDONLY); for (int i = 0; i < 1000000; ++i) { unsigned char c; if (read(fd, &c, 1) == -1) { fprintf(stderr, “error on read\n”); break; } } close(fd); return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このプログラムは、ファイル/dev/zero



から100万バイトの読み取りのみを生成し/dev/zero



。 テスト結果は次のとおりです。

 MacBook-Air-anikin:Downloads anikin$ time ./2 real 0m0.639s user 0m0.099s sys 0m0.495s
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まず、プログラムはほとんどすべての時間をカーネルモードで使用します。 次に、1秒間に約150万のシステムコールを行います。 ハッシュテーブルのパフォーマンスは1秒間に約200万回であったことを思い出してください。 奇妙なことに、 読み取りシステムコールはハッシュテーブルを検索するよりも30％遅くなります。 そして、これはこの呼び出しの単純さにもかかわらず、彼はディスクまたはネットワークにアクセスせず、単にゼロを返しました。



上記で書いたように、データベースサーバーを使用する場合、ハッシュテーブルには検索操作ごとに少なくとも5つのシステムコールがあります。 これは、システムコールの場合に少なくとも（5 * 1.3 =）6.5倍の時間が必要であることを意味します！ 状況を税務プレーンに転送すると、システムコールは85％の税金のようになります。 85％の給与税を歓迎しますか？ 獲得した100ルーブルのうち15ルーブルしか受け取らなかったら？ これについて考えた後、 読み取り 、 書き込み、およびその他のシステムコールに戻りましょう。 ネットワークバッファからの読み取り、Linuxカーネルでのメモリブロックの割り当て、内部カーネル構造の検索と変更など、さまざまなタスクを実行します。 したがって、85％以上の税金は実際には非常に少なく見えます。 要求を処理するときにMySQLまたはその他の従来のDBMSが呼び出すシステムの数を確認するには、Linuxでstraceユーティリティを使用できます。



したがって、システムコールは悪です。 それらを完全に放棄し、DBMSロジック全体をカーネルに転送することは可能ですか？ 良いように聞こえますが、難しいです。 おそらく、より実用的なソリューションがあります。 以下の例を見てください。

 #include <stdio.h> #include <fcntl.h> #include <unistd.h> int main() { int fd = open(“/dev/zero”, O_RDONLY); for (int i = 0; i < 1000; ++i) { unsigned char c[1000]; if (read(fd, &c, 1000) == -1) { fprintf(stderr, “error on read\n”); break; } } close(fd); return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果は次のとおりです。

 MacBook-Air-anikin:Downloads anikin$ time ./2 real 0m0.007s user 0m0.001s sys 0m0.002s
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このプログラムは以前のプログラムとまったく同じです- /dev/zero



ファイルから100万バイトをコピーします-ただし、実行時間はわずか7ミリ秒で、639ミリ秒の以前の結果よりほぼ100倍高速です！ これはどのように可能ですか？ 秘trickは、システムコールの数を減らし、それぞれが実行する作業量を増やすことです。 システムコールを適切に作業でロードすれば、システムコールはそれほど悪くないことがわかります。 通話に対して固定料金を支払うと、ほぼ無料で使用できます。 これは外国の遊園地に似ています：入場券に対して1回支払い-終日すべてのアトラクションを使用します。 まあ、または一日より少し少ない：チケットの価格は変わりませんが、別のアトラクションの点ではもう少し高価になります。



そのため、データベースサーバーの速度を上げるには、システムコールを減らし、各コール内でより多くの操作を実行する必要があります。 これを達成する方法は？ リクエストとその処理を組み合わせてみましょう：

1. 1回の読み取り呼び出しで、ネットワークから1000件のリクエストを読み取ります。
2. ハッシュテーブルをロックします。
3. 1000件のリクエストを処理します。
4. ハッシュテーブルのロックを解除します。
5. write / writevを1回呼び出すだけで、1000個のトランザクションをログに書き込み ます 。
6. 1回の書き込み呼び出しでネットワークに1000の応答を書き込みます。

いいね！ しかし、ちょっと待ってください、DBMSは通常、バッチでリクエストを処理しません（少なくとも明示的に尋ねられない場合）、オンラインで動作します：リクエストが到着するとすぐに、DBMSは最小限の遅延で即座にリクエストを処理します。 彼女は、1000件のリクエストが到着するのを待つことはできません。



この問題を解決するには？



公共交通機関を見てみましょう。 そこで、この問題は前世紀に解決されました（前年ではない場合）。 バスのスループットが高いため、バスのチケットはタクシーに乗るよりも安くなります。したがって、1人の乗客の旅行の価格は低くなります。 ただし、バス（または特定の都市に応じて地下鉄）の遅延（待機時間）は、忙しい中心部のタクシーの遅延とほぼ同じです（少なくとも、ニューヨーク、モスクワ、パリ、ベルリン、東京でこのパターンを観察しています）。 どのように機能しますか？



肝心なのは、100人がバス停に到着するまでバスが待機しないことです。 通常、バス停の乗客は常に十分です。なぜなら、中心部は街の忙しい部分だからです（読み込み：作業負荷が高い）。 したがって、1つのバスが停止し、乗客を乗せて（車室がいっぱいになるまで、または停留所に誰も残らなくなるまで）立ち去ります。 その後、次のバスが立ち上がり、再び十分な数の乗客を迎えます。最初のバスの出発から2番目のバスの到着までの間に、新しい人が停留所に現れたからです。 バスは満車を待ちません。 それは最小限の遅延で機能します：人がいます-それを取り、運転しました。



DBMSが同じように機能するためには、ネットワークサブシステム、トランザクションプロセッサ、およびディスクサブシステムを独立したバス（または、必要に応じて地下鉄列車）と見なす必要があります。 これらの各バスは、他の2つのバスに対して非同期に動作します。 そして、これらのバスはそれぞれ、バス停にいるのと同じ数の乗客を乗せます。 十分な乗客がいない場合-ええ、はい、高い固定料金のバスはほとんど空なので、プロセッサは非効率的に使用されます。 一方、それは何が問題なのですか？ 既存の負荷に完全に対応します。 プロセッサは、1秒あたり10,000リクエストと1秒あたり100万リクエストの両方で99％でロードできますが、どちらの場合もシステムコールの数が同じであるため、応答時間も同様に良好です。 また、このインジケータは、システムコールごとに転送されるバイト数よりも重要です。 プロセッサは常にロードされますが、驚くべきことに負荷の下でスケーリングし、実行される大容量と小容量の両方の負荷を均等に保持します。 システムコールで実行される操作の数が100回変化する場合でも、応答時間は実質的に変更されません。 この理由は、1つのシステムコールの非常に高い固定価格です。



これらすべてを最良の方法で実装する方法は？ 非同期的に。 Tarantool DBMSの例を考えてみましょう。

1. Tarantoolには3つのストリームがあります。ネットワークを操作するためのストリーム、トランザクションを処理するためのストリーム（ トランザクション処理の略語TXを使用しますが、PではなくXがある理由は聞かないでください）およびディスクを操作するためのストリームです。
2. ネットワークスレッドは、ネットワークから要求を読み取り（I / Oをブロックせずにネットワークバッファーから読み取ることができる量、1つの要求であるか、1000を超えるか）、TXに転送します。 また、彼はTXからの応答を受信して​​ネットワークに書き込み、パケットに含まれる応答の数に関係なく、これを1つのネットワークパケットで行います。
3. グループのTXストリームは、ネットワークで動作するためにストリームから受信したトランザクションをメモリ内で処理します。 メモリー内の1つのグループのトランザクションを処理すると、ディスクで作業するためにそれをストリームに転送します。 同時に、特定のグループにいくつのトランザクションがあるかに関係なく、グループは次々に転送されます。 電車を降りてバス停に向かう人だかりのようです。 接近するバスは、すべての乗客の停留所から1人の乗客まで乗車します。 誰かがバスの出発前に停車することができなかった場合、次のバスを待つ必要があります。 バスは1ミリ秒余分に待機しません。最後の乗客の後ろに誰もいない場合、彼は出発します。 グループを処理すると、ディスクを操作するためのストリームはそれをTXストリームに返し、トランザクションをコミットし、このグループに含まれるすべての要求をネットワークで操作するためのストリームに返します。

このようにして、Tarantoolのシステムコールの数を大幅に削減しました。 ここでは、システムがどのように動作し、単一のコアで毎秒100万のトランザクションに対処するかについて詳しく読むことができます。



以下の画像は、ワークフロー全体を概略的に示しています。









注意を払う価値がある主なことは、各スレッドが並行して実行され、残りの2つの作業に干渉しないことです。 並列処理が多く負荷が高いほど、要求ごとのシステムコールが少なくなり、システムが1秒あたりに処理できる要求が多くなります。



同時に、スレッドは他のスレッドを待機するのではなく、単に現在持っている作業を実行するだけなので、応答時間は十分にありますが、その間、作業の新しい部分が並行して準備されています。



RAM内のDBMSについての記事がさらに増えます。 お楽しみに！



記事の内容に関するすべての質問は、元のdanikinの著者、メールおよびクラウドサービスMail.Ru Groupのテクニカルディレクターに宛ててください。