数据存储，其实说的就是数据库，也就是在高并发的业务场景下，咱们的数据库如何架构设计。sql 知道有哪些数据库数据库 关系型数据库后端 是创建在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据，几句简单的SQL语句就能快速的实现小规模数据的读写、查询统计，对于程序猿来讲真是爽歪歪呀。缓存 MySQL安全 目前互联网企业基本都用它来作数据存储。愿意很简单，它是免费的，轻量级的，其余关系型数据库能作他他同样能作。用起来爽爽的。而且能基于Mycat的中间件的帮助，同样完成大规模数据的存储，知足高并发下的数据读写。关于MyCat，国内开源的项目，从它的版本更新计划，仍是有不少让人值得期待的地方。服务器 Oracle微信 应该说是最好的关系数据库，容量大，数据安全。好比金融行业，实时交易系统较多，在对数据的联机事务处理（OLTP）上也就要求很高。但作大规模的数据存储，扩展性很差且价格昂贵。网络 SQL Server数据结构 若是还有人在用SQL Server，说明这个企业的信息化水平很Low。SQL Server几乎没人在用了。架构 大数据 NoSQL数据库 也叫是“Not Only Sql”，指的是非关系型的数据库。这类数据库主要有这些特色：非关系型的、分布式、开源的、水平可扩展的。 memcached-临时性键值存储 是一个自由开源的，高性能，分布式内存对象缓存系统。数据所有放在内存中，在架构设计中使用memcached能减小对磁盘数据的读写操做。 好比能够提升用户对空节点数据查询的性能，页面上查不到数据，用户还在狂点，我不可能不停的查边系统中的每一个节点。须要对空节点数据进行缓存。 还有一个就是减小对数据库的读写，好比对查询命中率很高的可否作缓存。对写操做可否所队列缓存。人家是对象缓存系统，因此啥对象都 是能够放的。 Redis-永久性键值存储 Redis和memcached在功能上发挥的做用和使用场景基本是同样的。只是Redis更像是一个对象数据库，它不只作内存对象缓存，还能够作对象磁盘缓存。也就是最终的数据是被放到了磁盘上的。功能上比memcached要丰富一些，在企业中Redis用的更多一些。 MongoDB面向文档的数据库 轻量的分布式文件存储系统，MongoDB的功能很强大，在大规模数据的读写方面不亚于HBASE。MongoDB对数据的存储是透明的。如今通常企业经过MongoDB存一下非格式的文件，好比图片，视频，各类文件等。MongoDB在数据查询上比HBase方面，但在数据分析处理上不及HBase。 HBase面向列的数据库 面向列的新型的数据存储方式，这也是HBase在超大规模数据量中能毫秒级读写数据的缘由。超大的什么级别呢，“This project’s goal is the hosting of very large tables — billions of rows X millions of columns，billions of rows X millions of columns”一个表的数据能支持的数据结构是上亿行 乘以 百万列，这是HBase官方的描述。也就是说你一个HBase表没有上亿条数据，都对不起使用HBase。牛逼吧。哈哈。以前咱们卡弗卡大数据课堂的一个学生亲自测过，确实可能达到上亿行 乘以 百万列的这个结构。 虽然HBase的维护成本比较高，但在数据分析上妥妥的，由于他是基于HDFS的，跟MapReduce、Hive、spark等都能很好的整合，达到数据的计算分析。 大数据 关系型数据库特色 优势： 保持数据的一致性 能够进行复杂查询，操做简单。 通用而且技术成熟。 缺点: 数据读写必须通过sql解析，大量数据高并发下读写性能不足。 对数据作读写，或修改数据结构时须要加锁，影响并发操做。 没法适应非结构化存储。 扩展困难。 昂贵、复杂。 NoSQL数据库的特色 优势： 高并发，大数据下读写能力较强。 基本支持分布式，易于扩展，可伸缩。 简单，弱结构化存储。 缺点: 不能操做复杂的查询。 事务支持较弱。 大数据 理解分布式系统的CAP理论 前面咱们说了关系型数据库和NoSQL数据库的种类以及他们的特色。如何能很好的在实际项目中的合理的应用，咱们应该要了解CAP理论。 CAP的含义是Consistency, Availability, Partition-tolerance也就是一致性、可用性以及分区容错性。 Consistency：一致性（C） Availability：可用性（A） Partition tolerance：分区容错性（P） 一致性在多并发访问更新过的数据时，提供给用户的数据是否一致。对于关系型数据库，要求更新过的数据能被后续的访问都能看到，这是强一致性。若是能容忍后续的部分或者所有访问不到，则是弱一致性。若是通过一段时间后要求能访问到更新后的数据，则是最终一致性。 可用性某一节点的服务器挂了，集群总体还能响应客户端的读写请求。 分区容错性若是因为节点通信的问题不能达成数据一致性，必须在一致性和可用性中作出选择。 因此说任何分布式系统只可同时知足二点，无法三者兼顾。例如： CA应用：传统上的关系型数据库(RMDB). CP应用：基于HDFS的牛叉的HBase分布式数据库 AP应用：面向文档的分布式系统的数据库MongoDB。 那么咱们说CAP理论提出就是针对分布式数据库环境的，因此，P这个属性是必须具有的。P就是在分布式环境中，因为网络的问题可能致使某个节点和其它节点失去联系，节点之间互相没法知道对方的状态，这在分布式环境下是很是常见的。因此就造成了P(partition)。那么当P发生时，你要么考虑A（Availability），失去联系的节点依然能够向系统提供服务给客户端，只不过它的数据就不能保证是同步的了（失去了C（Consistency）属性），但至少服务及时作了响应。要么考虑C，选择一致性C（Consistency）为了保证数据库的一致性，咱们必须等待失去联系的节点恢复过来，在这个过程当中，那个节点是不容许对外提供服务的，这时候系统处于不可用状态(失去了A（Availability）属性)。 最多见的例子是读写分离，某个节点负责写入数据，而后将数据同步到其它节点，其它节点提供读取的服务，当两个节点出现通讯问题时，你就面临着选择A（继续提供服务，可是数据不保证准确）或者C（用户处于等待状态，一直等到数据同步完成）。 AP和CP该如何取舍呢？ 我以为能够根据不一样的业务场景作不一样的处理。CP对系统的一致性要求较高如ERP系统，OA系统。AP系统能够容许不一致。好比微博系统。 大数据 结论 懂得CAP理论，在实际业务需求中咱们能很好的来作数据的存储的架构设计。 因此，高并发下的大数据读写，尽量的交给NoSQL,HBase或者MongoDB数据库。虽然他们不能像关系型数据库那样很爽的让你查询，但他们确实彪悍。由于专业就是干这个的。对于强事务的数据操做，NoSQL数据库就不要跟人家抢。固然，MySQL不是很差，表数据超过500W，就不要像几十条数据那样的修改、删除。这时候应该考虑是否须要读写分离，从业务上是否须要考虑分割哪些数据常常修改，哪些数据会频繁被查询，是否有大量的数据写入，是否有大量随机的数据读取。 看似操做差很少，但在高并发的大数据面前，这些都是咱们须要慎重考虑的。 |
本文分享自微信公众号 - 互联网后端架构（fullstack888）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。