制作企业网站的软件,wordpress源代码在哪里,行业门户网站有哪些,网站页面分析范文PostgreSQL 不仅仅是一个简单的关系数据库#xff1b;它是一个数据管理框架#xff0c;有可能吞没整个数据库领域。
“一切皆用 Postgres”的趋势不再局限于少数精英团队#xff0c;而是正在成为主流最佳实践。
OLAP 的新挑战者 PostgreSQL 生态系统中的一个重大差距是缺乏…PostgreSQL 不仅仅是一个简单的关系数据库它是一个数据管理框架有可能吞没整个数据库领域。
“一切皆用 Postgres”的趋势不再局限于少数精英团队而是正在成为主流最佳实践。
OLAP 的新挑战者 PostgreSQL 生态系统中的一个重大差距是缺乏适用于 OLAP 工作负载的足够好的列式存储引擎。虽然 PostgreSQL 本身提供了大量的分析功能但其对较大数据集进行全面分析的性能并不能完全达到专用的实时数据仓库的水平。
考虑ClickBench一个分析性能基准我们在其中记录了 PostgreSQL、其生态系统扩展和衍生数据库的性能。未调优的 PostgreSQL 性能较差 ( x1050 )但通过优化可以达到 ( x47 )。此外还有三个与分析相关的扩展列式存储Hydra ( x42 )、时间序列TimescaleDB ( x103 ) 和分布式Citus ( x262 )。
这种性能并不算差特别是与 MySQL 和 MariaDBx3065、x19700等纯 OLTP 数据库相比然而它的第三层性能还不够“好”落后于 Umbra、ClickHouse、Databend、SelectDBx3~x4等第一层 OLAP 组件一个数量级。这是一个棘手的地方——使用起来不够令人满意但又太好了而无法丢弃。
然而 ParadeDB和DuckDB的到来改变了游戏规则
ParadeDB的原生 PG 扩展pg_analytics实现了第二层性能 ( x10 )将与顶层的差距缩小到仅 3-4 倍。考虑到额外的好处这种水平的性能差异通常是可以接受的——无需 ETL 的 ACID、新鲜度和实时数据无需额外的学习曲线无需维护单独的服务更不用说其 ElasticSearch 级全文搜索功能。DuckDB专注于纯粹的 OLAP将分析性能推向极致x3.2——排除专注于学术的闭源数据库 UmbraDuckDB 可以说是实用 OLAP 性能最快的。它不是 PG 扩展但 PostgreSQL 可以通过DuckDB FDW和pg_quack等项目充分利用 DuckDB 作为嵌入式文件数据库的分析性能提升。
ParadeDB和DuckDB的出现将PostgreSQL的分析能力推向了OLAP的顶级填补了其分析性能的最后一个关键空白。
OLTP 和 OLAP 之间选择之难 OLTP 和 OLAP 之间的区别在数据库诞生之初并不存在。由于传统 OLTP 数据库难以支持分析场景的查询模式和性能需求OLAP 数据仓库与数据库的分离出现于 20 世纪 90 年代。
长期以来数据处理的最佳实践涉及使用 MySQL/PostgreSQL 处理 OLTP 工作负载并通过 ETL 流程将数据同步到专门的 OLAP 系统如 Greenplum、ClickHouse、Doris、Snowflake 等。
与许多“专业数据库”一样专用 OLAP 系统的优势通常在于性能——比原生 PG 或 MySQL 实现 1-3 个数量级的提升。然而代价是冗余数据、过多的数据移动、分布式组件之间的数据值缺乏一致、专业技能的额外劳动力费用、额外的许可成本、有限的查询语言能力、可编程性和可扩展性、有限的工具集成、较差的数据完整性。与完整的 DMBS 相比的可用性。
然而俗话说“善有善报恶有恶报”。随着硬件遵循摩尔定律三十多年来不断改进性能呈指数级增长而成本却直线下降。 2024年单台x86机器可以拥有数百个核心512 vCPU EPYC 9754 x2数TB RAM单个NVMe SSD可以容纳高达64TB单个全闪存机架可以达到2PB像 S3 这样的对象存储提供了几乎无限的存储空间。
硬件的进步解决了数据量和性能问题而数据库软件的开发PostgreSQL、ParadeDB、DuckDB则解决了访问方法的挑战。这使得分析行业即所谓的“大数据”行业的基本假设受到审视。
大数据已死 正如 DuckDB 的宣言“大数据已死”所暗示的那样大数据时代已经结束。大多数人没有那么多数据而且大多数数据很少被查询。随着硬件和软件的发展大数据的前沿正在消退99%的场景都不再需要“大数据”。
如果现在可以在具有独立 DuckDB 或 PostgreSQL及其副本的单台计算机上处理 99% 的用例那么使用专用分析组件有何意义如果每部智能手机都可以自由地发送和接收短信那么寻呼机还有什么意义呢 需要注意的是北美医院仍在使用寻呼机这表明可能只有不到 1% 的场景真正需要“大数据”。
基本假设的转变正在引导数据库世界从多元化阶段回到趋同阶段从大爆炸转向大规模灭绝。在这个过程中一个统一、多模型、超融合的数据库新时代将出现OLTP和OLAP重新统一。但谁将领导这项重新整合数据库领域的艰巨任务呢
PostgreSQL数据库世界吞噬者 数据库领域有很多选项时间序列、地理空间、文档、搜索、图形、矢量数据库、消息队列和对象数据库。 PostgreSQL 在所有这些领域中都体现了它的存在。
一个典型的例子是 PostGIS 扩展它为地理空间数据库设定了事实上的标准 TimescaleDB 扩展尴尬地定位了“通用”时间序列数据库向量扩展PGVector将专用向量数据库利基变成了笑点。
这不是第一次了我们在最古老、最大的子领域再次见证了这一点OLAP 分析。但 PostgreSQL 的野心并不止于 OLAP它正在关注整个数据库世界
是什么让 PostgreSQL 如此强大 当然它很先进但 Oracle 也很先进它是开源的MySQL 也是如此。
PostgreSQL的优势来自于它的先进性和开源性这使得它能够与Oracle/MySQL竞争。
但它真正的独特之处在于其极端的可扩展性和蓬勃发展的扩展生态系统。
PostgreSQL 不仅仅是一个关系数据库它还是一个关系数据库。它是一个能够吞没整个数据库星系的数据管理框架。除了开源、先进之外其核心竞争力还源于可扩展性即基础设施的可重用性和扩展的可组合性。
极致可扩展性的魔力 PostgreSQL 允许用户开发扩展利用数据库的通用基础设施以最低的成本提供功能。例如矢量数据库扩展pgvector仅有几千行代码与 PostgreSQL 的数百万行代码相比其复杂性可以忽略不计。然而这种“微不足道”的扩展实现了完整的矢量数据类型和索引功能优于许多专用矢量数据库。
为什么 因为 pgvector 的创建者不需要担心数据库一般的额外复杂性ACID、恢复、备份和 PITR、高可用性、访问控制、监控、部署、第三方生态系统工具、客户端驱动程序等这些都需要数百万个几行代码就很好解决了。他们只关注问题的本质复杂性。
例如ElasticSearch 是在 Lucene 搜索库上开发的而 Rust 生态系统有一个改进的下一代全文搜索库Tantivy作为 Lucene 的替代品。 ParadeDB 只需要包装并连接到 PostgreSQL 的接口即可提供与 ElasticSearch 相当的搜索服务。更重要的是它可以站在PostgreSQL的肩膀上利用整个PG生态的联合力量例如与PG Vector的混合搜索与另一个专用数据库进行“不公平”竞争。
可扩展性还带来了另一个巨大的优势扩展的可组合性允许不同的扩展一起工作产生11»2的协同效应。例如TimescaleDB可以与PostGIS结合用于时空数据支持用于全文搜索的 BM25 扩展可以与 PGVector 扩展相结合提供混合搜索功能。
此外分布式扩展Citus可以透明地将独立集群转变为水平分区的分布式数据库集群。该功能可以与其他功能正交组合使PostGIS成为分布式地理空间数据库PGVector成为分布式矢量数据库ParadeDB成为分布式全文搜索数据库等等。
更强大的是扩展是独立发展的不需要繁琐的主分支合并和协调。这允许扩展——PG的可扩展性让众多团队可以并行探索数据库的可能性所有扩展都是可选的不会影响核心功能的可靠性。那些成熟、健壮的功能有机会稳定地集成到主分支中。
PostgreSQL 通过极致可扩展性的魔力实现了基础可靠性和敏捷功能使其成为数据库世界中的异类并改变了数据库格局的游戏规则。
DB Arena 的游戏规则改变者 PostgreSQL 的出现改变了数据库领域的范式致力于打造“新数据库内核”的团队现在面临着一项艰巨的考验——如何在开源、功能丰富的 Postgres 中脱颖而出。他们独特的价值主张是什么
在出现革命性的硬件突破之前实用的、新型的通用数据库内核的出现似乎不太可能。没有任何一个数据库可以与 PG 的整体实力相媲美在其所有扩展的支持下即使是 Oracle也无法与 PG 的开源和免费王牌相媲美。
PostgreSQL 长期以来一直是 HackerNews 和 StackOverflow 中最受欢迎的数据库。许多新的开源项目默认将 PostgreSQL 作为主要如果不是唯一数据库选择。许多新一代公司正在全力以赴地使用 PostgreSQL。
正如“ Radical Simplicity: Just Use Postgres ”所说“Just Use Postgres”可以实现简化技术堆栈、减少组件、加速开发、降低风险和添加更多功能。 Postgres 可以替代许多后端技术包括 MySQL、Kafka、RabbitMQ、ElasticSearch、Mongo 和 Redis轻松为数百万用户提供服务。Just Use Postgres不再局限于少数精英团队而是成为主流最佳实践。
对于绝大多数场景来说PostgreSQL 已经是一个近乎完美的数据库内核这使得内核“瓶颈”的想法变得荒谬。以内核修改为卖点的 PostgreSQL 和 MySQL 的分支基本上不会有任何进展。
这与当今 Linux 操作系统内核的情况类似尽管 Linux 发行版众多但每个人都选择相同的内核。分叉 Linux 内核被认为会造成不必要的困难业界对此不以为然。
因此主要的冲突不再是数据库内核本身而是两个方向——数据库扩展和服务前者涉及内部可扩展性而后者涉及外部可组合性。就像操作系统生态系统一样竞争格局将集中在数据库发行版上。在数据库领域只有那些以扩展和服务为中心的发行版才有机会取得最终成功。
内核仍然不冷不热MySQL 母公司的分支 MariaDB 已接近退市而 AWS 则通过在免费内核之上提供服务和扩展而获利蓬勃发展。投资已流入众多 PG 生态系统扩展和服务发行版Citus、TimescaleDB、Hydra、PostgresML、ParadeDB、FerretDB、StackGres、Aiven、Neon、Supabase、Tembo、PostgresAI
挑战与整合 PostgreSQL生态系统中的一个困境是许多扩展和工具的独立发展缺乏一个统一器来协同它们。例如Hydra 发布了自己的包和 Docker 镜像PostgresML 也是如此每个都发布了带有自己的扩展且仅自己的扩展的 PostgreSQL 镜像。这些镜像和包与AWS RDS等综合数据库服务相去甚远。
扩展是 PostgreSQL 的灵魂。没有自由使用扩展的 Postgres 就像做饭没有盐一样受到巨大的限制。
整合 PostgreSQL 生态系统的优势打造类似于数据库世界Ubuntu的协同力量。
PostGIS提供地理空间数据类型和索引这是 GIS 的事实标准 pgPointCloud、 pgRouting。TimescaleDB添加时间序列、连续聚合、分布式、列式存储和自动压缩功能。PGVector支持 AI 向量/嵌入和 ivfflat、hnsw 向量索引以及用于稀疏向量的pg_sparse。Citus将经典的主从 PG 集群转变为水平分区的分布式数据库集群。Hydra添加列式存储和分析可与 ClickHouse 的分析功能相媲美。ParadeDB将全文搜索和混合检索提升到 ElasticSearch 级别以及用于中文标记化的zhparser。Apache AGE图形数据库扩展为 PostgreSQL 添加类似 Neo4J 的 OpenCypher 查询支持。PG GraphQL向 PostgreSQL 添加原生内置 GraphQL 查询语言支持。DuckDB FDW允许通过 PostgreSQL和 DuckDB CLI直接访问 DuckDB 强大的嵌入式分析数据库文件。Supabase基于 PostgreSQL 的开源 Firebase 替代品提供完整的应用程序开发存储解决方案。FerretDB基于 PostgreSQL 的开源 MongoDB 替代方案与 MongoDB API/驱动程序兼容。PostgresML促进经典机器学习算法使用 SQL 调用、部署和训练 AI 模型。
https://www.jdon.com/73039.html
