AEM support for 1000+ jcr nodes - user profile/products

Hi Thanks,

Also this http://docs.adobe.com/docs/en/aem/6-0/develop/platform/custom-authentication-scenarios.html gives multiple user scenarios . But for millions of users the design speaks about UserManager implementation to Authorization table in DB ? Will a MongoMK be a better alternative solution OOTB for a large end user profile storage and personalization ? considering profile sync handled in MongoDB cluster (data layer) 

Also please share thoughts on product/PIM nodes in jcr - recommended scale /number of product nodes for PIM sync  with e-commerce /PIM importers running in author considering large product catalog imports? also please share if any reference number for large product catalog using PIM importers ?

As I pointed out, 1000 node limitation is only in the case of ordered children  in OAK.If you dont need to maintain order, you can use nodetypes like oak:unstructured, which allows you to store a large number of children. Also for your usecases of 300K users, oak handles it.

 Hi all,

Just got to see this jackrabbit 3 oak goals 

http://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jackrabbit%203

Which has some details on supporting - not sure if it is current (done) or future (in-progress)

- 10M direct child nodes

- Number of users: 200M / 20M per group

Does this mean the above node statistics is alsosupported in AEM  as it uses OAK ? or it is still a goal kind of in-progress ?

Answer to this might give more clarity AEM support for 300K + Users / Product /Content nodes .

Hi

1) I haven't found a good source of documentation for this.

2) It mostly affects the performance of the UI. Displaying thousands of assets isn't fun for the browser ...

3) I am not aware of any limits beyond the jcr standard.

kind regards,
Jörg

I dont think there is any restriction on the node depth ! Node depth is just for better organizing and grouping.

Hi Kalyan,

Thanks for your inputs few more question to get more clarity 

1) Is there any technical references / links to the nature of unordered child nodes and 1000+ ordered node limitations ?

2) How does 1000 node limitation impact DAM assets and its nodes ?

3) Also are there any specific references maximum node depth supported by JCR both with TarMK/MongoMK kind of load data test references on CRX2/CRX3 ?

4) What is the optimal depth recommended for user profile nodes to have better read and write performance ?

5) Overall looking for some best practices on end user profile nodes and product data nodes within in AEM

1. OAK should be able to manage 300K users . By default, it will create 300K users in 64 sub trees. So it wil be some 5000 users in a folder.for ex.,(/home/users/(A-Z,a-z) etc.,
2. This 1000 node limitation is only if the parent node can have only ordered child nodes. This is irrespective of tarmk or mongomk. The rep:authorizable fodler(the immediate folder under/home/users ) can have unordered child nodes. So it doesnt have that problem
3. As always, do not store any PII info. Do not store and sensitive info.
4. As mentioned in 2., as long as the folder can have unordered child nodes(for ex., nt:unstructured will only have ordered child nodes where as oak:unstructured can have unordered child nodes), we wont have this 1000 node children limitation
5. Please use unordered node types.

We come across this question time and again while creating solution for enterprise. Profile management along with their identity. Before i churn out my set of questions for audience, i would love to know what was the decision taken on this?

The 1000 child node limitation was for CRX2, in Oak as Joerg pointed out it is more around it's not a great UX experience to have so many children under a single node. 

As for having 300k users in the repository, is this really necessary? What kind of site is this? For large numbers of users you should consider an external authentication mechanism LDAP or SAML. If the personal details are alwaready stored in a back end system, then leave them there and you can then get personal details after authentication and store these in the browser, allowing you to personalise the content. Rather than persisting the user, you can create the user on authentication and then have a job to delete users that have not logged in for a certain time period. It all comes down to use case, it sounds like this is a theoretical question rather than a specific use case, which makes it hard to give advice without concrete requirements.

Reverse replication for users has been deprecated and you should use SCD to sync users across a TarMK farm.

Regards,

Opkar