Open xinzhuxiansheng opened 1 year ago
A1：第一，表的那个分割数量怎么确定？默认每个分片大概是 8096，就是根据这个数量来的。这里面具体分的话其实是有两种分片的方式。第一种，分片如果说你表示自增并且是均匀的，我们直接取一个 min 跟 max，就你可以通过一个简单的数学计算确定这个分片数量。还有一种就是表的分片是不均匀的，比如说它的 ID 是个 UUID 这个时候我们就是通过 query 来查，就是通过数据库查询这个分片的边界。当然的话在社区也做了很多优化，就是说他会 lazy 地去查，因为一些 query 会比较耗时，支持一边查查询确定分片，一边读取已经确定的分片内容。
那第二个问题就是说把增量 merge 到全量的这个效率跟结束时间怎么保证。其实的话读一个全量数据一个 Snapshot chunk 的时候之间发生的那个 Binlog 我们是有过优化的。如果是说那个 Binlog 的位点没有前进，或者说前进的时候这张表没有做改变，那么我不会去读这个增量。那如果说有读，那个增量其实应该就很少一部分这些都是在内存里面做了一个 upsert 或者说叫 normalize 整个过程的话这个是非常快的，并且这个的话是可以并发做的。比如说我们大的作业我搞个一千个并发在这个地方读一千个并发，或者说上几百个并发在这个地方读，效率跟这个时间跟这个并发相关。
A1：第一，表的那个分割数量怎么确定？默认每个分片大概是 8096，就是根据这个数量来的。这里面具体分的话其实是有两种分片的方式。第一种，分片如果说你表示自增并且是均匀的，我们直接取一个 min 跟 max，就你可以通过一个简单的数学计算确定这个分片数量。还有一种就是表的分片是不均匀的，比如说它的 ID 是个 UUID 这个时候我们就是通过 query 来查，就是通过数据库查询这个分片的边界。当然的话在社区也做了很多优化，就是说他会 lazy 地去查，因为一些 query 会比较耗时，支持一边查查询确定分片，一边读取已经确定的分片内容。
那第二个问题就是说把增量 merge 到全量的这个效率跟结束时间怎么保证。其实的话读一个全量数据一个 Snapshot chunk 的时候之间发生的那个 Binlog 我们是有过优化的。如果是说那个 Binlog 的位点没有前进，或者说前进的时候这张表没有做改变，那么我不会去读这个增量。那如果说有读，那个增量其实应该就很少一部分这些都是在内存里面做了一个 upsert 或者说叫 normalize 整个过程的话这个是非常快的，并且这个的话是可以并发做的。比如说我们大的作业我搞个一千个并发在这个地方读一千个并发，或者说上几百个并发在这个地方读，效率跟这个时间跟这个并发相关。