一、数据多的时候为什么要使用redis而不用mysql？
通常来说，当数据多、并发量大的时候，架构中可以引入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详细了解参见我近期文章：https://www.toutiao.com/i6543810796214813187/ ）
读写异常快 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进行非持久化的存储，以供查询使用，是解决并发性能问题的其中一个手段
二、大数据分析的最佳分析模型，是"优化"，对吗
1.可视化分析
大数据分析的使用者有大数据分析专家，同时还有普通用户，但是他们二者对于大数据分析最基本的要求就是可视化分析，因为可视化分析能够直观的呈现大数据特点，同时能够非常容易被读者所接受，就如同看图说话一样简单明了。
2. 数据挖掘算法
大数据分析的理论核心就是数据挖掘算法，各种数据挖掘的算法基于不同的数据类型和格式才能更加科学的呈现出数据本身具备的特点，也正是因为这些被全世界统计 学家所公认的各种统计方法（可以称之为真理）才能深入数据内部，挖掘出公认的价值。另外一个方面也是因为有这些数据挖掘的算法才能更快速的处理大数据，如 果一个算法得花上好几年才能得出结论，那大数据的价值也就无从说起了。
3. 预测性分析
大数据分析最终要的应用领域之一就是预测性分析，从大数据中挖掘出特点，通过科学的建立模型，之后便可以通过模型带入新的数据，从而预测未来的数据。
4. 语义引擎
非结构化数据的多元化给数据分析带来新的挑战，我们需要一套工具系统的去分析，提炼数据。语义引擎需要设计到有足够的人工智能以足以从数据中主动地提取信息。
5.数据质量和数据管理。 大数据分析离不开数据质量和数据管理，高质量的数据和有效的数据管理，无论是在学术研究还是在商业应用领域，都能够保证分析结果的真实和有价值。
大数据分析的基础就是以上五个方面，当然更加深入大数据分析的话，还有很多很多更加有特点的、更加深入的、更加专业的大数据分析方法。
大数据的技术
数据采集： etl工具负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。
数据存取： 关系数据库、nosql、sql等。
基础架构： 云存储、分布式文件存储等。
数据处理： 自然语言处理(nlp，natural language processing)是研究人与计算机交互的语言问题的一门学科。处理自然语言的关键是要让计算机”理解”自然语言，所以自然语言处理又叫做自然语言理解也称为计算语言学。一方面它是语言信息处理的一个分支，另一方面它是人工智能的核心课题之一。
统计分析： 假设检验、显著性检验、差异分析、相关分析、t检验、 方差分析 、 卡方分析、偏相关分析、距离分析、回归分析、简单回归分析、多元回归分析、逐步回归、回归预测与残差分析、岭回归、logistic回归分析、曲线估计、 因子分析、聚类分析、主成分分析、因子分析、快速聚类法与聚类法、判别分析、对应分析、多元对应分析（最优尺度分析）、bootstrap技术等等。
数据挖掘： 分类 （classification）、估计（estimation）、预测（prediction）、相关性分组或关联规则（affinity grouping or association rules）、聚类（clustering）、描述和可视化、description and visualization）、复杂数据类型挖掘(text, web ,图形图像，视频，音频等)
模型预测 ：预测模型、机器学习、建模仿真。
结果呈现： 云计算、标签云、关系图等。
大数据的处理
1. 大数据处理之一：采集
大数据的采集是指利用多个数据库来接收发自客户端（web、app或者传感器形式等）的 数据，并且用户可以通过这些数据库来进行简单的查询和处理工作。比如，电商会使用传统的关系型数据库mysql和oracle等来存储每一笔事务数据，除 此之外，redis和mongodb这样的nosql数据库也常用于数据的采集。
在大数据的采集过程中，其主要特点和挑战是并发数高，因为同时有可能会有成千上万的用户 来进行访问和操作，比如火车票售票网站和淘宝，它们并发的访问量在峰值时达到上百万，所以需要在采集端部署大量数据库才能支撑。并且如何在这些数据库之间 进行负载均衡和分片的确是需要深入的思考和设计。
2. 大数据处理之二：导入/预处理
虽然采集端本身会有很多数据库，但是如果要对这些海量数据进行有效的分析，还是应该将这 些来自前端的数据导入到一个集中的大型分布式数据库，或者分布式存储集群，并且可以在导入基础上做一些简单的清洗和预处理工作。也有一些用户会在导入时使 用来自twitter的storm来对数据进行流式计算，来满足部分业务的实时计算需求。
导入与预处理过程的特点和挑战主要是导入的数据量大，每秒钟的导入量经常会达到百兆，甚至千兆级别。
3. 大数据处理之三：统计/分析
统计与分析主要利用分布式数据库，或者分布式计算集群来对存储于其内的海量数据进行普通 的分析和分类汇总等，以满足大多数常见的分析需求，在这方面，一些实时性需求会用到emc的greenplum、oracle的exadata，以及基于 mysql的列式存储infobright等，而一些批处理，或者基于半结构化数据的需求可以使用hadoop。
统计与分析这部分的主要特点和挑战是分析涉及的数据量大，其对系统资源，特别是i/o会有极大的占用。
4. 大数据处理之四：挖掘
与前面统计和分析过程不同的是，数据挖掘一般没有什么预先设定好的主题，主要是在现有数 据上面进行基于各种算法的计算，从而起到预测（predict）的效果，从而实现一些高级别数据分析的需求。比较典型算法有用于聚类的kmeans、用于 统计学习的svm和用于分类的naivebayes，主要使用的工具有hadoop的mahout等。该过程的特点和挑战主要是用于挖掘的算法很复杂，并 且计算涉及的数据量和计算量都很大，常用数据挖掘算法都以单线程为主。
整个大数据处理的普遍流程至少应该满足这四个方面的步骤，才能算得上是一个比较完整的大数据处理。
三、MySQL到底能支持多大的数据量(mysql多大数据量会影响性能)
mysql3.22限制的表大小为4gb。由于在mysql3.23中使用了myisam存储引擎，最大表尺寸增加到了65536tb（2567_1字节）。由于允许的表尺寸更大，mysql数据库的最大有效表尺寸通常是由操作系统对文件大小的限制决定的，而不是由mysql内部限制决定的。
innodb存储引擎将innodb表保存在一个表空间内，该表空间可由数个文件创建。这样，表的大小就能超过单独文件的最大容量。表空间可包括原始磁盘分区，从而使得很大的表成为可能。表空间的最大容量为64tb。
扩展资料
mysql数据库中，数据量越来越大的优化方案：
单表优化可以从这几个角度出发：
1、表分区
mysql在5.1之后才有的，可以看做是水平拆分，分区表需要在建表的需要加上分区参数，用户需要在建表的时候加上分区参数；分区表底层由多个物理子表组成，但是对于代码来说，分区表是透明的。
sql中的条件中最好能带上分区条件的列，这样可以定位到少量的分区上，否则就会扫描全部分区。
2、增加缓存
主要的思想就是减少对数据库的访问，缓存可以在整个架构中的很多地方；比如：数据库本身有就缓存，客户端缓存，数据库访问层对sql语句的缓存，应用程序内的缓存，第三方缓存（如redis等）。
