简单生活

  • 本周 Gartner 正式对外发布了 2024 年的数据库魔力象限[1],对今年全球范围内大型数据库厂商做了一个整体的“盘点”,是的,在这个象限中几乎都是“大型”的数据库厂商。

    整体上,依旧有Google、AWS、Azure、Oracle领跑;MongoDB、DataBricks、Snowflake则又向左上角前进了一些;阿里云则依旧保持在领导者象限。华为云则在时隔两年后,再次进入该象限。

    分布式数据库厂商 SingleStore 进入,而 Yugabyte 跌出。

    领跑组:Google 高歌猛进

    Google 是 AI 与云计算领域的领导者,在数据库产品上不断增强与 AI 产品的链接;其他方向上,则加强其 AlloyDB (或其 Omni版本)、BigQuery、Spanner、Cloud SQL等功能。凭借着 AI 与 大数据技术的持续领先,Google 依旧是最领先技术的弄潮儿。

    Amazon 在数据库方向上的核心产品是托管数据库、Aurora 和 DynamoDB 。并且,在今年,Aurora 发布了 DSQL 版本,跨区域强一致的全球数据库,DynamoDB 也发布了类似的能力;托管数据库则不断紧跟社区,并开始以更高性价比的形式支持了最新一代的Graviton 芯片。

    微软在过去的数年,云计算成功的赶上了第一梯度,在 AI 浪潮中,微软凭借快速高效的与OpenAI进行合作并持续创新,再次站在潮头。在数据库方向,在云端微软一方面持续发展SQL Database、Cosmos DB。在本地则发布了SQL Server 2025版本。今年11月,看到 Azure 托管数据库发布支持了 PostgreSQL 17,追赶了这么年,可以认为 Azure 的数据库基础设施最终赶上了其他头部云厂商[3]

    Oracle 则在不断践行多云和 AI 战略,发布了Oracle@Google、Oracle@Azure、Oracle@AWS等系列合作产品。在 MySQL 方向上,依旧的,在不断的增强 HeatWave 能力,包括分析能力和 AI 功能[4]

    中国数据库厂商:阿里云和华为云

    在去年,中国数据库厂商,仅有阿里云数据库在孤军奋战[5] ,今年华为云再次进入该象限(注:2020/2021年曾进入),可见,华为在被美国限制的情况下,依旧在尝试在全球市场寻求更大的突破。阿里云相比于去年的位置,没有发生太大的变化,依旧是处于领导者象限。华为云,则相比于 2020、2021 年的所处的niche players象限进步很大,跃入了挑战者象限。

    而在魔力象限之外,依旧有不少数据库厂商在奋力征战全球市场。分布式数据库 TiDB 从市场宣传、产品投入可以看到,全球市场市场是其重点方向。向量数据库 Zilliz / Milvus,则已经站在了全球向量数据库的领导者的位置。此外,还有 NebularGraph 、Databend、KubeBlocks等。

    独立厂商与平台厂商

    在全球云计算快速侵蚀传统数据中心的大背景下,独立数据库厂商则在尝试寻找独立的、垂直的价值空间。其中一个非常重要的战略是,各个独立厂商都发布了各自的云服务平台,包括TiDB Cloud、Neo4j Aura、Redis Cloud、MongoDB Atlas等。

    关于 Gartner 魔力象限

    曾经在阿里云工作时,多次参加过 Gartner 数据库魔力象限的项目。Gartner 项目团队会从多个角度对数据库厂商进行评估,主要包括营收规模、多维度的产品能力、产品规划等方面,在评价体系中,Gartner 还会邀请厂商的客户对该厂商的产品进行评价。除此,厂商和 Gartner 项目组可以就自己关心的问题进行询问。最终,Gartner 会根据上述信息形成一个综合的评估,并将多个数据库厂商的评估结果汇总成一个整体的报告,也就是通常大家看到的,Magic Quadrant。

    在 Gartner 的 “Cloud Database” 定义是比较广泛的,不仅仅包含RDBMS,也包括各类NoSQL,此外,还包括了各个厂商的分析类产品。在计算营收时,通常云计算厂商会将数据库或大数据库类目的营收数据合并上报,所以规模通常都比较大。而且,云厂商的数据库营收,通常都是硬件(IaaS)营收为主,辅以部分授权收入,这也是云厂商收入规模很大的原因。相比之下,独立的数据库厂商,通常只能计算数据库售卖的授权费用,所以,在营收规模的维度,独立数据库厂商是难以与云厂商抗衡的。所以,第一梯队,甚至第一象限,几乎都是云厂商。

    另一面

    Gartner 更像是一个数据库的“神仙打架”榜单,Gartner的魔力象限有着非常高的准入门槛。入选 Gartner 最为重要的应该就是营收,有了营收,才有后面的所有,才有资源去做产品能力评估、规划汇报或者客户评价等。对于头部厂商来说,所有的资源都是充足了,厂商之间会在其他维度(诸如产品能力、客户评价等)去竞争,从而获得更好的象限位置,以便后续宣传。但,这对小的、创新厂商是不友好的。所有,对于没有进入的厂商,并不是这些厂商不优秀,也不是这些厂商不创新,而只是时候未到。

    过去十年对比参考

    参考链接

  • Mini-batch Gradient Descent的主要想法

    在前面的实践中,使用“Gradient Descent”时,都是一次性把所有的数据集都考虑进去,一切似乎都没有什么问题。

    但是,在现实实践中,如果训练数据量非常大,这种方式就不适用了。试想,在前面的示例中,输入样本数据,即\( X \)(或者 \( A^{[0]}\)),其维度(或者说shape)则可能是\( 300 \times 10,000,000 \)。这会导致每一次的梯度计算量都非常大,一次迭代(epoch)的时间会很长。

    一种非常常见的、也是非常经典的梯度下降改进,就是 mini-batch gradient descent。首先,将样本分层若干小份,并单独对每个“小份”进行“Gradient Descent”,最后逐步完成所有样本的训练。完成一次所有样本的遍历,称之为一次迭代epoch

    在神经网络的训练中,可以用下面步骤理解这个过程:

    for "a-small-batch-of-samples X^{t} " in "all-samples"
        forward  propagation on X^{t}
        backward propagation on X^{t}
        update W/b
            W^{[l]} = W^{[l]} - lr * dW^{[l]}
            b^{[l]} = b^{[l]} - lr * db^{[l]}

    相对于 mini-batch gradient descent ,前面介绍的一次把所有样本都用于训练的方法,也被称为“batch gradient descent”。

    Stochastic Gradient Descent

    在 mini-batch 中,如果每次批量的样本大小是 1 的话,那么,也称为Stochastic Gradient Descent(简称 SGD,随机梯度下降)。事实上,自开始使用 Backpropagation 算法以来,SGD就被用于提升神经网络的训练的效率。并且很快的,mini-batch gradient descent 就作为一种优化被使用。目前,mini-batch gradient descent 依旧是一种常用神经网络训练方法[1][2]

    收敛稳定性预估

    不难想象,在“batch gradient descent”中,一次性把所有数据都用于梯度下降的算法,通常都能够获得更好的收敛速度。而在使用 mini-batch 的时候,由于不同的批次的样本在计算时,“计算梯度”都与“全局梯度”有一定的偏差,并且有时候偏差较大,有时候较小,所以,相比之下,收敛速度要慢一些。而,Stochastic Gradient Descent 则可能会更慢一些。

    可以这么理解, mini-batch 和 Stochastic Gradient Descent 都总是使用一个局部的梯度(部分样本的梯度)来预估整体的梯度方向,自然效果会差一些。

    这里我们改进了原来的神经网络实现 ssnn_bear.py,将其更新为使用 mini-batch 的 ssnn_cat.py。详细代码可以参考GitHub仓库:super simple neural network

    运行 ssnn_cat.py 并观察 mini-batch 的 cost 下降速度如下:

    mini-batch 迭代下cost总是在上下波动

    batch gd算法下cost下降非常稳定

    batch_size 大小的配置

    一些经验数值可能是64、128、256、512等。Mini-batch 需要在大数据量和向量化计算之间取得一个平衡,所以通常需要更具训练的设备选择合适的 batch 大小,使得每次迭代都充分利用硬件的资源。

    代码实现

    在前述的神经网络上(参考),再做了一些修改,实现了 Mini-Batch 或者随机梯度下降。

    新增 batch 大小参数

    首先,新增了 batch_size 参数表示,同时增加对应参数 batch_iteration 表示,在一次样本迭代中,总计需要循环多少次。所以,这两个参数有如下关系:

    batch_iteration = math.ceil(m/batch_size)
    对每批次样本做迭代
    batch_iteration = math.ceil(m/batch_size)
    ...
    for i in range(iteration_count):
        for i_batch in range(batch_iteration):
            ...
            # sample from i_batch*batch_size
            batch_from  = i_batch*batch_size
            batch_to    = min((i_batch+1)*batch_size,m)
            batch_count = batch_to - batch_from
            A0  = X[:,batch_from:batch_to] # column  [batch_from,batch_to)
            Y_L = Y[:,batch_from:batch_to] # Y_label [batch_from,batch_to)
            ...

    代码的其他地方,几乎不需要太大的改动。完整的代码参考:ssnn_cat.py

    参考

    • [1] Stochastic gradient descent
    • [2] https://github.com/orczhou/ssnn/blob/main/ssnn_cat.py
    • [3] https://github.com/orczhou/ssnn/blob/main/ssnn_bear.py
    • [4] https://github.com/orczhou/ssnn

    这是一个系列文章包含了,完整的文章还包括:

  • This content is password protected. To view it please enter your password below:

  • 对话式的大语言模型产品已经在改变我的很多日常习惯。鉴于 ChatGTP 国内访问非常不方便,现在也逐渐的在尝试使用通义千问、文心一言等产品。总体上感觉,通义千问和文心一言也都非常不错了,满足基本的日常使用是完全没有问题的,但相比于 ChatGPT 还是差了那么一点意思。这里记录一些日常使用的对比,看看,所谓的那么“一点意思”到底是什么。

    简要的问题和简要的回答

    这里的问题是:“方括号 英语”。来看看 ChatGPT、通义千问、文心一言的回答:

    ChatGPT

    通义千问

    文心一言

    可以看到,三个引擎都给出准确的答案。其中,ChatGPT 给出的回答最为简洁,也是这里我最为偏好的回答。

    为什么这里给出简单的回答更好呢?

    这里的问题非常简单,这时候,通常也是期望更为简单的回答的。试想这样的场景,你在写一篇英语小短文,但你不确定“方括号”的英语怎么说,恰好你旁边有一个英语很好的同事,你问她:“方括号的英语是?”。如果她像上述通义千问、文心一样,说了一大堆,你可能会打断她,因为当下写材料才是重点,不是想学英语。如果,我真的想学英语的话,我的问题,则可能是这样:“方括号 英语 并给出示例”。

    一般的,简单的问题简单回答就可以了。如果用户期待更多信息或者更详尽的回复,通常也会更详细的描述问题。

    再比如:“Latex表示一个矩阵(方括号): 变量用x表示,共n_x行,m列。其中行号用下标表示,列用带有括号的上标表示”

    ChatGPT

    通义千问

    文心一言

    同样的,ChatGPT 更简洁,通义千问次之,文心一言则略显啰嗦。毕竟,这时候我只是想要答案,不想知道获得这个结果的完整的推理过程。

    类似的,再比如:

    ChatGPT

    通义千问

    文心一言

    “分总/总分总”与“递进式”的结构

    我们来看看如下问题,不同的大模型的回答:使用中文介绍一下“Goldsmiths Research Online”

    ChatGPT

    通义千问

    文心一言

    可以看一下这个三个回答的对比,通义千问和文心一言,都使用了“总分总”或“分总”的结构去回答问题。而,ChatGPT则使用了递进式的结构,显得更加自然。

    同时,因为通义千问和文心一言总是倾向于使用“总分总”或“分总”类似的结构,所以就就会给人比较呆板一些的感受。

    前端展示效果

    因为最近在学习机器学习的一些原理,所以,有时候会让 ChatGPT 帮助编写一些数学公式。这里的问题是:x是一个3×4的矩阵,每个元素分别是1…12,使用latex写出这个矩阵。

    ChatGPT

    通义千问

    文心一言

    可以看到,ChatGPT 在前端应该使用了类似Latex的前端组件,有更好的展示效果。而通义千问、文心一言则没有使用类似组件去展示。根据测试,通义千问、文心一言也都是支持 Latex 的前端展示,只是不会经常使用。

    最后

    总体感觉,在日常使用中,通义千问、文心一言和 ChatGPT 差别并不是很明显,早期通过各种方式去科学访问 ChatGPT 现在看起来必要性并没有那么高了。但,在一些细节点上,还存在一些差距,期待通义千问、文心一言都后续的版本能够变得更强。

  • Oracle Cloud 是所有云平台最先支持 9.0 版本的。这里,我们来看看该版本的“标准性能”表现如何。

    测试实例与环境说明

    这里使用的实例类型是:MySQL.4,单个节点为4 ecpu 32gb,测试区域选择的是“东京”(ap-tokyo-1),多可用区(FAULT DOMAIN)的版本,测试实例存储空间大小为 100 gb。即:

    instance_type=MySQL.4
    vcpu_per_node=4
    memory_size_per_node=32
    region=tokyo
    availability=multi-az
    storage_size=100
    db_version=8.0.39/8.4.2/9.0.1

    性能对比

    本次测试分别测试了 8.0.39/8.4.2/9.0.1 这三个版本。详细的性能对比如下:

    dataMySQL80MySQL84MySQL90
    4355136063360
    8593653785256
    16805481867287
    32831780297817
    48813082047911
    64783879818060
    96850484308172
    128819882868000
    192804380538112
    256790780347536
    384820980558151
    512838680307872

    性能概述

    从该“标准”测试来看,9.0.1的性能较为稳定。从上述数据中来看,似乎略微低于 8.0和8.4 版本,但经过调查,主要原因是由于云平台 CPU 资源多少所导致的,而并不是数据库本身的问题。

    此外,在今年5月份观察到的8.4性能退化问题(参考),目前也已经解决。

  • 再登黄山

    ·

    去年的5月份和家人一起登过黄山,是个阴雨天,虽“三上三下”看到了“猴子观海”但更多景观多是雾里看花。这次运气非常好,山顶天气晴朗,群山云海、奇松奇石尽收眼底。和很多事情一样,虽黄山上的天气是多变的,但多做几次,老天总能偶尔眷顾。

    路线

    如下蓝色路线是,当天的行进路线概览:

    如下路线是GPS记录的详细路线:

    从索道上山到最后下山,一共花费了 7 个小时。其中大概有三个半小时,是在吃饭、等人、拍照等,完全没有移动的状态。如果自行安排时间,预留 4~5 小时是比较充裕的,而且体力也不会要求太高。当然,我们没有登最高峰天都峰或莲花峰。

    可遇不可求的云海

    这次再登黄山,天公作美,看到了可遇不可求的“云海”。黄山以奇石、奇松、云海而闻名。上次来的时候,虽天气不好,但也有幸看到了诸如猴子观海、始信峰等奇石怪峰,也看到了迎客松、黑虎松等奇松。

    可遇不可求的黄色云海
    那必须和云海、迎客松一起合个影

    再看猴子观海

    这次运气不错,视野非常好,远处的“猴子观海”看得非常清晰。

    黄山一线天

    似乎每个景点都有“一天线”

    徽州古镇

    在黄山附近,有很多的“徽州”古镇,其中最为有名的大概就是位于的“徽州古镇”。古镇确实也保存的不错,古镇中有很多小巷子,还住着当地的居民。

    这一代最为有名就是“许国石坊”。该牌坊已经有400年历史,为万历年间的大学士许国所修。因为牌坊比较牢固、高大所以也躲过十年浩劫,保存非常完整。许国18岁考中秀才,在六次参加乡试时中第一,即为解元。粗略理解,相当于现在的省状元吧。而后参加会试第七名;而后殿试为第一百零七名,为进士三甲[1]。此后,入朝为官,官至吏部尚书、建极殿大学士,《明史》有传。

    许国石坊

    另外,徽州古镇还保存了一些比较老的建筑。不过应该都是近现代的建筑。

    这是一家茶馆
    街角
    小巷子

    参考链接

    [1] https://zh.wikipedia.org/zh-cn/%E8%AE%B8%E5%9B%BD_(%E6%98%8E%E6%9C%9D)