nosql

#进入数据库 use test #创建一个集合 db.createCollection("runoob") #查看集合 show collections #插入文档 db . col . insert ({ title : 'MongoDB 教程' , description : 'MongoDB 是一个 Nosql 数据库' , by : '菜鸟教程' , url : 'http://www.runoob.com' , tags : [ 'mongodb' , 'database' , 'NoSQL' ], likes : 100 }) #查看集合 show collections #查看文档 db.col.find() #插入多条数据 var res = db . collection . insertMany ([{ "b" : 3 }, { 'c' : 4 }]) #更新数据，前面是查询条件，后面是更新的内容 db . col . update ({ 'title' : 'MongoDB 教程' },{ $set :{ 'title' : 'MongoDB' }}) #查询，等于 db.col.find({"by":"菜鸟教程"}) #查询，大于 db.col.find({"likes":{$gt:150}}) #查询，大于 db.col.find({"likes":{

本文参考书籍 https://github.com/oopsguy/microservices-from-design-to-deployment-chinese 微服务简介 单体应用 在项目开发启动阶段，比如开发一个电商系统，该系统包括了订单模块、商品搜索模块、用户模块和后台等系统，启动阶段虽然按照业务逻辑分模块开发，但是最终成功上线运行的是一个单体应用，在项目开发的初期，单应用的架构有助于快速更改业务流程，快速迭代，当项目发展到一定时期后，一个庞大、复杂的单体，对于新的功能的开发可能就是陷入了很大的困境，无论是修复线上小的问题还是新需求的开发都设计到整个项目的重新部署和测试，并且降低了开发的效率。 当项目发展到一定阶段后，不同模块存在资源需求的冲突，单体应用可能难以扩展；当单体应用在线上实际运行过程中，任何一个模块出现一个bug，都可能会导致整个单体应用不可用。当需要对项目中开发的某个模块进行灰度发布的时候，单体应用往往也不能满足很好的扩展性。那么如何进行改进呢？ 微服务 通过将应用程序分解成一套比较小的互联服务，即微服务架构模式。一个服务通常实现了一组不同的特性或功能，例如用户模块等。每一个微服务都是一个迷你应用，都包括了自己实现的业务逻辑，暴露了对外服务的接口，服务可单独部署与开发。 应用程序的每个功能区域都由相应的微服务实现，每个后端服务暴露相关接口

前言 前面我已经把 MySQL 的专题系列都更新完了，相信大家看了之后应该都有很大的收获（应该没有夸张吧哈哈哈哈），毕竟把 MySQL 通讲了一遍，出去面试应该也能够说比一般面试官知道得多了，在工作中性能调优的理论知识也基本上具备了（也建议大家多实践，实践出真知）。废话不多说，今天这个篇章是非专题系列，主要是给大家梳理一下关于架构方面的东西，希望大家看完之后能对服务器架构方面有一定的了解，也感谢大家一直以来的支持。 正文 架构的本质 一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。架构的本质就是对系统进行有序化重构，使系统不断进化。 那架构是如何实现无序到有序的呢？ 基本的手段就是分和合，先把系统打散，然后重新组合。<br /> 分的过程是把系统拆分为各个子系统 / 模块 / 组件，拆的时候，首先要解决每个组件的定位问题，然后才能划分彼此的边界，实现合理的拆分。<br /> 合就是根据最终要求，把各个分离的组件有机整合在一起，相对来说，第一步的拆分更难。 <br />拆分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得柔性，可以因需而变，实现业务敏捷。 架构的分类 架构一般可分业务架构、应用架构、技术架构：

系统架构演化历程-初始阶段架构 初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP特征：应用程序、数据库、文件等所有的资源都在一台服务器上。描述：通常服务器操作系统使用linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用Mysql，汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。 系统架构演化历程-应用服务和数据服务分离 好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver特征：应用程序、数据库、文件分别部署在独立的资源上。描述：数据量增加，单台服务器性能及存储空间不足，需要将应用和数据分离，并发处理能力和数据存储空间得到了很大改善。 系统架构演化历程-使用缓存改善性能 特征：数据库中访问较集中的一小部分数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的访问压力。描述：系统访问特点遵循二八定律，即80%的业务访问集中在20%的数据上。缓存分为本地缓存和远程分布式缓存，本地缓存访问速度更快但缓存数据量有限，同时存在与应用程序争用内存的情况。 系统架构演化历程-使用应用服务器集群 在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天

点击上方“ 五分钟学算法 ”，选择“星标”公众号 重磅干货，第一时间送达 我们在这一系列前面的文章曾经分析过 为什么 MySQL 使用 B+ 树 ，有读者在文章下面留言，希望能出一个为什么 MongoDB 使用 B 树的对比文章，这是一个比较好的问题，MySQL 和 MongoDB 两种不同类型的数据库使用了相似却不同的数据结构，为什么 MySQL 选择使用 B+ 树而 MongoDB 使用 B 树呢？ 概述 MongoDB 是一个通用的、面向文档的分布式数据库[^1]，这是官方对 MongoDB 介绍。区别于传统的关系型数据库 MySQL、Oracle 和 SQL Server，MongoDB 最重要的一个特点就是 『面向文档』 ，由于数据存储方式的不同，对外提供的接口不再是被大家熟知的 SQL，所以被划分成了 NoSQL，NoSQL 是相对 SQL 而言的，很多我们耳熟能详的存储系统都被划分成了 NoSQL，例如：Redis、DynamoDB[^2] 和 Elasticsearch 等。 sql-and-nosq NoSQL 经常被理解成没有 SQL（Non-SQL）或者非关系型（Non-Relational）[^3]，不过也有人将其理解成不只是 SQL（Not Only SQL）[^4]，深挖这个词的含义和起源可能没有太多意义，这种二次解读很多时候都是为营销服务的

一、引言 今天正式开始了Redis的学习，如果要想学好Redis，必须先学好Redis的数据类型。Redis为什么会比以前的Memchaed等内存缓存软件使用的更频繁，适用范围更广呢？就是因为Redis使用起来更方便，之所以方便，是因为Redis支持的数据类型比以前的Memchaed缓存支持数据类型的更多了。Redis有五种基本数据类型，String(字符串)，Hash(哈希),List(链表),Set(集合),ZSet(有序集合)，在这五种基本的数据类型中，String类型是最基础的。为什么说String类型是最基础的，就拿List为例来说，它是以列表的形式组织字符串数据，Set类型是以集合类型来组织字符串数据的。今天就让我们比较全面的来认识一下redis的基本数据类型吧。 二、NoSQL的介绍 NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，意为反Sql运动，提倡运用非关系型的数据存储，随着Web2.0网站的兴起，传统的关系型数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经力不从心，暴露了很多难以克服的问题，而非关系型数据库则由于其本身的特点得到了迅速发展。 NoSQL是以key-value形式存储，和传统的关系型数据库不一样，不一定遵循传统数据库的一些基本要求，比如：遵循Sql标准，ACID属性

简介 NoSQL 下载及安装 使用 数据类型 条件操作符 修改器 $的使用 sort - limit - skip python操作MongoDB 更多文档及学习资料 ： 菜鸟教程 百易教程 来源： oschina 链接： https://my.oschina.net/u/4374969/blog/4065340

起源 在进行架构转型与分库分表之前，我们一直采用非常典型的单体应用架构：主服务是一个 Java WebApp，使用 Nginx 并选择 Session Sticky 分发策略做负载均衡和会话保持；背后是一个 MySQL 主实例，接了若干 Slave 做读写分离。在整个转型开始之前，我们就知道这会是一块难啃的硬骨头：我们要在全线业务飞速地扩张迭代的同时完成架构转型，因为这是实实在在的”给高速行驶的汽车换轮胎”。 为了最大限度地减少服务拆分与分库分表给业务带来的影响（不影响业务开发也是架构转型的前提），我们采用了一种温和的渐进式拆分方案： 对于每块需要拆分的领域，首先拆分出子服务，并将所有该领域的数据库操作封装为 RPC 接口； 将其它所有服务中对该领域数据表的操作替换为 RPC 调用； 拆分该领域的数据表，使用数据同步保证旧库中的表与新表数据一致； 将该子服务中的数据库操作逐步迁移到新表，分批上线； 全部迁移完成后，切断同步，该服务拆分结束。 这种方案能够做到平滑迁移，但其中却有几个棘手的问题： 旧表新表的数据一致性如何保证？ 如何支持异构迁移？（由于旧表的设计往往非常范式化，因此拆分后的新表会增加很多来自其它表的冗余列） 如何保证数据同步的实时性？（往往会先迁移读操作到新表，这时就要求旧表的写操作必须准实时地同步到新表） 典型的解决方案有两种： 双写(dual write) :

起源 在进行架构转型与分库分表之前，我们一直采用非常典型的单体应用架构：主服务是一个 Java WebApp，使用 Nginx 并选择 Session Sticky 分发策略做负载均衡和会话保持；背后是一个 MySQL 主实例，接了若干 Slave 做读写分离。在整个转型开始之前，我们就知道这会是一块难啃的硬骨头：我们要在全线业务飞速地扩张迭代的同时完成架构转型，因为这是实实在在的”给高速行驶的汽车换轮胎”。 为了最大限度地减少服务拆分与分库分表给业务带来的影响（不影响业务开发也是架构转型的前提），我们采用了一种温和的渐进式拆分方案： 对于每块需要拆分的领域，首先拆分出子服务，并将所有该领域的数据库操作封装为 RPC 接口； 将其它所有服务中对该领域数据表的操作替换为 RPC 调用； 拆分该领域的数据表，使用数据同步保证旧库中的表与新表数据一致； 将该子服务中的数据库操作逐步迁移到新表，分批上线； 全部迁移完成后，切断同步，该服务拆分结束。 这种方案能够做到平滑迁移，但其中却有几个棘手的问题： 旧表新表的数据一致性如何保证？ 如何支持异构迁移？（由于旧表的设计往往非常范式化，因此拆分后的新表会增加很多来自其它表的冗余列） 如何保证数据同步的实时性？（往往会先迁移读操作到新表，这时就要求旧表的写操作必须准实时地同步到新表） 典型的解决方案有两种： 双写(dual write) :