网站购买空间,wordpress输出到模板,上海有几个区和县,北京简盟产品设计有限公司利用共享缓存和操作系统缓存利用 RAM
Postgres 是一个基于磁盘的数据库#xff0c;即使您的整个架构是围绕磁盘访问设计的#xff0c;利用 RAM 也很重要。如果按照人类规模的延迟来判断#xff0c;这可以将延迟从几天缩短到几分钟#xff08;图 1#xff09;。只需看一下…利用共享缓存和操作系统缓存利用 RAM
Postgres 是一个基于磁盘的数据库即使您的整个架构是围绕磁盘访问设计的利用 RAM 也很重要。如果按照人类规模的延迟来判断这可以将延迟从几天缩短到几分钟图 1。只需看一下下表即可看出与磁盘 I/O 相比访问 RAM 或英特尔傲腾 DC PM 的速度要快得多。 标准 Postgres 部署有两种常见的解决方案 - 共享缓冲区缓存和通用 操作系统页面缓存。前者缓存数据和关系索引Postgres 完全管理该组件而后者由操作系统提供给所有应用程序只是将文件页面/块保留在内存中。哪一种更好取决于用例。
然而如果 Postgres 在具有足够 RAM 的单台机器上运行并且不需要横向扩展那么这些缓存技术就足够了。但是一旦数据量和负载超过了即使是最强大的机器的容量我们就会开始寻找另一种解决方案。好吧如果共享缓冲区或操作系统页面缓存适用于所有场景我们就不会拥有分布式内存数据库。
使用 Pgpool-II 进行负载平衡
让我们暂时忘记高级缓存解决方案假设单机 Postgres 无法承受不断增长的负载这是一个经典的负载平衡问题。
Pgpool II需要作为第一个可能的选项进行审查特别是如果您的用例读取量很大。如图所示您需要部署多个 Postgres 实例将它们放在 Pgpool 协调器实例后面并让它负载平衡查询。 但是有几点需要考虑并制定架构清单
拥有的副本越多更新速度就越慢。主数据库实例必须保持从数据库同步。对于许多场景如果无论哪个副本将服务于请求都必须为应用程序保留 ACID 保证则复制需要同步。拥有副本意味着解决方案的有用容量受到主实例上可用存储空间的限制。例如在具有三个副本的集群中即使每台 Postgres 计算机运行 2 TB 磁盘总共 6 TB您也无法存储超过 2 TB 的应用程序生成的唯一数据。如果需要存储更多则需要分配容量更大的机器。
那么我们如何才能以弹性和无限的可扩展性来支持写入密集型或混合工作负载呢让我们在下一节中回顾一下。
使用 Postgres-XL 和云解决方案进行扩展
分片和分区让Postgres从单机数据库转变为纯粹的分布式存储。Postgres-XL可以将数据均匀地分配到集群的整个存储空间从而支持写入密集型和混合工作负载并且有可能能够存储无限的数据集。 此类解决方案的架构没有显着差异。请参阅 Postgres-XL 架构图 3该架构由存储分布式数据集的数据节点、了解数据分布并处理应用程序请求的协调器以及在集群中强制执行事务一致性的全局事务管理器组成。
但即使这些解决方案也不足以满足所有使用场景。那么还缺少或需要什么呢答案是——记忆。这些解决方案仍然基于磁盘尽管可以为每个数据节点启用共享缓冲区和操作系统页面缓存但这种配置将很笨拙且难以管理以确保大规模一致且可预测的延迟。
最后我们来谈谈专为 RAM 和英特尔傲腾 DC PM 设计的分布式内存存储以确保我们能够充分发挥分布式内存存储的潜力。
使用内存数据网格进行缓存和扩展
内存数据网格是一种分布式内存存储可以部署在 Postgres 之上并通过直接从 RAM 处理应用程序请求来卸载后者。网格有助于将可扩展性和缓存结合在一个系统中以大规模地利用它们。
Apache Ignite和GridGain是此类解决方案的示例之一如下图所示它们与 Postgres 互连并使其与内存中数据集保持同步 Ignite 和 GridGain 分区数据的方式与 Postgres-XL 的方式类似只有一个例外内存成为主存储而 Postgres 则保留为辅助磁盘存储。Ignite 和 Gridgain 都支持无限的水平可扩展性、SQL、分布式事务等。您实际上可以在 RAM 中存储 TB 级和 PB 级的数据。
总之我们总结一下讨论的用于增强和扩展 Postgres 的所有选项
共享缓冲区和操作系统页面缓存非常适合单机部署作为利用内存的一种方式。Pgpool-II 完美解决了读取繁重的工作负载的负载平衡问题。Postgres-XL 和类似的解决方案将 Postgres 转变为基于磁盘的分布式数据库用于处理大量写入和混合工作负载。Apache Ignite 和 GridGain 作为内存中的数据网格让我们能够大规模地分布式并利用内存同时将 Postgres 保留为磁盘存储。
