论数据的组织与存储
不同时间,人对数据的理解也不同。如何组织数据?用什么结构存储?
Stage 1
在最初的认识中,数据是以二维表形式组织的,比如:
学号 | 姓名 |
---|---|
101 | 亚索 |
102 | 盲僧 |
103 | 锐雯 |
104 | 锤石 |
105 | 炼金 |
Stage 2
接触数据库后,二维表正好能对应数据库的表,一个数据库中有多个表。 把二维表的行看成x,列看成y,那么数据库又多了一个维度z。
通过外键,表与表之间增加了约束,这样表之间就不是单独存在,而是相互依赖的了,字段之间建立起了联系,有利于数据引用的准确性。
这个阶段中,我在dms中大量使用了外键,例如log表的user_name字段的外键为 user表的 user_name字段,如下图所示:
Stage 3
sams也是用的传统的关系型数据库,但是在接触Json和面向对象的思想后,能感觉到关系型数据库的局限:
- 一方面,数据的联系是靠不同表的字段对应起来,一个relation就要涉及到两张表,对数据进行操作也要将两张表进行连接,有没有别的数据存储方法呢?
- 另一方面,数据的组织、提取要徒手写SQL语句,有其它简单的方法吗?(不可否认的是,标准SQL为不同的RDBMS提供了操作数据的统一接口)
对于后者的需求,ORM的出现解决了这个问题,它把数据转化为对象看待,在程序逻辑里操作对象就可以了,剩下的SQL语句由ORM代劳。
对于前者的需求,一种方案是面向文档的数据库,在关系型数据库中,键-值存储中“值”的部分,存储的是单纯的字符串;而面向文档的数据库“值”的部分是拥有结构的文档,文档的内容可以查询。典型代表如MongoDB。 还有一种方案是面向对象的数据库,它将面向对象语言中的对象直接进行永久保存。
Stage 4
在进入云计算时代后,数据库服务器成为了云计算系统的瓶颈,有很多场景只是需要通过键来获取值这样简单的操作,并不一定要动用RDB。
在这样的背景下,就出现了只管理键值对并将数据保存在内存中的缓存系统memcached。
数据库中的数据大多放在磁盘上,当对数据库进行查询时,操作开销很大,而memcached将查询结果缓存在内存中,这样可以提高性能。