4

I'm trying to write a light weight content type that work similar to Facebook's post.

  • The whole content schema is just a text field. There's no title, description.

  • It must be Contentish and is managed by CMFCore: It must have an FTI, a portaltype so that we can create/browse content through standard method; it is catalog-aware.

  • They will have relation/reference within each others.

  • The number of objects is gonna be huge, say 10-100M.

The most similar things to this is the comment object (plone.app.discussion). While I've looked through the plone.app.discussion, I found the content implementation is really complicated, with too much low level base classes. In most of the parts, I either don't understand it at all or it can't be reused outside the comment use case, and have little referenced/sample value to me.

So I want to ask is how much overhead it will be if I go the high level framework path compare to the low level one that plone.app.discussion went through ?

quyetnd
  • 589
  • 3
  • 8

2 Answers2

5

I don't think p.a.discussion is right for you.

A Dexterity type may be fine, but you'll need to tune the performance. If performance is going to be an issue, it'll be because of the things that make types contentish (e.g. an FTI, the CMF base classes), so nothing will be lighter than Dexterity and meet your requirements, but you may want to think about whether you actually want to store everything in a relational database or something else instead. It shouldn't be strictly necessary, though.

Martin

optilude
  • 3,538
  • 3
  • 22
  • 25
3

Plone will not scale to 10 M items in its catalogue (the largest I've heard of is something like 400 k). I would suggest building your application with a light weight framework like Pyramid.

Laurence Rowe
  • 2,909
  • 17
  • 20
  • Where do you think the problem lie ? ZODB can't scale big ? the catalog is too large to fit on the client's memory ? the catalog is poor implemented so that query over million objects take too much cpu ? – quyetnd Oct 13 '11 at 17:27
  • 2
    The ZODB is not the problem here. The problem is that Plone's portal_catalog becomes a single point of contention for every write to the database. Unfortunately all of Plone's navigation is built from the catalogue, which makes asynchronous catalogue updates difficult to achieve. This needs to be fixed, but is a long term project. – Laurence Rowe Oct 13 '11 at 21:17