关于postgresql今天的信息

服务器操作系统应该选择 Debian/Ubuntu 还是 CentOS?

著作权归作者所有。

商业转载请联系作者获得授权，非商业转载请注明出处。

作者：彭勇

链接：

来源：知乎

早期，我们使用 Debian 作为服务器软件，后来转向了CentOS，主要原因如下：

1、CentOS/RHEL的生命周期是7年，基本上可以覆盖硬件的生命周期，也就意味着一个新硬件安装以后，不用再次安装操作系统。要知道重新折腾一个生产机是很麻烦而且有风险的事情。

[2012.2.1]今天刚刚收到红帽子的通知邮件，RedHat 5, RedHat 6的生命周期，延长到10年，太牛叉了。这个对企业用户很重要。

而Debian的生命周期是不固定的，一般新版本发布以后，上个版本再维护18个月。而Debian的版本发布时间间隔不稳定，经常会延期。综合起来一个版本的生命周期一般在3～4年。

[2014.4.24]Debian 宣布对Squeeze(6.0)，提供5年的LTS长期支持。

Ubuntu的LTS版生命周期是5年。

如果你选用了 Debian 或者 Ubuntu作为服务器，等生命周期过了以后，就没有安全补丁，你的服务器就会裸奔或者需要重新安装系统。

2、RedHat是一个值得尊敬的开源公司，长期以来Linux内核RedHat的贡献程度都是最多的。可以这么说，如果一个Linux方面的问题，RedHat搞不定，那么也很少有其他公司可以搞定了。公司有一批Linux内核方面的如雷贯耳的大牛，比如：

Alan Cox - Core developer, numerous contributions

Ingo Molnar - x86 subsystem maintainer

Al Viro - VFS subsystem maintainer, linux内核贡献第二多的个人

David Miller - Sparc Port maintainer, linux网络部分开发者， linux内核贡献最多的个人

Jeff Garzik - Sata subsystem maintainer

John Linville - Wireless subsystem maintainer

Stephen Tweedie - Ext3 filesystem developer

Eric Sandeen - XFS, Ext4 filesystem developer

Josef Bacik - Btrfs filesystem developer

Rik Van Riel - VM developer

Ric Wheeler - Filesystem developer

Val Henson - Filesystem developer

Dave Jones - Fedora kernel maintainer

Kyle McMartin - Fedora kernel maintainer

Chuck Ebbert - Fedora kernel maintainer

Eric Paris - LSM/SELinux/Audit/Capabilities maintainer

Eugene Teo - Security Response

Kay Sievers - Hotplug

3、CentOS/RHEL对硬件的支持很好，主流硬件厂商早就将服务器拿过去测试，一般不存在硬件的兼容性问题。

而Debian就麻烦了，由于有版权上的考虑和代码纯洁性上的洁癖，一些硬件驱动和软件被删掉了，导致安装过程有问题。比如 Dell 服务器上，大量使用的网卡 BroadCom，就驱动不了，安装了以后，网络起不来。

4、大量商业软件，比如 Oracle ，都是针对 Redhat认证的，有大量的帮助文档和使用说明，有良好的技术支持。出了问题，也容易在网上找到类似的答案和经验。

5、CentOS 是RedHat的克隆版，如果需要可以随时平滑切换到 RedHat，从而享受RedHat的服务支持。要知道厂商的服务，是最后一道防火墙，如果你给一个大客户做方案，他们一般会倾向选用商业服务。万一出了什么问题，还有Redhat可以求助，或者有一个RedHat可以承担责任 :-)

6、如果你是一个工程师，熟悉了 CentOS/RedHat ，找工作更加容易。如果你是一个企业老板，相对也容易招聘到熟悉CentOS/RedHat的工程师。RHCE的培训，也相对较完善，认同程度高。

7、CentOS/RHEL 的批量安装更加方便

在机房，使用kickstart + PXE安装，给客户，使用定制的kickstart光盘，一键安装，一般在5分钟左右就可以安装完。

上述3，4，5，6几点中，都说明CentOS/RHEL相对于其他Linux操作系统，有相对完整的生态环境，很多公司在CentOS/RHEL投入了大量资源，积累了大量经验，绑定了自己的利益，这个是CentOS/RHEL得以长期良好发展的保证。

=============

补充对评论的一些回复

1. 所谓的“centos稳定性非常差”，不知道你指的是什么？能否举一些CentOS不稳定的例子？至少我们用了这么多年CentOS，稳定性上可以说是坚如磐石的。如果是你说的由于yum升级造成的混乱，那只能说明你对centos不熟悉。

2、RHEL/centos 对于一些新的软件的支持，采用 SCL的方式支持，比如ruby193，python27, python 33, PHP 54, nodejs 0.10, mariadb55, postgresql 9.2

AdditionalResources/Repositories/SCL

3、debian/ubuntu 同样存在版本稳定和程序太老的矛盾，比如他们的LTS版本，一般是两年多更新一次。squeeze是2011年2月发布，wheezy是2013年5月发布，如果你在2013年4月使用Debian，你会发觉好多软件太老，比如：

内核：2.6.32，和Centos 6 一样的

glibc 还是使用的2.11.2

mysql使用的5.1.49

openjdk使用的是 6

php使用的是 5.3.3

python使用的是2.6.6

下一个版本的Deiban，至少要到 2015年下半年才能发布，而RHEL7/CentOS7的正式版发布在即，里面用到的不少软件，都比wheezy的要新。按照你的逻辑，在接下来较长的时间里，是否CentOS比起Debian更加前卫？

再看看Rio的回复：“之前我用了很长一段时间的 Debian，但它的更新实在太慢了（好几年啊有木有！）”，呵呵

4、“debian的支持时间也非常长期”，这个最近确实有了改善，Debian刚刚宣布对 Debian 6.0 有了5年的LTS长期支持。可以这么说，Debian也看到了LTS的重要性，向CentOS学习了一把。

Debian -- News -- Long term support for Debian 6.0 Announced

但Debian做得还不够，因为Debian的LTS在后续版本，比如 Debian 7 (wheezy)， Debian 8 (jessie) 里的支持政策还不明朗：

Debian -- Security Information -- DSA-2907-1

Debian的LTS支持，也不是Debian 官方安全团队维护的，而是由其他志愿者维护的，工作效率和质量是否有保证还不知道。相比RHEL明晰的发展策略和安全更新策略，有10年的安全补丁保证，还有不少差距。

5、“debian这个系列的软件包也比较新，debian和他儿子ubuntu很多软件包维护是共享的，更新速度非常快”，不知道你使用的是稳定版还是测试版。稳定版里面你是如何看到软件包“更新速度非常快”的。

影响数据检索效率的几个因素

影响数据检索效率的几个因素

数据检索有两种主要形态。第一种是纯数据库型的。典型的结构是一个关系型数据，比如 mysql。用户通过 SQL 表达出所需要的数据，mysql 把 SQL 翻译成物理的数据检索动作返回结果。第二种形态是现在越来越流行的大数据玩家的玩法。典型的结构是有一个分区的数据存储，最初这种存储就是原始的 HDFS，后来开逐步有人在 HDFS 上加上索引的支持，或者干脆用 Elasticsearc 这样的数据存储。然后在存储之上有一个分布式的实时计算层，比如 Hive 或者 Spark SQL。用户用 Hive SQL 提交给计算层，计算层从存储里拉取出数据，进行计算之后返回给用户。这种大数据的玩法起初是因为 SQL 有很多 ad-hoc 查询是满足不了的，干脆让用户自己写 map/reduce 想怎么算都可以了。但是后来玩大了之后，越来越多的人觉得这些 Hive 之类的方案查询效率怎么那么低下啊。于是一个又一个项目开始去优化这些大数据计算框架的查询性能。这些优化手段和经典的数据库优化到今天的手段是没有什么两样的，很多公司打着搞计算引擎的旗号干着重新发明数据库的活。所以，回归本质，影响数据检索效率的就那么几个因素。我们不妨来看一看。

数据检索干的是什么事情

定位 = 加载 = 变换

找到所需要的数据，把数据从远程或者磁盘加载到内存中。按照规则进行变换，比如按某个字段group by，取另外一个字段的sum之类的计算。

影响效率的四个因素

读取更少的数据

数据本地化，充分遵循底层硬件的限制设计架构

更多的机器

更高效率的计算和计算的物理实现

原则上的四点描述是非常抽象的。我们具体来看这些点映射到实际的数据库中都是一些什么样的优化措施。

读取更少的数据

数据越少，检索需要的时间当然越少了。在考虑所有技术手段之前，最有效果的恐怕是从业务的角度审视一下我们是否需要从那么多的数据中检索出结果来。有没有可能用更少的数据达到同样的效果。减少的数据量的两个手段，聚合和抽样。如果在入库之前把数据就做了聚合或者抽样，是不是可以极大地减少查询所需要的时间，同时效果上并无多少差异呢？极端情况下，如果需要的是一天的总访问量，比如有1个亿。查询的时候去数1亿行肯定快不了。但是如果统计好了一天的总访问量，查询的时候只需要取得一条记录就可以知道今天有1个亿的人访问了。

索引是一种非常常见的减少数据读取量的策略了。一般的按行存储的关系型数据库都会有一个主键。用这个主键可以非常快速的查找到对应的行。KV存储也是这样，按照Key可以快速地找到对应的Value。可以理解为一个Hashmap。但是一旦查询的时候不是用主键，而是另外一个字段。那么最糟糕的情况就是进行一次全表的扫描了，也就是把所有的数据都读取出来，然后看要的数据到底在哪里，这就不可能快了。减少数据读取量的最佳方案就是，建立一个类似字典一样的查找表，当我们找 username=wentao 的时候，可以列举出所有有 wentao 作为用户名的行的主键。然后拿这些主键去行存储（就是那个hashmap）里捞数据，就一捞一个准了。

谈到索引就不得不谈一下一个查询使用了两个字段，如何使用两个索引的问题。mysql的行为可以代表大部分主流数据库的处理方式：

基本上来说，经验表明有多个单字段的索引，最后数据库会选一最优的来使用。其余字段的过滤仍然是通过数据读取到内存之后，用predicate去判断的。也就是无法减少数据的读取量。

在这个方面基于inverted index的数据就非常有特点。一个是Elasticsearch为代表的lucene系的数据库。另外一个是新锐的druid数据库。

效果就是，这些数据库可以把单字段的filter结果缓存起来。多个字段的查询可以把之前缓存的结果直接拿过来做 AND 或者 OR 操作。

索引存在的必要是因为主存储没有提供直接的快速定位的能力。如果访问的就是数据库的主键，那么需要读取的数据也就非常少了。另外一个变种就是支持遍历的主键，比如hbase的rowkey。如果查询的是一个基于rowkey的范围，那么像hbase这样的数据库就可以支持只读取到这个范围内的数据，而不用读取不再这个范围内的额外数据，从而提高速度。这种加速的方式就是利用了主存储自身的物理分布的特性。另外一个更常见的场景就是 partition。比如 mysql 或者 postgresql 都支持分区表的概念。当我们建立了分区表之后，查找的条件如果可以过滤出分区，那么可以大幅减少需要读取的数据量。比 partition 更细粒度一些的是 clustered index。它其实不是一个索引（二级索引），它是改变了数据在主存储内的排列方式，让相同clustered key的数据彼此紧挨着放在一起，从而在查询的时候避免扫描到无关的数据。比 partition 更粗一些的是分库分表分文件。比如我们可以一天建立一张表，查询的时候先定位到表，再执行 SQL。比如 graphite 给每个 metric 创建一个文件存放采集来的 data point，查询的时候给定metric 就可以定位到一个文件，然后只读取这个文件的数据。

另外还有一点就是按行存储和按列存储的区别。按列存储的时候，每个列是一个独立的文件。查询用到了哪几个列就打开哪几个列的文件，没有用到的列的数据碰都不会碰到。反观按行存储，一张中的所有字段是彼此紧挨在磁盘上的。一个表如果有100个字段，哪怕只选取其中的一个字段，在扫描磁盘的时候其余99个字段的数据仍然会被扫描到的。

考虑一个具体的案例，时间序列数据。如何使用读取更少的数据的策略来提高检索的效率呢？首先，我们可以保证入库的时间粒度，维度粒度是正好是查询所需要的。如果查询需要的是5分钟数据，但是入库的是1分钟的，那么就可以先聚合成5分钟的再存入数据库。对于主存储的物理布局选择，如果查询总是针对一个时间范围的。那么把 timestamp 做为 hbase 的 rowkey，或者 mysql 的 clustered index 是合适。这样我们按时间过滤的时候，选择到的是一堆连续的数据，不用读取之后再过滤掉不符合条件的数据。但是如果在一个时间范围内有很多中数据，比如1万个IP，那么即便是查1个IP的数据也需要把1万个IP的数据都读取出来。所以可以把 IP 维度也编码到 rowkey 或者 clustered index 中。但是假如另外还有一个维度是 OS，那么查询的时候 IP 维度的 rowkey 是没有帮助的，仍然是要把所有的数据都查出来。这就是仅依靠主存储是无法满足各种查询条件下都能够读取更少的数据的原因。所以，二级索引是必要的。我们可以把时间序列中的所有维度都拿出来建立索引，然后查询的时候如果指定了维度，就可以用二级索引把真正需要读取的数据过滤出来。但是实践中，很多数据库并不因为使用了索引使得查询变快了，有的时候反而变得更慢了。对于 mysql 来说，存储时间序列的最佳方式是按时间做 partition，不对维度建立任何索引。查询的时候只过滤出对应的 partition，然后进行全 partition 扫描，这样会快过于使用二级索引定位到行之后再去读取主存储的查询方式。究其原因，就是数据本地化的问题了。

[page]

数据本地化

数据本地化的实质是软件工程师们要充分尊重和理解底层硬件的限制，并且用各种手段规避问题最大化利用手里的硬件资源。本地化有很多种形态

最常见的最好理解的本地化问题是网络问题。我们都知道网络带宽不是无限的，比本地磁盘慢多了。如果可能尽量不要通过网络去访问数据。即便要访问，也应该一次抓取多一些数据，而不是一次搞一点，然后搞很多次。因为网络连接和来回的开销是非常高的。这就是 data locality 的问题。我们要把计算尽可能的靠近数据，减少网络上传输的数据量。

这种带宽引起的本地化问题，还有很多。网络比硬盘慢，硬盘比内存慢，内存比L2缓存慢。做到极致的数据库可以让计算完全发生在 L2 缓存内，尽可能地避免频繁地在内存和L2之间倒腾数据。

另外一种形态的问题化问题是磁盘的顺序读和随机读的问题。当数据彼此靠近地物理存放在磁盘上的时候，顺序读取一批是非常快的。如果需要随机读取多个不连续的硬盘位置，磁头就要来回移动从而使得读取速度快速下降。即便是 SSD 硬盘，顺序读也是要比随机读快的。

基于尽可能让数据读取本地化的原则，检索应该尽可能地使用顺序读而不是随机读。如果可以的话，把主存储的row key或者clustered index设计为和查询提交一样的。时间序列如果都是按时间查，那么按时间做的row key可以非常高效地以顺序读的方式把数据拉取出来。类似地，按列存储的数据如果要把一个列的数据都取出来加和的话，可以非常快地用顺序读的方式加载出来。

二级索引的访问方式典型的随机读。当查询条件经过了二级索引查找之后得到一堆的主存储的 key，那么就需要对每个 key 进行一次随机读。即便彼此仅靠的key可以用顺序读做一些优化，总体上来说仍然是随机读的模式。这也就是为什么时间序列数据在 mysql 里建立了索引反而比没有建索引还要慢的原因。

为了尽可能的利用顺序读，人们就开始想各种办法了。前面提到了 mysql 里的一行数据的多个列是彼此紧靠地物理存放的。那么如果我们把所需要的数据建成多个列，那么一次查询就可以批量获得更多的数据，减少随机读取的次数。也就是把之前的一些行变为列的方式来存放，减少行的数量。这种做法的经典案例就是时间序列数据，比如可以一分钟存一行数据，每一秒的值变成一个列。那么行的数量可以变成之前的1/60。

但是这种行变列的做法在按列存储的数据库里就不能直接照搬了，有些列式数据库有column family的概念，不同的设置在物理上存放可能是在一起的也可能是分开的。对于 Elasticsearch 来说，要想减少行的数量，让一行多pack一些数据进去，一种做法就是利用 nested document。内部 Elasticsearch 可以保证一个 document 下的所有的 nested document是物理上靠在一起放在同一个 lucene 的 segment 内。

网络的data locality就比较为人熟知了。map reduce的大数据计算模式就是利用map在数据节点的本地把数据先做一次计算，往往计算的结果可以比原数据小很多。然后再通过网络传输汇总后做 reduce 计算。这样就节省了大量网络传输数据的时间浪费和资源消耗。现在 Elasticsearch 就支持在每个 data node 上部署 spark。由 spark 在每个 data node 上做计算。而不用把数据都查询出来，用网络传输到 spark 集群里再去计算。这种数据库和计算集群的混合部署是高性能的关键。类似的还有 storm 和 kafka 之间的关系。

网络的data locality还有一个老大难问题就是分布式大数据下的多表join问题。如果只是查询一个分布式表，那么把计算用 map reduce 表达就没有多大问题了。但是如果需要同时查询两个表，就意味着两个表可能不是在物理上同样均匀分布的。一种最简单的策略就是找出两张表中最小的那张，然后把表的内容广播到每个节点上，再做join。复杂一些的是对两个单表做 map reduce，然后按照相同的 key 把部分计算的结果汇集在一起。第三种策略是保证数据分布的方式，让两张表查询的时候需要用到的数据总在一起。没有完美的方案，也不大可能有完美的方案。除非有一天网络带宽可以大到忽略不计的地步。

更多的机器

这个就没有什么好说的了。多一倍的机器就多一倍的 CPU，可以同时计算更多的数据。多一倍的机器就多一倍的磁头，可以同时扫描更多的字节数。很多大数据框架的故事就是讲如何如何通过 scale out解决无限大的问题。但是值得注意的是，集群可以无限大，数据可以无限多，但是口袋里的银子不会无限多的。堆机器解决问题比升级大型机是要便宜，但是机器堆多了也是非常昂贵的。特别是 Hive 这些从一开始就是分布式多机的检索方案，刚开始的时候效率并不高。堆机器是一个乘数，当数据库本来单机性能不高的时候，乘数大并不能起到决定性的作用。

更高效的计算和计算实现

检索的过程不仅仅是磁盘扫描，它还包括一个可简单可复杂的变换过程。使用 hyperloglog，count min-sketch等有损算法可以极大地提高统计计算的性能。数据库的join也是一个经常有算法创新的地方。

计算实现就是算法是用C++实现的还是用java，还是python实现的。用java是用大Integer实现的，还是小int实现的。不同的语言的实现方式会有一些固定的开销。不是说快就一定要C++，但是 python 写 for 循环是显然没有指望的。任何数据检索的环节只要包含 python/ruby 这些语言的逐条 for 循环就一定快不起来了。

结论

希望这四点可以被记住，成为一种指导性的优化数据检索效率的思维框架。无论你是设计一个mysql表结构，还是优化一个spark sql的应用。从这四个角度想想，都有哪些环节是在拖后腿的，手上的工具有什么样的参数可以调整，让随机读变成顺序读，表结构怎么样设计可以最小化数据读取的量。要做到这一点，你必须非常非常了解工具的底层实现。而不是盲目的相信，xx数据库是最好的数据库，所以它一定很快之类的。如果你不了解你手上的数据库或者计算引擎，当它快的时候你不知道为何快，当它慢的时候你就更加无从优化了。

如何解决 Microsoft VC++ runtime installer

今天在安装PostgreSQL时遇到下面的错误提示：

There has been an error.

an error occured executing the Microsoft VC++ runtime installer

最简单的解决方法如下

方法/步骤

以管理员方式打开命令行窗口

在窗口中输入如下类似的Dos命令，将当前目录切换到程序的安装文件目录下

我的程序安装目录文件在

H:\迅雷下载\MySQL5.5从零开始学光盘\postgresql-9.3.4-1-windows-x64

运行 postgresql-9.3.4-1-windows-x64.exe --install_runtimes 0

执行后会自动弹出如下页面，则说明可以正确进行安装了

五大数据库理念，读懂亚马逊云科技的数据库布局

1970 年，关系型数据库之父 E.F.Codd 发表《用于大型共享数据库的关系数据模型》论文，正式拉开数据库技术发展序幕。以 Oracle、DB2、SQL Server 为代表的三大商业数据库产品独占鳌头，随后涌现出 MySQL、PostgreSQL 等为代表的开源数据库 ，和以 Amazon RDS 等为代表的云数据库，拉开百花齐放的数据库新序幕。

我们知道，云计算十年为产业转型升级提供了 历史 性契机，但变革仍在进行，随着云计算的普及，数据库市场发生根本性改变，云厂商打破传统商业数据库的堡垒，成为数据库领域全新力量。其中以连续六年入选 Gartner 领导者象限的亚马逊云 科技 为代表，我们一起探讨：为什么亚马逊云 科技 能始终保持其创新性？纵观云原生时代下，亚马逊云 科技 数据库未来还有哪些更多的可能性？

01 面对四大数据库发展趋势，亚马逊云 科技 打造五大数据库理念

后疫情时代下，加速了不少行业的业务在线化和数字化运营，企业对数据价值挖掘的需求越发强烈，亚马逊云 科技 大中华区产品部总经理顾凡详细介绍其中四大趋势：

一是伴随互联网、移动互联网的发展，电商、视频、社交、出行等新应用场景的兴起，不仅数据量大，对数据实时性要求极高，传统关系型数据库无法满足需求，因此驱动云原生数据库的出现。

二是开源数据库的广泛应用。

三是应用程序现代化对数据库提出更高要求，期待数据库拥有更高的性能、可扩展性、可用性以及降低成本，让开发人员专注于核心业务的应用开发，不用关注和核心业务无关的代码。

四是软件架构历经 PC、互联网、移动互联网，再到如今的万物互联时代，其中的迭代和转型正在驱动数据库选型的变化。

在此四大趋势下，伴随企业的业务量越来越大、越来越复杂，对数据库的要求越来越高。亚马逊云 科技 洞察客户需求，在打造云上数据库产品时提出五大理念：

一是专库专用，极致性能；二是无服务器，敏捷创新；第三是全球架构，一键部署；第四是平滑迁移，加速上云；第五是 AI 赋能，深度集成。

02 历经真实锤炼，五大数据库理念，持续赋能企业数智转型

顾凡表示，随着数据爆炸式增长，微服务架构与 DevOps 愈发流行的今天，一个数据库打天下的时代已然过去。我们需要在不同的应用场景下，针对不同的数据类型和不同的数据访问特点，为开发者和企业提供专门构建的工具。

所以亚马逊云 科技 提出 第一个核心数据库理念：专库专用 。在此理念下，推出针对关系数据、键值数据、文档数据、内存数据、图数据、时许数据、分类账数据、宽列等专门构建数据库的产品家族。

这些数据库产品均经历过亚马逊内部核心业务的真实锤炼，成绩斐然：

亚马逊电商当年是 Oracle 的客户之一，随着亚马逊电商的应用重构和业务体量发展，亚马逊电商决定将业务迁移到亚马逊云 科技 里。100 多个团队参与这庞大的迁移工作中，将亚马逊电商采购、目录管理、订单执行、广告、财务系统、钱包、视频流等关键系统全部从 Oracle 迁出来。2019 年，亚马逊将存储近 7500 个Oracle 数据库中的 75 PB 内部数据迁移到多项亚马逊云 科技 的数据库服务中，包括 Amazon DynamoDB、Amazon Aurora、Amazon ElastiCache，于是亚马逊电商成为亚马逊云 科技 在全球的“第一大客户”。

从 Oracle 切换到亚马逊云 科技 后，亚马逊电商节省了 60% 成本，面向消费者端的应用程序延迟降低 40%，数据库管理支出减少 70%。

以被誉为“亚马逊云 科技 历史 上用户数量增速最快的云服务”Amazon Aurora 为例，其拥有科媲美高端商业数据库的速度和可用性，还拥有开源数据库的简单性与成本效益，Amazon Aurora 让客户满足“鱼和熊掌兼得”需求。

据顾凡介绍，Amazon Aurora 可提供 5 倍于标准 MySQL 性能，3 倍于 PostgreSQL 吞吐量。同时提供高可用，可用区（AZ）+1的高可用，Global Databases 可完成跨区域灾备。可扩展到 15 个只读副本，成本只有商业数据库的 1/10。

医药企业九州通为药厂、供应商，搭建药厂、供应商、消费者提供供应链链条。其 B2B 系统的业务特点是读多写少，受促销活动、工作时间等影响，经常会出现波峰波谷落差较大的情况，读写比例在 7：2 或者 8：3。九州通采用 Amazon Aurora 后实现读写分离和按需扩展，整体数据库性能提升 5 倍，TCO 降低 50%。实现了跨可用区部署、负载均衡、自动故障转移、精细监控、按需自动伸缩等。

据权威机构预测，到 2022 年，75% 数据库将被部署或迁移至云平台。在这个过程中，亚马逊云 科技 是如何通过技术来帮助客户加速应用上云的？这离不开除了上述的“专库专用”外，以下四大理念：

第二个理念是无服务器、敏捷创新。 亚马逊云 科技 大中华区产品部数据类产品高级经理王晓野表示，企业业务总有波峰波谷之时，如何按照企业 80-90% 的业务峰值来规划数据库的存储容量和计算资源的话，将给应用带来一定的业务连续性的妥协和挑战。因此大多数企业都是按照峰值留有余地来选择数据库的计算资源，这将造成成本上的浪费。而 Serverless 数据库服务可完成无差别的繁复工作和自动化扩展。

Amazon DynamoDB 是亚马逊云 科技 自研 Serverless 数据库，其诞生最早可追溯到 2004 年，当时亚马逊电商作为 Oracle 的客户，尽管对于关系型数据库在零售场景的需求并不频繁，70% 均是键值类操作，此时倒逼亚马逊电商思考：为什么要把关系型数据库这么重得使用？我们可以设计一款支持读写、可横向扩展的分布式数据库吗？后来的故事大家都知道了，这款数据库就是 Amazon DynamoDB，并在 2007 年发表论文，掀起业界 NoSQL 分布式数据库技术创新大潮。

Amazon DynamoDB 可为大规模应用提供支持，支撑亚马逊自身多个高流量网站和系统，如亚马逊电商网站、亚马逊全球 442 个物流中心等。在亚马逊电商一年一度 Prime Day，光是针对DynamoDB API 的调用达到数万亿次，最高峰值请求达到每秒 8920 万次。由此可见，DynamoDB 拥有高吞吐、扩展性、一致性、可预测响应延迟、高可用等优势。

智能可穿戴设备厂商华米 科技 ，在全球 70 多个国家拥有近 1 亿用户。仅 2020 年上半年，其手表出货量超 174 万台，截止到 2021 年 2 月，华米 科技 的可穿戴设备累计记录步数是 151 万步，累计记录的睡眠时间是 128 亿个夜晚，记录心率总时长达 1208 亿个小时。如此庞大的数据同时必须保证极高的安全性和低延迟相应，如何保证稳定性是巨大的挑战。

DynamoDB 帮助华米 科技 在任何规模下都能提供延迟不超过 10 毫秒的一致响应时间。华米 科技 健康 云的 P0 和 P1 级别故障减少了约 30%，总体服务可用性提升了 0.25%，系统可用性指标达到 99.99%，为华为 科技 全球化扩展提供了有力的支撑。

最新无服务数据库产品是 Amazon Aurora Serverless V2 提供瞬间扩展能力，真正把扩展能力发挥到极致，在不到一秒的时间内，将几百个事务扩展到数十万的级别。同时在扩展时每一次调整的增量都是非常精细化的去管理，如果按照峰值来规划数据库资源，可实现大概90%的成本节省。目前 Amazon Aurora Serverless V2 在全球实现预览。

第三个理念是全球架构、一键部署。 在全球化的今天，如何支撑全球客户的业务扩展连续性、一致性、以最低延迟带给到终端客户上，对数据库提出新的挑战。

亚马逊云 科技 提供 Amazon Aurora 关系型数据库Global Database、Amazon DynamoDB、Amazon ElastiCache 内存数据库、Amazon DocumentDB 文档数据库都能利用亚马逊云 科技 的骨干网络提供比互联网更稳定的网络支撑，以一键部署的方式，帮助客户实现几千公里跨区域数据库灾备，故障恢复大概能在一分钟之内完成，同时跨区域的数据复制延迟通常小于一秒。

第四个理念是平滑迁移、加速上云。 目前，450000+ 数据库通过亚马逊云 科技 数据库迁移服务迁移到亚马逊云 科技 中，这个数字每年都在不断增长。亚马逊云 科技 提供 Amazon DMS、Amazon Database Migration Service 等工具让开发者和企业进行自助式云迁移。另外，对于迁移过程中可能会需要的支持，可通过专业服务团队和合作伙伴网络成员，为客户提供专业支持，还通过 Database Freedom 项目帮助客户降低他们的顾虑。

今年 11 月，最新产品 Babelfish for Amazon Aurora PostgreSQL 在全球和中国两个区域正式可用，可加速企业上云的迁移，实现让企业可以利用原有的技术栈、原有的 SQL Server T-SQL的人员可以利用到云数据库进行创新。

第五个理念是 AI赋能，深度集成。 我们观察到，ML 技术赋能数据库开发者，开发者无需具备机器学习专业知识，就可进行机器学习操作。在此潮流下，亚马逊云 科技 推出 Amazon Neptune，借由 Deep Graph Library 和 Amazon SageMaker 驱动图神经网络。

今年 8 月，Neptune ML 在中国正式可用，允许数据工程师不需要掌握机器学习的技能直接从图数据库里导出数据、转换格式、训练模型并发布，用 gremlin 语句调用训练成的模型在数据库里实现推理，进行欺诈检测，推荐物品。

目前，亚马逊云 科技 加速在中国区域服务落地，2021年至今新发布 60 多个数据库服务与功能。亚马逊云 科技 正是通过上述五大数据库理念，打造丰富的数据库产品家族，在全球智能化发展趋势下，为企业提供更快更好的数智服务，释放数据价值，并连续六年入选 Gartner 领导者象限，得到业界和客户的深度认可。