数据库存储大体分为以下几类，有关系型（事务型）的数据库，以oracle、mysql为代表，有keyvalue数据库，以redis和memcached db为代表，有文档型数据库如mongodb，有列式分布式数据库以HBase，cassandra,dynamo为代表，还有其他的图形数据库、对象数据 库、xml数据库等。每种类型的数据库应用的业务领域是不一样的，下面从内存型、关系型、分布式三个维度针对相关的产品做性能可用性等方面的考量分析。
内存型的数据库，以高并发高性能为目标，在事务性方面没那么严格，以开源nosql数据库mongodb、redis为例
? Mongodb
通信方式
多线程方式，主线程监听新的连接，连接后，启动新的线程做数据的操作（IO切换）。
数据结构
数据库-->collection-->record
MongoDB在数据存储上按命名空间来划分，一个collection是一个命名空间，一个索引也是一个命名空间。
同一个命名空间的数据被分成很多个Extent，Extent之间使用双向链表连接。
在每一个Extent中，保存了具体每一行的数据，这些数据也是通过双向链接连接的。
每一行数据存储空间不仅包括数据占用空间，还可能包含一部分附加空间，这使得在数据update变大后可以不移动位置。
索引以BTree结构实现。
如果你开启了jorunaling日志，那么还会有一些文件存储着你所有的操作记录。
持久化存储
MMap方式把文件地址映射到内存的地址空间，直接操作内存地址空间就可以操作文件，不用再调用write,read操作，性能比较高。
mongodb调用mmap把磁盘中的数据映射到内存中的，所以必须有一个机制时刻的刷数据到硬盘才能保证可靠性，多久刷一次是与syncdelay参数相关的。
journal（进行恢复用）是Mongodb中的redo log，而Oplog则是负责复制的binlog。如果打开journal，那么即使断电也只会丢失100ms的数据，这对大多数应用来说都可以容忍了。从1.9.2+，mongodb都会默认打开journal功能，以确保数据安全。而且journal的刷新时间是可以改变的，2-300ms的范围,使用 --journalCommitInterval 命令。Oplog和数据刷新到磁盘的时间是60s，对于复制来说，不用等到oplog刷新磁盘，在内存中就可以直接复制到Sencondary节点。
事务支持
Mongodb只支持对单行记录的原子操作
HA集群
用的比较多的是Replica Sets，采用选举算法，自动进行leader选举，在保证可用性的同时，可以做到强一致性要求。
当然对于大量的数据，mongodb也提供了数据的切分架构Sharding。
? Redis
丰富的数据结构，高速的响应速度，内存操作
通信方式
因都在内存操作，所以逻辑的操作非常快，减少了CPU的切换开销，所以为单线程的模式（逻辑处理线程和主线程是一个）。
reactor模式，实现自己的多路复用NIO机制（epoll，select，kqueue等）
单线程处理多任务
数据结构
hash+bucket结构，当链表的长度过长时，会采取迁移的措施（扩展原来两倍的hash表，把数据迁移过去，expand+rehash）
持久化存储
a、全量持久化RDB（遍历redisDB,读取bucket中的key,value），save命令阻塞主线程，bgsave开启子进程进行snapshot持久化操作，生成rdb文件。
在shutdown时，会调用save操作
数据发生变化，在多少秒内触发一次bgsave
sync，master接受slave发出来的命令
b、增量持久化（aof类似redolog），先写到日志buffer,再flush到日志文件中（flush的策略可以配置的，而已单条，也可以批量），只有flush到文件上的，才真正返回客户端。
要定时对aof文件和rdb文件做合并操作（在快照过程中，变化的数据先写到aof buf中等子进程完成快照<内存snapshot>后，再进行合并aofbuf变化的部分以及全镜像数据）。
在高并发访问模式下，RDB模式使服务的性能指标出现明显的抖动，aof在性能开销上比RDB好，但是恢复时重新加载到内存的时间和数据量成正比。
集群HA
通用的解决方案是主从备份切换，采用HA软件，使得失效的主redis可以快速的切换到从redis上。主从数据的同步采用复制机制，该场景可以做读写分离。
目前在复制方面，存在的一个问题是在遇到网络不稳定的情况下，Slave和Master断开（包括闪断）会导致Master需要将内存中的数据全部重新生成rdb文件（快照文件），然后传输给Slave。Slave接收完Master传递过来的rdb文件以后会将自身的内存清空，把rdb文件重新加载到内存中。这种方式效率比较低下，在后面的未来版本Redis2.8作者已经实现了部分复制的功能。
关系型数据库在满足并发性能的同时，也需要满足事务性，以mysql数据库为例，讲述架构设计原理，在性能方面的考虑，以及如何满足可用性的需求。
? mysql的架构原理(innodb)
在架构上，mysql分为server层和存储引擎层。
Server层的架构对于不同的存储引擎来讲都是一样的,包括连接/线程处理、查询处理(parser、optimizer)以及其他系统任务。存储引擎层有很多种，mysql提供了存储引擎的插件式结构，支持多种存储引擎，用的最广泛的是innodb和myisamin；inodb主要面向OLTP方面的应用，支持事务处理，myisam不支持事务，表锁，对OLAP操作速度快。
以下主要针对innodb存储引擎做相关介绍。
在线程处理方面，Mysql是多线程的架构，由一个master线程，一个锁监控线程，一个错误监控线程，和多个IO线程组成。并且对一个连接会开启一个线程进行服务。io线程又分为节省随机IO的insert buffer，用于事务控制的类似于oracle的redo log，以及多个write，多个read的硬盘和内存交换的IO线程。
在内存分配方面，包括innodb buffer pool ，以及log buffer。其中innodb buffer pool包括insert buffer、datapage、index page、数据字典、自适应hash。Log buffer用于缓存事务日志，提供性能。
在数据结构方面，innodb包括表空间、段、区、页/块，行。索引结构是B+tree结构，包括二级索引和主键索引，二级索引的叶子节点是主键PK，根据主键索引的叶子节点指向存储的数据块。这种B+树存储结构可以更好的满足随机查询操作IO要求，分为数据页和二级索引页，修改二级索引页面涉及到随机操作，为了提高写入时的性能，采用insert buffer做顺序的写入，再由后台线程以一定频率将多个插入合并到二级索引页面。为了保证数据库的一致性(内存和硬盘数据文件)，以及缩短实例恢复的时间，关系型数据库还有一个checkpoint的功能，用于把内存buffer中之前的脏页按照比例(老的LSN)写入磁盘，这样redolog文件的LSN以前的日志就可以被覆盖了，进行循环使用；在失效恢复时，只需要从日志中LSN点进行恢复即可。
在事务特性支持上，关系型数据库需要满足ACID四个特性，需要根据不同的事务并发和数据可见性要求，定义了不同的事务隔离级别，并且离不开对资源争用的锁机制，要避免产生死锁，mysql在Server层和存储引擎层做并发控制，主要体现在读写锁，根据锁粒度不同，有各个级别的锁(表锁、行锁、页锁、MVCC)；基于提高并发性能的考虑，使用多版本并发控制MVCC来支持事务的隔离，并基于undo来实现，在做事务回滚时，也会用到undo段。mysql 用redolog来保证数据的写入的性能和失效恢复，在修改数据时只需要修改内存，再把修改行为记录到事务日志中(顺序IO)，不用每次将数据修改本身持久化到硬盘(随机IO)，大大提高性能。
在可靠性方面，innodb存储引擎提供了两次写机制double writer用于防止在flush页面到存储上出现的错误，解决磁盘half-writern的问题。
? 对于高并发高性能的mysql来讲，可以在多个维度进行性能方面的调优。
a、硬件级别，
日志和数据的存储，需要分开，日志是顺序的写，需要做raid1+0，并且用buffer-IO；数据是离散的读写，走direct IO即可，避免走文件系统cache带来的开销。
存储能力，SAS盘raid操作（raid卡缓存，关闭读cache，关闭磁盘cache，关闭预读，只用writeback buffer，不过需要考虑充放电的问题），当然如果数据规模不大，数据的存储可以用高速的设备，Fusion IO、SSD。
对于数据的写入，控制脏页刷新的频率，对于数据的读取，控制cache hit率；因此而估算系统需要的IOPS，评估需要的硬盘数量(fusion io上到IOPS 在10w以上，普通的硬盘150)。
Cpu方面，单实例关闭NUMA，mysql对多核的支持不是太好，可以对多实例进行CPU绑定。
b、操作系统级别，
内核以及socket的优化，网络优化bond、文件系统、IO调度
innodb主要用在OLTP类应用，一般都是IO密集型的应用，在提高IO能力的基础上，充分利用cache机制。需要考虑的内容有，
在保证系统可用内存的基础上，尽可能的扩大innodb buffer pool，一般设置为物理内存的3/4
文件系统的使用，只在记录事务日志的时候用文件系统的cache；尽量避免mysql用到swap(可以将vm.swappiness=0，内存紧张时，释放文件系统cache)
IO调度优化，减少不必要的阻塞，降低随机IO访问的延时(CFQ、Deadline、NOOP)
c、server以及存储引擎级别（连接管理、网络管理、table管理、日志）
包括cache/buffer、Connection、IO
d、应用级别（比如索引的考虑，schema的优化适当冗余；优化sql查询导致的CPU问题和内存问题，减少锁的范围，减少回表扫描，覆盖索引）
? 在高可用实践方面，
支持master-master、master-slave模式，master-master模式是一个作为主负责读写，另外一个作为standby提供灾备，maser-slave是一个作为主提供写操作，其他几个节点作为读操作，支持读写分离。
对于节点主备失效检测和切换，可以采用HA软件，当然也可以从更细粒度定制的角度，采用zookeeper作为集群的协调服务。
对于分布式的系统来讲，数据库主备切换的一致性始终是一个问题，可以有以下几种方式：
a、集群方式，如oracle的rack，缺点是比较复杂
b、共享SAN存储方式，相关的数据文件和日志文件都放在共享存储上，优点是主备切换时数据保持一致，不会丢失，但由于备机有一段时间的拉起，会有短暂的不可用状态
c、主备进行数据同步的方式，常见的是日志的同步，可以保障热备，实时性好，但是切换时，可能有部分数据没有同步过来，带来了数据的一致性问题。可以在操作主数据库的同时，记录操作日志，切换到备时，会和操作日志做个check，补齐未同步过来的数据；
d、还有一种做法是备库切换到主库的regolog的存储上，保证数据不丢失。
数据库主从复制的效率在mysql上不是太高，主要原因是事务是严格保持顺序的，索引mysql在复制方面包括日志IO和relog log两个过程都是单线程的串行操作，在数据复制优化方面，尽量减少IO的影响。不过到了Mysql5.6版本，可以支持在不同的库上的并行复制。
? 基于不同业务要求的存取方式
平台业务中，不同的业务有不同的存取要求，比如典型的两大业务用户和订单，用户一般来讲总量是可控的，而订单是不断地递增的，对于用户表首先采取分库切分，每个sharding做一主多读，同样对于订单因更多需求的是用户查询自己的订单，也需要按照用户进行切分订单库，并且支持一主多读。
在硬件存储方面，对于事务日志因是顺序写，闪存的优势比硬盘高不了多少，所以采取电池保护的写缓存的raid卡存储；对于数据文件，无论是对用户或者订单都会存在大量的随机读写操作，当然加大内存是一个方面，另外可以采用高速的IO设备闪存，比如PCIe卡 fusion-io。使用闪存也适合在单线程的负载中，比如主从复制，可以对从节点配置fusion-IO卡，降低复制的延迟。
对于订单业务来讲，量是不断递增的，PCIe卡存储容量比较有限，并且订单业务的热数据只有最近一段时间的(比如近3个月的)，对此这里列两种解决方案，一种是flashcache方式，采用基于闪存和硬盘存储的开源混合存储方式，在闪存中存储热点的数据。另外一种是可以定期把老的数据导出到分布式数据库HBase中，用户在查询订单列表是近期的数据从mysql中获取，老的数据可以从HBase中查询，当然需要HBase良好的rowkey设计以适应查询需求。
对 于数据的高并发的访问，传统的关系型数据库提供读写分离的方案，但是带来的确实数据的一致性问题提供的数据切分的方案；对于越来越多的海量数据，传统的数 据库采用的是分库分表，实现起来比较复杂，后期要不断的进行迁移维护；对于高可用和伸缩方面，传统数据采用的是主备、主从、多主的方案，但是本身扩展性比 较差，增加节点和宕机需要进行数据的迁移。对于以上提出的这些问题，分布式数据库HBase有一套完善的解决方案，适用于高并发海量数据存取的要求。
? HBase
基于列式的高效存储降低IO
通常的查询不需要一行的全部字段，大多数只需要几个字段
对与面向行的存储系统，每次查询都会全部数据取出，然后再从中选出需要的字段
面向列的存储系统可以单独查询某一列，从而大大降低IO
提高压缩效率
同列数据具有很高的相似性，会增加压缩效率
Hbase的很多特性，都是由列存储决定的
高性能
LSM Tree
适合高速写的场景
强一致的数据访问
MVCC
HBase的一致性数据访问是通过MVCC来实现的。
HBase在写数据的过程中，需要经过好几个阶段，写HLog，写memstore，更新MVCC;
只有更新了MVCC，才算真正memstore写成功，其中事务的隔离需要有mvcc的来控制，比如读数据不可以获取别的线程还未提交的数据。
高可靠
HBase的数据存储基于HDFS，提供了冗余机制。
Region节点的宕机，对于内存中的数据还未flush到文件中，提供了可靠的恢复机制。
可伸缩，自动切分，迁移
通过Zookeeper定位目标Region Server，最后定位Region。
Region Server扩容，通过将自身发布到Master，Master均匀分布。
可用性
存在单点故障，Region Server宕机后，短时间内该server维护的region无法访问，等待failover生效。
通过Master维护各Region Server健康状况和Region分布。
多个Master，Master宕机有zookeeper的paxos投票机制选取下一任Master。Master就算全宕机，也不影响Region读写。Master仅充当一个自动运维角色。
HDFS为分布式存储引擎，一备三，高可靠，0数据丢失。
HDFS的namenode是一个SPOF。
为避免单个region访问过于频繁，单机压力过大，提供了split机制
HBase的写入是LSM-TREE的架构方式，随着数据的append，HFile越来越多，HBase提供了HFile文件进行compact，对过期数据进行清除，提高查询的性能。
Schema free
HBase没有像关系型数据库那样的严格的schema，可以自由的增加和删除schema中的字段。
HBase分布式数据库，对于二级索引支持的不太好，目前只支持在rowkey上的索引，所以rowkey的设计对于查询的性能来讲非常关键。
统一的配置库
部署平台
大型分布式系统涉及各种设备，比如网络交换机，普通PC机， 各种型号的网卡，硬盘，内存等等，还有应用业务层次的监控，数量非常多的时候，出现错误的概率也会变大，并且有些监控的时效性要求比较高，有些达到秒级 别；在大量的数据流中需要过滤异常的数据，有时候也对数据会进行上下文相关的复杂计算，进而决定是否需要告警。因此监控平台的性能、吞吐量、已经可用性就 比较重要，需要规划统一的一体化的监控平台对系统进行各个层次的监控。
平台的数据分类
应用业务级别：应用事件、业务日志、审计日志、请求日志、异常、请求业务metrics、性能度量
系统级别：CPU、内存、网络、IO
时效性要求
阀值，告警：
实时计算：
近实时分钟计算
按小时、天的离线分析
实时查询
架构
节点中Agent代理可以接收日志、应用的事件以及通过探针的方式采集数据，agent采集数据的一个原则是和业务应用的流程是异步隔离的，不影响交易流程。
数据统一通过collector集群进行收集，按照数据的不同类型分发到不同的计算集群进行处理；有些数据时效性不是那么高，比如按小时进行统计，放入hadoop集群；有些数据是请求流转的跟踪数据，需要可以查询的，那么就可以放入solr集群进行索引；有些数据需要进行实时计算的进而告警的，需要放到storm集群中进行处理。
数据经过计算集群处理后，结果存储到Mysql或者HBase中。
监控的web应用可以把监控的实时结果推送到浏览器中，也可以提供API供结果的展现和搜索。
原文：http://www.cnblogs.com/ordili/p/6523210.html