 |
halovApr 2, 2024
1
分页吧
|
 |
2
这配置 这数据量 不随便玩儿吗
|
 |
wqhuiApr 2, 2024
3
稳定运行 10 年。。。设计跑个三五年差不多了，到时候自然会有新的方法或者新的需求要重写，另外你这数据量感觉用不着这么好的服务器
|
 |
qW7bo2FbzbC0Apr 2, 2024
4
要考虑断点续传以及分页的稳定性，最好加个自增 id ？每次取用时加上 id > lastTimeGotID
|
 |
yngzijApr 2, 2024
5
1W 条直接查了，mongo 可以都直接插入，mysql 分次插入就好了。
|
 |
6
一定要做分页，并且一定要限制最大返回数量，不然后续你麻烦，对方你麻烦。
当然，你也可以全部，后面等着刷 KPI ，毕竟老板喜欢员工忙忙的样子，大概是可以治愈他的焦虑罢。 |
 |
7
@crazyweeds 哈哈，明白了，是这样的😁
|
|
8
@qW7bo2FbzbC0 有的，把这个利用上
|
|
9
@admol 还有其他的业务
|
 |
sakilascottApr 2, 2024
10
10 年你都不在这个公司了，即便你在这个公司，也可能不负责这个业务了。
规划 2-3 年足够了 |
|
11
@sakilascott 是这样的，就是想考虑全面些
|
 |
meeopApr 2, 2024
12
随便,现在一个网页都数百兆了,全查回来 2 年以内都没问题
正规做法当然是提供一个支持分页查询接口,一点一点同步 |
|
13
好吧，认真回答你下
看你的描述，你应该是想问的是：每天去全量同步一次（前一天）增量的所有数据，还是分页去同步（前一天）增量的数据，也就是全量还是分页去同步新增的数据。 建议是： 1 、查询接口一定要限制一个数据范围，所以要分页 2 、要支持指定时间、主键 ID 等范围同步指定数据（失败后人工重试等异常场景） 3 、同步结果是否有通知？同步状态、同步数据条数等 |
|
14
@admol #13 收到，感谢大神，同步结果没有通知，我这边只负责提供数据，剩下的就是业务方自己保证了
|
 |
midsoloApr 2, 2024
15
补充一下：
1 、提供出去的接口一定要限制数据范围，并且这个范围不能太大 2 、下游请求时得带上时间戳，要在你设定的阈值范围内才可拉取 3 、把提供出去的数据封装成一个批次，让下游分批次拉取 4 、记录好下游拉取数据的日志，避免后续扯皮 |
 |
KarteApr 2, 2024
16
如果数据是写入之后无修改, 可以记录上次其获取到的数据 id, 然后将这个 id 之后的数据再发送给他. 有效减少查全库导致性能的下降.
如果修改不大建议最好做个 snapshot. 定时生成一个 snap 节点, 然后用户通过提交上次 snap 节点获悉所有数据更新状态. |
 |
rm0gang0rfApr 2, 2024
17
我这 一天 3000-5000, 2 核 4g.....运行 3 年了...
|
 |
1018jiApr 2, 2024
18
感觉还不如拉文件省事
|
2
Select Language