應用程式設定檔分為標準應用程式設定檔和 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"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[[["\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)."]]