A database model is the underlying blueprint a database follows: what shape a piece of data takes, where it physically lives, and which operations are fast versus slow. Pick the wrong blueprint for the job and every query built on top of it fights the structure instead of working with it.

数据库模型是数据库所遵循的底层蓝图:一条数据呈现什么形状、它实际存放在哪里,以及哪些操作快、哪些慢。为某项工作选错了蓝图,建立在其上的每一条查询都会与结构相抗衡,而不是顺应结构工作。

Notice the Structural / Hosting / Storage location tags above. These four models are not four points on the same scale, they answer different questions about a database. NoSQL and spatial are about the SHAPE of the data. In-memory is about WHERE the bytes physically sit. Cloud is about WHO runs the servers. A single real system can combine more than one, a spatial database can run in the cloud, an in-memory database can also be a NoSQL key-value store. The mistake callout further down this page is built entirely around this point.

请注意上方的结构 / 托管方式 / 存储位置标签。这四种模型并不是同一条量表上的四个刻度,它们回答的是关于数据库的不同问题。NoSQL 和空间数据库关乎数据的形状。内存数据库关乎字节实际存放在哪里。云数据库关乎谁来运行服务器。一个真实系统完全可以同时结合多种模型:空间数据库可以运行在云端,内存数据库也可以同时是一个 NoSQL 键值存储。本页下方的常见错误提示正是完全围绕这一点展开的。

Spatial databases exist because "where is this relative to that" is a genuinely different kind of question from anything a normal WHERE clause answers. A regular database can compare two numbers instantly, but has no built-in idea of distance, overlap or containment between two shapes, so a spatial database adds its own data types (a point, a line, a polygon, even a 3D shape) and its own indexes and functions purpose-built for exactly those geometric questions. PostGIS and Oracle Spatial are real examples, and GIS, mapping and location-based services are what actually needs this. The cost is that this expertise does not transfer from ordinary SQL, someone on the team has to know it specifically.

空间数据库之所以存在,是因为"这个相对于那个位置在哪里"这类问题,与普通 WHERE 子句能回答的任何问题都截然不同。普通数据库可以瞬间比较两个数字,但对两个形状之间的距离、重叠或包含关系没有内置的概念,因此空间数据库增加了自己的数据类型(点、线、多边形,甚至三维形状)以及专门为这些几何问题而设计的索引和函数。PostGIS 和 Oracle Spatial 就是真实的例子,而地理信息系统(GIS)、地图绘制与基于位置的服务正是真正需要这项能力的领域。代价在于,这项专业知识无法从普通 SQL 中直接迁移过来,团队中必须有人专门掌握它。

In-memory databases skip the disk entirely and keep every byte in RAM, which sounds like a small implementation detail but changes everything about how fast the database feels: reading and writing RAM is orders of magnitude quicker than reading and writing even a fast disk. Redis and Oracle TimesTen are real examples of this. It suits any job where a disk-backed database's extra milliseconds per operation would actually be felt: holding a shopping session while a customer browses, serving a leaderboard that changes every few seconds, or sitting in front of a slower database as a cache.

内存数据库完全跳过磁盘,将每一个字节都保存在内存(RAM)中。这听起来像是一个微小的实现细节,却彻底改变了数据库的响应速度:读写内存的速度比读写即便是高速磁盘也要快上几个数量级。Redis 和 Oracle TimesTen 就是真实的例子。它适用于任何一种基于磁盘的数据库多出的那几毫秒延迟会被真切感受到的场景:在顾客浏览时保存购物会话、为每隔几秒就变化一次的排行榜提供数据,或是作为缓存层置于速度较慢的数据库前面。