インメモリNoSQLデータベースを賢く選択する方法。 パフォーマンスのテスト

ドミトリー・カルギン・バラショフ（ Mail.RU ）

In-Memory NoSQLデータベースに関するレポートがあります。 In-Memory NoSQLデータベースとは誰のことですか？ 手を上げてください...恥ずかしくないですか？ データベースホール、そしてそれを知っているのは半分だけです。



人気を重視してデータベースを選択する場合、これは必要ありません。 一般的なデータベースの選択方法は？









最初のオプションは人気です。 これは歴史的に起こりました、つまり あなたは仕事に来て、そこにそのようなデータベースがあり、それを選択しなかった、例えば、あなたはそれを変更したいだけだ。



2番目のオプション-友人が私に助言した。 このオプションも非常に人気があります。



3番目のオプション-信じられている広告。 これは人気にも関連しています。「ああ、Redisはクールなデータベースです。使ってみましょう」という記事を読んでいます。



そして今、私は質問があります：あなたの何人があなた自身をエンジニアだと思いますか？ つまり あなたは大学を卒業し、工学の学位を取得しています。 データベースを選択するには、工学的アプローチを使用することをお勧めします。 テストすることをお勧めします。 独立して。 インターネットはすでにデータベーステストでいっぱいであることに私は合理的に反対することができ、人々がどのようにテストしたかを見ることができます。 すべてを特定の状況に非常に依存していることがわかるので、これも行う必要はありません。 つまり データベースがどのようにテストされ、自宅で実行され、その人が持っていたものを取得できないことがわかります。 つまり 負荷、マシン、仮想または非仮想、環境でテストする必要があります。 したがって、私のレポート全体は、データベースの選択に対する工学的アプローチに関するものです。



見て、この小さな男はあなたです。 あなたは自分をエンジニアだと考えています。 つまり この小さな男はクールです。







そして、誰もが彼を選択するので、エンジニアではなく、広告に導かれた可能性があり、友人を信じているか、単にRedisを選択した小さな男がいます。 だから、私たちは彼と邪魔にならない。 そして、グリーンマンを選択し、エンジニアとして行動します。



ここで問題は、何をテストするのかということです。 何をテストできると思いますか？ どのくらいのデータを保持できますか？



見て、2つのパラメーター-スループットとレイテンシーがあります。







これらのパラメーターの違いを理解している人は、手を挙げてください。 オーディエンスの約10％。 次に説明します。 誰がそのような店に行ったことがありますか？







喫煙者はいますか？ たばこはどこに行きますか？ もっと近いでしょう？ そのため、このストアは特別で、待ち時間が非常に短いです。 レイテンシーは、たとえば決定を下してから実際にどのようにタバコを手に入れたかの間など、タバコに行くときに予想される時間です。 つまり あなたはそれらを買う必要があることに気づき、庭に行き、店に入って、それを取って、レジに行って、買って、戻ってきました。 15分が経過しました。 これが待ち時間です。



スループットはすでに店舗のパラメーターです。つまり、単位時間あたりにどれだけの人が見逃すことができるかです。 つまり この店には通常、たくさんの人がいる1人のレジがあり、2分で1人が通ります。







つまり 十分に遅い。 一方で、私たちにとっては非常に高速ですが、私たちのような人がたくさんいると、店はdrれ、長い行列ができて、何も良いことはありません。 このストアをオーバーロードすると、全員が並んでいる必要があるため、レイテンシも増加します。



別の側面、月の向こう側があります。 次のようになります。







オーシャンにいたのは誰ですか？ すべてがあった。 素晴らしい。 それがどのように機能するかを見ましたか？ 多くの現金デスクがあります。 そして、同時に並行して動作します。







したがって、ある瞬間に、オーシャンはより多くの人々を自分自身に通します。 しかし、Auchanで何かを購入したい場合は、まず車に乗り、MKADの外のどこかで運転し、駐車し、降りて、カートに乗って、そこで2時間過ごし、購入して帰宅する必要があります。 つまり 待ち時間は非常に長くなりますが、このストアでのスループットは小さくなります。



データベースについて話している場合、誰もがスループットとレイテンシーを理解していますか？ 予想されるクエリ実行時間は待ち時間であり、スループットは1秒あたりに処理できるリクエスト数です。



また、テストする必要があるもう1つのパラメーターは、メモリフットプリントです。







「フットプリント」がどのように英語から翻訳されているか知っていますか？ フットプリント。 だからここに。







特に朝、彼は眠っている間に妻の足を一周し、署名しました。これは記憶の足跡です。 これは何？ ギガバイトのクリーンなデータをデータベースに入れて、プログラムがDBMSでどれだけ処理するかを確認すると、ギガバイトではなく、それ以上になります。 さらに多く-これはメモリフットプリントの価値です。 何度でも「で」、つまり さらに1バイトに費やすバイト数。 これは、購入する必要のあるRAMの量を決定するため、重要なパラメーターです。 つまり これはそのような通貨パラメーターです。



そして、どのようにデータベースをテストしますか？ YCSBユーティリティが利用可能-Yahoo! クラウドサービングベンチマーク。 このリンクにはクローンがあります：







これは私のgithubリポジトリです。いくつかの変更がありますが、それらについて説明します。



なぜこのユーティリティを使用する必要があるのですか？

1. まず、業界標準であり、誰もがそれを信頼しています。 通常、NoSQLデータベースをテストします。
2. さらに、負荷プロファイルの作成は非常に簡単です。 何らかの種類の非標準プロファイルがある場合は、構成を簡単に記述して、
   
   テストする。
3. 他のデータベース用のドライバを書くのは簡単で、そこには多くの標準的なドライバがありますが、非標準のものがあれば、自分で書くことができます。

使ってみませんか？ 私は1つの大きな理由を見つけました：







Javaを愛する人は、おそらくそのマイナス面のすべてを最もよく知っているでしょう。 彼女は多くのリソースを費やしています。 そして、ちょうど、コスティアはお金について話していました、私のお金を食べたのはJavaでした。なぜなら、テスターマシンはより強力に注文する必要があったからです...私はそれが少し必要だと思っていましたが、Javaはメモリに収まりません、そしてCPUには多くのコアが必要です。 テストするのにもっと高価なマシンが必要だったので、書き留めました。 しかし、これは私の個人的なものではなく、多分あなたは億万長者であり、Javaはこの問題であなたを傷つけません。



このYCSBには標準のワークロードがあります。 ワークロードは負荷プロファイルです。 彼らは何ですか？ 6つの標準タイプがあります。







Aは、読み取り要求の50％、書き込み要求の50％です。 シンプルなワークロード。



Bは読み取りで95％、更新で5％、書き込みで5％です。



Cは100％読み取り専用です。



それからもっと面白いものが来ます。



Dは読み取りで95％、挿入で5％ですが、1つの特異性があります-最近挿入されたもののみを読み取ります。 これは、たとえば、VKでニュースを書いて、書いて、送る-これは挿入です。 5％挿入。 そして、あなたの友人、あなたは彼らのトンを持っています、彼らは読み始めます、F5からかい、そして負荷はこのように作成されます。 つまり このようなプロファイルは、ニュースフィードのようなものです。



プロファイルEは、ヘビースキャンタイプのクエリです。 これは範囲要求です。 5％の挿入と95％のスキャン。 つまり これは、近くにないデータのヒープで何らかの検索を行う場合です。



最後の1つは、興味深いワークロードでもあります。 裸の読み取りの50％、およびそのような構成の50％があります。最初に読み取り、次に変更してから書き込みです。 つまり いくつかの部分を読んで、それを変更して、書き留めました。 かなり頻繁に、そのような組み合わせ。



任意のレイヤーを非常に簡単に書くことができます。 非常に単純な構成があります-5行で、パーセンテージと影響の方法を単純に記述します。たとえば、挿入の場合、最新のデータを選択します-これはワークロードD用です。



ドライバーの書き方は？ memcachedドライバーがなかったからです。 一般に、データベース用の多くのmemcachedは考慮しないことを理解しています。 何してるの？







このようなjavaクラスがあり、それを継承できます。 これらを実現します。 5つの方法があります。 ただ売るだけです。 たとえば、一部のワークロードがメソッドを暗示していない場合、たとえばdeleteメソッドを使用したワークロードがなかった場合、それを実装することすらできません。



そのようなグラフを作成します。







水平方向のスレッド数があり、対数的にポイントを示します-8スレッド、16、32など、最大1024。そして垂直方向-スループットグラフ-1秒あたりのリクエスト数。 これは、弱い、弱い仮想マシンです。 これはTarantoolデータベースです。 これはワークロードAです。



どのようにテストしますか？







遅延に対するネットワークの影響を排除するために、テスターとデータベースを搭載したマシンが同じデータセンター内にできるだけ近くに配置されることが非常に重要です。



1台のマシンでテストできないのはなぜですか？ 私はテストしました。 これは、同じマシン上の同じTarantoolです。 緑の車は1台の車にあり、赤の車は2台の車にあります。 それは別々であり、一緒です。







このこぶを見てみましょう。 これまでのところ、8、16、32スレッドがあり、1台のマシンで実際にスループットが高くなっていますが、2つのフローがさらに表示されると、テスター自体がデータベースとリソースを奪い合い、リソースを奪い始め、フォールバックします。



ただし、待ち時間があると状況は異なります。







遅延が消費される何らかの種類のネットワークがあるため、分離した場合の遅延は低くなります。 このような距離があります。 一緒にテストすると、遅延が改善されます。



もちろん、実際の話は個別のテストです。







さらに、すべてのテストは非常に脆弱な仮想マシンで行われ、非常にリソースに制約がありました。 専用サーバーがある場合、曲線の形状は保持されますが、距離は非常に長くなります。







それは、Azureで最も小さく、1対のコアを備えた、またはほぼ最小のAzureでした。







WALとは何ですか？ これは永続化ツールである先書きログです。 どのように機能しますか？ データベースに何かを追加します。これはトランザクションログです。データベースで行ったことを最後に書き込みます。 すべての変更。 何らかの理由で電源を切って再起動し、最初にそれを読み取り（このログに沿って）、すべてのコマンドを読み取り、この死後の状態を復元します。



WALでは、動作が異なります。 これらのすべてのテストにはWALがありませんでした。 WALでどのように機能するか、違いを示します。







参照してください、緑はWALと一緒です。 違いがあります。 これはWALなしで、これはWALありです。 そしてそこにある。 なぜ違いがあるのですか？ これはワークロードAであり、50％の読み取り、50％の更新を意味します。



読み取りによってレイテンシーを取る場合、何が起こるかを見てください：







違いはありません。 つまり WALは読み取りにまったく影響しません。 どうなったの？



そして、更新を行うと、違いがあります。







ディスクに書き込む必要があるため、もちろん、これにより全体が遅くなります。







仮想マシンも異なります。 つまり なぜインターネットから準備ができたテスト結果を取得できないのですか？ これらは2つの仮想マシンです。







これはDigitalOcean、これはAzureです。 ご覧のとおり、それらは非常に異なった働きをします。



そして今-私たちは一般的にどのようにデータベースを選択しますか？ 工学的アプローチについて話している場合、いくつかの段階があります。 最初の段階-何とか定性的に選択します。



私は4つのデータベースを取りました。 最初は大根です。







そして、私は自分のプロジェクトにとって重要なもの、いくつかの定性的価値、つまり 思い浮かぶのは、マインドマップを描くことです。 Redisには何がありますか？ 追加のみのファイルがあります-これはWALです、つまり 何らかの永続性を保存できます。 他に何がありますか？ 彼は、プロジェクトにとって重要なもの、例えば発展したコミュニティを持っています。 これが私にとって重要である場合、私はそれを自分自身に書きます。 Redisにとって他に良いことは何ですか？ 彼はテキストプロトコルを持っていますが、これは良くありません。 マイナスとして書き出されます。 通常、テキストプロトコルはバイナリプロトコルよりも低速です。 これは、memcachedの例で明確に見られます。memcachedの例では、このようなプロトコルがあり、バイナリが高速です。 そして、ストアドプロシージャを使用してビジネスロジックに記述することが多いストアドプロシージャがあります。







タランツール。 一般的に誰がTarantoolを使用しますか？ ホールで少し。 まず、Tarantoolはドキュメント指向のデータベースなので、とてもリアルです。 その主な競争相手は重要な価値です。 第二に、木製のインデックスがあります（または、木材ですか？Bツリー、バイナリツリー-これは、一般に、これはそのような専門用語です）。 タランツールにはまだWALがあります。 永続性を持つことができます。 スナップショットもあります。 Luaにはストアドプロシージャがあり、比較することもできます。 ここではテストを行いませんが、同じRedisと比較でき、非常に興味深い結果が得られます。 もう1つは私だけのものでした、あなたにとってはそうではありませんが、タランツールはMail.ruで私たちに作られました、そして質問があれば（つまり、これはコミュニティと同じです） Redis）、ここで私はKostya Osipovに来て、「これは何ですか？」 したがって、私は自分自身にプラスとして書いた。 特に破線。







次に、memcached。 ウサギがどこから来たのか知っていますか？ Memcachedのメインページにはそのような野ウサギがいます。 Memcachedは、前の2つとは異なり、すべてのコアをロードします。バイナリプロトコルがあります。 古い方法ではテキストを使用しますが、バイナリもあり、高速です。 また、彼には執着がありません。私たちが倒れたら、私たち全員が負けました。 つまり キャッシュを別のものとして使用できますが、使用できません。







そして、CouchBaseがあります。 一般に、このコレクションにCouchBaseが含まれているのはなぜですか？ 彼は少し違います。 これは完全なエンタープライズソリューションです。 インストールが非常に簡単になるように完了してください。 子供がそれを処理できるほど簡単です。 さらに、クラスターは非常に簡単に作成できます。 また、子供は対処します。 つまり 数回のマウスクリックのレベルです。 これは、以前のデータベースとは大きく異なります。 また、memcachedのようなmemcachedプロトコルも持っています。よく似ているので、同じドライバーを使用できます。テストしないのはこのCouchBaseであるため、テストに持ち込みました。







そして、スループットをテストしてみましょう。 私たちは何をしましたか？ 結果はそのような写真です：







青はTarantoolデータベースです。 ダークブルーはハッシュインデックス、ライトブルーはツリーインデックスです。 赤Redisがあります。 オレンジは、一般的に言って、Redisでもありますが、Azure Redis Cacheと呼ばれる特別なものです。 これは、Microsoftのサービスです。 曇っており、テスト仮想マシンと同じデータセンターにインストールできるため、そのようにテストできます。 灰色のCouchBaseがあります。 そして緑-Memcached。 memcachedの興味深い様子をご覧ください。 仮説があります。すべてのコアをロードし、後で天井に到達するためですが、まだ検証されていません。



ワークロードをまったく変更しても、状況はあまり変わりません。















ワークロードFは重いワークロードです。







そのような写真。 Tarantoolのスループットは、競合他社をはるかに上回っています。







WALでテストすると、どうなりますか？



これは、WALなしの画像です。







そして、WALを追加します。







原則として、わずかに減少しましたが、何も変わっていません。 TarantoolとRedisがメインの競争相手です。そのような写真が出てきます。 CouchBaseとMemcachedははるかに低いですが、WALはありません。 CouchBaseはまだテストしていませんが、Memcachedはテストしていません。







レイテンシーについて。 このユーティリティYahoo!は、すべてのタイプのコマンドのレイテンシを個別にカウントします。 読み取りレイテンシは次のようになります。







そして、レイテンシーが低いほど良いのです。 つまり スループットを検索した場合は、検索する必要があります。 色は同じで、下にTarantool、次にRedisです。 これは遅延平均です。







Yahoo! 既に2つのパーセンタイルを提供していますが、パッチを当てることができ、ヒストグラムを作成することができ、任意のパーセンタイルを作成することができ、95番目を提供します。



そしてここを見てください：







95パーセンタイルでは、RedisがTarantoolよりわずかに劣っています。 しかし、99日には反対に：







つまり それらは非常に近いですが、95パーセンタイルで交換されます。 エラーはありません。正確なデータを次に示します。 ここでは、クエリの数は500万クエリであり、パーセンタイルは200万レコードの500万クエリでこのデータをすべて構築しました。







Upadateがある場合（まだワークロードAがある場合）、次のようになります。







ここに平均があります。 Memcachedがどこでどのように不思議になったかを見てください。



そしてここに95パーセンタイルがあり、タランツールは再び優れています：







しかし、99パーセンタイルに移動すると、ここでもRedisの方が優れていますが、ここではそれらの間の距離がより強くなります。







なぜそうですか、それはどういう意味ですか？ Tarantoolには高速クエリが多数ありますが、低速クエリにはテールがありますが、Redisにはすべてのクエリがあります。 彼のヒストグラムは少し右側にあります。 Tarantoolには2つのこぶがあります。 最初に、高速クエリ、それらの多く-95％、そしてさらに進んで、99パーセンタイルがRedisに向けられた後のどこかに、多くの低速クエリが続きます。 また、Redisの中央には1つのこぶがあります。 そして、ヒストグラムを作成する場合、Yahoo！ テストはそれらのビルド方法を知っているので、それを確認します。 唯一のことは、そこで自分でビルドする場合、Xに沿った対数スケールでビルドする必要があることです。そうしないと、何も表示されません。







このような興味深いRead-Modify-Writeコマンドがあります。 これはワークロードFです。 読み取り-変更-書き込み。 リーダーからのデータが自分自身を通過するのを待つ必要があるため、スループットは待ち時間に大きく依存するため、これは難しいチームです。



見て、このような写真があります：







つまり Tarantoolのレイテンシははるかに低くなっています。 見てください、ここで私たちのRedisは非常に高くなりました。



95パーセンタイルがある場合、RedisはTarantoolに小さな赤いしがみつき、memcachedのあるクラウドは逃げました：







99パーセンタイルがある場合、Redisは再びTarantoolよりわずかに進んでいます。 99パーセンタイルでは、RedisはTarantoolをわずかに上回っています。 木製のインデックスを持つタランツールが上がりました。 このような興味深い画像：







さて、これはテストする1つの方法です、Yahoo！ テスト。 私は別のテストを書いて、テストのアプローチをわずかに変更しようとしましたが、多くはありませんが、まずデータベースから最大スループットを絞り込もうとしました 限界まで直接、ワークロードなしでそれを絞ってください。 このようなテストは2つの部分で構成されています。最初にデータをハンマーで読み取り、次にデータを読み取ります。 ページがあり、これは非常に簡単なテストです。







次に、その仕組みを説明します。 彼は非常に興味深い結果を出しましたが、Tarantoolには4つのバグがあり、そのうち2つはクラストで、すぐに修正されました。 それらはすでにリリースされています。







どのように機能しますか？ スループットのためにデータベースにリクエストを注入するためのプールスレッドがたくさんあります。 ここにはソケットがあり、そこには必要な数のソケットがあり、ソケットごとに2つのストリームがあります。 一般に、無差別に、書き込み、書き込み、書き込みを直接自動的に書き込みます。 そして、2番目は準備データを読み取ります。 また、レイテンシをカウントするスレッドがあります。 それらのいくつかがあります。 多くの最初のストリームがあり、それらはペアであり、待ち時間のストリームは1つ、時には2つまたは3つであり、最初に書き込み、次に回答を待ち、回答を読んで、そこで強調されているものを要約します。 特別な変数はアトミックに合計され、平均が考慮されます。 つまり パーセンタイルはまだ考慮されていません。 近い将来、私はそれを行いますが、これまでのところ平均が考慮されています。 もちろん、相互に影響しますが、レイテンシフローには2つまたは3つの部分があり、スループットには数百個ありますが、わずかに影響します。 さらに、スループットはより多くのノンストップでポンピングされ、レイテンシが期待されます。 また、モニターがすべての変数を1秒に1回メモリーから読み取り、画面に表示するストリームがあります。



そして、私たちは何を得ますか？







Yahoo!テストの悪い点は、標準クライアントを使用していることです。 彼はデータベース自体をテストするのではなく、データベースをクライアントと一緒にテストします。 Memcachedのクライアントを作成したとき、spymemcachedを使用しました。 これはCouchBaseの作者によるライブラリで、非常に高速ですが、それにもかかわらず、私たちにとってはブラックボックスです。 そして、一般に、クライアントを取り除き、最もシンプルなクライアントを作成することを目標に設定しました。これは、テストのためだけであり、機能をまったく使用せず、仕事で使用することはできません。リクエストの送信と回答の読み取りのみが可能です。 どうやってやるの？ タランツールには3つの部分があります。1つ目はサイズ、ヘッダー+本体、2つ目はヘッダー、2つの数字です。 青で強調表示されているものに興味があります。 これは、エラーまたはエラーではないリターンコードです。 そして、最初のサイズのフィールドを知っているので、最初のフィールドを読んで、ヘッダーを読んで、残りを読んで、サイズを知っています。 そして、これらのストリームのペアでこのことを無差別にただ読んで読んでください（スライドをさらに高く見てください）、スクラップの方法で読んだばかりの緑と赤のものがあります。



Msgpackは、このようなバイナリ実装プロトコルです。 それからの通常のライブラリは遅いため、 すべてのライブラリを削除しようとしましたが、msgpuckと呼ばれる実装もあります。 彼女は速いです、私はこの問題のためにそれを少し修正しました。



Memcachedはまだ簡単です。 そのプロトコルは、バイナリ、固定サイズ、および可変フィールド長です。 構造を減算し、戻りコードを取得し、フィールドを減算しました。 それだけです つまり とても簡単です。



Redisはより複雑で、テキストプロトコルがあります。 Redisプロトコルに入ると、選択に対する成功した答えはプラス記号で始まることがわかります。 「+」そして、何かが戻ります。 間違いはマイナス記号です。 そして、キーも、読み書きするデータセットの値も「+」または「-」を持たず、ソケットからバイトのベアストリームを読み取ることに同意する場合、単に賛否両論を数えることができます。 「+」-返された成功した応答の数、「-」-返されたエラーの数。 このような実装は高速になります。 「+」および「-」、すべて。 バイトが「-」ではなく「+」ではない場合は読み取り、「+」または「-」では単純にカウンターを追加します。 そして、私たちはこのことを推進し始めます。 彼女はAzureを追いかけ、次のような結果を受け取りました。







最初にそのような写真を用意しました。 これがテスト全体です。 始まりがあり、これらは選択のフェーズであり、そこで何かが起こり、RPSは非常に高く、ヤフーのテストよりもはるかに高いことが判明しました！..破線がある場合、破線のないWALがあります-WALなし 赤-タランツール、オレンジ-木付きタランツール、緑-Memcached、青-Redisバージョン2



だから私たちには洞察がありました：







データが高速で圧縮されるため、スループットが高いほど、テストは短くなります。



そして、レイテンシーを考慮します：







このテストは、ここでのグラフィックストリームの数ではなく、時間に基づいていることに注意してください。







そして、「失敗」があります。 時々Yahoo!をテストする 良い結果を示すことができますが、作業を開始すると、ある時点で急激に鈍化し始めます。 平均は普通のように思えますが、そのようなtupeyは合格できます。 そして、タイムラインを構築することが望ましいです。 Yahoo! これは、小さな松葉杖を構築する場合に可能です。 ここではかなり自然な方法で構築されており、すぐにcsvがExcelまたは他の場所にエクスポートされます。 私はこれらのスケジュールを上司に伝えました、上司は、ナンセンスで読めないと言いました。 だから私はそれらを描き直した。 このように：







これがスループットです。 赤はタランツール（ハッシュ）、オレンジはタランツール（ツリー）です。 次にMemcachedを実行してから、RedisとAzure Redis Cachedを使用します。 ここで、Redisはバージョン2です。3番目、最後、3番目ではなく、Memcachedエリアで少し高くなります。



WALがある場合、画像は変更されません。







そして、遅延がある場合、まさに「障害」を正確に見ることができます。







つまり、大きなスループットを持っているように見えますが、いくつかの点でここで機能するすべてのものを台無しにする可能性があります。 見えます。







挿入を比較する場合、画像は、完全に予測可能です。 再びタランツールが高いです。







そしてレイテンシー。 Redisは、他のすべてのものよりも大幅に待ち時間が長い、つまり 3行あります-すべて1つです。







そして、ここでもこのように。



そして、メモリフットプリントを測定する方法は？







このために、小さなスクリプトが書かれています。 与えられたビットがどれだけのメモリを占有しているか、与えられたプロセス識別子を考慮するだけです。 スクリプトは次のようなものです。







RSSを読んで、これらのRSSフィードを追加し、bcで要約します。 そして、タイムアウトして追加してサーバー側に出力します。







同時に、テスター側ではデータベースに送信したクエリの数を把握しているため、残っているデータの量を把握しています。 また、スケジュールを作成できます。



グラフ自体は興味深いものですが、ここで最も興味深いのは死後の状態です。 そして、これは非常に予想外の写真です。 そのスコープは非常に予想外です。







ハッシュを使用したTarantool、ここではツリーを使用したTarantool ... 彼女が使うRAMの量。 , — . Memcached — . .



. つまり , , . :







- — . .



: « , , ?». .



. , , , . . , , range from to, B-, , , - Memcached . WAL, Memcached . . -, . , .



. , , . ? , . - , . . , , « » , , , , , - . -, , .



, , , - , - .



. , .

連絡先

» Rvncerr

» facebook

» Mail.ru会社ブログ

このレポートは、高負荷システムHighLoad ++の開発者の会議で行われた最高のスピーチの1つの転写です。現在、2016年の会議を積極的に準備しています。今年は11月7日と8日にSkolkovoでHighLoad ++が開催されます。



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