以下は、テーブル/コレクションの挿入/読み取りに関する統計を示すテストの小さなセットです。 アプリケーションで発生する実際の状況をテストで確認できないことは明らかです。 それでも、好奇心から、私はいくつかの測定を行うことにしました。 その結果と結論は、私がカットされました。
テスト対象：
OS名：Windows 7 Professional
OSアーキテクチャ：AMD64
プロセッサー名：Intel Core（TM）i5-3340 CPU @ 3.10GHz
メーカー：GenuineIntel
プロセッサアーキテクチャ：AMD64 / EM64T
物理コア：2
論理プロセッサ：2
合計RAM：8139 MB（7.95 GB）
公式ドライバーの最新バージョンがmongo に使用されました
mcの場合、負荷を引いたものを使用しました。 10種類のクライアントで使用され、一部は起動しなかった、一部は非同期で動作しようとして落ちた。
Mongoバージョン：2.6.3
MCバージョン：1.4.4-14-g9c660c0（Windows用にコンパイルされた最後のバージョン）
アーランバージョン：5.10.4 / OTP R16B03
開始前の小さなコメント。
フォームの質問を予見します：「そして、mongoはそれと何の関係があるのでしょうか。メモリ内のストレージとディスク上のストレージをどのように比較できますか？！」 質問は合理的です。 答えは簡単です。私は興味を持ちました。 そして、私は人気があり、Erlangにドライバーがあるリポジトリを比較しました。
すべてのテストは真空で球形に分類できることを思い出してください。
それでは始めましょう。
挿入
私がチェックすることを最初に決めたのは、レコードの挿入速度とそれによって消費されるメモリです。結果は予想されていました。
ネイティブEtsテーブルは、最も近い競合他社であるdetsを10回以上も上回る確率で他のすべての人にオッズを与えました。 しかし、ちなみに、etsはメモリ内で動作し、ディスク上で動作するため、これは論理的です。 Mcはメモリでも動作しますが、どうやらそうです。 ドライバーが原因で（googleは約2倍の速度で結果を見つけました）、ほぼ70倍遅れ、mongaが少し速くなったことがわかりました。
10,000個のレコードを挿入する操作を実行すると、Mongodは2.7 GBのRAMを消費し、2.87 GBはETを、Mcは1.6を消費しました。
サンプリング：
ここでは、啓示も起こりませんでした。 Etsが最速で、次にdets、Mc、mongoの順になりましたが、ここでは最後の結果を確認する必要があります。 多数のレコードを処理する場合、Detsは非効率になり、レコードの数が多いほど効率は低下します。Mcはそれをバイパスします。 mongoの場合、サンプリングフィールドでインデックスが作成されました。
最後に、1秒間に処理できるレコードの数：
少しの結論
Cap Minute：組み込みツールを使用してデータをキャッシュします。
そして、実際には、etsテーブルの使用を妨げるものは何でしょうか？ それらに用語を保存しておくと便利です。 主な欠点は、データがメモリに保存されることです。また、テーブルを作成したプロセスが落ちた場合、テーブルも一緒に消え、その時点でそれにアクセスしているプロセスを引きずります。 はい、プロセスはスーパーバイザによって再起動されますが、データはすべてさようならです。 OK、データを使用してみましょう。すべてがディスクに保存され、何も失われません。 はい、しかし、ああ、これは「でも」です。大きなファイルサイズでテーブルを再度開いて損傷をチェックする時間は非常に重要です。プロセスは待機しますか？ それで、残っているのはMcであり、偶然にも、何らかの理由で、またはMongaで、または...
はい、厳しい現実にはすべてが落ちる可能性がありますが、McまたはMongoにはクラスターを展開する機能があり、1台のマシンがクラッシュした場合はいつでも別のマシンに切り替えることができます。 ただし、テストされたシステムの中で最も低速です。 そのため、パフォーマンスとデータのどちらを犠牲にするかを選択する必要があります。
選択したり犠牲にしたりすることはできませんが、私自身は次のような結論に達しました。
1）etsでは、「ホット」データキャッシュを保存する必要があります。これは常に必要であり、その損失は前兆ではありません。 また、ドキュメントでは、detsテーブルを開いてメモリ内で使用でき、閉じるとディスクにダンプされることが示されています。 しかし、テストからわかるように、detは少量のデータで効果的です。そうしないと、ディスクの操作に費やされる時間が長くなりすぎます。
2）あなたにとって重要なすべてのデータは、信頼できるストレージに保存する必要があります。それは問題ではありません。sql/ nosqlはあなたが落ち着く場所です。
3）Mcに似たモジュールが必要ですが、etsテーブルでは、必要なデータを「ホット」キャッシュに書き込んですぐに使用できるようにし、同期/非同期モードで他のストレージに転送できるようにします
結論はキャプテンのものであることが判明しましたが、おそらく、いくつかの測定からのすべての結論はほぼ同じであり、一度、どこかですでに聞こえていました。
ご清聴ありがとうございました。