海量数据存储面临的问题

海量数据存储面临的问题


成本高

传统存储硬件通用性差,设备投资加上后期维护,升级扩容的成本非常高。


例如:盘位满了,要换更多盘位的机器。3
image.png


性能低

单节点I/O性能瓶颈无法逾越,难以支撑海量数据的高并发高吞吐场景。


可扩展性差

无法实现快速部署和弹性扩展,动态扩容、缩容成本高,技术实现难度大。


如何实现分布式文件存储


如何支撑高效率的计算分析

image.png

传统存储方式意味着数据存储是存储,计算是计算,当需要处理数据的时候把数据移动过来(存储不动,数据移动)。
程序和数据存储是属于不同的技术厂商实现无法有机统一整合在一起。


如何解决海量数据存储的问题

传统做法是单机存储,随着数据变多,会遇到存储瓶颈。

  • 单机纵向扩展:
    内存不够加内存,磁盘不够加磁盘,有上限限制,不能无限制加下去。

  • 多机横向扩展:
    采用多台机器存储,一台不够就加机器。理论上可以无限。
    多台机器存储也意味着迈入了分布式存储


如何解决海量数据文件查询便捷问题

当文件被分布式存储在多台机器之后,后续获取文件的时候如何能快速找到文件位于哪台机器上呢?


一台一台查询过来是不靠谱的。因此可以借助于元数据记录来解决这个问题。把文件和其存储的机器的位置信息记录下来,类似于图书馆查阅图书系统,这样就可以快速定位文件存储在哪一台机器上了。


image.png


如何解决大文件传输效率慢的问题

大数据使用场景下,GB、TP级别的大文件是常见的。当单个文件过大的时候,如何提高传输效率?

通常的做法是分块存储:

把大文件拆分成若干个小块(block简写blk),分别存储在不同机器上,并行操作提高效率。

此外分块存储还可以解决数据存储负载均衡问题。此时元数据记录信息也应该更加详细:文件分了几块,分别位于哪些机器上。


image.png


如何解决硬件故障数据丢失问题

image.png


如何解决用户查询视角统一规整问题

namespace也可以理解为文件夹的目录
image.png


分布式存储应具备的特征

image.png


HDFS的优缺点

Hdoop HDFS(大数据分布式文件系统)
HDFS是一个分布式文件系统,是Hadoop生态系统中的一个重要组成部分,是Hadoop中的存储组件,HDFS是一个高度容错性的系统,HDFS能提供高吞吐量的数据访问,非常适合飞规模数据集上的应用。


HDFS的优点:

  1. 搞容错性
    1. 数据自动保存多个副本
    2. 副本丢失后,自动恢复
  2. 良好的数据访问机制
    1. 一次写入,多次读取,保证数据一致性
  3. 适合大数据文件的存储
    1. TB,甚者PB级数据
    2. 扩展能力很强

HDFS的缺点:

  1. 低延迟数据访问
    1. 难以应付毫秒级以下的应用
  2. 海量小文件读取
    1. 占用NameNode大量内存
  3. 一个文件只能有一个写入者
    1. 仅支持append(追加)
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
什么是SF1R SF1R是一个分布式的存储搜索一体化海量数据引擎。SF1R来自于iZENECloud团队多年的 研发成果,并且已经在商业网站上经受住了严苛的考验。2014年,iZENECloud团队把SF1R 开放给社区,采用Apache License 2,希望共同改进和维护。 Note SF1R的全称是Search Formula 1 Revolution,SF1R是iZENECloud团队给搜索引擎项目使用的内部代号。 SF1R的历史和特色 SF1R是一个存在多年的项目,完全基于C 语言开发,最新的master分支已经可以用 C 11编译。SF1R在早期开发时,参考了流行的Lucene的索引设计,并进行了若干改进, 这里边包括实时索引,以及更好的压缩手段如PForDelta以及NewPFor。然而在使用过程 中,我们发现Lucene这种完全基于文件的索引应对高并发和低延迟方面不具有优势,鉴于 绝大多数大规模搜索引擎的索引均完全放置于内存中,iZENECloud团队又给SF1R添加了 两种索引Zambezi和Suffix,这2种索引均是业界最佳的设计,大大提升了SF1R的性能, 在后边将分别提到。iZENECloud团队在根据需求不断调整SF1R的过程中,给SF1R添加了众 多的功能,包括各种数据挖掘特性,以及集成了推荐引擎,使之成为一个庞大的搜索,存储, 推荐,挖掘一体化引擎,项目也因此变得臃肿不堪。因此,在2014年,iZENECloud团队针对 老版本的SF1R进行了大量裁剪,把不需要的数据挖掘,以及推荐引擎都从项目里删除,只留下 搜索和存储,这就是SF1R-Lite项目,感兴趣的朋友可以从提交历史里恢复这些裁剪。 为什么采用SF1R 社区目前绝大多数应用都已经采用Lucene,以及基于Lucene的一系列搜索解决方案比如Solr 和ElasticSearch,这些搜索方案经过十多年很多人的改进,在通用化方面已经非常优秀。那么 基于此,为什么还要再采用新的搜索方案呢? 这里边有3个原因:首先,基于Java的搜索方案, 在面临高压力场景时,由于GC的存在而时常有延迟抖动发生,SF1R在实际应用中,可以做到跑满 全部CPU(例如16核),并且7*24不间歇的运转而没有上述抖动;其次,SF1R采用的2种内存索引, 在性能上远高于常规方案,更能满足对性能要求苛刻的应用,在实际应用中,SF1R曾经在单一节点 上部署和索引了上亿文档,仍然提供快速响应;第三,SF1R是一个完整的服务端引擎,可以方便的 对索引和其他功能进行扩展。相比Lucene社区的庞大代码仓库,SF1R的项目要精简得多,因此更加 便于针对特定场景进行修改和维护,这从SF1R支持3种索引结构就可以看出,此外,针对广告检索, SF1R也可以方便扩充第4种索引,这些都是传统搜索解决方案Lucene不具备的。 Zambezi索引 Zambezi索引来自于 Zambezi 项目,索引的原理可以参考相关的论文,这是传统倒排索引结构里的最佳设计之一,因为它可以做到在 提供实时搜索的功能下不损失查询性能,因此非常适合作为Twitter或者微博搜索服务。在引入Zambezi 到SF1R的过程中,iZENECloud团队又进行了若干改进,这里边包含:原始Zambezi索引完全为Twitter 类查询服务,因此,对于不常见的词(比如在少于128个文档里出现),原始设计进行了剪枝,既无法在 索引中搜索到。iZENECloud团队的改进去掉了这种限制;此外,iZENECloud团队还引入了一些最新的索引 压缩技术并且加以改进,比如 SIMD intersection ,使之具备最高速的解压方案。 Suffix索引 Suffix索引采用了罕见的Succinct Self Index结构,基础设施是Suffix Array和Wavelet Tree, 具备完全不同于倒排索引的结构,相关的原理可以参见SF1R的技术报告。Suffix索引具备远高于传统索引的查询性能,缺点是构建的时候需要占用大量内存,并且无法支持增量。 标签:SF1R

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

识途老码

赞赏是第一生产力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值