【leanCould开发爬坑教程(开篇)】集结了我所有遇到的坑


theme: cyanosis
highlight: agate

前言

  1. 我会把我遇到所有的坑列举处理,很多是无法避免的,属于平台无法避免的
  2. 看完我踩的坑,再决定要不要 入坑
  3. 本人算是 leanCould的深度用户,目前三个应用在线上运营

坑一 【选择的节点不一样,差距很大】

在你选择创建账户的时候,创建 应用的时候,会有 华东节点 和 华北节点。表面上差距不大,只是部署的地方不一样

那么你就太天真了,一定要看这里
请一定选择华北的节点,因为他支持的功能更多,而这是官网里面没有地方告诉你的

我也是遇到了线上问题,然后又看不到线上的日志的时候,去发工单询问才知道这个事情的

华北节点与华东节点的区别

如下是我在提工单的时候,官方给的回复:

华北节点我们底层接入的服务商是 UCloud,华东是腾讯云,在国内不同地区的访问速度基本没有差别
目前华北节点的用户更多,功能更完善一些,有一些功能在华东还不支持,例如,华东节点暂不支持在控制台自助绑定独立 IP、不支持日志表与离线分析、混合推送中不支持 FCM 推送等。

虽然华东节点功能少了很多,但是在收费这一块,确实一模一样的,商业版价格一模一样,不分你是哪个节点

华东节点的应用如何迁移呢

关于这一点,我也咨询了,总结来看:没有一键迁移的功能。迁移非常复杂,我也直接引用官方给的答复吧

应用如何切换节点?

已有的应用不支持一键切换节点,「应用转让」功能也仅限在相同节点转让。如果一定要切换节点,可以通过数据导入导出的方式实现。
需要注意:

  • 只有数据存储服务的结构化数据支持导出与导入。
  • 即时通信服务的会话记录与聊天记录无法导出。
  • 云引擎需要重新部署。
  • 短信签名与模板需要重新审核。
  • 推送厂商设置、开发证书上传、敏感词库上传等等应用维度的设置信息都需要重新配置。
  • 还有一个重要的问题是,数据导入到华北节点新创建的应用,APP ID 、APP Key 是变了的,还需要在客户端修改初始化代码
  • 数据导入导出的文档 [https://leancloud.cn/docs/dashboard_guide.html#hash-238129571]

看了如上的 回复,这不是相当于,自己把数据 全部导出,再导入,并且在 华北的节点上再配置一遍,还要改代码

对于线上应用而言,基本不太可能迁移,成本太高,风险太大

坑二 【导入导出数据的坑】

前面一个坑,提到了 导入导出。其实没有用过的人,一眼看上去感觉很不错,但是,作为深度用户的我来跟你说说 这里面的坑

数据全部导出再导入

当你在数据导出的时候,选择数据全部导出,包含schema 和所有数据,导出之后,会有很多的 json 文件,一个json文件就是一个 Class 的所有数据

再选择一个个导入,注意:此处无法一次性全部导入

注意点:

  • 导入数据之后,原来表中的 注释都会没有了
  • 导入数据之后,原来表中设置的 默认值也没有了,这意味着 后面的 产生的数据 可能就会没有默认值,导致代码判断有问题
  • 导入数据之后,File表中的 链接是导不进去的

也就是说 schema的里面的信息都失效了,不是导出的时候都选择了导出 Schema了吗?为啥还是不能同步Schema信息

数据全部导出再导入,数据量有限制

导入文件必须小于30M,但其实我就 3-4M,就被限制了,无法导入

那么这还怎么数据迁移

单独导出Schema的数据

单独导出Schema的数据的时候,一个表导出 4个相关文件,会有一个 使用指南,但是的话,也有坑

指南指定的两种导入方式

  • 直接导入带 _all.json 结尾的文件即可
  • 将其余三个 .json 文件分别导入即可

注意:一定要自己自己指定 导入的表名,否则表名就叫:xx_all,但是这个指南没有说
另外:无法识别表名这个问题,在全量导入那边不会有这问题,两边不一致

坑三 【不支持事务】

Leancould 本身是基于 MongooDB的,而MongoDB从4.0 开始早就支持事务了,但是目前Leancould是不支持的

具体什么时候支持,只是有规划而已,没有具体的时候

事务这个场景太普遍了,无时无刻都在用到,不支持就是个大坑

坑三 【不支持联表查询】

场景

表User,存的是用户数据,里面有一个 性别的字段 sex,是一个外健,链接另外一个表 Sex(name:男或女)(该例子只是方便大家理解)
此时想查询 所有 男生的有多少个

官方有一个 matchesKeyInQuery 相关用法,看文章应该是 可以实现的

但是,但是,当你的数据超过 1000 条,那么数据就不对,查询有问题,结果压根不对

我就遇到了这个问题,批量审核的时候,很多数据漏了,太影响了

我也咨询了官方

这样来说的话,「字段冗余」确实也不是一个好方案。目前来看确实没有好的方法,可能要考虑一些变通的办法。比如在 innerQuery 中通过时间戳来限制内部的查询数量,类似这样

{ actionAuth: 1, createdAt: { $gt: "", $lt: "" }}

按时间进行分段查询,当然这个过程处理起来也相当繁琐。

总结

此篇文章中列出的坑都是无法容忍的,会对 你的业务有很大的影响,请有正准备入坑的同学,认真思考,它是否适合你
有问题随时交流

© 版权声明
THE END
喜欢就支持一下吧
点赞10 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片

    暂无评论内容