私はいくつかのWebサービスを開発しています。1つは製品を購入するためのもので、もう1つは製品を検証するためのものです。複数のクライアントがBUY（約250 /秒）を呼び出し、VALIDATEについても同じです。バックエンドを呼び出す前に、表形式のデータ構造をクエリして更新する必要があります。
Oracleのようなリレーショナルデータベーステーブルを使用してこの共通のデータ構造を維持すると、ネットワークの待ち時間が原因で処理速度が低下するように感じます（データベースとクエリが最適に調整されていると仮定）。私はEhCacheとHazelcastを提案されましたが、データベーステーブルをよく知っているので、データベーステーブルを使用することを好みます。
ネットワークを介してデータベースにアクセスすることが、1秒あたり250〜300のトランザクションを処理することになっているアプリケーションのボトルネックになる可能性があるかどうかを誰かが確認できますか？
確かに、サーバーインスタンスがダウンし、データ構造のメモリ内表現が失われた場合でも問題ありません。
それは本当にあなたのアプリケーションが何をしているかに依存します。
もちろん、高価なハードウェアと高価なネットワークハードウェアを備えたデータベースマシンを使用できます。
問題は、これは本当に必要なのかということです。
いくつかのコメントで述べられているように、キャッシングは、主にREAD（書き込み要求よりもREAD要求が多い）を実行する場合にほとんど役立ちます。最適化するには、インデックス作成を検討する必要があります（たとえば、アドレスを保存する場合は、ID以外のほとんどのクエリがこのフィールドによるものであると想定して、「ip」フィールドによるインデックス作成を検討できます）。
これは正しい部分にすぎません。 DBスキーマの計画（これの他の側面は、データを可能な限り適切にモデル化することにより、テーブル間の複雑な結合を回避することかもしれません）、そしておそらくNoSQLデータベースですら。
スケーリングについてキャッシュとスケーリングを行う場合は、分散キャッシュ/分散データ構造を使用する必要があります。
たとえば、infinispanはここで役立ちます。また、 h2
などのメモリ内/プロセス内（つまり、コードがjar内にあり、アプリケーションのJVMで共同ホストされている）を使用してパフォーマンスを向上させることもできます。これにより、クエリ時間をさらに短縮できます。しかし、繰り返しになりますが、それは実際には特定のユースケースに依存します。残念ながら、説明した内容は一般的すぎます。
IMO、キャッシュは、更新リクエストがクエリリクエストよりも低い場合に役立ちます...サーバー上の行も更新する必要があるたびに更新する場合、すでにクエリされた値を格納する大きなマップとしてキャッシュすることを想像してください。 DBへの要求を再度実行するために、エントリを無効にすることによってキャッシュ。