Google Cloud Datastore能否支撑每秒100万次写入的高吞吐应用？专用OLTP库更优？

先给你拍板：Google Cloud Datastore完全扛不住每秒100万次写入的高吞吐量需求，专用OLTP数据库才是这个场景的正确打开方式。下面给你拆解原因：

一、Datastore的硬限制根本达不到百万级写入 #

咱们先掰扯清楚Datastore的核心瓶颈：

• 实体组写入天花板：哪怕是用最终一致性写入，单个实体组的极限也就每秒几十到上百次（强一致性写入更是每秒仅1次）。要凑够100万次写入，得拆出几万甚至十几万个实体组，这不仅架构复杂度爆炸，Datastore的全局写入配额、并发连接数也顶不住这种级别的压力。
• 批量请求的上限：Datastore的批量写入请求最多包含500个操作，就算把请求塞满，要达到100万次写入，每秒得发2000个批量请求——这还没算网络延迟、请求排队的损耗，实际中Datastore的后端根本撑不住这么高的并发批量请求。
• 配额的天花板：Datastore的写入配额虽然可以申请调高，但百万级每秒的写入已经远远超出了它的设计目标，官方也不会批这么夸张的配额。

二、专用OLTP数据库才是为这种场景量身定做的 #

像PostgreSQL（带分片扩展）、MySQL（高性能集群）、CockroachDB这类专用OLTP数据库，天生就是为高吞吐量事务型写入设计的：

• 线性水平扩展：通过数据分片、读写分离，可以随着集群规模扩大线性提升写入能力，百万级每秒写入只要集群配置到位就能稳定扛住。
• 高频事务优化：针对小批量、高并发的事务做了大量底层优化——比如内存池复用、事务日志高效刷盘、精细化并发控制，能高效处理海量并行写入请求。
• 灵活的一致性选项：既支持强一致性事务，也能根据场景调整为最终一致性，兼顾性能和数据可靠性。

三、有没有折中方案？ #

如果你的写入是无事务、弱一致性、可容忍少量丢失的日志类数据，或许可以试试Datastore配合消息队列做缓冲：先把写入请求发到队列，再用后台服务异步写入Datastore。但就算这样，Datastore的写入能力还是跟不上100万每秒的输入，最终还是会出现消息堆积，解决不了根本问题。

总结下来：如果你的业务真的需要稳定支撑每秒100万次写入，别纠结Datastore了，直接上专用OLTP数据库是最靠谱的选择。

内容的提问来源于stack exchange，提问作者skunkwerk