0、读数据库 还是 读文件
txt快.
之所以大家用数据库,是因为TXT对于大量数据中的某一些符合要求的数据进行"查找"效率低
1 、直接读文件相比数据库查询效率更胜一筹
2 、一次读取的内容越大，直接读文件的优势会越明显。
读文件时间都是小幅增长（这跟文件存储的连续性和簇大小等有关系），说明MYSQL对更大文件读取可能又附加了某些操作（两次时间增长了近30%），如果只是单纯的赋值转换应该是差异偏小才对。
3 、写文件和INSERT几乎不用测试就可以推测出，数据库效率只会更差。
4 、很小的配置文件如果不需要使用到数据库特性，更加适合放到独立文件里存取，无需单独创建数据表或记录，很大的文件比如图片、音乐等采用文件存储更为方便，只把路径或缩略图等索引信息放到数据库里更合理一些。
总结
读 写任何类型的数据都没有直接操作文件来的快，不论MSYQL过程如何，最后都要到磁盘上去读这个“文件”（记录存储区等效），所以当然这一切的前提是只读 内容，无关任何排序或查找操作
对比
io写硬盘
优势：本地文件系统，不需要通过jdbc驱动序列化进行网络传输，不存在网络问题
劣势：跟硬盘性能有关，没有优化（当然自己可以封装，例如：使用内存缓存，然后批量触发，但这样会占用少量内存资源，也比较麻烦）
存数据库
优势：如果连接已经存在，客户端无需关心服务端的处理（cilent发送过去 ->服务端缓存-〉结束），无需像写硬盘等待写入结束。自己负责事情少，检索方便！
劣势：网络问题，如果连接不存在，有连接数据库的开销
数据库的优势是体现的大量数据的查询、统计以及并发读写，不是在速度上．
一、数据库分类
- 层次式数据库 - 按路径查询数据
a. 含义：是一种有根节点的 定向有序树。
b. 条件： 1）有且只有一个结点 没有双亲结点；2）根以外的其他结点 有且只有一个双亲结点
只能处理 一对多 的实体联系。
c. 特点：任何一个给定的记录值只能按其层次路径查看，没有一个子女记录能够脱离双亲记录值而独立存在的。
d. 优点：数据结构比较简单清晰，数据库的查询效率高，提供了良好的完整性支持。
e. 缺点：现实世界中很多联系是非层次性的，它不适用于结点之间具有多对多联系；查询子女结点必须通过双亲结点；由于结构严密，层次命令趋于程序化。
- 网络式数据库 - 按路径查询数据
a. 按照网状数据结构建立的数据库系统。
b. 条件：1）允许一个以上的结点无双亲；2）一个结点可以有多于一个的双亲。
注：层次模型实际上是网状模型的一个特例。
c. 优点：能够更为直接地描述现实世界，如一个结点可以有多个双亲，结点直接可以有多种联系；具有良好的性能，存取效率较高。
d. 缺点：结构比较复杂，随应用环境的扩大，数据库的结构就变得越来越复杂，不利于最终用户掌握；记录之间的联系是通过存取路径实现的，访问数据时必须选择适当的存取路径，因此用户必须了解系统结构的细节。
- 关系型数据库 - 必须定义表结构
a. 由来
虽然网状数据库和层次数据库已经很好的解决了数据的集中和共享问题，但在数据库 独立性 和 抽象级别上仍有很大欠缺。
用户在对这两种数据库进行存取时，仍然需要明确数据的存储结构，指出存取路径。二关系型数据库能很好的解决这个问题。
关系型数据库模型，把复杂的数据结构归结为简单的二元关系 即 二维表格形式。
b. 最典型的数据结构是 表
| id | content |
|---|---|
| 1 | test a |
| 2 | test b |
c. 优点：建立在严格的数学概念的基础上；概念单一，无论实体还是实体之间的联系都是用关系来表示。存储路径对用户透明，从而具有更高的独立性、更好的安全保密性，简化了程序员开发工作。
d. 缺点：存取路径的隐蔽导致查询效率不如格式化数据模型。
- 非关系型数据库 - 不需定义表结构
a. 由来
随着互联网的兴起，传统的关系数据库在应付 web2.0 网站，特别是超大规模和高并发 的 SNS 类型的 WEB2.0 纯动态网站已经显得力不从心。
而非关系型数据库在特定的场景下可以发挥难以想象的高效率 和高性能，作为 关系型的补充。
b. 典型的数据结构是文档，以 JSON 为例
[
{
"id" : 1,
"content" : "test a"
},
{
"id" : 2,
"content" : "test b"
}
]
c. 应用场景
* 经常进行连接查询 - 因关系型数据库在进行多表连接查询时，会出现很多数据冗余
* 同一个表 不同记录 的数据结构 经常不一样
d. 分类
* 键值存储数据库 (key-value)
* 列存储 (Column-oriented) 数据库
* 面向文档 (Document-Oriented) 数据库
* 图形数据库 - 以 数据结构 图 的形式存储
- 非关系型 与 关系型 区别
速度：
关系型拥 有复杂的查询语句，需要语句解析，且 绝大多数数据都需要存在磁盘中，当我们需要数据时，需访问磁盘，速度受限；
非关系型 基于键值对，不需语句解析，且大多数数据存储在内存中，访问速度大大提升。
非关系型
- 基于 CAP 模型，偏向于 OLAP 场景
- 存储的是 非结构化 的数据
- 性能
NoSQL 是基于键值对的，不需要经过 SQL 层的解析，故性能非常高
- 可扩展 - 没有固定的表结构
因基于键值对，数据之间没有耦合性，容易水平扩展，即"表的列"可不一致，可动态增删
关系型
- 基于 ACID 模型，偏向于 OLTP 场景
- 复杂查询
使用 SQL 语句 方便在一个表 以及多个表之间做 非常复杂的数据查询
- 事务支持 – 安全性很高
- 很难扩展 – 固定的表结构
总结
这两类数据库，对方的优势就是自己的劣势。但 近年来这两类数据库正向着对方的方向发展。
【注】：
**CAP : **
* 一致性 (Consistency) 所有节点在同一时间具有相同的数据；
* 可用性 (Availability) 保证每个请求不管成功或者失败都有响应；
* 分隔容忍 (Partition tolerance) 系统中任意信息的丢失或失败不会影响系统的继续运作。
分布式系统只能满足三项中的两项，而不能同时满足全部三项。
ACID：
* 原子性 (Atomicity) 或称为不可分割性：一个事务中所有操作要么全部完成，要不全部不完成；
* 一致性 (Consistency) ：在事务的开始或结束时，数据库应该在一致状态；
* 隔离性 (Isolation) 又称独立性：事务将假定只有它自己在操作数据库，彼此不知晓；
* 持久性 (Durability) ：一旦事务完成，就不能返回。
OLAP: - 联机分析处理 (数据处理分类)
* On-Line Analytical Processing 联机**分析**处理，也叫 DSS 决策支持系统；
* 语句执行量不是考核标准，一条语句的执行时间可能会非常长、读取的数据也非常多；
* 考核标准：磁盘子系统的吞吐量 (带宽)，如 达到多少 MB/s 的流量；
* 吞吐量取决于磁盘的个数，此时 Cache 基本没效果；故 尽量采用个数比较多的磁盘以及比较大的带宽；
* 常使用分区技术、并行技术；
* 不需要使用绑定(BIND)变量，因整个系统执行量很小，分析时间对于执行时间可忽略；
* 应用于 数据仓库系统，支持复杂的分析操作、侧重决策支持，提供直观易懂的查询结果；
* 强调数据分析，强调SQL执行市场，强调磁盘 I/O ,强调分区
* 优化策略：增加 CPU 处理速度、磁盘 I/O 速度
* 数据量大、DML (数据操作语言 - 增删改查) 少
OLTP: - 联机事务处理 (数据处理分类)
* On-Line transaction Processing 联机**事务**处理；
* 应用于 传统的 关系型 数据库，主要是 基本的、日常的 事务处理；
* 强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作，提供高并发；
* 优化方式：Cache技术 - 决定很多语句不需要从磁盘子系统获得；B-Tree 树索引 - 语句越简单越好，一定要使用绑定变量，减少语句解析，尽量减少表关联、减少分布式事务；
* 分区、并行技术无效。
* 优化策略：内存优化、增加内存条
* 数据量少、DML(数据操作语言 - 增删改查) 频繁、并行事务处理多 但一般很短
- 内存数据库 - 大多数非关系型
- SQL Server 2016 In-Memory OLTP
- MySQL Memory Engine
- Apache Ignite
- FastDB
- Redis & Memcached
- MongoDB
二、SQLite - 本质是对磁盘上的文件进行操作
- 目的 / 优势：
- 设计目标是 嵌入式 的，占用资源低
- 不存在通信组件，是嵌入到程序中，直接调用 API 的
- 本地通用性存储组件
- 适用范围：
SQLite 功能简约、小型化、追求最大磁盘效率；
嵌入式应用、代替磁盘访问；
若只是 单机上用、数据量不是很大、需要方便移植或频繁 读/写 磁盘文件 用SQLite。
但，不适合高并发
- 查询性能：
- 使用 B-tree 做索引，B±tree 处理表
- 不慢于其他数据库，几乎与内存或磁盘同速
- 由于没有 调用服务器的网络或认证 以及 权限协商 的开销，对于简单查询反而更快
- 对于大数量数据的复杂查询不如大型数据库
- 执行方式
- 一切操作都会转化为对文件的操作
- 默认情况下，每次执行 sql 语句，都会使用事务操作，都会 “打开 - 关闭” 文件一次
- 优化插入性能
- 手动使用事务操作，提高读写速度，原理：先将执行的 sql 语句存储在内存中，当 commit 时才一次性执行
- 事务操作方法：
QSqlDatabase db_sqlite;
db_sqlite.transaction();// 开始启动事务
query.exec(“insert into …”);
query.exec(“insert into …”); //多条插入数据，若查询 - 使用 commit 时才返回数据
db_sqlite.commit(); // 提交事务，打开文件执行SQL语句
- 开启预处理
QSqlQuery query;
query.prepare( "INSERT INTO person (id, forename, surname) "
“VALUES(:ID, : forename, :surname)” );
query.bindValue(":id", 1001);
query.bindValue(":forename", “Bart”);
query.bindValue(":surname", “Simpson”);
query.exec();
可以看到 prepare 就是提前准备好一个查询语句，预编译到数据库，下次再次执行相同的语句时，就不用再次编译，节省了大量的时间
注：必须在 create query 之前 load SQL Driver 且激活 connection
- 总结
- SQLite 的简单性 (粗粒度锁机制 多次读 单次写 )-- 抛弃了 “支持高度的写并发”，不支持复杂查询
- SQLite 作为嵌入式数据库 – 不支持网络；若实现，可通过网络文件系统，但大多数网络文件系统存在延时，且 网络文件在实现文件逻辑锁方面存在 BUG，同时修改 可能会出现问题；
- 速度：没有绝对的谁快问题，在并发量少的情况下，I/O 写在磁盘上的速度更快
- 低并发量 数据库与I/O读写 速度对比： " 内存系统 > 文件系统 > 数据库系统 "
- 高并发量 数据库与I/O读写 速度对比：不好说
- 并发：SQLite 对于整个数据库文件进行 读/写 锁定，不适合 高并发
- 额外空间：开始一个事务处理时，会分配一小块 文件缓冲页面，来管理回滚操作；对于超大数据集时，需考虑其他数据库；1 MB 数据库文件 需 256 字节
三、MySQL
- 目的 / 优势：
- 目标 – 成为一个快速的 Web 服务器后端
- 体积小、易于使用和部署、运行速度快，高并发，多线程，开源，支持跨平台
- 满足企业数据库绝大多数的应用需求
- 适用范围：
功能全面、综合化、追求最大并发效率；
分布式操作、Web 网站 Web 应用、安全性高
需要满足多用户同时访问、网站访问量比较大，使用 MySQL
淘宝网也选择弃用Oracle，而更换为MySQL
主要应用范围：互联网领域、大中小型网站、游戏公司、电商平台
注：若 并发量 要求更加严苛，请使用 Oracle 或 NoSQL
- 应用架构
- 单点 ( Single ) ： 适合小规模应用
- 复制 ( Replication ) ： 适合中小规模应用
- 集群 ( Cluster ) ： 适合大规模应用
- MySQL 与 Oracle
- 都是关系型数据库；
- Oracle 是大型数据库、收费、安装占用空间大 (3G左右)；
- MySQL 是中小型数据库、开源、免费、安装占用空间小 (152M)；
- 并发性：Oracle 较优秀。Oracle 使用行级锁，对资源锁定的粒度要小很多，对并发性支持要好很多；MySQL 以表级锁为主，对资源锁定的粒度要大，虽然 InnoDB 引擎的表可以用行级锁，但需依赖表的索引。
- 数据持久性。如果出现异常重启，Oracle 可以从联机在线日志恢复客户提交的数据，而 MySQL 也行会丢失数据
- 性能诊断：Oracle 拥有各种成熟的 性能诊断 调优工具，且 更多的管理工具、图形界面等
- 分区表 与 分区索引：Oracle 的分区表和分区索引都很成熟，而 MySQL 分区表不太成熟
- 对事务的提交：MySQL 默认是自动提交；Oracle 默认不自动提交，需用户手动 commit
四、NoSQL - 非关系型 (例：MongoDB)
- 分类：
- 键值存储数据库（key-value）
优势在于简单、易部署、高并发
典型产品：Memcached、Redis、MemcacheDB
- 列存储（Column-oriented）数据库
用来应对分布式存储海量数据，擅长以列为单位读入数据，具有高扩展性，即使数据增加也不会降低相应的处理速度（特别是写入速度），所以它主要应用于需要处理大量数据的情况。但，因其面向列，思维方式与行数据库不一样，应用困难。
典型产品：Cassandra、HBase
- 面向文档（Document-Oriented）数据库
比键值数据库的查询效率更高
典型产品：MongoDB、CouchDB
MongoDB 介于 关系数据库 和 非关系数据库 之间
- 图形数据库
将数据以图的方式存储
典型产品：Neo4J、InforGrid
- MongoDB
- 基于键值对
- 介于关系数据库和非关系数据库之间的产品
- 支持的查询语言非常强大
- 语法 类似于 面向对象的查询语言，几乎可实现关系数据库查询的绝大部分功能
- 支持对数据建立索引
- 高性能、易部署、易使用，存储数据方便，行列可动态修改，易于扩展
- 文件存储方式为 BSON (一种 JSON 的扩展)
- 把数据存储在文件中，可以将不同结构的文件存储在同一数据库里
- 目的 / 优势：
- 为了处理 杂乱的 非结构化数据来设计的；即 数据具有横向伸缩性
- 以社交、搜索为代表的互联网业务产生海量数据时，关系型数据库在扩展性 (分片)、高昂的表变更成本、高并发量、写入延迟等，面对很多挑战，故 出现了 NoSQL；
- 在大数据存取上、高并发量上，具备 关系型数据库 无法比拟的性能优势
五、NoSQL 与 SQL
对于那些关系复杂的数据处理和分析统计，SQL值得花钱。但当数据库结构非常简单时，SQL可能没有太大用处。如果能用普通文件存储代替数据库系统的话，优选普通文件存储。
- 适合使用 SQL 开发的项目
- 可以预先定义逻辑相关的离散数据的需求
- 数据一致性是必要的
- 具有良好的开发者经验和技术支持的标准的成熟技术
- SQL是精确的。适合于具有精确标准的、定义明确的项目。典型：在线商店和银行系统
- 适合使用 NoSQL 开发的项目
- 不相关，不确定和逐步发展的数据需求
- 更简单或者更宽松的能够快速开始编程的项目
- 速度和可扩展性至关重要
- NoSQL 是多变的。适合具有不确定需求的数据。典型：社交网络、客户管理、网络分析系统
- 举例
- 通讯记录 - NoSQL
例：一个人 拥有 多个电话号码、多个邮箱、多个地理位置
若 使用 关系型 结构，我们将抽象出 四个 表：个人表、电话表、邮箱表、地理位置表
这样的数据是 碎片化 的，我们查找个人完成信息时，需用一条 Select 语句来 JOIN 多个表来获取。若一个人有 3 个电话，5 个邮箱和 2 个地理位置，那么 SQL 会查询出 30 个结果，效率会很慢。
且，以后我们还有可能对个人信息添加更多的项，如：职位、周年纪念日、关系、社交号、喜好等；
这时，我们使用表结构就会很受限。
使用 NoSQL 来代替 SQL
- 社交网络 - NoSQL
对于社交网，能够不受限制的扩展比更丰富的功能更加重要。因为开发者无法罗列出人的所有需求，即 无法创建一个固定的表结构，恰恰相反，随着网站的运行，增加表结构的字段会成为常态。
以 Facebook 用户数据集为例，不可能把3亿条数据集存放在同一个表格、文件或由同一台计算机处理，这要求系统能支持数据分区，把数据集分割在多台节点计算机中，每台计算机分担一部分负载，当用户增加到一定程度时，系统能允许加入新的节点计算机，并且尽可能地减少数据迁移。
- 仓库管理系统 -** **SQL
数据需求：
1. 保存货物的基本信息，如：尺寸、大小、颜色等，不需要个性化信息
2. 尽量避免错误发生，数据的准确性
3. 更加简单的方式操作。从 A 移动到 B
4. 分类，相同的物品放分配到相邻位置
5. 摆放顺序 以及 配送货物的先后顺序
六、其他
- SQL Server 数据库 - 只能在 Windows 系统下运行
- Access 数据库 - 桌面关系型数据库
- Memcached 非关系型 key-value 内存缓存 数据库
key - value 型，具有内存缓存系统，可用于减轻数据库负载
速度 内存 > 缓存 > 磁盘
因 其为纯内存缓存软件，重启时，数据会丢失
- Redis 非关系型 key-value
与 Memcached 类似，但其支持的存储 value 类型相对更低
支持持久化存储
