DB演进理解

##DB演进理解

  1. RDBMS
    这是最熟悉的数据存储方式,一般情况下数据存储在一台机器上,这种形式方便提供完善ACID特性和丰富查询模型。这就是传统的关系型数据库的基础模式,但是面对现如今越来越大的数据量,这种模式的扩展变得难以满足。实践证明通过增加节点这种简单廉价的扩展方式是可行的。RDBMS的横向扩展主要有主从复制(Master-slave)、分表、分区等。
    横向扩展RDBMS – Master/Slave 
    利用数据库的复制或镜像功能,同时在多台数据库上保存相同的数据,从而将读操作和写操作分开,写操作集中在一台主数据库上,读操作集中在多台从数据库上。
    问题:
    读写同步需要一定的时间,导致关键的读取有出错风险;
    主节点将数据复制到从节点,数据量很大是可能造成问题,

    横向扩展RDBMS - Sharding
    在满足ACID特性的数据库中进行扩展是非常难的。基于这个原因,对数据进行扩展,这个数据库本身就必须拥有简单的模型,将数据分割为N片,然后在单独的片中执行查询。数据分割的单元被称为“shard”。将N片数据分配个M个DBMS进行操作。DBMS并不会去管理数据片,程序开发负责数据片的处理。 不同的分片方法有:

    • 垂直分区(Vertical Partitioning):将不需要进行联合查询的数据表分散到不同的数据库服务器上。
    • 水平分区(sharding) 将同一个表的记录拆分到不同的表甚至是服务器上,这往往需要一个稳定的算法来保证读取时能正确从不同的服务器上取得数据。如Range-Based Partitioning, Key or Hash-Based partitioning等。
      优点与不足
    • 对读取和写入都有很好的扩展
    • 不透明,程序需要识别分区 
    • 不再有跨分区的关系/joins 
    • 参照完整性损失

    其他RDBMS扩展方法
    Multi-Master replication:所有成员都响应客户端数据查询。多主复制系统负责将任意成员做出的数据更新传播给组内其他成员,并解决不同成员间并发修改可能带来的冲突。
    INSERT only, not UPDATES/DELETES:数据进行版本化处理。
    No JOINs, thereby reducing query time:Join的开销很大,而且频繁访问会使开销随着时间逐渐增加。
    非规范化(Denormalization)可以降低数据仓库的复杂性,以提高效率和改善性能。
    In-memory databases:磁盘数据库解决的是大容量存储和数据分析问题,内存数据库解决的是实时处理和高并发问题。主流常规的RDBMS更多的是磁盘密集型,而不是内存密集型。

    ACID Transactions
    一个完善的数据库系统都是希望支持“ACID transactions,”其包括:
    Atomic : Either the whole process is done or none is.(原子性)
    Consistent : Database constraints are preserved.(一致性)
    Isolated : It appears to the user as if only one process executes at a time.(隔离性)
    Durable : Effects of a process do not get lost if the system crashes.(持久性)

  2. NoSQL

NoSQL现在被理解为 Not Only SQL 的缩写,是对非关系型的数据库管理系统的统称 NoSQL 与 RDBMS 不同点,
-不使用SQL作为查询语言。
-不需要固定的表模式(table schema)。

  • 放宽一个或多个 ACID 属性(CAP定理)

补充:CAP理论
CAP理论是数据系统设计的基本理论,目前几乎所有的数据系统的设计都遵循了这个理论。CAP理论指出,分布式系统只能满足以下三项中的两项而不可能满足全部三项,
一致性(Consistency)(所有节点在同一时间具有相同的数据)
可用性(Availability)(保证每个请求不管成功或者失败都有响应)
分区容忍性(Partition tolerance)(系统中任意信息的丢失或失败不会影响系统的继续运作)

一致性有两种类型:

  • strong consistency – ACID(Atomicity Consistency Isolation Durability):对于关系型数据库,要求更新过的数据能被后续所有的访问都看到,这是强一致性。
  • weak consistency – BASE(Basically Available Soft-state Eventual consistency ) – Basically Available - system seems to work all the time (基本可用)
    – Soft State - it doesn’t have to be consistent all the time (不要求所有时间都一致)
    – Eventually Consistent - becomes consistent at some later time (最终一致性)

对于分布式数据系统(scale out),分区容忍性是基本要求,否则就失去了价值。因此只能在一致性和可用性上做取舍,如何处理这种取舍正是目前NoSQL数据库的核心焦点。牺牲一致性而换取高可用性。当然,牺牲一致性,只是不再要求关系数据库中的强一致性,而是只要系统能达到最终一致性即可。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的。

NoSQL 的两种主要实现方式
1.Key/Value
Amazon S3 (Dynamo)
Voldemort
Scalaris
Memcached (in-memory key/value store)
Redis

  1. 弱模式型(column-based, document-based or graph-based.)
    Cassandra (column-based)
    CouchDB (document-based)
    MongoDB(document-based)
    Neo4J (graph-based)
    HBase (column-based)

K/V模式
优点:
very fast
very scalable
simple model
able to distribute horizontally
劣势:
many data structures (objects) can’t be easily modeled as key value pairs (需要多余转换)
Schema-Less 模式
优点
Schema-less data model is richer than key/value pairs eventual consistency
many are distributed
still provide excellent performance and scalability
劣势
typically no ACID transactions or joins

  1. HBase

HBase is an open-source, distributed, column-oriented database built on top of HDFS (or KFS) based on BigTable! 
按照CAP理论,HBase属于C+P类型的系统。HBase是强一致性的(仅支持单行事务)。每一行由单个区域服务器(region server)host,行锁(row locks)和多版本并发控制(multiversion concurrency control)的组合被用来保证行的一致性。
查找:
快速定位使用row key + column family + column + timestamp.
按范围查找:start row key – end row key.
全表扫描
交互方式

  • Java, REST, or Thrift APIs.
  • Scripting via JRuby.

HBase 一些特性

- No real indexes(row key 即数据的索引)  
- Automatic partitioning(region自动split)  
- Scale linearly and automatically with new nodes(扩展容易 节点添加方便)  
- Commodity hardware(廉价硬件)  
- Fault tolerance(较强的容错性)  
- Batch processing(批处理能力优秀)  
  1. Hive

    • Provide higher-level language (HQL, like SQL) to facilitate large-data processing
    • Higher-level language “compiles down” to Hadoop Map/Reduce jobs
  2. Hive + HBase

    Reasons to use Hive on HBase:
    A lot of data sitting in HBase due to its usage in a real-time environment, but never used for analysis
    Give access to data in HBase usually only queried through MapReduce to people that don’t code (business analysts)
    When needing a more flexible storage solution, so that rows can be updated live by either a Hive job or an application and can be seen immediately to the other