{"_id":"567b00307c40060d005603e7","__v":4,"category":{"_id":"567b0005802b2b17005ddea3","pages":["567b001117368a0d009a6e10","567b00307c40060d005603e7","567b039a7c40060d005603ec"],"project":"5633ebff7e9e880d00af1a53","version":"5633ec007e9e880d00af1a56","__v":3,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-12-23T20:11:49.377Z","from_sync":false,"order":1,"slug":"best-practices","title":"Best Practices"},"project":"5633ebff7e9e880d00af1a53","user":"5633ec9b35355017003ca3f2","version":{"_id":"5633ec007e9e880d00af1a56","project":"5633ebff7e9e880d00af1a53","__v":15,"createdAt":"2015-10-30T22:15:28.105Z","releaseDate":"2015-10-30T22:15:28.105Z","categories":["5633ec007e9e880d00af1a57","5633f072737ea01700ea329d","5637a37d0704070d00f06cf4","5637cf4e7ca5de0d00286aeb","564503082c74cf1900da48b4","564503cb7f1fff210078e70a","567af26cb56bac0d0019d87d","567afeb8802b2b17005ddea0","567aff47802b2b17005ddea1","567b0005802b2b17005ddea3","568adfffcbd4ca0d00aebf7e","56ba80078cf7c9210009673e","574d127f6f075519007da3d0","574fde60aef76a0e00840927","57a22ba6cd51b22d00f623a0"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"parentDoc":null,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-12-23T20:12:32.937Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":2,"body":"We're commonly asked the question \"What kind of plan do I need?\" The answer? \"It depends.\" There's no cookie-cutter answer that meets all needs. Planning out your cluster is a matter of identifying the resources you'll need, and matching those observations against the various plans. The biggest things to consider when planning out an Elasticsearch cluster are:\n\n* **Total data capacity.** How you're storing and analyzing your documents will influence the size. We expect a 3–5x multiple over the source data, but that highly varies. Each level of replication will also increase the total capacity required; plan to use at least one replica for basic redundancy, with another to accommodate higher traffic volumes.\n\n* **Total number of shards.** Generally keep this low, at least for \"hot\" indices. Each shard in Elasticsearch is internally treated as an open file handle, which can cause a bottleneck in your cluster. Some clusters can be designed to specifically accommodate a large number of shards, but that's something of a specialized case.\n\n* **Data per shard.** Temporal sharding can help with constantly increasing data, while a relatively fixed index may be partitioned with primary shards to divide its data across more than one node. Generally larger shards won't scale performance as well.\n\n* **Update frequency.** Indexing uses a lot of compute (CPU) resources because Elasticsearch is essentially parsing a high number of strings. You need lots of CPU resources to index quickly. The primary concern of sharding is to maximize the amount of compute per batch of incoming documents. For relatively low update volumes, the default of one shard is fine. For higher volumes, you may have a shard per node to max out your cluster's CPU resources.\n\n* **Search features.** Some search features require a lot of compute resources. Generally these features benefit from more memory for better caching. Examples are presented in the next section.\n\n* **Memory.** Efficient use of memory helps to alleviate CPU used for searches. We generally recommend allocating memory equal to 10-30% of the total data size, but the memory required will vary by use case. It's typically a secondary concern, after CPU bottlenecks have been resolved.\n\n* **Concurrency.** A major performance bottleneck is introduced by performing a large number of simultaneous read/write operations. In this case, the limiting factor is the number and speed of your available CPU cores. For updates, it's a more efficient use of CPU resources to use a lower concurrency and update in bulk. Concurrency is better allocated towards searches to increase your throughput.\n\n\n## How Bonsai meters these resources\n\nBonsai offers two types of hosted Elasticsearch clusters. Our multitenant packages offer users performance-optimized, resource-metered, 3 node clusters at a compelling price point, while our dedicated clusters provide the maximum possible performance with no metering imposed. The following descriptions are applicable to the multitenant plans only.\n\n**Capacity.** Bonsai will also allocate a certain amount of disk space for each user. We periodically check how much space each cluster is using, and reach out to the owner if there is a problem.\n\n**Concurrency.** Maintaining a stable and performant network is of critical importance to us. For that reason, Bonsai meters on concurrent connections in real time. Concurrent connections are the number of simultaneous connections allowed at any given time. It is related to the number of requests per second.\n\nFor example, if a typical search request is completed in 10ms, then you could theoretically serve 100 requests per second. So at a limit of 5 concurrent connections, then you could theoretically serve 500 requests per second.\n\nBonsai enforces three kinds of limits: searches, updates and bulk requests, and the limits vary by plan. These limits are still in flux. If you have questions about the existing limits, send us an email.\n\n\n## Planning your cluster\n\nIn planning your cluster, you should ask yourself a few questions:\n\n1. **How many documents/objects will I need to index?** This will help you to determine how much disk capacity you will need to start out with. A good way to estimate this is to set up a local development cluster, and index a representative sample of your data, then use the [cluster stats API](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-stats.html) to get an idea of a typical document size. Multiply that by the number of documents you need to support to get an estimate of how much disk space you'll need. A good rule of thumb is to add 20% to this calculation to account for overhead and growth.\n\n2. **How often will I be writing to the cluster?** The answer to this question, along with how long a typical update request takes, will let you gauge roughly how many concurrent update connections you'll need. Keep in mind that making updates to a Lucene index can be a fairly expensive operation. Even if you don't hit a connection limit, frequent, single-document updates can degrade performance. If your app can tolerate latency between when a document is updated and when that update is visible to searches, then batching updates is a good way to reduce the performance hit.\n\n3. **How often will I be searching (reading) the cluster?** Figuring out how many concurrent search connections you need will help you select a plan. Plan to maintain some overhead above your expected peak usage to account for unexpected growth.\n\n4. **What do my queries look like?** Even if your search traffic volume is not high enough to reach a connection limit, you can easily exhaust your available memory by using \"heavy\" queries (searches that are hard on memory or CPU). In this case, you'll want to opt for a plan with a higher amount of available memory and concurrency. Some of those heavy queries involve:\n\n* Aggregations\n* Dynamic scripting\n* Geofilters\n* Deep pagination\n* Sorting\n* Inefficient filter query caching (ex: caching timestamps by second or minute, instead of hourly or daily)\n\n5. **What type of performance do I need?** It's a good idea to understand what performance metrics are most important to your application, and how they relate to Elasticsearch. For example, adding additional replicas will help with availability and performance. Additional CPU resources will provide a greater buffer during unexpected traffic spikes. Another good idea is using a queuing system like Kafka or Kinesis to mitigate performance problems caused by excessive updates.\n\n\n## Guidelines for deploying your first cluster\n\n* We default to three nodes for maintaining a production quorum, and recommend the same for users configuring a local cluster\n* Use a single shard index to help measure and project capacity requirements\n* Use three shards for a larger index (> 1 GB or more than 1MM docs to bulk import)\n* If you have a really huge index, use 15 shards to help with eventual oversharding (works well on a 3-node 5-node and 15-node cluster)\n* If you have constantly increasing data over time (analytics, social media) we strongly recommend temporal sharding","excerpt":"","slug":"capacity-planning","type":"basic","title":"Capacity Planning"}
We're commonly asked the question "What kind of plan do I need?" The answer? "It depends." There's no cookie-cutter answer that meets all needs. Planning out your cluster is a matter of identifying the resources you'll need, and matching those observations against the various plans. The biggest things to consider when planning out an Elasticsearch cluster are: * **Total data capacity.** How you're storing and analyzing your documents will influence the size. We expect a 3–5x multiple over the source data, but that highly varies. Each level of replication will also increase the total capacity required; plan to use at least one replica for basic redundancy, with another to accommodate higher traffic volumes. * **Total number of shards.** Generally keep this low, at least for "hot" indices. Each shard in Elasticsearch is internally treated as an open file handle, which can cause a bottleneck in your cluster. Some clusters can be designed to specifically accommodate a large number of shards, but that's something of a specialized case. * **Data per shard.** Temporal sharding can help with constantly increasing data, while a relatively fixed index may be partitioned with primary shards to divide its data across more than one node. Generally larger shards won't scale performance as well. * **Update frequency.** Indexing uses a lot of compute (CPU) resources because Elasticsearch is essentially parsing a high number of strings. You need lots of CPU resources to index quickly. The primary concern of sharding is to maximize the amount of compute per batch of incoming documents. For relatively low update volumes, the default of one shard is fine. For higher volumes, you may have a shard per node to max out your cluster's CPU resources. * **Search features.** Some search features require a lot of compute resources. Generally these features benefit from more memory for better caching. Examples are presented in the next section. * **Memory.** Efficient use of memory helps to alleviate CPU used for searches. We generally recommend allocating memory equal to 10-30% of the total data size, but the memory required will vary by use case. It's typically a secondary concern, after CPU bottlenecks have been resolved. * **Concurrency.** A major performance bottleneck is introduced by performing a large number of simultaneous read/write operations. In this case, the limiting factor is the number and speed of your available CPU cores. For updates, it's a more efficient use of CPU resources to use a lower concurrency and update in bulk. Concurrency is better allocated towards searches to increase your throughput. ## How Bonsai meters these resources Bonsai offers two types of hosted Elasticsearch clusters. Our multitenant packages offer users performance-optimized, resource-metered, 3 node clusters at a compelling price point, while our dedicated clusters provide the maximum possible performance with no metering imposed. The following descriptions are applicable to the multitenant plans only. **Capacity.** Bonsai will also allocate a certain amount of disk space for each user. We periodically check how much space each cluster is using, and reach out to the owner if there is a problem. **Concurrency.** Maintaining a stable and performant network is of critical importance to us. For that reason, Bonsai meters on concurrent connections in real time. Concurrent connections are the number of simultaneous connections allowed at any given time. It is related to the number of requests per second. For example, if a typical search request is completed in 10ms, then you could theoretically serve 100 requests per second. So at a limit of 5 concurrent connections, then you could theoretically serve 500 requests per second. Bonsai enforces three kinds of limits: searches, updates and bulk requests, and the limits vary by plan. These limits are still in flux. If you have questions about the existing limits, send us an email. ## Planning your cluster In planning your cluster, you should ask yourself a few questions: 1. **How many documents/objects will I need to index?** This will help you to determine how much disk capacity you will need to start out with. A good way to estimate this is to set up a local development cluster, and index a representative sample of your data, then use the [cluster stats API](http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-stats.html) to get an idea of a typical document size. Multiply that by the number of documents you need to support to get an estimate of how much disk space you'll need. A good rule of thumb is to add 20% to this calculation to account for overhead and growth. 2. **How often will I be writing to the cluster?** The answer to this question, along with how long a typical update request takes, will let you gauge roughly how many concurrent update connections you'll need. Keep in mind that making updates to a Lucene index can be a fairly expensive operation. Even if you don't hit a connection limit, frequent, single-document updates can degrade performance. If your app can tolerate latency between when a document is updated and when that update is visible to searches, then batching updates is a good way to reduce the performance hit. 3. **How often will I be searching (reading) the cluster?** Figuring out how many concurrent search connections you need will help you select a plan. Plan to maintain some overhead above your expected peak usage to account for unexpected growth. 4. **What do my queries look like?** Even if your search traffic volume is not high enough to reach a connection limit, you can easily exhaust your available memory by using "heavy" queries (searches that are hard on memory or CPU). In this case, you'll want to opt for a plan with a higher amount of available memory and concurrency. Some of those heavy queries involve: * Aggregations * Dynamic scripting * Geofilters * Deep pagination * Sorting * Inefficient filter query caching (ex: caching timestamps by second or minute, instead of hourly or daily) 5. **What type of performance do I need?** It's a good idea to understand what performance metrics are most important to your application, and how they relate to Elasticsearch. For example, adding additional replicas will help with availability and performance. Additional CPU resources will provide a greater buffer during unexpected traffic spikes. Another good idea is using a queuing system like Kafka or Kinesis to mitigate performance problems caused by excessive updates. ## Guidelines for deploying your first cluster * We default to three nodes for maintaining a production quorum, and recommend the same for users configuring a local cluster * Use a single shard index to help measure and project capacity requirements * Use three shards for a larger index (> 1 GB or more than 1MM docs to bulk import) * If you have a really huge index, use 15 shards to help with eventual oversharding (works well on a 3-node 5-node and 15-node cluster) * If you have constantly increasing data over time (analytics, social media) we strongly recommend temporal sharding