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:
Exactly.
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.
--
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.
On Jul 3, 2013, at 7:47 AM, Erick Erickson erickerick...@gmail.com 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
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
://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 kowish.adam...@gmail.com 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
-cloud-date-based-paritioning-tp4074729.html
Sent from the Solr - User mailing list archive at Nabble.com.
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.
On 2 July 2013 22:35, kowish.adamosh kowish.adam...@gmail.com 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
.nabble.com/Solr-cloud-date-based-paritioning-tp4074729p4074899.html
Sent from the Solr - User mailing list archive at Nabble.com.
-date-based-paritioning-tp4074729p4074899.html
Sent from the Solr - User mailing list archive at Nabble.com.
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-paritioning-tp4074729p4074899.html
Sent from the Solr - User
14 matches
Mail list logo