orczhou.com

简单生活

  • Protected: 与“上苍”的契约

    ·

    admin

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

  • 参加 GOSIM 大会的 AI 见闻

    ·

    admin

    大概是在朋友圈看到的这个会议 GOSIM（Global Open-Source Innovation Meetup），注意到有来自HuggingFace、vLLM、SGLang、BAAI 、字节等开发者来分享，果断报名去学习。大会是周六、日两天大概有接近10个分会场同时并发分享，于是只能选择一些自己感兴趣的部分主题听听，本文是部分见闻记录与分享。

    推理优化与推理框架

    这次关于大模型“推理优化”相关的话题特别多，包括 vLLM、Llama.cpp、SGLang、🤗 Optimum、Chitu、kTransformers、llm-d 等。大模型要能够向企业或组织提供服务，除了通过 API （SaaS）的方式之外，最为常见的则可能是需要搭建一套具备高并发服务能力的平台，而这些平台则需要满足高并发、底层本、易运维等要求，这就是上述这些框架、工具所解决的问题。相关的研究和发展方向则集中在KVCache优化、网络优化、PD分离、容器化管理、量化效率提升、多硬件适配、国产化适配（Chitu）、expert deferral等。

    如果用数据库类比的话，这大概相当于各种 DBPaaS 平台如何通过调度、CPU硬件、网络设备去提升整理的数据库资源利用率。但是，LLM/VLM等所面临的问题，则更多的关注在 GPU （或与CPU协同等）层面。

    “赤兔”定位是开源的「生产级大模型推理引擎」，面向于国产硬件环境做了很多适配，是一家“清华”背景的计算机专家推出的产品，背后的公司是：清程极智。

    SGLang 是一个被比较广泛使用的大模型 大语言模型（LLMs）及多模态语言模型（VLMs）推理平台。该项目是LMSYS的一部分，目前似乎是以非盈利组织的模式在运作。该组织，最初是源自美国多所大学协作的项目（参考）。LMSYS 开发的其他著名项目包括：Chatbot Arena 、SGLang、FastChat、Vicuna LLM等。

    🤗 Optimum 是对 Transformer 库的扩展，目标是能够让模型能够更加高效在多种不同的硬件平台上高效的运行，包括训练和推理等。目前适配的硬件包括了NVIDIA、AMD、Intel、AWS Trainiu/Inferentia、Google TPUs、Habana、FuriosaAI，此外也可以非常方便与多个开源模型优化矿建进行集成，例如ONNX、ExecuTorch、Exporters、Torch FX。

    Second Me

    现在的大模型学习能力确实非常强，也许真的可以虚拟出一个“人”完整的“影子”。这个项目非常有意思，也获得了非常多个关注，项目的强调 “AI that amplifies, not erases, YOU.” 。项目的构想在于使用本地模型和存储，基于个人的数据、事件等构建一个数字的自己。也许现在的 AI 技术让这个设想有了某种可能性，这个项目则是对这种可能性的探索。感兴趣的可以关注：Second-ME。

    Agents

    因为时间所限仅选择了部分 Agents 场次去听，包括“扣子空间”、“Google Agents”等。

    来自Google的开发者则非常系统的介绍了面向Agent，Google为整个生态提供了哪些能力，其实是几乎覆盖了整个Agent生命周期的，包括了 Agent 构建SDK、Agent之间通信、Agent托管等一系列完整的服务。Google 对于 AI 各个方向都是非常大的，并且整体都很成功，这大概也能够顺利的帮助 Google 从搜索时代过渡到 AI 对话时代。

    字节跳动的大模型（Seed）似乎还在“蓄力”阶段，但是上层的应用迭代和发展比较快。面相普通用户有“豆包”，面相开发者则有“扣子”，基于“扣子”，最近则退出了类似的“deep research”产品“扣子空间”。这次大会上，来自字节的工程师则分享了Agent、多Agent构建过程中的一些经验。此外也分享了一些有意思的“事实”：目前Agent领域发展非常快，在2024年初Agent基本上仅限于对话、陪伴机器人等少数方向；2024年底，智能客服则逐渐走向较为成熟的阶段；而现在则百花齐放，各个领域都在做大量探索，最为典型的就是“Manus”模式。

    OpenSeek

    OpenSeek 是一个比较新的、由 BAAI 发起的一个开源大模型项目，该项目致力于构建一个更加完整开源大模型项目，而不是仅仅开源模型架构和参数，而是提供更加完整模型构建过程的代码，从而向开发者提供更加“开放”的模型。此外，这次分享中，也介绍了一些 OpenSeek 的一些基础实现，例如mid/post training，此外特别提到了 OpenSeek 的 DMA 机制（Dynamic Mask Attention 通过动态计算部分Token的Attention，降低计算复杂度）去实现更高性价比的模型训练与推理。感兴趣的可以访问 GitHub 地址：OpenSeek@GitHub。

    MemTensor

    随着 AI 技术的继续发展，预训练和后训练对于模型能力的增强的加速度是在下降的。那么，为了提升自然语言与模型的交互的效果，演讲者认为“记忆体”可能会成为增强大模型体验的关键组件。MemTensor团队则尝试通过将模型与“记忆”更加紧密的链接起来，从而增强模型的使用体验。

    关注的议题：

    最后

    GOSIM 大会大概有超过十个分论坛在并行分享，还有很多关于具身智能、Rust等相关的技术。

  • 最近

    ·

    admin

    最近参加了很多的线下的活动，包括了ACMUG、AWS 中国峰会、华为云HDC、IvorySQL & PostgreSQL生态大会，另外，还泡了一些杨梅酒、看了《长安的荔枝》，公司的产品“NineData”社区版发布了4.2.0。

    最近下线的活动很多，包括OceanBase、TiDB、各个云数据库厂商、各个数据库社区等，都在积极的组织一些社区活动，总的感受是，活动虽然很多，但开发者们对线下活动的热情是在减退的，而如果一场活动与AI关系不大，那么来现场的人一般是对这个技术的“真爱”。

    华为云的 HDC

    在上周末，受华为云数据库的朋友邀请，去参加华为云的 HDC 大会（开发者大会）。最近几年，和华为云的数据库合作比较多，也结识了很多华为云数据库团队的人。虽然数据库技术都是一样的，但每家公司都有着自己非常独特的环境与基因，有这自己不一样的风格。华为云数据库，感受着更多来自客户与一线的炮火，有着更接地气的拼劲。而整个公司因为在全球范围内的制裁压力，反而激发了更强的凝聚力。这次HDC大会上，华为云数据库发布了：GaussDB业务透明多写能力、“GaussDB Doer”一个面向华为云数据库的运维助手、TaurusDB for PostgreSQL

    此外，这次的HDC是在华为的松山湖园区，这是一个非常有特色的欧洲式建筑园区，随手拍了几张石雕，感受一下：

    前面的骑马的女神，大概是雅典娜
    拿着美杜莎之盾，大概是伯尔修斯
    经周陌认证，中间大概是波塞冬
    奥古斯都 屋大维

    ACMUG

    今年是 MySQL 30 年，这次成都的线下活动算是特别盛大的一次了，成都虽然有点远，但 MySQL 领域很多的有影响力的人去了。活动本身除了白天严肃的分享议题之外，下午、晚上大家随意闲聊各种八卦似乎要更有趣一些，这大概也是更多人参加的动力吧。

    亚马逊中国峰会

    这是因 NineData 赞助而去参加的活动，是以合作伙伴的身份参加的。Amazon的峰会在2015年的时候曾在上海参过一次，2018年还曾去过Vagas参加过一次re:Invent。Amazon 在全球云计算领域的地位依旧遥遥领先，但中国是一个特别的地方，确实很特别，无论是 Oracle 还是现在的 Amazon ，在全球大杀四方的时候，在中国却寸步难行，到底是谁的问题，一时难下结论，但这也确实给中国的厂商们留下一些时间和机会。

    云计算是现代应用非常底层的基础技术，而亚马逊作为一家美国的企业，要在中国开荒拓地，如果国际合作关系没有好转，未来大概是难有好转的。

    社区版发布4.2.0

    此外，这段时间，NineData 的社区版也发布了4.2.0，这是一个免费的（但不开源）数据库迁移同步工具，该免费版本中可以非常方便的帮助开发者完成诸如MySQL迁移、PostgreSQL迁移、Doris同步等工作。但如果是重要的生产环境或者需要长期运行的关键链路，则依旧建议考虑采购企业版。

    IvorySQL & PostgreSQL 生态大会

    这次大会主要由“瀚高”数据库团队在背后主办，是非常赞的活动，大会上有着关于 PostgreSQL 数据库方方面面的技术话题。这次参会，也认识了更多的 PostgreSQL 方向的开发者们。

    正如自己数年的感受一样：“PostgreSQL 在经历一场慢热的崛起”。从过去两三个月的两场收购（Neon、Crunchy Data）来看，在 AI 时代，PostgreSQL 依旧是在潮头的。

    杨梅酒

    最近几年，越来越体会到，杨梅是一种极为美味的水果了。杨梅大概在每年的6月初成熟，到了月底则已经逐渐下架，又因为其运输和保存都非常困难，也让这口美味，更显难得。江浙一带的杨梅种植技术大概是非常强的，这里的杨梅品种是非常独特的，甜中带着酸、酸中偷着甜，早上从台州一带的树上摘下，中午或晚上送到杭州，简单清洗一下，吃上十个八个，实为人间难得的美味。

    杨梅因为表面没有保护的表皮，所以其运输的难度比起荔枝要难数十倍。“杨贵妃”大概是没有尝过江浙一带的杨梅的，否则，则可能每年下江南一次。想运到长安或洛阳，不要说古代，即便是现在，都有一些困难的。

    喝酒这件事情，我大概是“人菜瘾大”的那类。在听说可以用杨梅泡酒后，从去年起就做了一些尝试。今年的杨梅酒已经按经验泡制、封存，约两个月后就可以品尝了。届时，如果感兴趣的，可以来我家“尝一尝”。

    长安的荔枝

    今年，一个多年未见的小学同学给我寄了一箱来自岭南一带的荔枝，放了半箱再公司，剩下的自己和家人吃了部分，上下楼的邻居也送了一些些。在此，代这些吃上荔枝的人一并感谢这位多年未见的同学。

    公众号久不更新，甚是心慌，记录如上，算是交代。

  • 在Schema-Less场景下使用MySQL：MySQL JSON Path的使用

    ·

    admin

    随着 MySQL 对 JSON 类型的原生支持，操作 JSON 数据已变得非常高效与强大。在过去数年的版本中，MySQL 也在不断地增强 JSON 处理相关的功能。在 JSON 处理中需要非常频繁的使用“JSON Path” 语法，而这部分又是略微复杂的部分，本文将系统的介绍如何在 MySQL 中使用 JSON Path，包括语法规则、各种通配符用法、递归匹配等高级技巧，并通过丰富示例帮助开发者快速掌握。

    什么是 JSON Path？

    JSON Path 是一种表示法，用来描述如何在 JSON 文档中定位数据。类似于文件系统路径，JSON Path 指引着从 JSON 根节点出发，逐步深入结构内部。在 MySQL 中，几乎所有的 JSON相关的函数都会使用到，包括：JSON_EXTRACT()、JSON_SET()、JSON_REPLACE()、JSON_REMOVE()、JSON_CONTAINS()等。

    我们看到的场景的写法类似于：$.name、$.colors[0]、$.store**.price等。

    基础语法说明

    JSON Path的基础语法，遵循以下规则：

    • $：表示 JSON 文档的根节点。
    • .：用于访问对象中的属性。
    • ["key"]：另一种访问对象属性的方式，适合处理特殊字符的 key。
    • [index]：访问数组中的元素。
    • *：通配符，匹配所有子元素。
    • **：递归通配符，匹配所有嵌套层级的元素
    • [start to end]：数组范围选择

    JSON Path 基本示例

    示例表与示例数据

    创建带 JSON字段的表，并写入数据：

    CREATE TABLE t1 (
    id INT PRIMARY KEY AUTO_INCREMENT,
    data JSON
);

INSERT INTO t1 (data) VALUES
('{
  "name": "Alice",
  "age": 25,
  "email": "alice@example.com"
}');

    提取对象字段

    这里使用基本的$.name引用根节点中属性为name的对象，示例如下：

    mysql> SELECT JSON_EXTRACT(data, '$.name') FROM t1;
+------------------------------+
| JSON_EXTRACT(data, '$.name') |
+------------------------------+
| "Alice"                      |
+------------------------------+
1 row in set (0.00 sec)

    也可以使用如下等价的写法data->'$.name'：

    mysql> SELECT data->'$.name' FROM t1;
+----------------+
| data->'$.name' |
+----------------+
| "Alice"        |
+----------------+

    访问数组元素

    初始化如下数据：

    -- truncate table t1;

INSERT INTO t1 (data) VALUES
('{
  "colors": ["red", "green", "blue"]
}');

    先访问colors属性，再查找该数组对象的第一个元素（注意：编号是0），故 JSON Path 为$.colors[0]，示例如下：

    mysql> SELECT data->'$.colors[0]' AS first_color FROM t1;
+-------------+
| first_color |
+-------------+
| "red"       |
+-------------+

    访问数组的范围

    除了像上述展示的，可以使用数值访问数组外，还可以使用0 to 1这样的语法表示一个范围，并访问数组中的多个元素：

    mysql> SELECT data->'$.colors[0 to 1]' AS first_color FROM t1;
+------------------+
| first_color      |
+------------------+
| ["red", "green"] |
+------------------+

mysql> SELECT data->'$.colors[1 to 1]' AS first_color FROM t1;
+-------------+
| ["green"]   |
+-------------+

mysql> SELECT data->'$.colors[1 to 2]' AS first_color FROM t1;
+-------------------+
| ["green", "blue"] |
+-------------------+

    使用通配符

    准备示例数据

    为了展示相关的示例，这里先给出一个更为复杂的示例数据：

    CREATE TABLE t1 (
    id INT PRIMARY KEY AUTO_INCREMENT,
    data JSON
);
-- truncate table t1;

INSERT INTO t1 (data) VALUES
('{
  "store": {
    "book": [
      {
        "category": "fiction",
        "title": "Harry Potter",
        "price": 29.99
      },
      {
        "category": "fiction",
        "title": "Lord of the Rings",
        "price": 49.99
      }
    ],
    "bicycle": {
      "color": "red",
      "price": 19.95
    }
  }
}');

    使用通配符查询所有book

    则可以使用如下的搜索表达式：$.store.book[*]：

    SELECT data->'$.store.book[*]' AS all_books 
FROM t1;

mysql> SELECT data->'$.store.book[*]' AS all_books
    -> FROM t1;
+--------------------------------------------------------------+
| all_books                                                    |
+--------------------------------------------------------------+
| [{"price": 29.99, "title"...}, {"price": 49.99, "title"...}] |
+--------------------------------------------------------------+

    这里比较容易错误的写成：$.store.book.*、$.store.book.[*]或$.store.book*。

    使用通配符递归查询

    列出所有书店中的书名

    依旧使用上述的数据，这里可以使用递归的通配符（**）查询结构中所有title属性的取值，则'$.store**.title'：

    SELECT data->'$.store**.title' AS all_books 
FROM t1;
+---------------------------------------+
| all_books                             |
+---------------------------------------+
| ["Harry Potter", "Lord of the Rings"] |
+---------------------------------------+

    当然，也可以改成直接从“根”处开始递归查找，即$**.title

    mysql> SELECT data->'$**.title' AS all_books  FROM t1;
+---------------------------------------+
| all_books                             |
+---------------------------------------+
| ["Harry Potter", "Lord of the Rings"] |
+---------------------------------------+

    类似的，我们还可以取出所有的价格：

    SELECT 
  data->'$.store**.price' AS book_prices 
FROM t1;
+-----------------------+
| book_prices           |
+-----------------------+
| [29.99, 49.99, 19.95] |
+-----------------------+

    小结

    熟悉 MySQL JSON Path Syntax 可以让开发者更加高效操作 JSON 数据。更多参考：

  • 在 Oracle 云上免费测试数据库

    ·

    admin

    Oracle 云（即Oracle Cloud Infrastructure，简称OCI ）的免费策略大概是所有云厂商中最为彻底与直接的。对于注册的账号，可以持续免费使用主要的云资源，包括虚拟主机（VM.Standard.E2.1.Micro）、数据库（1OCPU 16GB内存）等。

    相比于 AWS 的 一个月免费、GCP的 $300 代金券，OCI在免费策略上是最具诚意的云厂商。在使用方式上，也更具有诚意，不太因为使用超时、忘记关闭、规格选择错误等因素，而造成误收费，这些在AWS、GCP上都是很容易发生的。

    创建免费的数据库

    创建免费的 HeatWave MySQL 实例

    在创建数据库时，就可以选择“Always Free”选项，这时，在后续规格选择的时候，就不会误选成计费实例了。

    开启免费的 HeatWave 实例

    HeatWave是最近几年Oracle/MySQL最重要的发展方向，可以非常好的支持各种复杂与分析类的查询，很好的弥补了MySQL在分析能力上的短板。

    “Always Free” 也非常友好的支持了 HeatWave 相关的特性，可以让开发者非常好的体验HeatWave相关功能。

    创建实例账号

    创建数据库的管理员账号：

    查看免费实例

    在完成实例创建后，实例详情，可以看到“Always Free”标签：

    创建虚拟主机

    选择免费的虚拟主机规格

    这里需要注意，目前支持的免费规格，需要在分类“Virtual Machine->Specialty and previous generation”中选择：

    虚拟主机的基础选项

    查看实例状态

    在虚拟主机的实例列表页，可以查看该实例，并且看到免费标签“Always Free”：

  • MySQL 压测工具 Sysbench 生产数据大小预估

    ·

    admin

    Sysbench 是 MySQL 社交常用的压测工具，本文对 Sysbench 默认压测表大小进行分析，以帮助开发者了解该测试运行时的数据量大小。

    结论概述

    测试了 100万、500万数据，占用空间大小可以参考如下数据：

    sysbench 表大小预估单表记录表数量总空间预估
    场景 11,000,000102.3 GB
    场景 25,000,0001618.4 GB
    场景 310,000,0001636.32 GB

    生成数据命令

    这里使用如下的命令进行数据生成

    sysbench --mysql-host=... --mysql-db=sysbenchdb --db-driver=mysql \
         --mysql-user=... --mysql-password=...   \
         --table_size=1000000 --tables=10 prepare

    占用空间大小

    可以通过如下命令观察数据库中的表大小：

    MySQL [sysbenchdb]> show table status like '%sbtest1%'\G
*************************** 1. row ***************************
           Name: sbtest1
         Engine: InnoDB
        Version: 10
     Row_format: Dynamic
           Rows: 986400
 Avg_row_length: 228
    Data_length: 225132544
Max_data_length: 0
   Index_length: 16269312
      Data_free: 4194304
 Auto_increment: 1000001
    Create_time: 2025-03-01 05:57:45
    Update_time: 2025-03-01 05:57:45
     Check_time: NULL
      Collation: utf8mb4_0900_ai_ci
       Checksum: NULL
 Create_options:
        Comment:

    可以看到，单表约为 230 MB：

    (225132544+16269312)/1024/1024 ~ 230

    再通过数据库的物理文件观察大小：

    # ls -lah
total 2.4G
drwxr-x---  2 mysql mysql 4.0K Mar  1 14:04 .
drwxr-x--x 11 mysql mysql 4.0K Mar  1 14:02 ..
-rw-r-----  1 mysql mysql 240M Mar  1 14:04 sbtest10.ibd
-rw-r-----  1 mysql mysql 240M Mar  1 14:00 sbtest1.ibd
-rw-r-----  1 mysql mysql 240M Mar  1 14:01 sbtest2.ibd
-rw-r-----  1 mysql mysql 240M Mar  1 14:01 sbtest3.ibd
-rw-r-----  1 mysql mysql 240M Mar  1 14:02 sbtest4.ibd
-rw-r-----  1 mysql mysql 240M Mar  1 14:02 sbtest5.ibd
-rw-r-----  1 mysql mysql 240M Mar  1 14:03 sbtest6.ibd
-rw-r-----  1 mysql mysql 240M Mar  1 14:03 sbtest7.ibd
-rw-r-----  1 mysql mysql 240M Mar  1 14:03 sbtest8.ibd
-rw-r-----  1 mysql mysql 240M Mar  1 14:04 sbtest9.ibd

    可以看到，单表大小约为 240 MB，与上述计算的 230 MB 并无太大差距。

    数据生成时间统计

    这里使用的是一台 Amazon RDS xlarge 规格的实例，存储类型为io1，iops规格为3000，在该环境下，大约18秒完成一个表的初始化，算是比较快的速度，即每秒写入约为5.5万记录。

    关于“标准测试”

    在“云数据库 MySQL 的对比测试”中，选择了4c16g的规格，压测时使用了10个记录数为100万的表，即按上述计算，数据量大小约为2.3GB。即，所有的数据均可以缓存再内存当中。这也是为什么该测试是一个 CPU 密集型测试的主要原因。

    如果考虑将数据量调整为 500万，即单表约为1.15GB，总集16个表，那么数据量就可能达到 18.4 GB，那么这个测试就可能成为一个IO密集型的测试，准确的说，可能是一个读IO密集型的测试。

    sysbench 表大小预估单表记录表数量总空间预估
    场景 11,000,000102.3 GB
    场景 25,000,0001618.4 GB

    更多统计

    Sysbench 500万数据大小
    bash-5.1# ls -l
-rw-r----- 1 mysql mysql 1220542464 Mar 23 02:18 sbtest1.ibd
    mysql> show table status\G
*************************** 1. row ***************************
           Name: sbtest1
         Engine: InnoDB
        Version: 10
     Row_format: Dynamic
           Rows: 4938540
 Avg_row_length: 205
    Data_length: 1017118720
Max_data_length: 0
   Index_length: 0
      Data_free: 3145728
 Auto_increment: 5000001
    Create_time: 2025-03-23 02:17:49
    Update_time: 2025-03-23 02:17:49
     Check_time: NULL
      Collation: utf8mb4_0900_ai_ci
       Checksum: NULL
 Create_options:
        Comment:
1 row in set (0.01 sec)

    可以看到，实际占用空间：1.137GB ~ 1220542464/1024/1024。那么，依次数据，16个大小约为 18.19 GB。与上述数据并无太大差距。

    Sysbench 1千万数据大小

    如下数据统计了，1000万数据大小。可以看到，总占用磁盘空间：2.27GB = 2436890624/1024/1024/1024。

    bash-5.1# ls -l
-rw-r----- 1 mysql mysql 2436890624 Mar 23 02:42 sbtest1.ibd
    mysql> show table status\G
*************************** 1. row ***************************
           Name: sbtest1
         Engine: InnoDB
        Version: 10
     Row_format: Dynamic
           Rows: 9868349
 Avg_row_length: 220
    Data_length: 2179989504
Max_data_length: 0
   Index_length: 0
      Data_free: 5242880
 Auto_increment: 10000001
    Create_time: 2025-03-23 02:41:25
    Update_time: 2025-03-23 02:41:25
     Check_time: NULL
      Collation: utf8mb4_0900_ai_ci
       Checksum: NULL
 Create_options:
        Comment:
1 row in set (0.01 sec)

mysql> select count(1) from sbtest1;
+----------+
| count(1) |
+----------+
| 10000000 |
+----------+
1 row in set (2.74 sec)