围绕着内存数据库的4个流言

标签: 大数据 内存 内存数据库 数据库 | 发表时间:2015-09-13 12:20 | 作者:DinK
出处:http://www.199it.com

作者Yiftach Shoolman是Redis Labs的联合创始人兼CTO,拥有着丰富的实践经验。Yiftach 之前曾是Crescendo Networks(后被F5收购)的总裁、创建者兼CTO,更早还是Native Networks的技术副总裁。在本文中,Yiftach直述了当下开发者对内存数据库所存在的偏见,并提出了一些技术选型参考意见。

以下为译文

时下,我们正处于一个日新月异的时代,而优秀应用的响应时间往往需要被控制在0.1秒内。这也意味着,如果可接受网络通信时间为50毫秒,那么开发者必须在剩余的50毫秒内处理数据并进行响应。要实现这一点毫无疑问会需求毫秒级的数据库响应时间,在同时支撑上万个请求的场景中更是如此,而这样的需求当下只有少数几个灵活度极高、功能齐全的数据库才能满足。

在大数据处理情景中,洞见必须被快速收集并做出决策,而在没有复杂优化或折中的情况下,内存数据库可以在数秒内完成以往传统数据库数小时或者数分钟的工作。尽管如此,当下在内存数据库领域仍然存在诸多流言,大量人仍然认为内存数据库不可靠性、不一致并且伴随着昂贵的开销。然而最重要的是,还有人认为只要把数据库放到内存中就可以获得所需的性能。

流言1:所有内存数据库都很快

答案显然是否定的。即使当下大部分内存数据库都使用非常高效的语言编写,比如C和C++,但是它们仍然无法得到所需的响应需求,这主要基于以下几点原因:

1. 在不同数据库中,处理命令的复杂性是不同的。在高性能数据库中,处理命令会在最小复杂度下执行。最直接的影响就是就是,在数据集不断增大的情况下,你可能需要一直优化查询时间。

2. 查询效率同样不同。有些时候,数据库会把全部加载进内存的数据当做单一的BLOB(类似memcached的缓存机制),这显然是没有效率的——数据库应该具备分散存储和查询值的能力,以及有效地节约网络和内存开销,从而显著地降低应用程序处理时间。

3. 单线程和多线程架构的权衡。

多线程会尽可能的利用计算能力,无需数据库用户做任何处理,但是这个解决方案同样需要做大量的内部管理和同步,从而消耗大量的计算资源。在多线程模式下,锁开销可能会大幅度降低数据库性能。

单线程使用了一个非常简单的执行模型,在这个解决方案中不存在锁的问题,同时也只会耗费少许的计算性能,但毫无疑问的是,计算资源的管理将从数据库移交给用户。理想的解决方案肯定是让用户尽可能少地做资源管理,因为数据库管理本来就是个轻度资源密集型工作。

4. 零共享vs. 共享vs. 共享一切。共享会影响到系统的扩展性。在数据库体积不断增长的同时,性能也必须时刻满足实例的需求。零共享模型让所有实体都以独立单元的形式存在,从而避免了处理暴增后的通信开销,实现线性扩展能力。

5. 通过避免网络方面任务和减少TCP协议开销, 零延时分布式代理等内置加速组件可以显著地提升数据库性能。在某些情况下,代理也可能与数据库通信,以确定其是否作为主机上服务远程客户端的另一个本地客户端进程。

如果吞吐量和延时是主要目标,那么机构很显然需要选择一个可以实现毫秒级延时并最小化服务器需求的数据库。

流言2:内存计算是不可靠和不一致的

大多数NoSQL数据库(不只是内存数据库)在提交数据到磁盘或者副本之前都为客户端提供了acknowledgements (ack)。因此,这里很可能会造成数据不一致的情况。

55ed1b4f8e53e_middle

CAP定理标明任何分布式计算机系统都不能同时具备一致性、可用性和分区容错性。不同的数据库会选择不同的类型,具体情形如下:选择CP模型表示开发者不用去关心一致性,但是在网络分割事件中写命令则是不允许的。如果选择AP模型则意味着数据库对读写一直可用,但是开发者在写应用程序代码时就需要考虑一致性问题,而不是期望数据库去完成这个操作。因此,请根据使用场景来选择合适的数据库模型。

流言3:内存计算很难扩展

扩展共有两个途径。首先通过给托管数据库的服务器纵向扩展,比如增加更多的CPU和内存;其次,通过向内存集群中添加更多的主机实现横向扩展。在许多数据库中,你可以在同一个节点上运行同一个数据集的多个分片,因此可以通过更有效率的计算资源利用来延缓扩展需求。同样,这里也可以将多个服务器的内存整合起来成为一个共享内存池,从而突破单机内存大小限制。现下,很多内存数据库同时允许这两种方法的扩展,通过动态的增加分配给数据库的核心和内存节点数量来最大化应用程序的响应能力。

流言4:内存计算是昂贵的

任何需要快速提升吞吐量的应用都面临着相同的问题:“一定等级的吞吐量究竟需要花多少钱”。举个例子,在1500万OPS情景下,运行在单Amazon EC2实例上的内存数据库会比非内存数据库便宜,但是如果使用数百台服务器达到同样的效果结果可能就会截然相反。

如果数据集规模是TB级别,内存的花费很显然会成为问题,然而当下已经有使用闪存扩展内存的技术存在,从而降低花费。但需要注意的是,使用闪存来扩展内存势必会影响到系统性能,因此这里理想的技术是控制闪存和内存的比例以达到一个理想的性价比。

综上所述,根据实际场景来选择合适的数据库技术将会大幅度提高资源利用效率。同时,新型数据库出现已有很长一段时间,因此抛弃不必要的成见才能让工作事半功倍。

原文链接: Busting 4 Myths of In-Memory Databases

翻译/ OneAPM工程师

相关 [内存 数据库 流言] 推荐:

围绕着内存数据库的4个流言

- - 199IT互联网数据中心
作者Yiftach Shoolman是Redis Labs的联合创始人兼CTO,拥有着丰富的实践经验. Yiftach 之前曾是Crescendo Networks(后被F5收购)的总裁、创建者兼CTO,更早还是Native Networks的技术副总裁. 在本文中,Yiftach直述了当下开发者对内存数据库所存在的偏见,并提出了一些技术选型参考意见.

VoltDB内存数据库分析

- - 淘宝核心系统团队博客
VoltDB是一个宣称性能超过Mysql 100倍的新型数据库. 它源自Micheal Stonebraker一篇论文H-Store. 在这篇论文发表后,Stonebraker成立了VoltDB公司带着他的一些学生开始在OLTP数据库领域打拼. Stonebraker从上世纪70年代——数据库刚开始发展的时间——就开始在数据库领域活跃,这样的老古董提出的数据库的新想法,给了整个存储领域很大的想象空间.

对内存数据库的使用已达临界点

- - InfoQ cn
微软的David Campbell在文章《 内存数据库即将到到临界点(The coming in-memory database tipping point)》中说到, 内存数据库离广泛采用越来越近了. 他还说明了微软在这个领域的策略. 据David所说,以下各种趋势使得内存数据库会在五年内变得普遍:.

内存数据库分析-装载整理

- - 人月神话的BLOG
转载整理自: http://titan.iteye.com/. 传统的数据库管理系统把所有数据都放在磁盘上进行管理,所以称做磁盘数据库(DRDB:Disk-Resident Database). 磁盘数据库需要频繁地访问磁盘来进行数据的操作,由于对磁盘读写数据的操作一方面要进行磁头的机械移动,另一方面受到系统调用(通常通过CPU中断完成,受到CPU时钟周期的制约)时间的影响,当数据量很大,操作频繁且复杂时,就会暴露出很多问题.

内存数据库FastDB和SQLite性能测评

- - CSDN博客数据库推荐文章
在很多项目中,经常会碰到这样的需求,需要对大量数据进行快速存储、查询、删除等操作,特别是在一些针对诸如运营商、银行等大型企业的应用中,这些需求尤为常见. 比如智能网中的大量在线并发用户的数据管理、软交换平台中的在线信息交互、宽带/3G等数据网中在线用户行为记录等等. 针对这些情形,我们通常需要选择高性能的数据库产品,而且通常需要使用内存数据库,顾名思义,内存数据库指的是所有的数据访问控制都在内存中进行,这是与磁盘数据库相对而言的,磁盘数据库虽然也有一定的缓存机制,但都不能避免从外设到内存的交换,而这种交换过程对性能的损耗是致命的,目前主流数据库如SYBASE、ORACLE等都有这种缓存机制,如将特定表绑定一定的缓存,从而在一定程度上改善数据吞吐性能.

如何让NoSQL内存数据库适合企业级应用

- - CSDN博客数据库推荐文章
如何让NoSQL内存数据库适合企业级应用. 作者:chszs,转载需注明. 博客主页: http://blog.csdn.net/chszs. 英文原文: How to Make Your In-memory NoSQL Datastores Enterprise-Ready. 对于每一个关注用户体验的Web应用或移动应用而言,NoSQL内存数据库(例如开源的 Redis和Memcached)正逐步成为事实上的标准.

[转]内存数据库的几个典型应用场景

- - 小鸥的博客
近些年内存数据库(IMDB)技术发展迅猛. 除了与生俱来的高性能之外,IMDB本身越来越向着功能完整的独立DB的方向发展. 下面简单描述当前比较常见的几个IMDB应用场景,希望对有志于IMDB技术的同僚以启发——. IMDB最大规模的应用集中在电信领域,尤其以计费系统为主. 当然,近些年陆续开始向新的电信业务领域拓展,例如核心网、CRM、精确营销等.

内存参数设置不合理导致数据库HANG

- - CSDN博客数据库推荐文章
内存参数设置不合理导致数据库HANG. 2节点RAC,数据库忽然HANG住,重启一个实例后恢复正常. 故障时间段约为8:30-10:00,以下为alert报错:. Thread 2> ORA-07445: 出现异常错误: 核心转储 [kksMapCursor()+323] [SIGSEGV] [ADDR:0x8] [PC:0x763597B] [Address not mapped to object] [].

当内存512遇上Access数据库600M,IO磁盘受伤了

- - 博客园_首页
服务器内存就512M,Access数据库(文章库)600多M,结果竟然就是IO受伤了. 秋色园技术原理解析 系列,园里不少看过的帅歌,应该有点印象,从开始到现在,还是铁打的Access数据库. 虽然本人目前对Access恨入之骨,皆因囊中羞涩,暂时不得不与之同流合污. 忙碌 微博粉丝精灵几个月来, 秋色园一直运行正常,除了远程界面都变的很卡之外,基本上也没发现什么异常.

数据库sharding

- - 数据库 - ITeye博客
当团队决定自行实现sharding的时候,DAO层可能是嵌入sharding逻辑的首选位置,因为在这个层面上,每一个DAO的方法都明确地知道需要访问的数据表以及查询参数,借助这些信息可以直接定位到目标shard上,而不必像框架那样需要对SQL进行解析然后再依据配置的规则进行路由. 另一个优势是不会受ORM框架的制约.