The strategy doesn't require putting all the recent data on a single node.
What has been suggested is collection based - the most recent data will simply
be in it's own collection, that may or may not be on a single node.
This is pretty much always going to be advantageous for time series data.
Not saying it's always one way or the other, just
that one shouldn't automatically _assume_
putting the most recent data on a single node
is automatically good. It may well be, but
not in all cases.
On Wed, Jul 3, 2013 at 12:21 PM, Otis Gospodnetic <
otis.gospodne...@gmail.com> wrote:
> Exactl
Exactly. And the newest shard can also be kept small (e.g. maybe just
last 12h is OK to hit first and dig deeper only if you can't find
enough stories in the last 12h), which means it will fit in memory and
be crazy fast.
Otis
--
Solr & ElasticSearch Support -- http://sematext.com/
Performance Mo
On Jul 3, 2013, at 7:47 AM, Erick Erickson wrote:
> Usually most people
> care about today's news, and a hot story will
> generate lots of queries, all of which are serviced
> by today's shard.
That's really the whole point though - rather than slamming your whole cluster
with every search, th
Kowish
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Solr-cloud-date-based-paritioning-tp4074729p4074993.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
Otis,
Is it implemented? I can find only unresolved JIRA issues.
Kowish
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-cloud-date-based-paritioning-tp4074729p4074993.html
Sent from the Solr - User mailing list archive at Nabble.com.
ery much for advice.
>
> Out of curiosity: is there any way to partition shards (logical and
> physical) by specified value of specified field?
>
> Kowish
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Solr-cloud-date-based-paritioni
results will be unsatisfactory.
> Thanks very much for advice.
>
> Out of curiosity: is there any way to partition shards (logical and
> physical) by specified value of specified field?
>
> Kowish
>
>
>
> --
> View this message in context:
> http://lucen
66.n3.nabble.com/Solr-cloud-date-based-paritioning-tp4074729p4074899.html
Sent from the Solr - User mailing list archive at Nabble.com.
On 2 July 2013 22:35, kowish.adamosh wrote:
> Thanks!
>
> I have very limited response time (max 100ms) therefore sharding is a must.
Really? "Sharding is a must" without any measurements to
validate that assertion? I am not sure what advice to give
you if you seem determined to ignore any, but a
t find anything in documentation.
Thanks for help!
Kowish
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-cloud-date-based-paritioning-tp4074729p4074823.html
Sent from the Solr - User mailing list archive at Nabble.com.
ers...
>
> Thanks!
> Kowish
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Solr-cloud-date-based-paritioning-tp4074729.html
> Sent from the Solr - User mailing list archive at Nabble.com.
On 2 July 2013 20:05, kowish.adamosh wrote:
> Hi guys!
>
> I have simple use case to implement but I have problem with date based
> partitioning... Here are some rules:
>
> 1. At the beginning I have to create huge index (10GB) based on one db
> table.
> 2. Every day I have to update this index.
>
http://lucene.472066.n3.nabble.com/Solr-cloud-date-based-paritioning-tp4074729.html
Sent from the Solr - User mailing list archive at Nabble.com.
14 matches
Mail list logo
