NOSQL数据库
主要是文档数据库（mongoDB）
SQL缺陷
- 隔离程度低，需要程序员写逻辑
- 过于庞大和复杂
- 范式化无法做到，schema难看
设计思想
- 想要与应用做更好的结合，对应于json，object
- 更易于使用
- 扩展能力：由于功能简单，很好的扩展性（no join，no transaction，只能交给应用，如何在nosql上做transaction）
- 接口
- CRUD
- 高可用
- replication
- 多版本的一致性，共识协议 raft，service availability
- write，read concern
OOP
Object-Relational Impedance Mismatch
- OO与DB有各自的数据模型，两种模型之间存在差异
- 常常使用ORM工具
- 帮助用户建立/管理/维护对象和关系之间的映射
- 实际上将关系有所改变
- 主码变得没有意义（代理键）
- 对象中的属性也可能是对象（也形成一种关系）
- 缺陷
- 映射关系的标注和维护不简单
- 无法代替复杂查询和数据库管理（索引）
数据库设计过程
- 需求分析 OO 对每个对象设计一个文档
- 概念模型设计
- 逻辑模型设计
- 物理模型设计（是否可以embedding，denormalization）
- 操作原子性（需要了解）
- 日志
- 锁
- 可线性化
NoSQL的事务功能
现状
- NoSQL数据库通常不支持事务!
- 只保证单个操作的原子性。
- MongoDB的Multi-document Transaction 只限于单节点。（不是分布式）
- 原因
- 事务的性能得不到保证。
- 把数据一致性的问题交给应用来解决
事务的ACID vs 操作的原子性：
- 事务
- 过程未知，只能使用通用并发控制手段，如2PL;
- 粒度和时间不可控，可以很大。
- 操作
- 过程已知，可以为其定制并发控制手段，访问数据的方式已知，可以进行优化
- 粒度小，时间短。
数据一致性问题
- Embedding
- 将经常被同时更新的字段放在统一文档中，与文档数据库的设计理念相同
- 同步标记
- 标记打开说明同步工作未完成，下次启动时重新操作
- 需要满足幂等性质
- 操作一次和多次的结果是一样的
- 消息队列
- 可能使用数据库之外的其他系统实现
- 每条消息都是原子的，同一个消息队列中的消息串行执行，不同消息队列中保证不会有冲突
- 依然需要满足幂等性质
- 若不满足幂等性质的操作（转账等），使用类似于事务处理的机制
- 日志
- 时间戳
- 补偿事务
- 使用操作系统的同步机制
- 锁
- 信号
- 原子操作（CAS）