随着云计算和数据库技术的快速发展，存储与计算资源分离已成为现代数据库架构的重要趋势。诸如Neon和AWS Aurora等先进的在线事务处理（OLTP）数据库系统采用了这种设计，极大地提升了资源弹性和服务的"无服务器"特性。然而，许多用户和开发者仍持有一个误解，即存储与计算分离必然导致读取性能下降，原因在于计算节点需要经过额外的网络跳转才能访问存储层，增加了延迟。本文将深入探讨为何这种观点并不准确，并通过Neon的本地文件缓存（Local File Cache, LFC）技术实例，说明如何在实现架构弹性的同时，确保读取速度不打折扣。 传统数据库架构通常将计算和存储资源耦合在一起，计算节点直接对本地磁盘或集群内存进行读写操作。这种设计的优点是访问延迟低，性能稳定且可预测。
但随之而来的是资源利用率低下及弹性不足的问题。用户必须在初始部署时预先确定计算与存储规模，一旦数据库规模增长或访问峰值变化，扩展往往艰难且代价高昂。面对这一挑战，存储与计算分离的架构应运而生。通过将存储做成底层的多租户键值服务，计算层则独立运行Postgres等数据库引擎实例，按需扩展或缩减计算资源。存储看似无底洞般弹性，可以动态扩容到TB甚至PB级别，而计算层也能根据实时负载调整，极大节约成本与运维难度。 但存储与计算分离的天然缺点是计算访问存储时需要跨网络传输数据，完成一次存储页读操作便新增一跳网络通信。
而数据库的IO延迟极其敏感，任何微小的额外延迟都可能累加成显著的性能瓶颈。因此很多人担忧，虽然分离架构弹性强，却注定了读取性能的不理想。 Neon针对这一问题创新性地引入了本地文件缓存（LFC）这一额外缓存层，架设于传统Postgres共享缓存（shared buffers）和底层存储服务之间。LFC部署在具备高速NVMe固态盘的计算节点本地，缓存冷热数据页，实现近乎RAM级别的访问延迟。该缓存不仅利用了Linux页面缓存机制，还具备可动态调整大小的灵活能力。 相比Postgres固定大小的共享缓存，LFC可以根据数据库的工作集大小进行弹性扩展，甚至超出物理RAM容量，通过NVMe的快速存储延展缓存空间，兼顾速度和容量的最佳平衡。
例如，在针对TPCC类基准测试中，将LFC配置为500GB的本地缓存时，Neon在8计算单位（8CU）条件下达到约17030 QPS（每秒查询数），90百分位延迟约384毫秒，性能与传统本地固定容量NVMe存储环境非常接近，甚至能以更低的本地存储用量实现类似甚至优异表现。 这种表现的关键在于LFC允许缓存大小灵活匹配数据库的工作集，而非强制要求缓存全库。相较于传统云主机只能选择若干固定大小的磁盘规格，用户不得不为峰值容量提前采购过大磁盘，Neon可智能估算热点数据集和访问模式，通过调整LFC大小适配运行需求，显著节省成本。此举打破了“存储与计算分离导致读取变慢”的性能瓶颈，既保留了架构弹性和成本优势，又实现了与本地部署相媲美的快速读写能力。 此外，Neon的本地文件缓存还有助于自动弹性计算的实现。由于LFC缓存大小可随实例规模动态伸缩，数据库中断或扩展时读取性能无明显波动，保障用户体验平稳。
配合底层存储自动弹性扩容，Neon实现了真正“按需付费、随用随扩”的云数据库服务，大幅提升运营效率。 除了性能和弹性优势，Neon架构还显著提升了业务开发与运维效率。开发者无需担心磁盘容量规划、计算规模绑定，可更专注于业务逻辑开发。通过提供分支、即时恢复等现代Postgres工作流支持，团队可实现数据库快照、分支的低成本复制和测试，从而加速迭代周期。 配合认证、安全合规、细粒度访问管理等企业级特性，Neon构建的一体化生态为多租户应用、SaaS平台以及AI数据驱动系统提供稳健底座。从应用角度看，存储与计算分离加LFC技术赋能的数据库能轻松应对多TB的海量数据规模和突发流量，满足业务高峰期自动弹性扩展需求。
综合来看，Neon通过创新的本地文件缓存设计，成功消解了长期以来存储与计算分离带来的性能诟病。Elastic且serverless的数据库已经不再是性能和灵活性的妥协，而是可实现共赢的现代架构典范。未来，随着更多细粒度缓存控制和高效内存管理技术不断成熟，该架构必将更广泛地被认可和采用。 对于正在寻求稳定、高性能且具备弹性资源管理能力云数据库解决方案的企业和开发者而言，深刻理解存储与计算分离背后的技术原理和Neon本地文件缓存的实际表现，尤为重要。它打破了传统思维的局限，为数据库架构设计带来新范式，也为推动云原生应用发展注入强劲动力。存储与计算分离不代表慢读，合理利用本地缓存技术，才能真正实现性能与弹性的双重提升。
。
