データベースは何に使用されますか、古き良きファイルはありますか？ なぜそれらはデータベースよりも悪いのですか、データベースはファイルよりも優れているのですか？ DBはより構造化されたストレージです。 トランザクション、リクエストなどを行うことができます。 最も単純なケース：データベースを備えたサーバーと、サーバーにリクエストを送信するいくつかのアプリケーションがあります。 データベースは応答し、データベース内の何かを変更します。データベースへの負荷が大きくなり、データベースが対処しなくなるまで、すべてが正常です。



これが読み取りロードのみであると仮定すると、問題はレプリケーションによって解決されます。 必要な数のレプリカをデータベースに配置し、レプリカのすべての読み取りとマスターのすべてのレコードを開始できます。 データベースに書き込み負荷がある場合、すべてのレプリカで記録を実行する必要があるため、レプリケーションはこの問題を解決しません。 したがって、どれだけ配置しても、1台のマシンあたりの記録の負荷は軽減されません。 ここで、シャーディングが助けになります。



データベースがレコードの負荷を保持していない場合、シャードを無限に追加できます。 シャードはレプリカよりも複雑です。これは、テーブル間またはテーブル内で、ハッシュ、範囲ごとに何らかの方法でデータを分散する必要があるためです-多くの異なるオプションがあります。 したがって、レプリカとシャードを追加すると、データベースの負荷を共有できます。 望むことはこれ以上ないように思われます。

しかし、問題があります

...これはもはや技術の面にありません。 増え続けるサーバーの群れを見ているあなたの上司は、多くのお金がかかるのでinし始めます。 負荷が増大し、ユーザーからのリクエストの数が増大しているため、サーバーを追加および追加します。 あなたは技術者です、お金については考えないでください-投資家にそれをさせてください。 そして、上司に次のように伝えます。 無限にスケーラブルなシステムがあります。 サーバーを追加していますが、すべてが正常に機能します。」 そして上司は次のように答えています。 これで何かする必要があります。 そして、問題を解決しない場合、ビジネス全体を閉鎖する必要があります。 なぜなら、ビジネスの成長にもかかわらず、私たちはデータベースとサーバーでより速い速度で成長しているからです。」 そして、この問題を解決するのは投資家ではなくあなた次第です。なぜなら、それはおそらく技術面にあるからです。 次に何をする？ Amazonははるかに高価です。 最適化？ すべてのクエリはすでに最適化されています。



解決策は、多くの場合選択されるデータをキャッシュすることです。 多数のレプリカやシャードに頼らずに、キャッシュに保存してそこから継続的に戻すことができます。

キャッシュの問題

さて、問題は解決されました。1つのmemcachedが、レプリカサーバーのラック全体に置き換えられます。 しかし、あなたはすべてにお金を払わなければなりません。

1. アプリケーションは、キャッシュとデータベースの両方に書き込みますが、それらは相互に複製されません。 したがって、データの不整合が発生します。 たとえば、最初にキャッシュに書き込み、次にデータベースに書き込みます。 何らかの理由で、データベースへの書き込みが機能しませんでした。アプリケーションがクラッシュし、ネットワークが点滅しました。 その後、アプリケーションはユーザーにエラーを返しましたが、他のデータはすでにキャッシュにあります。 つまり、キャッシュにはいくつかのデータがあり、データベースには他のデータがあります。 これについては誰も知らないので、アプリケーションは引き続きキャッシュを操作します。 また、再起動すると、別のコピーがデータベースにあるため、データが失われます。
   
   
   
   面白いことは、逆の順序で書くと同じことが起こるということです。 データベースに記録しましたが、キャッシュへの書き込みに失敗しました。 キャッシュの古いデータを処理します。データベースには新しいデータがありますが、誰もそれを知りません。 キャッシュがリブートしました-データは再び失われます。 つまり、どちらの場合も、更新は失われます。 これは、データベースの特定のプロパティ、つまり記録されたデータがデータベースに永久に保存されること、つまりコミットがコミットされなくなるという保証を失うことを意味します。 アプリケーションがそれだけで動作するようにスマートキャッシュを記述することにより、データの不一致に対処できます。 アプリケーションがデータベースで動作しない場合のみ、ライトスルーできます。 まず、キャッシュは受信したデータをデータベースに書き込み、次にそれ自体に書き込む必要があります。 何らかの理由でデータがデータベースに書き込まれなかった場合は、キャッシュにも書き込まないでください。 これにより、データは常に同期されます。 キャッシュはメモリであり、メモリが破損した場合を除き、メモリへの書き込みは常に通過するため、データはキャッシュに書き込む必要がありますが、この場合もスマートキャッシュは「フォール」し、キャッシュされたすべてのデータを忘却に陥れます。ただし、データが同期しなくなることはありません。
   
   
   
   ただし、データが同期しないというまれなケースが1つ残っています。アプリケーションがキャッシュに書き込み、キャッシュがデータベースに書き込み、データベース自体がコミットされます。 さらに、操作が正常に完了したことをキャッシュに確認しますが、現時点ではネットワークが切断され、キャッシュはこの確認を受け取りません。 彼は、データがデータベースに書き込まれていないと考えており、自宅では適用しません。 しかし、データベースではそれらはまだ適用されます。 アプリケーションは古いデータで動作し、その後キャッシュがリロードされます-データは再び異なります。 これは非常にまれなケースですが、可能です。
   
   
   
   そして最も重要なこと-スマートキャッシュはシャーディングの問題を解決しません。 また、上司はシャーディングが好きではありません。なぜなら、非常に高価だからです。多くのサーバーを購入する必要があるからです。
2. とりわけ、キャッシュの実装は、記録が加速されないため、シャーディングから私たちを救いません。 各コミットは、キャッシュではなく、どこかでコミットする必要があります。
3. 次の問題：キャッシュはデータベースではなく、通常のキー/値ストレージです。 リクエストとトランザクションは失われます。 インデックスとテーブルも失われますが、キーと値のキャッシュの上に半分の罪で構築できます。 したがって、アプリケーションを簡素化し、根本的にやり直す必要があります。
4. 4番目の問題はコールドスタートです。 キャッシュが上昇すると、空になり、データがなくなります。 さらに、すべての選択はデータベースに直接移動し、キャッシュを通過します。これはまだ何もないためです。 したがって、少なくとも完全ではなく、レプリカを再度追加する必要があります。 キャッシュを何らかの方法でウォームアップする必要があります。 そして、ウォームアップすると、多くの選択がベースに行きます。 したがって、キャッシュをウォームアップするためだけに多数のレプリカを保持する必要があります。 それは十分に無駄に見えませんか？ ただし、これらのレプリカがないと、正常に起動できません。 この問題の解決策をより詳細に検討してみましょう。

コールドスタート

当時、次のアイデアが生まれました。データは常に「暖かく」、「冷やす」必要はないということです。 これを行うには、キャッシュを永続化する必要があります。つまり、データをディスクのどこかに保存する必要があります。そうすれば、すべてが正常になります。 キャッシュが開始され、データがロードされます。 しかし、疑いがありました。キャッシュはRAMであり、高速である必要があります。また、ディスクがカップルでキャッシュに与えられると、データベースほど遅くなりませんか？ 実際、そうではありません。







最も簡単な方法は、N分ごとにキャッシュを「保持」し、ディスクに完全にダンプすることです。 このダンプは、バックグラウンドで非同期的に実行できます。 操作を遅くしたり、プロセッサーをロードしたりしません。 これにより、ウォームアップを何度も高速化できます。キャッシュが上昇すると、既に独自のデータダンプが手元にあり、それらを線形かつ非常に迅速に読み取ります。 これは、任意の数のデータベースレプリカを使用する場合よりも高速です。 しかし、そう簡単ではありませんよね？ 5分ごとにダンプするとします。 また、ギャップに障害がある場合、前のダンプの時点から蓄積された変更は失われます。 一部のアプリケーションでは、これは統計などでは重要ではありませんが、一部のアプリケーションでは重要です。



2番目の問題は、ディスクを適切にロードすることです。これは、ログなどの他の何かに必要になる場合があります。 ダンプ中、ディスクの速度が低下し、これが無限に発生します。 これは、通常のダンプダンプの代わりにログを保持すれば回避できます。 問題はすぐに発生するはずです。「どうして？ キャッシュであり、高速であり、すべてをここに記録しています。」 これは実際には問題ではありません。 通常のハードドライブでファイルにログを順番に書き込む場合、書き込み速度は100 Mb / sに達します。 100バイトの平均トランザクションサイズが1秒あたり100万トランザクションであるとします。 明らかに、キャッシュのログを記録するときにディスクのパフォーマンスが低下することはありません。 これにより、IOPSの問題も解決されます。すべてのデータが永続的になるように、必要なだけディスクをロードします。 データは常に最新であり、失われることはありませんが、ウォームアップは高速です。



しかし、ジャーナリングには欠点があります。 ログを維持する場合、同じアイテムを更新する更新は1つのレコードにグループ化されません。 それらは多くあり、キャッシュを開始するときは、これらすべてのレコードを「再生」する必要があります。これは、ダンプから開始するよりも時間がかかる場合があります。 さらに、ログ自体は多くのスペースを占有し、ディスクに収まらない場合もあります。



問題を解決するには、ダンプダンプとロギングの両方のアプローチを組み合わせることができます。 どうして？ ダンプ、つまり、1日に1回スナップショットを作成し、同時に常にログに書き込むことができます。 スナップショットでは、最後の変更のIDを保存します。 キャッシュを開始する必要がある場合、スナップショットを読み取り、すぐにメモリに適用し、スナップショットの最後の変更からログを読み取り、スナップショットの上に適用します。 それだけです、キャッシュは暖かいです。 これは、ダンプから読み取るのと同じ速さで実行されます。 それで、コールドスタートで、リストの残りの問題を解決しましょう。

残りの3つの問題

データベースには、トランザクションを通じて提供される永続性などのプロパティがあります。 通常、データベースにはホットデータとコールドデータが格納されます。 少なくともキャッシュに到達すると、データは確実にホットとコールドに分割されます。 通常、多くのコールドデータがあり、ホットデータはほとんどありません。 これが人生の配置です。 ホットデータを提供するためだけに、多数のコピーとシャードを使用してデータベースを複製およびシャーディングします。 私たちは自分自身に言うことができます：「なぜ私たちはこれをすべてコピーするのですか？ ホットデータのみをシャードしましょう。」 ただし、まったく同じ数のサーバーを使用する必要があるため、これは何の役にも立ちません。なぜなら、データがメモリまたはディスクに収まらないためではなく、CPUに遭遇するためです。 つまり、データベースには処理する時間がありません。 したがって、ホットデータのシャーディングとレプリケーションだけでは、この問題を解決できません。 そして、あなたはすべての新しいサーバーにお金を払わなければならないので、ボスはまだ怒っています。



何ができますか？ キャッシュはありますが、データベース内のホットデータでは平和に生きることができず、レプリカとシャードを配信します。 ただし、データベースと同様に、キャッシュにもデータが格納されます。 必要に応じて、複製を作成できます。 キャッシュをプライマリデータソースとして使用できない理由は何ですか？ トランザクションのような機能の欠如？ 取引ができます。 したがって、残りの3つの問題を解決します。これは、ホットデータをデータベースにまったく保存できず、キャッシュにのみ保存できるためです。 データベースを多くのサーバーに分割する必要がないため、キャッシュは書き込みを含む負荷にうまく対処するため、シャーディングも不要になります。 キャッシュはジャーナルなしで書き込むのと同じ速さでジャーナルに書き込むため、彼はなんとか書きます。



そのため、キャッシュには、データベースに固有のすべてのプロパティを埋め込むことができます。 私たちはそうしました、そして結果として生まれた子供はTarantoolと呼ばれました 。 読み取りおよび書き込み速度の点では、キャッシュに匹敵しますが、必要なすべてのデータベースプロパティを備えています。 したがって、ホットデータを保存するためのベースを放棄できます。 すべての問題が解決されました。

Tarantoolの機能と機能

したがって、小さなホットデータを処理するためにのみ、これらの多数のコールドデータを複製および分割しました。 これで、めったに要求および変更されないコールドデータがSQLに格納され、ホットデータがTarantoolに送信されます。 つまり、Tarantoolはホットデータのベースです。 その結果、ほとんどのタスクでは2つのインスタンス（マスターとレプリカ）で十分です。 1つでも問題ありませんが、データベースであるにもかかわらず、それとRPSへのアクセスのパターンは通常のキャッシュのパターンと同じであるためです。 一部の人にとって、これは心理的な問題です。トランザクションに対応した居心地の良い耐久性のあるデータストレージの信頼できるソースとしてデータベースを放棄し、キャッシュに移動するにはどうすればよいでしょうか。 実際、memcachedまたはその他のキャッシュの使用を開始した時点で、データベースの利点はすでに放棄されています。 一貫性の欠如と更新の損失を考えてください。 そして、この観点から、Tarantoolは作業を高速化してお金を節約できるだけでなく、トランザクション、クエリ、インデックスなどを備えたデータベースの世界にあなたを連れ戻します。



トランザクションの並列操作に関するいくつかの言葉。 LuaをTarantoolで使用する場合、それは単一のトランザクションと見なされます。すべての読み取りをメモリから読み取り、すべての書き込みを一時バッファーに転送し、最後にディスクに書き込みます。 また、データの書き込み中に、別のトランザクションがロックなしでメモリから古いコミットされていないデータを既に読み取ることができます！ トランザクションのキューは、ディスクへの順次書き込みのスループットを超えた場合にのみ発生します。

暑いから寒いへの移行方法

このプロセスはまだ自動化されていません。 ログを分析し、そのようなパターンのデータはホットとみなすことができると判断します。 たとえば、ユーザープロファイルはホットです。つまり、ユーザープロファイルをTarantoolに転送しています。 たとえば、一部のユーザーはもはや郵便局に行かないため、冷たいものもキャッチすることは明らかです。 しかし、過剰な支出にもかかわらず、これはMySQLを使用するよりも効率的です。 Tarantoolのメモリフットプリントが非常に最適化されているためだけに。 非常に興味深い事実：SQLデータベースはすべてをディスクに保存しますが、10〜20％をメモリにキャッシュする必要があります。 しかし同時に、従来のSQLフットプリントデータベースはTarantoolよりも3〜5倍悪いため、これらの20％は100％に変わります。 同様の負荷では、SQLサーバーはこの負荷を保持しませんが、メモリで勝つことさえありません。

タランツールvsレディス

私たちの観点から見ると、TarantoolとRedisには2つの重要な違いがあります。

1. テストによると、Tarantoolはパーセントより30％高速です。 テスト結果は、Tarantool Webサイトおよびこの記事に記載されています 。
2. Tarantoolはデータベースです。 そこで、Luaでサーバー側スクリプトを作成できます。 RedisにもLuaがありますが、シングルスレッドのブロッキングであり、独自のスクリプトを作成できますが、そのスコープは非常に限られています。 さらに、RedisのLuaはトランザクションではありません。 この意味で、Tarantoolは完璧です。 より高速で、必要な場所でトランザクションを使用できます。 キャッシュからキーを取得し、更新して、並行して他の誰かが変更できる場合に戻す必要はありません。

100万ドル

この金額は魅力的な見出しの発明ではありませんが、Mail.Ru Groupプロジェクトの1つで節約されたお金です。 ユーザープロファイルをどこかに保存する必要がありました。 それ以前は、彼らは古い倉庫にいて、私たちはそれらをどこに移すかを考えていました。 私たちはもともとMySQLを見ました。 16個のMySQLレプリカとシャードをデプロイし、それらの読み込みおよび書き込みプロファイルからの負荷を徐々に複製し始めました。 プロファイルとは、各ページで通常必要な名前、送信された文字数、さまざまなフラグおよびサービスデータを格納する小さな情報（500バイトからキロバイト）です。 このデータは、多くの場合、要求および更新されます。 負荷の1/8で、16個のMySQLのファームが壊れました。 そして、これはそこで行ったすべての最適化の後です。 その後、タランツールを試すことにしました。 彼は以前は128台のサーバーに分散していた4台のサーバーに冷静に負荷をかけていました。 実際、1台のサーバーを維持していても、安全のために4台設置しました。 また、128台のサーバーの形で節約し、ホスティングコストを削減することは、100万ドルに相当します。



そして、これはほんの一例です。 Tarantoolは、多くのプロジェクトで用途を見出しています。 たとえば、Mail and Cloudには120のTarantoolインスタンスがあります。 MySQLを既存の負荷レベルで使用した場合、数万台のサーバーまたはその他のSQL（PostgreSQL、Oracleなど）をインストールする必要があります。 それが何百万ドルになるかを見積もることさえ難しい。 このf話の教訓は、適切なツールを選択する必要があるタスクごとに、単純な機能で多くのお金を節約できることです。 コールドデータは、これを目的としたSQLデータベースに格納する必要があり、ホットデータ（多くの場合、クエリおよび更新される）は、これに適合したストレージ（Tarantool）に格納する必要があります。



現在開発中のバージョン1.7では、RAFTのようなシャーディングとレプリケーションを使用した完全自動クラスターソリューションを作成したいと考えています。 お楽しみに ！