如何设计一个无限可扩展的元数据服务?

在分布式文件系统里面,元数据的可扩展性是衡量一个分布式文件系统的重要指标。如果让你来设计,你会如何设计?inode 和 dentry 如何存储?

【特别说明】此问题属于「Boss 有请·电商专场」,提问者正在招聘高薪岗位,如果你使用真实身份发布回答,BOSS 将可直接查看你的在线简历,并选择是否与你主动开聊。

回答·65
最热
最新
  • 这是一个无目标的技术控提出的问题。所有的设计都是为特定目标而做的优化和平衡。 xml 原生就是元数据,python 中的原类都是可扩展的。列出服务的目标才可能有最合适的设计。 这种靠猜面试人员的目标位的问题,已经偏离了面试的初衷。
  • 难点是有非常多子项信息的目录,要做一种分布式 map 数据结构来保存,每个 kv 保存子项的名称和 ino 的映射,关键是这个对应一个目录的分布数据结构要有这样的特点:1 分成多个 chunk, 这样能写入 chunk 存储; 2 能惰性装载,需要哪部分就只装载哪部分,这样才能支持“无线的”数据结构的计算。实际上有些时候需要通过元数据保存大对象或文件的空间分配,也得用这样的方法。 解了上面的难题,元数据就映射为 chunk 了,chunk 存储的伸缩性并不难。 但是需要高超一些的软件开发能力,还是有特别多的难题,例如分布事务,一致性冲突,读写流水线。
  • 先不说理想的无限是不可能的,因为钱不是无限的。 实际文件块存储相对不是问题, 问题实质就是要解决 超大规模 key - value 存储和查询的问题,  那么这里我偷个懒,找一个支持大规模水平扩展的 MPP 数据库来支持这个, 可以自动 sharding, 方便添加节点就好了嘛,这个解决主要矛盾。 TiDB 可以出场了,知乎 Tidb 集群存储超过 1PB, 存元数据还有啥不够的呢。    如果你还觉得不够,可以多几个 tidb 集群,元数据再分个区,上面加一层代理集群来裁决应该去哪个集群查或者存
  • 如果一万个人回答这个问题,BOSS 没有付出任何代价,到获得的是最佳的解决方案!老板就是老板!
  • 要做到无限扩展,需要支持两个核心功能: 1. 可平滑扩展的哈希函数,负责为 key 生成索引 2. 可扩展父级索引的能力。 举个例子: 当前 hash 函数生成 32 位索引,假如要扩容,需要 hash 函数能支持扩容到 64 位索引。然后对已有数据做 rehash。索引表也从原来的 2 级升级为 4 级,每一级用 64 位中的 16 位来查该级的索引表。找到下一级索引表位置。 只要支持这两个功能,就可以做到无限扩展。无非就是给索引和索引表扩容嘛!
  • 首先,无限可扩展的元数据是不存在的。 如果要实现题目中的问题,有二种方法可以实现: 一:非对称式构架:这种架构把元数据独立出来,部署于高性能的硬件节点,好处在于便于针对性优化。应对方案一是升级硬件配置,比如多加点 SSD,升级 CPU 内存。 二:对称式构架:元数据的功能模块打散,分布到每一台节点,每一台硬件节点既是数据节点也是元数据节点,当系统扩展时,两者同步扩展。 但这二种都不可能实现无限扩展元数据。
  • 1、用 hash 值做一个虚拟的圆环 2、取服务节点多个 hash 值确定在 hash 环上形成多个虚拟节点机制 3、当我们增加或减少元数据服务节点时,只是操作圆环上的虚拟节点 能力有限,不知可否达到无限扩展需求,还需前辈多多指点批评
  • 我最近就写了一个按业务数据关系与动态属性设计的业务项目微服务系统,可以说除了工具类 API,我做项目不会再写通常的后端业务代码,只做设计与文档。如果要说具体是如何实现的方法,理论与实现方法太多,在些也说不清楚。如果一定要几句话说明白,就如下几个基本原则,一全局统一状态元数据,二全局统一业务关系结构可变丶可组装丶动态属性且可移动。三关系数据库与非关系数据库相容通,四不写具体应用方面的业务代码,只写与具体应用无关的组件与服务,五是服务接口是按需自动产生的,参数是可变化,可添加可转移,六业务元数据驱动,七表或业务动态属性,八交互模板化且自动寻找可匹配的服务接口,九任何业务数据结构都是建立在几个基本的结构模型上的,且具有多唯与动态属性,可实时挂靠,可聚合,可无限追塑,但只应用三级关联。
  • 呵呵呵,不知道你说什么元数据不元数据,我自己使用的分布式文件系统就全是 c 艹设计,已经设计成“要扩容只需在新机器上执行 file_server 即可”,file_server 自动连调度服务器,不需要人工干预。文件 crc32->file_server_id,调度服务器内存少时用 hash 存,有钞能力就 4*4g 内存直接无锁查询。一台 i7 服务器都足以处理全球请求(忽略带宽瓶颈,单纯机器性能),文件内容请求则分配到最多 42 亿台 file_server 处理,有钞能力就弄 42 亿个节点每台机器独享带宽。至于文件系统的固有问题,那就确保同一目录下文件/文件夹数量限制在一个范围内,除非你自己写个操作系统设计一套文件系统,否则只能这样。这算是无限扩展吗?是不是元数据服务我不知道,反正我就是按可靠性和效率优先扩展第二来设计。如果你说最多 42 亿台机器不算无限,那你牛逼。其他一些细节就不说了。不知道有多少人能看懂我在说啥🐶
  • 增加链表式标记,加入服务节点指向

推荐关注

正在加载中...