Again:
searchAfter is good, but when you do Web paging, you will never know The user
go to which page.
Unlike google or yahoo... they only give you max 76 page as I see.
In my scenario, user can go to 10-20 or 20-30 and then again 10-20
by the way , the timestamp I stored is long, using: System.currentMillisecond()
/ 1000 , I just get rid of Millisecond and the minmum is seconds
when I do paging , especially when I using sort ( the sorting field is just the
timestamp) , it is really eating memory
searchAfter(docId) require docId, I saw the lucene Core test code , there is a
Test code using searchAfter, but you still fisrtly get the docId
how do I get the docId? 4999990-5000000, I need to get 4888889, but if I really
get 4888889 docId, there is no need to use searchAfter, you
see 4888889 vs 5000000, just 20 , instead I think I will use search() to get
all 5000000 and then get the last ten.
My scenario is specail unlike most search engine requirements
Toke Eskildsen :
(timestamp_in_ms << 10) | counter++ is a unique identifior ?
Using timestamp_in_second can reduce terms but because the logs are too many ,
it doesn't do much
According to Hibernate Search and mysql, I decide to use Shard by num.
for example:
1000000 logs as a index , and then create a new one, besides I can use this is
I identifiy the log using a timstamp one by one.
so :
1000000 | 1000000 | 1000000 | 1000000
only one is active , which is doing indexing, and when reaching 1000000 , a new
one created
when I search things, I combine them together, not using MultiReader, but using
Concurrent index searching just like ExexuteService.
And I must be careful of the Paging, because I need to caculate echo index
contains how many documents.
I don't whether this is good , but the is one way I thought of
---------------------------------------------------------------------------------------------------
Confidentiality Notice: The information contained in this e-mail and any
accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential
and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of
this communication is
not the intended recipient, unauthorized use, forwarding, printing, storing,
disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this
communication in error,please
immediately notify the sender by return e-mail, and delete the original message
and all copies from
your system. Thank you.
---------------------------------------------------------------------------------------------------
