postgresqlredis缓存
特性 MySQL PostgreSQL
实例 通过执行 MySQL 命令（mysqld）启动实例。一个实例可以管理一个或多个数据库。一台服务器可以运行多个 mysqld 实例。一个实例管理器可以监视 mysqld 的各个实例。
通过执行 Postmaster 进程（pg_ctl）启动实例。一个实例可以管理一个或多个数据库，这些数据库组成一个集群。集群是磁盘上的一个区域，这个区域在安装时初始化并由一个目录组成，所有数据都存储在这个目录中。使用 initdb 创建第一个数据库。一台机器上可以启动多个实例。
数据库 数据库是命名的对象集合，是与实例中的其他数据库分离的实体。一个 MySQL 实例中的所有数据库共享同一个系统编目。 数据库是命名的对象集合，每个数据库是与其他数据库分离的实体。每个数据库有自己的系统编目，但是所有数据库共享 pg_databases。
数据缓冲区 通过 innodb_buffer_pool_size 配置参数设置数据缓冲区。这个参数是内存缓冲区的字节数，InnoDB 使用这个缓冲区来缓存表的数据和索引。在专用的数据库服务器上，这个参数最高可以设置为机器物理内存量的 80%。 Shared_buffers 缓存。在默认情况下分配 64 个缓冲区。默认的块大小是 8K。可以通过设置 postgresql.conf 文件中的 shared_buffers 参数来更新缓冲区缓存。
数据库连接 客户机使用 CONNECT 或 USE 语句连接数据库，这时要指定数据库名，还可以指定用户 id 和密码。使用角色管理数据库中的用户和用户组。 客户机使用 connect 语句连接数据库，这时要指定数据库名，还可以指定用户 id 和密码。使用角色管理数据库中的用户和用户组。
身份验证 MySQL 在数据库级管理身份验证。 基本只支持密码认证。 PostgreSQL 支持丰富的认证方法：信任认证、口令认证、Kerberos 认证、基于 Ident 的认证、LDAP 认证、PAM 认证
加密 可以在表级指定密码来对数据进行加密。还可以使用 AES_ENCRYPT 和 AES_DECRYPT 函数对列数据进行加密和解密。可以通过 SSL 连接实现网络加密。 可以使用 pgcrypto 库中的函数对列进行加密/解密。可以通过 SSL 连接实现网络加密。
审计 可以对 querylog 执行 grep。 可以在表上使用 PL/pgSQL 触发器来进行审计。
查询解释 使用 EXPLAIN 命令查看查询的解释计划。 使用 EXPLAIN 命令查看查询的解释计划。
备份、恢复和日志 InnoDB 使用写前（write-ahead）日志记录。支持在线和离线完全备份以及崩溃和事务恢复。需要第三方软件才能支持热备份。 在数据目录的一个子目录中维护写前日志。支持在线和离线完全备份以及崩溃、时间点和事务恢复。 可以支持热备份。
JDBC 驱动程序 可以从 参考资料 下载 JDBC 驱动程序。 可以从 参考资料 下载 JDBC 驱动程序。
表类型 取决于存储引擎。例如，NDB 存储引擎支持分区表，内存引擎支持内存表。 支持临时表、常规表以及范围和列表类型的分区表。不支持哈希分区表。 由于PostgreSQL的表分区是通过表继承和规则系统完成了，所以可以实现更复杂的分区方式。
索引类型 取决于存储引擎。MyISAM：BTREE，InnoDB：BTREE。 支持 B-树、哈希、R-树和 Gist 索引。
约束 支持主键、外键、惟一和非空约束。对检查约束进行解析，但是不强制实施。 支持主键、外键、惟一、非空和检查约束。
存储过程和用户定义函数 支持 CREATE PROCEDURE 和 CREATE FUNCTION 语句。存储过程可以用 SQL 和 C++ 编写。用户定义函数可以用 SQL、C 和 C++ 编写。 没有单独的存储过程，都是通过函数实现的。用户定义函数可以用 PL/pgSQL（专用的过程语言）、PL/Tcl、PL/Perl、PL/python 、SQL 和 C 编写。
触发器 支持行前触发器、行后触发器和语句触发器，触发器语句用过程语言复合语句编写。 支持行前触发器、行后触发器和语句触发器，触发器过程用 C 编写。
系统配置文件 my.conf Postgresql.conf
数据库配置 my.conf Postgresql.conf
客户机连接文件 my.conf pg_hba.conf
XML 支持 有限的 XML 支持。 有限的 XML 支持。
数据访问和管理服务器 OPTIMIZE TABLE —— 回收未使用的空间并消除数据文件的碎片
myisamchk -analyze —— 更新查询优化器所使用的统计数据（MyISAM 存储引擎）
mysql —— 命令行工具
MySQL Administrator —— 客户机 GUI 工具 Vacuum —— 回收未使用的空间
Analyze —— 更新查询优化器所使用的统计数据
psql —— 命令行工具
pgAdmin —— 客户机 GUI 工具
并发控制 支持表级和行级锁。InnoDB 存储引擎支持 READ_COMMITTED、READ_UNCOMMITTED、REPEATABLE_READ 和 SERIALIZABLE。使用 SET TRANSACTION ISOLATION LEVEL 语句在事务级设置隔离级别。 支持表级和行级锁。支持的 ANSI 隔离级别是 Read Committed（默认 —— 能看到查询启动时数据库的快照）和 Serialization（与 Repeatable Read 相似 —— 只能看到在事务启动之前提交的结果）。使用 SET TRANSACTION 语句在事务级设置隔离级别。使用 SET SESSION 在会话级进行设置。
MySQL相对于PostgreSQL的劣势：
MySQL
PostgreSQL
最重要的引擎InnoDB很早就由Oracle公司控制。目前整个MySQL数据库都由Oracle控制。
BSD协议，没有被大公司垄断。
对复杂查询的处理较弱，查询优化器不够成熟
很强大的查询优化器，支持很复杂的查询处理。
只有一种表连接类型:嵌套循环连接(nested-loop),不支持排序-合并连接(sort-merge join)与散列连接(hash join)。
都支持
性能优化工具与度量信息不足
提供了一些性能视图，可以方便的看到发生在一个表和索引上的select、delete、update、insert统计信息，也可以看到cache命中率。网上有一个开源的pgstatspack工具。
InnoDB的表和索引都是按相同的方式存储。也就是说表都是索引组织表。这一般要求主键不能太长而且插入时的主键最好是按顺序递增，否则对性能有很大影响。
不存在这个问题。
大部分查询只能使用表上的单一索引;在某些情况下，会存在使用多个索引的查询,但是查询优化器通常会低估其成本,它们常常比表扫描还要慢。
不存在这个问题
表增加列，基本上是重建表和索引，会花很长时间。
表增加列，只是在数据字典中增加表定义，不会重建表
存储过程与触发器的功能有限。可用来编写存储过程、触发器、计划事件以及存储函数的语言功能较弱
除支持pl/pgsql写存储过程，还支持perl、python、Tcl类型的存储过程：pl/perl，pl/python，pl/tcl。
也支持用C语言写存储过程。
不支持Sequence。
支持
不支持函数索引，只能在创建基于具体列的索引。
不支持物化视图。
支持函数索引，同时还支持部分数据索引，通过规则系统可以实现物化视图的功能。
执行计划并不是全局共享的, 仅仅在连接内部是共享的。
执行计划共享
MySQL支持的SQL语法(ANSI SQL标准)的很小一部分。不支持递归查询、通用表表达式（Oracle的with 语句）或者窗口函数（分析函数）。
都 支持
不支持用户自定义类型或域(domain)
支持。
对于时间、日期、间隔等时间类型没有秒以下级别的存储类型
可以精确到秒以下。
身份验证功能是完全内置的，不支持操作系统认证、PAM认证，不支持LDAP以及其它类似的外部身份验证功能。
支持OS认证、Kerberos 认证 、Ident 的认证、LDAP 认证、PAM 认证
不支持database link。有一种叫做Federated的存储引擎可以作为一个中转将查询语句传递到远程服务器的一个表上,不过,它功能很粗糙并且漏洞很多
有dblink，同时还有一个dbi-link的东西，可以连接到oracle和mysql上。
Mysql Cluster可能与你的想象有较大差异。开源的cluster软件较少。
复制(Replication)功能是异步的,并且有很大的局限性.例如,它是单线程的(single-threaded),因此一个处理能力更强的Slave的恢复速度也很难跟上处理能力相对较慢的Master.
有丰富的开源cluster软件支持。
explain看执行计划的结果简单。
explain返回丰富的信息。
类似于ALTER TABLE或CREATE TABLE一类的操作都是非事务性的.它们会提交未提交的事务，并且不能回滚也不能做灾难恢复
DDL也是有事务的。
PostgreSQL主要优势：
1. PostgreSQL完全免费，而且是BSD协议，如果你把PostgreSQL改一改，然后再拿去卖钱，也没有人管你，这一点很重要，这表明了PostgreSQL数据库不会被其它公司控制。oracle数据库不用说了，是商业数据库，不开放。而MySQL数据库虽然是开源的，但现在随着SUN被oracle公司收购，现在基本上被oracle公司控制，其实在SUN被收购之前，MySQL中最重要的InnoDB引擎也是被oracle公司控制的，而在MySQL中很多重要的数据都是放在InnoDB引擎中的，反正我们公司都是这样的。所以如果MySQL的市场范围与oracle数据库的市场范围冲突时，oracle公司必定会牺牲MySQL，这是毫无疑问的。
2. 与PostgreSQl配合的开源软件很多，有很多分布式集群软件，如pgpool、pgcluster、slony、plploxy等等，很容易做读写分离、负载均衡、数据水平拆分等方案，而这在MySQL下则比较困难。
3. PostgreSQL源代码写的很清晰，易读性比MySQL强太多了，怀疑MySQL的源代码被混淆过。所以很多公司都是基本PostgreSQL做二次开发的。
4. PostgreSQL在很多方面都比MySQL强，如复杂SQL的执行、存储过程、触发器、索引。同时PostgreSQL是多进程的，而MySQL是线程的，虽然并发不高时，MySQL处理速度快，但当并发高的时候，对于现在多核的单台机器上，MySQL的总体处理性能不如PostgreSQL，原因是MySQL的线程无法充分利用CPU的能力。
目前只想到这些，以后想到再添加，欢迎大家拍砖。
PostgreSQL与oracle或InnoDB的多版本实现的差别
PostgreSQL与oracle或InnoDB的多版本实现最大的区别在于最新版本和历史版本是否分离存储，PostgreSQL不分，而oracle和InnoDB分，而innodb也只是分离了数据,索引本身没有分开。
PostgreSQL的主要优势在于：
1. PostgreSQL没有回滚段，而oracle与innodb有回滚段，oracle与Innodb都有回滚段。对于oracle与Innodb来说，回滚段是非常重要的，回滚段损坏，会导致数据丢失，甚至数据库无法启动的严重问题。另由于PostgreSQL没有回滚段，旧数据都是记录在原先的文件中，所以当数据库异常crash后，恢复时，不会象oracle与Innodb数据库那样进行那么复杂的恢复，因为oracle与Innodb恢复时同步需要redo和undo。所以PostgreSQL数据库在出现异常crash后，数据库起不来的几率要比oracle和mysql小一些。
2. 由于旧的数据是直接记录在数据文件中，而不是回滚段中，所以不会象oracle那样经常报ora-01555错误。
3. 回滚可以很快完成，因为回滚并不删除数据，而oracle与Innodb，回滚时很复杂，在事务回滚时必须清理该事务所进行的修改，插入的记录要删除，更新的记录要更新回来(见row_undo函数)，同时回滚的过程也会再次产生大量的redo日志。
4. WAL日志要比oracle和Innodb简单，对于oracle不仅需要记录数据文件的变化，还要记录回滚段的变化。
PostgreSQL的多版本的主要劣势在于：
1、最新版本和历史版本不分离存储，导致清理老旧版本需要作更多的扫描，代价比较大，但一般的数据库都有高峰期，如果我们合理安排VACUUM，这也不是很大的问题，而且在PostgreSQL9.0中VACUUM进一步被加强了。
2、由于索引中完全没有版本信息，不能实现Coverage index scan，即查询只扫描索引，直接从索引中返回所需的属性，还需要访问表。而oracle与Innodb则可以;
进程模式与线程模式的对比
PostgreSQL和oracle是进程模式，MySQL是线程模式。
进程模式对多CPU利用率比较高。
进程模式共享数据需要用到共享内存，而线程模式数据本身就是在进程空间内都是共享的，不同线程访问只需要控制好线程之间的同步。
线程模式对资源消耗比较少。
所以MySQL能支持远比oracle多的更多的连接。
对于PostgreSQL的来说，如果不使用连接池软件，也存在这个问题，但PostgreSQL中有优秀的连接池软件软件，如pgbouncer和pgpool，所以通过连接池也可以支持很多的连接。
② 为什么 MySQL 使用多线程，而 Oracle 和 PostgreSQL 使用多进程
.NET平台很棒。真的很棒。直到它不再那么棒。我为什么不再用.NET？简单来说，它限制了我们选择的能力(对我来说很重要)，转移了我们的注意力，使得我们向内认知它的安全性，替代了帮助我们认知外面广阔世界的所有可能性。[系好安全带：这个文章的长度几乎成了一本书…]优点首先让我开始说说.NET做得对的许多事吧，尽管这其中的大多数并不来自.NET本身，但却是由.NET社区而来。C#C#令人惊叹。我认为它是一个令人惊叹的编程语言。从强大的C语言背景而来，我彻底地喜欢其语法，流和这门语言的所带来的感觉。当然有我可能改变的事，但总体来说它是一门扎实的语言。并且基于开发人员使用的编程语言如此巨额的百分比和Windows操作系统的优越性，它是一门众所周知的语言。ReSharper我也很喜欢Resharper。在JetBrains工作的开发者们都是奇迹般的人。如果没有ReSharper和一些相关的工具，我可能并不会如此喜欢C#。BDDandMSpec我也很喜欢简称为机器规格(mspec)的BDD风格的框架。它是一个令人惊叹的测试框架，真正支持在测试中使用正确的语言测试本身。在使用mspec之前，我的测试真是一团糟并且很碍我的事。另外，当我们创建GoConvey—基于Golang的BDD测试框架的时候，Mspec对于我的组织来说是一个巨大的灵感和激励。多语言运行时我认为多语言的CLR(公共语言运行时)的观念真得使得JVM的世界思考着。我不知道任何非java的JVM语言在CLR之前，但随着“公共语言运行时”的到来，我的理解是这使得使用JVM的人们向前进并且最终创造了如Scala和Clojure这样伟大的JVM编程语言。如果我错了请纠正我。再者，CLR使得Sun公司的人们坐下来并关注它，因为Java有一点陈旧并且随着Java8的到来，仅仅现在才在多个方面追赶着。竞争是一件非常好的事。NuGet另一个显着的例子是NuGet。这个包在Windows中作为一个整体特别是在Windows的开发中，它的管理轶事是糟透的。NuGet解决了很多问题，他们也通过从Python和Ruby借用了很多东西去做了很多正确的事。有改进的余地吗？当然。但比起其他一些选择在这儿或那儿的包升级来说，我还没有感到使用NuGet有这许多痛楚。Mono对于Mono的开发者们，我不能不说太棒了。他们所创造的太惊奇了。没有任何官方支持和不顾潜在的悬在他们头上的法律问题，他们向前推进并创造了一个居然能替代官方运行时的实现。我已经有一些运行在产品中应用程序，在Mono下运行了几乎一年而没有任何问题。它的产品准备好了吗？这可能取决于你的应用程序(见下文“Mono”)。CQRS和事件溯源可以认为，关于.NET最好事之一是，它是CQRS的诞生地并有相关的技术：事件溯源。就算这样，CQRS+ES本身并没有什么很新的东西。正如GregYoung将会告诉你的，这是由一堆40年历史原料为我们重新打包并更名的。对于大型代码库我有些非常严重的问题，当我5年前使用CQRS+ES的时候，它完全释放了我的域。CQRS+ES现在是命名模式的并且其成长是显而易见的。这可能是因为.NET已经能够和其他的开发平台交互共享的原因。除了这个之外，大多数的创新是从外部来的。缺点优点先放在一边，让我们看看什么出错了和我为什么不再用.NET框架。关于我最近开发平台的迁移，最能激励我的事是我可以利用许多最好的部分而丢下不好的部分(如下文所说)。Windows正如前文所述，当面对基于网络的服务器软件时，Windows并不是一个好的选手。在我看来，Windows的另一个真正的大问题是传统的Windows开发者是通常仅仅擅长于Windows，当他们离开安乐窝之后就会很快迷失，这对于Linux开发者来说却不是问题。计算远不止是Windows。开发者仅仅能操作单一的操作系统的一个问题是它不可避免得导致Windows的激增。换句话说，Windows生了Windows。没法打破这个循环。另一方面，*NIX的开发者通常熟悉多操作系统(Linux，Unix，OSX，Windows等等)，一个操作系统的内部工作原理，不同的分布(基于Debian和基于Fedora)，窗口管理器，桌面管理器，文件系统，包管理，编译，重新编译，重新打包，命令行“fu”等等。我的一个心病是文件系统。NTFS并不是系统唯一的文件系统，对于任何给予的任务它几乎都不是最好的选择。ZFS，BTRFS，ReiserFs，ext*等等，有一些很酷的特性。我也很喜欢为了各种高速/透明的磁盘操作，能从BASH创建回路设备或者创建RAM设备。这在Windows中不会发生—如果没有第三方软件的话。在AWS云服务中，启动一个Windows机器要花掉足足10多分钟。我大约15-20秒就能启动一个简单的Linux机器。当涉及到云计算规模，它能够迅速扩展是很重要的，因为当扩展很重要时，10-15分钟就像是永恒的。VisualStudio在我这另一根刺，当属VisualStudio。我需要一个大大超出预期的IDE去做任何开发，这个想法困扰着我。它只是如Windows一样庞大的资源猪。我有一个内核i73770K3.5GHZ的台式机，以16GB的内存和最大4512GB的固态硬盘去编译。它差不多刷爆了Windows体验指数，但Windows+VS仍然很慢。(是的，ReSharper使得它更慢了，但是ReSharper对这来说是值得的。)现在我在MacBookPro上开发，它比起我的强大的台式机来说只有更少的CPU马力，但运行明显更快，在一个短小的学习曲线之后，UX（用户体验）变得无限美好了。事实上，我甚至不再用鼠标了—我的双手一直在键盘或触控板上，我可以用手势操作我的电脑并让它回应—不像在Windows。关于VS很酷的一个事是调试器。它的查看和使用，令人难以置信得方便。每隔一段时间会在监视窗口报告错误的值，导致花费时间去调试。同时，这也是很大的负面，因为CLR默认的，多线程的世界使得我一开始就需要一个调试器。没有调试器是一个解脱的体验，因为它迫使你以另一种方式编程。VS同样也有创建“csproj”和“sln”文件的坏毛病。我恨这些。当然，C#必须知道编译什么和何时编译。我理解这点。在Golang中，引用在代码中使用了很重要的语句。如果它不是.NET中用到的工程文件，我可能使用简单的文本编辑器编码C#，并且对这门语言更流畅。使用gitrebase操作时，这些文件也有导致合并冲突。别让我开始说换行符的差异。我不能相信直到今天我们还在处理这样的事。如果VS解决方案文件以Linux行结束符结束，通过双击它并不能载入该解决方案，因为VS解决方案文件分析器读不出它来。源代码管理幸运的是，我早就跳出了微软阵营的源代码管理(版本控制系统VSS)。我早在2000年初，在VSS无数次丢失了我的提交之后，就使用了Subversion(译者注：Subversion是开源的版本控制系统)。之后git(译者注：git是开源的版本控制系统，内容管理系统等)出现了，我又迷上了它。不幸的是，没有Windows的接口—对我来说是典型的遭遇。最终有人创建了一个接口，我就用了那个并且没有回头。Git是一把非常锋利的刀，但当你正确运用它的时候，它是一个强大而高效的工具。我曾经在一个小工程中用过TFS(译者注：TeamFoundationServer，工作流协作引擎)，它是一个怪物—和所有来自Redmond(译者注：美国微软总部)的产品一样。它感染了我的项目文件并且污染了我的源代码目录。真可恶。不，还是谢谢你。给了我任意一天用命令行git…或者可能是SourceTree，如果你需要从GUI得到一点关爱。Mono是的，这是第二次提及Mono。正如Mono本身如此惊艳一样。在.NET的世界，它仍然二等公民。无论什么时候我尝试在Mono上运行任何重要的东西，我通常都在和漏洞作斗争。幸运的是，对下载代码，查找问题，发送请求和在Linux上编译代码我没有感到不舒服。但是这件事我都记不清做了多少遍了。是的，CLR是个巨大的怪物，并且对一个非官方的应用在不同的操作系统都有相同的行为，简直是个类似于分开红海的奇迹。但事实是，我不得不花费如此多的时间来填补漏洞以使我的代码能够正确运行，实在是很难为其辩护。Mono的特定区域也慢。也许它不是在慢在过载，但对我来说Web服务器是关键所在。并且它非常慢，最后，慢到了最底下—即使是微不足道的东西。我想好消息是它只能从这儿得到更好的。我也应该提及Mono的开发者可能忘了Linux，比起我可能知道的还多，所以我不能太挑剔。IIS也许IIS在尝试着为太多的应用程序做太多的事情。它从作为一个web服务器变为像J2EE应用程序容器一样的应用程序宿主。它也站在慢速这一边。我猜如果我需要更高的性能，我应该编写我自己的web服务器，但我真的很想只关注我应用程序的代码。可能利用Windows事件服务器将是好的，但nginx(译者注：一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP代理服务器)和其他服务器只是不喜欢在Windows中生产。虚拟的以JVM为基础的实现，例如Netty(译者注：JBOSS提供的一个java开源框架)，很容易处理每秒650K+/的请求量。IIS在运行一个简单的CLR应用程序“Hello,World!”，处理大约每秒50K的请求量时就会壅塞。(有趣的题外话，参考基准开发者通过TCP套接字创建了一个简单的C#的web服务器，它能处理大约每秒120K的请求量。)狭隘的心理前些年有个运动叫做ALT.NET。该运动是全部是关于寻找我们自身之外的更广阔的开发社区以作为一个整体，并汇聚不同的部分。有趣的是，那是StructureMap、Autofac、NuGet、ASP.NETMVC和许多其它工具的灵感来源。在传统的.NET的圈子里，这个运动受到了很多的不屑和鄙视。我把这看作是，作为一个整体的社区普遍的狭隘心理和怠惰的一个极大的例证。(的确，它们中的一些可能会消失，进而以包括Redis，MongoBD还有其它的不同的技术而出现。)有这么多很棒的方案在那里。假定微软已注定是唯一正确之路的想法是荒谬的。如果是这样的话，我们就都还在使用VisualStudio的设计工具去拖放按钮和链接元素到一个WebForm的界面上，我们会设定了该按钮并且依赖ViewState以帮助我们与可怕的HTTP所带来的恐惧隔开。我从我的一个部署的代码库中最后一个WebForm中摆脱的那一天，是个光荣的值得庆贺的日子。谁又曾想过“网络控制”是个好主意？很显然我考虑过因为我喝了Kool-Aid(译者注：卡夫公司出品的饮料，这里意指明知是注定的或有危险的仍然去做,有负面涵义)并且完全接受它。它狠咬了我。见过2MB的ViewState吗？[注：当我写这篇文章的时候，原来的标题，“为什么我不再用.NET”，意味着整个.NET生态系统。标题感觉有点短于是我更新为“为什么我不再用.NET框架”。我想.NET作为一个生态系统，包括了所有的工具，工程，平台，组织还有很多开发者。这就是为什么有些更广泛的.NET社区的元素在我的这篇文章中受到抨击原因。]性能杀手C，Java和C#中典型的多线程范例都强烈推荐使用锁和互斥。对于锁来说有个隐藏的开销：它们慢得难以忍受。使用Disruptor(JVM中的无锁的环形缓存[译者注：实际上就是拥有一个序号指向下一个可用元素的数组])，你可以很容易得每秒处理20M以上的事件。在.NET中使用规定的“最佳实践”等任何超过每秒十几次的传输，都被认为是体面又好的性能表现，在这一点上来说你仅仅需要更大/更好/的硬件设备。事实上，我见过第三方客户端库(Rabbit，Couch，Mongo等等)中锁语句遍布整个代码。即使在我的代码中没有任何的并发，默认的和首选的方法都用了锁。无锁的、事件驱动的方法允许你大幅降低硬件和资金支出。大部分应用程序可以轻易地运行在两台机器上，第二台机器仅仅在冗余和失效备援时是必须的，以防因为硬件相关的问题导致第一台机器不可用的时候起作用。这个问题的另一个方面是调用网络和磁盘子系统的传统方式：同步，阻塞代码。如果你需要多个并发的HTTP请求，你需要的线程。大多数人不知道的是，为维持线程多出的1-2MB和上下文切换线程的需求，使得CPU内核消耗所有的时间颠簸在上下文切换上而不是做真正的工作。所以现在我们得到了在一个应用程序中数百或数千的线程，占用了RAM，并造成CPU停滞不前。还有个更好的方式。Netty/NIO(JVM)，Erlang，Node，Gevent(Python)和Go都支持使用事件驱动的子系统操作(选择/epoll[译者注：Linux内核中的一种可扩展IO事件处理机制]/kqueue[译者注：FreeBSD的可扩展的事件通知接口])。这就意味着当等待数据包被tx/rx跨网络的时候，CPU可以自由地去做其它，重要的工作。因为JVM的成熟，Netty可以认为是做这项工作最快的，但我喜欢Go用Goroutines操作这个的方式—它简单，优雅，很容易推理，没有像意大利面条一样的回调。SQLServer作为一名.NET开发者，当你开始一个新的工程时，有一些事是你通常会去做的：创建一个新的solution将其部署到TeamFoundationServer(译者注：Microsoft应用程序生命周期管理(ALM)解决方案的核心协作平台)IIS中建立相应的网站入口创建一个新的SQLServer数据库在solution中关联EntityFramework(通常是2010年之后创建的工程)开始设计你的数据库和ActiveRecord实体在大多数情况下这不是编写代码的正确方式。当然它可能在某些情况下有效，但是作为一个“默认的架构”它并不是你想要的。为什么在我们甚至还没理解问题领域之前已经做了任何技术上的选择？这简直是本末倒置了。微软的生态系统鼓励每个人使用SQLServer。在VisualStudio中和SQLService进行交互或者使用SQLManagementStudio(和它的前身，SQL查询分析器)是如此令人难以置信的容易。这种以数据库为中心的重点，是钦定的或唯一正确的方式的一部分。它使你更加迷恋微软。厂商锁定始终对厂商来说是好的。为什么我们要如此开发？为什么我们不地考虑应用程序的行为而不是它如何存储的？现在我所有的项目都使用基于JSON的键/值存储。有了这种功能，我可以选择任何我想要的存储引擎，包括SQLServer，Oracle，PostgreSQL，MySQL，Cassandra,CouchDB,CouchBase,Dynamo,SimpleDB,S3,Riak,BerkeleyDB,Firebird,Hypertable,RavenDB,Redis,TokyoCabinet/Tyrant,AzureBlobs，文件系统中的明文JSON文件等等等等。突然之间，我们能够开始根据其优点而不是仅仅对其熟悉来选择存储引擎了。题外话：在AWSRDS的云上运行过SQLServer吗？别这么做。当然它会工作，但是一些例如复制这样最简单的事是不存在的。文章充斥着对SQLServer不能在AWSRDS上工作的引用。结论也许我在软件开发中学到的两件最重要的教训是：边界和封装的重要性(以多种形式)付出代价以得到正确的模型和抽象许多年前我恨“模型”这个词。每个人都会把它到处扔，它是一个如此过载的术语，很难理解它的含义和它为什么这么重要。就这点来说，我仅仅会说模型是对你想要封装的现实的一个有限的表示。也许最简单的例子就是地球仪的墨卡托投影了。这很确切得说明了一件事：导航。如果你在其他的事情上使用它，它并不毫无价值。如果你不专注于付出代价去使模型正确，去封装商业现实，那么没有任何技术能够拯救你。我对.NET最大的抱怨是，“唯一正确的方式”引导你远离理想的模型并把你推向关注实现细节和技术缺陷的方向。这样的关注导致技术实施渗血并且感染模型，最终导致它腐烂变质，因为它不能适应不断变化的商业需求。当这发生的时候，开发者挣扎着并蹬踢着，如同吸毒者一样，他们从一个新技术转向另一个，以期望下一个强大的技术能够治愈他们的病痛。技术本身并不是灵丹妙药，相反地，它是关于取舍和选择。只有正确地理解了商业行为并把它们封装进结构良好的，易于理解的模型中，以帮助保持技术堆栈在属于它的地方—作为一个实现细节。这就是我为什么不再用.NET框架，因为它不断地重申自己(的主张)，不断地想要比它的本身的：一个实现细节。
③ 如何扩大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 " 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, www.hnne.com id::text,id::text,id::text,id::text,id::text,id::text from generate_series(1,10000000) id"|time psql -p 40382 -c " 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
-------
④ 数据库管理系统软件有哪些
数据库管理系统软件：
1、OracleDatabase
知名的Oracle数据库，一直处于行业领先地位，是许多人认可的、世界上最流行的关系数据库管理系统。
作为“十大数据库管理系统排名榜”之首，Oracle数据库使用方便、功能强大，可扩展性强、数据安全性强，系统可移植性好、稳定性佳，适用于各类大、中、小微机环境。2019年，艾媒金榜发布“企业服务品牌之HRM系统排行榜”，Oracle数据库位列第一。
2、Navicat
Navicat是一套可创建多个连接的数据库管理工具，可以方便管理Oracle、MySQL、PostgreSQL等多个不同类型的数据库，并支持管理腾讯云、阿里云等云数据库。
整体而言，Navicat的功能可以满足专业开发人员的需求，同时对数据库服务器初学者来说又相对容易。曾有一项数据统计，《财富》世界500强中有超过100家公司使用了Navicat。
3、DBeaver
DBeaver是一个通用的数据库管理工具和SQL客户端，具有相对较高的易用性，并且免费、支持跨平台使用、允许扩展插件。
支持的操作系统包括Windows、Linux、MacOS、Solaris、AIX、HPUX；基本特性编辑：支持数据库元数据浏览，支持元数据编辑（包括表/列/键/索引），支持SQL语句和脚本的执行，支持SQL关键字高亮显示，简单友好的显示页面。
4、Mysql
MySQL是最流行的关系型数据库管理系统之一，在WEB应用方面，MySQL也是最好的RDBMS应用软件之一。
作为十大数据库管理系统之一，MySQL所使用的SQL语言是用于访问数据库的最常用标准化语言；其软件采用双授权政策，分社区版、商业版，由于其速度快、体积小、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择MySQL作为网站数据库。
5、phpMyAdmin
phpMyAdmin是一个以PHP为基础，以Web-Base方式架构在网站主机上的MySQL的数据库管理系统软件，管理者可用Web接口管理MySQL数据库。
功能特性包括但不限于：支持大多数MySQL功能；从CSV和SQL导入数据，将数据导出为各种格式；以各种格式创建数据库布局的图形；使用逐例查询（QBE）创建复杂查询；使用一组预定义的函数将存储的数据转换为任何格式。
6、IBMDB2
DB2是IBM公司开发的关系型数据库系统，主要应用于大型应用系统，具有较好的可伸缩性，支持从大型机到单用户环境。
DB2提供了高层次的数据利用性、完整性、安全性、可恢复性，以及小规模到大规模应用程序的执行能力，具有与平台无关的基本功能和SQL命令。DB2可以在Windows、UNIX和Linux操作系统上运行，是最强大的十大数据库管理系统之一。
7、MSSQLServer
SQL Server是微软推出的关系型数据库管理系统，具有使用方便、可伸缩性佳、与相关软件集成程度高等优点，可跨平台使用。SQL Serve最初是由微软、Sybase 和Ashton-Tate三家公司共同开发的，于1988年推出了第一个OS/2版本。
在Windows NT推出后，Microsoft与Sybase在SQL Server的开发上就分道扬镳了，Microsoft将SQL Server移植到Windows NT系统上，专注于开发推广SQL Server的Windows NT版本。Sybase则较专注于SQL Server在Unix系统上的应用。
8、ApacheCassandra
数据库管理软件哪个好？ApacheCassandra是一款优秀的分布式数据库软件。
该DBMS软件突出特点：一，模式灵活，使用时就像文档存储，用户不必提前解决记录中的字段，可以在系统运行时随意的添加或移除字段，最终提升效率。
二，具有纯粹意义上的水平扩展。为给集群添加更多容量，可以指向另一台计算机，用户不必重启任何进程，改变应用查询，或手动迁移任何数据。三，多数据中心识别。
9、Redis
Redis是C语言开发的一个开源高性能键值对的内存数据库，可以用来做数据库、缓存、消息中间件等场景，是一种NoSQL的数据库。
其主要特点：性能优秀，数据是存储在内存中，读写速度非常快，可支持并发10WQPS；可作为分布式锁；支持五种数据类型；支持数据持久化到磁盘；可以作为消息中间件使用等。数据缓存是Redis极其重要的一个场景。
10、Sybase
十大数据库管理系统排名榜中的Sybase，是一种典型的UNIX或WindowsNT平台上客户机/服务器环境下的大型数据库系统。系统具有完备的触发器、存储过程、规则以及完整性定义，支持优化查询，具有较好的数据安全性。
Sybase还提供了一套应用程序编程接口和库，可以与非Sybase数据源及服务器集成，允许在多个数据库之间复制数据，适于创建多层应用。