应用配置文件可以是标准应用配置文件,也可以是 Data Boost 应用配置文件,具体取决于其使用的计算类型。标准应用配置文件使用预配的集群节点进行计算,通常用于应用服务流量。Data Boost 应用配置文件使用无服务器计算,专为高吞吐量的读取作业和查询而设计。如需详细了解 Data Boost,请参阅 Data Boost 概览。
借助 Data Boost 应用配置文件,您可以使用 Data Boost 的无服务器计算来将高吞吐量作业和查询与应用服务流量隔离。您无法使用 Data Boost 应用配置文件配置请求优先级,并且唯一可用的路由政策是单集群。如需了解详情,请参阅 Data Boost 概览。
应用配置文件更改
如果您需要更改工作负载的路由政策或请求优先级,则可以更新用于工作负载的应用配置文件。您还可以将应用配置文件从标准隔离转换为 Data Boost 隔离,或从 Data Boost 隔离转换为标准隔离。将标准应用配置文件转换为使用 Data Boost 后,系统会从应用配置文件中移除请求优先级设置以及所有非单集群路由政策。
[[["易于理解","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-08-27。"],[[["\u003cp\u003eApp profiles in Bigtable manage how instances handle requests, using either a default profile or a custom-specified profile for each application connection.\u003c/p\u003e\n"],["\u003cp\u003eThere are two types of app profiles: standard, which uses provisioned cluster nodes, and Data Boost, which uses serverless compute for high-throughput tasks.\u003c/p\u003e\n"],["\u003cp\u003eUsing a unique app profile for each workload or application component provides workload isolation by enabling different compute and routing policies.\u003c/p\u003e\n"],["\u003cp\u003eMultiple app profiles enhance observability, offering metrics per profile, which can aid in troubleshooting and optimizing performance, and in facilitating support.\u003c/p\u003e\n"],["\u003cp\u003eThe default app profile is automatically created with each instance and its routing settings depend on the number of clusters at instance creation, however, creating new ones instead of modifying it is considered best practice.\u003c/p\u003e\n"]]],[],null,["# App profiles overview\n=====================\n\nAn application profile, or *app profile*, stores settings that tell your\nBigtable instance how to handle incoming requests from an application.\nWhen your application connects to a Bigtable instance, it uses\neither the default app profile or an app profile specified by you.\nBigtable uses that app profile for requests that the application\nsends over that connection.\n\nAn app profile is either a standard app profile or a Data Boost app profile,\ndepending on the type of compute it uses. A *standard app profile* uses\nprovisioned cluster nodes for compute and is typically used for\napplication-serving traffic. A *Data Boost app profile* uses serverless\ncompute, which is designed for high-throughput read jobs and queries. For more\ninformation about Data Boost, read the [Data Boost\noverview](/bigtable/docs/data-boost-overview).\n\nThis page describes app profiles and provides guidance on using them.\n\nFor code samples showing how to use an app profile in your application, see\n[Connect with a custom app\nprofile](/bigtable/docs/configuring-app-profiles#connecting).\n\nUse a separate app profile for each workload\n--------------------------------------------\n\nWhen you create a Bigtable instance, a [default app\nprofile](#default-app-profile) is created automatically, and its settings depend\non the number of clusters the instance has. To take full advantage of the\nbenefits of app profiles, you should create and use additional app profiles and\nuse a different app profile for each application or workload.\n\nApp profiles are especially important for instances that have two or more\nclusters, but even if your instance has only one cluster, you should use a\nunique app profile for each application that you run, or for different\ncomponents within a single application.\n\nThe following sections describe the benefits of creating and using multiple app\nprofiles.\n\n### Workload isolation\n\nUsing separate app profiles lets you use different Bigtable\ncompute and routing policies for different purposes. For example, consider a\nsituation when you want to prevent a batch read job (workload A) from increasing\nCPU usage on clusters that handle an application's steady reads and writes\n(workload B). You can take one of the following approaches:\n\n- Create a standard app profile for workload B that routes to a cluster group\n that excludes one cluster. Then you create a separate standard app profile\n for workload A that specifies single-cluster routing to the cluster that\n workload B doesn't send requests to.\n\n- Use a standard app profile, which uses cluster nodes for compute, configured\n to route to any cluster for workload B, and create a Data Boost app\n profile for use against a single cluster with workload A. Data Boost\n uses serverless compute, while the application traffic uses cluster nodes\n for compute.\n\nYou can change the settings for one application or function without affecting\nother applications that connect to the same data.\n\n### Observability\n\nUsing separate app profiles for different workloads gives you better insight\ninto your applications' usage of Bigtable, because metrics are\navailable per app profile. This increase in observability can be helpful in the\nfollowing ways:\n\n- You're able to look at latency at the app profile level to help you\n determine which application might be impacting overall performance.\n\n- Monitoring the [CPU utilization per app\n profile](/bigtable/docs/monitoring-instance#cpu) for a workload using a standard\n app profile can help you troubleshoot CPU utilization issues or make decisions about the size or\n location of the cluster, so you can optimize usage and reduce costs.\n\n- Metrics at the app profile level are useful if you need to\n [seek support](/bigtable/docs/support/getting-support), because you're better\n able to share the exact workload that is causing an issue.\n\nYou can use the Bigtable Google Cloud console to view separate graphs\nof your Bigtable metrics for each app profile. To learn which\nmetrics that are available at the profile level, see the table\nat [System insights charts for Bigtable\nresources](/bigtable/docs/monitoring-instance#console-monitoring-resources).\n\nStandard app profiles\n---------------------\n\nA standard app profile routes traffic to an instance's clusters using the\nclusters' nodes.\n\n### Routing\n\nA standard app profile defines the [routing\npolicy](/bigtable/docs/routing) that\nBigtable uses and controls whether [single-row\ntransactions](/bigtable/docs/routing#single-row-transactions) are allowed. A standard app\nprofile also lets you specify the [priority\nlevel](/bigtable/docs/request-priorities) for requests sent using the app\nprofile.\n\n### Request priority\n\nYou can specify the priority that Bigtable should give to a standard\napp profile's data requests. To review the priority levels that are available, see\n[Configure request priorities](/bigtable/docs/request-priorities).\n\nData Boost app profiles\n-----------------------\n\nA Data Boost app profile lets you use Data Boost's serverless compute to\nisolate high-throughput jobs and queries from app serving traffic. A\nData Boost app profile doesn't let you configure request priority, and the\nonly routing policy available is single-cluster. For more information, see the\n[Data Boost\noverview](/bigtable/docs/data-boost-overview).\n\nApp profile changes\n-------------------\n\nIf you need to change the routing policy or request priority for a workload, you\ncan update the app profile that is used for the workload. You can also convert\nan app profile from standard to Data Boost isolation or from Data Boost\nto standard isolation. Converting a standard app profile to use Data Boost\nremoves the request priority settings from the app profile as well as any\nrouting policies that aren't single-cluster.\n\nChanges to an app profile are effective immediately.\n\nHowever, in many cases, instead of modifying an app profile that is in use, you\nshould create a new app profile with a different configuration, like you would\nfor a new use case, and then change your application code to use the new app\nprofile. Creating a new app profile to make changes for a workload\nensures that you don't inadvertently change the app profile for any other\nworkloads that use the app profile.\n\nIf you change an app profile from standard to Data Boost, the type of\ncompute that is used for the app profile's traffic is changed to serverless, along with\npricing. For more information, see the [Data Boost\noverview](/bigtable/docs/data-boost-overview) and [Bigtable\npricing](/bigtable/pricing).\n\nSimilarly, if you change an app profile from Data Boost to standard, traffic\nthat is sent by the app profile starts using cluster nodes for compute. This\nmeans that all clusters that the app profile routes to must have enough nodes to\nsatisfy CPU usage requirements. For more\ninformation, see [Nodes](/bigtable/docs/instances-clusters-nodes#nodes).\n\nTo see how to view, create, and update app profiles, see [Create and\nconfigure app profiles](/bigtable/docs/configuring-app-profiles).\n\nDefault app profile\n-------------------\n\nWhen you create an instance, Bigtable automatically creates a\ndefault app profile for the instance. The default app profile is a standard app\nprofile, but you can convert it to a Data Boost profile. If your application\ndoes not specify an app profile, or if you use the HBase shell to connect to\nyour instance, Bigtable uses the settings in the default app\nprofile.\n\nThe settings in an instance's default app profile depend on the number of\nclusters the instance had when you first created it:\n\n- If you created the instance with 1 cluster, the `default` app profile uses [single-cluster routing](/bigtable/docs/routing#single-cluster), and it enables [single-row\n transactions](/bigtable/docs/routing#single-row-transactions). This ensures that adding additional clusters later doesn't change the behavior of your existing applications.\n- If you created the instance with 2 or more clusters, the `default` app profile uses [multi-cluster routing](/bigtable/docs/routing#multi-cluster) to any cluster. Single-row transactions are never allowed with multi-cluster routing.\n\nThe default app profile does not change when you add or remove clusters.\nYou must manually [update the default app profile](/bigtable/docs/configuring-app-profiles#updating-app-profile) to\nchange its settings. However, as a best practice you should **create and use a\nnew app profile** instead of changing the default app profile.\n\nCustom app profiles\n-------------------\n\nA *custom app profile* is an app profile that you create and configure. An\ninstance can have up to 2,000 app profiles.\nEvery app profile that is not the default is considered a custom app profile.\n\nWhat's next\n-----------\n\n- [Monitor a standard app profile's CPU usage.](/bigtable/docs/monitoring-instance#cpu)\n- [Find the right replication settings for your use case](/bigtable/docs/replication-settings).\n- [Create and manage app profiles for your instance](/bigtable/docs/configuring-app-profiles)."]]