Hi Davide, My POV: Storing the indexes within the repo itself allows for operational simplicity. In particular: it allows to create a backup of the persistence (including the indexes) in a consistent form - without having to stop writes to the repo. In JR2 it is not possible to create a consistent backup of nodes and indexes without stopping writes to the repo (to my knowledge at least). You also extend your question to “what would happen if separate cluster nodes would maintain their own indexes (on local/private disc)?”. Two things: 1. Each cluster node would have to process full text extraction - i.e. Computationally expensive 2. Really bad: if a new node joins the cluster then that node would have to re-index the full repo.
IMHO the current design (to store indexes in the repo itself) is totally the right approach. This discussion is only about balancing property indexes vs Lucene indexes Michael On 10/08/16 15:11, "Davide Giannella" <[email protected]> wrote: >On 09/08/2016 13:18, Ian Boston wrote: >> Alternatively, move the indexes so that a sync property index update >> doesn't perform a conditional change to the global root document ? ( A new >> thread would be required to discuss this if worth talking about.) > >I'm stubborn and maybe even slow in learning, but again I ask myself: >why are we storing the indexes in the repository itself? > >I was not part of the original discussion around this; but frankly I >would have expected to have the indexes stored separately from the >repository. Let's say on the file system. Something like JR2 where it >was even possible to delete a directory and all the indexes were >re-generated from scratch. > >What do we loose if we would be moving the indexes outside of the >repository? Which means each AEM node will have its own index(es). > >Cheers >Davide > >
