大索引技术,大数据的未来

原创 2014年12月17日 11:43:13

不管你信也好,不信也好,大数据时代真的来临了,随着Hadoop技术的普及,其生态圈发展的越来越壮大,Hive、Hbase、Spark、storm等的一系列新名词不断的涌现在我们的眼里。似乎nosql一夜间,攻陷了全部的大数据阵地。

那么传统的关系型数据库的一些思路,真的没有用武之地了么?真的就一去不复返了么?当大数据技术大旗在每个山头摇摆的时候,我们躲在角落里还能做些什么?“索引”,没错,数据库时代的必杀,大数据的利器。

当大数据使用上大索引后有什么好处?

1. 索引技术大幅度的加快数据的检索速度。

2. 索引技术可以显著减少查询中分组、统计和排序的时间。

3. 索引技术大幅度的提高系统的性能和响应时间,从而节约资源。

这个大索引系统应该什么样?

1. 数据规模超:万亿甚至十万亿。

2. 数据时效性高:数据从产生到能够查询到结果这个间隔不会超过30秒。

3. 查询响应要快:从万亿规模的数据里,查询到相关数据,响应时间为毫秒或者几秒。

4. 支持容灾:要能够支撑可靠的容灾,并且保证良好的数据的准确性。

5. 能够与现有的大数据系统进行较好的融合,方便之间的交互(数据导入导出)

存在哪些问题?

传统的关系型数据库的索引目前存在如下几个问题,是我们需要改进的。

1. 索引存储在本地硬盘

首先是分散在机器的每个硬盘上,索引不容易管理,容灾与高可用的实现代价较高。

其次是索引的迁移成本以及单机硬盘的大小制约了其索引规模和大小。

最后是如果是通过冗余("master/slave"或者"双写")等方式实现数据容灾,数据一致性的设计难度较大。

2. 表的管理,索引,调度曾混杂在一起,集群规模上不去

索引数据、计算资源掺杂在一起,调度系统管理的事情太多,既要管理索引,又要管理心跳,也要维护容灾,导致调度系统的机器规模上不来。同一个计算资源只分配给固定的索引数据导致计算资源太多的浪费。

3. 对硬件要求太高

数据必须长期持久的滞留在内存中,否则无法快速的加载和查询数据,对硬件要求较高一般都是需要大内存(48G以上)以及SSD硬盘,百亿规模的数据甚至需要数百台机器来支撑快速的查询,对于万亿规模的数据来说成本太高.

应该如何改进?

随着基于Docker on Gaia (腾讯版的Yarn)技术的趋于成熟以及在HDFS中的索引技术的成熟和性能的提升,低延迟的万亿规模的索引技术有了希望。

1.Gaia本身是一套完美的任务调度系统,他解决了Hadoop1.0版本Jobtracker调度的不足,调度延迟时间大大缩小,并且适合实时的即席任务调度,启动的任务是可以长久的持久化的运行的,并且有很好的容灾机制。

2.Docker解决了复杂的环境的依赖的问题,简化了Hermes繁杂的部署步骤。

3.索引可以直接存放在HDFS中,通过HDFS来解决数据的容灾问题,让业务能更专注索引的实现。目前也不要说HDFS性能很差了,那是过去,现在来看,其HDFS结合Hermes的BlockBuffer后性能还是很不错的。

Hermes大数据大索引的一个实现

我们实现Hermes on Docker的版本,该版本的设计有如下几个特点。

    1.易于使用与部署,几个Jar包几个Submit命令,服务直接在Docker上启动,不再需要部署复杂的环境。

    2.将索引数据与计算资源的分开,不再交叉的放在一起,分别管理,划清界限,减少程序设计复杂度。计算资源的管理直接交给Gaia来处理,从而提升集群的规模。

    3.一个计算资源不再固定的负责一个索引,而是根据实际的计算需要,处理不同的索引,这比之前一个资源(CPU+内存)固定的分配给一个索引利用率会高很多,因为并不是每次检索和查询都需要扫描全部的数据,有些数据根本就不需要或者很少去查,就没必要让他们长期的占用一个资源。

    4.索引会直接存储在HDFS上,通过HDFS来实现数据的高可用,这样程序的设计复杂性就会减少很多,不再担心本地硬盘的问题(是否损坏,是否已满,硬盘损坏时迁移时间过长),也不用担心各种网络的问题,理论上HDFS上有多大的空间,我们就可以存储多少索引,不再受限于本地磁盘大小的限制,数据规模可以很容易的水平拓展。

    5.索引的管理将会充分的放权,采用HDFS的目录形式的层次结构,便于管理,外部可以自由的配置索引的存储目录,根据不同业务的需要,索引可以按照时间进行打散,按照时间进行目录分区,也可以按照某些用户ID进行hash,也可以按照某些业务来管理配置不同的生命周期。

6.这个版本的Hermes除了可以单独对外提供服务,也会更加的开放,对外提供索引服务,提供了很多拓展功能,现有的Hive以及Spark可以很方便的通过类似InputFormat或RDD的方式直接使用大索引。同时可以方便的与HDFS,Hbase,Hive,进行交互,也可以通过自定义实时的消费Kafka,MetaQ等消息队列的数据。

试想下,Spark在利用上这个大索引后,一个万亿规模的数据,几秒钟就返回结果,而且还支持很多的复杂查询,是不是很值得期待呢 。


拓展阅读

Hermes与开源的Solr、ElasticSearch的不同



索引技术详解(转)

一、数据表的基本结构 为认识索引工作原理,首先有必要对数据表的基本结构作一次全面的复习。 SQLS 当一个新表被创建之时,系统将在磁盘中分配一段以8K为单位的连续空间,当字段的值从内存写入...
  • wfyhewfy
  • wfyhewfy
  • 2016年03月10日 18:30
  • 500

大索引技术,大数据的未来

不管你信也好,不信也好,大数据时代真的来临了,随着Hadoop技术的普及,其生态圈发展的越来越壮大,Hive、Hbase、Spark、storm等的一系列新名词不断的涌现在我们的眼里。似乎nosql一...
  • muyannian
  • muyannian
  • 2014年12月17日 11:43
  • 1853

大索引技术大数据的未来

一、大索引技术,大数据的未来        YDB并没有采用堆积机器,靠大内存和SSD硬盘的方式来提升计算速度。YDB采用索引技术, 在RDBMS中索引的概念大家一点都不陌生,但是在大数据里大家...
  • Coding_Cao
  • Coding_Cao
  • 2017年02月20日 10:49
  • 484

大索引技术大数据的未来

一、大索引技术,大数据的未来        YDB并没有采用堆积机器,靠大内存和SSD硬盘的方式来提升计算速度。YDB采用索引技术, 在RDBMS中索引的概念大家一点都不陌生,但是在大数据里大家...
  • qq_33160722
  • qq_33160722
  • 2017年02月19日 11:19
  • 190

大数据时使用索引实例

本文是根据 海量数据库的 查询优化及分页算法方案 做的实验,不知为何,同样的数据量时间却比原文少了将近百倍,由于插入数据耗时时间过长,所以只能勉强得出结论,大致还是准确的,可适当增加数据 CREATE...
  • u014269422
  • u014269422
  • 2016年07月13日 16:07
  • 528

Oracle索引技术 美 Darl Kuhn 中文PDF扫描版

  • 2014年12月22日 16:50
  • 14.15MB
  • 下载

技术管理之巅

  • 2017年09月18日 14:45
  • 8.09MB
  • 下载

畅想VR技术的未来

VR技术畅想 2016年是VR元年,所谓元年就是开始的一年吧。就在这一年,VR技术被国内外炒的火热,然而,作为一名技术员,应当冷静地看待VR技术将会带来的变革,以及当下这门技术的瓶颈在哪里。...
  • wolfqong
  • wolfqong
  • 2016年07月21日 16:46
  • 668

大数据应用的未来挑战和发展趋势

过去需要用百年才能走完的一个时代现在可能用几十年、十几年就完成了,英国的工业革命从发芽到在全世界生根用了一百年,美国的信息高速公路从一项绝密计划到让世界变成一个村落用了二三十年,而移动互联网、云计算、...
  • dotnetstudio
  • dotnetstudio
  • 2014年10月10日 16:10
  • 2794

apache kafka技术分享系列(目录索引)

apache Kafka中国社区中国社区QQ群1:162272557 未满  收费5¥,保证QQ运营,腾讯QQ VIP收年费,2000人群非常活跃,质量很高中国社区QQ群2:414762562 未满 ...
  • lizhitao
  • lizhitao
  • 2018年02月08日 11:30
  • 52847
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:大索引技术,大数据的未来
举报原因:
原因补充:

(最多只允许输入30个字)