简单生活

  • 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)

  • Docker 安装非常简单,几乎一分钟内即可完成安装。

    Docker 安装 MySQL 9.1

    安装镜像:

    docker pull container-registry.oracle.com/mysql/community-server:9.1

    启动镜像:

    docker run --name=mysql91  --restart on-failure -d container-registry.oracle.com/mysql/community-server:9.1

    查看初始安装时 root 账号密码:

    docker logs mysql91 2>&1 | grep GENERATED

    登录安装的数据库:

    docker exec -it mysql91 mysql -uroot -p

    好了。这就完成安装了:

    # docker exec -it mysql91 mysql -uroot -p
    Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
    Enter password:
    Welcome to the MySQL monitor.  Commands end with ; or \g.
    Your MySQL connection id is 10
    Server version: 9.1.0
    
    Copyright (c) 2000, 2024, Oracle and/or its affiliates.
    
    Oracle is a registered trademark of Oracle Corporation and/or its
    affiliates. Other names may be trademarks of their respective
    owners.
    
    Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
    
    mysql>

    修改 root 密码:

    ALTER USER 'root'@'localhost' IDENTIFIED BY 'YOUR-NEW-PASSWORD';

    详细的步骤与说明可以参考:Basic Steps for MySQL Server Deployment with Docker

    其他的 Docker 相关管理命令

    docker start    mysql91 # 启动
    docker stop     mysql91 # 关闭
    docker restart  mysql91 # 重启
    
    docker rm       mysql91  # 删除容器

    体验 MySQL 9.0/9.1 系列

    创建数据库:

    mysql> create database orczhou;
    Query OK, 1 row affected (0.00 sec)
    
    mysql> use orczhou
    Database changed

    创建一个表,可以用于存储向量,并进行简单的向量计算:

    create table vector_t01 (
        id int,
        s_v_01 vector(390),
        s_v_02 vector(390)
    );
    
    mysql> create table vector_t01(id int,s_v_01 vector(390),s_v_02 vector(390));
    Query OK, 0 rows affected (0.02 sec)
    
    mysql> insert into vector_t01 values (1,string_to_vector('[1,2,3]'),string_to_vector('[4,5,6]'));
    Query OK, 1 row affected (0.00 sec)
    
    mysql> select DISTANCE(s_v_01,s_v_02);
    ERROR 1305 (42000): FUNCTION orczhou.DISTANCE does not exist

    啥!FUNCTION DISTANCE does not exist

    看看文档描述,我下巴掉了一地(参考):

    Note

    DISTANCE() is available only for users of HeatWave MySQL on OCI; it is not included in MySQL Commercial or Community distributions.

    没有search就算了,好不容易有一个 DISTANCE,发现还是受限制的…

    好了,那就体验到这里吧… 期待在后续的版本能够把搜索功能补齐。一定要体验的话,可以自己去Oracle Cloud进行测试。

    参考链接

  • 标题:Zilliz获Forrester报告全球第一;OB支持向量能力;Azure发布DiskANN,吊打pg_vector;阿里云PG发布内置分析引擎;AWS发布托管Valkey服务

    重要更新

    Azure发布 PostgreSQL 向量索引扩展DiskANN,声称在构建HNSW/IVFFlat索引上,速度、精准度都超越pg_vector,并解决了pg_vector长期存在的偶发性返回错误结果的问题 [1] 

    阿里云 RDS PostgreSQL 发布AP加速引擎(rds_duckdb)。该引擎提供了列存表和向量化执行能力,显著提升复杂查询的执行速度,且无需修改原始查询语句,从而确保您能够方便且高效地获取结果。当前白名单开放中[7]

    OceanBase发布4.3.3版本,支持了向量数据存储与索引功能,这也是4.3版本第一个GA版本[3]

    Forrester发布第一份Vector Database的报告(Forrester Wave),Zilliz(产品名:milvus)凭借完整、高效的向量数据处理能力获的第一。后续厂商分别有:DataStax、Microsoft、Amazon、Oracle、Pinecone等[2]

    更新详情

    阿里云
    • RDS MySQL支持定价详情功能,可以查看各计费项的定价说明和价格。[4]
    • RDS PostgreSQL新增支持PostgreSQL 17大版本。[5]
    • RDS PostgreSQL高可用系列标准版新增pg.x8.16xlarge.2c(128核 1024GB)独享规格。[6]
    • RDS PostgreSQL发布AP加速引擎(rds_duckdb)。该引擎提供了列存表和向量化执行能力,显著提升复杂查询的执行速度[7]
    • RDS PostgreSQL 内核版本发布小版本20240830 [8]
    • PolarDB Serverless集群支持IMCI列存索引(IMCI)功能 [9]
    GCP(谷歌云)
    • 创建Cloud SQL支持了证书颁发机构 (CA) 配置功能 [11] 
    • pg_ivm 扩展版本 1.9 现已正式发布。此扩展可让您更新物化视图,其中仅计算增量更改并将其应用于视图,而不是从头开始重新计算内容 [12] [13] 
    • “alloydb_scann”扩展程序(以前称为“postgres_scann”)已正式发布(GA),如需详细了解如何存储向量嵌入、创建索引以及调整索引以实现更快的查询性能和更好的召回率,请参阅使用向量[17] 
    • 现在,您可以在创建实例后使用“gcloud sql instance patch”命令更新 Cloud SQL for SQL Server 实例的时区。以前,您只能在首次创建实例时为 SQL Server 实例设置自定义时区.[19] 
    • Cloud SQL for MySQL 8.4 现已正式发布  [24] 
    • AlloyDB 主实例和备实例上支持公网IP [26] 
    火山云(字节)
    • DBW 数据库审计日志的默认保留时长变更为 30 天,同时新增支持选择保留 180 天、1 年和 3 年。[30]
    • 在操作审计页面 DBW 管理员支持查看所有操作行为,DBW 普通用户和非 DBW 系统角色仅支持查看自己的操作行为。[33]
    AWS(亚马逊云)
    • Aurora Serverless v2 新增支持 256 个 ACU [35]
    • Amazon Aurora/RDS 支持控制台到代码 [36]
    • Amazon 新增 ElastiCache for Valkey /MemoryDB for Valkey [38] [39] 
    • Aurora 支持 PostgreSQL 16.4、15.8、14.13、13.16 和 12.20 [50]
    • Aurora MySQL 现已支持 RDS 数据 API [51]
    腾讯云
    • TDSQL-C MySQL 版“只读分析引擎”内核版本更新到1.2404.10.0,主要优化了产品使用的体验和稳定性。支持了 date_sub 函数 [53]
    Azure(微软云)
    • 托管 PostgreSQL 支持了更多数据库参数的修改 [54]
    • 托管 Redis 7.2( Azure Cache for Redis Enterprise)正式发布 [55] 
    • 托管 PostgreSQL 支持postgresql_anonymizer插件,更好的保护隐私数据 [56] 
  • 在不同的云厂商,购买相同规格的MySQL实例(如4vCPU-16GB),获得的性能相同吗?

    dataaliyun_202409_hangzhou->stdbenchtencent_202409_beijing_exclusive->stdbenchhwcloud_202409_beijing_x86->stdbenchbaiducloud_202409_beijing->stdbenchaws_202409_tokyo_m6i->stdbenchazure_202409_east_asia_4c16g->stdbenchgcp_202409_tokyo_80_enterprise->stdbenchoci_202409_tokyo_8039->mysql_on_4_ecpu
    47102559225572206163920257233551
    897029936467441013313365413415936
    161466016141822972986427654825028054
    3222155223361352012022121571036348578317
    4827905247701784916448165161197367458130
    6432704264952011418187181181276180717838
    9636846290772088321007207821330096758504
    128396972991820128210292244613388106208198
    192389993061020521220912259013478115078043
    256383563105221187216652232312985118727907
    384396793122421729211672190212904121318209
    512403333180522647216272159112930121068386
    have_sslDISABLEDDISABLEDDISABLEDDISABLEDYESYESYESYES
    innodb_buffer_pool_size9.75GB12GB9GB12GB11GB12GB11GB17GB
    innodb_doublewriteONONONONOFFOFFONON
    innodb_flush_log_at_trx_commit11111111
    innodb_flush_methodO_DIRECTO_DIRECTO_DIRECTfsyncO_DIRECTfsyncO_DIRECTO_DIRECT
    innodb_io_capacity200002000012000200020020050001250
    innodb_read_io_threads44484NA42
    innodb_write_io_threads44484NA44
    log_binONONONONOFFONONON
    performance_schemaOFFOFFOFFOFFOFFONONON
    rpl_semi_sync_master_enabledONONONONNANANANA
    rpl_semi_sync_master_timeout1000100001000010000NANANANA
    sync_binlog11110001111
    thread_pool_size84NANANA4NA16
    version8.0.368.0.30-txsql8.0.28-2310038.0.32-2.0.0.28.0.358.0.37-azure8.0.31-google8.0.39-cloud
    cpu_capacity80.493.3163.673.9110.956.349.9114.7

    测试结果概述

    在本次测试中:阿里云RDS MySQL性能表现最好,极限的QPS达到了4万;其次是腾讯云,达到了3.2万;第二梯队是华为云、百度云和AWS,极限的QPS约2.2万;之后是Azure、Google云,极限QPS约1.2万;最后是Oracle云,极限QPS约8500。详细的数据和趋势图,可以参考以上的图、表,这里不再详述。

    (more…)
  • 数据库DevOps这个话题我讲过很多次了,在阿里的数据库环境,已经是成熟的实践经验。现在离开阿里,以独立数据库工具厂商的身份去讲这个话题,还是有一些不一样的思考。

    09年,刚加入淘宝DBA团队的前几年,其实是很痛苦的。最早还没有工具和平台的思维,很多事情都是”手挑肩扛”。不过生产环境的数据库数量增长很快就远超团队人员增长速度。最早,淘宝内部将DBA分为”系统DBA”,负责数据库的安装/部署、监控、备份、性能监控报警、故障诊断等工作;还有一部分是”产品DBA”,负责面向上层业务的数据库支持,包括数据库的设计与发布、架构选型、业务优化、容量规划等。

    当时我在”系统DBA”团队,为了解决人员与系统增长不匹配的问题,当时也在前辈建立的”北斗”数据库管理基础上进行改进,并构建了淘宝数据库环境内首个MySQL数据库管理平台”天机“,取名字也是来自”北斗”七星中的”天玑”,不过取自”天机不可泄露”便取”天机”。而后,这个平台也几经改造与重构,发展为内部一套完整、健壮的DBaaS系统。

    而”产品DBA”也面临着同样的问题,表现上略有不同。主要问题包括:业务/研发爆发式增长,”数据库的设计与发布、架构选型、业务优化(性能管理)、容量规划”这些原本DBA的工作,已经不可能再靠有限的DBA人力完成了。于是,内部的开始尝试通过一些简单的工具尝试解决这个矛盾。最早,先是使用WebSQLPlus解决数据查询的问题、而后是dbtask解决了数据库DDL发布的问题。再之后,对于研发、DBA如何一起共同支撑起业务发展,从而构建出了全新的iDB平台,并且在iDB从3.0升级到4.0版本时候,重新对平台做了定位,由一个面向DBA的工具,转变为面向研发使用数据库的产品,也是在这个时候,正式提出了数据库DevOps的理念。

    在2017年,这套产品也在阿里云上正式商业化发布,开始从一个服务阿里内部的系统正式的以商业化的形式服务云上的更多企业。

    2021年,离开了阿里,一方面是很冲动,另一个很重要的原因是认为,这套系统应该是一个独立于某个云厂商的、第三方的系统,这样可以更好的服务当前企业用户,无论企业用户的数据库是在阿里云、还是在华为云、腾讯云、AWS、百度云,亦或者是在自己筹建的IDC之内,都可以很好的使用这个产品,用这个理念去管理数据库,去解决研发、DBA与数据库的问题。

    记得特别清楚,有一年端午节,在内部p8->p9的晋升答辩上,有一个评委问我:“DMS/DTS”等这些工具产品,交由第三方厂商去做是不是更好?当时回答得很凌乱…,现在可以给评委一个简单的回答了:“是的”。

    关于这次分享的详细内容可以参考,这篇文章:《企业级数据库 DevOps 最佳实践,通过 NineData 实现高效安全的数据库开发》。分享的片子如下:

    orczhou-database-devops-best-practice-dtcc-2024