[[["容易理解","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-05 (世界標準時間)。"],[[["\u003cp\u003eMultitenancy in applications is supported by creating separate data partitions for each client organization (tenant), allowing for custom data values while maintaining a uniform data schema across all tenants.\u003c/p\u003e\n"],["\u003cp\u003eDatastore mode facilitates multitenancy through the use of namespaces, where each namespace, combined with a project ID, forms a partition ID, isolating each tenant's data.\u003c/p\u003e\n"],["\u003cp\u003eEntities in Datastore mode are confined to a single partition, and queries are restricted to that same partition, with all entities and their ancestors within a hierarchical structure sharing the same namespace.\u003c/p\u003e\n"],["\u003cp\u003eApplications must process entities of the same kind consistently across different namespaces to be considered multitenant, which means using a single schema and behavior for a given entity type.\u003c/p\u003e\n"],["\u003cp\u003eThe namespace assigned to an entity cannot be changed once the entity has been created, and entities without a specified namespace are automatically assigned to the default namespace.\u003c/p\u003e\n"]]],[],null,["# Multitenancy\n\nYou can support *multitenancy* in your application by providing separate data\npartitions for multiple client organizations, known as tenants. This allows you\nto customize *data values* for each tenant, while keeping the same *data schema*\nfor all tenants. This makes provisioning new tenants more efficient because\nyou don't have to change data structure when you add a tenant.\n\nBenefits of multitenancy\n------------------------\n\nFirestore in Datastore mode allows a multitenant application to use separated silos of data\nfor each tenant while still using:\n\n- a single project\n- a single logical structure for the kinds\n- a single set of index definitions, because the kinds are the same logically for each tenant\n\nDatastore mode enables multitenancy by providing *namespaces*.\n\nMultitenancy and partitioned data\n---------------------------------\n\nDatastore mode uses *partitions* to silo data for each tenant. The\ncombination of a project ID and a namespace ID forms a *partition ID*, which\nidentifies each partition. An entity belongs to a single partition, and queries\nare scoped to a single partition.\n| **Note:** Namespaces are not a security mechanism in Datastore mode. A user with access to one partition in a project has access to all partitions in the project. Namespaces provide a way to organize your entities within a project.\n\nSpecifying a namespace for an entity\n------------------------------------\n\nYou specify the namespace when you create the entity: after you create the entity,\nyou cannot change the namespace. If you don't explicitly specify a namespace for\nan entity, it is automatically assigned to the *default namespace*, which has\nno string identifier.\n\nUsing namespaces with parent entities\n-------------------------------------\n\nAn entity and all of its ancestors belong to one and only one namespace. This\nmeans that when you create an entity with another entity designated as parent,\nthe child entity is in the same namespace as its parent: you cannot specify\nsome other namespace.\n\nSample use case\n---------------\n\nA key benefit of multitenancy is having the same application serve multiple\nclient organizations. To achieve this benefit, for a given kind, your\napplication should behave the same regardless of the namespace. For example,\nfrom the application's perspective, an entity of kind `Task` in one namespace\nshould logically be the same as an entity of kind `Task` in all other\nnamespaces. Your application could then use a single set of index definitions\nto support `Task` queries, regardless of which namespaces contain `Task`\nentities.\n\nFor example, consider a Task List application that silos data on a per user\nbasis. The application could define namespaces based on user name, resulting in\nthe following partitions: \n\n```\nPartition ID: project:\"my_project_id\"/namespace:\"Joe\"\nPartition ID: project:\"my_project_id\"/namespace:\"Alice\"\nPartition ID: project:\"my_project_id\"/namespace:\"Charlie\"\n```\n\nThe application could define a logical structure of a `Task` kind as follows, to\nuse for all namespaces: \n\n```\nkind: Task\nproperties:\n - \"done\", Boolean\n - \"created\", DateTime\n - \"description\", String, excluded from index\n```\n\nWhen a user creates an entity of kind `Task`, the entity is stored in the user's\nown partition, resulting in siloed data. The application processes `Task`\nentities consistently across namespaces because only one schema is used for the\n`Task` kind. An application with siloed data and consistent behaviour would be\nmultitenant.\n\nIf the logical structure of a `Task` kind differs by namespace, the application\nwould not be multitenant because it processes `Task` entities differently\nacross namespaces. For example, consider `Task` kinds that have different schema\nbased on namespace:\n\n- `Task` entities in the Joe namespace *exclude* the `description` property from the index\n- `Task` entities in the Alice namespace *include* the `description` property from the index\n\nThe application could query on the `description` property for Alice's `Task`\nentities, but it could not query on the `description` property for Joe's `Task`\nentities, so the application would not be multitenant.\n\nViewing namespaces in the console\n---------------------------------\n\nTo see statistics for the namespaces used in your project, visit the\n[Datastore Dashboard](https://console.cloud.google.com/datastore/stats) page in\nthe Google Cloud console. To programmatically determine which namespaces are used\nin your project, see [Namespace queries](/datastore/docs/concepts/metadataqueries#namespace_queries).\n\nIf you need to group data *within* a tenant, you can categorize your data by\n[kinds](/datastore/docs/concepts/entities#kinds_and_identifiers), and you can also organize highly related data with\n[entity groups](/datastore/docs/concepts/entities#entity_groups).\n\nWhat's next\n-----------\n\n- Learn about [entities](/datastore/docs/concepts/entities).\n- Learn about [queries](/datastore/docs/concepts/queries)."]]
