type
status
date
slug
summary
tags
category
icon
password
作为一个经常利用Bytebase公号软文来给自己的知识体系打补丁的“九漏鱼” 🐶🤣，自己此前看到sqlchat发布文章时，就感叹原来今时IT行业的新鲜玩意儿并不是我们这一代人突然开了天眼洞察出的市场需求，反而大部分是对既往同类目的产品的一次次改造、迭代、升级，只不过现代人更擅长新造名词罢了。而对于ChatGPT这一当红辣子鸡，原本自己更多地觉得这是对信息检索的革新，但文章中提及的“这是交互方式从GUI演化到Chat”的观点确实很inspiring。毕竟，想想吃到从CLI到GUI变化红利的Microsoft和Apple，就更对这样交互方式变革背后的商业机会肃然起敬了。
在前不久参加Bytebase新手村任务时，自己就对Chat SQL的自动写SQL功能进行了试用，感叹这简直就是对SQL女工的革命性解放。于是，在新产品SQL Chat发布的第一时间，自己就进行了试用。趁此次新一期产品体验官活动，回头来再次使用对比并整理成文。
以下是本文目录，可根据实际需求食用：
1 sqlchat.ai基本情况2 作为用户，感知到的AHA moment2.1 响应快2.2 chat+execute的丝滑2.3 change data等写入操作不直接提供执行3 作为好奇宝宝，探索发现的功能实现方式3.1 聊天机器人3.2 创建数据库连接3.3 查询4 作为找茬专业户，需要指出的问题4.1 等待服务器响应时间频繁过长4.2 新建数据库连接时4.3 数据库连接密钥存储问题4.4 连接数据库后，无法展示ER图4.5 单次对话组中，chat接口返回内容没有联系上文（和此前的结果联动）5 总结About Author
1 sqlchat.ai基本情况
- URL：https://www.sqlchat.ai/，大概是03-20创建的
- 部署在Vercel，服务器位于US；刚发布时大中华局域网可直接访问（而且挂梯子的话机器人返回速度会慢3x），但目前好像还是得挂梯子才能访问；
- 若使用上述云服务，OPENAI API费用由Bytebase承担；若本地部署，需要用自己的API KEY，API费用由自己承担；
- chat接口调用的是OPENAI的GPT-3.5-Turbo模型；
（跑个题，考虑到这个团队的未来前景，我是不是该先去把其他相关地址注册下，以方便以后好狠狠敲一笔🙊）
2 作为用户，感知到的AHA moment
2.1 响应快
如果说ChatGPT目前在用户体验方面有痛点的话，那这个痛点就是其返回内容的速度了。所以一开始和机器人聊天的时候，原本已经做好了响应速度会很慢的心理预期，但实际使用时却发现这响应速度简直惊人啊！试了很多次后发现content download前的waiting for server response时间基本都在1s内，网络不差、chat内容没那么那么复杂的时候可以在500ms内，这速度相较于ChatGPT简直逆天了。
当然，由于现在需要梯子，如果代理选择了香港的线路而不是美国的话，前面的等待速度就会长很多。
2.2 chat+execute的丝滑
在连好自己放在AWS RDS的employees数据库后，进行了chat👉query操作。由于此前已经尝试过Bytebase里面的Chat SQL功能，所以对于目前的SQL自动生成功能并没有那么惊讶（dbq，我飘了 😈）。但这里的交互明显比之前嵌在Bytebase里的ChatGPT+NotionAI合并式的交互方式要自然得多，就整个一丝滑流畅。
2.3 change data等写入操作不直接提供执行
考虑到Bytebase主产品在change data时审核的谨慎，自己在SQL Chat斗胆试了试drop table和update命令，发现会返回SQL语句，但不提供执行按钮。这么细节的考虑对一个MVP产品而言，也太难能可贵了吧！
3 作为好奇宝宝，探索发现的功能实现方式
3.1 聊天机器人
- 用户输入文本，点击【发送】图标或输入回车后，调用chat接口；
- chat接口的入参中的message是用户在此次对话中所有历史内容；
- chat接口返回内容即是调用openai api + 基于规则生成的内容；
3.2 创建数据库连接
- 点击save前，都是前端；
- 点击save后，先调用test接口；如果成功，则调用db接口；如果成功，则返回页面；
- test接口：
- 请求方式POST，请求地址https://www.sqlchat.ai/api/connection/test
- 请求入参：用户输入的数据库连接信息
- 返回结果：（状态码）
- db接口：
- 请求方式POST，请求地址https://www.sqlchat.ai/api/connection/db
- 请求入参：用户输入的数据库连接信息
- 返回结果：数据库名称
3.3 查询
- 用户输入文本，点击【发送】图标或输入回车后，先调用db_schema接口
- 再用db_schema接口返回的数据库schema信息/建表语句作为入参，调用chat接口
- 再用chat接口返回的sql语句作为入参，调用execute接口
step1：调用db_schema接口
- db_schema接口：
- 请求方式：POST；请求URL：https://www.sqlchat.ai/api/connection/db_schema
- 请求入参是数据库连接信息
- 返回结果：该数据库的建表语句
step2：db_schema返回后，调chat接口。
- chat接口：
- 请求方式：POST；请求URL：https://www.sqlchat.ai/api/chat
- 请求入参：一个消息队列，包括db_schema的返回结果、用户的输入内容
- 返回结果：SQL语句
step3：点击【执行】按钮后，调用execute接口。
- execute接口：
- 请求方式：POST；请求地址：https://www.sqlchat.ai/api/connection/execute。
- 请求入参：用户此前输入的数据库连接信息+chat接口返回的SQL语句。
- 返回结果：sql执行结果
4 作为找茬专业户，需要指出的问题
4.1 等待服务器响应时间频繁过长
SQL Chat刚发布时，明显的是飞一般的速度，能体会到的延迟大多在1s内。但这次自己再用时，明显感觉响应速度降下来了。除了考虑到自己使用梯子带来延迟这一外部因素外，请求发送后，waiting for server response时间超过5s的情况也频频发生。
由于db_schema接口并没有调用OPENAI的API，不受其模型变慢的影响，所以应该还是SQL Chat这边负载均衡的问题。如果我之后真的要常用SQL Chat的话，这个速度确实会有点劝退。
🤣当然，也可能是我这边网络的问题，没有控制变量测过。
4.2 新建数据库连接时
缺少连接名称、密码隐藏、测试连接按钮等上一代SQL Client已经培养出的用户习惯的功能（不过这些都是细节小问题，不影响产品主干功能）。
看了下test接口和db接口的设计，目前都有tittle字段，猜测对应数据库连接名称。但目前为空，不知道之后前端会不会用上。
在SQL Chat刚发布时，本来还在吐槽数据库连接缺少SSL，但没想到这次再用时已经补上了这块儿功能，这迭代速度真心绝绝子👏👏👏。
但参考自己在使用SQLtron时只需勾选SSL、无需自己准备CA证书的使用经历，这里可能、也许、maybe做到SQL Chat的云服务中？（对CA证书的生成细节不太了解，不知道该想法是不是真的可行的）
4.3 数据库连接密钥存储问题
db_schema请求的入参，私钥完全明文，说明之前建立数据库连接时密钥也是明文存储的。虽然数据库连接信息是存储在浏览器缓存里的、网络连接时也可以通过SSL来做通信的加密，但感觉这里password在转存到浏览器前确实应该做一次加密，毕竟不是直接传用户填入的POST内容，至少不应该能通过F12直接看到password明文吧？（当然，实现是否可行、具体怎么实现我也不知道🐶）
尽管github上有写数据库连接存在本地浏览器、仅会把schema信息传给OpenAI（而不是table中一行行的实际数据）、我也并不在意schema信息传给OpenAI（毕竟我用的是MySQL和PGSQL的官方样例库），但密钥明文这一点确实让人有点不安心。
4.4 连接数据库后，无法展示ER图
无法展示ER图，用户连接后无法知道数据库结构，因此目前还无法替代dbeaver等工具；
4.5 单次对话组中，chat接口返回内容没有联系上文（和此前的结果联动）
前往发现chat接口的入参包括此次对话中的历史输入，但自动生成的SQL并没有把对话上下文考虑在内。这个要求可能有点吹毛求疵了，但从使用ChatGPT和NotionAI的经验来看，它们确实做了同一次对话、同一页联系上下文。
上述这些问题和发现的其他问题，自己之后也会找时间提到github issue的bug report和enhancement里。
5 总结
SQL Chat整体给我的惊喜远大过使用细节上的小缺憾，真的应得上产品发布推介文所述的是GUI到Chat的交互变革，希望早日能冲上Dev Tools 2.0 Portfolio！
About Author
- a 2-year data platform PM at an indigenous tier-2 public cloud provider, focusing on privacy-preserving computing, data security, data opening, system security, product process optimization, product QA test, user experience, & etc.
- have experiences in data mining projects, but no SWE/SRE/DBA work background
- have experiences in using ubuntu, docker, aws rds, google bigquery, snowflake, databricks, fivetran, dbt, chatgpt, notion ai, web & data security products
- familiar with sql, python, gitlab, jira, dbeaver
- name:rachel, gender:female, age:27, contact:[email protected]
- 作者:Rachel Law
- 链接:https://rachellaw.xyz/2023/SQLChat
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。