Hello,
so if Lucene or Solr have a problem or are busy for some reasons, we can't 
search anything, if i understand.

So, i imagine, we have to be very careful to the search engine that is a 
potential single point of failure if it goes down or if loose index and so it 
has to make a full reindex.

What kind of topology (application and search engine) do you suggest to 
mitigate this problem ?

Thanks in advance,
best regards

-----Messaggio originale-----
Da: Davide Giannella [mailto:[email protected]] 
Inviato: venerdì 26 febbraio 2016 10:17
A: [email protected]
Oggetto: Re: info on queries and index

On 25/02/2016 16:40, Ancona Francesco wrote:
>
> Hello,
>
> we'd like to study in deep queries and index. In particular is not so 
> clear, from documentation, what is indexed by default.
>
> For instance if i create a new type of document (IdentityCard with 
> name IDC) with 2 new properties (idCard and idGeneralAnagrafic) are 
> these data (ie metadata) indexed ?
>
Short answer: oak does not index anything by default.

Long one. It depends by how you construct the repository. For example if you 
build a JCR repository by providing the InitialContent RepositoryInitializer 
(0), you'll see that it creates some index definitions (1): uuid, nodetype and 
counter.

(0) https://goo.gl/MNpam7
(1) https://goo.gl/G6RChL
>
>  
>
> And in that case the search is delegated to db (mongo or postgres that 
> store metadata) or is delegated to solr or lucene ?
>
As it is now, Oak does not delegate to the persistence any of the searches. We 
don't have plans to do so as far as I know. In oak we have mainly 2 types of 
indexs: PropertyIndex and  LuceneIndex. You can find more details starting from 
(3)

(3) http://goo.gl/vfMJm3

>  Finally, if we store a few million documents, what kind of strategy 
> would you suggest for the search?
>
>  
>
The main strategy around searches is that the query is faster then the index is 
small. So fine tuning the indexes is the main strategy around fast queries. 
Depending on the index you use it will make sense one strategy versus the 
other. As a rule of thumb I'd say that doesn't matter what index you use for as 
long as you keep the content with a decent structure. For example 
LucenePropertyIndex can evaluate multiple conditions and path restrictions as 
well.

When defining an index you can specify for what path they should index making 
therefore the index as accurate as possible. It's a tradeoff you'll have to 
find yourself as with all the performance tuning. Again I'd start with (3).

HTH
Davide

 
 
************************************************************************************
This footnote confirms that this email message has been scanned by PineApp 
Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************



Reply via email to