何时考虑多区域数据库

[liza89]

如果您的大多数用户都在读取数据并且他们分布在全球各地，那么多区域数据库可以提供帮助。

该图显示了从主数据库到跨不同区域的多个分布式数据库的全局数据复制，以提高性能和可用性。

这会跨区域复制您的数据，因此欧洲、亚洲或澳大利亚的用户可以从最近的副本读取数据。这可以改善延迟并减少单个数据库节点的负载。

像 AWS 这样的云提供商提供了多区域功能，例如DynamoDB Global Tables和Aurora Global，但像 CockroachDB 这样的专用数据库也可以轻松地跨区域复制数据以获得更好的性能。

在以下情况下，分布式数据库是一个很好的选择：

读取次数远远超过写入次数
轻微的陈旧（最终一致性）是可以接受的
您希望减少全球往返
但如果出现以下情况，请暂缓：

您的应用需要严格的一致性（例如金融交易）
您在许多区域都有频繁写入
您需要精确控制版本冲突
关注你的查询
即使您进行了缓存和共置，错误的查询仍然会成为性能的瓶颈。

尽早设置监控以跟踪百分位延迟：

p50 = 平均查询时间
p75 = 查询速度较慢，通常 韩国电话号码列表 在轻负载下
p99 = 最坏情况的查询，通常隐藏着性能问题
例如，30ms 的 p50 很好 - 但如果您的 p99 为 700ms，一些用户仍然会感受到痛苦的延迟。

在识别性能瓶颈时，还需寻找：

N+1 查询模式
过滤字段缺少索引
过度获取嵌套数据
只需改进几个繁重的查询，就能将整体延迟减半。Prisma Optimize等工具可以识别边缘和无服务器函数中最慢的查询，找出根本原因，并提出可行的修复建议，从而简化这一过程。

Prisma Optimize 仪表板的动画演示显示查询延迟、请求率和缓存命中率等指标，以监控和优化数据库性能。

快速回顾
下面简要介绍一下这些问题及其解决方法。

问题 修复它
长时间数据库往返 与数据库共置计算
连接过多 添加连接池
重复读取 边缘缓存
全局延迟 考虑多区域数据库
慢查询 使用 Prisma Optimize 或 Datadog 等监控工具
最后的想法
交付到边缘很容易。但要让你的应用感觉起来快速——尤其是在全球范围内——则需要多加思考。

好消息？您无需重建堆栈。只需进行一些小的更改（缓存、主机托管、池化和监控），就能带来巨大的改变。

下次你的边缘函数开始感觉速度变慢时，很少是因为计算。十有八九是数据库的问题。数据库通常是速度变慢的起点，也是速度提升的关键所在。

让我们继续对话
如果这对您有帮助，我们很乐意听取您的意见。请在 X 上标记我们，分享您正在构建的内容。或者，如果您想聊天、排查问题或深入探讨数据库和性能，欢迎加入我们的 Discord 。

我们还会定期在 YouTube 上发布深度视频。如果您感兴趣，请点击订阅。更多示例、更多性能技巧，或许还会有一些惊喜发布。我们不见不散。