たとえば、FacebookのGraph APIのように見えるものを実装しようとしていて、非常に高速で何百万ものユーザーをサポートする必要がある場合、RDBMSの代わりにRedisを使用することの欠点は何ですか?
ありがとう!ジョナサン
たとえば、FacebookのGraph APIのように見えるものを実装しようとしていて、非常に高速で何百万ものユーザーをサポートする必要がある場合、RDBMSの代わりにRedisを使用することの欠点は何ですか?
ありがとう!ジョナサン
従来のRDBMSの代わりにRedisを使用することには、多くの潜在的な利点と潜在的な欠点があります。彼らは確かに非常に異なる獣です。
潜在的な欠点のみに焦点を当てます。
Redisはメモリ内ストアです。すべてのデータがメモリに収まる必要があります。RDBMSは通常、データをディスクに保存し、データの一部をメモリにキャッシュします。RDBMSを使用すると、メモリよりも多くのデータを管理できます。Redisではできません。
Redisはデータ構造サーバーです。クエリ言語(コマンドのみ)はなく、関係代数はサポートされていません。アドホッククエリを送信することはできません(RDBMSでSQLを使用できる場合のように)。すべてのデータアクセスは開発者が予測する必要があり、適切なデータアクセスパスを設計する必要があります。多くの柔軟性が失われます。
Redisには、永続性のための2つのオプションがあります。通常のスナップショットと追加専用ファイルです。それらのどれも、REDO / UNDOロギング、ブロックチェックサム、ポイントインタイムリカバリ、フラッシュバック機能などを提供する実際のトランザクションサーバーほど安全ではありません...
Redisは、インスタンスレベルで(アクセス権に関して)基本的なセキュリティのみを提供します。RDBMSはすべて、オブジェクトごとのきめ細かいアクセス制御リスト(またはロール管理)を提供します。
一意のRedisインスタンスはスケーラブルではありません。シングルスレッドモードでは、1つのCPUコアでのみ実行されます。スケーラビリティを得るには、いくつかのRedisインスタンスをデプロイして開始する必要があります。配布とシャーディングはクライアント側で行われます(つまり、開発者がそれらの面倒を見る必要があります)。それらを一意のRedisインスタンスと比較すると、ほとんどのRDBMSはより高いスケーラビリティを提供します(通常、接続レベルで並列処理を提供します)。これらはマルチプロセス(Oracle、PostgreSQL、...)またはマルチスレッド(MySQL、Microsoft SQL Server、...)であり、マルチコアマシンの利点を活用します。
ここでは、主な欠点についてのみ説明しましたが、Redisを使用することには多くの利点もあることを覚えておいてください(非常に高速、優れた同時実行サポート、低レイテンシ、プロトコルパイプライニング、楽観的な同時パターンを簡単に実装できる優れた、優れたユーザビリティ/複雑さの比率) 、SalvatoreとPieterからの優れたサポート、実用的なナンセンスなアプローチ、...)
特定の問題(グラフ)については、グラフ指向のデータを格納するために特別に設計されたneo4JまたはOrientDBを確認することをお勧めします。
いくつかの追加があります:redisには値の長さの制限があります。redisを使用するときは、特にredisクラスターでは、常にredisのK、Vサイズについて考えます。