我们使用Elasticsearch存储的文档数量接近50亿（算上1份复制，接近100亿文档），总共10个数据节点和2个元数据节点（48GB内存，8核心CPU，ES使用内存达到70%），每天的文档增量大概是3000W条（速度持续增加中）。目前来看，单个文档的查询效率基本处于实时状态；对于1到2周的数据的聚合统计操作也可以在10秒之内返回结果。
创新互联公司是一家专注于成都网站设计、成都网站建设与策划设计,临淄网站建设哪家好?创新互联公司做网站,专注于网站建设10多年,网设计领域的专业建站公司;建站业务涵盖:临淄等地区。临淄做网站价格咨询:028-86922220
但是，还有提升的空间：
1. 对于查询单条数据的应用场景来说，我们可以使用ES的路由机制，将同一索引内的具有相同特征（比如具有相同的userid）的文档全部存储于一个节点上，这样我们之后的查询都可以直接定位到这个节点上，而不用将查询广播道所有的节点上；
2. 随着数据节点的增加，适当增加分片数量，提升系统的分布水平，也可以通过分而治之的方式优化查询性能；
个人以为Elasticsearch作为内部存储来说还是不错的，效率也基本能够满足，在某些方面替代传统DB也是可以的，前提是你的业务不对操作的事性务有特殊要求；而权限管理也不用那么细，因为ES的权限这块还不完善。由于我们对ES的应用场景仅仅是在于对某段时间内的数据聚合操作，没有大量的单文档请求（比如通过userid来找到一个用户的文档，类似于NoSQL的应用场景），所以能否替代NoSQL还需要各位自己的测试。如果让我选择的话，我会尝试使用ES来替代传统的NoSQL，因为它的横向扩展机制太方便了。
在我的工作过程中，我深切体会到：经验固然是一个很重要的东西，因为它能够帮助我们少走很多弯路，但同时也应该看到经验的另一面——它会变成一个笼子，将我们闭塞其中，使我们错过一些可能更好的解决方案，关键是我们要学会尝试，接触新的世界。
当为大家描述我们的整体服务架构时，最常见的两个问题是：
为什么采用结构化方式将数据存储在SQL数据库中，而不使用NoSQL平台？
为什么自己维护数据中心，而不将Evernote托管到云服务提供商？
这两个问题都很有趣，我们先来探讨第一个。
对特定的应用而言，相比一个单一的SQL实例，一个现代的键值存储引擎具备显著的性能优势和可扩展性。
CREATE TABLE notebooks ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, name varchar(100) COLLATE utf8_bin NOT NULL, ... ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE notes ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, notebook_id int UNSIGNED NOT NULL, title varchar(255) NOT NULL, ... FOREIGN KEY (notebook_id) REFERENCES notebooks(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
如果你在Windows客户端上创建了一个名为“Cooking”的记事本，并立即在其中粘贴了一个名为“Quick Tomato Sauce”的食谱，客户端会立刻进行如下同步：
调用NoteStore.createNotebook() 请求服务器创建记事本，并返回以创建记事本的GUID。
通过指定记事本的GUID，调用NoteStore.createNote()在记事本中创建笔记。
每次API调用都通过SQL事物予以实现，可以让客户端完全信任服务器的任何提示。ACID兼容的数据库可以做到这些：
原子性（Atomicity）：如果API调用成功，那么所有的改动都会保存；如果API调用失败，所有的改动都不会提交。
一致性（Consistency）： 在API调用完成后，所有的账户都可用，并能保证内部状态的一致性。每篇笔记都与记事本相关联，以避免出现孤立项。数据库不允许删除关联有记事的记事本，这得感谢FOREIGN KEY约束。
持久性（Durability）：当服务器发送记事本已创建完毕的回执后，客户端会认为它的存在具有持久性，以便进行后续的操作。变更的持久性，可以让客户端知道在任何时刻对服务状态的影响都能保持一致性。
对我们的同步协议而言，持久性最为重要。如果客户端不能确定服务器端的变更具有持久性，那么协议将会变得复杂而低效。
“大数据”问题
得益于事务处理的数据库的ACID属性，同样使得数据集非常难以扩展，以超出单台服务器的范围。数据库集群和多主复制技术并不理想，键值存储为实现可扩展性提供了一条捷径。
所幸，Evernote暂时不需要考虑这个问题。即便是我们有近10亿的笔记，和近20亿的资源文件，这也并不能称得上是一个大数据集。通过按用户分区，它被划分成了2千万个独立的数据集。
我们尚未遇到所谓“大数据”引发的问题，倒是遇到了许多“中数据”的存储问题，这就是通过规整分区形成的分片存储架构。
也许以后……
我们对新的存储系统非常感兴趣，非常乐意应用在哪些对ACID要求不强，但确实需要横向扩展的新项目中。例如，我们的报告分析系统已经逐渐超出了MySQL平台的承受力，需要被更快、更先进的系统所取代。
我们现在对以Evernote用户元数据为基础的MySQL分片存储颇为满意，尽管这不会引起那些IT弄潮儿的兴趣。
通常来说，当数据多、并发量大的时候，架构中可以引入Redis，帮助提升架构的整体性能，减少Mysql(或其他数据库)的压力，但不是使用Redis，就不用MySQL。
因为Redis的性能十分优越，可以支持每秒十几万此的读/写操作，并且它还支持持久化、集群部署、分布式、主从同步等，Redis在高并发的场景下数据的安全和一致性，所以它经常用于两个场景：
缓存
判断数据是否适合缓存到Redis中，可以从几个方面考虑： 会经常查询么？命中率如何？写操作多么？数据大小？
我们经常采用这样的方式将数据刷到Redis中：查询的请求过来，现在Redis中查询，如果查询不到，就查询数据库拿到数据，再放到缓存中，这样第二次相同的查询请求过来，就可以直接在Redis中拿到数据；不过要注意【缓存穿透】的问题。
缓存的刷新会比较复杂，通常是修改完数据库之后，还需要对Redis中的数据进行操作；代码很简单，但是需要保证这两步为同一事务，或最终的事务一致性。
高速读写
常见的就是计数器，比如一篇文章的阅读量，不可能每一次阅读就在数据库里面update一次。
高并发的场景很适合使用Redis，比如双11秒杀，库存一共就一千件，到了秒杀的时间，通常会在极为短暂的时间内，有数万级的请求达到服务器，如果使用数据库的话，很可能在这一瞬间造成数据库的崩溃，所以通常会使用Redis（秒杀的场景会比较复杂，Redis只是其中之一，例如如果请求超过某个数量的时候，多余的请求就会被限流）。
这种高并发的场景，是当请求达到服务器的时候，直接在Redis上读写，请求不会访问到数据库；程序会在合适的时间，比如一千件库存都被秒杀，再将数据批量写到数据库中。
所以通常来说，在必要的时候引入Redis，可以减少MySQL（或其他）数据库的压力，两者不是替代的关系 。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
Redis和MySQL的应用场景是不同的。
通常来说，没有说用Redis就不用MySQL的这种情况。
因为Redis是一种非关系型数据库（NoSQL），而MySQL是一种关系型数据库。
和Redis同类的数据库还有MongoDB和Memchache（其实并没有持久化数据）
那关系型数据库现在常用的一般有MySQL，SQL Server，Oracle。
我们先来了解一下关系型数据库和非关系型数据库的区别吧。
1.存储方式
关系型数据库是表格式的，因此存储在表的行和列中。他们之间很容易关联协作存储，提取数据很方便。而Nosql数据库则与其相反，他是大块的组合在一起。通常存储在数据集中，就像文档、键值对或者图结构。
2.存储结构
关系型数据库对应的是结构化数据，数据表都预先定义了结构（列的定义），结构描述了数据的形式和内容。这一点对数据建模至关重要，虽然预定义结构带来了可靠性和稳定性，但是修改这些数据比较困难。而Nosql数据库基于动态结构，使用与非结构化数据。因为Nosql数据库是动态结构，可以很容易适应数据类型和结构的变化。
3.存储规范
关系型数据库的数据存储为了更高的规范性，把数据分割为最小的关系表以避免重复，获得精简的空间利用。虽然管理起来很清晰，但是单个操作设计到多张表的时候，数据管理就显得有点麻烦。而Nosql数据存储在平面数据集中，数据经常可能会重复。单个数据库很少被分隔开，而是存储成了一个整体，这样整块数据更加便于读写
4.存储扩展
这可能是两者之间最大的区别，关系型数据库是纵向扩展，也就是说想要提高处理能力，要使用速度更快的计算机。因为数据存储在关系表中，操作的性能瓶颈可能涉及到多个表，需要通过提升计算机性能来克服。虽然有很大的扩展空间，但是最终会达到纵向扩展的上限。而Nosql数据库是横向扩展的，它的存储天然就是分布式的，可以通过给资源池添加更多的普通数据库服务器来分担负载。
5.查询方式
关系型数据库通过结构化查询语言来操作数据库（就是我们通常说的SQL）。SQL支持数据库CURD操作的功能非常强大，是业界的标准用法。而Nosql查询以块为单元操作数据，使用的是非结构化查询语言（UnQl），它是没有标准的。关系型数据库表中主键的概念对应Nosql中存储文档的ID。关系型数据库使用预定义优化方式（比如索引）来加快查询操作，而Nosql更简单更精确的数据访问模式。
6.事务
关系型数据库遵循ACID规则（原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)），而Nosql数据库遵循BASE原则（基本可用（Basically Availble）、软/柔性事务（Soft-state ）、最终一致性（Eventual Consistency））。由于关系型数据库的数据强一致性，所以对事务的支持很好。关系型数据库支持对事务原子性细粒度控制，并且易于回滚事务。而Nosql数据库是在CAP（一致性、可用性、分区容忍度）中任选两项，因为基于节点的分布式系统中，很难全部满足，所以对事务的支持不是很好，虽然也可以使用事务，但是并不是Nosql的闪光点。
7.性能
关系型数据库为了维护数据的一致性付出了巨大的代价，读写性能比较差。在面对高并发读写性能非常差，面对海量数据的时候效率非常低。而Nosql存储的格式都是key-value类型的，并且存储在内存中，非常容易存储，而且对于数据的 一致性是 弱要求。Nosql无需sql的解析，提高了读写性能。
8.授权方式
大多数的关系型数据库都是付费的并且价格昂贵，成本较大（MySQL是开源的，所以应用的场景最多），而Nosql数据库通常都是开源的。
所以，在实际的应用环境中，我们一般会使用MySQL存储我们的业务过程中的数据，因为这些数据之间的关系比较复杂，我们常常会需要在查询一个表的数据时候，将其他关系表的数据查询出来，例如，查询某个用户的订单，那至少是需要用户表和订单表的数据。
查询某个商品的销售数据，那可能就会需要用户表，订单表，订单明细表，商品表等等。
而在这样的使用场景中，我们使用Redis来存储的话，也就是KeyValue形式存储的话，其实并不能满足我们的需要。
即使Redis的读取效率再高，我们也没法用。
但，对于某些没有关联少，且需要高频率读写，我们使用Redis就能够很好的提高整个体统的并发能力。
例如商品的库存信息，我们虽然在MySQL中会有这样的字段，但是我们并不想MySQL的数据库被高频的读写，因为使用这样会导致我的商品表或者库存表IO非常高，从而影响整个体统的效率。
所以，对于这样的数据，且有没有什么复杂逻辑关系（就只是隶属于SKU）的数据，我们就可以放在Redis里面，下单直接在Redis中减掉库存，这样，我们的订单的并发能力就能够提高了。
个人觉得应该站出来更正一下，相反的数据量大，更不应该用redis。
为什么？
因为redis是内存型数据库啊，是放在内存里的。
设想一下，假如你的电脑100G的资料，都用redis来存储，那么你需要100G以上的内存！
使用场景
Redis最明显的用例之一是将其用作缓存。只是保存热数据，或者具有过期的cache。
例如facebook，使用Memcached来作为其会话缓存。
总之，没有见过哪个大公司数据量大了，换掉mysql用redis的。
题主你错了，不是用redis代替MySQL，而是引入redis来优化。
BAT里越来越多的项目组已经采用了redis+MySQL的架构来开发平台工具。
如题主所说，当数据多的时候，MySQL的查询效率会大打折扣。我们通常默认如果查询的字段包含索引的话，返回是毫秒级别的。但是在实际工作中，我曾经遇到过一张包含10个字段的表，1800万+条数据，当某种场景下，我们不得不根据一个未加索引的字段进行精确查询的时候，单条sql语句的执行时长有时能够达到2min以上，就更别提如果用like这种模糊查询的话，其效率将会多么低下。
我们最开始是希望能够通过增加索引的方式解决，但是面对千万级别的数据量，我们也不敢贸然加索引，因为一旦数据库hang住，期间的所有数据库写入请求都会被放到等待队列中，如果请求是通过http请求发过来的，很有可能导致服务发生分钟级别的超时不响应。
经过一番调研，最终敲定的解决方案是引入redis作为缓存。redis具有运行效率高，数据查询速度快，支持多种存储类型以及事务等优势，我们把经常读取，而不经常改动的数据放入redis中，服务器读取这类数据的时候时候，直接与redis通信，极大的缓解了MySQL的压力。
然而，我在上面也说了，是redis+MySQL结合的方式，而不是替代。原因就是redis虽然读写很快，但是不适合做数据持久层，主要原因是使用redis做数据落盘是要以效率作为代价的，即每隔制定的时间，redis就要去进行数据备份/落盘，这对于单线程的它来说，势必会因“分心”而影响效率，结果得不偿失。
楼主你好，首先纠正下，数据多并不是一定就用Redis，Redis归属于NoSQL数据库中，其特点拥有高性能读写数据速度，主要解决业务效率瓶颈。下面就详细说下Redis的相比MySQL优点。（ 关于Redis详细了解参见我近期文章： ）
读写异常快
Redis非常快，每秒可执行大约10万次的读写速度。
丰富的数据类型
Redis支持丰富的数据类型，有二进制字符串、列表、集合、排序集和散列等等。这使得Redis很容易被用来解决各种问题，因为我们知道哪些问题可以更好使用地哪些数据类型来处理解决。
原子性
Redis的所有操作都是原子操作，这确保如果两个客户端并发访问，Redis服务器能接收更新的值。
丰富实用工具 支持异机主从复制
Redis支持主从复制的配置，它可以实现主服务器的完全拷贝。
以上为开发者青睐Redis的主要几个可取之处。但是，请注意实际生产环境中企业都是结合Redis和MySQL的特定进行不同应用场景的取舍。 如缓存——热数据、计数器、消息队列（与ActiveMQ，RocketMQ等工具类似）、位操作（大数据处理）、分布式锁与单线程机制、最新列表（如新闻列表页面最新的新闻列表）以及排行榜等等 可以看见Redis大显身手的场景。可是对于严谨的数据准确度和复杂的关系型应用MySQL等关系型数据库依然不可替。
web应用中一般采用MySQL+Redis的方式，web应用每次先访问Redis，如果没有找到数据，才去访问MySQL。
本质区别
1、mysql：数据放在磁盘 redis：数据放在内存。
首先要知道mysql存储在磁盘里，redis存储在内存里，redis既可以用来做持久存储，也可以做缓存，而目前大多数公司的存储都是mysql + redis，mysql作为主存储，redis作为辅助存储被用作缓存，加快访问读取的速度，提高性能。
使用场景区别
1、mysql支持sql查询，可以实现一些关联的查询以及统计；
2、redis对内存要求比较高，在有限的条件下不能把所有数据都放在redis；
3、mysql偏向于存数据，redis偏向于快速取数据，但redis查询复杂的表关系时不如mysql，所以可以把热门的数据放redis，mysql存基本数据。
mysql的运行机制
mysql作为持久化存储的关系型数据库，相对薄弱的地方在于每次请求访问数据库时，都存在着I/O操作，如果反复频繁的访问数据库。第一：会在反复链接数据库上花费大量时间，从而导致运行效率过慢；第二：反复地访问数据库也会导致数据库的负载过高，那么此时缓存的概念就衍生了出来。
Redis持久化
由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。
redis是放在内存的~！
数据量多少绝对不是选择redis和mysql的准则，因为无论是mysql和redis都可以集群扩展，约束它们的只是硬件(即你有没有那么多钱搭建上千个组成的集群)，我个人觉得数据读取的快慢可能是选择的标准之一，另外工作中往往是两者同是使用，因为mysql存储在硬盘，做持久化存储，而redis存储在内存中做缓存提升效率。
关系型数据库是必不可少的，因为只有关系型数据库才能提供给你各种各样的查询方式。如果有一系列的数据会频繁的查询，那么就用redis进行非持久化的存储，以供查询使用，是解决并发性能问题的其中一个手段
NoSQL，指的是非关系型的数据库。NoSQL有时也称作Not Only SQL的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称。
NoSQL用于超大规模数据的存储。（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
NoSQL的优点/缺点
优点:
- 高可扩展性
- 分布式计算
- 低成本
- 架构的灵活性，半结构化数据
- 没有复杂的关系
缺点:
- 没有标准化
- 有限的查询功能（到目前为止）
- 最终一致是不直观的程序 （BY三人行慕课）
sql是对数据传输和存储的格式化，NOSQL是对数据使用时候格式化或者其他可以不用sql的应用。
如果你对一个学生资料进行统计排序等操作，nosql肯定效率低下。
NoSQL薄弱的安全性会给企业带来负面影响 。Imperva公司创始人兼CTO Amichai Shulman如是说。在新的一年中，无疑会有更多企业开始或筹划部署NoSQL。方案落实后就会逐渐发现种种安全问题，因此早做准备才是正确的选择。 作为传统关系型数据库的替代方案，NoSQL在查询中并不使用SQL语言，而且允许用户随时变更数据属性。此类数据库以扩展性良好著称，并能够在需要大量应用程序与数据库本身进行实时交互的交易处理任务中发挥性能优势，Couchbase创始人兼产品部门高级副总裁James Phillips解释称：NoSQL以交易业务为核心。它更注重实时处理能力并且擅长直接对数据进行操作，大幅度促进了交互型软件系统的发展。Phillips指出。其中最大的优势之一是能够随时改变(在属性方面)，由于结构性的弱化，修改过程非常便捷。 NoSQL最大优势影响其安全性 NoSQL的关键性特色之一是其动态的数据模型，Shulman解释道。我可以在其运作过程中加入新的属性记录。因此与这种结构相匹配的安全模型必须具备一定的前瞻性规划。也就是说，它必须能够了解数据库引入的新属性将引发哪些改变，以及新加入的属性拥有哪些权限。然而这个层面上的安全概念目前尚不存在，根本没有这样的解决方案。 根据Phillips的说法，某些NoSQL开发商已经开始着手研发安全机制，至少在尝试保护数据的完整性。在关系型数据库领域，如果我们的数据组成不正确，那么它将无法与结构并行运作，换言之数据插入操作整体将宣告失败。目前各种验证规则与完整性检查已经比较完善，而事实证明这些验证机制都能在NoSQL中发挥作用。我们与其他人所推出的解决方案类似，都会在插入一条新记录或是文档型规则时触发，并在执行过程中确保插入数据的正确性。 Shulman预计新用户很快将在配置方面捅出大娄子，这并非因为IT工作人员的玩忽职守，实际上主要原因是NoSQL作为一项新技术导致大多数人对其缺乏足够的知识基础。Application Security研发部门TeamSHATTER的经理Alex Rothacker对上述观点表示赞同。他指出，培训的一大问题在于，大多数NoSQL的从业者往往属于新生代IT人士，他们对于技术了解较多，但往往缺乏足够的安全管理经验。 如果他们从传统关系型数据库入手，那么由于强制性安全机制的完备，他们可以在使用中学习。但NoSQL，只有行家才能通过观察得出正确结论，并在大量研究工作后找到一套完备的安全解决方案。因此可能有90%的从业者由于知识储备、安全经验或是工作时间的局限而无法做到这一点。 NoSQL需在安全性方面进行优化 尽管Phillips认同新技术与旧经验之间存在差异，但企业在推广NoSQL时加大对安全性的关注会起到很大程度的积极作用。他认为此类数据存储机制与传统关系类数据库相比，其中包含着的敏感类信息更少，而且与企业网络内部其它应用程序的接触机会也小得多。 他们并不把这项新技术完全当成数据库使用，正如我们在收集整理大量来自其它应用程序的业务类数据时，往往也会考虑将其作为企业数据存储机制一样，他补充道。当然，如果我打算研发一套具备某种特定功能的社交网络、社交游戏或是某种特殊web应用程序，也很可能会将其部署于防火墙之下。这样一来它不仅与应用程序紧密结合，也不会被企业中的其它部门所触及。 但Rothacker同时表示，这种过度依赖周边安全机制的数据库系统也存在着极其危险的漏洞。一旦系统完全依附于周边安全模型，那么验证机制就必须相对薄弱，而且缺乏多用户管理及数据访问方面的安全保护。只要拥有高权限账户，我们几乎能访问存储机制中的一切数据。举例来说，Brian Sullivan就在去年的黑帽大会上演示了如何在完全不清楚数据具体内容的情况下，将其信息罗列出来甚至导出。 而根据nCircle公司CTO Tim ‘TK’ Keanini的观点，即使是与有限的应用程序相关联，NoSQL也很有可能被暴露在互联网上。在缺少严密网络划分的情况下，它可能成为攻击者窥探存储数据的薄弱环节。因为NoSQL在设计上主要用于互联网规模的部署，所以它很可能被直接连接到互联网中，进而面临大量攻击行为。 其中发生机率最高的攻击行为就是注入式攻击，这也是一直以来肆虐于关系类数据库领域的头号公敌。尽管NoSQL没有将SQL作为查询语言，也并不代表它能够免受注入式攻击的威胁。虽然不少人宣称SQL注入在NoSQL这边不起作用，但其中的原理是完全一致的。攻击者需要做的只是改变自己注入内容的语法形式，Rothacker解释称。也就是说虽然SQL注入不会出现，但JavaScript注入或者JSON注入同样能威胁安全。 此外，攻击者在筹划对这类数据库展开侵袭时，也很可能进一步优化自己的工具。不成熟的安全技术往往带来这样的窘境：需要花费大量时间学习如何保障其安全，但几乎每个IT人士都能迅速掌握攻击活动的组织方法。因此我认为攻击者将会始终走在安全部署的前面，Shulman说道。遗憾的是搞破坏总比防范工作更容易，而我们已经看到不少NoSQL技术方面的公开漏洞，尤其是目前引起热议的、以JSON注入为载体的攻击方式。 NoSQL安全性并非其阻碍 然而，这一切都不应该成为企业使用NoSQL的阻碍，他总结道。我认为归根结底，这应该算是企业的一种商业决策。只要这种选择能够带来吸引力巨大的商业机遇，就要承担一定风险，Shulman解释道。但应该采取一定措施以尽量弱化这种风险。 举例来说，鉴于数据库对外部安全机制的依赖性，Rothacker建议企业积极考虑引入加密方案。他警告称，企业必须对与NoSQL相对接的应用程序代码仔细检查。换言之，企业必须严格挑选负责此类项目部署的人选，确保将最好的人才用于这方面事务，Shulman表示。当大家以NoSQL为基础编写应用程序时，必须启用有经验的编程人员，因为客户端软件是抵挡安全问题的第一道屏障。切实为额外缓冲区的部署留出时间与预算，这能够让员工有闲暇反思自己的工作内容并尽量多顾及安全考量多想一点就是进步。综上所述，这可能与部署传统的关系类数据库也没什么不同。 具有讽刺意味的是，近年来数据库应用程序在安全性方面的提升基本都跟数据库本身没什么关系，nCircle公司安全研究及开发部门总监Oliver Lavery如是说。
