[[["易于理解","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-21。"],[],[],null,["# Spanner for non-relational workloads\n\nSpanner is a highly reliable, fully managed, database system. While\nSpanner has [evolved](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46103.pdf) to become a relational database management system,\nit has its [roots](https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf) as a non-relational, key-value storage system, and retains the\nfundamental characteristics of such a system. As such, you can use\nSpanner as a non-relational (NoSQL) database and migrate from\nother non-relational databases to Spanner. This document helps\nyou understand whether Spanner is the right fit for your\nnon-relational workloads.\n\nNoSQL databases came into use during a time when conventional relational\ndatabases lacked features to support emerging applications that required high\nscalability, availability, and compute elasticity. They did so by sacrificing\nseveral features often critical for data management such as transactions,\nconsistency, and ad-hoc queries. Spanner was built to support\nboth the demanding nature of highly available applications and functionalities\nprovided by conventional relational databases, so that customers can take\nadvantage of both sets of features.\n\nWith Spanner, you can start off with straightforward, non-relational\nstorage needs and scale your application as needed.\n\nHow Spanner meets NoSQL database criteria\n-----------------------------------------\n\nSpanner meets the following key criteria for your NoSQL\nworkloads.\n\n### Scale and performance\n\nNoSQL databases gained popularity due to their ability to scale reads and writes\nhorizontally. With Spanner, you don't need to worry about scale\nor performance being a concern. Key-value styled Spanner\ndatabases can scale horizontally to support hundreds of millions of read or write\nrequests per second and petabytes of data. Spanner's compute\ncapacity scales with the workload, maintaining a consistent, low latency profile\neven as your application scales by several orders of magnitude.\n\n### NoSQL API\n\nConventional relational databases are typically accessed using SQL, which comes\nwith a learning curve for developers unfamiliar with relational databases.\nClients for these databases also typically rely on persistent connections, and\nrequire connection pooling infrastructure to be deployed in order to scale. In\ncontrast, the Spanner API is built on top of a gRPC/HTTP2 request\nand response model that automatically handles connection failures.\nSpanner provides straightforward, language-native, and efficient\nNoSQL read-write APIs which don't require SQL knowledge. In addition,\nSpanner clients don't require any connection pooling in order to\nscale.\n\n### Fully managed\n\nA big draw of NoSQL databases has been that they are perceived to be easier to\nmanage. As a fully managed service, Spanner doesn't place any\noperational burden on customers. Spanner performs zero-downtime\nsoftware and hardware updates behind the scenes while maintaining backward\ncompatibility. The Spanner API and semantics are the same as if\nthe operations were being performed on a single machine database and don't\nrequire knowledge of Spanner's internal architecture.\nSpanner runs on deployments ranging from 1/10th of a node to tens\nof thousands of nodes, scaling automatically and responsively with a\n[managed autoscaler](/spanner/docs/managed-autoscaler).\n\n### Semi-structured data\n\nSpanner supports flexible data types like JSON and BYTES that are\nused to store semi-structured or unstructured data. Like other NoSQL databases,\nyou can use these data types to avoid specifying all your storage schema\nupfront.\n\n### Access control\n\nLike other NoSQL databases, Spanner supports [IAM based access\ncontrol](/spanner/docs/iam). Administrators can configure and administer access\ncontrol policies without storing usernames and passwords in the database.\n\nHow Spanner differs from conventional NoSQL databases\n-----------------------------------------------------\n\nSpanner provides the following advantages over conventional NoSQL\ndatabases.\n\n### Transactions\n\nAs applications grow in complexity, they often need to perform multi-row and multi-table\ntransactional operations on the database. With Spanner, you don't\nneed to migrate to a transactional datastore as your database grows because\nSpanner has full support for read-write transactions. As\nan ACID compliant database, Spanner maintains transactional\nconsistency of your database at all times, regardless of scale.\n\n### Data modeling\n\nSchema design in NoSQL databases can be unnatural due to the need to fit all\ndata into one table, and to forcibly denormalize data due to the inability to\nperform joins. With Spanner, you can specify your schema without\nresorting to a single table or denormalization. To optimize access patterns that\ntouch multiple tables, you can use [table interleaving](/spanner/docs/schema-and-data-model#create-interleaved-tables).\nYou can also perform joins across tables.\n\n### Ad hoc queries\n\nEven if you mainly use the NoSQL API, it is often still useful to run ad hoc\nqueries for debugging or analytics purposes. Spanner adheres to\nthe SQL standard query language. You can use [request prioritization](/spanner/docs/reference/rest/v1/RequestOptions)\nto isolate ad hoc low-priority traffic from online traffic or use\nSpanner [Data Boost](/spanner/docs/databoost/databoost-overview)\nto run analytical queries on compute resources completely isolated from online\ndatabase traffic.\n\n### Strongly consistent secondary indexes\n\nApplications often require secondary indexes to support low latency lookups.\nTypical NoSQL databases offer eventually consistent secondary indexes or\nplace constraints on how large an index can grow. This can complicate\napplication logic which needs to work around these constraints.\nSpanner offers strongly consistent secondary indexes at scale\nwithout any size constraints. This lets you focus on\nyour application logic and not worry about consistency issues.\n\nIs Spanner right for your NoSQL database needs?\n-----------------------------------------------\n\nSpanner is a flexible data storage system that supports both SQL\nand NoSQL use cases. While some applications start off with straightforward storage\nneeds, as they grow in complexity, they need more features typically not offered\nby NoSQL databases, such as transactions, consistent secondary indexes, and\na flexible query language. With Spanner, you aren't constrained\nby these limitations and can grow your application as needed.\n\nMost non-relational workloads are a great fit for Spanner. Not\nonly does Spanner offer a straightforward NoSQL read-write API,\nbut it's also backed by high availability, high reliability, low latency,\ncompute elasticity, and extreme scalability. Spanner lets you\nconsolidate diverse workloads onto a single flexible platform."]]
