nosql

前言 net core 已经出了很久了，网上的各种框架也很多了，但是没看到一个很小很轻的框架，基本都是那种啥功能都有，但是我需要的功能只占他们框架的百分之几，很少很少，所以自己创造一个框架。 因为之前的知识断层太多了，现在为了拟补这些知识，也是走了不少弯路，现在和一个新手没啥区别，所以那里写的不对也请大家谅解。 1.我需要的框架结构是什么样的？ 我在搭建这个框架的时候查阅了很多资料，园子里有很多很多的大佬都已经写了怎么搭建一个框架，而阅读最广泛的是一套DI框架。但是不知道怎么回事园子里面的原文是加密的，打不开。可能是作者不想让爬虫爬吧。。 那么我到底需要什么框架呢？ 冥思苦想，有几个要求 1.不为现在工作而做一个框架 2.通用性高 3.简单易懂 4.中小型项目压力小 然后就随便画了一下结构图 哪我需要做的就是从中转平台到数据库支持这一块内容。 2 ORM的选择 我也是第一次学习net core和EF，以前都不懂EF是什么东西，也是通过现在工作学会一点EF的使用，觉得局限性太高了。但是写一写简单的操作还是比较快的，然后看到微软也发布了 EF Core，查了查资料看看了文章 也在各种ORM对比，结果发现EF Core被人黑的地方就是不能写sql语句，如果不能写sql语句那么就需要使用框架的人掌握linq和 lamuda的程度要很高了，不再是一个简单的新手小白可以使用的框架

一、数据库瓶颈 不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。 1、IO瓶颈 第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。 第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。 2、CPU瓶颈 第一种：SQL问题，如SQL中包含join，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算。 第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。 二、分库分表 1、水平分库 概念： 以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。 结果： 每个库的结构都一样； 每个库的数据都不一样，没有交集； 所有库的并集是全量数据； 场景： 系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库。 分析： 库多了，io和cpu的压力自然可以成倍缓解。 2、水平分表 概念： 以字段为依据，按照一定策略（hash、range等）

[TOC] 一、ORM介绍 orm：对象关系映射 对象关系映射简单说：就是通过操作对象的方式，去操作数据库。不需要写大量原生的sql语句就可以完成数据的增删改查 映射关系： 类 数据库中的表 对象 表单记录 对象获取属性 记录的某个字段对应的值 优点: 能够让一个不会数据库操作的人 也能够简单快捷去使用数据库 缺点: 由于封装程度太高 可能会导致程序的执行效率偏低，有时候 结合项目需求 可能需要你手写sql语句 注意事项：django的orm不会自动帮你创建库，库需要你自己手动创建，表会自动帮你创建 你只需要书写符合django orm语法的代码即可，去应用下所在的models.py中书写类 二、模型层 模型层：应用下的 models.py 。 在该文件先写表类继承于 odels.Model ，然后去定义属性字段 这里写的 类 ，会到数据库中去 创建响应的表(类名) ，每一个 设置的属性 ，就是一个 类中的字段 关于数据库的连接配置请参考： 002 Django框架及ORM的基本使用 如果想打印orm转换过程中的sql，需要在settings中进行配置日志： LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'console':{ 'level':'DEBUG', 'class':

4.0 版本 （1）跨文档事务支持 （ACID） 首个支持跨文档事务的NoSQL云数据库，将文档模型的速度，灵活性和功能与ACID保证相结合。现在，使用MongoDB解决各种用例变得更加容易。 （4.0 的事务存在最大修改 16MB、事务执行时间不能过长的限制） （2）40%迁移速度提升 并发的读取和写入，使得新增分片shard迁移性能提升了约 40%， 新增节点能更快的承载业务压力。 （3）读性能大幅扩展 4.0版本借助事务特性，使得备节点不再因为同步日志而阻塞读取请求。 （4）Change Stream 增强 在MongoDB3.6之前，如果我们希望对MongoDB数据库中的数据变动进行监听，通常是通过 “监听并回放oplog”。从MongoDB3.6开始支持的 Change Streams打破了这个僵局。 Change Streams使得数据的变动监听变得简单易用。如果你只需要针对某一个collection进行变动监听，MongoDB3.6就可以满足你的需求。在4.0版本中我们可以针对若干个数据库或者整个实例（复制集或者sharding）进行变动监听。与 watch() 某一个collection不同，4.0中我们可以 watch() 某个数据库或者整个实例。 4.2 版本 （1）分布式事务 4.2 支持分布式事务，MongoDB 采用二阶段提交的方式，实现在多个 Shard