Information needed on limitation/recommendation on custom type in content model

ranjeetsi

Hi community,

We are in process of designing content model - would like to know on restrictions/limitations if any:

a) We will have around 400 million nodes

b) We have 200 custom types . Will creation of 200 custom types with parent cm:content have performance issues/ other issues.

c) Or another option of having - 10 abstract custom types
Group them to 20 each custom types
Will this approach have any performance benefit/ other benefit.

d) Also - let me know if there is any limitation/recommendation on the levels of custom type like 3 level or 4 level depending on performance or other

Kindly note: On an average we have 10 properties for each custom type.

Please suggest.

afaust

Note: This platform / forum is not used by any Alfresco Support Team members. This is a community-focused platform, with most active members being either freelancers, employees of Alfresco partners / service providers, users, or some Alfresco community staff / developer evangelist / community-member-turned-Alfresco-developers.

When considering the amount of nodes in the system, having more custom types which can be used to create highly selective queries should generally be considered better for performance than having only very limited numbers. Any kind of branch / level you can reasonably create and use to differentiate nodes in your content model both during creation but also lookup / query, will improve the selectivity of queries, improving both general query times e.g. for TMQ but also allow for more efficient cache re-use in SOLR queries.

There is no limitation at all as to the number of custom type levels / properties per type. I have work with systems where a single aspect defined up to 100 properties, from which only maybe a few dozen would be set on individual nodes.

In contrast to the data model, you should probably be more concerned with your technical server architecture / scaling and optimisation of supporting services, e.g. ensuring your DB can cope with the amount of data (by vertical / horizontal scaling), and prepare to use sharding for SOLR. You may also want to look into adjusting ACS allocated memory and cache configuration to ensure that you have a sufficient part of the hourly/daily working set of nodes cached at runtime, and do not suffer from frequent cache overflows / invalidations, causing ACS to do many repetitive loads from the DB and slowing down on average as a result.