orczhou.com

  • 在Amazon Linux 2上安装PostgreSQL

    概述

    使用的Amazon Linux 2，相当于是CentOS 7，于是使用了官方的yum repo来进行安装。

    官方文档的参考：Linux downloads (Red Hat family)@postgresql.org

    添加yum仓库

    /etc/yum.repos.d/pgdg.repo
[pgdg13]
name=PostgreSQL 13 for RHEL/CentOS 7 - x86_64
baseurl=https://download.postgresql.org/pub/repos/yum/13/redhat/rhel-7-x86_64
enabled=1
gpgcheck=0

    注意，上述文件中的url需要根据实际情况调整，需要根据主机的发行版本和需要安装的PostgreSQL版本，在仓库中找到对应的目录：目录列表。

    更新yum仓库配置信息，并安装postgresql-server

    sudo yum update

    sudo yum install postgresql13-server

    添加执行文件到PATH路径

    export PATH="${PATH}:/usr/pgsql-13/bin"

    准备数据文件（database cluster）

    参考：Creating a Database Cluster

    root# mkdir /usr/local/pgsql
root# adduser postgres
root# chown postgres /usr/local/pgsql
root# su postgres

postgres$ export PATH="${PATH}:/usr/pgsql-13/bin"

postgres$ pg_ctl -D /usr/local/pgsql/data initdb

    启动/关闭postgresql

    pg_ctl start -l logfile -D/usr/local/pgsql/data
pg_ctl stop -D /usr/local/pgsql/data

    修改配置文件

    vim /usr/local/pgsql/data/postgresql.conf  # 例如修改 shared_buffers = 64MB

    连接数据库

    psql

  • SQL Server中的login和database user

    SQL Server的用户体系和MySQL有非常大的不同，无论是在使用上、还是概念上。所以，这里梳理一下SQL Server的用户与认证的一些基础概念与使用。另外，这个概念在SQL Server相关资料中各个地方都会出现，是理解权限体系的基础。

    “login”与“database user”

    在SQL Server中，”login”不是一个动词，而是一个”名称”（注：”log in”是动词），代表的是一个用于登录的对象（Object），这是一个服务器级别的对象，所以，它有自己的登录名(login name)、密码、默认语言、认证方式等。需要强调的是，它不是一个数据库（database）级别的对象。

    而”Database User”是一个数据库级别的对象，与之相对应的则是数据库级别的权限。”Database User”并不能连接或者登录SQL Server实例，所以，一般来说，也不需要密码。

    “login”因为是Server级别的，所以权限也都是Server级别的。本身不能赋予任何数据库相关的权限，但是，login可以和一个Database User建立映射，使用该login连接数据库的时候，该连接也就可以根据Database User权限进行相关的操作了。

    最常见、最简单的创建login和database user的命令如下：

      use zzxdb2;
  create table t_1(id int,nick nchar(12),birthday date);

  create login zzxdb2 with password='zzxdb2' ,CHECK_POLICY=OFF;
  create user zzxdb2 for login zzxdb2;

  -- 当没有赋予权限的时候，zzxdb2可以登录SQL Server，但是看不到zzxdb2下面的TABLE
  -- 所以，最后还需要赋予database user相应的权限，如下
  exec sp_addrolemember 'db_owner', 'zzxdb2';

    为什么容易混淆

    通常的系统中只有用户的概念，权限系统都是基于用户。而SQL Server在其上新增了Login这一层，与其他的系统都不同。另外，在一般的客户端中，在需要登录的时候，通常都是使用”user name”/”password”作为登录认证的凭证，而不是”Login”/”password”，所以初学者通常容易混淆，例如微软的Mac客户端Azure Data Studio：

    一些可以帮助理解”login”和”user”关系的一些问题

    1. 只创建login，而不map到一个具体的database用户，是否可以登录？

    答案是简单的：可以登录，但是没有数据库相关的权限。测试如下：

    先创建一个没有映射到”user”的”login”：

    CREATE LOGIN alogin WITH PASSWORD = 'alogin', CHECK_POLICY=OFF;
-- 注： CHECK_POLICY可以让你设置简单密码，并不建议加上
    • 使用上面的”login”在Azure Data Studio中连接并进入SQL Server。可以看到，可以正常登录，但是因为没有database相关的权限，所以展示database里面的对象的时候，会失败，如下：

    也就说，”login”只有在与具体的某个database user建立了mapping之后，才可以访问对应的数据库。在上面例子中的”login”主体”alogin”，要访问和管理数据库9zcloud，是会失败的。

    当然，如果真的需要访问的话，那么我们需要先建一个database user，并在user和login之间建立mapping，具体操作如下：

    CREATE USER a_db_user_9zcloud FOR LOGIN alogin;

    2. 创建用户，不映射到任何login，后续是否还可以重新映射？

    如果在用户创建的时候显式的声明，不映射到任何login，那么后续是否还可以重新映射到某个login？答案似乎没有那么明显了。遂测试如下：

    CREATE USER a_db_user_9zcloud WITHOUT LOGIN;
ALTER USER  a_db_user_9zcloud WITH LOGIN='alogin';
-- 报错如下：

消息 33016，级别 16，状态 1，第 45 行
The user cannot be remapped to a login. Remapping can only be done for users that were mapped to Windows or SQL logins.

    可见，如果在创建的时候显示声明不映射到任何”login”，那么就不能够再重新映射任何的”login”。

    3. 如果用户名和login主体名字不一样，客户端登录的时候使用哪个？

    答案是显然的，但是还是验证一下。

    具体的，如果数据库用户名和login用户名不一样，那么在登录连接SQL Server的时候，使用的是database user还是login的名称？具体看下面的例子，在使用客户端登录的时候，使用的alogin，还是使用a_db_user_9zcloud？ 

    CREATE LOGIN alogin WITH PASSWORD = 'alogin', CHECK_POLICY=OFF;
CREATE USER a_db_user_9zcloud FOR LOGIN alogin;

    答案，当然是使用login的主体alogin。

    4. 在创建用户时如果映射到了某个login，同时也创建密码，那么这个密码有什么用？

    是啊，有什么用呢？ 具体的，在创建用户时映射到某个具体的login，但是依旧指定一个密码，那么这个密码有什么用？测试验证如下：

    CREATE LOGIN alogin WITH PASSWORD = 'alogin', CHECK_POLICY=OFF;
CREATE USER a_db_user_9zcloud FOR LOGIN alogin WITH PASSWORD = 'dbuser9zcloud';

    答案：你就不能这么用！！（注：仅当在contained database中可以使用密码，参考） 在明确映射到某个具体的login的用户，不需要密码，也无法指定密码。所以，上面的语句执行会失败，报如下错误：

    消息 33234，级别 16，状态 1，第 47 行

The parameter PASSWORD cannot be provided for users that cannot authenticate in a database.

    另外，注意到login在创建的时候，是可以指定默认数据库(DEFAULT_DATABASE)的；创建用户的时候，可以指定默认的schema。

    其他内容

    • 在给一个对象(主体)赋权的时候，可以通过按照细粒度(某个表的某种权限)方式进行，也可以直接将其加入到某个角色组，那么这个角色组对应的权限就都有了。例如，将login加入到”sysadmin”(fixed server role)，那么就有了所有sysadmin角色组的权限，sysadmin可以理解是一个超级权限组，如果在该组中，那么访问对象时不需要检查该账号的权限；与sysadmin对应的一个权限是”CONTROL SERVER”，如果使用GRANT则可以使用这个权限。
    • 另外，前文中偶尔会用到”主体”这个名称，英文对应SQL Server文档中的”Principals”，”主体”是SQL Server官方中文文档的翻译(参考)。可以理解为一个实体，或者前面对象的实例化或者实体，也就是说，某个具体的”server roles, logins, database roles, or users.” 都可以称作”Principals”。
    • SQL Server中的系统表sys.server_principals、sys.server_permissions会存储相关的元数据。
    • 在SQL Server官方文档中将”login”翻译为”登录名”(参考)。这也是为什么，一些客户端在让输入用户名的时候，其实是输入一个login主体名和对应的密码。
    • 在创建user的时候，如果没有显示的指定FOR LOGIN，没有指定WITHOUT LOGIN，那么该user将会被映射到同名的login上(还没有验证这一点，参考：If FOR LOGIN is omitted, the new database user will be mapped to the SQL Server login with the same name.)。
    • 另外，系统中还有一个名字为guest的login，默认是不可用的。
    • 在实际中，也有一些场景是需要创建user，而不映射到任何的login，后续会再考虑介绍这类场景。

    参考阅读

    • Determining Effective Database Engine Permissions：链接 如何查看系统中的账号权限
    • Database Engine Permissions SQL Server 2017 and Azure SQL Database： 链接

  • 长路漫漫 踏歌而行

    Canon EOS R5 RF24-70mm F2.8 ISO-100 ƒ5.6 1/200 By Pingping

  • MacOS X上python连接SQL Server

    这是一个记录。虽然微软的文档已经非常完善和友好了，但是涉及到一些软件版本等相关问题，配置并不畅通。

    安装

    本地环境是macOS Big Sur 11.4版本，使用的是Python 3.8.2版本。

    zzx@localhost % python3
Python 3.8.2 (default, Apr  8 2021, 23:19:18)
[Clang 12.0.5 (clang-1205.0.22.9)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

    需要安装pyodbc、unixodbc、msodbcsql17、mssql-tools等工具（详细参考）：

    pip3 install pyodbc
brew install unixodbc

    测试脚本

    主要参考微软文档：Proof of concept connecting to SQL using pyodbc。测试连接脚本如下：

    import pyodbc
# Some other example server values are
# server = 'localhost\sqlexpress' # for a named instance
# server = 'myserver,port' # to specify an alternate port
server = 'x.x.x.x'
# server = 'tcp:x.x.x.x,1433'
database = 'xxx'
username = 'xxx'
password = 'xxx'
cnxn = pyodbc.connect('DRIVER={ODBC Driver 17 for SQL Server};SERVER='+server+';DATABASE='+database+';UID='+username+';PWD='+ password)
cursor = cnxn.cursor()

#Sample select query
cursor.execute("SELECT @@version;")
row = cursor.fetchone()
while row:
    print(row[0])
    row = cursor.fetchone()

    一下子就跑通了？ 有经验的开发者都知道，那当然不能这么顺利，是吧。首先，遇到如下报错：

    Traceback (most recent call last):
  File "mssqlremotessh.py", line 10, in <module>
    cnxn = pyodbc.connect('DRIVER={ODBC Driver 17 for SQL Server};SERVER='+server+';DATABASE='+database+';UID='+username+';PWD='+ password)
pyodbc.OperationalError: ('08001', '[08001] [Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection (0) (SQLDriverConnect)')

    是哪个环节的问题？

    老实说，这个报错真的很不友好，无法看出来是什么地方的问题。首先，根据Github上一个issue建议首先通过isql命令（应该是unixODBC的工具）尝试连接一下SQL Server，果然有了新的发现：

    # 注意：下面命令的IP和密码都被修改了
isql -v -k 'Driver={ODBC Driver 17 for SQL Server};Server=tcp:18.336.80.202,1433;Database=9zcloud;Uid=zzx;Pwd=********;'


[08001][Microsoft][ODBC Driver 17 for SQL Server]SSL Provider: [OpenSSL library could not be loaded, make sure OpenSSL 1.0 or 1.1 is installed]
[08001][Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection
[ISQL]ERROR: Could not SQLDriverConnect

    解决openssl版本依赖问题

    看起来似乎是ODBC依赖OpenSSL 1.0或者1.1，而查看了本地默认安装的应该是v3版本，查看如下：

    $ cd /usr/local/Cellar/ && ls
$ cd openssl@3/3.0.1/bin
$ ./openssl version
$ OpenSSL 3.0.1 14 Dec 2021 (Library: OpenSSL 3.0.1 14 Dec 2021)

    自此，已经找到了问题的症结（也可能是问题的症结之一，是吧）：似乎是ODBC只认这两个版本的openssl，沿着此线索搜索，发现，这个问题在Github的 issue 59@microsoft/homebrew-mssql-release 中讨论得比较多，而且，在下面的回答中也有一些办法可以尝试解决：在系统中，额外在安装openssl 1.1，并把链接库目录的软连接从3.0版本更换到1.1版本。（这么做，还是有点担心其他的软件运行有问题的，但是先这么做吧，把问题解决了），详细回答参考如下：

    具体的操作如下：

    zzx@localhost ~ % ls -lah /usr/local/opt/openssl
lrwxr-xr-x  1 zzx  admin    25B 12 28 10:21 /usr/local/opt/openssl -> ../Cellar/openssl@3/3.0.1

unlink /usr/local/opt/openssl

# 这里要注意，你所安装的openssl版本和目录可能和以上截图中是不同的，所以要根据实际情况进行连接，例如我这里是1.1.1m版本，而不是截图中的1.1.1l版本。
ln -s /usr/local/Cellar/openssl@1.1/1.1.1m /usr/local/opt/openssl

    Finnally，it works！！

    zzx@localhost ~ % ln -s /usr/local/Cellar/openssl@1.1/1.1.1m /usr/local/opt/openssl
zzx@localhost ~ % isql -v -k 'Driver={ODBC Driver 17 for SQL Server};Server=tcp:19.36.80.2,1433;Database=9zcloud;Uid=zzx;Pwd=******;'
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL> select * from dbo.t_1;
+------------+---------------------------------+-----------+
| id         | nick                            | birthday  |
+------------+---------------------------------+-----------+
| 1          |                                 |           |
| 2          | zzx                             |           |
| 3          | yzs                             | 2008-09-23|
+------------+---------------------------------+-----------+

    在回头去运行，最前面的示例脚本，也可以正常连接SQL Server，至此，剧终。所以，回头来看，今天的解决问题的堆栈如下：

    • unixODBC关于openssl版本兼容性的问题
    • 安装unixODBC & mssql-tools
    • 尝试python连接SQL Server
    • 尝试通过ssh tunnel连接SQL Server

    相关阅读

    • 更多关于什么是unixODBC，什么事isql，可以参考：unixODBC
    • Install the Microsoft ODBC driver for SQL Server (macOS)：参考

  • 云时代数据库从业者的新要求

    注：这是一篇阿里云数据库ACP认证的软文，但是还是非常非常推荐阅读。因为这个认证很可能会成为国内数据库领域最重要的认证，对很多数据库极其相关技术人员都会有很大的影响。

    概述

    TLDR版本：阿里云数据库ACP认证填补了云时代与传统数据架构时代之间数据库专业认证的空白。无论是不是写软文，笔者都是非常推荐云数据库从业者或者与数据库相关度比较高的开发者，都去拿下这个认证的。另外，也提醒一下，这个认证是刚刚推出，无论是试题还是流程都还有一些小的磕盼，也可以考虑等半年之后再去拿证，都时候应该会更加成熟一些。也预警一下：这个证书要花费一些费用，考试难度还是比较大的，所以通过考试并不容易，笔者考试过程整整鏖战两小时，83分，涉险过关（80分通过）。

    什么是阿里云数据库ACP认证

    我从阿里云出来已经几个月了，恍如隔世…，出来之前也曾是阿里云数据库认证体系建设的负责人，在整个事业部的支持下，设计并上线了阿里云数据库的ACA认证（参考）。在上周，阿里云数据库推出ACP认证，是一个更高级别的认证，认证一上线，我就便迫不及待的上线去考下了这个证书。据说，可能是全球第一个获得阿里云数据库ACP认证的人员（烦请内部同学再帮确认一下）。

    数据库ACP认证是整个阿里云面向开发者的认证体系的一部分（参考），与初级的”数据库ACA”认证组成了数据库垂直领域的初步认证体系。ACP全称是专业工程师(Alibaba Cloud Certified Professional)，也是*当前*云数据库最高端的认证（也许未来会推出ACE）。主要面向，云数据库相关从业者，包括DBA、云系统管理员、与数据库相关度比较高的开发者等。要求上，需要参与认证的人，对通用数据库基础有非常好的了解，同时，对于云数据库相关技术也非常详细的了解。数据库的ACP认证分了两个方向：关系型数据库、数据仓库，可以根据自己的专业背景选择其中一个方向去挑战。

    数据库领域的”各种认证”

    在计算机发展之初，一个重要的应用就是数据的存储与计算。数据库在过去60年的发展中，一直都是计算机技术最重要的分支技术之一。在现代数字化企业架构中，数据架构的设计、数据技术选型都是重大的挑战，无论是在基于本地IDC的架构，还是基于现代的云计算架构，这一点都没有发生变化。而且，在当前各行各业数字化转型的过程中，数据架构在企业中的地位也越来越重要。

    数据库技术人员也一直是构建企业数据架构的核心人员。在数据库技术发展的过去的半个世纪，各个数据库厂商，为了培养各个不同类型的数据库的专业人才，推出了各个垂直方向的认证，例如，Oracle的OCP、OCM认证，微软早期的MCSA、MCSE、MongoDB Developer/Database Administrator、TiDB的Associate/professional、OceanBase的OBCA/OBCA/OBCE等。

    这些认证中，其中Oracle认证一度最为成功。从认证的设计上，非常完善，OCA/OCP/OCM三级认证，层层递进，很好的帮助学习逐步了解Oracle数据库的各个方面。另外，更重要的，也因为Oracle认证的权威性，企业人员在招聘时有了一个不错的参考，也让想进入这个领域的从业者，有了一个非常好的入门途径（参考）。

    • 阿里云数据库 ACP
    • Oracle数据库认证
    • PingCAP TiDB认证
    • OceanBase认证

    云时代数据库从业者的新要求

    云计算已经改变了企业和开发者使用数据库的方式，现代企业是以数字化为基础的，数据架构也是企业架构的核心部分，企业在数据架构选型上，两个趋势已经是事实了：一个是”云化”，选择以云计算技术为基础的架构，利用云计算的平台与产品优势，提升企业的业务研发效率；一个是”多种数据库”并行，随着数字化在业务场景中不断深化，各类的数据场景都呈现出了不一样的数据存储、查询、分析的要求，一两个数据库就解决所有的企业存储要求，已经不可能了。可以看到，在传统关系型数据库基础上，图数据库、时序数据库、文档数据库等都在快速发展。

    随着云计算的逐渐渗透，各家云厂商争相发布的各个数据库全托管服务(如RDS)，使得企业内部已经不再需要单独的人去做很多基础的工作了，例如数据库的安装部署、备份管理、监控配置等；另一方面，随着数据存储场景的增加，数据库种类的增多，如何选择最合适的数据库存储引擎支撑业务快速发展与决策，成为了更重要的命题；另外，随着云厂商的积极投入(“juan”，第三声)，如何选择最适合企业的云数据架构，也是企业的基本诉求。

    这对企业数据库架构师、数据库管理员就提出了完全不同的要求，无论是技能上，还是职业发展上，都发生了很大的变化。这也是为什么传统的认证，已经不再适应当前的时代，细心的数据库从业者应该已经注意到了这一点，一方面传统的认证参与人员变少了，另一方面各个数据库厂商自己认证也在变化（例如Oracle将废弃老的OCA，微软也重点推Azure相关的认证）。

    在多个云厂商并驾齐驱的时代，在数据库存储引擎百花齐放的时代，云数据库的认证就成为当前的最佳选择，云数据库认证将在众多的数据库认证中崛起。这也是云时代，对数据库从业者的新要求：熟悉多种数据库引擎、熟悉多个云平台上的数据库特点，基于此构建现代企业的数字化架构，帮助企业提升业务效率与决策支持。

    云厂商数据库认证的优势与缺点

    相比单个数据库认证，云数据库厂商的认证则更加丰富，更加立体，不是简单拘泥于某个数据库的技术细节，更加在意数据库的通用技术，例如阿里云数据库ACP认证就覆盖了MySQL、PostgreSQL、数据复制工具等产品。当然，”私心”也很明显，例如，就包含了大量的PolarDB、AliSQL等相关内容。当然，阿里云作为重要的数据库厂商，PolarDB又是最重要的产品，多去了解一下，也是非常有必要的。

    谁应该考ACP

    数据库的ACP认证难度系数是比较高的，并不适合所有的技术人员都去考。有几类人是建议获取这个认证的：

    • 所有的DBA、数据架构师
    • 构建数据相关应用的开发人员
    • 基于云架构的系统管理员
    • 想深入了解云数据库技术的技术人员

    考试的形式与内容

    这部分，在官网上有比较详细的说明：参考。这里简单说一下感受，目前，学习资料还不是很丰富，有一个200页的ppt，内容大致方向都涵盖了，但是实际考试试题是远超出ppt本身的内容的，ACP考试配套的还有一个视频学习课程，如果想顺利通过考试，认真学习视频是非常有必要的。另外，除了考试之外，还有一系列的动手试验，目前，这部分设计的都还比较简单，也都有step by step的引导，难度还不算高。

    完成动手实验，通过考试，就可以获得正式的ACP证书了。

    最后，也晒一下，据悉是全球第一个阿里云数据库ACP的证书，如下：

    参考文档

    1. Database@Wikiedia https://en.wikipedia.org/wiki/Database#History
    2. 阿里云数据库ACA认证： https://edu.aliyun.com/certification/aca09
    3. 阿里云数据库ACP认证：https://edu.aliyun.com/certification/acp17
    4. 阿里云认证： https://edu.aliyun.com/certification
    5. Oracle数据库认证： https://education.oracle.com/en/oracle-certification-path/pFamily_32
    6. PingCAP认证： https://learn.pingcap.com/learner/certification-center

  • AWS RDS Custom实例，与阿里云数据库的MyBase类似吗？

    最近，Amazon RDS Custom开始支持了SQL Server。RDS Custom形态一方面提供托管数据库的安装、管理、弹性等能力，另一方面又提供类似自建数据库的OS访问与配置、驱动程序安装等能力。

    这种形态与阿里云数据库提供的MyBase有一些类似，那是不是同类产品呢？我们从一下几方面来看看Amazon RDS Custom。

    面向的场景：Amazon RDS Custom主要是面向一些比较封闭、传统的应用系统，需要对数据库控制、配置都有非常高要求的应用系统，让系统人员可以接触、控制RDS所运行的主机OS，从而完成这类“封闭、传统”的应用系统配置工作。所以，从这个逻辑出发，RDS Custom优先支持的是Oracle，现在又支持了SQL Server，而不是当下最流行的MySQL或者PostgreSQL。

    提供的能力：RDS Custom向用户提供了底层OS的访问权限，可以让用户一定程度上配置和管理数据库的运行环境。普通的RDS是一种全托管的数据库，用户不用关心数据库的安装配置，更不用关心底层的OS运行情况；如果基于EC2/ECS等构建数据库，则需要用户对OS、数据库做完整地管理与配置。可以这样理解，RDS Custom是一种介于这两种形态之间的一种中间形态，一方面RDS Custom提供了托管数据库地安装、管理、弹性等能力，另一方面又提供类似自建数据库地OS访问与配置、驱动程序安装等能力。下图，比较好的概括了相关能力，并给出了对比：

    一些常见的场景：

    • 在安装数据库时需要安装特定的数据库和OS补丁
    • 需要对数据库做一些特殊的配置
    • 应用系统和数据库需要通过文件的方式传输、共享数据

    RDS Custom的一些优势：

    • 安装、备份/恢复、监控/告警等，依旧可以全托管自动化完成
    • 可以在主机上运行自己的软件，例如某些第三方应用程序等
    • 可以按需的自己安装数据库补丁和OS补丁
    • 可以作为从本地环境迁移到全托管环境的一个过渡
    • 可以运行自己的系统脚本，例如监控、诊断、调度等

    与MyBase的异同：

    • 都提供了主机级别的权限，一方面向用户提供了更大自由度定制数据库和运行OS环境，另外也可以在主机上运行一些额外的软件（例如监控agent等）
    • MyBase比较重要的一点是，提供在主机级别超卖率的配置，可以让用户根据自己应用的实际情况去配置，这就可以在一些非性能关键的场景下，获得非常高的性价比。同时，MyBase也基本是全托管的（自动化安装、备份、监控等），使用起来依旧很建档，让客户更加专注于自己的业务系统。
    • 整体上，定位是不同的。RDS Custom核心是解决用户的部分传统应用部署时候对数据库有一些特殊要求的场景，所以，支持的数据库也是Oracle和SQL Server；而MyBase是提供给用户一个更加自主可控的环境，另外，MyBase是以主机为单位购买，也向用户提供更加高性价比的实例选择，基于此，希望通过这种产品形态，让用户放下一些“顾忌”，选择云数据库上云。

    所以，RDS Custom和MyBase这两个形态看起来有些像，但是出发点、形态、使用上差异也都非常大。不过有一点是一样的，都是在一些较为垂直的场景上，帮助用户更加便利、平滑的完成数据库上云。

    参考：