数据库与存储系统[二] 数据库｜ 青训营

EricMoin
227 阅读7分钟

关系型数据库

关系是什么？

1970年，IBM的研究员，有“关系数据库之父”之称的Edgar Frank Codd在刊物《Communication of the ACM》上发表了题为“A Relational Model of Data for Large Shared Data banks（大型共享数据库的关系模型) 的论文，文中首次提出了数据库的关系模型的概念，奠定了关系模型的理论基础。20世纪70年代末，关系方法的理论研究和软件系统的研制均取得了很大成果，IBM公司的San Jose实验室在IBM370系列机上研制的关系数据库实验系统System R历时6年获得成功。1981年IBM公司又宣布了具有System R全部特征的新的数据库产品SQL/DS问世。由于关系模型简单明了、具有坚实的数学理论基础，所以一经推出就受到了学术界和产业界的高度重视和广泛响应，并很快成为数据库市场的主流。20世纪80年代以来，计算机厂商推出的数据库管理系统几乎都支持关系模型，数据库领域当前的研究工作大都以关系模型为基础。

  • 关系和关系模型：关系实际上就是关系模式在某一时刻的状态或内容。其最基本的组成要素是实体，关系和属性。也就是说，关系模式是型，关系是它的值。关系模式是静态的、稳定的，而关系是动态的、随时间不断变化的，因为关系操作在不断地更新着数据库中的数据。但在实际当中，常常把关系模式和关系统称为关系

  • 关系模型：用二维表的形式表示实体和实体间联系的数据模型

  • 换种角度理解：关系其实就是一种特殊的集合，其内是若干元素形成的若干有序偶对，反应了事物间对应的某种联系

  • 关系代数：对关系作运算的抽象语言（笛卡尔积，集合交并）

  • SQL(Structured Query Language)：一种DSL(Domain Specific Language)(领域专用语言)，方便人类阅读的关系代数表达形式

关系型数据库

  • 是一种存储系统，在拥有存储基本功能的同时，又扩展了其它能力

  • 特点

    • 结构化数据友好

    • 支持事务

    • 支持复杂的查询语言(SQL)

  • 结构化数据：也被称作行数据，是由二维表结构来逻辑表达和实现的数据，严格遵循数据格式和长度规范。我们平日里见的诸如表格，成绩单这些等等，都是很典型的结构化数据。与其相对应的自然是非结构化数据，这些数据不适用于结构化的保存，如PPT，商业报表，图片和视频等等，这些数据的保存都有属于自己的组织方式。

  • 关系型数据库对结构化数据的支持很好，甚至说，就是为了维护结构化数据而生

  • 事务：并发控制的单位，由用户定义的操作序列。可以更简单的理解为一次操作（如我要把大象放进冰箱里，这就是一个事务）

  • 在讲到事务时，就不得不提到事务的四个特点(ACID)

    • 原子性(Atomicity)：事务是数据库的逻辑工作单位，事务中包括的操作必须要么全做，要么不做。当我打开冰箱，这个事务就已经开始，不会出现把大象放进冰箱，突然不关冰箱门的这种骚操作。

    • 一致性(Consistency)：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性密切相关。如何理解？数据库增加一条数据，新状态和旧状态之间由事务紧密相关，如果撤回一件事务，那增加的一整条就消失，新状态就可以完美退回原来的状态，不会出现出弓没有回头箭的说法。

    • 隔离性(Islocation)：一个事务的执行不能被其它事务干扰。当数据量大的时候，数据库的事务执行往往采取并发形式，事务的执行之间互不干扰。当我把大象放进冰箱的过程中，不会因为我待会突然想要去吃饭，而放弃这个事务，因为是并发执行，我可以一只手开冰箱门，另一只手吃饭，而这两件事互不影响。事务之间一定互不干扰。

    • 永久性(Durability)：一个事务一旦提交，对数据库中数据的影响一定是永久性的。当我把大象放进冰箱的这件事务成功后，冰箱内一定存在一个我放进去的大象，而不是一个有或没有的叠加态。

非关系型数据库(NOSQL)

  • 也是一种存储系统，为了应对传统关系型数据库无法解决的难题而提出

  • 特点

    • 对半结构化数据友好

    • 可能支持事务

    • 可能支持复杂的查询语言(SQL)

    • 易扩展：因为去掉了数据之间的关系型特性，无关系的数据可以自由组合，无形中增加了数据库的扩展性，在架构层面更丰富多彩。

    • 大数据量，高性能：非关系型数据库的读写性能都非常之高，大数据量下表现优秀（本就是为了解决大数据量的问题）由于是记录型的Cache，粒度更细，性能相较于关系型数据库的Query Cache要高出许多。

    • 数据模型灵活：传统的关系型数据库需要对存储的数据建立字段，而NOSQL省去了这个步骤，可以存储自定义的数据格式，若是要增删字段，传统的数据库需要进行大量的操作，而没有字段的非关系型数据库自然省去了这一麻烦。

    • 可用性高：不影响性能的情况下可以轻松实现高可用的架构(Cassandra,HBase)，复制模型也能实现高可用性。

和传统存储方式的比较

  • 我们还是以一个经典的用户信息为例子：
{
    "user_name":"小明",
    "gender":"男",
    "age":18,
    "password":"Hello World!",
    "hint":"Coding"
}
  • 如果我们要用传统的存储方式，可能是新建一个类
class UserBean{
    String user_name;
    String gender;
    int age;
    String password;
    String hint;
}

  • 然后用相应的文件输入输出流以文件的形式保存

  • 数据量少时，这样不失为一种简易可行的办法，而当用户量一多，这样的访问量增大就会带来更多的麻烦：

    • 我是将所有的用户都保存在一个文件里，还是保存在多个文件里？

    • 可能需要遍历所有文件才能找到我想要的用户怎么办？

    • 每次遍历的时间太长，如何才能提高增删查改的效率？

    • 如果我后续需要增加别的属性，原来的用户文件不就无效了？又该如何在保存原来用户的情况下直接增加属性？

    • ...

  • 现实中遇到的问题可能要比想象的复杂得多，需求也会随着运营而不断多样化，这样简单地把用户保存到文件的办法对后续的维护无疑增加了天堑般的难度。

  • 如果使用关系型数据库管理以上的数据，自然不成问题。由于对性能的要求，数据库在实现时就采用了优秀的数据结构和算法设计(B+ Tree,B- Tree等)，大大减少了维护的难度，也提高了响应速度；对事务的支持也使得它在一次增删大量数据时表现得如鱼得水，不用担心无法退回到之前的状态；支持并发也使得性能大大提升。可以说，在数据库面前，传统的存储方式就是一个一秒就倒的弱鸡。

avatar
文章
阅读
粉丝