超过 1 万条以上数据,请联系我们给你建索引,请报下 App ID。
抄送 @Proton
这个likes是默认和source都是user表,我刚刚查看了下,是有索引的
但是post没有,但是post只有1500条呢
appId是o49vknnavvgxfruo7gu7sxnm4hjdmzj4a6sgj4wa15opwmfr @Proton
尝试建立一些索引,然而提示“已经存在重复的数据,请勾选删除重复数据选项。“然而不能够删除数据呢
可以给一个比较慢的查询的例子么?
你需要到什么具体的样子?
用户, maxid,sinceid,limit,还有你那边消耗了多长时间
user 的objectId 是 5530393ae4b0840af8ddc03f,我不确定这个是否要登陆,如果需要,我晚点告诉你用户名和密码
maxid和sinceid都不需要,设置limit为10吧
这个是测试用户,内容比较少,但是查询用了2500ms 左右
如果用这个user 55292cb5e4b01e374f8aae55,查询下来的时间在8000ms左右,limit =1 时
发现这样查询你的 post.likes 数据量很大,query 中 include 进来开销也是很大的。能不能考虑把用到的 field 直接保存在 Post 中?
这个,post.likes有喜欢的用户呢,使用user的指针不是比直接放user的数据更好吗?这个不是很地道的用法?
还是说用AVRelation来建立这种关系?
这样用可以,只是会慢,因为直接 include 进来 API 还要多做很多查询。你可以试试看,不把 post.likes include 进来,速度就会降到一个可以接受的范围内。
如果额外的把需要的数据嵌进 post 里,就不用 include 了。这是一种常见的优化手段。
AVRelation 本质和 Pointer 的数组是一样的,只是有SDK提供的功能会比较容易用。
不include的确速度会快很多,但是感觉这个方法不地道用user的point在于,我以后想拓展user,很容易,不用考虑其他地方的使用,如果直接把部分属性放过去,以后想拓展还是需要考虑数据的升级
没有反馈了?那这种array 的include就不能用了?如果是,你们是否能够给一个官方的说明
你好,这种复杂的数据嵌套,自然会导致查询缓慢,或者取用起来比较复杂,是不鼓励使用的。请在一对多或者多对多的数据关联场景下,多使用 Pointer 或者 AVRelation 来实现。
请参考: https://blog.leancloud.cn/1723/
如果还有疑惑,请随时抛出来。
AVRelation 本质和 Pointer 的数组是一样的,只是有SDK提供的功能会比较容易用。你往上翻翻看之前的聊天记录呢
我还是不明白为啥这么慢Point的效率是O(1),array嵌套也最多是O(n)大家都是工程师,不要臆测,复杂的就一定会特别慢,讲逻辑和实践,对吧再次,我用的是pointer + array,这是很简单的组合使用,真的不复杂
LeanCloud 后端存储是基于 MongoDB 的,MongoDB 自身不提供跨表 join 的功能,include 功能实际上是分多个查询将数据取回的,所以 include 大量数据的时候实际上会发生很多次查询,速度自然会慢。即使是关系型数据库,跨表 join 对性能的影响也是很明显。
去范式化是常用的数据库优化手段,并不是很不地道的用法。
如果一定要实现类似的效果,也不想在数据库中放入冗余数据,可以考虑使用缓存。请看一下我们提供的 LeanCache。