简单生活

  • 选择

    ·

    在前公司的时候,参加过一个叫《选择》的培训(参考),与其说这是一个关于管理的培训,倒不如说这是一个认识自己,认识人与人关系的培训,其背后的意义,并不仅仅适用于公司协作,更多的是在生活中,如何与自己”和解”,如何与他人”和解”。在这个课程中,当时的培训老师叫”龙子立”(参考),他在介绍中,介绍了什么是”价值观”,为什么”价值观”需要用具体的事情和衡量,为什么价值观需要付出代价。

    “付出”有时候是试金石

    付出就是一颗”试金石”。根据生活中的经验,通常,每个人都深深的认为自己是一个好人,是一个善良的人。但是,如果,试问:你今年有没有帮助过你的朋友或者其他人?无论事情大小。例如,

    • 驾车时,斑马线一侧有人在左右张望,而你可以通过的情况下,你是否愿意停下车来等他?
    • 常用的服务/软件/产品的体验调研,你是否愿意花十分钟认真的完成?
    • 如果你是一个资深的技术人员,你用过很多的开源软件,你有没有帮助过这个软件?
    • 你会不会为你经常使用的软件,而慷慨付费?
    • 你有没有帮助过陌生人,无论事情大小?
    • 你是否会由衷在他人面前/背后,因为认可而夸赞他人?
    • 你是否会由衷的认可与你意见相左的人的一些行为或者做法?”

    再比如:

    • 当你有权责的时候,你是否会借此伤害(或大或小)曾经让你”怒目”的人?
    • 当你有能力的时候,你是否愿意帮助那些曾经让你“怒目”的人?
    • 当你意识到你错了的时候(有时候也许你是对的),你是否敢于向你曾经言语伤害到的人道歉?

    再比如:

    • 当你在游戏/追剧正酣时,是否愿意为了孩子找不到一块积木而停下?
    • 你是否愿意为了带孩子去动物/植物园,而放弃周末早上温暖的被窝?
    • 你是否愿意花几个小时/几百块,为爱人挑选一个礼物(也许她不一定喜欢)?
    • 你是否愿意花几个小时/几百块,在重大节日(例如新年)为大家准备一份节日惊喜?

    无论上面哪件事情,你都需要付出代价,或大或小,有时候是几分钟时间、有时候是几个小时,有时候是几十块钱,有时候是几千块或者更多。如果你从不曾做过一件帮助他人的事情,那么大概很难说服自己,自己是一个善良的人。

    不以善小而不为,不以恶小而为之

    这是”刘皇叔”大约两千年前写给儿子的”要求”,却从不曾过时。如果每个人都要求自己能够做出惊世骇俗之举,显然是不可能的,从善也是如此,每个人只能从小事开始。实际上,如果在小事上做到善良,那么遇到大事/大节,则也更可能做出善良的选择。反之亦然,”小恶”做的多了,自然更容易一步步走向”大恶”。

    在实际生活中,能够做一些”小善”便已经很好了,例如,能够在斑马线前停下来等待行人优先通过,能够停下来耐心的为快递小哥带路到”春晓苑”,为自己经常使用的软件付费等。

    这一次做个善良的人,不纠结于以前,也不要为以后背负任何负担

    做善良的事情并不容易。我们通常会屈服于各种各样的理由,很多理由似乎都没有任何道理。在骑电动车的时候,来到一个红灯路口,同时现在穿过也很安全的时候,以前经常会纠结:“我昨天就没有等这个红灯,今天要充什么好人”。现在,我则反过来激励自己:“虽然,我昨天没有等这个红灯,也许我明天也不会等这个红灯,这并不妨碍我这一次,这一刻做一件正确的事情”。事实上,这么想,这么做,骑电动车时闯这个红灯的次数少了很多。

    这是一个建议,一个选项,而不是一个“人设”

    近几年,“人设崩塌”事件时有发生,做个善良的人的人设则更难维持(似乎是不可能),所以,这不是一个人设,而是一个建议,今天做一个好人,做个善良的人,做一件善良的事情,并不要求自己永远都这样,每个人的经历、所处的环境通常都非常复杂,甚至还有很多是刻在基因中的选择倾向,做一个“自私”人的同时,并不影响依旧去做一些善良的事情,做了一些善良的事情,那么这件事情上,你就是一个善良的人,我不要求自己一直能够做一个善良的人,而且我也很确定,任何人都很难这样。

    我不想,不打算背负任何“好人”的人设负担,但我依旧愿意做好这一件善良、正确的事情。

    好人不一定有好报,但是,依旧做一个好人

    虽然,社会舆论会不断的渲染,因为做了好人,会可能获得更好的结果,但是实际的情况是,影响是否会有“好报”的因素,非常多,而你自己是不是一个好人,只是一个非常小的因子。一件事情,是不是有好报,个人做个粗略的判断,运气大概占了四层,个人努力可能占了三层,另外,还有三层大概是更多的不可知,或者不确定的因素。至于,你是不是一个好人,在其中的影响甚微。虽然,法律、道德等,都会尽量将社会引导到好人好报、恶人恶报,但是,非常非常遗憾,好人也会有恶报,恶人也会有好报,这几乎是一定的。

    所以,选择做一个好人,不能纠结于此,也不能因为好人没有获得好报而放弃,也不能因为恶人没有恶报,而忿忿。

    善良的分寸

    尽自己的绵薄之力帮助他人,就非常不错了。如果愿意付出更多,已经是侠义心肠了。给自己订立的“分寸”有两个原则,其一,对自己生活没有什么影响,受助者也只是需要基础的帮助。

    其二,付出一份,最好能够给他人带来更多收获。例如,拿出 100 元帮助边远地区贫困学子,于自己可能是较小的付出,但是于他人,则是几个月的生计、是一份安心就学保障,自然就达到了一份付出,更多收获的效果。

    如丰子恺所在“不宠无惊过一生”中提到,“不乱于心,不困于情。不畏将来,不念过往”。

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

    安装

    本地环境是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认证的权威性,企业人员在招聘时有了一个不错的参考,也让想进入这个领域的从业者,有了一个非常好的入门途径(参考)。

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

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

    随着云计算的逐渐渗透,各家云厂商争相发布的各个数据库全托管服务(如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
  • 这个示例可以结合着之前的连接MySQL一起来看:参考

    代码如下。当然,运行之前,你需要

    • 已经完成了基本的工具安装,这个并不容易(参考)
    • 已经有一个可以正常运行的与连接的SQL Server
    • 已经有一个网络上到SQL Server联通的主机的ssh账号
    • 下面的实例中,还需要一个t_1表,表中有三个字段

    import pyodbc
    import pandas as pd
    import logging
    import sshtunnel
    from sshtunnel import SSHTunnelForwarder
    
    ssh_host = 'x.x.x.x'
    ssh_port=22
    ssh_username = 'lilei'
    ssh_password = 'xxxxxx'
    
    
    db_server = 'x.x.x.x'
    db_port= 1433
    database = 'xxx'
    db_username = 'xxx'
    db_password = 'xx'
    
    
    tunnel = SSHTunnelForwarder(
        (ssh_host, ssh_port),
        ssh_username = ssh_username,
        ssh_password = ssh_password,
        remote_bind_address = (db_server, db_port),
    )
    tunnel.start()
    
    
    cnxn = pyodbc.connect('DRIVER={ODBC Driver 17 for SQL Server};SERVER=127.0.0.1,'+str(tunnel.local_bind_port)+';DATABASE='+database+';UID='+db_username+';PWD='+ db_password)
    cursor = cnxn.cursor()
    
    cursor.execute("SELECT * FROM dbo.t_1;")
    row = cursor.fetchone()
    while row:
        print('ID: %(id)03s | nick: %(nick)012s | birthdate: %(bd)010s' %
          {'id':row[0],'nick':row[1],'bd':row[2]})
        row = cursor.fetchone()

  • 最近,Gartner正式发布了2021年云数据库魔力象限。阿里云继续保持在全球领导者象限,华为继续在第三象限,位置也有不错的提升,腾讯竟意外落选。国际厂商,微软凭借强大的云战略,横纵坐标全面超越Oracle,AWS和微软则齐头并进。

    去年,笔者也深度参与阿里云数据库冲击Gartner Leader象限的项目,整体上,Gartner在产品评估上已经是非常专业与细致的,评估的维度也比较立体,涵盖了产品能力、市场理解、技术创新、未来规划、市场份额、客户反馈等多个方面,可以作为企业软件选择的重要参考。

    数据库厂商在魔力象限上的“战争”

    我们一起来回顾一下,自魔力象限发布以来总计九次魔力象限的厂商分布​。

    2020年,Gartner将魔力象限从Operational Database更名为Cloud Database,Amazon和所有的云厂商,也获得了更多的认可。前面十年是微软和Oracle争夺老大的地位,未来,将是Amazon和微软争夺。从2020年MQ来看,Oracle已经在纵坐标上落后于海外的三家云计算厂商Amazon、微软和Google了,在今年,随着Oracle云战略的进展,位置也有了一些进展。整体上,这四家公司,也组成了整个象限的第一“集团”。

    从2013年到2019年,Oracle和微软一直是前两名,并且保持着统治性的领先。Oracle凭借着强大的数据库能力和几十年的积累,在各个行业的头部大型企业中占据了绝对领先的位置,构建了难以超越的数据库能力;微软则凭借SQL Server和强大且封闭的Windows开发生态,在中小企业占据了领先。在云计算逐渐兴起的过去十年,两家厂商都在all-in云计算。微软通过强大的开发者生态以及对大量企业客户的深耕,同时在云计算上坚决的投入,已经在云计算领域已经成为了三分天下的一方霸主。Oracle的云计算战略则比较坎坷(技术与人员上),目前,还在持续迎头赶上的阶段,目前,市场份额还比较小。


    Snowflake和Databricks两个“欢喜冤家”也分别从挑战者、远见者象限进入了领导者象限。前者市值已经接近1000亿美元,后者在最近一次融资中估值达到了380亿美元。数据库领域,已经从存储价值扩展到了通过数据分析与洞察实现了直接的业务价值。另外,两者也分别是多云原生和开源分析产品的典型方向的代表,可以看到后续会有更多厂商加入到这些领域进行创新。

    Amazon凭借云计算领域的绝对优势,改变了企业的软硬件架构,从而也彻底改变企业使用数据库方式,AWS的创新产品DynamoDB、Aurora也给开发者带来非常大的数据存储与处理的便利。Amazon自从2016年进入MQ以来,就一直是在Leader象限,而且位置也在逐年向前。

    阿里云数据库,自2018年首次进入数据库魔力象限,到2020年成功进入全球领导者象限,确实是中国数据库在世界范围内的一次重大突破。阿里巴巴过去的二十年,在数据库方向投入都非常大,每个阶段都有非常强的团队和领导者,包括汪海、陈吉平、冯春培、阳振坤、周宝方、张瑞、周光辉、余锋、曹伟、杨冰、杨传辉,到现在的李飞飞,团队规模之大,人员能力(一个参考是人员级别)之强,是国内公司独一无二的。2018年,李飞飞的加入,也让阿里云数据库的影响力,逐步的扩展到了海外。到现在,已经基本在领导者象限站稳脚跟,继续突破则是要正面与国外厂商在产品能力、市场、战略、人才等多角度​竞争。

    不在乎的Gartner的MongoDB 自2013年其就在MQ当中,2015年进入Leaders象限,2016年跌入Challengers象限,2017年在MQ的“大裁剪”中不再出现。但是,MongoDB在开发者群体中依旧非常受欢迎,在2021年StackOverflow的开发者年度调研中,MongoDB为排名第四的数据库;在资本市场,MongoDB自2017年上市以来,每股30美元增至到现在的超500美元(对应市值约350亿美元),应该是数据库领域非常耀眼的明星了,但似乎一直不怎么受Gartner MQ的“待见”。

    一直默默向前的MariaDB,今年第一次入选MQ。MariaDB凭借在多云部署、混合分析能力、容量评估与性能诊断等综合能力受到​认可。MariaDB这些年一直在苦苦与MySQL竞争,但是MySQL依旧凭借着最近十几年积累的生态与品牌优势,暂时领先。也许,现在是时候考虑,用MariaDB替换部分的MySQL​了。

    ​最后

    Gartner对于市场份额考量非常重,相对来说,对于较小的、垂直的数据库厂商不是那么的友好。另外,市场占有率有时候也比较难评估,各家厂商的最真实的数据,也不会直接透露给Gartner,实际透露给Gartner都会从结果的角度考虑,做一些调整。

    Gartner对于使用场景考虑是有一定缺陷的。比如,SAP、InterSystems等厂商,数据库主要是用于自家的应用系统,收入也都来自这些地方,这就让收入数值调整的空间比较大。另外,这样的评价,对于企业进行数据库架构选型并没有太大的参考意义。而,这应该是Gartner MQ的重要作用之一。

  • 在前段时间微软Ignite前后,Azure的SQL Server托管服务(Azure SQL Managed Instance)发布一个基于”Always On”技术的新的“Link”特性。可以帮助用户在云端实例和其他环境实例建立一条同步链路,将其他环境的数据同步到Azure云端。该功能当前处于邀请测试阶段(limited public preview),支持SQL Server 2019(需要CU13),长期计划支持2016及其以后的版本。

    从感受上来说,国外三家云厂商,Azure应该是更新最快速的,可以说是最努力的那朵云,相比AWS虽然起步晚,但是跑得非常快。从这个功能来看,微软在尝试通过产品化的方式帮助用户将本地的数据,快速、低成本的迁移到Azure。

    这里简单介绍一下该功能。使用该功能,可以实现如下能力:

    • 将本地或者其他云上的SQL Server数据”近实时”地同步到Azure云的SQL Server
    • 可以实现本地环境SQL Server的读扩展,可以将部分可以接受延迟的读服务切换到Azure上
    • 可以利用Azure上的一些分析产品能力,包括Synapse、MI、PBI等
    • 可以通过多个Link通路,将多个实例数据同步一个Azure实例上用于聚合分析
    • 利用Azure在全球众多区域部署,使用Link同步通路,可以让业务快速具备就近访问的能力
    • 可以帮助用户更加无缝的实现,从其他环境迁移到Azure上,使用Link特性是一个很好地过渡
    • 如果需要建设SQL Server数据库的容灾能力,这也是一个非常简单快速的方式

    参考链接:

    • Managed Instance link – connecting SQL Server to Azure reimagined:链接
    • Link feature for Azure SQL Managed Instance (limited preview):链接
    • Distributed availability groups:链接