Skip to content

Commit

Permalink
Apply suggestions from code review
Browse files Browse the repository at this point in the history
Co-authored-by: Mike Lewis <[email protected]>
  • Loading branch information
mdlinville and mikeCRL authored Sep 25, 2024
1 parent 160643f commit 9a82e65
Showing 1 changed file with 12 additions and 12 deletions.
24 changes: 12 additions & 12 deletions src/current/cockroachcloud/plan-your-cluster.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ This page provides guidance for planning and estimating costs for a CockroachDB

The compute resources available to a CockroachDB {{ site.data.products.standard }} cluster is provisioned and scaled using a capacity model measured in _virtual CPUs (vCPUs)_. A cluster's capacity requirements depend on the scale and query profile of the cluster's workload, and may change over time as the workload evolves. It’s typical to estimate the initial compute capacity needed for a workload before creating the cluster, and to adjust the capacity up or down based observation of the workload's consumption.

Storage for a CockroachDB {{ site.data.products.standard }} cluster is allocated on demand and is not covered in this section. Refer to [Storage](#storage-pricing)
Storage for a CockroachDB {{ site.data.products.standard }} cluster is allocated on demand and is not covered in this section. Refer to [Storage](#storage-pricing).

### Quickstart: Provision and adjust capacity

Expand All @@ -27,11 +27,11 @@ To achieve a rough initial estimate of compute capacity, consider:

- **Additional capacity buffer**: To accommodate unanticipated load and mitigate the risk of application degradation if the cluster's capacity is exceeded, we recommend that you plan for additional capacity beyond your initial estimate. A 40% buffer is a good starting point, but more may be needed if the workload is unpredictable or highly sensitive to query latency. Depending on the nature of the workload, such as when demand is seasonal, you can plan to scale the cluster's capacity temporarily to address the workload's requirements.
- **Exceeding capacity limit**: CockroachDB {{ site.data.products.standard }} enforces the cluster's provisioned capacity, limiting application throughput if the workload exceeds the cluster's provisioned capacity. This can lead to increased query latency and degraded application performance.
- **Notifications to prevent overrun**: To help mitigate against the risk of exceeding a cluster's capacity, email and CockroachDB {{ site.data.products.cloud }} Console notifications will occur when a cluster workload exceeds 90% and 90% of its provisioned capacity.
- **Notifications to prevent overrun**: To help mitigate against the risk of exceeding a cluster's capacity, email and CockroachDB {{ site.data.products.cloud }} Console notifications will occur when a cluster workload exceeds 70% and 90% of its provisioned capacity.

- **Multi-region deployments**: The provisioned capacity of your cluster applies to the entire cluster, regardless of the number of nodes or regional topography. The provisioned capacity is effectively a budget for the cluster that can be used by a node in any region to meet its compute demand. This simplifies planning compute capacity for multi-region deployments. The overall [compute capacity cost]({% link cockroachcloud/billing-management.md %}) for a multi-region CockroachDB {{ site.data.products.standard }} cluster is calculated based on the price of the most expensive region in the cluster.

After considering the above factors, you have enough information to [create a CockroachDB {{ site.data.products.standard }} cluster]({% link cockroachcloud/create-your-cluster.md %}) using the CockroachDB {{ site.data.products.cloud }} Console or the [CockroachDB Terraform provider]({% link cockroachcloud/provision-a-cluster-with-terraform.md %}). After the cluster is deployed, you can [scale its compute capacity]({% link cockroachcloud/cluster-management.md %}#edit-cluster-capacity) by increasing or decreasing its provisioned capacity as needed.
After considering the above factors, you have enough information to [create a CockroachDB {{ site.data.products.standard }} cluster]({% link cockroachcloud/create-your-cluster.md %}) using the CockroachDB {{ site.data.products.cloud }} Console, the [CockroachDB Terraform provider]({% link cockroachcloud/provision-a-cluster-with-terraform.md %}), or the [CockroachDB Cloud API](cloud-api.md). After the cluster is deployed, you can [scale its compute capacity]({% link cockroachcloud/cluster-management.md %}#edit-cluster-capacity) by increasing or decreasing its provisioned capacity as needed.

{{site.data.alerts.callout_success}}
You can decrease the provisioned capacity only three times within a 7-day period. You can increase the provisioned capacity at any time.
Expand All @@ -43,7 +43,7 @@ The CockroachDB {{ site.data.products.cloud }} Console provides insight into you

Important capacity and pricing policies mentioned elsewhere are summarized here:

- **Minimum and maximum provisioned capacity**: - A CockroachDB {{ site.data.products.standard }} cluster must have a provisioned capacity of at minimum 2 vCPUs. For production workloads, we recommend at minimum 4 to 8 vCPUs. The maximum capacity for CockroachDB {{ site.data.products.standard }} is 60 vCPUs. To express interest in higher-capacity clusters, [talk to an expert](https://www.cockroachlabs.com/contact/).
- **Minimum and maximum provisioned capacity**: A CockroachDB {{ site.data.products.standard }} cluster must have a provisioned capacity of at minimum 2 vCPUs. For production workloads, we recommend at minimum 4 to 8 vCPUs. The maximum capacity for CockroachDB {{ site.data.products.standard }} is 60 vCPUs. To express interest in higher-capacity clusters, [talk to an expert](https://www.cockroachlabs.com/contact/).

- **Enforcing provisioned capacity limits**: CockroachDB {{ site.data.products.cloud }} enforces the cluster’s provisioned capacity, limiting application throughput if the workload exceeds the capacity limit. This can result in degraded performance and increased query latency. You can increase a cluster's capacity at any time.

Expand All @@ -60,12 +60,12 @@ We recommend that you start with [Quickstart: Provision and adjust capacity](#qu
- **Smaller workloads**: CockroachDB {{ site.data.products.standard }} is well suited for workloads that require 12 or fewer vCPUs. By contrast, 12 vCPUs (3 nodes x 4 vCPUs) is the minimum configuration for CockroachDB {{ site.data.products.advanced }}.

CockroachDB {{ site.data.products.standard }} is not recommended for:
- Analytical workloads that involve a large quantity of large, complex reads
- OLAP or hybrid OLTP/OLAP applications
- **Analytical workloads that involve many large, complex reads**
- **OLAP or hybrid OLTP/OLAP applications**

- **Asymmetric multi-region workloads**: Often, multi-region deployments are asymmetric in terms of CPU utilization across regions. For example, in a three-region cluster, two of the three regions may require more capacity than the third, or vice versa. In CockroachDB {{ site.data.products.standard }}, a cluster's compute capacity is available in all regions.

For workloads that require symmetric capacity per region or where a given region must maintain a given compute capacity, CockroachDB {{ site.data.products.advanced }} may be a better option.
For workloads that require asymmetric capacity per region or where a given region must maintain a given compute capacity, CockroachDB {{ site.data.products.advanced }} may be a better option.

- **Workloads that are sensitive to latency**: CockroachDB {{ site.data.products.standard }} clusters use a different networking architecture than CockroachDB {{ site.data.products.advanced }}. This architecture can introduce additional query latency of around 1 microsecond when compared with CockroachDB {{ site.data.products.advanced }}.

Expand All @@ -76,23 +76,23 @@ For more details to help you compare CockroachDB {{ site.data.products.cloud }}
## Storage pricing

Storage capacity for a CockroachDB {{ site.data.products.standard }} cluster is [priced]({% link cockroachcloud/billing-management.md %}) on demand in units of GiB-month. Storage prices vary across providers and [regions]({% link cockroachcloud/regions.md %}). Storage is charged based on the logical amount of data in the database.
- **3 replicas included**: - CockroachDB {{ site.data.products.standard }} maintains at minimum three replicas of your data at no additional cost.
- **3 replicas included**: CockroachDB {{ site.data.products.standard }} maintains at minimum three replicas of your data at no additional cost.

For a cluster with more than three replicas, storage for each additional replica is priced at the storage price for the region.
For a cluster with more than three replicas, storage for each additional replica is priced at the storage price for the region.

- **Multi-region storage**: In a multi-region cluster, storage prices vary by region. The data in each region is priced at that region's storage rate.
- **Multi-region storage**: In a multi-region cluster, storage prices vary by region. The data in each region is priced at that region's storage rate.

### Single-region example

By default, CockroachDB {{ site.data.products.cloud }} maintains three replicas for a single-region cluster, spread across three different availability zones within the region. You are not charged to store these replicas.

For example, if a single-region cluster is deployed in `us-central-1` and contains 500 GiB of data. CockroachDB {{ site.data.products.cloud }} stores three replicas, for a total of 1500 GiB of data. However, you are billed only for 500 GiB of storage.

If you add a fourth replicas, the cluster consumes 2000 GiB of storage (500 x 4), but you are billed only for 1000 GiB (500 for the data and 500 for the fourth replica).
If you add a fourth replica, the cluster consumes 2000 GiB of storage (500 x 4), but you are billed only for 1000 GiB (500 for the data and 500 for the fourth replica).

### Multi-region example

For multi-region clusters, we recommend 5 or more replicas are typically maintained across availability zones and regions for resilience against both zone and region failure. The first three replicas are included in the base storage price, while additional replicas are priced based on the ratio of additional regions to the initial three.
For multi-region clusters, we recommend that 5 or more replicas are maintained across availability zones and regions for resilience against both zone and region failure. The first three replicas are included in the base storage price, while additional replicas are priced based on the ratio of additional regions to the initial three.

Consider the example of a three-region cluster with 500 GiB of logical data, deployed in `us-central1`, `us-west2`, and `europe-west1`, with 5 replicas. The logical data and the first three replicas are included in the monthly storage cost. The additional two replicas are charged at 2/3 of the monthly storage cost. This cluster consumes 2500 GiB of storage, but is billed for 1500 GiB for the initial data and 3 replicas, plus 2/3 of the additional 1000 GiB for the additional two replicas (2 replicas beyond the initial 3).

Expand Down

0 comments on commit 9a82e65

Please sign in to comment.