Postgres分片历史
内容提要
Postgres分片历史：从MySQL因LAMP流行而领先，到Postgres的PL/Proxy、Instagram逻辑分片、Citus扩展等方案。Neki作为新方案，结合前人经验，提供显式分片、真实Postgres集群、可扩展路由器和完整生命周期管理，旨在简化分片复杂度，实现行星级扩展。
延伸解读
分片术语的起源
文章指出，“分片”一词可能源自1997年的网络游戏《网络创世纪》。游戏开发者为了在多台服务器上承载玩家，创造了“碎片”的设定：邪恶巫师被打败后，水晶破碎成多个碎片，每个碎片都包含一个世界副本。这个术语后来逐渐演变为数据库分片的含义。了解这一背景有助于理解分片概念的本质：将数据分散到多个独立节点，每个节点独立演进。
MySQL与Postgres分片发展差异
文章强调，MySQL在2010年代因LAMP架构流行而成为主流，因此其分片工具（如Vitess）发展更快。而Postgres早期多依赖定制化方案，如Skype的PL/Proxy和Instagram的逻辑分片。这种差异导致Postgres分片方案成熟较晚，但后来者如Citus和Neki借鉴了前人的经验，逐步完善了Postgres的分片生态。
显式分片与自动分片的权衡
文章对比了显式分片（如Neki、Citus）与自动分片（如Spanner、CockroachDB）的优劣。自动分片隐藏了分片细节，但可能导致性能不可预测、数据放置漂移和扩展支持受限。显式分片则让工程师能清晰规划跨分片查询的延迟，但需要更多手动管理。Neki选择显式分片，旨在提供可控性和可预测性，同时简化运维。
Q&A
Postgres分片的历史背景是什么？
Postgres分片的历史背景是，随着公司规模扩大，数据库无法承受负载，需要分片。在2010年代，MySQL因LAMP栈流行而更早发展出分片工具，而Postgres的分片方案发展较慢，经历了从定制内部方案到PL/Proxy、Instagram逻辑分片、Citus扩展等过程。
为什么MySQL在分片方面比Postgres更早成熟？
因为LAMP栈在2010年代初非常流行，许多成功公司都使用MySQL，因此MySQL的分片工具（如gh-ost、Vitess）发展更快。而Postgres的分片方案相对滞后，很多公司不得不自建内部解决方案。
PL/Proxy分片方案的工作原理和缺点是什么？
PL/Proxy是Skype在2007年提出的早期分片方案，它作为Postgres扩展运行在代理数据库上，通过定义SQL函数来路由查询到不同分片。缺点是每个查询模式都需要手动定义函数，应用和数据库操作员需要紧密配合，维护成本高。
Instagram是如何实现Postgres分片的？
Instagram在2012年采用应用层逻辑分片方案，将数千个逻辑schema映射到少数物理分片上。应用层负责映射和路由，当schema过大时迁移到新物理数据库并更新映射。这种方案低开销，但跨分片查询需在应用层处理，且分片依赖自定义整数ID。
Citus分片方案有哪些优缺点？
Citus是第一个为Postgres设计的开源分片方案，最初是Postgres的分支，2016年重构为扩展。它通过协调节点和工作者节点实现分片，集中管理路由。优点是改进了早期方案，但缺点是协调节点成为瓶颈，分片管理和备份是半手动的，需要大量配置。
自动分片方案（如Spanner）有什么问题？
自动分片方案（如Spanner）隐藏了分片细节，自动分布数据，但存在性能不可预测、扩展支持受限、数据放置难以预测等问题。由于底层不是真正的Postgres，可能导致性能与预期不符，相关行可能分散在不同存储位置，增加延迟。
Neki分片方案有哪些特点？
Neki要求显式分片，使用真正的Postgres集群，支持扩展和SQL兼容性。它通过数据拓扑文件定义分片，路由器可水平扩展，无单点瓶颈。每个分片有独立主备，支持备份、恢复、连接池、schema变更等完整生命周期管理。
Neki与Citus、PgDog等方案相比有何不同？
Neki与Citus、PgDog等方案相比，不仅提供分片路由，还管理备份、恢复、节点健康、连接池、schema变更等，是更完整的数据库生命周期管理方案。它使用真正的Postgres集群，支持显式分片，路由器可水平扩展，避免单点瓶颈。
