MongoDB 入门指南：了解 NoSQL 数据库的基本概念

NoSql

BigData

需积分: 7 183 浏览量更新于2024-07-18 收藏 1.66MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

MongoDB Basic MongoDB 是一个跨平台的文档oriented数据库程序，使用 JSON 类似的文档与架构。它是一个 NoSQL 数据库程序，发行于 Server Side Public License version 1 许可证下。 MongoDB 的出现填补了传统关系型数据库的不足之处，提供了更加灵活和高效的数据存储解决方案。在 MongoDB 中，每个文档都可以拥有不同的架构，而不需要像传统关系型数据库那样，需要定义固定的表结构。这样，MongoDB 就可以更好地适应快速变化的数据结构和大数据时代的需求。 MongoDB 的特点： 1. 文档oriented：MongoDB 使用 JSON 类似的文档来存储数据，每个文档都可以拥有不同的架构。 2. NoSQL：MongoDB 是一个 NoSQL 数据库程序，不需要定义固定的表结构。 3. 跨平台：MongoDB 可以在多种平台上运行，包括 Windows、Linux 和 macOS 等。 4. 高性能：MongoDB 采用了高性能的存储引擎，可以快速地存储和检索大量数据。 5. 高可扩展性：MongoDB 可以水平扩展，以满足大规模数据存储的需求。 MongoDB 的应用场景： 1. 大数据存储：MongoDB 可以存储大量的半结构化数据，适合大数据时代的需求。 2. 实时数据处理：MongoDB 可以实时处理大量数据，适合实时数据分析和处理的需求。 3. 云计算：MongoDB 可以在云计算平台上运行，提供了高效的数据存储和处理解决方案。 4. 移动应用：MongoDB 可以用于移动应用的数据存储和处理，提供了高效的数据同步和实时更新机制。 MongoDB 的优点： 1. 高灵活性：MongoDB 可以适应快速变化的数据结构和大数据时代的需求。 2. 高性能：MongoDB 采用了高性能的存储引擎，可以快速地存储和检索大量数据。 3. 高可扩展性：MongoDB 可以水平扩展，以满足大规模数据存储的需求。 4. 跨平台：MongoDB 可以在多种平台上运行，包括 Windows、Linux 和 macOS 等。 MongoDB 的挑战： 1. 学习曲线：MongoDB 的学习曲线较陡，需要一定的技术背景和经验。 2. 数据一致性：MongoDB 的数据一致性需要特殊的注意和处理。 3. 安全性：MongoDB 的安全性需要特殊的注意和处理，以防止未经授权的访问和数据泄露。 MongoDB 是一个功能强大且灵活的 NoSQL 数据库程序，适合大数据时代的需求。然而，MongoDB 也存在一定的挑战和不足之处，需要技术人员具备一定的技术背景和经验，并且需要特殊的注意和处理。

资源详情

资源推荐

CHAPTER 1 ■ INTRODUCTION TO MONGODB

The second key benefit to using BSON is that it is easy and quick to convert BSON

to a programming language’s native data format. If the data were stored in pure JSON, a

relatively high-level conversion would need to take place. There are MongoDB drivers for

a large number of programming languages (such as Python, Ruby, PHP, C, C++, and C#),

and each works slightly differently. Using a simple binary format, native data structures

can be quickly built for each language, without requiring that you first process JSON. This

makes the code simpler and faster, both of which are in keeping with MongoDB’s stated

goals.

BSON also provides some extensions to JSON. For example, it enables you to store

binary data and to incorporate a specific datatype. Thus, while BSON can store any JSON

document, a valid BSON document may not be valid JSON. This doesn’t matter, because

each language has its own driver that converts data to and from BSON without needing to

use JSON as an intermediary language.

At the end of the day, BSON is not likely to be a big factor in how you use MongoDB.

Like all great tools, MongoDB will quietly sit in the background and do what it needs to

do. Apart from possibly using a graphical tool to look at your data, you will generally work

in your native language and let the driver worry about persisting to MongoDB.

Supporting Dynamic Queries

MongoDB’s support for dynamic queries means that you can run a query without

planning for it in advance. This is similar to being able to run SQL queries against an

RDBMS. You might wonder why this is listed as a feature; surely it is something that every

database supports—right?

Actually, no. For example, CouchDB (which is generally considered MongoDB’s

biggest “competitor”) doesn’t support dynamic queries. This is because CouchDB has

come up with a completely new (and admittedly exciting) way of thinking about data. A

traditional RDBMS has static data and dynamic queries. This means that the structure

of the data is fixed in advance—tables must be defined, and each row has to fit into that

structure. Because the database knows in advance how the data is structured, it can make

certain assumptions and optimizations that enable fast dynamic queries.

CouchDB has turned this on its head. As a document-oriented database, CouchDB is

schemaless, so the data is dynamic. However, the new idea here is that queries are static.

That is, you define them in advance, before you can use them.

This isn’t as bad as it might sound, because many queries can be easily defined

in advance. For example, a system that lets you search for a book will probably let you

search by ISBN. In CouchDB, you would create an index that builds a list of all the ISBNs

for all the documents. When you punch in an ISBN, the query is very fast because it

doesn’t actually need to search for any data. Whenever new data is added to the system,

CouchDB will automatically update its index.

Technically, you can run a query against CouchDB without generating an index;

in that case, however, CouchDB will have to create the index itself before it can process

your query. This won’t be a problem if you only have a hundred books; however, it will

result in poor performance if you’re filing hundreds of thousands of books, because each

query will generate the index again (and again). For this reason, the CouchDB team does

not recommend dynamic queries—that is, queries that haven’t been predefined—in

production.

www.it-ebooks.info

CHAPTER 1 ■ INTRODUCTION TO MONGODB

CouchDB also lets you write your queries as map and reduce functions. If that sounds

like a lot of effort, then you’re in good company; CouchDB has a somewhat severe

learning curve. In fairness to CouchDB, an experienced programmer can probably pick it

up quite quickly; for most people, however, the learning curve is probably steep enough

that they won’t bother with the tool.

Fortunately for us mere mortals, MongoDB is much easier to use. We’ll cover how

to use MongoDB in more detail throughout the book, but here’s the short version: in

MongoDB, you simply provide the parts of the document you want to match against, and

MongoDB does the rest. MongoDB can do much more, however. For example, you won’t

find MongoDB lacking if you want to use map or reduce functions. At the same time, you can

ease into using MongoDB; you don’t have to know all of the tool’s advanced features up front.

Indexing Your Documents

MongoDB includes extensive support for indexing your documents, a feature that really

comes in handy when you’re dealing with tens of thousands of documents. Without an

index, MongoDB will have to look at each individual document in turn to see whether it

is something that you want to see. This is like asking a librarian for a particular book and

watching as he works his way around the library looking at each and every book. With an

indexing system (libraries tend to use the Dewey Decimal system), he can find the area

where the book you are looking for lives and very quickly determine if it is there.

Unlike a library book, all documents in MongoDB are automatically indexed on the

_id key. This key is considered a special case because you cannot delete it; the index is

what ensures that each value is unique. One of the benefits of this key is that you can be

assured that each document is uniquely identifiable, something that isn’t guaranteed by

an RDBMS.

When you create your own indexes, you can decide whether you want them to

enforce uniqueness. If you do decide to create a unique index, you can tell MongoDB

to drop all the duplicates. This may or may not be what you want, so you should think

carefully before using this option because you might accidentally delete half your data.

By default, an error will be returned if you try to create a unique index on a key that has

duplicate values.

There are many occasions where you will want to create an index that allows

duplicates. For example, if your application searches by lastname, it makes sense to build

an index on the lastname key. Of course, you cannot guarantee that each lastname will be

unique; and in any database of a reasonable size, duplicates are practically guaranteed.

MongoDB’s indexing abilities don’t end there, however. MongoDB can also create

indexes on embedded documents. For example, if you store numerous addresses in the

address key, you can create an index on the ZIP or postal code. This means that you can

easily pull back a document based on any postal code—and do so very quickly.

MongoDB takes this a step further by allowing composite indexes. In a composite

index, two or more keys are used to build a given index. For example, you might build

an index that combines both the lastname and firstname tags. A search for a full name

would be very quick because MongoDB can quickly isolate the lastname and then, just as

quickly, isolate the firstname.

We will look at indexing in more depth in Chapter 10, but suffice it to say that

MongoDB has you covered as far as indexing is concerned.

www.it-ebooks.info

CHAPTER 1 ■ INTRODUCTION TO MONGODB

Leveraging Geospatial Indexes

One form of indexing worthy of special mention is geospatial indexing. This new,

specialized indexing technique was introduced in MongoDB 1.4. You use this feature to

index location-based data, enabling you to answer queries such as how many items are

within a certain distance from a given set of coordinates.

As an increasing number of web applications start making use of location-based

data, this feature will play an increasingly prominent role in everyday development. For

now, though, geospatial indexing remains a somewhat niche feature; nevertheless, you

will be very glad it’s there if you ever find that you need it.

Profiling Queries

A built-in profiling tool lets you see how MongoDB works out which documents to return.

This is useful because, in many cases, a query can be easily improved simply by adding

an index. If you have a complicated query, and you’re not really sure why it’s running

so slowly, then the query profiler can provide you with extremely valuable information.

Again, you’ll learn more about the MongoDB Profiler in Chapter 10.

Updating Information In-Place

When a database updates a row (or in the case of MongoDB, a document), it has a couple

of choices about how to do it. Many databases choose the multi-version concurrency

control (MVCC) approach, which allows multiple users to see different versions of the

data. This approach is useful because it ensures that the data won’t be changed partway

through by another program during a given transaction.

The downside to this approach is that the database needs to track multiple copies of

the data. For example, CouchDB provides very strong versioning, but this comes at the

cost of writing the data out in its entirety. While this ensures that the data is stored in a

robust fashion, it also increases complexity and reduces performance.

MongoDB, on the other hand, updates information in-place. This means that (in contrast

to CouchDB) MongoDB can update the data wherever it happens to be. This typically means

that no extra space needs to be allocated, and the indexes can be left untouched.

Another benefit of this method is that MongoDB performs lazy writes. Writing to and

from memory is very fast, but writing to disk is thousands of times slower. This means

that you want to limit reading and writing from the disk as much as possible. This isn’t

possible in CouchDB, because that program ensures that each document is quickly

written to disk. While this approach guarantees that the data is written safely to disk, it

also impacts performance significantly.

MongoDB only writes to disk when it has to, which is usually once every second or

so. This means that if a value is being updated many times a second—a not uncommon

scenario if you’re using a value as a page counter or for live statistics—then the value will

only be written once, rather than the thousands of times that CouchDB would require.

This approach makes MongoDB much faster, but, again, it comes with a tradeoff.

CouchDB may be slower, but it does guarantee that data is stored safely on the disk.

MongoDB makes no such guarantee, and this is why a traditional RDBMS is probably a

better solution for managing critical data such as billing or accounts receivable.

www.it-ebooks.info

CHAPTER 1 ■ INTRODUCTION TO MONGODB

Storing Binary Data

GridFS is MongoDB’s solution to storing binary data in the database. BSON supports

saving up to 4MB of binary data in a document, and this may well be enough for your

needs. For example, if you want to store a profile picture or a sound clip, then 4MB

might be more space than you need. On the other hand, if you want to store movie clips,

high-quality audio clips, or even files that are several hundred megabytes in size, then

MongoDB has you covered here, too.

GridFS works by storing the information about the file (called metadata) in the files

collection. The data itself is broken down into pieces called chunks that are stored in the

chunks collection. This approach makes storing data both easy and scalable; it also makes

range operations (such as retrieving specific parts of a file) much easier to use.

Generally speaking, you would use GridFS through your programming language’s

MongoDB driver, so it’s unlikely you’d ever have to get your hands dirty at such a low

level. As with everything else in MongoDB, GridFS is designed for both speed and

scalability. This means you can be confident that MongoDB will be up to the task if you

want to work with large data files.

Replicating Data

When we talked about the guiding principles behind MongoDB, we mentioned that

RDBMS databases offer certain guarantees for data storage that are not available in

MongoDB. These guarantees weren’t implemented for a handful of reasons. First,

these features would slow the database down. Second, they would greatly increase the

complexity of the program. Third, it was felt that the most common failure on a server

would be hardware, which would render the data unusable anyway, even if the data were

safely saved to disk.

Of course, none of this means that data safety isn’t important. MongoDB wouldn’t

be of much use if you couldn’t count on being able to access the data when you need it.

Initially, MongoDB provided a safety net with a feature called master-slave replication,

in which only one database is active for writing at any given time, an approach that is

also fairly common in the RDBMS world. This feature has since been replaced with

replica sets, and basic master-slave replication has been deprecated and should no

longer be used.

Replica sets have one primary server (similar to a master), which handles all the

write requests from clients. Because there is only one primary server in a given set, it can

guarantee that all writes are handled properly. When a write occurs it is logged in the

primary’s ‘oplog’.

The oplog is replicated by the secondary servers (of which there can be many) and

used to bring themselves up to date with the master. Should the master fail at any given

time, one of the secondaries will become the primary and take over responsibility for

handling client write requests.

www.it-ebooks.info

CHAPTER 1 ■ INTRODUCTION TO MONGODB

Implementing Sharding

For those involved with large-scale deployments, auto-sharding will probably prove one

of MongoDB’s most significant and oft-used features.

In an auto-sharding scenario, MongoDB takes care of all the data splitting and

recombination for you. It makes sure the data goes to the right server and that queries are

run and combined in the most efficient manner possible. In fact, from a developer’s point

of view, there is no difference between talking to a MongoDB database with a hundred

shards and talking to a single MongoDB server. This feature is not yet production-ready;

when it is, however, it will push MongoDB’s scalability through the roof.

In the meantime, if you’re just starting out or you’re building your first MongoDB-

based website, then you’ll probably find that a single instance of MongoDB is sufficient

for your needs. If you end up building the next Facebook or Amazon, however, you will be

glad that you built your site on a technology that can scale so limitlessly. Sharding is the

topic of Chapter 12 of this book.

Using Map and Reduce Functions

For many people, hearing the term MapReduce sends shivers down their spines. At

the other extreme, many RDBMS advocates scoff at the complexity of map and reduce

functions. It’s scary for some because these functions require a completely different way

of thinking about finding and sorting your data, and many professional programmers

have trouble getting their heads around the concepts that underpin map and reduce

functions. That said, these functions provide an extremely powerful way to query data.

In fact, CouchDB supports only this approach, which is one reason it has such a high

learning curve.

MongoDB doesn’t require that you use map and reduce functions. In fact,

MongoDB relies on a simple querying syntax that is more akin to what you see in

MySQL. However, MongoDB does make these functions available for those who want

them. The map and reduce functions are written in JavaScript and run on the server.

The job of the map function is to find all the documents that meet a certain criteria.

These results are then passed to the reduce function, which processes the data. The

reduce function doesn’t usually return a collection of documents; rather, it returns a

new document that contains the information derived. As a general rule, if you would

normally use GROUP BY in SQL, then the map and reduce functions are probably the

right tools for the job in MongoDB.

Note ■ You should not think of MongoDB’s map and reduce functions as poor imitations

of the approach adopted by CouchDB. If you so desired, you could use MongoDB’s map and

reduce functions for everything in lieu of MongoDB’s innate query support.

www.it-ebooks.info

剩余132页未读，继续阅读

FZhang70

粉丝: 0
资源: 2

MongoDB 入门指南：了解 NoSQL 数据库的基本概念

MongoDB.Data.Modeling.1782175342

boot+security4+mongodb+mybatis

Due to limitations of the com.mongodb.BasicDocument, you can't add a second 'null' criteria. Query already contains

visual basic数据库管理系统编程

mongodb find

如何通过 "$nearSphere" 操作符实现了根据经纬度查找范围内所有点位的功能

pymongo TypeError: 'Database' object is not callable

et(express)2010

spring boot sec

写一个前后端分离的java系统

Django 安装包 linux

#-ssm-056-mysql-水稻朔源信息系统.zip

基于springboot毕业设计成绩管理系统的设计与实现.docx

全球与中国工业内窥镜市场现状及未来发展趋势（2024版）.docx

SWAN-time.bin

“人力资源+大数据+薪酬报告+涨薪调薪”

Avanza-0.0.6-py3-none-any.whl.zip

人大金仓Kingbase数据库安装教程

最新资源