目次
1.由文档存储牵出的问题
2.什么是MongoDB？
3.ES和MongoDB的对比
1.由文档存储牵出的问题
本文大概说关于mongodb的这个系列文章的源头：
前面我们聊过了分布式链路追踪系统，在基于日志实现的分布式链路追踪的方式seluth+zipkin中为了防止数据丢失，需要将数据持久化。我们给出的是持久化进mysql中的示例。
【JAVA】分布式链路追踪技能概论-CSDN博客
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在文档的存储上更优秀，适合存储海量文档，但是只支持简单的文档搜索，而不是全文检索。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
