标签: tidb

  • 从40秒到11毫秒:TiDB Cloud一次SQL深潜优化实战

    从40秒到11毫秒:TiDB Cloud一次SQL深潜优化实战

    此文参加了 TiDB 社区第四届专栏征文大赛,获得二等奖。感谢 TiDB,感谢 Gemini,感谢跟我一起做 Awesome Comment 的某同学。

    有空的同学麻烦帮我投个票:https://asktug.com/t/topic/1046966 搜索“深潜”就能找到给我投票的地方

    在数据库应用中,慢SQL是常见的性能瓶颈。本文将详细记录一次针对TiDB Cloud v7.5.2环境中复杂评论查询的SQL优化过程,如何通过分析执行计划、添加索引、改写SQL(使用EXISTSUNION)等手段,将一个40多秒的查询逐步优化到11毫秒,希望能为读者提供有价值的实战参考。

    不知道什么时候,TiDB Cloud 升级到 v7.5.2,于是我们的评论应用 RU 消耗开始起飞,达到以往月份的 3 倍左右。没办法,只好拖着病榻之躯来 Debug。还好 Gemini 2.5 Pro 给力,很快我就完成了这次优化,记录在这篇博客里。另外,这篇博客也是 Gemini 2.5 Pro 帮我写的,AI 之力,恐怖如斯 😱😱。

    (更多…)
  • 记一次不成功的数据库搬家

    记一次不成功的数据库搬家

    我这个博客始建于 2011 年,当时我从 ZOL 离职,表达欲旺盛的我,希望找个地方继续写博客,于是就买了台集成 WordPress 的虚拟主机,开始写技术博客。除博客之外,我也利用这个平台学习 Linux、nginx、PHP、MySQL 等服务器端软件的使用,从中受益良多。

    后来忘记哪年,从虚拟主机换到 VPS,终于可以拥有自己全权控制的服务器了。当时很兴奋,觉得自己应该在后端取得更深入的发展,于是开始研究 PHP + WordPress 开发,准备基于 WordPress 做一些尝试,模版、插件、WooCommerce,感觉能做的东西很多。

    不过坦率地说,WordPress 历史太久,历史包袱太多,代码架构不好,二次开发很难受,属于能用但是不好用的状态,所以我的学习进度一直不快。另一方面,我的职业机会也不少,所以真正投入在这个方向的时间并不多,拖着拖着就黄了。

    不过我一直在坚持更新博客,后来我发现数据库也不小,每次导出 + 备份都需要不少时间。正巧当时我了解到 TiDB,还恰逢 TiDB Cloud 初次发布,感觉似乎可以把数据库放在云端,这样就一下解决了自动扩容和自动备份这两个需求(其实都没需要)。于是就把数据库迁移过去。

    最初使用 TiDB Cloud 时,因为刚刚参加完 TiDB Hackathon,账户上有免费赠送的额度,所以没感觉有什么问题。但是从去年开始,我发现每个月都要付给 TiDB 几美金费用。我研究了一下 TiDB Cloud 的计费体系,主要分成两大项:

    1. 容量。免费 5G,我的用量远远不够。
    2. 计算用量,RU。不太确定怎么计算,但是我用超甚多,所以费用都产生自这里。

    我首先排除 Slow SQL 的问题。WordPress 这点做得挺好,毕竟是世界上用户数量最大的软件,我也没有用很多来源不明的插件,所以并没有 Slow SQL。

    接下来通过 Metrics 面板查阅,看不太出来用量和时间有什么关系,偶尔我的博客访问量大的时候,RU 会涨一点点,但其实影响不大。

    然后我试图增加 CDN,给页面增加缓存时间等,意图通过降低访问压力降低数据库消耗,但也都没什么实际作用。

    然后我尝试移除一些插件,比如 Jetpack 系列,避免来自 WordPress 官方的请求消耗掉我的额度,也失败了。

    最后我只好诉诸代码,研究来研究去,得到结论:

    1. 我这个博客时间很久,收录也不错,多半已经处于各种垃圾营销的大列表里面
    2. 于是会有很多自动化的机器人来抓取、注册、灌垃圾评论等等
    3. 这些机器人大部分不走网页,没法被缓存,而且每次都会大量读写 wp_options
    4. 不知道具体原因,不过对于 TiDB Cloud 来说,这种对小表的高频请求会消耗大量的 RU
    5. 在不改变架构的前提下,这个问题无法解决

    于是,在九月份被刷掉 $15 之后,我终于忍不了了,利用国庆,把数据库迁回本地。随便刷吧,nnd。下一步,肯定是要重新建站了,把 WordPress 当成纯 C MS,前端用现代化架构重新构建。正好也督促自己把 Awesome Comment 的 SaaS 做起来。

    最后强调一下,这个跟 TiDB Cloud 没关系,纯粹因为项目不合适。我现在有好几个服务都在蹭他们家的免费流量,一点问题没有,非常顺利。

  • 聊两句广州开源人聚会(2023-10-21)

    聊两句广州开源人聚会(2023-10-21)

    我不记得怎么关注的 @tison,印象里好像是有人在聊开源,我看到觉得不错就关注了。他上周六号召了一场广州开源人聚会,我一看 TiDB(PingCAP)赞助了场地,路线熟悉,这个周六也没什么安排,就报名参加了。

    这场活动由 开源社TiDB 赞助。我和两家都有些交集。TiDB 自不用说;去年 Google 主办的 Code for better _ Hackathon 后,我们几个获奖选手都应邀去 开源社开源年会 做了演讲。不过说来惭愧,我对开源的贡献不多,虽然我的代码大都放在 GitHub 上面,并且使用 MIT 协议,但实际上没有推广、没有测试、也没有文档,所以真心算不上什么贡献。

    所以我去参加活动的时候也很忐忑,很怕大家一盘道,原来我是作品做少、用户最少的一个。不过很明显是过虑了:这是场蛮典型的程序员聚会,大家大多默默走进房间,默默坐下,默默拿出手机开始刷。只有几个人在高谈阔论,如此社牛很明显是主办方,果然,其中一人便主持人 @tison。

    @tison 分享了他从事开源的经历。真好呀,年轻又厉害。他的早期经历跟春哥有点像,也是大学期间从 Perl 开始。毕业后经历过大厂,但更多的还是在开源商业公司做开发,目前在 StreamNative。他参与了很多项目,现在竟然还在给 Answer 作 mentor,虽然年纪很轻,但真的非常厉害。

    我对他的发言印象最深的是:

    1. 开源项目很多都是少数几个核心骨干做很多工作,其他贡献者可能付出寥寥
    2. 创始者的风格会对开源项目带来很大影响,比如 Perl,就很像一门宗教
    3. 他接手开源项目,或者做 mentor,起手式是文档、CI、测试。我觉得这点很好,值得我学习。

    接下来,另外两位开源商业项目的从业者上台,分享他们的开源经历。这两位就比较让我感到亲切了,除去为公司工作写开源项目外,他们分享的也是给文档挑 typo 这种经历,哈哈。

    接下来聊聊开源软件的商业化。我对这种商业模式很熟悉,毕竟当年我在 OpenResty Inc. 工作过,而我们正是开源商业公司。我们的工作模式是:

    1. 维护开源软件
    2. 售卖软件服务

    开源软件可以很容易地接触到尽可能多的用户,培养他们的使用习惯,在他们的使用过程中捕获错误、改进产品。找到机会成为事实上的行业标准,然后整个行业就离不开这个软件,最典型的例子就是 Linux。

    作为软件的核心开发者,创造软件的公司自然可以享有更高的话语权;也更能说服此软件的使用者:如果你们需要进一步的服务,找我们准没错。这就相当于把传统企业用在市场上的费用,拿来支持开源软件开发,所以商业上也说得通。

    以前我只知道国外有 WordPress、Ghost、RedHat,这次见到国内的开源商业公司也都在茁壮成长,感觉很高兴。

    不过呢,这些公司(包括 TiDB)的目标领域有些过分单一:基础设施。数据库、不同种类的数据库、网关(API6),等,都是基础设施。原因我猜很简单,因为基础设施最可能拿到稳定的收入。这些软件,即使使用开源版本,都有很高的配置和使用门槛,更不要说后期维护、升级。如果是普通 2c 软件、SaaS 软件开源,可能更多的是拿去套壳做二次贩售吧……

    总之吧,我觉得,前途仍然是光明的、充满期望的,希望中国开源软件越做越好。

    感谢各位赞助商,开源社、TiDB,主办方 @tison,希望下次我能找到足够多的东西分享给大家。

  • 记一次 TiDB Cloud Serverless 超额导致的博客超时故障

    记一次 TiDB Cloud Serverless 超额导致的博客超时故障

    今天早上起来,习惯性地刷新博客统计页面,发现 502。这可不妙,好不容易我坚持到现在终于有点流量,于是赶紧想办法修复。

    博客基础架构

    我的博客架构大体是:

    • 小主机,本地跑 php8.2-fpm 和 nginx
    • 使用 nginx 代理提供服务
    • 数据库使用 TiDB Cloud Serverless
    • 外面套上腾讯云 CDN

    仔细一看,错误页面的 Nginx 是 1.18.0,正是我服务器上的版本,貌似是本地上游 php-fpm 的问题,不是腾讯云 CDN 的问题。ssh 登录服务器,基本正常,验证了判断。查看错误日志,tail /var/log/nginx/blog-error.log,大量的 upstream 错误。top 查看进程负载,服务器本身很闲,但是 5 个 php-fpm 进程虽然不忙,但是都跑了很久。

    重启治百病,先升级系统

    以前没见过这种情况,本着遇事不决先重启的思路,我想先升级重启试试。于是 apt update & apt upgrade 升级系统,接着 reboot。停了一会儿打开网页还是不行。

    登录服务器 service --status-all 查看服务,貌似都正常。查看博客服务器的配置文件,也没写错。输入 service nginx restartservice php8.2-fpm restart 重启服务,还是不行。

    然后 Google PHP8.2、php-fpm、502 等关键词,限制最近一周,看看会不会是新版本引入了新 bug。没有找到结果,应该也不是。

    会不会是 TiDB Cloud 没钱了?

    看过前面博客:💪 WordPress 使用 TiDB Cloud 替换 MySQL 💪 的同学可能知道,我不久前把博客从本地 MySQL 迁移到了 TiDB Cloud Serverless。会不会是欠费停机了?我觉得不应该呀,免费额度 5GB,我的博客数据库前几天看过才区区 300+MB,不会突然就突破限制。

    不过我还是打开了 TiDB Cloud,姑且看一眼吧。没成想,果然是 TiDB Cloud 额度用完了,不过不是容量问题,而是 RU(Request Units,请求单位,TiDB 的某个计费单位)超限。TiDB Serverless Tier 每个月有 50M 的免费 RU 额度,我当时已经用掉 59.6M,所以被停止服务了。

    不过这里有个问题:我的 php-fpm 整个被卡死了,因为 TiDB Cloud 没有及时断开连接,导致我的 PHP 一直在等待数据库响应,但实际上数据库是不会响应的,相当于我的 PHP 线程都在守活寡。直到超时,才得到解脱。这样一来,我的服务器也无法响应任何其它 PHP 请求,包括 phpinfo() 等未使用 TiDB Cloud,甚至那些只有简单 PHP 功能的请求。

    按理说我超额,他们应该拒绝连接,让我看到数据库连接失败的错误,而不是卡住我直到超时。这样一来,

    1. 至少我的服务器还可以响应别的 PHP 请求
    2. 有了数据库连接失败的错误提示,我也能尽快找到问题根源。

    上调预算

    TiDB 还是蛮大方的,不需要预付款、预充值,只要将来按用量结账即可。于是我把预算上调到 $5/月,然后,重启了服务器。结果,又发生了第二个意外。

    我以为上调预算之后,连接、请求就能恢复,结果没有,还是白屏。而且,从 TiDB Cloud 的统计页面来看,在上调预算之后,数据库经历了一大波密集的请求:

    直到约 30 分钟之后,我的博客才渐渐缓过来,我也才有机会写这篇复盘文章。

    我不太确定这波请求是哪里产生的,是我的博客还是 TiDB 的网关,这个有待进一步研究学习。

    请教 TiDB 大佬

    我带着问题在推上请教了大 V 能哥。他告诉我,按照目前的产品策略,超额用户也可以以很低的频率访问数据库,因为有人是占了太多空间,需要有机会让他删数据。

    那这就是彼之蜜糖,吾之砒霜了。我的情况是存储量少(不到400mB),但是请求数高(我看的时候为 60M),所以除非调高预算,我不存在继续使用的可能性。但是他们又不会拒绝我的服务,于是就变成了我服务器上的 php-fpm 被卡死在连接数据库阶段,无法响应任何 PHP 请求。

    我把这个问题反馈给了 TiDB 的社区工作人员,期待他们能解决这个问题。

    下一步:解决方案

    这次故障的修复过程对我来说还是挺新鲜的,也还算顺利。给我在系统设计领域提供了新的经验,所以我拿出来分享给大家。

    不过话说回来,从白嫖的角度来看,迁移到 TiDB Cloud Serverless Tier 上似乎不是很明智。按照 WordPress Jetpack 的统计,我现在每月访问量大约是 7k UV,10k PV,如果这个级别就要花钱,而且动辄几刀的话,那我可能还是迁回去用本地数据库好一些。

    当然,解决方案还是有的。

    首先,Serverless Tier 可以创建多个节点,每个账号的最初的 5 个节点都有 5GB 空间+50M RUs/M 的免费用量。所以我可以写一个自动化脚本,每周将数据同步到下一个节点,然后自动修改链接类到新的节点。嘿嘿嘿,不知道这样的作品能不能参加 Hackathon 😂😂

    其次,好好查查 slow sql,找找优化点。减少每次请求产生的 RU 消耗。

    再次,升级 CDN 配置。我目前的网页都是 30d 缓存,按理说不应该有很多消耗才对。后台只有我一个人在用,不应该有很多数据库访问。我怀疑还是这块儿没搞好。应该有不小的优化空间。

    总结

    TiDB 正在举办新一年的 Hackathon,我也厚着脸皮去要了 $100 的赞助,白嫖大业应该还能再坚持一段时间。如果你也对数据库应用开发感兴趣,我强烈推荐你也来参加这次 Hackathon:【TiDB Future App Hackathon 2023 】TiDB 首届全球黑客马拉松,开发者的狂欢夏日盛会!快来一起 Coding 吧!这次 Hackathon 针对应用层,基本上使用 TiDB Cloud Serverless 就可以,适合各个领域的开发者参加。

    无论如何,感谢 TiDB 提供给我们免费、好用的数据库产品,也推荐大家使用 TiDB Cloud Serverless。如果大家有什么意见建议,欢迎留言讨论。

  • 💪 WordPress 使用 TiDB Cloud 替换 MySQL 💪

    💪 WordPress 使用 TiDB Cloud 替换 MySQL 💪

    白嫖使我快乐。一直白嫖,一直快乐,😊。感谢 TiDB,感谢 TiDB Cloud,你们让我的博客内容更丰富多彩。

    前言

    我这个博客从 2011 年开始写,如今已经 12 年。最早,从 ZOL 离职后,我需要换个新平台写博客;另一方面,我也想学习 Linux、PHP、MySQL,这些原本不熟悉的技术,于是选择了 WordPress。这么多年来,服务器从共享主机搬迁到 VPS,又升级到云主机;PHP 从 5.5、5.6 升级到 7,又升级到 8;Apache 被换成 Nginx;唯独数据库没有变化,基本一套老框架沿用至今。

    我前阵子发现:因为编码问题,无法在标题里或正文里插入表情符号。于是升级数据库也被提上日程。刚好我一直关注的 TiDB 开始提供云数据库服务,采用 Serverless 模式,Free Tier 有 5GB 可以用,足够我写博客。于是我就准备趁此机会切换到 TiDB Cloud 上。

    注册 TiDB Cloud

    打开 tidbcloud.com 注册即可。

    TiDB Cloud 很大方,不需要绑卡,不需要繁琐的操作,直接第三方登录就可以使用。Serverless(Free Tier)只支持 AWS 机房,可选的位置也不多,因为我 ECS 买在美西,所以就把数据库也买在美西,这样速度应该会快一些。

    每个账号可以创建若五个 Serverless 节点,有免费额度,超过限制用量则开始收费。只要稍稍点两下,就建好了,体验很流畅,这里不再赘述。接下来开始使用。

    连接 TiDB Cloud

    数据库准备就绪之后,我们可以进入数据库详情页。点击右上角的“Connect”按钮,即可打开连接信息窗口。

    TiDB 贴心的准备了各种客户端、各种平台的连接方式,对于我这种数据库准小白来说非常有帮助。第一次使用,需要点击右下角的“Reset password”按钮生成数据库密码,生成后,这个按钮会变成复制密码。记得要妥善保存密码,因为我们不能再次查看或者获取。

    这里发现一个设计缺陷:点击 Reset password 按钮没有确认过程,所以我的数据库密码直接就被改掉了……这种破坏性操作还是应该多一个确认比较好,回头反馈给 TiDB 的工作人员。

    导入数据

    TiDB Cloud 只支持导入 CSV 文件,比较难用。可能因为我数据库知识储备不足,我甚至想象不出 CSV 该怎么支持表结构😅。不过没关系,我有 JetBrains 全家桶,命令行操作也还凑合,所以直接从本地跑就行。

    首先在服务器上执行 mysqldump -u USER -p --database BLOG_DB > backup.sql 把整个博客数据库包含数据结构都导出到 backup.sql 文件里。

    打开 sql 文件,把数据库的编码全部改成 utf8mb4 或者 utf8mb4_unicode_ci,这样就可以支持表情符号咯 🎉🎉。

    打开 DataGrip,按照上一节介绍建立数据库连接,右键,选择“SQL Scripts”,然后执行刚才的 SQL,等一会儿,数据即可完成导入。当然,实际过程肯定没有这么顺利,不过云数据库嘛,有问题就直接整个节点干掉再重建就好。不留脏数据。

    WordPress 连接

    TiDB Cloud 要求必须使用 TLS 安全连接,所以我们需要修改 wp-config.php

    /** WordPress数据库的名称 */
    define('DB_NAME', 'blog');
    
    /** MySQL数据库用户名 */
    define('DB_USER', '用户名');
    
    /** MySQL数据库密码 */
    define('DB_PASSWORD', '密码');
    
    /** MySQL主机 */
    define('DB_HOST', '主机域名:端口');
    
    /** 使用 SSL 连接 */
    define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);
    

    因为我的服务器是 Ubuntu 22.04 系统,证书放在默认位置,可以自动加载。如果你使用其它系统,可能需要修改一下证书路径。

    解决 SQL_CALC_FOUND_ROWS 导致翻页丢失的问题

    完成上述操作,打开博客,500 😱。查看 error.log,原来是不支持 SQL_CALC_FOUND_ROWS 导致报错。我并不知道这个东西是干嘛用的,丢到 Google 里搜索,找到这个 issue,原来 WordPress 的 SQL 要使用这个函数,但是 TiDB 并不支持。

    解决方案是在数据库里执行 SET GLOBAL tidb_enable_noop_functions=1。之后 WordPress 不会再报错,但是相应的,翻页功能也没有了,因为 WordPress 无法统计博文数量。

    继续搜索。看起来 SQL_CALC_FOUND_ROWS 并不是什么好东西,不知道为什么 WordPress 至今都不愿意把它移除。还好,WP 留有开关,我们可以关闭这个函数的使用。我自己创建了一个 WP 小插件,用来给博客加广告、调整页面,所以我就在里面添加函数,关掉 SQL_CALC_FOUND_ROWS

    if ( ! function_exists( 'wpartisan_set_no_found_rows' ) ) :
      function wpartisan_set_no_found_rows( \WP_Query $wp_query ) {
        $wp_query->set( 'no_found_rows', true );
      }
    endif;
    add_filter( 'pre_get_posts', 'wpartisan_set_no_found_rows', 10, 1 );
    
    if ( ! function_exists( 'wpartisan_set_found_posts' ) ) :
      function wpartisan_set_found_posts( $clauses, \WP_Query $wp_query ) {
        // Don't proceed if it's a singular page.
        if ( $wp_query->is_singular()  ) {
          return $clauses;
        }
    
        global $wpdb;
    
        // Check if they're set.
        $where = isset( $clauses[ 'where' ] ) ? $clauses[ 'where' ] : '';
        $join = isset( $clauses[ 'join' ] ) ? $clauses[ 'join' ] : '';
        $distinct = isset( $clauses[ 'distinct' ] ) ? $clauses[ 'distinct' ] : '';
    
        // Construct and run the query. Set the result as the 'found_posts'
        // param on the main query we want to run.
        $wp_query->found_posts = $wpdb->get_var( "SELECT $distinct COUNT(*) FROM {$wpdb->posts} $join WHERE 1=1 $where" );
    
        // Work out how many posts per page there should be.
        $posts_per_page = ( ! empty( $wp_query->query_vars['posts_per_page'] ) ? absint( $wp_query->query_vars['posts_per_page'] ) : absint( get_option( 'posts_per_page' ) ) );
    
        // Set the max_num_pages.
        $wp_query->max_num_pages = ceil( $wp_query->found_posts / $posts_per_page );
    
        // Return the $clauses so the main query can run.
        return $clauses;
      }
    endif;
    add_filter( 'posts_clauses', 'wpartisan_set_found_posts', 10, 2 );

    调整完毕,翻页功能恢复正常。

    使用体验小结

    Serverless 讲究一个即用即起,平时是休眠状态,有人用才会启动。所以最好避免冷启动,否则第一个用的人要等很长时间,体验很差。作为博客,更简单的方式是配置 CDN,给首页外的页面添加长期缓存,就能改善大部分用户的体验。

    实际上我目前使用了一个多月,并没有冷启动的感觉。我的博客日均几百的访问量,感觉相当可以。另外一个实例,作为 NoCoDB 的数据库,因为访问量很小,所以冷启动感觉很明显。

    其它方面,速度和效率都不比本地数据库差,以后我再搞产品,应该都不会自己数据库了,嘿嘿嘿。


    后记

    我已经两次报名参加 TiDB Hackathon,第一次止步外围筛选第二次虽然进入决赛圈,但是因为对云数据库不了解,挑战开发 NoCoDB+TiDB Cloud 失败,铩羽而归。

    但是借用群里同学的说法:人生没有白走的路,每一步,都算数。虽然 Hackathon 没能获得好成绩,但是我获得了更多关于 TiDB Cloud 的知识,于是这次可以顺利完成迁移。

    目前博客网站使用体验良好,速度不比之前使用本地数据库慢。前两天,我发现 TiDB Cloud 开放了 Data Service,提供 HTTP Endpoint,这表示着他们向 DaaS(Database as a Service)更近一步,也意味着我们在 Edge Function 里使用 TiDB Cloud 成为可能。那么接下来,我打算好好利用一下这个薅羊毛机会,把几个 Side Project 的数据端放在 TiDB Cloud 上,跟 Supabase 比一比,看哪个更好用,更适合新项目、小公司从零到一。

    到时候也会写成更多文章,或许做成视频,跟大家分享。

    如果各位读者老爷对数据库、云开发、薅羊毛感兴趣,欢迎留言讨论,可提出问题,亦可指点一二,均非常欢迎。

  • TiDB Hackathon 2022 参赛小记

    TiDB Hackathon 2022 参赛小记

    今年的 TiDB Hackathon 来的比去年早一些,赶在 1024 前举行。去年我参加 TiDB Hackathon 2021 之后,感觉非常好:组织给力、参赛选手水平高、技术分享氛围好,能学到很多东西。于是今年毫不犹豫,再次报名参加。

    我其实一直想搞个移植类的项目,把某个能用但不够好用的项目移植到 TiDB 上,得奖倒在其次,主要是为了将来自己用或者给别人用。但是我也知道,这类作品的技术含量有限,除非做得很好或者很有特点,否则多半连决赛都很难入围。于是我韬光养晦,卧底在群里,等待抱大腿的机会。

    然而,赛前创意脑爆会,CTO 黄东旭说了一些跟我很接近的想法——当然,也可能是我听错了,我当时一边搬砖一边开着直播,注意力不集中;后来我又听了一遍,没能找到印象中的那几点。

    本来想抱大腿,但是经历上次思否 Hackathon 之后,必须得说,哥们儿飘了,哥们儿觉得自己行了,哥们儿觉得自己也是个角儿了。于是我甩掉了前面已经蹭进去的队伍,拉大旗谋虎皮,邀请赋闲在家的竹子一起,组了自己的队伍,准备携余威再下一城。

    正所谓黄粱美梦,终有一醒。很快教训就来了。

    0. 开场 brief

    由黄东旭(TiDB CTO + CoFounder)演讲。

    TiDB 的诞生

    • 三个后端基建程序员,厌倦了分库分表的枯燥生活,决定造福大家。
    • 一腔热血+盲目自信,开始动手
    • Why TiDB?(自吹的部分省略,哈哈

    TiDB 的未来

    • From OLTP to HTAP
    • From SQL to API
    • From TiDB to TiDB-as-a-Service
    • From Infrastructure to Applications
    • From Code to You

    TiDB 近景展示

    基于云的高速动态 Scale 能力,把 TiDB 从数据库变成 end-point,让用户对底层无感,应该是未来的发展方向。

    1. 密集 coding

    开幕式结束后,各支队伍开始 coding。今年规定比较严,必须在入围决赛后才能写代码,杜绝有人拿一年的大项目 hackathon 上改个字体就参赛的行为。

    我们团队其实有一些前期的调研和摸索,比如我的 NocoDB + TiDB 实例很早就部署了,然后队伍的日常管理也在上面。不过事后来看,我们还是太轻敌了,各方面的。

    1. 行级权限控制(Row Level Security / Row Based ACL)

    首先我要确定 NocoDB 怎么支持行级权限控制,因为 idea 脑爆会上东旭有提到,所以得重视起来(面向 CTO 编程)。结果比较令人失望,NocoDB 并不直接支持类似 LeanCloud 那种 row based ACL。

    用一些比较复杂的方式似乎能够实现。比如:

    1. 生成主表
    2. 为用户创建不同的视图
    3. 用户通过特定表单提交信息

    总之这个方向进展不顺利。

    2. Vercel Template

    我们计划做的第二个东西(也是脑爆会上提到的),是 Vercel Template,即可以让用户在 Vercel 上一键部署实例的东西。

    临近中午,竹子找我说可能做不了,于是我赶紧去看。Vercel 本身主要提供静态内容托管,从 GitHub 拉纯前端仓库然后部署。后端服务只提供 serverless functions,支持文件路由映射。next.js 和 nuxt.js 不知道是主动还是被动,都提供了类似的方案去适配。

    NocoDB 前端是基于 Vue3+nuxt.js 打造的,所以并不难搞。困难的是服务端。我们面临两个选择:

    1. 手动把 API map 到文件路由(比如 /api/user => /api/user.get.js
    2. 直接用入口 js 作为 serverless function

    竹子开始尝试了方案(1),觉得可能超出 hackathon 的时间要求。我也觉得方案(1)不太靠谱,于是开始尝试方案(2)。由于依赖的问题、Vercel 的问题,我们一直折腾到凌晨 00:30,最终推翻了方案(2)……由于 serverless functions 的无状态特性,没有优化过的程序完全没法跑。

    3. SaaS

    最后我们只剩下来原本计划中 Nice to have 的功能:SaaS 平台。这个部分我们本来只想在 PPT 里提一嘴,算是对未来的展望,希望评委老师感兴趣。并没打算做,毕竟 hackathon 里俩人做 SaaS,怎么看也不靠谱,但是现在,这竟然是我们唯一可能的交付物了,真的是……

    当然完整交付是不可能的,我们的目标就是让评委相信我们能做出这样的东西来。

    其实说白了,这垂死挣扎,就是高考前,语文/英语老师说:“你们作文不会写,就把前面阅读理解打乱顺序抄一遍,不要空着!”,那个意思。

    2. 小转机

    没想到真的有转机,虽然不大。

    竹子 mock 了几个 API,仿真了在 Vercel 上使用 Template 部署应用的过程,录成视频,准备在 demo 的时候播。我一看,咦?反正都是模拟 API,我那儿(测试服)有现成的啊。这样一想,我整理出一个似乎还可以的想法:

    1. 部署 nocodb-gui
    2. 使用我的测试服作为 server API
    3. 完成演示

    这样可以演示一些效果,而且很容易带出来我们接下来要做的:基于 NocoDB+TiDB 的 SaaS。哎,昨天真是被 Vercel 部署消耗掉太多体力脑力了,竟然没想到这么直接的解法。

    3. 答辩

    其实事后想想,上面也称不上什么转机,顶多就算是把阅读题抄了一遍,只是稍微打乱了一下顺序。

    答辩时评委问我:你们这个有什么优势呢?有什么是你们做了,但别人难以做到的?扪心自问,其实没有。我甚至没来得及做 Vercel Integration。如果我们事先准备好,让用户能够通过 Vercel Integration 得到独立的 NocoDB Backend API 与 独立的 TiDB 实例,也许算是个完整的产品,但目前这个完成度,也就比交白卷强那么一丢丢。

    哎,打回原形,再次寄望于来年吧。

    4. 赛事组织点评

    TiDB Hackathon 的组织一如既往的给力。首先参赛过程非常舒服,纪念品诚意满满。CTO 的开场 brief 让人动力十足。后勤保障非常给力:包三餐、零食饮料下午茶管够;有些同学从外地来,想在公司打地铺,组委会也尽力帮忙满足。组委会还准备了一些活动,让大家能放松心情,加强交流,可惜我一直在跟 Vercel 搏斗,没空参加。哥们儿好歹也在 Just Dance 有 MegaDancer 的表现。

    哦对,美中不足,空调不够给力,只有风没有制冷。猜测是大厦周末不供冷,不能全怪主办方。

    这次我还动员了一些同学来参赛,不知道他们战果如何,希望比我好。相信他们也会收获颇丰。

    5. 其它收获和感想

    1. NocoDB 输入体验不行,但其它体验挺好,值得长期使用
    2. TiDB 的确挺快,developer tier 足够我现在的用量,准备继续白嫖下去
    3. 学会了 Vercel 生态的知识
      • deploy button
      • template
      • integration
      • deploy API
      • cli
    4. 新概念:HTAP

    总结

    今年的项目方向多半还是对的。降低用户门槛,提升产品可用性,应该是受主办方欢迎的方向。可惜我们选择的执行方式不够得当,可以帮用户薅羊毛,但要能薅到羊毛才行,目前这个方案,其实还有一段路要走。

    考虑到厂里年底要突击,姆伊用药助手 0.2 版本还没开始动工,以及其它一些开发需求,我估计会把这个项目放一放,先用着我的 NocoDB + TiDB 实例。等待时机,再动手折腾折腾。

    感谢 TiDB,举办这么棒的 Hackathon;感谢组委会,尽心尽力尽责,把活动办得这么好;感谢我老婆,给我放假让我在外面肝了两天代码;感谢竹子,跟我一起辛辛苦苦折腾半天,最后铩羽恶而归。生活还要继续,下周继续努力,大家一起加油。

  • 关于我作为前端报名 TiDB Hackthon 2021 然后被毫无悬念地淘汰这档事

    关于我作为前端报名 TiDB Hackthon 2021 然后被毫无悬念地淘汰这档事

    2021 年年底,我偶然在推上看到 TiDB 举办 Hackthon 的消息。当时好像已经得知被金山办公优化的消息,所以准备给自己找点事情做,就报名参赛了。

    作为一名全栈偏前端工程师,我对数据库的了解停留在基础安装、配置、优化上面。不太了解数据库生态,也不清楚各大厂牌之间的区别。我只在 teahour.fm 上听过 PingCap CTO 黄东旭的访谈,对他们只有一些粗浅的了解:

    1. TiDB 由豌豆荚内部项目孵化而来
    2. 他们试图给 KV 数据库增加类似 MySQL 的 API,让熟悉 MySQL 的用户能够无痛迁移到 TiDB 上
    3. KV 数据库天生便于拆分和分布式,更能适应未来的应用场景
    4. TiDB 是开源的,PingCap 提供基于 TiDB 的 SaaS 服务

    Hackthon

    2018年年底,我去北京参加了思否组织的 WeGeek 小程序 Hackthon。去之前,我以为 Hackthon 就是现场组队、现场立项,大家比拼脑洞、比拼协作能力。去了之后才知道,很多队伍都是长期合作的小团队,项目可能也做了很久,现场更多是准备答辩。

    结果我们当然是陪跑。

    这次的情况也类似。赛道提前一个月就公布了,大部分选题多半也是同期开始准备的。前面也说过,我本来就对数据库所知了了,也不熟悉 TiDB,自己没法想出好的选题,只能将希望寄托在被其他队伍招募上。

    没成想这是个数据库 Hackthon,对前端的需求约等于零,于是我无队可投……求组队求到最后,我准备不行我就随便整个 Ghost+TiDB 或者 IndexedDB+TiDB 之类的项目随便搞一下,不要交白卷就行。还好最后 TiDB 送温暖,派了个后端来扶贫,勉强帮我凑齐了队伍,确定了选题。

    参赛

    TiDB 有个周边产品,叫 Chaos Mesh,可以进行混沌测试,测试服务器集群或者容器在各种干扰下会有怎么样的表现。功能不错但体验稍逊,我们就想改进它。

    第一个想法是做游戏,我们设计了多个游戏方案,最终又都推翻了,因为 Chaos 其实有很多限制:

    1. 操作有失败的可能,不是每次都能成功
    2. 操作有很多,需要不同的表现方式
    3. 操作过程很长,多则几十分钟到数小时

    眼瞅着比赛日一天天逼近,最终我们决定,先改进表单和拓扑图,毕竟纯前端用户界面类的开发,应该不会太难,有机会出成绩。

    这是我第一次真正写 React 应用,还是花了不少时间学习和摸索。但是最难的点不在这里,而是,项目里这块实现的不算太好,还有些 Bug……这对我来说就有点超纲了,如果是 Vue+某个我熟悉的组件库,多半也能搞定;但是技术选型我也不熟悉、产品逻辑我也不清楚,确实做不完。

    最终只勉强修了一个 GitHub 上的 issue,算没有交白卷吧。

    比赛日

    比赛日当天,我作为本组代表,到广州分赛区参与答辩。

    TiDB Hackthon 的现场组织非常好:工作人员友善热情积极,现场环境舒适宜人,座位宽敞舒服,网速快,还供应三餐、下午茶和宵夜。签到之后就有纪念品,还能抽奖。纪念品里有我最看重的键帽,感觉组织者真的懂。

    答辩进行得很顺利,因为项目做的不咋地,所以要说的东西也不多,5分钟时间比较宽松地把做过的工作都介绍了一下,然后坐到一边等待结果。

    事实证明我想多了。这次 Hackthon 预留了一个多月的准备时间,更有很多参赛选手从上一届就开始筹划这次的项目。所以从理念、从设计、从实施,都远胜我们。

    于是我们毫无悬念在预赛阶段就被淘汰了。

    总结

    虽然从前期报名到后面开始写代码的过程都很不顺利;立的项也被各路高手从各种方面碾压。但我必须得说,TiDB Hackthon 的组织能力真得很强,参赛选手水平真高,奖品也真给力,非常值得一来。而且仔细看 决赛项目,全都不明觉厉,如果能准备得更充分一些,相信能学到很多东西。

    于是,今年我有两个打算:

    1. chaos-mesh 作为学习 react+typescript 的入门项目,争取在春节前把这次立项的功能完成,代码合并入主干(或具备合并的条件)。今年每个季度都能贡献一些代码。
    2. 慢慢积累对 TiDB 的使用经验,争取在年底前能形成一个可行又有价值的提案,然后参加 TiDB Hackthon 2022。