We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A1:第一,表的那个分割数量怎么确定?默认每个分片大概是 8096,就是根据这个数量来的。这里面具体分的话其实是有两种分片的方式。第一种,分片如果说你表示自增并且是均匀的,我们直接取一个 min 跟 max,就你可以通过一个简单的数学计算确定这个分片数量。还有一种就是表的分片是不均匀的,比如说它的 ID 是个 UUID 这个时候我们就是通过 query 来查,就是通过数据库查询这个分片的边界。当然的话在社区也做了很多优化,就是说他会 lazy 地去查,因为一些 query 会比较耗时,支持一边查查询确定分片,一边读取已经确定的分片内容。
那第二个问题就是说把增量 merge 到全量的这个效率跟结束时间怎么保证。其实的话读一个全量数据一个 Snapshot chunk 的时候之间发生的那个 Binlog 我们是有过优化的。如果是说那个 Binlog 的位点没有前进,或者说前进的时候这张表没有做改变,那么我不会去读这个增量。那如果说有读,那个增量其实应该就很少一部分这些都是在内存里面做了一个 upsert 或者说叫 normalize 整个过程的话这个是非常快的,并且这个的话是可以并发做的。比如说我们大的作业我搞个一千个并发在这个地方读一千个并发,或者说上几百个并发在这个地方读,效率跟这个时间跟这个并发相关。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
A1:第一,表的那个分割数量怎么确定?默认每个分片大概是 8096,就是根据这个数量来的。这里面具体分的话其实是有两种分片的方式。第一种,分片如果说你表示自增并且是均匀的,我们直接取一个 min 跟 max,就你可以通过一个简单的数学计算确定这个分片数量。还有一种就是表的分片是不均匀的,比如说它的 ID 是个 UUID 这个时候我们就是通过 query 来查,就是通过数据库查询这个分片的边界。当然的话在社区也做了很多优化,就是说他会 lazy 地去查,因为一些 query 会比较耗时,支持一边查查询确定分片,一边读取已经确定的分片内容。
那第二个问题就是说把增量 merge 到全量的这个效率跟结束时间怎么保证。其实的话读一个全量数据一个 Snapshot chunk 的时候之间发生的那个 Binlog 我们是有过优化的。如果是说那个 Binlog 的位点没有前进,或者说前进的时候这张表没有做改变,那么我不会去读这个增量。那如果说有读,那个增量其实应该就很少一部分这些都是在内存里面做了一个 upsert 或者说叫 normalize 整个过程的话这个是非常快的,并且这个的话是可以并发做的。比如说我们大的作业我搞个一千个并发在这个地方读一千个并发,或者说上几百个并发在这个地方读,效率跟这个时间跟这个并发相关。
The text was updated successfully, but these errors were encountered: