Hi Carsten,
we designed "souper"[1] for the use case of large amounts of light
weight data in the zodb. "souper.plone"[2] integrates it with plone.
We use it in several projects to store information outside of the normal
plone content trees. It uses IOBTrees to store generic records based on
"node" and indexes all in an "repoze.catalog". Its a library/tool for
programmers without any out of the box functionality except a
controlpanel to administrate the location of the soup or reindex it.
Look at "souper.plone" pypi page where the simple steps to set up a soup
are shown.
Its easy to have such a soup storage on a separate mount point, which I
would recommend for your case. If you dont have it already (with such an
amount of users anyway) I'd think about using history free RelStorage
(with memcached) on postgresql.
[1] https://pypi.python.org/pypi/souper
[2] https://pypi.python.org/pypi/souper.plone
regards
Jens
On 2013-09-02 08:05, Carsten Senger wrote:
We have a bigger Plone site with an active community that has ~3000
frequently active users and plan to develop an add-on to send private
messages between members. Every member will have an "Inbox" where he
sees the list of members he has a conversation with. All messages he
exchanged with a member will be shown in 1 plain chronological list. The
functionality of the inboxes will be very simple. Beside the list of
messages per conversation we need to get the list of conversations with
unread messages and their unread message count.
Currently we plan how to store the messages and look into the following
options:
- ZODB / BTrees
- seperate ZODB mounted somewhere
- store messages in either
- a huge btree with all the messages, similar to
plonesocial.microblog
- a tree of objects per user/conversation, messages in btrees
- store the unread message count per conversation
- Store the messages in an RDBMS
For simplicity reasons we would like to keep the messages in the ZODB.
Has someone experience with a similar system and the performance of
BTrees? Is there a product with similar storage requirements that we can
look at?
Thanks,
...Carsten
--
Klein & Partner KG, member of BlueDynamics Alliance
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers