MongoDB数据模型设计指南：文档结构与应用实践

需积分: 12 36 浏览量更新于2024-07-22 收藏 6.02MB PDF 举报

在设计现代应用程序的数据模型时，特别是在使用非关系型数据库（NoSQL）系统如MongoDB时，设计模式起着至关重要的作用。与传统的关系型数据库（RDBMS）如MySQL不同，MongoDB采用文档存储方式，而非固定表格结构。在MongoDB中，数据是以键值对形式的 BSON（Binary JSON）文档组织的，这使得数据可以包含嵌套的数组和子文档，提供了更大的灵活性和复杂度。设计模式在MongoDB中主要关注如何有效地利用这种非结构化存储特性来支持应用程序的不同需求。以下是一些关键的设计模式： 1. **文档模式**（Document-oriented Design）：MongoDB的核心设计理念是文档，每个文档代表一个独立的对象实例，可以包含多种类型的字段，包括嵌套对象。这种模式鼓励数据的紧密耦合，减少数据冗余，但可能需要在查询和聚合操作时更加细致地考虑数据结构。 2. **分片（Sharding）**：为了处理大规模数据，MongoDB支持水平分割数据到多个物理服务器，称为分片。设计时需考虑数据的自然分布，以及如何通过分片键（shard key）来均匀分布数据。 3. **集合（Collections）**：每个文档都属于一个集合，类似于表，但集合中的文档可以有完全不同的结构。设计时应选择合适的集合结构，避免过多的索引创建，以保持性能。 4. **文档结构一致性**：由于MongoDB支持动态模式，开发人员可以在不破坏数据完整性的情况下添加、修改字段。但为了维护代码清晰和可读性，应该遵循一定的结构模式，并在必要时定义模式验证规则。 5. **嵌套文档（Nested Documents）**：MongoDB中的数组和子文档允许数据层次化，这在处理树状或关联数据结构时非常有用。设计时需要规划好文档结构，以确保查询效率和易用性。 6. **索引优化**：尽管MongoDB默认支持高效的JSON查询，但索引的选择和设计对于性能至关重要。设计时要根据查询模式创建合适的索引，避免全表扫描。 7. **复制集（Replica Sets）**：为了提高可用性和容错性，MongoDB支持复制集架构。设计时要考虑如何在多个副本之间同步数据，以及在出现故障时如何进行自动切换。 8. **查询优化**：MongoDB的查询语言（例如聚合框架Aggregation Framework）有自己的特性和优化技巧。设计时要考虑如何编写高效的查询，充分利用索引和聚合管道。通过遵循这些设计模式，开发人员可以构建出在MongoDB上运行高效、可扩展和易于维护的应用程序。MongoDBAppliedDesignPatterns这本书由Rick Copeland撰写，提供了深入的实践指导，帮助读者理解和应用这些模式。

What Is a Normal Form, Anyway?

Schema normalization typically begins by putting your application data into the first

normal form (1NF). Although there are specific rules that define exactly what 1NF

means, that’s a little beyond what we want to cover here. For our purposes, we can

consider 1NF data to be any data that’s tabular (composed of rows and columns), with

each row-column intersection (“cell”) containing exactly one value. This requirement

that each cell contains exactly one value is, as we’ll see later, a requirement that MongoDB

does not impose, with the potential for some nice performance gains. Back in our re‐

lational case, let’s consider a phone book application. Your initial data might be of the

following form, shown in Table 1-1.

Table 1-1. Phone book v1

id name phone_number zip_code

1 Rick 555-111-1234 30062

2 Mike 555-222-2345 30062

3 Jenny 555-333-3456 01209

This data is actually already in first normal form. Suppose, however, that we wished to

allow for multiple phone numbers for each contact, as in Table 1-2.

Table 1-2. Phone book v2

id name phone_numbers zip_code

1 Rick 555-111-1234 30062

2 Mike 555-222-2345;555-212-2322 30062

3 Jenny 555-333-3456;555-334-3411 01209

Now we have a table that’s no longer in first normal form. If we were to actually store

data in this form in a relational database, we would have to decide whether to store

phone_numbers as an unstructured BLOB of text or as separate columns (i.e., phone_num

ber0, phone_number1). Suppose we decided to store phone_numbers as a text column,

as shown in Table 1-2. If we needed to implement something like caller ID, finding the

name for a given phone number, our SQL query would look something like the

following:

SELECT name FROM contacts WHERE phone_numbers LIKE '%555-222-2345%';

Unfortunately, using a LIKE clause that’s not a prefix means that this query requires a

full table scan to be satisfied.

Alternatively, we can use multiple columns, one for each phone number, as shown in

Table 1-3.

4 | Chapter 1: To Embed or Reference

Table 1-6. Phone book v4 (numbers)

contact_id phone_number

1 555-111-1234

2 555-222-2345

2 555-212-2322

3 555-333-3456

3 555-334-3411

As part of this step, we must identify a key column which uniquely identifies each row

in the table so that we can create links between the tables. In the data model presented

in Table 1-5 and Table 1-6, the contact_id forms the key of the contacts table, and the

(contact_id, phone_number) pair forms the key of the numbers table. In this case, we

have a data model that is free of redundancy, allowing us to update a contact’s name, zip

code, or various phone numbers without having to worry about updating multiple

rows. In particular, we no longer need to worry about inconsistency in the data model.

So What’s the Problem?

As already mentioned, the nice thing about normalization is that it allows for easy

updating without any redundancy. Each fact about the application domain can be up‐

dated by changing just one value, at one row-column intersection. The problem arises

when you try to get the data back out. For instance, in our phone book application, we

may want to have a form that displays a contact along with all of his or her phone

numbers. In cases like these, the relational database programmer reaches for a JOIN:

SELECT name, phone_number

FROM contacts LEFT JOIN numbers

ON contacts.contact_id=numbers.contact_id

WHERE contacts.contact_id=3;

The result of this query? A result set like that shown in Table 1-7.

Table 1-7. Result of JOIN query

name phone_number

Jenny 555-333-3456

Jenny 555-334-3411

Indeed, the database has given us all the data we need to satisfy our screen design. The

real problem is in what the database had to do to create this result set, particularly if the

database is backed by a spinning magnetic disk. To see why, we need to briefly look at

some of the physical characteristics of such devices.

Spinning disks have the property that it takes much longer to seek to a particular location

on the disk than it does, once there, to sequentially read data from the disk (see

6 | Chapter 1: To Embed or Reference

剩余174页未读，继续阅读

scutgui

粉丝: 1
资源: 8

MongoDB数据模型设计指南：文档结构与应用实践

[奥莱理] MongoDB Applied Design Patterns

MongoDB资料汇总.rar

MongoDB Applied Design Patterns

flask-login-template:烧瓶+ mongodb的锅炉板

高清彩版 Node.js Design Patterns, 2nd Edition

The.Little.Mongo.DB.Schema.Design.Book151739402

【Design Expert插件开发教程】：中文版插件创建与应用：定制化你的设计工具

基于net的超市管理系统源代码（完整前后端+sqlserver+说明文档+LW）.zip

LABVIEW程序实例-公式节点.zip

大米商城开源版damishop(适合外贸)

最新资源