1
LeeReamond 2021-11-18 22:33:28 +08:00
不太理解是什么使用场景,如果每次都在 main 分支上提交的话,似乎与传统的锁行锁表也区别不大,如果在分支上再开新分支的话,这在数据库有啥用呢
|
2
xingzhi 2021-11-19 07:09:54 +08:00
@LeeReamond 跟代码的开发同理,db 的新分支用于修改 scheme ,开发测试,没问题后再应用 deploy 到 prod (main)
|
3
LeeReamond 2021-11-19 08:23:56 +08:00
@xingzhi 个人看法,无论如何,开发中就算有一丁点可能性动到生产服务器的数据,我都觉得是一件很可怕的事情。。
|
4
Livid MOD OP @LeeReamond 是啊,正是因为改表这件事情到了 2021 年都那么恐怖,所以看起来有希望的解决方案才会有价值。
|
5
hlwjia 2021-11-20 10:53:56 +08:00 via iPhone
一直有在关注!
看过几个用例,超赞 |
6
catxo 2021-11-20 20:19:57 +08:00
这个我记得之前站里有看到国人创业的类型的产品
也不知道是不是竞品 哈哈哈哈 |
7
lockelee 2021-11-23 14:21:48 +08:00
@catxo you mean bytebase. bytebase 管理 schema 变更,但是不 host db instance
|
8
catxo 2021-11-24 09:21:37 +08:00
|
9
clf 2021-11-24 10:46:15 +08:00
现在最痛苦的是后端不仅仅是 mysql 一个数据库需要分支,得所有用到的数据库一起切分支才可以
|
12
tianzhou 2021-12-07 01:02:44 +08:00 2
我们两家彼此的默契在于,我们看到的问题是一样,切入点都是开发工程师在开发应用时和数据库打交道的开发者体验。
有意思的是,我之前在 Google Cloud SQL 团队,做的是基于 Vanila 的 MySQL hosting 服务,而 PlanetScale 基于的是 Vitess 则用于 youtube ,也是当时除我们之外 Google 部署最大的 MySQL 集群。 不过 PlanetScale 是从中间件层解,而我们则是从工具层解,解法不一样。PlanetScale 的方法更加硬核一些,我们的则更贴近当下的用户。当然还有一种更硬核的做法,就是从引擎层解,估计马上也会有团队这样做的。 我个人也试用了一下 PlanetScale, 还读了一遍他的文档,是一个做的很好的产品。尤其加上和 Vercel 的配合,是有机会带来一个新的 V(ercel)P(lanetScale) 技术栈。 PlanetScale 和 Bytebase 要解的问题是有交叉,但目前的侧重点还不一样,不过未来发展久了,我们彼此都有去卷对方的可能性😅 |