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

不管你信也好,不信也好,大数据时代真的来临了,随着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中,通过HFDS来解决数据的容灾问题,让业务能更专注索引的实现。目前也不要说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在利用上这个大索引后,一个几万亿的数据,几秒钟就返回结果,而且还支持很多的复杂查询,是不是很值得期待呢。

来源:微信公众号---腾讯大数据

原文发布于微信公众号 - 数据的力量(shujudeliliang)

原文发表时间:2015-01-19

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏carven

实习中结

开始实习至今也有差不多有个月了(实际工作时间是一个多月),见识了很多新的事物,学到很多新的知识。公司搬到了T.I.T创意园。。。 等等,很多感觉是自己一个人在学...

790
来自专栏杨建荣的学习笔记

自动化平台开发小结(四)

今天对备份恢复和元数据的功能点进行了改进,突然发现需要做的事情远比想象的要多。 技术方面,目前Django的框架使用开始有一些需求的瓶颈了,因为有些需求从业务的...

3785
来自专栏idba

数据库系统中的“黑天鹅”

一 前言 纳西姆.尼古拉斯.塔勒布的经典著作《黑天鹅》中对“黑天鹅现象”的定义是

973
来自专栏ASP.NET MVC5 后台权限管理系统

ASP.NET MVC5+EF6+EasyUI 后台管理系统(37)-文章发布系统④-百万级数据和千万级数据简单测试

我想测试EF在一百万条数据下的显示时间!这分数据应该有很多同学想要,看看EF的性能! 服务器 ? 现在来向SQL2008R2插入1000000条数据吧 decl...

26510
来自专栏前端儿

2016校招内推 -- 阿里巴巴前端 -- 四面面试经历

其实也没什么可说的,一面主要问基础,二面才进入项目实习之类的探讨,三面两者都有吧但还是综合多一点

1142
来自专栏PHP在线

8 个不得不说的 MySQL 陷阱

Mysql安装简单,速度较快,功能丰富。另外它还是开源运动的标杆,它的伟大成就向我们展示了一个成功的公司是可以建立在开源代码之上的。 然而用过mysql的人都曾...

3745
来自专栏IT大咖说

你是否知道怎样借助ES在不同场景下构建数据仓库

内容来源:2017 年 11 月 25 日,数说故事平台架构团队高级工程师吴文杰在“Elastic Meetup 广州交流会”进行《Data Warehouse...

1634
来自专栏腾讯大数据的专栏

后Hadoop时代的大数据架构

提到大数据分析平台,不得不说Hadoop系统,Hadoop到现在也超过10年的历史了,很多东西发生了变化,版本也从0.x进化到目前的2.6版本。我把2012年后...

3638
来自专栏飞总聊IT

难圆满的SQL Server 2017Linux梦

难圆满的SQL Server 2017Linux梦 ? 最近数据库领域大事不断。继Oracle OpenWorld由70多岁的CTO Larry宣告着DBA们的...

3548
来自专栏芋道源码1024

慢讯!Sharding-Sphere 正式进入 Apache 孵化器

美国时间2018年11月10日,开源分布式数据库中间件生态圈Sharding-Sphere正式进入Apache基金会孵化器。

1763

扫码关注云+社区

领取腾讯云代金券