4

私は現在、大規模なプロジェクト (アクティブなメンバーは約数百 K) に取り組んでおり、Plone ソリューションに強く依存していました。

ここここのように、それに関連するいくつかの質問をしました。

非常に経験豊富なプロニスタ (およびアクティブなスタックオーバーフラワー) からいくつかの返信がありました。ほんとうにありがとう。人々は、Plone はそれほど大きく拡張できないと言い続けていますが、その理由のほとんどは ZODB によるものです。

次に、ZODB のインメモリ バックエンドについて考えます。RAMは今本当に安いです!通常の 300 ドルの 128 GB SSD の 10 倍であるわずか 3,000 ドルで 128 GB を取得でき、SSD の 300 MB に比べて 30 GB の IO 帯域幅を実現できます。

インメモリ バックエンド + バイナリ用の BLOB + バックアップ用の 10 秒のディスク ジャーナリング + 最後の 10 秒を除くすべての元に戻す操作は、インスタンスの kill になります。彼らはRDBMをスモークし、そのようなcouch*/redisなどと比較して完全なACID +トランザクション+オブジェクトマッピングを提供する必要があります.

技術的に可能ですか?実装はありますか?(あなたの意見では)実装する価値はありますか?

4

2 に答える 2

2

ZODB 全体をメモリに保持する代わりに、portal_catalog を別のマウント ポイントにマウントしてメモリに保持することができます。私はすでにこの種の構成を見てきましたが、標準ハードウェア (2 サーバー + 1 Zeo サーバー) を使用する約 8,000 人のユーザーに対してスムーズに動作します。おそらく、よりパフォーマンスの高いハードウェアを使用することで、ニーズには十分かもしれません。

于 2011-10-13T17:44:36.117 に答える