存储选型

技术选型是研发过程中一件重要的事，技术选型需要考虑多种因素，最重要的是首先搞清楚应用场景、业务场景这是根基，根基不稳可能后续很多决策都是错误的，做的越多会导致错的越多。

存储作为软件系统核心，是任何一个应用程序都离不开的，感兴趣同学可以思考反馈一下哪个程序离得开存储能够运行，我们可以探讨一下是否存在这么个程序。

在程序中应用的存储系统，我们应该有详尽的调研，深刻的理解以及简单的应用，是很好应用技术前提。

硬件基础，存储核心涉及cpu、IO、网络三个核心因素。硬件架构的发展方向是由追求单机主频转到追求多核研发方向，IO 磁盘由机械磁盘到SSD，速度在不断提升，网络由千兆网络到万兆网络以及飞速发展的无限网络。整个cpu多核发展方向网络的快速发展，就意味着未来发展方向是基于网络并行分布式存储，这会是未来潮流，抓住潮流才能使我们的学习以及应用事半功倍。基于对硬件的思考选择存储的演进方向。

上面的图是 jeff dean 说每个 程序员 都应了解的延迟数字，这样我们设计程序架构时，具体实现时才能有的放矢。要能够根据当下硬件处理能力进行合理设计而非基于想象。性能需要每一个设计实现细节整体考量，才能实现没有短板系统。

存储核心是数据结构，当下流行存储引擎有三种，他们是哈希存储引擎、B-树存储引擎、LSM存储引擎。作为存储数据结构有很高要求，既要能支撑很高的写能力又要支持超高读取能力。这是存储选型数据结构需要去思考得点。 哈希存储引擎，redis缓存和 Bitcask 属于这种， B-树 MySQL 数据库是这种存储引擎， LSM 分布式表格 HBase 是这种存储引擎。

从通用存储文件类型来说，包含 分布式文件系统、 分布式KV存储、 分布式表格存储、 分布式数据库，按照研发难易来说，分布式KV存储相对来说是简单的，但是使用场景是比较有限的。分布式数据库是最复杂的，使用上也是比较简单的，研发成本非常高，需要有持续稳定的投入以及相应的团队。

业务场景使我们选型场景核心的点，场景差异决定着存储选择方案，举个例子比如国民应用微信，微信朋友圈有7亿dau访问量巨大，但是业务特点是写少读多，比例1:6相当于我们可以针对性去设计存储架构，选取支持读取能力强存储，写相对弱系统。根据微信朋友圈，越是离现在近的数据越是读几率大，离现在越远数据读取几率越少，就可以将近的数据写入分布式缓存，远一些数据写入SSD类型存储，特别久远数据写入机械磁盘。这样既能满足性能要求，又能节省成本。

程序设计本质是平衡成本与性能，以及未来CPU由提高主频到提升多核性能、网络速度快速的发展，依据硬件发展并行分布式存储是未来发展方向。由大的选型来说一定是多级存储相结合，本地内存+分布式内存缓存（redis）+ SSD + 机械磁盘。有了大的原则，在取选取具体每一种相对更细节的问题，比如基于SSD存储是选择HBase还是RocksDB就是在具体一中类型中的选取。

存储自己研发还是开源？要看实际情况去慎重选择，尽量去选择开源，首先存储研发成本高、技术难度高、周期长，涉及理论众多，自研发需要团队有长时间没有产出的打算，当然如果团队有工程以及学习能力强的同学，这件事也不是不可为。开源的选择的化也不能直接随便就选择，一定要选择社区好，维护好，用户群体较大的，这样维护使用成本低，有了问题也容易去处理，并且要去深入去调研，存储是应用程序核心，使用一种就要深入调研，知其然知其所以然。

如果开源都不满足要求，那么自己研发就是一条必由之路，并且团队经过沟通后觉得也是一件必做不可得事。研发上相对对于应用来说有很多不同的地方，系统出问题后可能不能立即回滚，因为没有查到问题时，贸然处理数据可能会丢失，而数据是价值极大的，并且有些数据对用户来说极其珍贵的，这是一个巨大的难点。 需要对存储相关原理有深入认知，基于对原理认知来指导实践，相关概念非常多这是一个巨大挑战。 再有就是构建流程要包含严格详尽测试，单元测试、集成测试、测试人员测试、自动化测试等，通过严格测试来减少问题。

我们大部分应用都是数据密集型应用，设计一个优秀软件系统不是一件容易的事。需要对应用的技术以及业务有深刻认知，应用到的技术中存储是核心一环。《数据密集型应用系统设计》从原理上对存储进行深度探索与研究，豆瓣评分高达9.7，应该是每个程序员人手一本好书。《大规模分布式存储系统 原理解析与架构实战》从原理以及作者多年实践角度来详尽阐述分布式存储设计与实现，与前一本结合起来看，对于学习存储系统来说是事半功倍。

希望对大家能有点启发，你在实践中用过哪些存储，可以来分享一下。