阅读量:2
目录
1.由文档存储牵出的问题
本文或者说关于mongodb的这个系列文章的源头：
前面我们聊过了分布式链路追踪系统，在基于日志实现的分布式链路追踪的方式seluth+zipkin中为了防止数据丢失，需要将数据持久化。我们给出的是持久化进mysql中的示例。
https://bugman.blog.csdn.net/article/details/135258207?spm=1001.2014.3001.5502
后面我们发现存放日志以及需要进行后期统计这个场景来说的话关系型数据库是不合适的，于是引出了用ES系列：
https://bugman.blog.csdn.net/article/details/135342256?spm=1001.2014.3001.5502
https://bugman.blog.csdn.net/article/details/135425284?spm=1001.2014.3001.5502
https://bugman.blog.csdn.net/article/details/135515805?spm=1001.2014.3001.5502
https://bugman.blog.csdn.net/article/details/135581380?spm=1001.2014.3001.5502
聊完ES后，这时候我们难免就避不开mongodb这个热门的文档数据库，什么是MongoDB，MongoDB的核心概念，ES和MongoDB的对比，将会是本文的核心内容。
2.什么是MongoDB？
MongoDB（由“Humongous Database”缩写而来）是一种开源的、面向文档的 NoSQL 数据库系统，自4.0版本开始支持ACID。它在设计上采用了分布式文件存储的思想，适用于大规模数据的存储和处理。
说的直白点，MongoDB在设计的时候就是冲着解决海量文档的存储来的。
mongodb的架构如下：
database（数据库）：数据库是一个仓库，里面可以存放集合。
collection（集合）：类似于数组，可以在集合中存放文档。
document（文档）：mongodb最小的单位，我们存储和操作的内容都是文档。
数据库类比数据库，集合类比表，文档类比一条数据。
数据库和集合都不需要我们手动创建，当我们创建文档时，文档所在的数据库或者集合不存在，会自动创建数据库和集合。
mongodb的数据结构：
MongoDB的数据结构是其用来应对海量文档存储的核心，其是以类JSON的方式来存储数据，也就是BSON。BSON是二进制的，这样做的目的是为了增强存储能力，具体的细节后文说。先来看看JSON和BSON的比较：
假设我们有如下的 JSON 对象，用于描述一个人的基本信息：
这个 JSON 对象包含了一些基本的数据类型，如字符串、数字、布尔值、对象和数组。
{
"name": "John Doe",
"age": 30,
"isStudent": false,
"birthday": "1990-01-01",
"address": {
"street": "123 Main St",
"city": "Anytown"
},
"hobbies": ["reading", "cycling"]
}
现在，我们将同样的数据转换为 BSON 格式。在 BSON 中，我们可以使用一些 JSON 中不存在的数据类型。以下是 BSON 版本的同一数据，包含一些 BSON 特有的字段（请注意，这是概念性的表示，因为 BSON 实际上是二进制格式，无法以纯文本形式直观展示）：
{
"name": "John Doe", // 字符串
"age": Int32(30), // 32位整数
"isStudent": false, // 布尔值
"birthday": ISODate("1990-01-01"), // 日期类型
"address": { // 嵌套文档
"street": "123 Main St",
"city": "Anytown"
},
"hobbies": ["reading", "cycling"]// 数组
}
在这个 BSON 示例中，我们可以看到一些与 JSON最大的不同就是其数据是有类型的，BSON最是二进制的，有类型声明这样能准确的从二进制里解析出准确的值来，从而避免了还要转一遍的这种解析过程。所有我们可以看到BSON是很适合用来进行文档存储的，二进制化后减小了原始数据的体积，又由于有类型的存在，能直接读出来，又很适合检索。
3.ES和MongoDB的对比
其实到这里很多人都会有疑惑，ES和MongoDB都能存储海量文档，都支持文档的搜索，很多功能上都是高度重合的，那为什么会出现如此相似的两个东西？他们各自的应用场景有什么不同？
首先我们要知道：
ES的核心是冲着全文检索去的，MongoDB的核心是冲着文档存储去的。
全文搜索和文档存储在某种程度上可以被视为对立的或至少是有着不同优化方向的技术，也就是说二者是不能相互兼顾的，只能二选一。
全文搜索的特点：
- 全文搜索的核心在于能够快速有效地检索出包含特定词汇或词组的文档。
- 为此，搜索引擎（如 Elasticsearch）建立复杂的索引来存储每个词汇的出现位置、频率等信息。
- 这些索引通常需要快速访问，因此搜索引擎可能会牺牲一些存储效率来提高读取速度。
文档存储的特点：
- 文档存储（如 MongoDB）主要关注于存储和查询结构化或半结构化数据。
- 这些系统可能采用不同的存储优化技术，如数据压缩、分片等，以提高存储效率和处理大量数据的能力。
- 文档数据库的索引通常不是为了全文搜索设计的，而是为了快速查找特定字段或数据结构。
优化方向的差异：
- 全文搜索引擎的设计重点在于最大化检索效率，特别是在处理大量文本数据时的搜索性能。
- 文档数据库则更侧重于数据的灵活性、存储效率和结构化查询的性能。
OK，到这里其实我们就已经知道了ES和MongoDB最核心的区别了，也就不会疑惑。也可以得出:
es拥有更细粒度的查询能力，也就是能对全文进行各种检索，但在文档的存储上要差一点。
MongoDB在文档的存储上更优秀，适合存储海量文档，但是只支持简单的文档搜索，而不是全文检索。
