Memcache缓存与Mongodb数据库的优势和应用

先说说自己对Memcache和Mongodb的一些看法,主要是抛砖引玉了,希望看到大家的意见和补充。

Memcache

Memcache的优势我觉得总结下来主要体现在:

1) 分布式。可以由10台拥有4G内存的机器,构成一个40G的内存池,如果觉得还不够大可以增加机器,这样一个大的内存池,完全可以把大部分热点业务数据保存进去,由内存来阻挡大部分对数据库读的请求,对数据库释放可观的压力。

2) 单点。如果Web服务器或App服务器做负载均衡的话,在各自内存中保存的缓存可能各不相同,如果数据需要同步的话,比较麻烦(各自自己过期,还是分发数据同步?),即使数据并不需要同步,用户也可能因为数据的不一致而产生用户体验上的不友好。

3) 性能强。不用怀疑和数据库相比确实是,根源上还是内存的读写和磁盘读写效率上几个数量级的差距。有的时候我们在抱怨数据库读写太差的情况下可以看看磁盘的IO,如果确实是瓶颈的话装啥强劲的数据库估计也档不了,强不强无非是这个数据库多少充分的利用了内存。

但是也不太建议在任何情况下使用Memcache替代任何缓存:

1) 如果Value特别大,不太适合。因为在默认编译下Memcache只支持1M的Value(Key的限制到不是最大的问题)。其实从实践的角度来说也不建议把非常大的数据保存在Memcache中,因为有序列化反序列化的过程,别小看它消耗的CPU。说到这个就要提一下,我一直觉得Memcache适合面向输出的内容缓存,而不是面向处理的数据缓存,也就是不太适合把大块数据放进去拿出来处理之后再放进去,而是适合拿出来就直接给输出了,或是拿出来不需要处理直接用。

2) 如果不允许过期,不太适合。Memcache在默认情况下最大30天过期,而且在内存达到使用限制后它也会回收最少使用的数据。因此,如果我们要把它当作static变量的话就要考虑到这个问题,必须有重新初始化数据的过程。其实应该这么想,既然是缓存就是拿到了存起来,如果没有必定有一个重新获取重新缓存的过程,而不是想着它永远存在。

在使用Memcache的过程中当然也会有一些问题或者说最佳实践:

1) 清除部分数据的问题。Memcache只是一个Key/Value的池,一个公共汽车谁都可以上。我觉得对于类似的公共资源,如果用的人都按照自己的规则来的话很容易出现问题。因此,最好在Key值的规范上上使用类似命名空间的概念, 每一个用户都能很明确的知道某一块功能的Key的范围,或者说前缀。带来的好处是我们如果需要清空的话可以根据这个规范找到我们自己的一批Key然后再去清空,而不是清空所有的。当然有人是采用版本升级的概念,老的Key就让它过去吧,到时候自然会清空,这也是一种办法。不过Key有规范总是有好处的,在统计上也方便一点。

2) Value的组织问题。也就是说我们存的数据的粒度,比如要保存一个列表,是一个保存在一个键值还是统一保存为一个键值,这取决于业务。如果粒度很小的话最好是在获取的时候能批量获取,在保存的时候也能批量保存。对于跨网络的调用次数越少越好,可以想一下,如果一个页面需要输出100行数据,每一个数据都需要获取一次,一个页面进行上百次连接这个性能会不会成问题。

那么Memcache主要用在哪些功能上呢?

其实我觉得平时能想到在内存中做缓存的地方我们都可以考虑下是不是可以去适用分布式缓存,但是主要的用途还是用来在前端或中部挡一下读的需求来释放Web服务器App服务器以及DB的压力。

Mongodb

Mongodb是一款比较优良的非关系型数据库的文档型的数据库。它的优势主要体现在:

1) 开源。意味着即使我们不去改也可以充分挖掘它,MS SQL除了看那些文档,谁又知道它内部如何实现。

2) 免费。意味着我们可以在大量垃圾服务器上装大量的实例,即使它性能不怎么高,也架不住非常多的点啊。

3) 性能高。其它没比较过,和MS SQL相比,同样的应用(主要是写操作)一个撑500用户就挂了,一个可以撑到2000。在数据量上到百万之后,即使没索引,MS SQL的插入性能下降的也一塌糊涂。其实任何事物都有相对性的,在变得复杂变得完善了之后会牺牲一部分的性能,MS SQL体现的是非常强的安全性数据完整性,这点是Mongodb办不到的。

4) 配置简单并且灵活。在生产环境中对数据库配置故障转移群集和读写分离的数据库复制是很常见的需求,MS SQL的配置繁琐的步骤还是很恐怖的,而Mongodb可以在五分钟之内配置自己所需要的故障转移组,读写分离更是只需要一分钟。灵活性体现在,我们可以配置一个M一个S,两个M一个S(两个M写入的数据会合并到S上供读取),一个M两个S(一个M写入的数据在两个S上有镜像),甚至是多个M多个S(理论上可以创建10个M,10个S,我们只需要通过轮询方式随便往哪个M上写,需要读的时候也可以轮训任意一个S,当然我们要知道不可能保证在同一时间所有的S都有一致的数据)。那么也可以配置两个M的对作为一套故障转移群集,然后这样的群集配置两套,再对应两个S,也就是4个M对应2个S,保证M点具有故障转移。

5) 使用灵活。在之前的文章中我提到甚至可以通过SQL到JS表达式的转换让Mongodb支持SQL语句的查询,不管怎么说Mongodb在查询上还是很方便的。

之前也说过了,并不是所有数据库应用都使用采用Mongodb来替代的,它的主要缺点是:

1) 开源软件的特点:更新快,应用工具不完善。由于更新快,我们的客户端需要随着它的更新来升级才能享受到一些新功能,更新快也意味着很可能在某一阶段会缺乏某个重要功能。另外我们知道MS SQL在DEV/DBA/ADM多个维度都提供了非常好的GUI工具对数据库进行维护。而Mongodb虽然提供了一些程序,但是并不是非常友好。我们的DBA可能会很郁闷,去优化Mongodb的查询。

2) 操作事务。Mongodb不支持内建的事务(没有内建事务不意味着完全不能有事务的功能),对于某些应用也就不适合。不过对于大部分的互联网应用来说并不存在这个问题。

在使用Mongodb的过程中主要遇到下面的问题:

1) 真正的横向扩展?在使用Memcache的过程中我们已经体会到这种爽了,基本可以无限的增加机器来横向扩展,因为什么,因为我们是通过客户端来决定键值保存在那个实例上,在获取的时候也很明确它在哪个实例上,即使是一次性获取多个键值,也是同样。而对于数据库来说,我们通过各种各样的方式进行了Sharding,不说其它的,在查询的时候我们根据一定的条件获取批量的数据,怎么样去处理?比如我们按照用户ID去分片,而查询根本不在乎用户ID,在乎的是用户的年龄和教育程度,最后按照姓名排序,到哪里去取这些数据?不管是基于客户端还是基于服务端的Sharding都是非常难做的,并且即使有了自动化的Sharding性能不一定能有保障。最简单的是尽量按照功能来分,再下去就是历史数据的概念,真正要做到实时数据分散在各个节点,还是很困难。

2) 多线程,多进程。在写入速度达不到预期的情况下我们多开几个线程同时写,或者多开几个Mongodb进程(同一机器),也就是多个数据库实例,然后向不同的实例去写。这样是否能提高性能?很遗憾,非常有限,甚至可以说根本不能提高。为什么使用memcache的时候多开线程可以提高写入速度?那是因为内存数据交换的瓶颈我们没达到,而对于磁盘来说,IO的瓶颈每秒那么几十兆的是很容易达到的,一旦达到这个瓶颈了,无论是开多少个进程都无法提高性能了。还好Mongodb使用内存映射,看到内存使用的多了,其实我对它的信心又多了一点(内存占用多了我觉得CPU更容易让它不闲着),怕就怕某个DB不使用什么内存,看着IO瓶颈到了,内存和CPU还是吃不饱。

Memcache和Mongodb的配合

其实有了Memcache和Mongodb我们甚至可以让80%以上的应用摆脱传统关系型数据库。我能想到它们其实可以互相配合弥补对方的不足:

Memcache适合根据Key保存Value,那么有的时候我们并不知道需要读取哪些Key怎么办呢?我在想是不是可以把Mongodb或说数据库当作一个原始数据,这份原始数据中分为需要查询的字段(索引字段)和普通的数据字段两部分,把大量的非查询字段保存在Memcache中,小粒度保存,在查询的时候我们查询数据库知道要获取哪些数据,一般查询页面也就显示20-100条吧,然后一次性从Memcache中获取这些数据。也就是说,Mongodb的读的压力主要是索引字段,而数据字段只是在缓存失效的时候才有用,使用Memcache挡住大部分实质数据的查询。反过来说,如果我们要清空Memcache中的数据也知道要清空哪些Key。

时间: 2025-01-24 12:11:06

Memcache缓存与Mongodb数据库的优势和应用的相关文章

使用Memcache缓存mysql数据库操作的原理和缓存过程浅析_Mysql

对于大型网站如facebook,ebay等网站,如果没有Memcache做为中间缓存层,数据访问不可能吃得消,对于一般网站,只要具备独立的服务器,完全可以通过配置Memcache提高网站访问速度和减少数据库压力,这里主要讨论一下Memcache和MySQL数据库交互过程的流程关系,了解Memcache的中间缓存层作用,从而深入了解Memcache机制原理. Memcache和MySQL交互流程图 如上图,传统的查询方法是直接查询数据库,数据库将结果返回给查询语句,而当有Memcache中间缓存层

emlog中使用memcache缓存配置修改方法

这次只是简单的HACK emlog cache程序,使用memcache缓存,毕竟memcache缓存在内存, 文件缓存在硬盘(要看I/O的性能),一般来说内存的性能大于硬盘,所以一般来说memcache缓存优于文件缓存. memcache相对于文件缓存的优点: 1.读写性能优异,特别是高并发时和文件缓存比有明显优势. 2.memcached组建支持集群,并且是自动管理负载均衡 注意:memcache的原理是内存分块,单个item大于1M的数据存memcache和读取速度可能有点慢. 具体的情况

从源码角度理清memcache缓存服务

   memcache作为缓存服务器,用来提高性能,大部分互联网公司都在使用.     前言      文章的阅读的对象是中高级开发人员.系统架构师.      本篇文章,不是侧重对memcache的基础知识的总结,比如set,get之类的命令如何使用不会介绍.是考虑到,此类基础知识网络已经有一大把资料,所以更加倾向于深入性的知识点.文章侧重的重点是对memcache的原理理清楚.在实战中自己所遇到的坑.自己的思考心得与理解.    好记性不如烂笔头,整理文章的初衷是为了加深自己的理解,对知识进

php操作memcache缓存方法分享

  一般来说,如果并发量不大的情况,使不使用缓存技术并没有什么影响,但如果高并发的情况,使用缓存技术就显得很重要了,可以很好的减轻数据库和服务器的压力,当然解决高并发的技术有很多,这里只是以缓存的角度来说明使用memcache的便捷性和方便性, 使用memcache的前提是需要在服务端先配置好memcahche的环境!确认memcahce可以正常连接之后就可以在程序使用了! ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

Discuz!下Memcache缓存实现方法_php技巧

前言:在PHP+MySQL架构的站点中,本文重点从MySQL的角度去分析如何使Discuz!论坛(或者类似的PHP+MySQL架构的程序)应对大访问量.同时给出一些使用Memcache去减轻MySQL压力的建议.其中很多数据是个人测试的结果,如有不同意见,敬请留言告之.另外由于个人思维的问题,行文比较跳跃,特此声明! 系统分析:单纯的从MySQL的角度出发,单台MySQL的数据库负载到每天上亿次的操作(每秒大概1100次MySQL操作,然后乘以86400)应该不是非常困难的事情.按照这个数据也就

php实现memcache缓存示例讲解_php实例

概述 共享内存是一种在相同机器中的应用程序之间交换数据的有效方式.一个进程可创建一个可供其他进程访问的内存段,只要它分配了正确的权限.每个内存段拥有一个惟一的 ID(称为 shmid),这个 ID 指向一个物理内存区域,其他进程可在该区域操作它.创建并提供了合适的权限之后,同一台机器中的其他进程就可以操作这些内存段:读取.写入和删除. 这表明使用 C 语言编写的应用程序可与使用其他语言(比如 Java 或 PHP)编写的应用程序共享信息.它们都可以共享信息,只要它们可访问和理解该信息.共享内存在

用php实现memcache缓存实例详解

概述共享内存是一种在相同机器中的应用程序之间交换数据的有效方式.一个进程可创建一个可供其他进程访问的内存段,只要它分配了正确的权限.每个内存段拥有一个惟一的 ID(称为 shmid),这个 ID 指向一个物理内存区域,其他进程可在该区域操作它.创建并提供了合适的权限之后,同一台机器中的其他进程就可以操作这些内存段:读取.写入和删除. 这表明使用 C 语言编写的应用程序可与使用其他语言(比如 Java 或 PHP)编写的应用程序共享信息.它们都可以共享信息,只要它们可访问和理解该信息.共享内存在针

Discuz!的Memcache缓存实现配置方法

前言: 在PHP+MySQL架构的站点中,本文重点从MySQL的角度去分析如何使Discuz!论坛(或者类似的PHP+MySQL架构的程序)应对大访问量.同时给出一些使用Memcache去减轻MySQL压力的建议.其中很多数据是个人测试的结果,如有不同意见,敬请留言告之. 系统分析: 单纯的从MySQL的角度出发,单台MySQL的数据库负载到每天上亿次的操作(每秒大概1100次MySQL操作,然后乘以86400)应该不是非常困难的事情.按照这个数据也就是说一个单MySQL服务器的论坛来说可以跑到

MongoDB数据库高可用和分区解决方案

MongoDB是当前比较流行的文档型数据库,其拥有易使用.易扩展.功能丰富.性能卓越等特性.MongoDB本身就拥有高可用及分区的解决方案,分别为副本集(Replica Set)和分片(sharding),下面我们主要看这两个特性.   1.副本集   有人说MongoDB副本集至少需要三个节点,但其实这句是有问题的,因为副本集中节点最少可以是一台,3.0之前最多12个节点,3.0开始节点数量能够达到50个.但节点数1个或者2个的时候,MongoDB就无法发挥副本集特有的优势,因此我们一般建议节