• 随着企业规模增长,或者,企业原本就在监管非常严格的行业或环境,所面临合规要求也会逐步增多,密码的定期轮换通常也是众多要求中的一个基础项。MySQL 8.0 提供的“双密码”管理机制,可以让大规模数据库密码轮换变得更平滑,而无需任何的停机时间。

    100台MySQL、1000台应用服务

    考虑这样的场景,你是一个 DBA ,生产环境有 100 台 MySQL 实例,运行在这些数据库上约有 1000 台应用服务器。如果需要对,这些 MySQL 的应用账号密码统一做一次更新,如何实现不停机的迁移。

    在 MySQL 之前(8.0.14版本之前)的单密码机制下,更换密码通常会遇到以下问题:无论是先更新数据库服务器上的密码,还是新调整应用服务器上的密码,这个先后顺序都会带来一定的服务不可用时间。通常,为了降低这个服务不可用时间,应用变更人员和 DBA 则需要非常密切的配合。

    双密码机制(dual password)

    从 MySQL 8.0.14 起,开始支持了双密码策略。在密码更换时,可以保留旧密码依旧可用:

    ALTER USER 'appuser1'@'host1.example.com'
      IDENTIFIED BY 'password_b'
      RETAIN CURRENT PASSWORD;

    在一段时间后,可以删除旧密码:

    ALTER USER 'appuser1'@'host1.example.com'
      DISCARD OLD PASSWORD;

    构建批量密码轮换流程

    有了该功能,就可以使用上述的命令,更加平滑的实现大规模数据库场景下的密码更换。

    1. 给变更数据库服务器上账号的密码,同时将原密码作为备用密码保留(使用“RETAIN CURRENT PASSWORD”)
    2. 变更应用服务器上的访问数据库的密码
    3. 检查并观察一段时间,删除数据库中的原密码(使用“DISCARD OLD PASSWORD ”)

    这是一个简化的过程,实际的操作还需要考虑:

    • 严格遵循企业内部的变更规范
    • 灰度的进行发布,而不是一次性操作所有的实例/服务器
    • 做好检查,需要确保诸如密码已经变更完成、应用服务器密码均已经更新
    • 做好回滚方案,避免过程中操作失误导致的问题
    • 在业务低峰时间进行操作

    参考阅读

  • 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

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

  • 标题:KaiwuDB时序场景获benchANT第一;阿里云RDS支持自定义原生复制;GaussDB高分完成HyBench

    重点更新

    华为云数据库GaussDB以最高成绩顺利完成HyBench基准测试。在1000X数据量场景下,GaussDB H-Score评分为:1483.63,为历史最高成绩的3.8倍[1]

    KaiwuDB 在国际权威数据库性能测试 benchANT 获得时序数据库场景第一名。具体的,KaiwuDB 数据库在 xsmall 和 small 两类规格下的时序数据写入吞吐、查询吞吐、查询延迟、成本效益等多个指标刷新榜单原有数据记录,位居全球时序数据库性能测试榜单第一[2]

    阿里云 RDS MySQL 支持以原生命令的方式管理复制,可以帮助用户更简洁的实现容灾、数据上云,当前该功能处于邀测阶段[5]

    功能详情

    阿里云
    • 阿里云 RDS MySQL 支持原生复制,支持直接使用数据库的复制管理命令,实现便捷的数据上云、容灾等能力[5]
    • RDS MySQL 全球多活数据库(GAD)灾备实例组新增数据双向同步能力,同时在灾备链路中您可以选择同步整个实例或指定库表的数据 [4]
    Azure(微软云)
    • Azure Database for PostgreSQL 现支持性能管理参数的修改[6]
    • Azure Database for PostgreSQL 支持了网络监视指标、高可用性健康状态指标等 [7][8]
    AWS(亚马逊云)
    • Aurora Serverless v1 将逐步停止服务支持,建议用户升级到 v2 版本 [26]
    • Aurora 现可作为 Amazon Bedrock 知识库中的快速创建向量存储使用 [33]
    GCP(谷歌云)
    • AlloyDB 支持 ScaNN 向量索引执行 K 最近邻 (KNN) 和近似最近邻 (ANN) [11]
    • AlloyDB 数据库性能快照报告功能已 (GA) [16]
    火山云(字节)
    • veDB MySQL 支持创建仅关联主节点的自定义读写终端 [17]
    • 支持在 veDB MySQL 控制台修改通过 SQL 创建的不符合命名规范账号的权限和密码 [20]
    • veDB MySQL 新增对 Terraform 的支持 [21]
    腾讯云
    • TDSQL-C MySQL 版实例形态为预置资源的集群支持挂载 Serverless 只读实例,实现集群下的混合部署(一个集群同时挂载预置资源只读实例和 Serverless 只读实例),也支持将集群下预置资源只读实例转化为 Serverless 只读实例。[35]

    参考链接

  • 上周在 AWS re:Invent大会(类似于阿里云的云栖大会)上推出了新的产品 Aurora DSQL[1] ,在数据库层面提供了多区域、多点一致性写入的能力,兼容 PostgreSQL。并声称,在多语句跨区域的场景下,延迟只有Google Spanner的1/4。

    Aurora DSQL 提供了多可用区、多区域的多点一致性写入的内容。在技术层面,Aurora DSQL 通过把数据库的 log 模块和 block (或者说是cache)模块做了分离,从而更好的实现多点/多区域分布式能力,这与 Google AlloyDB 是比较类似的;此外,在跨区域强一致性实现上,则使用“Amazon Time Sync Service” [3] 来保障多个区域之间事务顺序的一致性。

    在产品层面,分为两个场景,一个是 Aurora DSQL(region内模式)和一个 Aurora DSQL Global 模式(多 region 内模式)。在 Region 内场景下,相比于普通 Aurora PostgreSQL ,Aurora DSQL 在多个可用区内都可以提供强一致的读写接入点,而Aurora PostgreSQL只在一个可用区提供写,其他可用区仅提供只读节点。

    在跨 Region 的场景下,Aurora DSQL 则提供了同步的、跨区域的多点写入能力。这对于业务在全球分布的客户,则可以进一步的降低业务的复杂度。而原来的 Aurora Global Database 仅提供单个 Region 的写入能力,并且,在其他 Region 的读节点需要承受一定的数据访问延迟,这对于很多的在线业务场景可能是无法接受的,或者需要在应用层面做针对性的改造。

    这是 Aurora 发布的10周年,AWS 依旧是创新、技术能力非常强的一家公司。此外,产品是在内测阶段,普通用户还无法体验。

    参考文档

  • 在前述的文章(参考)中,我们实现了带有一个隐藏层的神经网络,并使用该神经网络对手写数字0/1进行识别。本文对该神经网络的识别效果以及相关的超参数的配置做一些分析与优化。

    这里涉及的超参数包括了学习率、迭代次数、隐藏层神经元的个数,这里对这三个参数的不同取值进行了相关测试,并观察训练时间与模型效果。

    不同学习率的模型训练

    学习率应该是这里最为重要参数了。在相同的迭代次数下(这里取500),不同的学习率展现出了非常大的差异。这里从0.001开始、尝试了:0.001、0.005、0.01、0.1、0.5等取值。详细的数据如下:

    可以看到,不同的学习率展现出了训练效率的差异非常大:

    • 在相同的迭代次数(均取500)情况下,学习率增加到0.1之后,预测错误率降低到了0.09%,并且再增加学习率,预测错误率并没有提升
    • 在学习率,从0.001增加到了最后的0.5之后,在进行了相同的迭代次数时,训练的目标函数取值下降一直都较为明显

    学习率如何影响目标函数的收敛速度

    右图展示了学习率取值分别为0.1和0.01时,目标函数的收敛速度趋势图。可以看到:

    • 学习率为 0.1 时,在迭代约40次以前,目的函数的收敛速度非常快,并快速的收敛到了非常低的水平
    • 学习率为0.01时,迭代到100次时,代价依旧非常高

    从这次实现代码也可以看到,学习率对于模型的训练效率有这至关重要的影响。如果学习率选择不合适,则会耗费大量计算资源进行非常慢的训练。那么,如果选择合适的学习率以进行更加高效进行梯度下降迭代,这是一个比较复杂的问题,这里暂时先挖个小坑在这里,待后续再做更多讨论。

    迭代次数 epoch 如何影响模型

    这里选取学习率为0.01,隐藏层10个人工神经元,从而观测随着“迭代次数”效率如何影响:

    可以看到,当迭代不够充分时,目标函数收敛还不够时,模型效果也会比较差。随着迭代次数不断增加,目标函数下降就不再明显了。完整的目标函数收敛趋势如下图:

    隐藏层神经元个数与模型效果

    这里观察隐藏层神经元个数与模型效果趋势图。这里分别测试了1、10、50、100、150、300个神经元时候模型的表现,如下图:

    从测试来看,在这个案例中,随着隐藏层神经元个数的增加并不会提升模型性能的。这可能暗示了,此类任务(图像识别相关)使用前馈神经网络时,其性能可能较差。

    部分识别失败的图片

    在该模型与训练下,部分识别失败率比较高的图片如下:

    9879
    8325
    9634
    3073
    2185

  • 标题:AWS re:Invent 发布新的数据库产品 Aurora DSQL; NineData SQL编程大赛开始; 腾讯云支持PostgreSQL 17

    重要更新

    AWS re:Invent 发布新的数据库产品 Aurora DSQL ,提供了跨区域、强一致、多区域读写的能力,同时具备99.999%(多区域部署)的可用性,兼容PostgreSQL;同时发布的还有 DynamoDB 也提供类似的跨区域强一致的能力。 [1] 

    第二届 SQL 编程大赛开赛,感兴趣的可以去挑战一下:一条SQL秒杀100万张火车票 [2]

    更新详情

    阿里云
    • 开启RDS MySQL的写优化功能后,可以确保每次数据页写入的原子性,从而安全地关闭InnoDB双写机制。这不仅降低了I/O写入量,还简化了刷脏过程,大幅度降低实例写盘的IOPS及带宽需求,达到提升实例写性能的目的。[4]
    • RDS MySQL本地盘实例最大IOPS提升—RDS MySQL本地盘实例(含主实例与只读实例)的最大IOPS调整,最高提升至150000。本次IOPS提升不会产生任何额外费用。[5]
    • 主实例规格—RDS PostgreSQL主实例高可用系列标准版独享规格上线大规格实例。[6]
    火山云(字节)
    • veDB MySQL 支持创建兼容 MySQL 5.7 版本的实例,您可根据业务情况,选择合适的兼容版本,满足更多业务场景需求。[11]
    AWS(亚马逊云)
    • DynamoDB 支持零 ETL 与 Amazon SageMaker Lakehouse 集成[20]
    • Oracle Database@AWS 现已推出有限预览版 [40]
    腾讯云
    • TDSQL-C MySQL 版“只读分析引擎”发布了新版本,支持了新的函数、进行了系统优化,例如:支持了 FROM_UNIXTIME 与 UNIX_TIMESTAMP 函数 [42]
    • TDSQL-C MySQL 版支持 Serverless 成本评估器,帮助您更好的了解使用 Serverless 服务的成本。[43]
    • 云数据库 PostgreSQL 全面支持 PostgreSQL 17.0。[44]
    • 云数据库 PostgreSQL 开启8core 64GiB规格售卖。[45]

    参考链接