Hello Ivan, Thanks for the feedback, see my comments inline:
чт, 22 окт. 2020 г. в 17:59, Ivan Daschinsky <ivanda...@gmail.com>: > Hi! > Alexey, your proposal looks great. Can I ask you some questions? > 1. Is nodes, that take part of metastorage replication group (raft > candidates and leader) are expected to also bear cache data and participate > in cache transactions? > As for me, it seems quite dangerous to mix roles. For example, heavy > load from users can cause long GC pauses on leader of replication group and > therefore failure, new leader election, etc. > I think both ways should be possible. The set of nodes that hold metastorage should be defined declaratively in runtime, as well as the set of nodes holding table data. Thus, by default, they will be mixed which will significantly simplify cluster setup and usability, but when needed, this should be easily adjusted in runtime by the cluster administrator. > 2. If previous statement is true, other question arises. If one of > candidates or leader fails, how will a insufficient node will be chosen > from regular nodes to form full ensemble? Random one? > Similarly - by default, a 'best' node will be chosen from the available ones, but the administrator can override this. > 3. Do you think, that this metastorage implementation can be pluggable? it > can be implemented on top of etcd, for example. I think the metastorage abstraction must be clearly separated so it is possible to change the implementation. Moreover, I was thinking that we may use etcd to speed up the development of other system components while we are working on our own protocol implementation. However, I do not think we should expose it as a pluggable public API. If we want to support etcd as a metastorage - let's do this as a concrete configuration option, a first-class citizen of the system rather than an SPI implementation with a rigid interface. WDYT?
