あなたの質問に対する正確な回答ではありません (コメントするほどの評判ではありません (?!?)) が、問題はスケールであり、PostgreSQL から来ていることを理解しています。PostgresXC をまだ試しましたか? これは、NoSQL への移行よりもはるかに簡単な移行かもしれません。ご存じのとおり、NoSQL データベースのパフォーマンス特性とニュアンスは大きく異なり、実際には良いことよりも悪いことの方が多い可能性があります。Postgres-XC は PostgreSQL のマルチマスター書き込みスケーラブル フォークであり、PostgreSQL 機能の観点から 9.1 と 9.2 の間のどこかにあり、アクティブなプロジェクトです。9.2 への準拠は、私の記憶が正しければ、今月か最後に予定されていました。セットアップは比較的簡単です。1 つはプライマリとして、もう 1 つはフェイルオーバーとして、2 つの GTM を構築し、十分なメモリを提供します。次に、コーディネーターとデータ ノードのペアを追加することで、水平方向にスケーリングできます。サーバーごとに 1 つのコーディネーターと 1 つのデータ ノード。アプリケーション層は任意のコーディネーターと通信でき、トランザクションは適切なコーディネーターに送信され、テーブルごとにデータの分散を指定できます (小さな参照テーブルの場合は複製するか、大きな参照テーブルの場合は分散します)。クエリを適切に設計すると、複数のコーディネーター/データ ノードのペアでクエリを配布して同時に実行できるため、パフォーマンスが大幅に向上します。
あなたが NoSQL を探していることは知っていますが、私たちにも垂直スケールと水平スケールの問題があり、リレーショナル機能を NoSQL システムに組み込むよりも NoSQL 機能をリレーショナル システムに組み込む方が簡単であることがわかったので、これについて言及します。 . そしてもちろん、それはすべてデータに依存します。NoSQL が絶対に最良の選択である場合もあります。場合によっては、大きな頭痛の種になることもあります。たとえば、一部の NoSQL データベースにはファイルシステムの成長に問題があるため、水平スケーラビリティを購入したと思っていたのに、家や家の外で SAN を使い果たしてしまった場合などです。
とにかく、それが役立つことを願っています! 私はそれをコメントとして残していたでしょうが、stackoverflowには奇妙な評判が続いています。
忘れていたのですが、Postgres-XC を使用すると、分散する列とアルゴリズムの種類を指定できます。私は通常、ハッシュで配布し、2 つのことを確認します。1 つ目は、アプリケーション側でハッシュを生成できるため、膨大な数の行であるテーブルで結合を行う必要がありません。2 つ目は、ハッシュがサーバー間で分散レベルを維持することです。正しいだけでなく、関連する情報を同じサーバーにまとめて保持し、クエリの出荷可能性を高めます。つまり、顧客テーブルと顧客注文テーブルがある場合、両方のテーブルにある顧客固有の情報のハッシュで両方を配布し、そのアプリケーション側で生成できることを確認します。それが理にかなっていることを願っていますが、うまく説明できたかどうかはわかりません。