查看原文
其他

云数据库是不是智商税?

谁谓河广一苇航之 非法加冯 2023-02-01

寒冬来袭,大厂纷纷开始裁员,进入降本增效模式,作为公有云杀猪刀一哥的云数据库,故事还能再讲下去吗?

近日,Basecamp & HEY 联合创始人 DHH 的一篇文章【1】【2】引起热议,主要内容可以概括为一句话:

“我们每年在云数据库(RDS/ES)上花50万美元,你知道50万美元可以买多少牛逼的服务器吗?我们不做冤大头要下云了,拜拜了您呐!

所以,50万美元可以买多少牛逼的服务器?


云数据库是不是智商税?荒谬的定价成本刺客足够好吗?适用的场景让DBA下岗?垄断的威胁应对的方案‍‍‍‍‍参考


荒谬的定价

公有云上什么最花钱?正常来说,如果不是把公有云单纯当作一个 IDC 2.0 或者 CDN供应商来用,最费钱的服务就是云数据库。公有云上的存储、计算、网络资源贵吗?严格来说不算特别离谱。IDC托管物理机代维的核月成本大约为二三十块,而公有云上一核 CPU 算力用一个月的价格,大概在七八十块到一两百块,考虑到各种折扣与活动,以及弹性溢价,基本处于薄利多销的状态。

公有云上的存储、计算、网络资源贵吗?严格来说不算特别离谱。IDC托管物理机代维的核月成本大约为二三十块,而公有云上一核 CPU 算力用一个月的价格,大概在七八十块到一两百块,考虑到各种折扣与活动,以及弹性溢价,基本处于薄利多销的状态。

计算资源价格(元/核·月):公有云定价通常在几十到一两百不等

不过云数据库就非常离谱了,同样是一核算力用一个月,云数据库价格比起对应规格的硬件可以翻几倍乃至十几倍。 便宜一些阿里云,核月单价三四百,贵一些的 AWS,核月单价可以上千。

数据库单价
AWS RDS PostgreSQL db.T2 (4x)440
AWS RDS PostgreSQL db.M5 (4x)611
AWS RDS PostgreSQL db.R6G (8x)786
AWS RDS PostgreSQL db.M5 24xlarge1328
阿里云 RDS PG 2x内存(独占)260
阿里云 RDS PG 4x内存(独占)320
阿里云 RDS PG 8x内存(独占)410
ORACLE数据库授权10000

云数据库资源价格(元/核·月):公有云定价通常在几百到一两千

云数据库的定价模型基本上都是对应 硬件资源价格(EC2)乘以某一个倍率。例如,阿里云 RDS PG (基础版)与同规格 ECS 定价的关系就是 RDS = 2.3 x ECS,而在AWS上,这个倍率则会更高。

AWS 96C 384G m5.24xlarge, RDS是EC2 十倍的价格。

作为一条经验法则,租一年云数据库的成本,差不多够你买两三台更好规格的服务器放在IDC里托管

单价二十块的硬件,为什么可以卖出几百甚至上千的价格来,究竟是服务器是金子做的,还是RDS是金子做的?

常用的话术是:数据库是基础软件里的皇冠明珠,凝聚着无数无形知识产权BlahBlah。因此软件的价格远超硬件,是非常合理的。如果是 Oracle 这样的顶尖商业数据库,这么说也有些道理。但公有云上的云数据库,本质上就是免费开源数据库内核换皮封装魔改,加上自己管控软件和共享DBA人头服务。那这种溢价率就非常荒谬了。

公有云的秘密就在这里:用廉价的存算资源获客,用云数据库杀猪

尽管国内公有云 IaaS (存储、计算、网络)的收入占营收接近一半,但毛利率只有 15% ~ 20%,而公有云 PaaS 的营收虽然不如 IaaS,但 PaaS 的毛利率可以达到 50%,完爆卖资源吃饭的 IaaS 。而 PaaS 中最具代表性的,就是云数据库。


成本刺客

公有云上什么最花钱?正常来说,如果不是把公有云单纯当作一个 IDC 2.0 或者 CDN供应商来用,最费钱的服务当属数据库

在我职业生涯的第一站中,一次杀猪经历让我记忆犹新:作为前几个被逼上A云的内部BU,A云直接出工程师加入手把手提供上云服务。用ODPS全家桶换掉了自建的大数据/数据库全家桶。应该说服务确实不错,只不过每年的存储计算开销从千万出头飙升到接近一亿,利润几乎都转移到A云了。

在第二站则完全不同,我们有两万五千核规模的 PostgreSQL 与 Redis 数据库集群。这个规模如果用云数据库,即使打到骨折,每年一两亿还是要的;甚至,如果说按照WCU/RCU的计费模式,费用可以干到每年十亿量级。但结果是,我们两三个DBA,几个运维,以每年不到一千万的总成本(人年工资+机器5年折旧+IDC托管代维均摊)便支撑起这样规模的服务,而且做的相当不赖,四五百万的QPS,可用性普遍在5个9以上。

以我们自己使用的数据库机型为例, DELL R730 64核CPU 384GB内存 + 3TB NVME SSD,跑PostgreSQL单台点查QPS几十万,写入TPS十几万,性能澎湃。采购价七万五一台,高可用数据库集群至少两台,以五年折旧计,每年成本三万块

而类似规格的云数据库,以阿里云RDS PG高可用版独享64C 512G pg.x8.8xlarge.2c为例,不同付费模式折合的每年成本如下表所示。

付费模式单价¥折合每年¥
按需付费99.59/小时87.2w
按月付费47548/月57.1w
按年付费(85折)484989/年48.5w
3年付费(5折)855864/3年28.5w
自建(5年折旧)15万/5年3w

这玩意自建的价格合每年3万,看看溢价率有多高?AWS RDS只会更贵。

总的来说,在不考虑人工成本的情况下,打成骨折的云数据库,还是比同规格自建贵了几乎有十几倍,多么疯狂!(人工成本后面再说)


足够好吗?

只要东西足够好,单纯贵并不是问题。那么问题就来了,RDS足够好吗?

应该说,对于玩具应用,微型网站,个人托管,野路子土法自建数据库来,毫无技术能力与认知的甲方说,RDS足够好了。但在高净值客户群体与数据库专家看来,云数据库RDS不过是及格线上的大锅饭产品罢了。说到底,公有云源于大厂内部的运维能力外溢,对大厂大可不必有什么莫名的崇拜。(Google也许算个例外,它的问题恰好相反)。

性能 为例,性能的核心指标是 延迟 / 响应时间,特别是长尾延迟,会直接影响用户体验。在这一点上,云数据库的性能表现就非常之拉垮。在小规模的Bench测试中,所有工作集都在内存中,有时候看不出来这一点。但实际跑起来一旦内存缓冲区没有命中访问存储,延迟会立刻从几十微秒飙升到几十毫秒。这样的长尾延迟经过几次应用倍乘放大,对于用户体验来说非常致命:没有人愿意等着每个操作都要转几秒圈圈(银行App差不多就是这种)。

在我们自己的业务里使用的是本地NVME SSD,典型性能表现为读写延迟几十个微秒(3.2TB / MLC ),一条简单读/写查询的响应时间在PG侧为 100~200µs,在应用侧的端到端请求延迟通常为 200 ~ 500µs,超过1毫秒的查询都会视作异常慢查询。而云数据库底层使用的EBS服务本身延迟就非常之高,例如,AWS默认的GP3默认8K读写延迟稳定为40ms,io1规格延迟约为10毫秒,云数据库光是磁盘IO延迟就能给你干到十毫秒的数量级,你说这咋整?【4】



确实,有时候云厂商会提供性能足够好的本地的NVME SSD,但都会非常鸡贼的设定各种限制条件,来避免用户来使用EC2来自建数据库。AWS的限制方式是 ephemeral storage,这种本地盘一旦遇上EC2重启就自动抹干净了。阿里云的限制方式是给你卖天价,例如ESSD PL3 定价为 38.4 ¥ / GB·年,一块3.2TB的磁盘用一年要收12万,好家伙,用一年这钱够你买20块这样的磁盘了。所以在成本上,无论是RDS本体还是存储,都是纯纯的杀猪智商税。


再以 可观测性 为例,没有一家RDS的监控能称得上是“好”。就以监控指标数量来说吧,虽然说知道服务死了还是活着只需要几个指标,但如果想进行故障根因分析,需要越多越好的监控指标来构建良好的Context。而大多数RDS都只是做了一些基本的监控指标,和简陋到可怜的监控面板。以阿里云RDS PG为例【4】【5】,所谓的“增强监控”,里面只有这么点可怜的指标 , AWS里和PG数据库相关的指标也差不多不到100个。‍

而我们自己的监控系统里主机指标有800多类,PGSQL数据库指标610类,REDIS指标257类,整个大约三千类指标,在数量上完爆这些RDS。一个公开的Demo可以在这里看到:http://demo.pigsty.cc 。

至于可靠性,都不想说12月香港机房那场丑闻了,租的机房,服务器喷水消防,OSS故障,然后阿里云自己整个Region的管控服务竟然因为一个AZ故障自己尿掉了,大量RDS不可用也切不了,让异地容灾成了一个大笑话。不是说自己建就不会出这些问题,稍微靠谱点的IDC托管都不会有这么离谱的事。安全性也闹过几次大笑话,著名的SHGA;一堆样例代码里硬编码AK/SK,你说云RDS更安全?别搞笑啦,经典架构起码还有VPN堡垒机扛着,公网上暴露端口的数据库简直不要太多。

云数据库另一个广为人所诟病的是可扩展性。RDS是不给用户dbsu权限的,这也意味着用户是不能在数据库中安装扩展插件的,而 PostgreSQL 的插件恰恰就是其醍醐味,没有扩展的PostgreSQL就像可乐不加冰,酸奶不加糖一样。当然更严重的问题是,在一些故障出现时,用户甚至都丧失了自我救助的能力。参见:《云数据库:从删库到跑路》中的真实案例,WAL归档与PITR这么基础性的功能,在RDS中竟然是一个付费的升级功能。至于可维护性,有些人说云数据库可以点点鼠标就创建销毁多方便呀,说这话的人肯定没经历过重启每个数据库都要收手机短信验证码的sb场景。有 Database as Code 式的管理工具,真正的工程师绝对不会用这种“ClickOps”。

不过任何事物存在都有其道理,云数据库也不是一无是处,起码在可伸缩性上,确实是整出了一些花活。除此之外,确实没有什么能吹嘘的了。


适用的场景

no silver bullet

选型一款数据库,需要从许多维度出发:稳定性,可靠性,安全性,简单性,可伸缩性,可扩展性,可观测性,可维护性。公有云的鼓吹者很喜欢往云脸上贴金:节约成本,灵活弹性,安全可靠,是企业数字化转型的万灵药,是电动车对马车的革命,既要又要。但绕开这些虚头巴脑的东西,相比专业的数据库服务,云数据库真正占有优势的只有一条:弹性。具体来说是两点:启用成本低,可伸缩性强。

启动成本低,说的是你不需要进行机房建设,服务器采购就可以开始用,当然代价是高到离谱的维护成本。可伸缩性强,指的是各种配置升降配,扩缩容比较容易。因此,公有云真正适用的场景就是这两种:

  1. 起步阶段,流量极小的简单应用

  2. 毫无规律可循,大起大落的负载

前者主要包括简单网站,个人博客,小程序小工具,演示/POC,试水性Poc/Demo。后者主要包括低频的的数据分析/模型训练,突发的秒杀抢票,明星并发出轨等。


公有云的场景其实类似于共享充电宝,出门在外,共享充电宝可以解决临时应急性的小规模充电需求。但对于大量日常在家/单位两点一线的人来说,每天用它给手机电脑乃至电车充电,毫无疑问是荒谬的。共享充电宝租一个小时4块钱,租几个小时的钱,就够你把它直接买下来了。

租车可以很好的满足临时的、突发的、一次性用车需求:外地出差旅游,临时拉一批货。但如果你的出行需求是频繁的,粗略可预测的,那么购置一辆自动驾驶的车也许是最省事省钱的选择。房子的租售比二三十年,汽车的租售比五六年,而公有云服务器的租售比通常只有几个月,如果你的业务稳定活几个月,为什么不买而要租呢?

所以,云厂商赚的钱,要么是VC投出来的朝不保夕的科技创企,要么是信息不对称人傻钱多的大户,要么是灰色空间比云溢价还高的特殊单位,要么是个人站长/学生/VPN用户。聪明的高净值客户,谁会放着便宜舒适的大House不住,跑去挤着租住方舱医院人才公寓呢?

如果为了不需要的灵活性与弹性支付几倍乃至十几倍溢价,这是纯纯的智商税。



让DBA下岗?

另一种云数据库的鼓吹论点是,用了RDS,你就不用DBA啦。我们有数据库自治服务,RDS能帮你解决这些数据库相关的问题,DBA都要下岗了。我相信,任何认真看过这些‘自治服务’文档【6】【7】的人都不会说出这种可笑的话出来:这种连一个好用的监控系统都算不上的小模块,能让数据库自治起来?

DBA的由来

很多地方都需要DBA:糟糕的模式设计,奇烂的查询性能,鬼知道有没有用的备份;等等等等。可惜的是,从事软件工作的人中,很少有人了解什么是DBA。成为DBA,意味着与研发人员创造的熵进行永无休止的战斗。

DBA,Database Administrator,数据库管理员,以前也叫做数据库协调员、数据库程序员。DBA是一个横跨于研发团队与运维团队的广博角色,涉及DA、SA、Dev、Ops、以及SRE的多种职责,负责各种与数据与数据库有关的问题:设置管理策略与运维标准,规划软硬件架构,协调管理数据库,验证表模式设计,优化SQL查询,分析执行计划,乃至于处理紧急故障以及抢救数据。

DBA的第一点价值在于安全兜底:他是企业核心数据资产的守护者,也是可以轻易对企业造成致命伤害的人。在蚂蚁金服有个段子,能搞死支付宝的,除了监管就是DBA了。高管们通常也很难意识到 DBA 对于公司的重要性,直到出了数据库事故,一堆CXO紧张地站在DBA背后观看救火修复过程时…。

DBA的第二点价值在于性能优化。许多公司并不在乎他们的查询是纯狗屎,他们只是觉得“硬件很便宜”,砸钱买硬件就好了。然而问题在于,一个调整不当的查询/SQL或设计不当的数据模型与表结构,可以对性能产生几个数量级的影响。总会在某一个规模,堆硬件的成本相比雇佣一个靠谱DBA的成本高得令人望而却步。实话说,我认为大多数公司在IT软硬件开销中花费最大的是:开发人员没有正确使用数据库

优秀的DBA还会负责数据模型设计与优化。数据建模和SQL几乎已成为一门失传的艺术,这类基础知识逐渐为新一代工程师遗忘,他们设计出离谱的模式,不懂得正确地创建索引,然后草率得出结论:关系型数据库和SQL都是垃圾,我们必须使用糙猛快的NoSQL来省时间。然而人们总是需要可靠的系统来处理关键业务数据:在许多企业中,核心数据仍然是一个常规关系型数据库作为Source of Truth,NoSQL数据库仅用于非关键数据。

在一个大型组织中,一个好的DBA是至关重要的。不过好的DBA相当稀有,以至于这个角色在大多数组织中只能外包:包给专业的数据库服务公司,包给云数据库RDS服务团队,或者内包给自己的研发/运维人员。

DBA的未来

尽管DBA/数据库专家对于大型组织与大型数据库而言非常重要,不幸的是,DBA作为一份职业前景可能确实是晦涩暗淡的。大趋势是数据库本身会越来越智能,易用性越来越好,而各式各样的工具、SaaS、PaaS不断涌出,也会进一步压低数据库的使用门槛。公有云/私有云DBasS的出现更是让数据库的门槛进一步下降,只要掏钱就可以迅速达到优秀DBA的廉价七成正确水准。而数据库的专业技术门槛降低,将导致DBA的不可替代性降低:安装一套软件收费十几万,做一次数据恢复上百万的好日子肯定是一去不复返了。

无论是公有云厂商,还是以Kubernetes为代表的云原生/私有云,或者是类似 Pigsty 【8】这样的本地开源RDS替代,其核心价值都在于尽可能多地使用软件,而不是人来应对系统复杂度。那么,云软件会革了运维与DBA的命吗?好的软件可以解决70%的高频问题,然而总是会有那么一些低频的,复杂的需要人才能处理。

根据复杂度守恒定律,无论是系统管理员还是数据库管理员,管理员这个岗位消失的唯一方式是,它们被重命名为“DevOps Engineer”或SRE。云并不会消灭管理员,你可能需要更少的人手来打理这些云软件,但总归还是需要人来管理的:从整个行业的视角看,云软件的推广会让100个初中级运维(传统系统管理员)的工作岗位变成10个中高级运维岗位(DevOps/SRE),同样的事也有可能发生在DBA身上。例如,现在也出现了与SRE相对应的 DREDatabase Reliability Engineer。

DBA的岗位会发生分化,运维性,事务性的工作会逐渐剥离消亡,而管理性、业务性的工作内容占比会加大。顶尖的数据库专家永远不会担心失业问题,也许换一个新的名字:与SRE相对应的 DREDatabase Reliability Engineer。中上的DBA的岗位会因为软件替代减少,而初级DBA,或者内包为‘初级DBA’得研发运维人员,会因为管控软件的门槛降低而增多。

RDS确实让一部分DBA下岗了,但在自我革命这件事上,云数据库是不可能干过顶尖DBA的。RDS既然先不仁,就不要怪DBA不义了。


垄断的威胁

我们更需要担心的是这样一幅图景,公有云(或果子云)坐大,控制硬件与运营商上下游,垄断计算,存储,网络,顶尖专家资源。想要用好数据库,必须用昂贵的RDS才行。而只要掌握这些关键少数,就可以控制整个互联网。这毫无疑问与互联网的初心愿景背道而驰的。引用 DDIA 作者 Martin Kelppmann 的一段话【9】来说:

在2020年,计算自由的敌人是云计算软件

—— 即主要在供应商的服务器上运行的软件,而你的所有数据也存储在这些服务器上。典型的例子包括:Google Docs、Trello、Slack、Figma、Notion和其他许多软件。

这些“云软件”也许有一个客户端组件(手机App,网页App,跑在你浏览器中的JavaScript),但它们只能与供应商的服务端共同工作。而云软件存在很多问题:

  • 如果提供云软件的公司倒闭,或决定停产,软件就没法工作了,而你用这些软件创造的文档与数据就被锁死了。对于初创公司编写的软件来说,这是一个很常见的问题:这些公司可能会被大公司收购,而大公司没有兴趣继续维护这些初创公司的产品。

  • 谷歌和其他云服务可能在没有任何警告和追索手段的情况下,突然暂停你的账户。例如,您可能在完全无辜的情况下,被自动化系统判定为违反服务条款:其他人可能入侵了你的账户,并在你不知情的情况下使用它来发送恶意软件或钓鱼邮件,触发违背服务条款。因而,你可能会突然发现自己用Google Docs或其它App创建的文档全部都被永久锁死,无法访问了。

  • 而那些运行在你自己的电脑上的软件,即使软件供应商破产了,它也可以继续运行,直到永远。(如果软件不再与你的操作系统兼容,你也可以在虚拟机和模拟器中运行它,当然前提是它不需要联络服务器来检查许可证)。例如,互联网档案馆有一个超过10万个历史软件的软件集锦,你可以在浏览器中的模拟器里运行!相比之下,如果云软件被关闭,你没有办法保存它,因为你从来就没有服务端软件的副本,无论是源代码还是编译后的形式。

  • 20世纪90年代,无法定制或扩展你所使用的软件的问题,在云软件中进一步加剧。对于在你自己的电脑上运行的闭源软件,至少有人可以对它的数据文件格式进行逆向工程,这样你还可以把它加载到其他的替代软件里(例如OOXML之前的微软Office文件格式,或者规范发布前的Photoshop文件)。有了云软件,甚至连这个都做不到了,因为数据只存储在云端,而不是你自己电脑上的文件。

如果所有的软件都是免费和开源的,这些问题就都解决了。然而,开源实际上并不是解决云软件问题的必要条件;即使是闭源软件也可以避免上述问题,只要它运行在你自己的电脑上,而不是供应商的云服务器上。请注意,互联网档案馆能够在没有源代码的情况下维持历史软件的正常运行:如果只是出于存档的目的,在模拟器中运行编译后的机器代码就够了。也许拥有源码会让事情更容易一些,但这并不是关键,最重要的事情,还是要有一份软件的副本。

我和我的合作者们以前曾主张过本地优先软件的概念,这是对云软件的这些问题的一种回应。本地优先的软件在你自己的电脑上运行,将其数据存储在你的本地硬盘上,同时也保留了云计算软件的便利性,比如,实时协作,和在你所有的设备上同步数据。开源的本地优先的软件当然非常好,但这并不是必须的,本地优先软件90%的优点同样适用于闭源的软件。

云软件,而不是闭源软件,才是对软件自由的真正威胁,原因在于:云厂商能够突然心血来潮随心所欲地锁定你的所有数据,其危害要比无法查看和修改你的软件源码的危害大得多。因此,普及本地优先的软件显得更为重要和紧迫。如果在这一过程中,我们也能让更多的软件开放源代码,那也很不错,但这并没有那么关键。我们要聚焦在最重要与最紧迫的挑战上。


应对的方案

我希望未来的世界人人都有自由使用优秀服务的事实权利,而不是只能被圈养在几个公有云厂商提供的猪圈里吃屎。这就是为什么我要做 Pigsty, 一个更好的,开源免费的 PostgreSQL RDS替代。让用户能够在任何地方(包括云服务器)上,一键拉起有比云RDS更好的数据库服务。

Pigsty是对云数据库的辛辣嘲讽,也是对 PostgreSQL 的彻底补完。Pigsty 是 Postgres in Great STYle 的缩写,即“全盛状态下的 PostgreSQL”。 它是一个完全基于开源软件的,可以运行在任何地方的,浓缩了 PostgreSQL 使用管理最佳实践的,Me-Better  RDS 开源替代。Pigsty就是用真实世界的大规模,高标准 PostgreSQL 集群打磨而来的解决方案,它是为了满足我们自己管理数据库的需求而诞生的。它在八个维度上进行了许多工作:


可观测性(Observability)是天;天行健君子以自强不息;Pigsty使用现代可观测性技术栈为 PostgreSQL 打造了一款无与伦比的监控系统,从全局大盘概览到单个表/索引/函数等对象的秒极历史详情指标一览无遗,让用户对系统能够做到洞若观火,进而掌控一切。此外,Pigsty的监控系统还可以独立使用,监控第三方数据库实例。

可控制性(Controllability)是地;地势坤君子以厚德载物;Pigsty提供Database as Code的能力:使用表现力丰富的声明式接口描述数据库集群的状态,并使用幂等的剧本进行部署与调整。让用户拥有精细定制的能力的同时又无需操心实现细节,解放心智负担,让数据库操作与管理的门槛从专家级降低到新手级。

可伸缩性(Scalability)是水;水洊至习坎君子以常德行;Pigsty提供预制通用调参模板(OLTP / OLAP / CRIT / TINY),自动优化系统参数,并可通过级联复制无限扩展只读能力,也使用Pgbouncer连接池优化海量并发连接;Pigsty确保 PostgreSQL 的性能可以在现代硬件条件下充分发挥:单机可达数万并发连接/百万级单点查询QPS/十万级单条写入TPS。

可维护性(Maintainability)是火;明两作离大人以继明照于四方;Pigsty 允许在线摘除添加实例以扩缩容,Switchover/滚动升级进行升降配,提供基于逻辑复制的不停机迁移方案,将维护窗口压缩至亚秒级,让系统整体的可演化性,可用性,可维护性提高到一个新的水准。

安全性(Security)是雷;洊雷震君子以恐惧修省;Pigsty提供了一套遵循最小权限原则的访问控制模型,并带有各种安全特性开关:流复制同步提交防丢失,数据目录校验和防腐败,网络流量SSL加密防监听,远程备份AES-256防泄漏。只要物理硬件与密码安全,用户无需担心数据库的安全性。

简单性(Simplicity)是风;随风巽君子以申命行事;Pigsty旨在以最小的复杂度成本交付完整的RDS功能,模块化设计允许用户自行组合选用所需的功能。Pigsty提供基于Vagrant的本地开发测试沙箱,与Terraform的云端IaC一键部署模板,让您在任意新EL节点上一键完成离线安装,完整复刻环境。

可靠性(Reliability)是山;兼山艮君子以思不出其位;Pigsty提供了故障自愈的高可用架构应对硬件问题,也提供开箱即用的PITR时间点恢复为人为删库与软件缺陷兜底,并通过长时间、大规模的生产环境运行与高可用演练验证其可靠性。

可扩展性(Extensibility)是泽:丽泽兑君子以朋友讲习;Pigsty深度整合PostgreSQL生态三大核心扩展PostGIS、TimescaleDB、Citus 、以及大量扩展插件;Pigsty提供模块化设计的Prometheus/Grafana可观测性技术栈,以及MINIO,ETCD,Redis、Greenplum 等组件的监控与高可用部署与PostgreSQL 组合使用;


更重要的是,Pigsty是完全开源免费的自由软件,采用 AGPL v3.0 协议,也提供免费的社区支持和答疑,这一部分主要是靠的是社区专家与用户的情怀用爱发电。所以,您可以用20块的纯硬件成本运行功能完备,甚至更好的RDS服务。

尽管Pigsty 本身旨在用数据库自动驾驶软件替代人肉数据库运维,但再好的软件也没法解决 100% 的问题。优秀的软件可以解决80% 的高频常见问题,但是总会有 20% 的冷门低频疑难杂症,需要专家来介入处理。 这也是为什么我们也提供专业的商业支持与订阅服务,来为有需要的企业级用户使用 PostgreSQL 与 Pigsty 兜底。Pigsty帮助用户用好 PostgreSQL,而我们帮助用户用好 Pigsty。

RDS成本与规模成本曲线‍‍


如果您可以用 十分之一的成本使用RDS服务,那么再用云数据库真的就是纯纯的智商税了。



参考

【1】为什么我们要离开云 https://world.hey.com/dhh/why-we-re-leaving-the-cloud-654b47e0

【2】上云“被坑”十年终放弃,寒冬里第一轮“下云潮”要来了? https://www.infoq.cn/article/qoq3v6jfenwwzmpg4fre

【3】vantage.sh EC2/RDS 价格 https://instances.vantage.sh/

【4】FIO测试AWS存储性能 https://github.com/Vonng/pgtpc/blob/master/fio/aws-ebs-bench.md

【5】阿里云RDS PG 增强监控 https://help.aliyun.com/document_detail/299200.html

【6】阿里云RDS PG 数据库自治服务 https://help.aliyun.com/document_detail/159166.html

【7】https://docs.opengauss.org/zh/docs/3.0.0/docs/Developerguide/AI4DB-%E6%95%B0%E6%8D%AE%E5%BA%93%E8%87%AA%E6%B2%BB%E8%BF%90%E7%BB%B4.html

【8】Me-Better RDS PostgreSQL 替代 Pigsty  https://pigsty.cc

【9】是时候和GPL说再见了【Martin Kleppmann】https://pg.vonng.com/#/post/goodbye-gpl


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存