Mongodb项目实践后的分享
前言
最近将前段时间做的日志服务进行了改进，数据存储改为mongodb，数据流转为：
filebeats收集-->logstash过滤-->mongodb保存
mongodb摸索使用过程中总结了不少东西，分享给大家。如果文中有出入，还望各位指出。
这里只分享一些重要的点，具体实施细节可以去官方网站或者这里去看看
https://www.runoob.com/mongodb/mongodb-tutorial.html
1. Mongodb是什么
1.1 概况
先来一个Google趋势分析，这是2016年至今的Oracle与Mongodb热度趋势，可以发现，后者在稳步上升，前者逐步下降趋势，下面的统计中国关注度很亮眼
再来看看国内趋势分析，国内用的是百度趋势，对比更加明显了，从11年到现在，关注度越来越高，可见mongodb的热度是不容忽视的，特别进来更新功能越来越给力，不仅支持分布式部署，还支持分布式事务，性能也是非常强悍。
1.2 详述
它是一个文档数据库，号称是最像关系型数据库的非关系型数据库，属于NOSQL数据库类，在MongoDB中的一条记录就是一个文档，是一个数据结构，由字段和值对组成。MongoDB文档与JSON对象类似，叫做BSON。字段的值有可能包括其它文档、数组以及文档数组。
下面是他的数据结构：
{
"type":"book",
"title":"The Red Book",
"attributes": {
"color":"red",
"size":"large",
"inside": {
"bookmark":1,
"postitnote":2
},
"outside": {
"dustcover": "worn"
}
}
}
{
"type":"book",
"title":"The Blue Book",
"attributes": {
"color":"blue",
"size":"small",
"inside": {
"map":1
},
"outside": {
"librarystamp": "Local Library"
}
}
}
从上面可以看出，他的数据全是以键值对的形式出现，可能现在你还是对他的数据结构不太清楚，就拿后端最熟悉的关系型数据库对比下一下就立马明了了。
| Oracle | MongoDB |
|---|---|
| ACID Transactions | ACID Transactions |
| Table | Collection |
| Row | Document |
| Column | Field |
| Secondary Index | Secondary Index |
| GROUP_BY | Aggregation Pipeline |
Oracle的表(Table)就是它的集合(Collection),Oracle的行(Row)就是它的文档(Document)，Oracle的列(Column)就是它的字段(Field)。
需要注意的是：
文档中的键/值对是有序的。
文档中的值不仅可以是在双引号里面的字符串，还可以是其他几种数据类型（甚至可以是整个嵌入的文档)。
MongoDB区分类型和大小写。
MongoDB的文档不能有重复的键。
文档的键是字符串。除了少数例外情况，键可以使用任意UTF-8字符。
文档键命名规范：
键不能含有\0 (空字符)。这个字符用来表示键的结尾。
.和$有特别的意义，只有在特定环境下才能使用。
以下划线"_"开头的键是保留的(不是严格要求的)。
聚合查询：Aggregation Pipeline
Aggregation Pipeline的功能类似于关系型数据库的GROUP_BY，可以做很多统计查询操作。
以下是mongodb的几条基本操作对比：
2. 特点
2.1 大的不同点
mongodb与关系型数据库有一个非常大的不同点，关系型数据库的列都是固定的，无法实现对字段的任意扩展。而mongodb不同，它支持对字段的任意扩展，比如上文中提到过的
{
"type":"book",
"title":"The Red Book",
"attributes": {
"color":"red",
"size":"large",
"inside": {
"bookmark":1,
"postitnote":2
},
"outside": {
"dustcover": "worn"
}
}
}
{
"type":"book",
"title":"The Blue Book",
"attributes": {
"color":"blue",
"size":"small",
"inside": {
"map":1
},
"outside": {
"librarystamp": "Local Library"
}
}
}
可以发现：前后inside的属性是不同的，可以随意对表结构进行灵活变换，增加/减少字段，所以非常适合那种对表结构变动频繁的场景。
2.2 事务
早前的Mongodb版本被人所诟病的就是无事务，抑或是事务很鸡肋，但是今年新出的4.x版本已经解决了这些疑问，4.2版本已经可以完美支持分布式事务，如果有事务方面需求的可以去关注一下他的新特性。
2.3 索引
索引通常能够极大的提高查询的效率，如果没有索引，MongoDB在读取数据时必须扫描集合中的每个文件并选取那些符合查询条件的记录。这种扫描全集合的查询效率是非常低的，特别在处理大量的数据时，查询可以要花费几十秒甚至几分钟，这对网站的性能是非常致命的。索引是特殊的数据结构，索引存储在一个易于遍历读取的数据集合中，索引是对数据库表中一列或多列的值进行排序的一种结构
如何创建索引？
>db.collection.createIndex(keys, options)
3 MongoDB 复制（副本集）
MongoDB复制是将数据同步在多个服务器的过程。复制提供了数据的冗余备份，并在多个服务器上存储数据副本，提高了数据的可用性， 并可以保证数据的安全性。复制还允许从硬件故障和服务中断中恢复数据。
3.1 什么是副本集
保障数据的安全性
数据高可用性 (24*7)
灾难恢复
无需停机维护（如备份，重建索引，压缩）
分布式读取数据
3.2 MongoDB副本集原理
1）mongodb的副本集至少需要两个节点。其中一个是主节点，负责处理客户端请求，其余的都是从节点，负责复制主节点上的数据。
2）mongodb各个节点常见的搭配方式为：一主一从、一主多从。
3）主节点记录在其上的所有操作oplog，从节点定期轮询主节点获取这些操作，然后对自己的数据副本执行这些操作，从而保证从节的数据与主节点一致。
（ps:话说这个同步过程还和redis主从同步过程蛮像的）
3.3 副本集特征：
- N 个节点的集群
- 任何节点可作为主节点
- 所有写入操作都在主节点上
- 自动故障转移
- 自动恢复
4 MongoDB分片（Sharding）技术
- 分片（sharding) 是MongoDB用来将大型集合分割到不同服务器（或者说一个集群）上所采用的方法。尽管分片起源于关系型 数据库分区，但MongoDB分片完全又是另一回事。
- 和MySQL分区方案相比，MongoDB的最大区别在于它几乎能自动完成所有事情，只要告诉MongoDB要分配数据，它就能自动维护数据在不同服务器之间的均衡。
4.1 分片的目的
https://docs.mongodb.com/manual/sharding/
分片是一种用于在多台计算机之间分配数据的方法。MongoDB使用分片来支持具有非常大的数据集和高吞吐量操作的部署。具有大数据集或高吞吐量应用程序的数据库系统可能会挑战单个服务器的容量。例如，高查询率可能会耗尽服务器的CPU容量。大于系统RAM的工作集大小会增加磁盘驱动器的I / O容量。
为了解决这些问题,有两个基本的方法: 垂直扩展和水平扩展。
垂直扩展：增加更多的CPU和存储资源来扩展容量。
水平扩展：将数据集分布在多个服务器上。水平扩展即分片。
MongoDB 通过分片支持水平扩展。
4.2 分片设计思想
分片为应对高吞吐量与大数据量提供了方法。使用分片减少了每个分片需要处理的请求数，因此，通过水平扩展，集群可以提高自己的存储容量和吞吐量。举例来说，当插入一条数据时，应用只需要访问存储这条数据的分片。使用分片减少了每个分片存储的数据。
例如：
如果数据库1tb的数据集，并有4个分片，然后每个分片可能仅持有256 GB的数据。如果有40个分片，那么每个切分可能只有25GB的数据。
参考文献及图片出处
(1)https://www.runoob.com/mongodb/mongodb-tutorial.html
(2)https://www.cnblogs.com/duanxz/p/10730121.html
(3)https://docs.mongodb.com/manual/