システムで何をすべきか: 集中化された大きな (100 - 400 mb) テキスト ファイルを保存/管理する
保存するもの : テキスト ファイルの行。一部のファイルでは行が一意である必要があり、ファイルに関するメタデータ (ファイル名、コメント、最終更新など) もファイル内の位置に保存する必要があります (同じファイルでも、アプリケーションごとに異なる位置にある場合があります)。
操作 : ファイルからの同時取得行 (クエリで 100 ～ 400 行)、行の追加 (100 ～ 400 行も)、エクスポートは重要ではなく、スケジュール可能
では、SQL DBMS を使用するストレージはどれですか?
NoSQL: Cassandra はオプションです (行ごとまたは行のグループごとに保存できると思います)。Voldemort も悪くありません。MongoDB を使用することもできますが、「大きなファイル」の要件に適合するかどうかはわかりません。
ばかげていないすべてのデータベース サーバーのキャッシュから 400 MiB が完全に提供されます。その限りでは、データベースの選択はあまり重要ではなく、どのデータベースでも高速に配信できます (「高速」にはさまざまな種類がありますが、必要なものによって異なります)。
生の速度がどうしても必要な場合は、次のようなものを使用できますredis。繰り返しますが、400 MiB は問題ではありません。
SQL は少し遅いかもしれませんが (それほどではありません)、柔軟であるという大きな利点があります。柔軟性、汎用性、および「組み込みプログラミング言語」の存在は無料ではありませんが、どちらの方法でもバッファ キャッシュからデータを返すことは多かれ少なかれ RAM の速度で機能するため、それほど悪い影響を与えるべきではありません。
後で別のデータベースが必要になった場合は、SQL を使用すると、いくつかのコマンドでそれを実行できます。また、計画していない別のデータベースが必要な場合は、SQL が実行します。単純なキー値ストアで別のことを実行できるという保証はありません。
個人的には、このようなかなり「小さな」データセットのパフォーマンスについて心配する必要はありません。本当に、あらゆる種類の DB が十分に機能しますが、心配する必要はありません。データセットのサイズが数十ギガバイトになったら、もう一度来てください。
本格的な SQL データベース システムが提供する余分な機能が絶対に必要ないと 100% 確信している場合は、NoSQL を使用して数マイクロ秒を短縮してください。それ以外の場合は、安全のためにそのまま使用してください。
編集：
詳しく説明すると、「やや下位クラス」のデスクトップには現在2 GiB（通常は4 GiB）以上があり、典型的な「大したことのない」サーバーには32 GiBのようなものがあると考えてください。その点では、400 MiB は何でもありません。サーバー上の典型的なネットワーク アップリンクは (追加料金を支払う意思がない限り) 100 mibit/s です。
400 MiB のテキスト ファイルには、約 100 万行が含まれる可能性があります。つまり、「典型的な SQL サーバー」では 6 ～ 7 回のメモリ アクセスが発生し、「典型的な NoSQL サーバー」では 2 回のメモリ アクセスに加えてハッシュの計算に必要な時間になります。つまり、数ダースのサイクルを与えるか、または取るか、どちらの場合も同じです。比較的遅いシステムでは、約0.5マイクロ秒です。
SQL を使用する場合は、クエリを解析、検証、および最適化する必要があるため、クエリが初めて実行されるときに数十マイクロ秒が追加されます。
運が良ければ、ネットワーク遅延は約 2 ～ 3ミリ秒です。これは、接続の確立、サーバーへの要求の送信、および応答の受信に 3 ～ 4 桁多くなります。それに比べて、クエリに 517 マイクロ秒かかるか 519 マイクロ秒かかるかを心配するのはばかげているように思えます。間に 1 ～ 2 台のルーターがある場合は、さらに顕著になります。
同じことが帯域幅にも当てはまります。最大サイズのフレームを想定し、ACK を想定せず、他のトラフィックがまったくなく、パケット損失がゼロであると想定すると、理論的には 1 Gibit/s リンクで約 119 MiB/s をプッシュできます。RAM は、問題なく 1 秒あたり数十 GiB を提供します。