As a really, really rough guide; Start with a small instance, 4-8G RAM (2-4G heap). Keep loading documents until things start to slow down (ie query/update responsiveness drops). Add a new node. Rinse and repeat.
If you have one node there is no point using replicas as they have nowhere to go. You can easily add replicas later though so it's no big deal. Shards is a little harder, start with the standard/default of 8 shards and go from there. Using aliases can allow you to reindex your data later if you feel you may want to change this. You can monitor your cluster with a range of monitoring plugins - elasticHQ, kopf, elasticsearch-monitoring, bigdesk. Just search for them on github. As Boaz mentioned, it really does depend on what you are doing. Chances are you will go through all this and get to a point where you want to rebuild your cluster with all your gained knowledge! Regards, Mark Walkom Infrastructure Engineer Campaign Monitor email: ma...@campaignmonitor.com web: www.campaignmonitor.com On 8 January 2014 09:18, Boaz Leskes <b.les...@gmail.com> wrote: > Hi Adolfo, > > The best way to scale depends on your data and how it behaves. You can > watch this great talk by Shay about two use cases to get inspired: > http://www.elasticsearch.org/videos/big-data-search-and-analytics/ > > Cheers, > Boaz > > > On Tuesday, January 7, 2014 8:13:18 PM UTC+1, Adolfo Rodriguez wrote: >> >> Hi, I plan to start with a small project, initially, with small data (few >> thousands records) to learn ES response, and, incrementally, increase data >> and resources on demand, to the big data, taking advantage of ES >> scalability. >> >> Is there a document describing such a strategy, i.e.: >> >> * how to properly configure an small basic deployment with good >> performance on low resources? (shards, nodes, clusters...) >> >> * then, how to keep detecting the necessity of incrementally adding >> resources, shard/nodes..., according to increases on data load? >> >> >> All docs that I find on scaling ES starts on deployments with m/billions >> of records. >> >> Alternatively, any advice on properly "configuring ES for the small >> data"? (as a starting point?) >> >> Thanks >> > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elasticsearch+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/3d444d6f-fa0d-4567-a46b-538ea9b379f9%40googlegroups.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAEM624ZRacXqWCg56kFvjYsf1_cDxLT4Drhdbk6jFL5_Q1EekA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
