• 扩散性百万咸面包
    2020-09-09
    思考题： 大部分分布式系统都有这么一个存储元数据的东西，比如TiDB的PD，HBase里的ZK，k8s的etcd。也可以把他们看成存储小数据的KV存储系统，一般通过Raft或者Paxos来维持共识，就跟普通分布式系统一样

    作者回复: 是的：）

    共 2 条评论
    18
  • 真名不叫黄金
    2020-08-22
    猜测一下，如果是TiDB的话，将元数据存在PD，而PD本身又可部署为多节点高可用的，不过数据最终是落在etcd的，PD只是交互节点。 Spanner如何做的就不太好猜测，但是Spanner也有PD这个角色，也许是差不多的。

    作者回复: 是的，基本正确，点赞。另外，TiDB还做了一些优化，详细的内容在第7讲有说明

    共 4 条评论
    9
  • 扩散性百万咸面包
    2020-08-22
    Hash 分片写性能出众，但查询性能差，Range 则相反。 没懂这一句话，文章中哪里有详细阐释为什么Hash分片的写性能更好呢？为什么Range的写性能就不行呢？

    作者回复: Hash分片会将数据比较均匀的分散在集群的各个节点上，所以性能更好，而Range的数据分布是根据编码规则（静态）或者主键（动态）的，不以追求平均分布为目标，所以性能会差些。这个性能差异问题，我在第17讲还会再说明。

    共 2 条评论
    8
  • 开心哥
    2020-08-21
    元数据搞个etcd存起来如何？

    作者回复: 嗯，说得对，这是方案之一，点赞

    
    4
  • 旅途
    2020-09-24
    多数采用半同步复制，平衡可靠性和性能。这意味着，所有分片的主副本必须运行在 Set 的主节点上。 老师,这句话没懂,为什么使用半同步复制,所有分片的主福本都运行在set主节点呢

    作者回复: 这是由单体数据库的主从复制机制决定的，无论哪种策略，都是以节点为单位的，从节点不能提供确保数据一致性的服务。

    
    3
  • 游弋云端
    2020-08-21
    元数据集中存储，特别是能用全内存性能最好，但可靠性不足，一般做HA;或者元数据可以做一致性Hash来分片打散，个人认为Range不适合元数据，变化了数据位置不好计算。

    作者回复: Hash分片确实是无主架构常采用的一种方式，不过CockroachDB的Range分片也是一个不错的思路

    
    1
  • 楚翔style
    2020-10-16
    hash环那里,A(0-3)表示只能放3个hash值吗?这个区间可以随意设置吗?

    作者回复: 这里只是举例，数量要由实现的具体算法控制

    
    
  • 扩散性百万咸面包
    2020-09-20
    老师，PGXC的这种模式，如果按Set来分片的话，那么为什么不能像Multi Raft Group一样，主Set副本分布在不同节点呢？这样就可以把读写压力分摊在不同节点上了。
    共 1 条评论
    4
  • 南国
    2020-08-22
    分片数据存在分布式文件系统里，元数据像bigtable一样用一个高可靠的协调中心存，比如Zookeeper，在合并和分裂的时候修改元数据，客户端缓存需要的元数据，修改的时候通知即可
    
    4
  • yang
    2021-04-25
    hash--分片，基于hash槽的设计几乎没讲--，比如redis-cluster--事实上这种在大规模应用中反而会更多。
    
    3