包含postgresql好处的词条

你所知道的数据库有哪些?各有什么优缺点?

四、MySQL的主要优点

1、首先是速度，MySQL通常要比PostgreSQL快得多。MySQL自已也宣称速度是他们追求的主要目标之一，基于这个原因，MySQL在以前的文档中也曾经说过并不准备支持事务和触发器。但是在最新的文档中，我们看到MySQL 4.0.2-alpha已经开始支持事务，而且在MySQL的TODO中，对触发器、约束这样的注定会降低速度的功能也列入了日程。但是，我们仍然有理由相信，MySQL将有可能一直保持速度的优势。

2、MySQL比PostgreSQL更流行，流行对于一个商业软件来说，也是一个很重要的指标，流行意味着更多的用户，意味着经受了更多的考验，意味着更好的商业支持、意味着更多、更完善的文档资料。

3、与PostgreSQL相比，MySQL更适宜在Windows环境下运行。MySQL作为一个本地的Windows应用程序运行(在NT/Win2000/WinXP下，是一个服务)，而PostgreSQL是运行在Cygwin模拟环境下。PostgreSQL在Windows下运行没有MySQL稳定，应该是可以想象的。

4、MySQL使用了线程，而PostgreSQL使用的是进程。在不同线程之间的环境转换和访问公用的存储区域显然要比在不同的进程之间要快得多。

5、MySQL可以适应24/7运行。在绝大多数情况下，你不需要为MySQL运行任何清除程序。PostgreSQL目前仍不完全适应24/7运行，这是因为你必须每隔一段时间运行一次VACUUM。

6、MySQL在权限系统上比PostgreSQL某些方面更为完善。PostgreSQL只支持对于每一个用户在一个数据库上或一个数据表上的INSERT、SELECT和UPDATE/DELETE的授权，而MySQL允许你定义一整套的不同的数据级、表级和列级的权限。对于列级的权限，PostgreSQL可以通过建立视图，并确定视图的权限来弥补。MySQL还允许你指定基于主机的权限，这对于目前的PostgreSQL是无法实现的，但是在很多时候，这是有用的。

7、由于MySQL 4.0.2-alpha开始支持事务的概念，因此事务对于MySQL不再仅仅成为劣势。相反，因为MySQL保留无事务的表类型。这就为用户提供了更多的选择。

8、MySQL的MERGE表提供了一个独特管理多个表的方法。

9、MySQL的myisampack可以对只读表进行压缩，此后仍然可以直接访问该表中的行。

相关问答

Q1: 若要玩转大数据，在什么应用场景使用Hadoop，PostgreSQL

但是由于“大数据”和“Hadoop”这两个热门词，即使很多人实际上不需要Hadoop，他们也愿意穿上“紧身衣”。

一、如果我的数据量是几百兆，Excel可能没法加载它

对于Excel软件来说的“很大的数据”并非大数据，其实还有其它极好的工具可以使用——我喜欢的Pandas。Pandas构建于Numpy库 之上，可以以矢量格式的方式有效地把数百兆的数据载入到内存中。在我购买已3年的笔记本上，它可以用Numpy在一眨眼的功夫把1亿的浮点数乘在一起。 Matlab和R也是极好的工具。

对于几百兆的数据量，典型的做法是写一个简单的Python脚本按行读取文件行，并处理它，向另一个文件写入。

二、如果我的数据是10GB呢

我买了个新笔记本，它有16GB的内存和256GB的SSD。如果你要载入一个10GB的CSV文件到Pandas，它占用的内存实际上是很小的 ——其结果是以数字类型的字符串保存的，如“17284832583”作为4字节货8字节的整数，或存储“284572452.2435723”字符串作 为8字节的双精度浮点数。

最坏的情况是你或许不能把所有的数据都同时载入到内存中。

三、如果我的数据是100GB、500GB或1TB呢

买个2TB或4TB的硬盘，在桌面PC或服务器上安装一个Postgre来解决它。

四、Hadoop远远比不上SQL或Python脚本

在计算的表达方面，Hadoop弱于SQL，也弱于Python脚本。

SQL是一个很直接的查询语言，适合做业务分析，SQL的查询相当简单，而且还非常快——如果你的数据库使用了正确的索引，二级查询或多级查询另当别论。

Hadoop没有索引的概念，Hadoop只有全表扫描，Hadoop有高度泄露抽象——我花了很多时间来处理Java的内存错误、文件碎片以及集群竞争，这些时间远大于我花在数据分析上的时间。

如果你的数据并不是像SQL表那样的结构化数据（比如纯文本、JSON对象、二进制对象），通常是直接写一个小的Python脚本来按行处理你的数据。把数据存储于文件，处理每一个文件，等等。如果换成是Hadoop就很麻烦。

相比于SQL或Python脚本，Hadoop要慢的多。正确的使用索引后，SQL查询总是非快——PostgreSQL简单的查找索引，检索确 切的键值。而Hadoop是全表扫描的，它会把整个表进行重新排序。通过把数据表分片到多台计算机上后，重排序是很快的。另一方面，处理二进制对 象，Hadoop需要重复往返于命名节点，目的是查找和处理数据。这适合用Python脚本来实现。

五、我的数据超过了5TB

你应该考虑使用Hadoop，而无需做过多的选择。

使用Hadoop唯一的好处是可伸缩性非常好。如果你有一个包含了数TB数据的表，Hadoop有一个适合全表扫描的选项。如果你没有这样大数据量的表，那么你应该像躲避瘟疫那样避免使用Hadoop。这样使用传统的方法来解决问题会更轻松。

六、Hadoop是一个极好的工具

我并不讨厌Hadoop，当我用其它工具不能很好处理数据时我会选择Hadoop。另外，我推荐使用Scalding，不要使用Hive或Pig。Scalding支持使用Scala语言来编写Hadoop任务链，隐藏了其下的MapReduce。

Q2: 如何扩大postgresql存储空间

1. 概述

cstore_fdw实现了 PostgreSQL 数据库的列式存储。列存储非常适合用于数据分析的场景，数据分析的场景下数据是批量加载的。

这个扩展使用了Optimized Row Columnar (ORC)数据存储格式，ORC改进了Facebook的RCFile格式，带来如下好处:

压缩:将内存和磁盘中数据大小削减到2到4倍。可以扩展以支持不同压缩算法。

列投影:只提取和查询相关的列数据。提升IO敏感查询的性能。

跳过索引:为行组存储最大最小统计值，并利用它们跳过无关的行。

2. 使用

cstore_fdw的安装和使用都非常简单，可以参考官方资料。

thub.com/citusdata/cstore_fdw

注)注意cstore_fdw只支持PostgreSQL9.3和9.4 。

下面做几个简单的性能对比，看看cstore_fdw究竟能带来多大的性能提升。

2.1 数据加载

2.1.1 普通表

CREATE TABLE tb1

(

id int,

c1 TEXT,

c2 TEXT,

c3 TEXT,

c4 TEXT,

c5 TEXT,

c6 TEXT,

c7 TEXT,

c8 TEXT,

c9 TEXT,

c10 TEXT

);

注:要和普通表的全表扫描作对比，所以不建主键和索引。

[postgres@node2 chenhj]$ time psql -p 40382 -At -F, -c "select id,id::text,id::text,id::text,id::text,id::text,id::text,id::text,id::text,id::text,id::text from generate_series(1,10000000) id"|time psql -p 40382 -c "copy tb1 from STDIN with CSV"

COPY 10000000

1.56user 1.00system 6:42.39elapsed 0%CPU (0avgtext+0avgdata 7632maxresident)k

776inputs+0outputs (17major+918minor)pagefaults 0swaps

real 6m42.402s

user 0m15.174s

sys 0m14.904s

postgres=# select pg_total_relation_size('tb1'::regclass);

pg_total_relation_size

------------------------

1161093120

(1 row)

postgres=# \timing

Timing is on.

postgres=# analyze tb1;

ANALYZE

Time: 11985.070 ms

插入1千万条记录，数据占用存储大小1.16G，插入耗时6分42秒，分析耗时12秒。

2.1.2 cstore表

$ mkdir -p /home/chenhj/data94/cstore

CREATE EXTENSION cstore_fdw;

CREATE SERVER cstore_server FOREIGN DATA WRAPPER cstore_fdw;

CREATE FOREIGN TABLE cstb1

(

id int,

c1 TEXT,

c2 TEXT,

c3 TEXT,

c4 TEXT,

c5 TEXT,

c6 TEXT,

c7 TEXT,

c8 TEXT,

c9 TEXT,

c10 TEXT

)

SERVER cstore_server

OPTIONS(filename '/home/chenhj/data94/cstore/cstb1.cstore',

compression 'pglz');

[postgres@node2 chenhj]$ time psql -p 40382 -At -F, -c "select id,id::text,id::text,id::text,id::text, id::text,id::text,id::text,id::text,id::text,id::text from generate_series(1,10000000) id"|time psql -p 40382 -c "copy cstb1 from STDIN with CSV"

COPY 10000000

1.53user 0.78system 7:35.15elapsed 0%CPU (0avgtext+0avgdata 7632maxresident)k

968inputs+0outputs (20major+920minor)pagefaults 0swaps

real 7m35.520s

user 0m14.809s

sys 0m14.170s

[postgres@node2 chenhj]$ ls -l /home/chenhj/data94/cstore/cstb1.cstore

-rw------- 1 postgres postgres 389583021 Jun 23 17:32 /home/chenhj/data94/cstore/cstb1.cstore

postgres=# \timing

Timing is on.

postgres=# analyze cstb1;

ANALYZE

Time: 5946.476 ms

插入1千万条记录，数据占用存储大小390M，插入耗时7分35秒，分析耗时6秒。

使用cstore列存储后，数据占用存储大小降到普通表的3分之1。需要说明的是，由于所有TEXT列填充了随机数据，压缩率不算高，某些实际的应用场景下压缩效果会比这更好。

2.2 Text列的like查询性能对比

2.2.1 普通表

清除文件系统缓存，并重启PostgreSQL

[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart

[root@node2 ~]# free

total used free shared buffers cached

Mem: 2055508 771356 1284152 0 9900 452256

-/+ buffers/cache: 309200 1746308

Swap: 4128760 387624 3741136

[root@node2 ~]# echo 1 /proc/sys/vm/drop_caches

[root@node2 ~]# free

total used free shared buffers cached

Mem: 2055508 326788 1728720 0 228 17636

-/+ buffers/cache: 308924 1746584

Swap: 4128760 381912 3746848

对Text列执行like查询

[postgres@node2 chenhj]$ iostat -k dm-2

Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

0.80 0.00 0.38 3.42 0.00 95.40

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

dm-2 58.55 330.68 212.08 7351441 4714848

[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where c1 like '%66'"

count

--------

100000

(1 row)

real 0m7.051s

user 0m0.001s

sys 0m0.004s

[postgres@node2 chenhj]$ iostat -k dm-2

Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

0.80 0.00 0.38 3.43 0.00 95.39

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

dm-2 58.90 381.53 211.90 8489597 4714956

耗时7.1秒，产生IO读1.14G,IO写108K。

不清文件系统缓存，不重启PostgreSQL，再执行一次。消耗时间降到1.6秒，几乎不产生IO。

[postgres@node2 chenhj]$ iostat -k dm-2

Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

0.80 0.00 0.38 3.43 0.00 95.39

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

dm-2 58.81 332.20 213.06 7350301 4714364

[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where c1 like '%66'"

count

--------

100000

(1 row)

real 0m1.601s

user 0m0.002s

sys 0m0.001s

[postgres@node2 chenhj]$ iostat -k dm-2

Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

0.80 0.00 0.38 3.43 0.00 95.38

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

dm-2 58.80 332.12 213.01 7350337 4714364

2.2.2 cstore表

清除文件系统缓存，并重启PostgreSQL

[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart

[root@node2 ~]# echo 1 /proc/sys/vm/drop_caches

对Text列执行like查询

[postgres@node2 chenhj]$ iostat -k dm-2

Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

0.80 0.00 0.38 3.38 0.00 95.45

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

dm-2 58.12 376.42 209.04 8492017 4716048

[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from cstb1 where c1 like '%66'"

count

--------

100000

(1 row)

real 0m2.786s

user 0m0.002s

sys 0m0.003s

[postgres@node2 chenhj]$ iostat -k dm-2

Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

0.80 0.00 0.38 3.38 0.00 95.44

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

dm-2 58.12 378.75 208.89 8550761 4716048

耗时2.8秒，产生IO读59M,IO写0K。执行时间优化的虽然不是太多，但IO大大减少，可见列投影起到了作用。

不清文件系统缓存，不重启PostgreSQL，再执行一次。消耗时间降到1.4秒，几乎不产生IO。

[postgres@node2 chenhj]$ iostat -k dm-2

Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

0.80 0.00 0.38 3.36 0.00 95.47

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

dm-2 57.75 376.33 207.58 8550809 4716524

[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from cstb1 where c1 like '%66'"

count

--------

100000

(1 row)

real 0m1.424s

user 0m0.002s

sys 0m0.001s

[postgres@node2 chenhj]$ iostat -k dm-2

Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

0.80 0.00 0.38 3.36 0.00 95.47

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

dm-2 57.70 375.96 207.38 8550809 4716588

2.3 对Int列执行=查询

2.3.1 普通表

清除文件系统缓存，并重启PostgreSQL后

[postgres@node2 chenhj]$ pg_ctl -D /home/chenhj/data94 -l logfile94 restart

[root@node2 ~]# echo 1 /proc/sys/vm/drop_caches

对Int列执行=查询

[postgres@node2 chenhj]$ iostat -k dm-2

Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

0.79 0.00 0.37 3.33 0.00 95.50

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

dm-2 57.25 373.21 205.67 8560897 4717624

[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where id =666666"

count

-------

1

(1 row)

real 0m6.844s

user 0m0.002s

sys 0m0.006s

[postgres@node2 chenhj]$ iostat -k dm-2

Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

0.79 0.00 0.37 3.34 0.00 95.49

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

dm-2 57.60 422.57 205.54 9699161 4717708

耗时6.8秒，产生IO读1.14G,IO写84K

不清缓存，再执行一次。消耗时间降到1.1秒，几乎不产生IO。

[postgres@node2 chenhj]$ iostat -k dm-2

Linux 2.6.32-71.el6.x86_64 (node2) 06/23/14 _x86_64_ (2 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

0.79 0.00 0.37 3.33 0.00 95.50

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

dm-2 57.44 421.37 204.97 9699177 4718032

[postgres@node2 chenhj]$ time psql -p 40382 -c "select count(*) from tb1 where id =666666"

count

-------

Q3: 三分钟！彻底搞懂PostgreSQL 和 MySQL 区别之分

PostgreSQL 和 MySQL 是将数据组织成表的关系数据库。这些表可以根据每个表共有的数据链接或关联。关系数据库使您的企业能够更好地了解可用数据之间的关系，并帮助获得新的见解以做出更好的决策或发现新的机会。

PostgreSQL 和 MySQL 都依赖于 SQL（结构化查询语言），这是与管理系统交互的标准语言。SQL 允许使用具有简单结构的几行源代码连接表，大多数非技术员工可以快速学习。

使用 SQL，分析师不需要知道订单表在磁盘上的位置、如何执行查找以查找特定订单或如何连接订单表和客户表。数据库编译查询并计算出正确的数据点。

MySQL 和 PostgreSQL 都支持 JavaScript Object Notation (JSON) 存储和传输数据，尽管 PostgreSQL 也支持 JSONB，这是 JSON 的二进制版本，它消除了键的重复和无关的空格。

除了传统的支持机制外，这两个数据库都提供强大的社区支持。

PostgreSQL，也称为 Postgres，是一种开源关系数据库，因其可靠性、灵活性和对开放技术标准的支持而享有盛誉。PostgreSQL 支持非关系和关系数据类型。它被称为当今可用的最兼容、最稳定和最成熟的关系数据库之一，并且可以轻松处理复杂的查询。

PostgreSQL 的特性包括：

PostgreSQL 这是一个“一刀切”的解决方案，适用于许多寻求经济高效的方法来改进其数据库管理系统 (DBMS) 的企业。它具有足够的可扩展性和多功能性，可以通过强大的扩展生态系统快速支持各种专业用例，涵盖时间序列数据类型和地理空间分析等工作。作为开源数据库解决方案构建的 PostgreSQL 完全不受许可限制、供应商锁定的可能性或过度部署的风险。PostgreSQL 通过对象关系数据库管理系统 (ORDBMS) 进行管理。

PostgreSQL 负责管理业务活动的在线事务处理 (OLTP)协议的企业数据库管理员提供了理想的解决方案，包括电子商务、客户关系管理系统 (CRM) 和财务分类帐。它也是管理接收、创建和生成的数据分析的理想选择。

这些是 PostgreSQL 的一些主要优点：

MySQL — 一种快速、可靠、可扩展且易于使用的开源关系数据库系统 — 旨在处理关键任务、高负载的生产应用程序。它是一种常见且易于启动的数据库，内存、磁盘和 CPU 利用率较低，有关系数据库管理系统 (RDMS) 管理。MySQL Community Edition 是一个由活跃的在线社区支持的免费下载版本。

MySQL 功能包括所有 SQL 标准命令以及事务和 ACID 合规性（代表原子性、一致性、隔离性和持久性）。

两个最常见的关系数据库是什么 MySQL 和 Oracle。MySQL 不是 SQL Server 的同义词，SQL Server 是 Microsoft 许可产品，与 MAC OS X 缺乏兼容性。

MariaDB 经常与 MySQL 混淆，它是 MySQL 的一个开源分支，速度更快，提供更多存储引擎 (12)，但功能有限。MySQL 和 MariaDB 使用的存储引擎都是 InnoDB。InnoDB 提供标准的 ACID 兼容特性。与 MySQL 不同，MariaDB 不支持数据屏蔽或动态列表。

MySQL 通常用作 Web 数据库来存储各种信息类型，从单个信息数据点到为组织提供的产品或服务的完整列表。它是LAMP（Linux 操作系统、Apache HTTP 服务器、MySQL RDBMS 和 PHP 编程语言）的基础组件，这是一种有助于创建API、Web 应用程序和网站的软件堆栈模型。

MySQL Workbench 是一个单一的、集成的可视化 SQL 平台，用于 MySQL 数据库的创建、开发、设计和管理。

MySQL 为市场提供了许多好处，包括：

PostgreSQL 和 MySQL 之间有很多不同之处。特性、功能和优势方面的一些差异如下：

总之，PostgreSQL 和 MySQL 都有不同的用途，它们之间的选择取决于企业目标和资源。一般来说，PostgreSQL 是一个更强大、更高级的数据库管理系统，非常适合需要在大型环境中快速执行复杂查询的组织。但是，对于预算和空间更受限制的公司来说，MySQL 是一个理想的解决方案。

Q4: 常用数据库系统简介

码字不容易啊，望采纳。

ORACLE (甲骨文，美国)

优点：产品系列齐全，几乎囊括所有应用领域，大型，完善，安全，可以支持多个实例同时运行，功能强。能在所有主流平台上运行（包括 windows）。完全支持所有的工业标准。采用完全开放策略。可以使客户选择最适合的解决方案。对开发商全力支持。

缺点：价格成本，服务费用，后期产品追加费用，管理维护相对麻烦，对硬件的要求高。

几乎匹配所有动态网页设计，性能优越。

SQLSERVER（微软，美国）

优点：简单，界面友好，上手容易，只能在WINDOWS平台下使用。一般用于.net 程序设计。Windows9X系列产品是偏重于桌面应用，NT server只适合中小型企业。

缺点：windows平台的可靠性，安全性和伸缩性是非常有限的。它不象unix那样久经考验，尤其是在处理大数据量的关键业务时。

网页设计多与C#（也是微软的）经典组合，不过也是几乎开放所有开发语言接口

MYSQL （被oracle收购，收购后的新版已出，市场反应一般）

优点：免费，功能不错,是开源的，体积小，并发执行的数据库,如今mysql逐渐体现出性价比高的优势。

缺点：稳定性有待考量，面对大量数据的处理能力有限，并发性处理的机制不健全。

网页开发mysql的应用还是很多的，应用比较广泛。

DB2 （IBM 美国）

优点：优点很多啦，与oracle一样是大型以及超大型的数据库，能力当然很好啦，企业解决方案很牛X，在金融和电信方运用DB2的很多，最适于海量数据。DB2在企业级的应用最为广泛,在全球的500家最大的企业中,几乎85%以上用DB2数据库服务器,而国内到97年约占5%。不过与oracle相比db2的应用相对较窄，一是价钱很贵，二是主要面向大型企业，市场份额还是oracle最高，所以db2专家较少，很吃香的。

以db2的优质能力相对海量并发的web服务和访问比较轻松啦。

Access（微软，美国）：

优点：操作简洁、方便，不用依赖Server也可以对数据进行操作。

缺点：安全性不够，如果做为服务器的话，对服务器要求很高，否则容易造成 MDB 损坏，高强度操作适应性差，不能将 VBA 代码开发的软件系统直接编译成 EXE 可执行文件，不能脱离 ACCESS 或者 ACCESS RUNTIME 环境，该环境相对其他软件体积较大（50M左右），每个数据库文件最大限制只有2G，对于大型网站显然不能够胜任。

我接触的access应用比较少啦，关于开发的不了解了。

Sybase（Sybase 美国）：

优点：操作简单，管理相对容易，对新手很好理解，上手快，曾经的sybase还是挺辉煌的，sybase 数据仓库还是挺不错，大数据的解决方案也不错，与oracle，db2齐名，但是之后似乎难以追随市场的脚步了。

缺点：Sybase使用的编程接口不是开放的，没有使用SQL92等相关的标准，因此编制存储程序和触发器所用的Transact-SQL也是它们自己专用的。 优化器(OPTIMIZER)不能有效的支持复杂的查询(ComplexQueries)。应用程序中稍微复杂一些的SQL语句，Sybase的优化器就无法妥善优化处理。已经退出主流数据库市场，市场份额缩水严重，被SAP收购后前途待观望。

web应用还是比较广泛的啦。

informix（被IBM收购）：

优点：如今被IBM定位为作为IBM在线事务处理（OLTP）旗舰级数据服务系统，使用不是很广泛，IBM对Informix和DB2都有长远的规划，两个数据库产品互相吸取对方的技术优势。

缺点：INFORMIX是以小型数据库起家，所以其产品设计到目前为止仍有许多小型数据库的限制。许多用户都曾遇到INFORMIX在数据存储、日志管理、备份、恢复等方面的问题。Informix的扩展并行选项在支持多用户并发访问时存在困难。INFORMIX由于缺乏对大量数据的管理经验，所以其优化器技术也不能针对大量数据做优化。 小型企业可以尝试使用。

postgresql（美国）：

优点：轻盈好用的数据库，有点很多，如优化排序性能，内存占用更少；表继承（很强），提高加锁效率和并发度；创建索引过程中允许INSERT/UPDATE/DELETE等等。

缺点：不足之处就是大数量的场景有待市场检验，目前触及海量数据的案例较少。

如果对你有帮助.请点击我的回答下方【选为满意回答】按钮