nosql

《Vue.js+Node.js开发实战：从入门到项目上线》以JavaScript语言为基础，以一个完整的网站开发过程为主线，介绍了一整套面向Web项目的开发技术，如使用Node.js搭建服务端，使用NoSQL数据库管理数据，使用Vue.js搭建前端UI，使用Nginx部署代码，使用Git管理版本等。通过阅读《Vue.js+Node.js开发实战：从入门到项目上线》，读者可以掌握从网站开发到网站上线的全过程。 《Vue.js+Node.js开发实战：从入门到项目上线》分为10章，涵盖的主要内容有购买域名、网站备案、Node.js安装、Express安装、Vue.js安装、前后端分离设计、网站需求设计、网站模块规划、网站服务器端开发、网站客户端UI开发、服务器端部署和网站上线等内容。 通过构建一个完整的Web工程项目，展现Web前后端开发的全流程。 涵盖服务器购买、数据库设计、前端开发、后端开发和部署上线等内容。 内容全面：涵盖Node.js后端开发、NoSQL数据库管理、Vue.js前端开发、Nginx代码部署及Git版本管理等Web全栈开发的大部分核心技术。 技术新颖：紧跟技术发展趋势，详解Web开发领域非常流行的前后端分离架构技术。 实用性强：通过一个综合项目案例展开讲解，并穿插大量的示例帮助读者提高编码能力。 风格独特：按照项目开发的流程推进

一、DDL、DML、DCL常用语句 1、DDL（Data Definition Language）数据库定义语言 （1）数据库模式定义 #创建数据库　　 create database if exsites db_name ; # 选定数据库 use db_name ; # 删除数据库 drop database if exists db_name ; # 修改数据库 alter database db_name set ...; # 展示所创建的数据库 show databases; （2）表定义　　　　 # 创建表 create table test_table ( s_id int not null auto_increment, s_name char ( 50 ) not null default "hanmei", s_age int not null , primary key (s_id), index index_name(s_name) ); # 删除表 drop table if exists test_table; # 展示表结构 desc test_table; 2、DML（data manipulation language）数据库操作语言 insert into test_table(s_age) values ( 18 ); insert into

点击上方 “ 慧响智凝 ” 可以订阅哦！ 本文字数： 5160字 阅读时间： 10分钟 最近阅读了一本架构方面的入门图书叫《从零开始学架构：照着做，你也能成为架构师》，部分内容比较不错，先做书摘总结，以便加深印象与未来回顾学习。 本文是该书第二部分，是书中第四、五章，主要介绍存储高性能、计算高性能，涉及到关系型数据库分库分表与读写分离、NoSQL类型、缓存穿透与热点、单服高性能、集群高性能等内容。 目录 ▪ 第四章 存储高性能 ▪第五章 计算高性能 ▪其他相关摘要 第四章 存储高性能 关系型数据库 读写分离 本质： 将访问压力分散到集群中的多个节点，但是没有分散存储压力。 读写分离的基 ‍ 本实现： 数据库服务器搭建主 ‍ 从集群，一主一从、一主多从都可以。 数据库主机负责读写操作，从机只负责读操作。 数据库主机通过复制将数据同步到从机，每台数据库服务器都存储了所有的业务数据。 业务服务器将 ‍ 写操作发给数据库主机，将读操作发给数据库从机。 读写分离在实际应用过程中需要应对复制延迟带来的复杂性。 解决主从复制延迟的方法： 写操作后的读操作指定发给数据库主服务器。 读从机失败后再读一次主机。 关键业务读写操作全部指向主机，非关键业务采用读写分离。 分库分表 本质： 既可以分散访问压力，又可以分散存储压力。 为了满足业务数据存储的要求，就需要将存储分散到多台数据库服务器上。

目录 一.NoSQL的诞生 二.分布式数据管理 三.ACID/BASE 四.NoSQL数据库的分类 一. NoSQL的诞生 （1）什么是数据库？ 数据库(Database)是按 照一定的 数据模型 来组织、存储和管理数据的仓库。 （2） 什么是数据模型 ？ 把现实世界中的人、物、活动、概念等用 【数据模型】 来抽象、表示 成计算机能识别和处理的数字。 数据模型是DB系统的核心和基础。 （3） 传统数据库数据模型的类型 层次型、网状型和 关系型 发展历程： （4）什么是 关系数据模型？ 关系模型有严格的数学基础，抽象级别比较高，而且简单清晰，便于 理解。很快工业界就参与进来研发关系数据库系统以及SQL。 代表产品有Oracle、IBM公司的DB2、微软公司的SQLServer 以及开 源的MySQL。 （5）关系型数据库的特点（优点）？ 容易理解 ：用二维表表示 使用方便 ：通用的SQL语言。 易于维护 ：丰富的完整性约束大大减低了数据冗余和数据不一 致的可能性。 （6）在大数据时代关系型数据库的不足 在大数据时代中， 数据量大，价值密度低，需要便宜的设备承载。 数据量达到了PB级别。 需要数据库拥有， 处理速度快，需要高并发支持及快速扩容能力。 1. 无法适应多变的数据结构 现代网络中存在大量的半结构化、非结构化数据，针对结构化数据而设计的关系 型数据库系统来说

CAP，BASE和最终一致性是NoSQL数据库存在的三大基石。而五分钟法则是内存数据存储的理论依据。这个是一切的源头。 几个名词解释： 网络分区：俗称“脑裂”。当网络发生异常情况，导致分布式系统中部分节点之间的网络延时不断变大，最终导致组成分布式系统的所有节点中，只有部分节点之间能够进行正常通信，而另一些节点则不能。当网络分区出现时，分布式系统会出现局部小集群。 三态：分布式系统的每一次请求和响应包含：成功，失败，超时三种状态。 CAP CAP理论，指的是在一个分布式系统中，不可能同时满足Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能满足其中的两项。 1、一致性： 指数据在多个副本之间是否能够保持一致的特性。当执行数据更新操作后，仍然剋保证系统数据处于一致的状态。 2、可用性： 系统提供的服务必须一直处于可用的状态。对于用户的每一个操作请求总是能够在“有限的时间内”返回结果。这个有限时间是系统设计之初就指定好的系统运行指标。返回的结果指的是系统返回用户的一个正常响应结果，而不是“out ot memory error”之类的系统错误信息。 3、分区容错性： 分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障

背景 　一致性是一个抽象的、具有多重含义的计算机术语，在不同应用场景下，有不同的定义和含义。在传统的IT时代，一致性通常指强一致性，强一致性通常体现在你中有我、我中有你、浑然一体；而在互联网时代，一致性的含义远远超出了它原有的含义，在我们讨论互联网时代的一致性之前，我们先了解一下互联网时代的特点，互联网时代信息量巨大、需要计算能力巨大，不但对用户响应速度要求快，而且吞吐量指标也要向外扩展（既：水平伸缩），于是单节点的服务器无法满足需求，服务节点开始池化，想想那个经典的故事，一只筷子一折就断，一把筷子怎么都折不断，可见人多力量大的思想是多么的重要，但是人多也不一定能解决所有事情，还得进行有序、合理的分配任务，进行有效的管理，于是互联网时代谈论最多的话题就是拆分，拆分一般分为“水平拆分”和“垂直拆分”（大家不要对应到数据库或者缓存拆分，这里主要表达一种逻辑）。这里，“水平拆分”指的是同一个功能由于单机节点无法满足性能需求，需要扩展成为多节点，多个节点具有一致的功能，组成一个服务池，一个节点服务一部分的请求量，团结起来共同处理大规模高并发的请求量。“垂直拆分”指的是按照功能拆分，秉着“专业的人干专业的事儿”的原则，把一个复杂的功能拆分到多个单一的简单的元功能，不同的元功能组合在一起，和未拆分前完成的功能是一致的，由于每个元功能职责单一、功能简单，让维护和变更都变得更简单、安全

点击上方 “ 方志朋 ”， 选择“置顶或者星标” 你的关注意义重大！ 来源：my.oschina.net/u/3772106/blog/1793561 前言 高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。 为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。 在电商相关产品开发的这些年，我有幸的遇到了并发下的各种坑，这一路摸爬滚打过来有着不少的血泪史，这里进行的总结，作为自己的归档记录，同时分享给大家。 服务器架构 业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。 一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运行的强大后盾。 服务器这块多是需要运维人员来配合搭建，具体我就不多说了，点到为止。 大致需要用到的服务器架构如下： 服务器 均衡负载(如：nginx，阿里云SLB) 资源监控 分布式 数据库 主从分离，集群 DBA 表优化，索引优化，等 分布式 nosql 主从分离，集群 主从分离，集群 主从分离，集群 redis mongodb memcache cdn html css js image 并发测试

点击上方 IT牧场 ，选择 置顶或者星标 技术干货每日送达！ 一、数据库瓶颈 不管是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、水平分表 概念：

作者 ： 尜尜人物 cnblogs.com/littlecharacter/p/9342129.html 本文目录 一、数据库瓶颈 IO瓶颈 CPU瓶颈 二、分库分表 水平分库 水平分表 垂直分库 垂直分表 三、分库分表工具 四、分库分表步骤 五、分库分表问题 非partition key的查询问题 非partition key跨库跨表分页查询问题 扩容问题 六、分库分表总结 七、分库分表示例 一、数据库瓶颈 不管是IO瓶颈，还是CPU瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。 1、IO瓶颈 第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -> 分库和垂直分表。 第二种：网络IO瓶颈，请求的数据太多，网络带宽不够 -> 分库。 2、CPU瓶颈 第一种：SQL问题，如SQL中包含 join ，group by，order by，非索引字段条件查询等，增加CPU运算的操作 -> SQL优化，建立合适的索引，在业务Service层进行业务计算。 第二种：单表数据量太大，查询时扫描的行太多，SQL效率低，CPU率先出现瓶颈 -> 水平分表。 二、分库分表 1、水平分库 概念： 以字段为依据

本文来源： cnblogs.com/littlecharacter/p/9342129.html 一、数据库瓶颈 不管是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等），将一个库中的数据拆分到多个库中。 结果： 每个库的结构都一样； 每个库的数据都不一样，没有交集； 所有库的并集是全量数据； 场景： 系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库。 分析： 库多了