迅闻网
让更多人看到你

mongodb redis结合使用(mongodb redis性能)

  mongodbredis结合使用

虽然我代表的是MongoDB,以下的答复看起来会很有安利自己产品的嫌疑,仍是要提醒楼主注意一些问题。
从问的问题来看,楼主对MongoDB或Redis都不熟,得出了用MongoDB+Redis来结合做项目的定论估计是看了哪篇文章的分享吧?不可否认,在某些很极点的场合在MongoDB前面再加一层Redis可能可以得到必定的收益,但是楼主是否考虑过自己的实际情况,是否真的到了需求在MongoDB前面加Redis的境地?要知道引进一项新技能,无论是保护成本仍是开发成本,以及对开发人员的要求都会成倍增加。
比方原来可以直接从数据库读的东西,现在要考虑什么时候该从缓存读取,相应的就要考虑缓存如何改写,脏数据该怎么办?这些问题说起来如同并不难,但不管什么问题放到高并发环境里就没有简单的问题。说句不中听的,楼主假如有满足的经历敷衍好上面这些问题,也就不会提现在这个问题了。幸运的是一般来说项目的并发还高不到需求两个一重用的境地,因为MongoDB已经有满足强的敷衍高并发的才能和水平扩展的才能。
所以抛开别人的定见不说,楼主自己应该想清楚这些问题:是什么唆使你把两项技能放在一起使用,你想从中得到什么优点?更重要的,假如只用其中一项技能,是不是也能解决问题?假如没有满足的依据说服自己,不妨实测一下用数据说话。

mongodb

mongodbredis性能

近期官网给出了RedisJson(RedisSearch)的功用测验报告,可谓碾压其他NoSQL,下面是核心的报告内容,先上定论:
关于隔离写入(isolatedwrites),RedisJSON比MongoDB快5.4倍,比ElasticSearch快200倍以上。
关于隔离读取(isolatedreads),RedisJSON比MongoDB快12.7倍,比ElasticSearch快500倍以上。
在混合作业负载场景中,实时更新不会影响RedisJSON的查找和读取功用,而ElasticSearch会遭到影响。以下是具体的数据:
RedisJSON*支撑的操作数/秒比MongoDB高约50倍,比ElasticSearch高7倍/秒。
RedisJSON*的推迟比MongoDB低约90倍,比ElasticSearch低23.7倍。
此外,RedisJSON的读取、写入和负载查找推迟在更高的百分位数中远比ElasticSearch和MongoDB安稳。当添加写入比率时,RedisJSON还能处理越来越高的整体吞吐量,而当写入比率添加时,ElasticSearch会下降它能够处理的整体吞吐量。
二、查询引擎
如前所述,reresearch和RedisJSON的开发十分着重功用。关于每一个版别,咱们都想确保开发者能够体验到安稳和产品。为此,咱们咱们给出了一些剖析东西、探测器来进行功用剖析。
而且,咱们每次发行新版别不时,也在不断的提升功用。特别是关于reresearch来说,2.2版别在加载和查询功用上都比2.0快了1.7倍,一起还改善了吞吐量和数据加载的推迟。
2.1加载优化
接下来的两个图显现了运转纽约市出租车基准测验的运转成果
从这些图表中能够看出,每一个reresearch的新版别都有一个实质性的功用改善。
2.2全文查找优化
为了评估查找功用,咱们索引了590万篇维基百科摘要。然后咱们运转一个全文查找查询面板,得到的成果如下图所示。
从上面的图能够看出,通过从v2.0迁移到v2.2,同样的数据,在写、读、查找(推迟图)方面都有了大幅度的改善,从而提高了运转Search和JSON的可完结吞吐量。
三、和其他结构的比照
为了评估RedisJSON的功用,咱们决议将它与MongoDB和ElasticSearch进行比较。为了便利比照,咱们会从文档存储、本地可用、云中可用、专业支撑和供给可伸缩性、功用等方面进行全方位的比照。
咱们运用了完善的YCSB规范来进行测验比照,它能够根据常见的作业负载来评估不同的产品,丈量推迟、吞吐量曲线直到饱满。除了CRUDYCSB操作之外,咱们还添加了一个两个字的查找操作,专门协助开发人员、体系架构师和DevOps从业者找到合适他们用例的最佳查找引擎。
3.1基准测验
此次测验,咱们运用了如下的一些软件环境:
MongoDBv5.0.3
ElasticSearch7.15
RedisJSON(RediSearch2.2+RedisJSON2.0)
此次是在AmazonWebServices实例上运转基准测验,这三种解决方案都是分布式数据库,而且最常用于生产中的分布式方式。这就是为什么一切产品都运用相同的通用m5d.8xlargeVM和本地SSD,而且每个设置由四个VM组成:一个客户端+三个数据库服务器。基准测验客户端和数据库服务器都在处于最佳网络条件下的单独m5d.8xlarge实例上运转,将实例严密地打包在一个可用区内,完结稳态剖析所需的低推迟和安稳的网络功用。
测验是在三节点集群上执行的,布置细节如下:
MongoDB5.0.3:三成员副本集(Primary-Secondary-Secondary)。副本用于添加读取容量并允许更低的推迟读取。为了支撑对字符串内容的文本查找查询,在查找字段上创建了一个文本索引。
ElasticSearch7.15:15个分片设置,启用查询缓存,并为2个根据NVMe的本地SSD供给RAID0阵列,以完结更高级别的文件体系相关弹性操作功用。这15个分片为咱们为Elastic所做的一切分片变体供给了可完结的最佳功用成果。
RedisJSON*:RediSearch2.2andRedisJSON2.0:OSSRedisClusterv6.2.6,有27个分片,均匀分布在三个节点上,加载了RediSearch2.2和RedisJSON2.0OSS模块。
除了这个首要的基准/功用剖析场景之外,咱们还在网络、内存、CPU和I/O上运转基准基准测验,以了解底层网络和虚拟机特性。在整个基准测验集期间,网络功用坚持在带宽和PPS的丈量约束以下,以发生安稳安稳的超低推迟网络传输(每个数据包p99<100micros)。
接下来,咱们将从供给单独的操作功用[100%写入]和[100%读取]开端,并以一组混合作业负载完毕以模仿实际作业中的应用程序场景。
3.2100%写入基准
如下图所示,该基准测验标明,RedisJSON*的吸取速度比ElasticSearch快8.8倍,比MongoDB快1.8倍,一起坚持每个操作的亚毫秒级推迟。值得注意的是,99%的Redis恳求在不到1.5毫秒的时刻内完结。
此外,RedisJSON*是咱们测验过的唯一一种在每次写入时自动更新其索引的解决方案。这意味着任何后续的查找查询都会找到更新的文档。ElasticSearch没有这种细粒度的容量;它将吸取的文档放在一个内部行列中,而且该行列由服务器(不受客户端控制)每N个文档或每M秒刷新一次。他们称这种办法为近实时(NRT)。ApacheLucene库(它完结了ElasticSearch的全文功用)旨在快速查找,但索引进程复杂且繁重。如这些WRITE基准测验图表所示,因为这种“规划”约束,ElasticSearch付出了巨大的价值。
结合推迟和吞吐量改善,RedisJSON*比Mongodb快5.4倍,比ElasticSearch快200倍以上,用于隔离写入。
3.3100%读取基准
与写相似,咱们能够观察到Redis在读取方面表现最佳,允许读取比ElasticSearch多15.8倍,比MongoDB多2.8倍,一起在整个推迟范围内坚持亚毫秒级推迟,如下表所示。
在结合推迟和吞吐量改善时,RedisJSON*比MongoDB快12.7倍,比ElasticSearch快500倍以上,用于隔离读取。
3.4混合读/写/查找基准
实际应用程序作业负载简直总是读取、写入和查找查询的混合。因此,在挨近饱满时了解由此发生的混合作业负载吞吐量曲线更为重要。
作为起点,咱们考虑了65%查找和35%读取的场景,这代表了一个常见的实际世界场景,在该场景中,咱们执行的查找/查询比直接读取更多。65%查找、35%读取和0%更新的初始组合也导致ElasticSearch和RedisJSON*的吞吐量持平。尽管如此,YCSB作业负载允许您指定查找/读取/更新之间的比率以满意您的要求。
“查找功用”能够指不同类型的查找,例如“匹配查询查找”、“分面查找”、“模糊查找”等等。咱们所做的最初向YCSB添加的查找作业负载仅专心于“匹配查询查找”,模仿分页的两词查询匹配,按数字字段排序。“匹配查询查找”是任何启用查找功用的供应商进行查找剖析的起点,因此,每个支撑YCSB的数据库/驱动程序都应该能够在其基准驱动程序上轻松启用此功用。
在每个测验变体中,咱们添加了10%的写入,以按相同的份额混合和削减查找和读取百分比。这些测验变体的方针是了解每个产品怎么处理数据的实时更新,咱们认为这是事实上的架构方针,即写入立即提交到索引,读取始终是最新的。
正如您在图表中所看到的,在RedisJSON*上不断更新数据和添加写入份额不会影响读取或查找功用并提高整体吞吐量。对数据发生的更新越多,对ElasticSearch功用的影响就越大,最终导致读取和查找速度变慢。
ElasticSearch可完结的ops/sec从0%更新到50%的演化,咱们注意到它在0%更新基准上以10kOps/sec开端,并遭到严重影响,削减了5倍的ops/sec,在50%更新率基准。
与咱们在上述单个操作基准中观察到的相似,MongoDB查找功用比RedisJSON*和ElasticSearch慢两个数量级,MongoDB的最大总吞吐量为424ops/sec,而RedisJSON*为16K最大ops/sec。
最终,关于混合作业负载,RedisJSON*支撑的操作数/秒比MongoDB高50.8倍,比ElasticSearch高7倍。如果咱们将剖析集中在混合作业负载期间的每种操作类型的推迟上,与MongoDB比较,RedisJSON*可将推迟下降多达91倍,与ElasticSearch比较,推迟下降23.7倍。
3.5完整推迟剖析
与丈量每个解决方案饱满之前发生的吞吐量曲线相似,在一切解决方案通用的可继续负载下进行完整的推迟剖析也很重要。这将使您能够了解关于一切已发布操作在推迟方面最安稳的解决方案是什么,以及哪种解决方案不易遭到应用程序逻辑引发的推迟峰值的影响(例如,弹性查询缓存未射中)。如果您想更深化地了解咱们为什么要这样做,GilTene供给了推迟丈量注意事项的深化概述。
查看上一节的吞吐量图表,并重视10%更新基准以包括一切三个操作,咱们做了两种不同的可继续负载变化:
250ops/sec:比较MongoDB、ElasticSearch和RedisJSON*,低于MongoDB的压力率。
6000ops/sec:比较ElasticSearch和RedisJSON*,低于ElasticSearch压力率。
3.5.1MongoDB与ElasticSearch与RedisJSON*的推迟剖析
在下面的第一张图片中,展示了从p0到p9999的百分位数,很明显,在每次查找时,MongoDB的表现都远远优于Elastic和RedisJSON*。此外,重视ElasticSearch与RedisJSON*,很明显,ElasticSearch容易遭到较高推迟的影响,这很可能是由垃圾搜集(GC)触发器或查找查询缓存未射中引起的。RedisJSON*的p99低于2.61毫秒,而ElasticSearchp999查找达到10.28毫秒。
在下面的读取和更新图表中,咱们能够看到RedisJSON*在一切推迟范围内表现最佳,其次是MongoDB和ElasticSearch。
RedisJSON*是在一切剖析的推迟百分位数上坚持亚毫秒级推迟的唯一解决方案。在p99,RedisJSON*的推迟为0.23毫秒,其次是MongoDB的5.01毫秒和ElasticSearch的10.49毫秒。
在写入时,MongoDB和RedisJSON*即使在p99时也能坚持亚毫秒级的推迟。另一方面,ElasticSearch显现出高尾推迟(>10毫秒),这很可能与导致ElasticSearch查找峰值的原因(GC)相同。
3.5.2ElasticSearch与RedisJSON的推迟剖析
仅重视ElasticSearch和RedisJSON*,在坚持6Kops/sec的可继续负载的一起,咱们能够观察到Elastic和RedisJSON*的读取和更新模式与以250ops/sec进行的剖析坚持一致。RedisJSON*是更安稳的解决方案,其p99读取时刻为3毫秒,而Elastic的p99读取时刻为162毫秒。
在更新时,RedisJSON*保留了3毫秒的p99,而ElasticSearch则保留了167毫秒的p99。
专心于查找操作,ElasticSearch和RedisJSON*以个位数p50推迟开端(p50RedisJSON*为1.13毫秒,而ElasticSearch的p50为2.79毫秒),其中ElasticSearch付出了GC触发和查询缓存未射中的价值在较高的百分位数上,在>=p90百分位数上清晰可见。
RedisJSON*将p99坚持在33毫秒以下,而ElasticSearch上的p99百分位数为163毫秒,高出5倍。

未经允许不得转载:迅闻网 » mongodb redis结合使用(mongodb redis性能)
分享到: 更多 (0)

评论 抢沙发

评论前必须登录!

 

迅闻网-让更多人看到你

登录/注册返回首页