开发者学堂课程【高校精品课-上海交通大学 -互联网应用开发技术：NoSQL 3】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/76/detail/15774
NoSQL 3
实际使用 MongoDB 的举例，详情如图所示：
分析可得，将人的信息存储到MongoDB 里面，使用spring 的相关技术进行访问，故大标题为Spring with MongoDB ，将人的信息存储到MongoDB 之后，很显然每个个体是一个document , 存储成为 jus 的对象，只有id 需要进行标注，表示的意义为String 在处理时表示的字段为id ，当应用在协助时，则id 是可以人为指定的，下划线杠id 的字段与其进行匹配。
在演示过程比较简单，此人只有first Name 以及last Name ，故可以在构造器里人为指定三种属性。
因为是id ，后面两个属性比较重要，故没有get 方法及set 方法，整个类里面只有一个Anotation ，没有其他多余的标注。
工程结构为了保持与之前一致，person 虽然数据在MongoDB 里面，但仍属于entity ，对此使用repository 接口生成新的Person Repository接口， 与之前访问惯性数据库是一致的，定义接口成功之后，spring 会定义实现类，然后撰写MongoConfiq 文件，配置信息的类里面有 Sample Application ，此为spring 构成的一个类，大致结构就是如此。
Person Repository 详情如下：
在Person Repository 里面，继承为Mongo Repository，里面的内容如果没有人为进行编辑，与之前的内容是一致的，是Mongo Repository 里面默认的一些方法进行实现，同时也可以使用first Name 以及last Name 进行查找，定义的一个原则为find By 是一个完好的模板，需要撰写的内容为后面的属性名，写完之后，spring Repository 会生成一个接口的时间类，会自动按照first Name 或者 last Name 属性的查找方法，内容为传递参数，传递成功之后，会生成三种查找方法。
Mongo Repository 是spring 生成的一项模板类，是Java C++ 里面学的内容，在Java 里面为泛型类template tener，同样的道理，处理的为person，后面的为主键的类对应匹配的为String，可以知道每个string对应在某个collection 里面，但people 属于某个库并没有进行声明，与之前JPA一样，需要在其他地方声明为某个库，就是未来代码可以做复用，只要代码里面有people 的collection 就可以进行复用，就可以访问到其他的库，这与JPA 的原理一致。下面为库的内容，在test里面有一个person 库，在MongoDB 安装成功之后，里面实际插入的一个对象，此对象的id 是随机插入的，此示例里面的id 是一个主角人物的first name 及last name，可以将此人为删除并输入想要的内容，正如示例所示，输入为三个，_id分别对应为1、2、3，再分别对应三个人名：曹操、刘备及孙权。此对应的class 就为刚刚定义的person 类，此为Repository 的一个接口，会自动生成一个类，这个类会提供find By Last Name 、find By First Name 以及一些已经预定的方法，例如get way，此与JPA 和Repository 是一致的，然后就可以进行使用，详情如下：
同样的道理，为了简单起见，要求自动组装实现person Repository 此对象，原则与之前提到的一致，spring 会在当前应用里面进行查找person Repository 的类，找到之后，就能在刚刚找到的接口上自动生成一个类，再将它注入进来，故无需进行声明定义就可以直接进行使用。使用过程第一步，将库（collection）里的内容全部删除，第二步，存储三个人的信息，三人分别为曹操、刘备、孙权，分别对应主键first name、last name，第三步，存储成功之后，详情如下：
调用在repository 里面find All ，find All 是repository 除了自己定义的方法，还有预定义的方法，例如delete 就是find All 预定义好的方法。
find All 是一个集合，故使用for 循环定义里面所有的person ，然后再从person 上调用get First Name 以及 get Last Name，输出之后可以看到里面存储的所有顾客的名称，同时也可以按照定义好的方法，例如根据find By First Name 、find By Last Name 进行查找，查找之后给定一个参数，因为之前定义了参数，进行查找之后返回的可能是一个名称，或者多个名称，但众所周知数据库有一个原则为若不按照id 查找，则返回的不能保证为单一的结果，故在之前定义时就要声明返回的内容为List ，若不是按照主键进行查找，其他方式都不能保证结果是唯一的。因为只有主键在每一条记录里面是不同的，故返回的内容就为List ，故需要定义List ，再输出first Name 以及last Name 。
这个简单的程序代码就是可以访问到MongoDB ，将原有的内容删除，再插入，再输出等，此程序代码的做法与之前JPA 的做法几乎是一致的，除了某个类的写法不一致，其他内容都是一致的。若要定义方法，例定义find By 及属性名，可以直接输入，类比于first Name 及last Name ，因为在Java 变量里面，成员变量为小写字母开头，将小写字母改成大写字母，其余保持不变，故若直接输入名字，Spring就按照定义属性查找，凡是按照属性查找，就不需要给出其他内容，Spring 有默认方法，但若想要定义一个属于自己的方法，例如之前同学问过的一个问题：若想要定义一个find By Last Name and first Name，对此在JPA 里面表示并不是在里面给定一个定义，因为要注意接口里面是不能含有定义的，不能直接写入查找的方法，这是不允许的。正确的做法应该是在前面先写一个Query （“ ”），括号里面输入对应数据库支持的查询语言，然后Spring 就能按照括号里面的逻辑生成方法来实现定义，大致过程就是如此。
示例中的类比较简单，person 就是按照两个属性进行查找，故此这种是不需要给出Query 逻辑，除了它之外的所有查找方法都属于Spring 不能直接解析的，故此需要使用Query 逻辑来辅助理解，但不能直接给定方法，因为接口是不能带有方法体的，以上为MongoDB 示例的大致内容及过程。
以上为在后台跑的MongoDB 的控制台，可以看到里面的内容与讲解的内容是一致的。若要跑程序的话，详情如下：
以上为跑程序之后的结果，可以看到第一次输出时找到了三个名称，first Name 只能查找刘备，last Name 查找结果为孙权，以上为查找的结果。若要做此过程，首先需要一个客户端，这个客户端就是用idea 进行创建，这个表格比较简单，故可以人为进行编辑，若碰上复杂的表格，此客户端就不太适用，就需要使用第三方客户端，找到之后进行各种连接，连接完之后里面的collection 类似于之前表达的内容就在此处，打开之后就能看到之前插入的三个人的信息，故此示例就是讲解如何使用Java代码通过比较简单的方式（Spring）进行访问，但是一定要注意，在使用分层架构之后，按照person 进行填写代码，至于person 如何组装与Repository 有关，看到的person 就为一个普通对象，故此可以在Application 类里面可以定义一个person ，然后可以找到一个对象赋给person ，给定相应的代码。
仔细观察Application 代码会发现，其实看不到与底层相关的内容，也就是说，在此处观察是看不到在某个数据库进行存储的，可能是MySQL 或者MongoDB ,这种未知就是想要达到的效果。
也就是说，现在撰写的代码，例如person 现在放置在MongoDB 里面，若想要改到数据库里面，则需要输入Application 内容，然后将Repository 里面的MongoDB 改成JPA ，凡是使用person 代码，例如之前讲过的Sample Application代码，就不需要进行修改，所有代码与存储位置是没有任何关系的，分层架构就是每往上一层就屏蔽底层的差异，通过Repository 来替换以下的内容存储位置是MongoDB 或者MySQL 这一事实，故此示例能体现分层架构的优点。Spring 在设置各种各样的Repository 时保持大体一致，故Mongo Repository 与JPA Repository 写法基本是一致的，此说明架构本身也遵循分层架构的原则，以上就是讲解的代码。
再观察以上代码，之前讲解的配置信息在此示例中只需要一个，可以不用写成一个类，只要写明库的位置即可。
在Person里面提到的id ，在Repository 里面映射的collection 叫做Person，但库的位置是未知的，故在 Application Repository 里面写明spring .data.mongodb .vri ,此为Spring 约定俗成的写法及规定。
而后面则是关于mongodb 的写法：
mongodb://test:test@localhost:27017/test。意思为mongodb在本地的27017的端口，跑了一个mongo 的实例，前面的test：test 为用户及密码，与之前讲解的数据库的访问一致，这段代码的写法在任何数据库中是一致的，前面的mongodb 是体现在某个数据库，MySQL 及MongoDB 的写法不一致，后面的写法都是一致的，通过用户名、密码、@、主机名、端口号、test等就能访问此数据库。
而看到的db 表示当前使用的数据库类型，此处为test，表示在test 输入数据在person的collection 里面，以上内容为简单的一个代码讲解。
此代码看着用处不大，因为这些内容在一个关键型数据库里面同样可以进行存储，每个人都有此三种属性，不一定要使用MongoDB 。故接下来就此代码进行讲解MongoDB 的使用，接着再举例来分析使用MongoDB 的优点。
将此实例进行操作，变成一个Spring put 的一个应用，详情如下：
同时也可以借助postmen 工具进行访问需要的内容，例如对其8080 使用postmen 工具，结果详情如下:
此为有关MongoDB 的person 的内容，故可以进行使用。具体使用方法如下：
Person 后面为一些可选的参数，若不进行选择，则默认为local host people，people 可以看到所有的内容，也可以对search 进行查看，结果详情如下：
上面的内容实际上是spring 帮助实现用户之后再进行查找数据。
根据上图可知，people/search/find By Last Name?Name = Liu ,此逻辑为从uill 开始，接着从请求的参数Name = Liu 进行获取，这部分内容就解释了之前代码的书写方式中要输入@param（“name”），因为当别人进行访问时，请求时是带着参数的，将name参数获取出来再进行传递，就能进行查找。
之后的find By Last Name 传递的参数为Name = Liu ，故当发出此请求时，就可以将刘备查找出来，而其余人则没有。若对person 进行试验就能得到此效果。
观察上图可知，在处理MongoDB 里面的JSON-like时，在描述MongoDB 的数据类型时，必须要与 JSON 或者Java Script 数据类型的描述要一致，就是图片下方的内容。
也就是说，得到的结果都是数值及文本，然后可以进行嵌套document ，意思为不能使用其他的例如Java 里面定义的数据类型，因为这两者之间是不一致的。若想要创建的内容 JSON 能够被Java Script 进行解析，就使用上图的数据类型，基本上使用的为数值，可能是小数、整数及字符串（true、false）等，其余使用的较少。
在执行查找时，MongoDB 本身支持在控制台上输入find 就能将内容都查找出来，find 就是 Mongo 的控制台，提供了查询功能。故此在查询时，若不是通过Spring 进行访问，而是通过控制台访问时，就会出现find ，find里面需要输入一个条件，条件为：({"age": {"$gte" : 18, "$lte" : 30}})，意思为年龄要大于等于18岁或者小于等于30岁，可以将符合这个范围的对象查找出来。
观察上图可知，此查询条件有where 语句 ，这与MySQL 里面的查询条件是一致的，无论如何执行此语句，query 会翻译为一个游标：a database cursor ，此游标为lazily returns batches ，此事件有点复杂，可能不太容易理解，故进行进一步解释，可以结合数据库一起理解，若实在不能理解也没关系。例如一张表格，里面包含了许多支路，假设有一个query ，会发现只有部分支路是符合条件的，同时会生成一张视图包含此符合条件的内容，但并不是直接复制，而是进行引用，箭头指向第一条，故可以得到一个结果集，在里面可以不断变换成每一个对象，这与之前讲解的内容一致。Lazily 的意思为，当访问第一条内容时，执行query 时并不是将三条数据同时取出， 而是当游标想要真正访问第一个对象时例如get first name 此方法时进行执行一次，执行之后，可能会带来某些问题，因为每一种数据库类型不太一样，当数据库的隔离级别或者保护不够时，就可能出现结果三个人都姓刘的情况，此时访问第一条时，但还没访问第二条，同时会有另外一个程序执行对第二个人的姓进行改动为孙，当游标指向第二个人时，就会发现错误，本来想要查询姓刘的对象结果查询到的对象姓孙，故此这种问题是有可能发生的。此为事务的隔离级别，相关内容其他老师会有详细讲解，之后大三也会进行进一步解释，目前不理解没有关系，只要记住前面这部分内容就可以。最后查询完毕之后会有个游标，与光标的移动类似，对此不断进行next 就能展查到想要查询的所有符合条件的对象。此游标也不一定非要next ，也可以一次性跳过一定的数量，例如可以直接从第一行跳到第五行，这样也是可以的，同时也可以在查询中进行限制，只要查找前五项内容，或者对所有的结果进行排序之后再返回，但必须基于这些结果能够进行排序，才能对此进行排序。
游标拿到之后，就可以进行操作，实际上此游标是查询到的结果符合查询条件的结果集上的游标，而数据库里面还有一个可以遍历所有元素的游标，这两者是不一致的。若对此不理解也没有关系，应该能看到cursor 进行。意思解释为：在某个完整的数据库里面，有一个游标在来回移动，其实查询到的结果只是数据库里面的一部分，游标只是在此三个之间进行移动，而不会移动到其他地方，但是看到的只是查询到的那一部分。若不能理解没有关系，知道大体意思即可。游标移动时就使用next ，先观察是否有符合条件的结果，若有则取出，这种比较便利的方法在之前的代码中也出现过。
观察上图可知，此内容是之前谈到的功能，第一种，对其进行限制（只查询三条）；第二种，查询到的所有结果跳过前三项，从第四项开始；第三种，查询到的所有结果按照用户名升序排列，若用户名一致，则按照年龄降序排列；第四种，对find 增加条件：此描述为MP3 ，且只查找前五十项，按照价格的降序排列；第五种，限制条件与第四种一致，但是需要跳过前五十项。故此就明白如何对第四种与第五种进行分页，第一页为第四种，第二页为第五种后面五十项，故结果获取了三次，第一次前100项，第二次101至200项，第三次201至300项，展示了分页功能。
在MongoDB 里面可以创建索引，例如在people 的collection 里面创建按照用户名升序进行索引，在进行查找时，例如：“date”：date 1，是按照date 升序排列，按照use name(用户名)降序排列,故在一个document 里面的结果是既有date 又有use name，先按照date 排序，再按照use name(用户名)排序。为了加快操作，可以先按照date 和use name 创建索引，在此基础上再进行查找，速度会加快。索引可以是升序，也可以为降序，可以根据需求自行选择。创建索引的原因就是提升速度。
对其进行操作的对象创建索引，但是MongoDB 里面有一个比较特殊的内容，称作地理索引，详情如下：
地理索引也是为了方便进行查找。例如，有一个二维的数值，表示两维空间的一个坐标点的概念，能够找到离此最近的若干事务，若知道东经二十度，北纬三十三度，就可以通过此索引进行查询离此地点三公里范围内的咖啡店的具体位置及名字等信息，或者指定查询距离最近的十个咖啡店，就可以通过此索引进行查找。也就是说，在MongoDB 里面若有一个表示平面位置概念的键值对，就可以将涉及到的内容全部映射到一个点上面，就可以通过地理索引查找最近的车的具体位置，但应该是一个平面，故给出东经北纬这种数据其实不好处理，因为地球看起来是球面，故每一块的区域差异较大，若经度相差一度，实际上距离相差很大，故此处理平面比较准确，处理球面会稍差一些。但是问题不大，因为对于处理的相对范围并不大，故差异也不会特别明显，除非在处理整个地球在靠近南极点或者北极点时，这种差异就会十分明显。
例如在北极点说，就没有距离这种说法，因为朝任何方向都是南，就不存在经度相差多少距离，故存在这种问题。但是抛开此缺陷来说，功能整体上还是不错的，只要给定一个平面的信息，就可以提供其他相关document 的信息。示例如下：
在创建索引时，需要增加一个参数为2d ,对GPS 创建索引，之前创建的索引是按照use name 升序排列或者按照age 降序排列，此示例不是1或者-1，而是2d ，对GPS 按照2d 这种方式进行排列，也就是地理索引这种方式排列。当给定输入一些信息，如下：
{ "gps": [ 0,100 ] }
{ "gps" : { "x”: -30, "y" : 30}}
{ "gps" : { "latitude" : -180, "longitude" : 180 } }
输入这些信息之后就可以进行创建索引，在实际领域建立一个索引，例如star.trek星际银河，按照光年创建一个索引，但是有一点与GPS 不同的是，GPS不管如何建模，纬度都为-90°至90°，经度都为-180°至180°，故所有的GPS 的点都可以进行创建地理索引。但是星际银河不一样，天上的恒星数不胜数，假设若星际银河将所有恒星的位置都输入进去，并且每个恒星到地球的距离都使用光年进行计算，如果说宇宙是一个巨大的球，知道这个球的位置，但是无穷无尽的，飞船也不一定能够到达，故需要对距离的范围进行限制，只对此范围内的目标产生索引，其他的则不起作用。举此示例是为了说明并不是所有的对象都要参与索引，而是满足一定条件的数据进行创建索引，这样可以提升搜索的效率。当GPS 创建索引成功之后，对此进行搜索，详情如下：
上图方式搜索的对象为两个值离40和-70最接近的数值，若数量非常多则只取前十个，这是此索引的优点所在。再进一步进行考虑，其实GPS 只是一个键值对的键的名字，名字不是确定的，数据也并不是只能是经度纬度，故本质上来说，若document 里面有一个键，数值是一个二维的，包含两个元素一个数字，此两个元素都是数值型，都为number ，满足以上条件就可以创建此类2d 索引。若将定义改成人的体型、身高与体重，就可以认为人的体型是游这两个指标构成的，故此可以在体型上创建2d 的索引，就可以查找出与此人体型最接近的对象。故此虽然名称叫做地理空间索引，但表达的含义未必非要是地理空间，其实只是由两个数值的键构成，只要满足条件就可以构建索引，故此并不一定只局限于地理，只是叫法如此而已，若想要有其他的用法，并满足数据的表示类型，也可以用此类方法。
观察上图可知，在MongoDB 里面还提供许多类似于函数的工具，可以用来进行查找应用。例如Count 可以查询在此collection 里面document 的数量；Distinct与SQL 语句里面一致，people 这个collection 里面不同的年龄的数量，结果为20、35、60岁等，和distinct 里面的写法是一致的，但是含义是不一致的。为了体现MongoDB 的优势，示例如下：
假设现在需要销售手机，做一个关系型数据库存储手机，有两张表格，第一张表格为mobiles ，有id 、名字和品牌，第二个表格为手机的参数，第二个mobile_id 与一个id是关联的，表明在介绍某个手机的参数，底下为名字及价值，这些可以用一张表格进行替代。横行依次为id 、name、brand 、屏幕类型、屏幕尺寸等需要的参数，不同的手机参数是不一致的，在关系型数据库里面就无法对此进行要求，若非要此要求，则结果iPhone 手机与三星手机的参数是不一致的，需要将所有属性列出，故表格就会变得特别庞大，因为有些手机没有部分属性，但又不能约束为空，这与所有不同的子类需要承接到一张表里是一样的，故此方法不太方便也不能扩展，若未来新出一款手机强调为耳机，但是表格内容已经确定，故不好进行修改。为了解决此类问题，各种各样的手机参数可以不一致并且参数可以进行拓展，故此将列转化为行进行存储，故就有了两张表格。如果一个苹果手机拥有十个属性，就会在第二张表格里出现十条记录，若三星手机拥有八种属性，对应第二张表格里面就有八条记录。就是将列转化成行进行存储，此为解决数据异构的一种想法，一个基本的操作为当苹果的手机与三星的手机差异较大的情况下，可以使用这种操作，这是在关系型数据库里面的做法。
然后将数据插入进去，如图所示，第一个为iPhone ，第二个为三星，下面对应内容为：iPhone 的待机时间评分为200，屏幕为OLED型，而三星的待机时间评分为300，屏幕为曲面屏，以上为手机的某些参数，如此手机属性的描述就完成了。
观察可知，若想要查找待机时间大于100的手机，可以进行搜索，搜索查询结果为苹果及三星的手机，同时也可以查询具有屏幕属性的，且屏幕为OLED 的手机，但是无论使用何种方式进行查找，都是使用这种方式获得了一个ID ，通过此id 再到mobile 里面进行查找，意思为使用第二张表里手机的属性查询到符合条件的第一张表里手机的类型型号，此过程为数据库的join 操作。很显然，在关系型数据库里面，为了保证数据库不一致且可扩展，故必须进行join 操作，若两个条件都需要满足，需要得到两个查询结果交集的id ，再到表里进行连接操作。
无论如何，现在需要进行join 操作，此为最大的问题之一，join 属于一种较慢的操作，要将两张表放置到一起进行关联，且不能保证得到的为一个值，若得到的为一个数组，再到mobile 表格里进行查找，两个集合一个较大一个较小，再进行交集，虽然算法可以优化，但速度还是较慢，若替换成MongoDB ，效率会有所提升。
