Thanks Chetan, Sorry, but that part is out of my reach. There is an IT team in charge of managing the infrastructure and make optimizations, so It is difficult to get that information. Basically what is was looking for is the way to parallelize the indexing process. On the other hand, reducing the indexing time would be fine (it was previously reduced from 7 to 2 days), but I think that traversing more than 100000000 nodes is a pretty tough operation and I'm not sure if there is much we can do. Anyway, any pointer related to indexing optimization or any advice on how to design the repo (e.g. use different paths to isolate different groups of assets, use different nodetypes to differentiate content type, create different repositories [is that possible?] for different groups of uses...) is welcome.
Regards. On Thu, Jun 8, 2017 at 12:44 PM, Chetan Mehrotra <[email protected]> wrote: > On Thu, Jun 8, 2017 at 4:04 PM, Alvaro Cabrerizo <[email protected]> > wrote: > > It is a DocumentNodeStore based instance. We don't extract data from > binary > > files, just indexing metadata stored on nodes. > > In that case 48 hrs is a long time. Can you share some details around > how many nodes are being indexed as part of that index and the repo > size in terms of Mongo stats if possible? > > Chetan Mehrotra >
