为啥postgrelsql的性能没有mysql好

Posted 2023-03-26

一、 PostgreSQL 的稳定性极强， Innodb 等引擎在崩溃、断电之类的灾难场景下抗打击能力有了长足进步，然而很多 mysql 用户都遇到过Server级的数据库丢失的场景——mysql系统库是MyISAM的，相比之下，PG数据库这方面要好一些。
二、任何系统都有它的性能极限，在高并发读写，负载逼近极限下，PG的性能指标仍可以维持双曲线甚至对数曲线，到顶峰之后不再下降，而 MySQL 明显出现一个波峰后下滑（5.5版本之后，在企业级版本中有个插件可以改善很多，不过需要付费）。
三、PG 多年来在 GIS 领域处于优势地位，因为它有丰富的几何类型，实际上不止几何类型，PG有大量字典、数组、bitmap 等数据类型，相比之下mysql就差很多，instagram就是因为PG的空间数据库扩展POSTGIS远远强于MYSQL的my spatial而采用PGSQL的。

四、PG 的“无锁定”特性非常突出，甚至包括 vacuum 这样的整理数据空间的操作，这个和PGSQL的MVCC实现有关系。
五、PG 的可以使用函数和条件索引，这使得PG数据库的调优非常灵活，mysql就没有这个功能，条件索引在web应用中很重要。
六、PG有极其强悍的 SQL 编程能力（9.x 图灵完备，支持递归！），有非常丰富的统计函数和统计语法支持，比如分析函数（ORACLE的叫法，PG里叫window函数），还可以用多种语言来写存储过程，对于R的支持也很好。这一点上MYSQL就差的很远，很多分析功能都不支持，腾讯内部数据存储主要是MYSQL，但是数据分析主要是HADOOP+PGSQL。
七、PG 的有多种集群架构可以选择，plproxy 可以支持语句级的镜像或分片，slony 可以进行字段级的同步设置，standby 可以构建WAL文件级或流式的读写分离集群，同步频率和集群策略调整方便，操作非常简单。
八、一般关系型数据库的字符串有限定长度8k左右，无限长 TEXT 类型的功能受限，只能作为外部大数据访问。而 PG 的 TEXT 类型可以直接访问，SQL语法内置正则表达式，可以索引，还可以全文检索，或使用xml xpath。用PG的话，文档数据库都可以省了。
九，对于WEB应用来说，复制的特性很重要，mysql到现在也是异步复制，pgsql可以做到同步，异步，半同步复制。还有mysql的同步是基于binlog复制，类似oracle golden gate,是基于stream的复制，做到同步很困难，这种方式更加适合异地复制，pgsql的复制基于wal，可以做到同步复制。同时，pgsql还提供stream复制。
十，pgsql对于numa架构的支持比mysql强一些，比MYSQL对于读的性能更好一些，pgsql提交可以完全异步，而mysql的内存表不够实用（因为表锁的原因）

最后说一下我感觉 PG 不如 MySQL 的地方。
第一，MySQL有一些实用的运维支持，如 slow-query.log ，这个pg肯定可以定制出来，但是如果可以配置使用就更好了。
第二是mysql的innodb引擎，可以充分优化利用系统所有内存，超大内存下PG对内存使用的不那么充分，
第三点，MySQL的复制可以用多级从库，但是在9.2之前，PGSQL不能用从库带从库。
第四点，从测试结果上看，mysql 5.5的性能提升很大，单机性能强于pgsql，5.6应该会强更多.
第五点，对于web应用来说,mysql 5.6 的内置MC API功能很好用，PGSQL差一些。

另外一些：
pgsql和mysql都是背后有商业公司，而且都不是一个公司。大部分开发者，都是拿工资的。
说mysql的执行速度比pgsql快很多是不对的，速度接近，而且很多时候取决于你的配置。
对于存储过程，函数，视图之类的功能，现在两个数据库都可以支持了。
另外多线程架构和多进程架构之间没有绝对的好坏，oracle在unix上是多进程架构，在windows上是多线程架构。
很多pg应用也是24/7的应用，比如skype. 最近几个版本VACUUM基本不影响PGSQL 运行，8.0之后的PGSQL不需要cygwin就可以在windows上运行。
至于说对于事务的支持，mysql和pgsql都没有问题。 参考技术A 这个是需要依剧的，一般来说PostgreSQL在千万级数据量才有优势。测试也可能和平台硬件之类有关。PostgreSQL速度最快的在它的文档型数据库

Electron：为啥 BrowserView 的性能比 Webview 好？

【中文标题】Electron：为啥 BrowserView 的性能比 Webview 好？

【英文标题】：Electron: Why does BrowserView has better performance then Webview?Electron：为什么 BrowserView 的性能比 Webview 好？

【发布时间】：2021-06-04 05:02:16

【问题描述】：

我已经阅读过有关 Webview 和 BrowserView 的信息，它们似乎在做同样的事情：将额外的 Web 内容嵌入到应用程序中。我知道 Electron 的 webview 标签基于 Chromium 的 webview，并且这个 API 是已弃用的 Chrome Apps 平台的一部分。甚至 Electron 也建议不要使用 Webview 并考虑替代方案（iframe、BrowserView）。

但是是什么改变让 BrowserView 更胜一筹呢？我知道与 Webview 不同，BrowserView 不使用另一个渲染器进程，这就是为什么 BrowserView 具有更好的性能？其他指标是什么？ BrowserView 与 Webview 内部有何不同？

【参考方案1】：

这绝不是一个完整的答案，但BrowserView 是由于webview 遇到的各种问题而创建的。

Here's 创建者的博文：

一种嵌入 Web 应用程序的新方法，错误更少并提高了性能 webviews 起初似乎运行良好，但随着时间的推移，我们遇到了越来越多的问题。拖放等基本功能存在错误，总体性能根本无法与 Chrome 相提并论。

Electron 的 webview documentation 说：

Electron 的 webview 标签基于 Chromium 的 webview，它正在经历巨大的架构变化。这会影响 webview 的稳定性，包括渲染、导航和事件路由。

过去有很多webviewbugs，尽管这些特定的似乎已修复。

Here's 一个关于BrowserView 命运的问题，维护者说：

<webview> 仍然存在许多错误。还有一些架构问题，例如缓慢的自动调整大小，不太可能很快在 Chromium 中得到解决

Here 是许多 webview 错误（尽管您当然也可以通过 BrowserView 找到错误）

另外，你说：

BrowserView 不使用另一个渲染器进程

我相信我在某处也看到了对它的引用，但我认为那不是真的。

当您将BrowserView 导航到页面时，会为其创建一个新的渲染器进程。

更新：哦，我认为这里的意思是 webview == 1 进程和 BrowserView == 1 进程，但是您在另一个 Renderer 进程内创建 webview，而在主进程内创建 BrowserView。所以webview会有一个额外的过程。