MongoDB设计模式：企业应用实战指南

需积分: 10 182 浏览量更新于2024-07-25 收藏 9.36MB PDF 举报

"MongoDB Applied Design Patterns" 是一本由Rick Copeland编著的书籍，由O'Reilly Media在2013年出版。本书主要探讨如何将MongoDB的设计模式应用于实际业务场景，解决大数据问题。 MongoDB是一种流行的NoSQL数据库，其非关系型特性和灵活的数据模型使得它在处理大量复杂数据时具有优势。本书通过Python和JavaScript的代码示例，展示了MongoDB如何简化开发过程并允许在扩展数据模型的同时保持高效。 1. **操作智能**：书中介绍了如何利用MongoDB进行实时业务数据分析，提供对业务数据的即时洞察，这对于决策支持和快速响应市场变化至关重要。 2. **电子商务**：书中讨论了将MongoDB用作产品目录主系统或库存管理系统的方法。文档嵌入和多态模式有助于管理商品信息，同时支持快速查询和更新。 3. **内容管理**：MongoDB可以有效地存储内容节点、二进制资产和讨论，适合构建灵活的内容管理系统。作者解释了如何优化这些数据结构以提高性能和可维护性。 4. **在线广告网络**：在广告领域，MongoDB可以用于频率上限广告展示、关键词定位和竞标策略。这些应用涉及大量的实时数据处理和复杂的规则匹配。 5. **社交网络**：针对复杂的社交图谱存储，如Google+的社交网络模型，书中给出了设计和实现的策略。这涉及到用户之间的多对多关系，以及动态更新和查询。 6. **在线游戏**：对于多人在线游戏，MongoDB可以提供并发访问角色和游戏世界数据的能力。这包括确保数据一致性，同时满足高并发读写需求，确保游戏体验流畅。本书不仅提供了理论指导，还包含大量实践案例，旨在帮助读者深入理解如何在实际项目中充分利用MongoDB的特性。无论你是企业开发者还是独立创业者，都能从中获得构建高性能、可扩展应用的宝贵知识。

www.it-ebooks.info

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

www.it-ebooks.info

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

www.it-ebooks.info

剩余174页未读，继续阅读

vanridin

粉丝: 108
资源: 1187

MongoDB设计模式：企业应用实战指南

MongoDB应用设计模式：MongoDB Applied Design Patterns

[奥莱理] MongoDB Applied Design Patterns

MongoDB Applied Design Patterns

MongoDB Applied Design Patterns 2013 python scripts

MongoDB Applied Design Patterns 原版PDF by Copeland

mongodb_applied_design_patterns

MongoDB and Python Patterns and Niall O'Higgins

MongoDB and Python Patterns and processes

HBase.Design.Patterns

nosql-mongodb2013:2013年10代教育/ MongoDB大学课程-开源

最新资源