Tarantool：負荷の高いプロジェクトのデータベースで100万ドルを節約する方法

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

今日、私たちがやったように、データベースに莫大なお金、例えば100万ドルを節約する方法をお話します。 そもそも、問題は、なぜファイルよりもデータベースを頻繁に使用するのかということです。



データベースは、ファイルよりも構造化されたリポジトリであり、ファイルにはない多くの機能を備えています。







そこでは、クエリを作成できます。トランザクション、インデックス、テーブル、安定した、多少信頼できるリポジトリがあります。 実際、データベースはファイルよりも便利です。





あなたがアプリケーションを持っていると想像してください、それはデータベースで動作します、それは読み取りのためにこれまでこのデータベースをロードします、すなわち 非常に多数のレコードではなく、多数の選択があります。







最終的に、データベースは過負荷になり、負荷を処理できなくなります。



そのような場合、彼らは通常何をしますか？ 別のサーバー。 これは複製です。 つまり、実際には、負荷を保持できる量のレプリカを正確に配布します。







レプリカの読み取りの全負荷を負担します。 したがって、マスターに残す記録の負荷。 この方式は、原則として、読み取りの負荷をほぼ無限にスケーリングできます。



その後、レコードに負荷がかかります。







また、レコードの負荷は、データベースがそれを保持できなくなると、ある程度の制限に達します。 この場合、レプリケーションは役立ちますか？ いや レプリケーション（マスタースレーブまたはマスターマスター）が何であれ、各レコードはすべてのサーバーを通過する必要があるため、レコードの負荷には役立ちません。 マスターマスターが存在する場合でも、クラスター全体に対してリクエストがいくつあるかを意味します。各サーバーにはまったく同じ量が送信されます。 あなたは何も勝ちません。



他にどんなアイデアがありますか？



シャーディング。







実際、シャーディングすることにより、レコードの負荷の問題を解決し、ほぼ無限にスケーリングできます。



シャーディングにはさまざまな方法があります。データベースにカットしたり、テーブルにカットしたり、1つのテーブル内でカットしたりできます。 百万通りの方法があります。 誰もが彼にとってより便利な方法を使用します。



実際、このようなデータベースの2次元クラスター、つまり 多数のシャードがあり、それぞれに複数のレプリカがあります。 シャード、レプリカを配布し、負荷を完全に変化させます。



しかし、あなたには問題があります。 次の問題はあなたの上司です。 彼はこれについて何が好きではないでしょうか？ すべてが機能し、すべてが断片化され、複製されているように見えますが、彼は何が好きではありませんか お金。 彼はすべてを気に入っていますが、サーバーを配信、配信、配信するために費用がかかり、料金を支払うことを除いて。



あなたは彼に言います：「あなたは理解していません、私はここに技術を持っています、私はシャーディング、複製を持っています...それは無限にスケーリングします-それは非常にクールなシステムです。」



彼は次のように語っています。「はい、はい、しかし私たちはお金を失っています。これが続けば、データベースサーバーを購入するお金がなくなるだけです。 閉じなければなりません。」



どうする？



実際、データベースの負荷は、いくつかのデータ項目が非常に、非常に頻繁に読み取られるように調整されることがよくあります-それらは「ホットデータ」と呼ばれます。



キャッシングは、問題を部分的に解決するものです。







レプリカの一部を削除して、上司を少し満足させることができます。 ところで、あなたは最高のレイテンシ、すなわち キャッシュはデータベースよりも高速であるため、リクエストはより高速に処理されます。



しかし...問題は何ですか？ 不整合の問題は、キャッシュの最大の問題の1つです。







これは、すぐに目に見える最初の問題です。



アプリケーションは、Memcachedなどのキャッシュに別々に書き込み、データベースに別々に書き込みます。 つまり キャッシュはベースのレプリカではなく、キャッシュは独立したエンティティです。 ここにキャッシュとベースの間に描かれた矢印があります。これは実際には仮想です。 それらの間に複製はありません。 すべてはアプリケーションレベルで行われます。 したがって、これはデータの不整合につながります。







ところで、書き込みキャッシュは最適化されず、キャッシュには何も保存できず、すべてがキャッシュを通過してデータベースに到達するため、シャーディングが残っています。 まあ、すぐにではなく、その横にありますが、それは飛びます。







これは、最初にデータベースに書き込み、次にキャッシュに書き込み、または最初にキャッシュに書き込み、次にデータベースに書き込みできることを示す図です。 どちらの場合も、矛盾が生じます。 参照：キャッシュにデータを書き込むと、アプリケーションは安全にクラッシュし、データベースに書き込む時間がなくなります。 アプリケーションが起動し、すでにキャッシュにあるがデータベースにはないデータを処理しますが、それについては誰も知りません。 キャッシュがリロードされる（そしていつかリロードされる）と、キャッシュが空のデータベースから古いデータを取得します。







奇妙なことに、逆の順序で書き込む場合-最初にデータベース、次にキャッシュに、まったく同じ問題があります：データベースに書き込み、アプリケーションがクラッシュし、古いデータがキャッシュにあり、すべてが古いデータで動作し、キャッシュがリブートし、データベースから新しいデータを引き出しました、そうであるように、別のコピーの上に加えられた変更に対応しない、不可欠ではないデータの別のブランチ...



つまり キャッシュには少なくとも2つの問題があります。データの整合性がなく、シャーディングが必要です。



他にどのようなキャッシュの問題がありますか？ 上司が怒った瞬間、どのようなキャッシュの問題を起こしましたか？ 問題はこれです。キャッシュはデータベースではありません。







キャッシュの前にデータベースがあり、リクエスト、トランザクションがあり、キャッシュからこれらのほとんどすべてが消え、アプリケーションはすでにキャッシュで動作しています。 インデックスとテーブルは残り、すべてのキャッシュにセカンダリインデックスがあるわけではなく、すべてのキャッシュにテーブルがあるわけではありませんが、何らかの方法でそれらをキーバリューでサポートできるため、これらのプロパティが満たされていると信じていますいや



次に、データの整合性の問題について説明します。 彼女とどうする？ キャッシュとデータベースの両方で全体的にデータを更新する方法は？ スマートキャッシュ。







スマートキャッシュとは何ですか？ 実際、多くの人がこれを実行している可能性が高いです。これは基本的に、データベース自体と通信するキャッシュです。 つまり これは独立したMemcachedデーモンではなく、内部のすべてをキャッシュし、データベース自体に書き込む独自のデーモンデーモンです。 アプリケーションはデータベースに書き込まず、キャッシュを介して完全に動作します。







これは、キャッシュが最初にデータベースに書き込み、次にそれ自体に書き込むため、非整合性の問題を解決します。 彼がデータベースに書き込みをしなかった場合、彼はエラーを出した-すべては問題ありません。 これは確かに良くありませんが、データは一貫しています。 キャッシュがデータベースに書き込まれた後、データがメモリに書き込まれるため、データがメモリに書き込まれることはほとんどないため、キャッシュは必ずデータ自体に書き込まれます。 むしろ、メモリがサーバー上で暴行し、その時点ですべてがクラッシュし、それでもキャッシュ全体が失われた場合に発生します。少なくともデータの整合性は失われません。



しかし、そのようなインテリジェントなキャッシュを使用しても、データが失われる場合があります。







アプリケーションはキャッシュに書き込み、キャッシュはデータベースに書き込み、データベースはこのエントリを内部的に適用し、キャッシュへの回答を与え、その瞬間にネットワークが切断されます。 キャッシュは、データベースへの書き込みが失敗したと判断し、それ自体にデータを書き込まず、ユーザーにエラーを与えます。 その後、キャッシュはその中にあるデータの処理を開始し、再起動後、データベースから古いデータを再び取得します。



これはまれなケースですが、それも起こります。 つまり スマートキャッシュは、データの整合性の問題を完全には解決しません。 そして、まだシャーディングが必要です。







シャーディングとは、同じサーバー上にあるデータベースがあり、それを単純に切断することです。 それを断片に切り分け、これらの断片を異なるサーバー、物理サーバーにスタックします。 これにより、記録の負荷が特定の部分に及ぶため、記録の負荷が軽減されます。 つまり 実際、すべてのCPU、たとえばすべてのサーバーがこの負荷の処理に関与しており、1つのサーバーのCPUだけではありません。



シャーディングはまだありますが、上司はシャーディングが好きではないことを覚えています。これは非常に高価であり、多数のサーバーがあり、誰もがレプリカを持っているためです。



そのため、残念ながら、データの非整合性はキャッシュに残り、シャーディングが必要であり、データベースプロパティはありません。



別の非常に厄介なキャッシュの問題は何ですか？ コールドスタート。







これは、キャッシュがゼロから、クリーンで、裸で、データなしで上昇する場合、非常に不快な問題です...完全に雪が散らかったマシンのように、それは役に立たない-あなたは最初にそれを取得する必要があり、またそれを取得する必要があります。 コールドスタートはキャッシュを完全に強制終了し、すべての要求は直接データベースに送信されます。







上司が承認しないアクションを実行する必要がありますが、何ができますか？ キャッシュをウォームアップするためだけにレプリカを配信する必要があります。 実際、このレプリカレイヤーは、レプリカ全体で配信する各シャードに対して、単にキャッシュをウォームアップするためのものです。 これらのサーバーを切断したり、キャッシュがウォームアップしたときに破棄したりすることはできません。これは、キャッシュを備えたサーバーが突然夜間に再起動するためです それでも同じように、すべてが夜間に機能し、これらのサーバーはすぐに負荷をかけてウォームキャッシュを提供する必要があります。 キャッシュはウォームアップされ、不要になりましたが、再びどこにも見つかりません。



4つのキャッシュの問題：







質問：キャッシュをウォームアップする方法は？ 意味をなすためには、キャッシュを常にウォームアップする必要があります。 データベースを介してウォームアップするのは、どういうわけか正確ではありません。レプリカが多数あり、それらすべてがウォームアップ、ウォームアップします。高価すぎるためです。



永続性は正しい言葉です。 キャッシュは冷やさない方が良いです。キャッシュは永続的である必要があります。キャッシュは、コールドスタートの問題を含むいくつかの問題を除いて、適切で迅速な解決策であるためです。 たとえば、シベリアでは、一部の人々は車を渋滞させないため、常に巻き上げられます。それ以外の場合は、ほぼ同じオペラから後で起動しません。



最も簡単なキャッシュ永続化方法は何ですか？







これは単なるデータのダンプです。 つまり、実際には、毎分、場合によっては1分、たとえば5分ごとに、キャッシュ全体をディスクに完全に、全体として直接ダンプします。 この決定はどうですか？ 一貫性が失われるため吸い込みます。 5分ごとにダンプすると、サーバーはそのまま上昇し、5分で変更が失われます。 データベースを介してそれらを加熱することはできず、これらの変更がどこから来たのかさえ明確ではありません。 そして、これが唯一の問題ではありません。







2番目の問題は、IOPSが悪いことです。 常にディスクをロードします。 ダンプ、ダンプ、そして再びダンプ、永続的。 必要なデータの一貫性が高いほど、ダンプする頻度が高くなります。 あまり快適ではない方法もあります。



キャッシュを保持する最良の方法は何ですか？



ログ 記録するだけです。







つまり なぜダンプする必要があるのか​​、ログを保持し、キャッシュの各変更がディスクに記録されるようにします。



遅いと思う場合（キャッシュは非常に高速で、そこにディスクが表示されると多少遅くなるという意見が常にあります）、実際、遅くはありません。 SSDではなく、最も一般的な回転する磁気ディスクでさえ、100 Mb / sの速度で書き込み、順次書き込みを行います。 トランザクションサイズがたとえば100バイトの場合、これは1秒あたり100万トランザクションです。 これは、このオーディエンスにいるほとんどすべての人、おそらく私をも満足させる驚くべきスピードです。 したがって、1つのディスクでもこのタスクに対処できますが、たとえば、10個の挿入があり、10個が同じデータを共有するため、すべてが崩壊するが、ログでは崩壊しないため、このログが非常に大きくなるという別の問題があります。 または、同じデータ項目の更新が100回ありますが、最後の更新のみが必要であり、すべてがログに保存されます。 この問題を解決するには？ ささやきます。







これら2つの方法を組み合わせる必要があります-ダンプとログを一緒に。 つまり 週に1回、または必要なときにダンプし、それ以外の時間はすべてログを書き込むだけです。 ダンプでは、最後に適用されたログエントリのID、またはこのスナップショットにまだある最後のログエントリのIDをまだ覚えています。 サーバーが再起動したら、ディスクからダンプを取得し、メモリに復元して、このレコードの後のログの一部をロールアップします。 すべて、キャッシュが復元され、すぐにウォームアップされます。



ところで、このウォームアップはデータベースからよりも高速です。 再起動中のこの種のウォームアップは、ファイルの線形読み取りであるため、ディスクに完全に入り込みます-100 Mb / s。 磁気ディスクでも、非常に高速です。



これですべて、コールドスタートの問題は解決されましたが、残念ながらこれは1つの問題にすぎません。 キャッシュは暖かいですが、さらに3つの問題があります。







最初の2つ、つまり不整合とシャーディングの問題を解決する方法について考えてみましょう。



キャッシュをデータベースとして使用するという考え方は正しい方向です。 実際、なぜこの場所にメインデータベースが必要なのでしょうか？ MySQLまたはOracle-なぜ必要なのですか？ 考え直してみましょう。



おそらく2つのことに必要です：

1. データベースはキャッシュとしてではなく、データを確実に保存すると信じています。 おそらく何らかの魔法があります。
2. データベースに複製があること。 キャッシュには通常、レプリケーションがありません。 したがって、サーバーのキャッシュは失敗するか、単に再起動し、ディスクからすべてを取り出すまではウォームアップよりも高速ですが、それでもダウンタイムは残ります。これも悪いことですが、そこには複製はありません。

最初のポイント-信頼できるストレージ。 見ると、データベースには何が保存されていますか？ データベースには、ホットデータとコールドデータが格納されます-これは基本的に格納されるすべてです。 通常、ホットデータは10〜10万RPSの小規模で非常に高温であり、コールドデータは非常に大きく低温であるため、コールはほとんどありません。







コールドデータは大きく、ホットデータは小さいことが常に判明しています。 これが生命の法則です。







実際、この小さなホットデータを処理するためだけに、多数のコピーでデータベースをレプリケートおよびシャーディングしています。残りのコールドデータに対するクエリが多数ないため、問題ありません。 しかし、ホットデータのためだけにこれらすべてを複製しています。



なぜこのコピーをすべて行うのですか？ おそらくホットデータのみをコピーできますか？







しかし、ここでも同じ問題があります。結局、負荷はホットデータに移るので、それらだけを複製して断片化すれば、問題はなくなりません。この巨大な負荷をすべて処理するには、まったく同じ数のサーバーが必要です。



そして、あなたはまだシャーディングを持っているので、あなたの上司はまだ怒っています。



実際、データベースにはデータが確実に保存されますが、キャッシュにはトランザクションログ（すべての変更が書き込まれるファイル）があるため、キャッシュにもデータが確実に保存されます。 これはトランザクションログに他なりません。データベースと同じです。データベースでの信頼できるストレージを確保するものであり、魔法はありません。キャッシュも同じです。



レプリケーションなし。 これはもちろん悪いことですが、なぜキャッシュをプライマリデータソースにできないのか考えてみましょう。 複製がないため？ はい、それを行います。



キャッシュをプライマリデータソースにできないのはなぜですか？ データベースのプロパティがないため？ これも行うことができ、これらすべてのデータベースプロパティをサポートでき、キャッシュがそれらを所有します。 「キャッシュはデータベースではありません」という画像を覚えていますか？







キャッシュはデータベースである可能性があります。 彼はこれらすべての特性を持つことができます。



キャッシュには、コールが多数あるホットデータのみを保持する必要があります。これは、ホットデータを提供するためだけにこれらのコールドデータをデータベース全体と一緒にシャーディングおよび複製するためです。 ただし、ホットデータをシャードするだけでは、ホットデータのリクエスト数に依存するため、問題は解決しません。つまり、キャッシュはデータベースになります。



実際、このデータベースにTarantoolという名前を付けました。







キャッシュであるホットデータ用の特別なデータベースを開発しましたが、永続性、トランザクション（アダルトデータベースと同じ）、レプリケーション、さらにストアドプロシージャも備えています。 つまり Tarantoolには、すべての基本的なデータベースプロパティがあります。 そのため、これをホットデータの主なソースとして使用します。 このデータはどこにも複製しません。 Tarantoolがあり、レプリカがあり、このデータは他のデータベースと同様にバックアップされますが、他のデータベースのどこにも複製されません。 これは常に永続性とデータベースプロパティを備えたホットキャッシュです。 彼はこれらすべての問題を解決します。







実際、シャーディングとレプリカを備えたこれらの数百台のサーバーすべてを今すぐに必要とするわけではありません。タスクを分割し、







適切なタスクに適切なツールを使用するだけです。 コールドデータはストレージに保存されます。 たとえば、コールドデータのためだけに数十年前に作成されたSQLストレージでは、データに対する1秒あたりのクエリ数がそれほど多くなかったため、誰も考えませんでした。 また、ホットデータは、Tarantoolのホットデータ用に特別に設計されたストレージに保存されます。







ここでは、原則として、すべてがスライドに書かれています-私たちが行ったパスですが、実際には、Tarantool全体の2つのインスタンスで十分です-1つのマスター、2つ目-レプリカ、データベースの場合、1つの例として、すべての負荷帯域を提供する可能性が高く、これは以前にSQLサーバーのクラスター全体に適用されていました。







ここに心理的なポイントが1つあります。居心地の良いデータベースの世界を、不快な新しいキャッシュの世界に残したくないのです。 トランザクションデータベースなど それから、上司が怒っているとき、あなたはキャッシュを配信し、どういうわけかすぐに不快になりました。 そして、タランツールだけがこの心地よさを返します。 さらに、彼は矛盾とコールドスタートの問題を解決します。 彼は、いわば、ホットデータのデータベースの世界に戻ってきます。



現在、このケースはMail.ruにあります。







ケースは次のとおりです。ユーザープロファイルを保存する必要がありました。 ユーザープロファイルは、ユーザーごとに500バイトから1 KBまでの非常に小さな情報です。 このために最初にMySQLの使用を開始しました。 そして、MySQLからファームへの読み取りと書き込みのために、以前のリポジトリにあったプロファイルの負荷全体を複製し始めました。 16個のMySQLのファームをセットアップし、事前にいじって負荷をかけました。 そして、すべての負荷の1/8であるこれら16台のサーバーが棚にぶつかったことが判明しました。 , .







, , , – 16 1/8 , .. , 128 MySQL . , – 1 . . Tarantool . , . , . . 4, , + , . .



, – 60 , . , .







120 Tarantool, Tarantool, , . MySQL SQL, , , .



: , , .. , Tarantool, . 1 . .







Summary , . , , , , -… , , , , – MySQL, – Tarantool, 1 . , , , .

連絡先

» anikin@corp.mail.ru

» danikin

» Mail.ru

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



" Tarantool ? ". :) — « , !» :) , !



HighLoad++ Tarantool . () , , .



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