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.
Solved! Go to Solution.
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.
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.
Hi @afaust l,
Thanks for your response.
Follow up question: Following bootstrap content model approach - is there a way to dynamically create node with a new custom TYPE ? Content model can be incrementally modified by adding but that would need build/release cycle ...
thanks,
Ranjeet
Ehm.... yes. New nodes with custom types can be created via API at runtime (dynamically) - though I am not sure that is what you were asking, but the question appears to be that basic to me. Models can be deployed + activated at runtime too, via the Data Dictionary.
Ask for and offer help to other Alfresco Content Services Users and members of the Alfresco team.
Related links:
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.