同样都是为了进行横向扩展
同样都是对数据进行分片
同样都需要引入一个节点来管理数据分片状况
同样都有数据 Balance
那么二者的区别是什么呢? 二者的优势和劣势分别是什么呢
ShardNothing 架构似乎对没有 CockroachDB 中 Multi-Raft 旨在要解决的心跳流量过大的问题, 毕竟不同 Shard 之间是无感知的
感谢回答哈
思考了一下 Multi-Raft 好像能节省节点数量, 同一节点即做复制保证可用性, 又做分片来实现扩展性
ShardNothing 想实现三副本两分片的话, 不算用来存储分片信息的节点话需要 2*3 共 6 个节点
而 Multi-Raft 只用 4 节点
但是这样并没有节省存储空间(不过对于物理机部署的话可以认为是增加了资源利用率), 反而增加了集群拓扑的复杂性, 运维成本感觉会很高
感觉sharednothing更像是一种思想（各节点相互独立， 每个更新请求都由集群中的单个节点来满足）。multi-raft，（按我的理解是在单个raft group基础上引入分片并解决分片带来的一些问题），可以看作是sharednothing的一种实现。
我自己本身对架构上的一些东西不算了解，以前也没了解过所谓的shared nothing，一起来探讨一下这个问题。
首先shared nothing的实现是有很多种的，如果从每个物理节点独立，不共享资源，通过网络通信的角度来看的话，tinykv的实现方式无疑也是shared nothing的一种。
multi-raft的实现也可以是很多种的，之所以给你带来这种差异感，我认为是粒度的问题。传统的分片应该是一个分片占据着一组主从服务器？数据分布方式有很多，range形式，hash形式，还有随机形式（写的时候随机写，读的时候去每个节点要数据然后汇总）。目前，由于参考spanner的原因，几个multi-raft的实现粒度都是region
具体到tinykv中以region为粒度管理数据的方式，每个region是一段连续的数据，特点在于，一个节点（我通常认为是一个raftstore），可以管理很多个并不连续，空间上无关的数据段（region），像你说的心跳流量的问题确实可能存在，因为单节点会需要支撑多个raft组。
首先可以带来一个比较明显的优势就是粒度小了，我可以将热点region调度开，散到各个节点上（虽然这样仍然避免不了热点问题，这是range形式的通病吧）。region之间也是无感知的，当然raftstore是需要一些信息的。然后region split和region merge的形式，也是能很方便地，由管理节点去感知到去调度到其他节点，调度和可扩展性是有优势的，加机器尤其方便，等scheduler把region调过来就好了。
传统分片，如果是基于hash的形式，扩展上是比较难敲定的，一致性哈希我并不太了解；range的形式，怎么切分数据，调度到新节点上，同时保证服务可用，也是需要考量的，因为shared内数据连续的话，数据均衡就只能在相邻的节点做，有限制；随机的形式我在clickhouse里见过（当然也可以不），对于OLTP数据库，能比较快速定位少量数据在那些地方才是比较重要的，随机的形式需要每个节点上读数据，读取扇出是相当大的。
这部分内容，建议去看google的spanner论文会有更好的了解，为什么这么设计和这么设计的优势应该会有更细致的研究，找个时间我也需要去读一下，tikv是spanner的一个开源实现吧，貌似还有几个同类的数据库。
在单一raftstore，从region的角度往物理存储看（虽然region并不感知），其实又有点像共享存储，因为都存在rocksdb上。
shared nothing这种架构上的划分其实是蛮笼统的，真实的实现是很复杂的，划分架构只是一种思考上的导向，关键还是为什么这么设计，这么设计的优势与缺点，如果上面的回答有什么错误，feel free to point out，我自己也在学习中，肯定会有不少理解上错误的地方
按我的理解完全是两码事；
shared nothing只是一种架构上的设计，强调无限水平扩展能力和MPP能力（参考gp），对立sqlserver和Oracle RAC（shared everything 和 shared disk）；
而multi-raft则是多副本分布式一致性的一种实现方式，要比较的话也是multi-paxos等分布式协议；
赞同，两者不是一个层面的东西
个人理解，raft关注的是节点扩展时的一致性，ShareNothing关注的是节点扩展时的资源分配方案（计算、存储），它们在横向拓展时在存储的部分采用了类似的方案
那像 tinykv 这种使用了 multi-raft 还分 region 的数据库属于什么架构呢? 比较困惑他的这种实现方式
其实想了一下, 后面想了一下, 确实 tinykv 这种也属于 ShardNothing, 但是他的 shard 维度变成了列族维度(表维度), 这点与普通的 ShardNothing 有较大的普通. 这使得数据的调度更加细粒度, 当然也带来较多的问题. 为了解决这些问题, 就引入了 MultiRaft 来作为他的一致性算法.
不过在我看来细粒度管理数据在我看来好像没有太高的收益, 反而是一种负担, 从运维测角度来看每个节点的的状态都是独特的, 如果出现了问题将比较难排查, 尤其是节点数量众多的情况下. (好像 tidb 的运维确实比较令人头痛
对于哈希分片实现方式的话, 一致性 hash+ 搬迁时双写应该是比较常见的.
感谢回答, 这里的话感觉确实应该去看下 Spanner 的论文了.
顺便更好奇跨节点的联表操作是如何完成的…
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。