[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[[["\u003cp\u003eScaling a Bigtable cluster involves adding or removing nodes to adjust to workload or storage needs, with autoscaling generally being the preferred method.\u003c/p\u003e\n"],["\u003cp\u003eBigtable offers a 2x node scaling factor option, which combines two standard nodes into a single compute node, enhancing throughput and stability, although it may increase costs for smaller workloads.\u003c/p\u003e\n"],["\u003cp\u003eScaling can be done manually or via autoscaling, and adding nodes before workload increases can help mitigate the up to 20 minute rebalancing delay and latency issues.\u003c/p\u003e\n"],["\u003cp\u003eRapidly decreasing nodes in a cluster by more than 10% in a 10-minute period may cause increased latency, therefore it is advised to scale down gradually.\u003c/p\u003e\n"],["\u003cp\u003e2x node scaling has specific limitations, including the inability to convert an existing cluster, not being supported for HDD clusters, and not being available in certain zones.\u003c/p\u003e\n"]]],[],null,["Scaling\n\n*Scaling* a cluster is the process of adding or removing nodes from a cluster in\nresponse to changes in the cluster's workload or data storage needs.\n\nYou can scale a Bigtable cluster in the following ways:\n\n- [Autoscaling](/bigtable/docs/autoscaling)\n- Manual node allocation\n\n**In most cases, choose autoscaling.** When you enable autoscaling for a\ncluster, Bigtable continuously monitors the cluster and\nautomatically adjusts the number of nodes based on your settings.\n\nYou can scale your Bigtable cluster based on metrics such as\nthe cluster's CPU usage. For example, if your cluster is under heavy load and\nits CPU utilization is high, you can add nodes to the cluster until its CPU\nusage drops. You can also save money by removing nodes from the cluster when it\nis not being used heavily.\n\nNode scaling factor\n\nWhen you create a Bigtable cluster, you have the option to\nconfigure the cluster with a **2x node scaling factor**. When you choose this\nconfiguration, Bigtable treats two standard nodes as a larger,\nsingle compute node, and the cluster is always scaled in increments of two\nnodes. As a result, there are fewer compute boundaries between nodes in the\ncluster. Depending on the workload, the benefits of 2x node scaling include the\nfollowing:\n\n- Improved throughput and tail latency stability\n- Greater ability to absorb hotspots\n\nYou can create a cluster with 2x node scaling factor enabled when you use the\nGoogle Cloud console or the gcloud CLI.\n\nYou can configure 2x node scaling with autoscaling or manual node\nallocation.\n\nFor limitations, see [Node scaling factor\nlimitations](#node-scaling-limitations).\n\nSmall clusters\n\n2x node scaling is optimal for larger workloads. If you are considering changing\nfrom standard node scaling (by a factor of one) to 2x node scaling, consider the\ncost implications. For a smaller workload, such as one that runs on a cluster\nwith one node, using 2x node scaling costs twice as much. Similarly, using 2x\nnode scaling for a workload that previously was run on a cluster with 3 nodes\nincreases costs by 33%.\n\nOn the other hand, for a workload that previously ran on a large cluster, such\nas a cluster with 50 nodes, the effect of a 2x node scaling factor is small\nrelative to the number of nodes.\n\nBigtable returns an error if you try to create a cluster with\n2x node scaling factor in an unsupported zone.\n\nLimitations\n\nCluster scaling is subject to node availability, takes time to complete, can't\ncompensate for an inappropriate schema design, and must be done gradually. The\nfollowing sections describe these limitations, as well as limitations that\napply to 2x node scaling.\n\nNode availability\n\nNode quotas apply whether a cluster has manual node allocation or autoscaling\nenabled. See [Quotas and node availability](/bigtable/quotas#availability) for details.\n\nDelay while nodes rebalance\n\nAfter you add nodes to a cluster, it can take up to 20 minutes under load before\nyou see a significant improvement in the cluster's performance. As a result, if\nyour workload involves short bursts of high activity, adding nodes to your\ncluster based on CPU load doesn't improve performance --- by the time\nBigtable rebalances your data, the short burst of activity will be\nover.\n\nTo plan for this delay, you can add nodes to your cluster, either\nprogrammatically or through the Google Cloud console, *before* you\nincrease the load on the cluster. This approach gives Bigtable\ntime to rebalance your data across the additional nodes before the workload\nincreases. On clusters that use manual node allocation, change the number of\nnodes. On clusters that use autoscaling, change the [minimum number of\nnodes](/bigtable/docs/autoscaling#parameters). After your traffic returns to normal, change\nyour node settings back.\n\nLatency increases caused by scaling down too quickly\n\nWhen you decrease the number of nodes in a cluster to scale down, try not to\nreduce the cluster size by more than 10% in a 10-minute period. Scaling down too\nquickly can cause performance problems, such as increased latency, if the\nremaining nodes in the cluster become temporarily overwhelmed.\n\nSchema design issues\n\nIf there are problems with the schema design for your table, adding nodes to\nyour Bigtable cluster may not improve performance. For example, if\nyou have a large number of reads or writes to a single row in your table, all of\nthe reads or writes will go to the same node in your cluster; as a result,\nadding nodes doesn't improve performance. In contrast, if reads and writes are\nevenly distributed across rows in your table, adding nodes will generally\nimprove performance.\n\nSee [Designing Your Schema](/bigtable/docs/schema-design) for details about how to design a\nschema that lets Bigtable scale effectively.\n\nNode scaling factor limitations\n\nYou can't convert a cluster with standard node scaling to use 2x node scaling;\nyou must create a new cluster and enable 2x node scaling at creation time. For\nmore information on adding a cluster to an instance, see [Modify an\ninstance](/bigtable/docs/modifying-instance).\n\nYou can't configure 2x node scaling for an HDD cluster.\n\nYou can create clusters configured with 2x node scaling in every\nBigtable region, but not in every zone. The following zones can't\ncontain a cluster with 2x node scaling:\n\n- asia-south1-c\n- europe-central2-c\n- me-central2-b\n- me-central2-c\n- northamerica-northeast1-a\n- northamerica-northeast1-b\n- southamerica-east1-c\n- us-south1-b\n- us-south1-c\n\nWhat's next\n\n- Learn about [Bigtable autoscaling](/bigtable/docs/autoscaling).\n- Find out how you can [monitor your instance](/bigtable/docs/monitoring-instance), both programmatically and through the Google Cloud console."]]