加入收藏 | 设为首页 | 会员中心 | 我要投稿 天瑞地安资讯网 (https://www.ruian888.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 大数据 > 正文

想扩展你的数据库吗?那么先学习一下I/O

发布时间:2021-08-03 19:11:46 所属栏目:大数据 来源:互联网
导读:副标题#e# 作为一名软件开发者,我们非常看重那些抽象化的东西。API越简单,对我们越有吸引力。辩证地讲,MongoDB最大的优势就是优雅的API和它的敏捷性,这让开发者的编码过程变得异常的简单。 但是,当MongoDB涉及到大数据可扩展性问题时,开发者还是需要
副标题[/!--empirenews.page--]

    作为一名软件开发者,我们非常看重那些抽象化的东西。API越简单,对我们越有吸引力。辩证地讲,MongoDB最大的优势就是“优雅”的API和它的敏捷性,这让开发者的编码过程变得异常的简单。

 

 

    但是,当MongoDB涉及到大数据可扩展性问题时,开发者还是需要了解一下它的底层,弄明白那些潜在的问题,然后才能快速地进行解决。如果不理解,最终可能会选择一个低效的解决方案,而且浪费了时间和金钱。本文重点介绍了,如何为大数据的扩展性问题找个一个高效的解决方案。

 

 

    定义问题

 

 

    首先,我们要确定应用的上下文,本文主要讨论的是MongoDB的应用程序。这意味着,我们将研究一个分布式文档存储数据库,而且它还支持二级索引和分片集群。如果是针对其他的NoSQL产品,像Riak或者Cassandra,我们可能会讨论I/O瓶颈问题,而本文主要关注MongoDB的一些特性。

 

 

    其次,这些应用能够做什么?是做联机事务处理( OLTP)还是做联机分析处理( OLAP)?本文主要讨论的是OLTP,因为对MongoDB而言,OLAP还是一个不小的挑战,或者说基本不能够进行处理。

 

 

    第三,大数据是什么?通过大数据,我们能够处理和使用更多的数据,不再局限于单机RAM中的那些部分。这样的话,有些数据保留在服务器上,而更多的数据则是存放在磁盘中,这就需要I/O的访问。但是请注意,我们不是在讨论数据库够不够大,而是关注那些经常被存取和使用的数据(有时称之为“工作集”)是不是很小。比如说,磁盘上虽然存储了好几年的数据,但是应用可能经常访问的只有最后一天的数据。

 

 

    第四,OLTP应用的限制性因素有哪些?简而言之,就是I/O。硬盘驱动每秒钟只可以启动上百次的I/O,而另一方面,RAM每秒可以实现数百万次的存取,这个限制性因素就是导致大数据应用I/O瓶颈的原因所在。

 

 

    最后,我们应该如何解决I/O瓶颈?通过分析思维,公式和直接指令给我们提供了很多种方式,但是一个持久性的解决方案就需要“理解”。用户必须着眼于应用程序的I/O特性,然后才能做出最好的设计决策。

 

 

    开销模型

 

 

    未来解决I/O瓶颈,第一步需要掌握哪些数据库操作会包括I/O。 无论MongoDB,还是其他的数据库类型,都有三种基本的操作:

 

 

    Point Query:查找一个独立的文件。在一个给定的位置的文件夹(磁盘或者内存上),检索该文档。对于大数据来说,该文件可能不在内存中。此操作可能会导致一次I/O。

 

 

    Range Query:在索引中,查找大量的连续性文件,对比Point Query而言,它是一个更高效的查询操作。这是因为我们查找的这些数据都是打包存放在磁盘上,可以通过极少的I/O操作来直接读入内存。Range Query一般检索100个文件才会启动一次I/O,相对比,100个Point Query检索100个文件可能就需要100次I/O操作。

 

 

    Write:写文件到数据库中。类似MongoDB这样的数据库,都会产生I/O。而对那些“写优化”数据结构的数据库而言,比如 TokuMX,仅仅需要很少的I/O。不像MongDB,“写优化”的数据结构能够通过执行多次插入来分摊I/O。

 

 

    在了解三个基本操作对I/O的影响之后,还需要理解MongoDB数据库语句对I/O的影响。MongoDB包含了这三个基本操作,同时还构建了四个用户级别的操作:

 

 

    插入:将一个新文件写到数据库中。

 

 

    查询:在集合上使用索引,这样做一个Range Queries和Point Query的整合。如果该索引是一个覆盖索引或者是集群索引,那么接下来基本上只需要做范围查询。否则的话,整合的范围查询和点查询就会被启用。

 

 

    修改和删除:这是一个查询和写操作的整合。查询操作用于发现那些需要更新和删除的文件,然后写操作再对这些文件进行修改或者是删除。

 

 

    现在,我们理解了开销模型。不过为了解决I/O的瓶颈问题,用户还需要知道哪些应用启动了I/O操作。这就需要我们了解数据库的行为。I/O启动是源于查询操作吗?如果是这样的话,查询行为是如何影响I/O的?还是源于修改操作?如果是因为修改导致的影响,那么是因为修改过程中的查询操作还是插入操作?一旦用户掌握了哪些因素会影响 I/O,接下来就可以逐步来解决瓶颈的问题了。

 

 

    假设我们明白了某个应用的I/O特性,我们就可以探讨几种途径来解决这一问题。我最喜欢的方式是这样的:首先尝试使用软件来解决该问题,如果不能完美的解决,那么再考虑硬件。毕竟软件的成本更低且易于维护。

 

 

[page]    可行的软件解决方案

 

 

    一个可行的软件解决方案,就是需要减少软件或者应用的I/O启动次数。针对不同的瓶颈,下面列举了对应可行的解决方案:

 

 

    问题:插入操作导致过多的I/O

 

 

    可行方案:使用一个写优化的数据库,比如说TokuMX,使用TokuMX的一项优势就是它能够大幅度减少对写操作的I/O请求,而索引方式使用的是Fractal Trees( TokuDB实际上还对Fractal Trees做了改进,将插入的IO数量级从log(N)提高到了logB(N))

 

 

    问题:查询操作导致过多的I/O

 

 

(编辑:天瑞地安资讯网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!