linux中的数据库是用来记录什么的？

数据库是用来记录大量数据，比如你从能百度上搜到各种各样的东西，这些东西在百度的服务器上，就是以数据库的形式记录的。excel和它不是一个功能方向的东西。excel的作用不是做表格、写简历，而是进行数据分析和运算，只不过看上去它表现得像个大表格而已。office套件里作为数据库存在的是access，只不过access作为桌面数据库，引擎不太强大，数据量大了以后会变慢，它只是为了方便办公而设计的，像你说的mysql、oracle这些都是商业数据库，可以存储亿万条数据并且可以迅速查询。

日志文件系统（journaling file systems）可防止系统崩溃时导致的数据不一致问题。对文件系统元数据（metadata）的更改都被保存在一份单独的日志里，当发生系统崩溃时可以根据日志正确地恢复数据。除此之外，日志使系统重新启动时不必进行文件系统的检查，从而缩短了恢复时间。

所以说元数据就是数据的数据。

任何文件系统中的数据分为数据和元数据。数据是指普通文件中的实际数据，而元

数据指用来描述一个文件的特征的系统数据，诸如访问权限、文件拥有者以及文件数据

块的分布信息(inode...)等等。在集群文件系统中，分布信息包括文件在磁盘上的位置以及磁盘在集群中的位置。用户需要 *** 作一个文件必须首先得到它的元数据，才能定位到文件的位置并且得到文件的内容或相关属性。

2． 元数据管理方式

元数据管理有两种方式。集中式管理和分布式管理。集中式管理是指在系统中有一个节点专门司职元数据管理，所有元数据都存储在该节点的存储设备上。所有客户端对文件的请求前，都要先对该元数据管理器请求元数据。分布式管理是指将元数据存放在系统的任意节点并且能动态的迁移。对元数据管理的职责也分布到各个不同的节点上。大多数集群文件系统都采用集中式的元数据管理。因为集中式管理实现简单，一致性维护容易，在一定的 *** 作频繁度内可以提供较满意的性能。缺点是单一失效点问题，若该服务器失效，整个系统将无法正常工作。而且，当对元数据的 *** 作过于频繁时，集中的元数据管理成为整个系统的性能瓶颈。

分布式元数据管理的好处是解决了集中式管理的单一失效点问题，而且性能不会随着 *** 作频繁而出现瓶颈。其缺点是，实现复杂，一致性维护复杂，对性能有一定影响。

数据持久化顾名思义就是把程序中的数据以某种形式保存到某存贮介质中，以达到持久化的目的。当程序运行时，一些数据是临时保存在内存中，一旦退出系统，这些数据就丢失了。那么，使用某种手段将数据保存在硬盘上或者数据库中，这样即使退出系统后又重新启动系统，那么这些数据仍然可以重新找回来。

例如管理员向一个用户管理系统中添加了一个用户的资料，那么这个系统需要将新添加的资料保存到数据库中，否则系统退出或者电脑重启后该用户资料就会丢失。将数据从内存保存到数据库中，这便是数据的持久化。当然，数据库只是持久化方式中的一种，也可以保存在其他的永久存贮介质中。

图为数据持久化的过程示意图。

持久化（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、XML数据文件中等等。

持久化是将程序数据在持久状态和瞬时状态间转换的机制。

DBC就是一种持久化机制。文件IO也是一种持久化机制。

日常持久化的方法

在一定周期内保持不变就是持久化,持久化是针对时间来说的。数据库中的数据就是持久化了的数据,只要你不去删除或修改。比如在浏览器中一次Session会话中Session对象变量也是不变的,是Session容器中持久化。对象持久化的方式有很多种,根据周期不同有,page,Session,Application。对象序列化机制对于需要将对象的状态保存到文件中，而后能够通过读入对象状态来重新构造对象，恢复程序状态. 对象序列化的过程是对象持久化的方法之一,把对象保存到文件中。

简单的理解持久化可以在二个层面：应用层和系统层、

应用层

如果关闭(shutdown)你的应用然后重新启动则先前的数据依然存在。

系统层

如果关闭(shutdown)你的系统（电脑）然后重新启动则先前的数据依然存在。

持久化是一种对象服务实现至少3个接口

，就是把内存中的对象保存到外存中，让以后能够取回。需要实现至少3个接口：

void Save(object o) 把一个对象保存到外存中

Object Load(object oid) 通过对象标识从外存中取回对象

boolExists(object oid) 检查外存中是否存在某个对象.

类似概念序列化

我们先跳开一下，看看另一个类似的有用概念：序列化Serialize也是一种对象服务，就是把内存中的对象序列化成流、或者把流反序列化成对象。需要实现2个接口：

void Serialize(Stream stream,object o) 把对象序列化到流中

object Deserialize(Stream stream) 把流反序列化成对象

序列化和持久化很相似，有些人甚至混为一谈，其实还是有区别的，序列化是为了解决对象的传输问题，传输可以在线程之间、进程之间、内存外存之间、主机之间进行。我之所以在这里提到序列化，是因为我们可以利用序列化来辅助持久化，可以说凡是可以持久化的对象都可以序列化，因为序列化相对容易一些（也不是很容易），所以主流的软件基础设施，比如.net和java，已经把序列化的框架完成了。

持久化方案可以分为关系数据库方案、文件方案、对象数据库方案、xml数据库方案

现今主流的持久化方案是关系数据库方案，

关系数据库方案不仅解决了并发的问题，更重要的是，关系数据库还提供了持久化服务之外的价值：统计分析功能。刚才我说到，凡是可以序列化的对象都可以持久化，极端的说，我们可以只建立一个表Object(OID,Bytes)，但基本上没有人这么做，因为一旦这样，我们就失去了关系数据库额外的统计分析功能。关系数据库和面向对象之间有一条鸿沟，因为二者模式不匹配，所以就存在一个OR映射问题。

Redis支持两种数据持久化方式：rdb方式和aof方式。前者会根据配置的规则定时将内存中的数据持久化到硬盘上，后者则是在每次执行写命令之后将命令记录下来。两种持久化方式可以单独使用，但是通常会将两者结合使用。

1、RDB方式

RDB方式的持久化是通过快照的方式完成的。当符合某种规则时，会将内存中的数据全量生成一份副本存储到硬盘上，这个过程称作”快照”，redis默认开启该持久化功能，具体配置如下：

save 900 1

save 300 10

save 60 10000

stop-writes-on-bgsave-error yes

rdbcompression yes

rdbchecksum yes

dbfilename dump.rdb

#文件名称

dir ./

#rdb文件存放路径

配置后系统会自动进行快照，save 60 10000表示60秒内有10000次写入，那么就会调用bgsave

除了系统自动进行快照外，我们也可以手动执行SAVE或BGSAVE命令主动进行快照 *** 作：

执行SAVE或BGSAVE命令

执行FLUSHALL命令

2、AOF方式

在使用Redis存储非临时数据时，一般都需要打开AOF持久化来降低进程终止导致的数据丢失，AOF可以将Redis执行的每一条写命令追加到硬盘文件中，这一过程会降低Redis的性能。

默认情况下，Redis没有开启AOF（append only file）持久化功能，可以通过在配置文件中作如下配置启用：

appendonly no    #是否开启aof，开启时将no改为yes

appendfilename "appendonly.aof"   持久化文件名称

auto-aof-rewrite-percentage 100

#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。

auto-aof-rewrite-min-size 64mb

#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。

appendfsync :everysec (推荐配置)

#持久化策略

always (同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好)

everysec (异步 *** 作，每秒记录，如果一秒钟内宕机，有数据丢失)

no  （将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的）

一般来说可以考虑同时使用两种持久化方案.

---