orczhou.com

admin

  • 云数据库行业动态@2024-12-13

    ·

    admin

    标题：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]

    参考链接

  • 快速了解 Aurora DSQL

    ·

    admin

    上周在 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 依旧是创新、技术能力非常强的一家公司。此外，产品是在内测阶段，普通用户还无法体验。

    参考文档

  • 浅层神经网络的超参数分析

    ·

    admin

    在前述的文章（参考）中，我们实现了带有一个隐藏层的神经网络，并使用该神经网络对手写数字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

  • 云数据库行业动态@2024-12-06

    ·

    admin

    标题：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]

    参考链接

  • 关闭 InnoDB 的 redo log

    ·

    admin

    在 MySQL 实例恢复时（尤其是逻辑备份的恢复），为了获得更快的恢复速度，通常会关闭二进制日志（Binary Log），并且将 InnoDB 的日志持久化级别调整到最低。从 MySQL 8.0.21起[1]，更进一步的，可以彻底的关闭 InnoDB redo 从而获得更好导入速度。后续的 8.4 / 9.0 / 9.1 可以使用该特性。

    在本文的测试中，可以看到关闭 InnoDB redo log 导入速度可以提升约 26%。

    使用场景

    最为常见的就是在进行大量数据导入时，希望能够加速数据导入的过程。

    管理命令

    可以使用如下的命令关闭/或打开 InnoDB redo log：

     ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG

    关闭 InnoDB redo log

    mysql>  ALTER INSTANCE DISABLE INNODB REDO_LOG;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW STATUS LIKE '%Innodb_redo_log_enabled%';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Innodb_redo_log_enabled | OFF   |
+-------------------------+-------+
1 row in set (0.02 sec)

    打开 InnoDB redo log

    mysql> ALTER INSTANCE ENABLE INNODB REDO_LOG;
Query OK, 0 rows affected (1.02 sec)

mysql> SHOW STATUS LIKE '%Innodb_redo_log_enabled%';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Innodb_redo_log_enabled | ON    |
+-------------------------+-------+
1 row in set (0.00 sec)

    执行该命令的权限

    因为该命令对数据库影响巨大，所以也引入独立的权限 INNODB_REDO_LOG_ENABLE来管理该命令的执行权限。具体参考：

    mysql> GRANT INNODB_REDO_LOG_ENABLE ON *.* to 'data_load_admin';

    性能对比

    这里做应该简单的性能对比，看看关闭 InnoDB Redo Log 导入速度会提升多少。

    # mysql -uroot test -e "show status like 'Innodb_redo_log_enabled'"
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Innodb_redo_log_enabled | ON    |
+-------------------------+-------+
#  mysql -uroot test -e "truncate table passenger"
# time mysql -uroot test < passenger.1000.sql > /dev/null

real	0m3.109s
user	0m0.017s
sys	0m0.013s
# mysql -uroot test -e "truncate table passenger"
# mysql -uroot test -e "ALTER INSTANCE DISABLE INNODB REDO_LOG"
# time mysql -uroot test < passenger.1000.sql > /dev/null

real	0m2.286s
user	0m0.022s
sys	0m0.009s

    在这个初步测试中，可以观察到，在关闭 InnoDB Redo 之后，到如时间从 3.109s 降低到了 2.286s，在该导入中，节省时间约 26%的时间。

    参考文档

  • Protected: 再思考教育：关于学习成绩的思考

    ·

    admin

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