背景
在目前所有的系统中，不管是何种架构都需要存储数据，常规的管理系统在两三年之后，数据往往是百万级别，甚至小千万级别的。涉及到制造业中的生产信息，运输业中的gps信息等每天会大批量产生的场景，往往数个月就会到达上亿级别的数据。这种数据又不是传统的大数据，几十TB甚至PB，这种中间层面的数据该怎么处理呢？有两点要求，一方面满足存储，一方面满足检索的能力。
解决方案
存储的问题，其实是很好解决的，存数据库，存各种fs，关键是怎么把数据从数据库中读取出来。
中间数据量快速检索
对于大几百万，小几千万的数据，这种量级的数据，通过索引就能做很大的优化。通过把查询的语句进行分析，建立对应的索引，让检索功能都尽量走索引，是一种很常规的解决方案。尤其是针对mysql这种关系型数据库，加上索引效果还是很明显的。这种策略的本质是空间换时间，因为索引的本质还是一种数据结构形成的文件，需要占用磁盘空间，通过空间换时间的方式来实现数据检索速度的提升。加了索引之后，需要提升你的sql水平，让你的sql走索引，避免全盘搜索的这种情况，从技术的角度就解决了很大一部门了。
套路性答案
往往遇到这种问题，第一个念头就是分库分表，这算是一个面试时候的标准答案了。怎么分表就成了一个学问。我常用的方案有两种，第一种是按照时间分表，比如每月一个表，然后检索时去每月的表中检索，缺点是如果跨月就很被动了，也就是所谓的水平切分；另一种策略是垂直切分，把一张表的不同字段拆分到不同的表中。
实战案例·策略表
实际工作中遇到一个交通行业的案例，车辆的物联网终端会发送gps定位信息到云平台，然后平台进行存储，对车载终端进行控制，管理。数据量的话，半年有个上亿数据，之前的架构是将数据存到mongodb里面，已经是按月分表了，哪怕如此，单表数据也会上亿。检索起来非常困难，经常超时，客户体验很差。针对这种情况，还是利用空间换时间的想法，基于现在的数据库基础，与业务结合，做一些改造。经过分析更多的是对日内数据的检索，以及对单终端的数据检索。基于这种特性，采用了一种数据三倍冗余的策略。一重冗余：已有的常规按月分表，将所有终端的数据进行，按月拆分，每个月一个大表，每个月的数据量可能在上亿，是已有策略的保留，也是一种最终的检索策略；第二重冗余，车月表，每个车辆终端每个月一张表，所有关于单车的查询逻辑，走车月表；第三重冗余，全车日表，每天存一张表，将一天的数据进行存储。
这样虽然数据产生了三倍冗余，但是所有的业务逻辑，有了专门的策略表，将旧数据，写个程序分流，就能直接上线这种策略。经验就是需要面对业务去设计表，纯粹的技术套路并不能适应所有场景。