为什么 PostgreSQL 没有 MySQL 流行

1、MySQL崛起那会，PG虽然已经有许多高级特性，但那些特性互联网用不着，互联网需要的特性——快速——那时的PG不具备。历史延续下来，造成了今天的局面。可以说互联网成就了MySQL.

成都创新互联是一家专业提供潮阳企业网站建设,专注与网站制作、成都做网站、H5开发、小程序制作等业务。10年已为潮阳众多企业、政府机构等服务。创新互联专业网站建设公司优惠进行中。

2、MySQL的主从复制、增量备份比PG设置简单（知道PG的增量备份多耗磁盘不！），这些特性在互联网是很有用的。而旧的pg　vacuum不如今天的友好。这些都限制了他在早期的崛起。

3、不认为商业支持是主要原因——有几个用MySQL的是买了商业支持的？倒是有些心理上的影响。

4、今天两者性能、特性上相差不多，而我认为pg略胜一筹，但大局在适时间内难改变——习惯造成的。

postgresql已经配置好主从，java中怎么进行读写分离

新建一个java项目，项目的目录结构如下所示，其中ReadRunnable.java是读文件的线程类，WriteRunnable.java是写文件的线程类，Test.java是代表读写文件的实现类及main方法入口类

ReadRunnable.java的代码实现

WriteRunnable.java的代码实现

Test.java的代码实现

mysql 主从复制 延时多大

主从复制延迟的监测，我以前的做法是通过比较show slave statusG中的两个变量的差值（Read_Master_Log_Pos，Exec_Master_Log_Pos），将差值设置为一个自己认为合理的范围，Seconds_Behind_Master 没有适用过，今天做一次解析:

Seconds_Behind_Master 是通过比较 SQL THREAD 接受 events事件的时间戳（timestamp） 与IO THREAD 执行事件 events时间戳的差值--秒数来确定slave 落后于master多少。如果主从机器的时间不同，该时间的计算也是不会受影响的（如果时间发生异常，则这个秒数的就不怎么可靠啦）

如果slave SQL thread 或者 slave I/O thread 或者没有连接到master，那么该变量的值为NULL.

0：表示master slave 复制没有延迟（大部分情况下是这个样子）。

正值：表示slave落后于master的秒数。

在网络很快的情况下，I/O thread 能够很快的从master上获取binlog到slave的 relay-log。这种情况下， seconds_behind_master的值能真正代表slave落后于master的秒数。在网络很差的情况下，I/O thread 同步很慢，slave收到的二进制日志信息，SQL THREAD能够很快的执行。这个时候 seconds_behind_master 是0，这种情况下 slave落后于master很多。

为了排除网络的干扰，我们可以参考percona 的工具 pt-heartbeat.

该工具可以计算出MySQL复制或者是PostgreSQL,它可以更新master或者监控复制。它还可以从my.cnf 读取配置。它借助timestmp的比较实现的，首先需要保证主从服务器时间必须要保持一致，通过与相同的一个NTP server同步时钟。它需要在主库上创建一个heartbeat的表，里面的时间戳ts就是当前的时间戳 now()，该结构也会被复制到从库上。表建好以后，会在主库上以后台进程的模式去执行一行更新操作的命令，定期去向表中的插入数据，这 个周期默认为1 秒，同时从库也会在后台执行一个监控命令，与主库保持一致的周期+0.5S（默认0.5S延迟检查）去比较，复制过来记录的ts值与主库上的同一条ts值，差值为0表示无延时，差值越大表示 延时的秒数越多。

SQLite，MySQL和PostgreSQL 三种关系数据库哪个好

这三个具体都有各自的有点和缺点，哪个好需要看使用在什么地方

1、什么时候要用 SQLite

a)、嵌入式应用 所有需要迁移性，不需要扩展的应用，例如，单用户的本地应用，移动应用和游戏

b)、代替磁盘访问 在很多情况下，需要频繁直接读/写磁盘文件的应用，都很适合转为使用 SQLite ，可以得益于 SQLite 使用 SQL 带来的功能性和简洁性

c)、测试 它能秒杀大部分专门针对应用业务逻辑（也就是应用的主要目的：能完成功能）的测试

2、什么时候不要用SQLite

a)、多用户应用 如果你在开发的应用需要被多用户访问，而且这些用户都用同一个数据库，那么相比 SQLite 最好还是选择一个功能完整的关系型数据库（例如 MySQL）

b)、需要大面积写入数据的应用 SQLite 的缺陷之一是它的写入操作。这个数据库同一时间只允许一个写操作，因此吞吐量有限

3、何时使用 MySQL？

a)、分布式操作 当你需要的比SQLite可以提供的更多时，把MySQL包括进你的部署栈，就像任何一个独立的数据库服务器，会带来大量的操作自由和一些先进的功能

b)、高安全性 MySQL的安全功能，用一种简单的方式为数据访问（和使用）提供了可靠的保护

c)、Web网站 和 Web应用 绝大多数的网站（和Web应用程序）可以忽视约束性地简单工作在MySQL上。这种灵活的和可扩展的工具是易于使用和易于管理的——这被证明非常有助于长期运行

d)、定制解决方案 如果你工作在一个高度量身定制的解决方案上，MySQL能够很容易地尾随和执行你的规则，这要感谢其丰富的配置设置和操作模式

4、何时不用 MySQL？

a)、SQL 服从性 因为 MySQL 没有[想要]实现 SQL 的全部标准，所以这个工具不完全符合SQL。如果你需要对这样的关系数据库管理系统进行整合，从MySQL进行切换是不容易的

b)、并发 即使MySQL和一些存储引擎能够真地很好执行读取操作，但并发读写还是有问题的

c)、缺乏特色 再次提及，根据数据库引擎的选择标准，MySQL会缺乏一定的特性，如全文搜索

5、何时使用PostgreSQL？

a)、数据完整性 当可靠性和数据完整性是绝对必要而无需理由时，PostgreSQL是更好的选择

b)、复杂的自定义过程 如果你需要你的数据库执行自定义过程，可扩展的PostgreSQL是更好的选择

c)、整合 在将来，如果可能要把整个数据库系统迁移到另一个适当的解决方案（例如Oracle）中，PostgreSQL对于这种切换将是最兼容和易于操作的

d)、复杂的设计 相比其他的开源和免费的 RDBMS（关系数据库管理系统）实现来说，对于复杂的数据库设计，PostgreSQL提供了大部分的功能和可能性，同时并没放弃其他有价值的地方

6、何时不用 PostgreSQL？

a)、速度 如果你需要的只是快速的读取操作, PostgreSQL 不是为此而准备的工具

b)、简化体制 除非你需要绝对的数据完整性，原子性，一致性，隔离性，耐久性，或复杂的设计，PostgreSQL 对简化体制来说是杀手

c)、复制 除非你愿意花不少时间，精力和资源，否则对于那些缺乏数据库和系统管理经验的人来说，实现与MySQL的（主从）复制可能不容易

Linux系统，oracle 11g 主从同步中，怎么区分主库与从库，可以在从库上执行增删改操作吗？

你说的是oracle的dg技术吗？可以使用select open_mode，database_role from v$database语句查询数据库角色

oracle的从库有三种角色，物理备库、逻辑备库、快照备库。

物理备库只能处于只读状态，无法执行写的操作

逻辑备库处于读写的状态，但是在备库写入的数据不会同步到主库的

快照备库处于读写状态，类似于给数据库创建一个还原点。

三者之间是可以互相转换的。

网页标题：包含postgresql主从的词条
当前路径：http://ybzwz.com/article/dscpigi.html