web api 2 for mvc developers pdf : C# merge pdf SDK control project winforms web page windows UWP mongodb_%20the%20definitive%20guide%20-%20kristina%20chodorow_140112-part1756

"n" : 8332,
"nscannedObjects" : 8332,
"nscanned" : 8332,
"nscannedObjectsAllPlans" : 8332,
"nscannedAllPlans" : 8332,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 0,
"nChunkSkips" : 0,
"millis" : 91,
"indexBounds" : {
"age" : [
"username" : [
"$minElement" : 1
"$maxElement" : 1
"server" : "ubuntu:27017"
This output first tells you what index was used: age_1_username_1. "millis" reports
how fast the query was executed, from the server receiving the request to when it sent
a response. However, it may not always be the number you are looking for. If MongoDB
tried multiple query plans, "millis" will reflect how long it took all of them to run, not
the one chosen as the best.
Next is how many documents were actually returned as a result: "n". This doesn’t reflect
how much work MongoDB did to answer the query: how many index entries and
documents did it have to search? Index entries are described by "nscanned". The num‐
ber of documents scanned is reflected in "nscannedObjects". Finally, if you were using
a sort and MongoDB could not use an index for it, "scanAndOrder" would be true. This
means that MongoDB had to sort the results in memory, which is generally quite slow
and limited to a small number of results.
Now that you know the basics, here is a breakdown of the all of the fields in more detail:
"cursor" : "BtreeCursor age_1_username_1"
BtreeCursor means that an index was used, specifically, the index on age and user‐
name: {"age" : 1, "username" : 1}. You may also see reverse (if the query is
Using explain() and hint() | 99
C# merge pdf - Merge, append PDF files in, ASP.NET, MVC, Ajax, WinForms, WPF
Provide C# Demo Codes for Merging and Appending PDF Document
batch combine pdf; pdf merger
C# merge pdf - VB.NET PDF File Merge Library: Merge, append PDF files in, ASP.NET, MVC, Ajax, WinForms, WPF
VB.NET Guide and Sample Codes to Merge PDF Documents in .NET Project
pdf split and merge; c# merge pdf
traversing the index in reverse direction—say for a sort) or multi, if it is using a
multikey index.
"isMultiKey" : false
If this query used a multikey index (see “Indexing Objects and Arrays” on page 95).
"n" : 8332
This is the number of documents returned by the query.
"nscannedObjects" : 8332
This is a count of the number of times MongoDB had to follow an index pointer to
the actual document on disk. If the query contains criteria that is not part of the
index or requests fields back that aren’t contained in the index, MongoDB must
look up the document each index entry points to.
"nscanned" : 8332
The number of index entries looked at if an index was used. If this was a table scan,
it is the number of documents examined.
"scanAndOrder" : false
If MongoDB had to sort results in memory.
"indexOnly" : false
If MongoDB was able to fulfill this query using only the index entries (as discussed
in “Using covered indexes” on page 90).
In this example, MongoDB found all matching documents using the index, which
we know because "nscanned" is the same as "n". However, the query was told to
return every field in the matching documents and the index only contained the
"age" and "username" fields. If we changed the query to have a second argument,
{"_id" : 0, "age" : 1, "username" : 1}, then it would be covered by the index
and "indexOnly" would be true.
"nYields" : 0
The number of times this query yielded (paused) to allow a write request to proceed.
If there are writes waiting to go, queries will periodically release their lock and allow
them to do so. However, on this system, there were no writes waiting so the query
never yielded.
"millis" : 91
The number of milliseconds it took the database to execute the query. The lower
this number is, the better.
"indexBounds" : {...}
This field describes how the index was used, giving ranges of the index traversed.
As the first clause in the query was an exact match, the index only needed to look
at that value: 42. The second index key was a free variable, as the query didn’t specify
100 | Chapter 5: Indexing
C# WPF PDF Viewer SDK to view, annotate, convert and print PDF in
C#, C# convert PDF to HTML, C# convert PDF to Word, C# extract text from PDF, C# convert PDF to Jpeg, C# compress PDF, C# print PDF, C# merge PDF files, C# view
combine pdfs online; c# merge pdf pages
C# HTML5 PDF Viewer SDK to view PDF document online in C#.NET
C#, C# convert PDF to HTML, C# convert PDF to Word, C# extract text from PDF, C# convert PDF to Jpeg, C# compress PDF, C# print PDF, C# merge PDF files, C# view
adding pdf pages together; merge pdf files
any restrictions to it. Thus, the database looked for values between negative infinity
("$minElement" : 1) and infinity("$maxElement" : 1) for usernames within
"age" : 42.
Let’s take a slightly more complicated example: suppose you have an index on {"user
name" : 1, "age" : 1} and an index on {"age" : 1, "username" : 1}. What
happens if you query for "username" and "age"? Well, it depends on the query:
> db.c.find({age : {$gt : 10}, username : "sally"}).explain()
"cursor" : "BtreeCursor username_1_age_1",
"indexBounds" : [
"username" : "sally",
"age" : 10
"username" : "sally",
"age" : 1.7976931348623157e+308
"nscanned" : 13,
"nscannedObjects" : 13,
"n" : 13,
"millis" : 5
We are querying for an exact match on "username" and a range of values for "age", so
the database chooses to use the {"username" : 1, "age" : 1} index, reversing the
terms of the query. If, on the other hand, we query for an exact age and a range of names,
MongoDB will use the other index:
> db.c.find({"age" : 14"username" : /.*/}).explain()
"cursor" : "BtreeCursor age_1_username_1 multi",
"indexBounds" : [
"age" : 14,
"username" : ""
"age" : 14,
"username" : {
Using explain() and hint() | 101
C# PDF Image Extract Library: Select, copy, paste PDF images in C#
PDF. |. Home ›› XDoc.PDF ›› C# PDF: Extract PDF Image. A powerful C#.NET PDF control compatible with windows operating system and built on .NET framework.
break a pdf into multiple files; pdf merger online
C# PDF Convert to Jpeg SDK: Convert PDF to JPEG images in
›› C# PDF: Convert PDF to Jpeg. C# PDF - Convert PDF to JPEG in C#.NET. C#.NET PDF to JPEG Converting & Conversion Control. Convert PDF to JPEG Using C#.NET.
pdf combine; pdf combine pages
"age" : 14,
"username" : /.*/
"age" : 14,
"username" : /.*/
"nscanned" : 2,
"nscannedObjects" : 2,
"n" : 2,
"millis" : 2
If you find that Mongo is using different indexes than you want it to for a query, you
can force it to use a certain index by using hint(). For instance, if you want to make
sure MongoDB uses the {"username" : 1, "age" : 1} index on the previous query,
you could say the following:
> db.c.find({"age" : 14"username" : /.*/}).hint({"username" : 1"age" : 1})
If a query is not using the index that you want it to and you use a hint to change it, run
an explain() on the hinted query before deploying. If you force MongoDB to use an
index on a query that it does not know how to use an index for, you could end up making
the query less efficient than it was without the index.
The Query Optimizer
MongoDB’s query optimizer works a bit differently than any other database’s. Basically,
if an index exactly matches a query (you are querying for "x" and have an index on
"x"), the query optimizer will use that index. Otherwise, there might be a few possible
indexes that could work well for your query. MongoDB will select a subset of likely
indexes and run the query once with each plan, in parallel. The first plan to return 100
results is the “winner” and the other plans’ executions are halted.
This plan is cached and used subsequently for that query until the collection has seen a
certain amount of churn. Once the collection has changed a certain amount since the
initial plan evaluation, the query optimizer will re-race the possible plans. Plans will
also be reevaluated after index creation or every 1,000 queries.
The "allPlans" field in explain()’s output shows each plan the query tried running.
When Not to Index
Indexes are most effective at retrieving small subsets of data and some types of queries
are faster without indexes. Indexes become less and less efficient as you need to get
larger percentages of a collection because using an index requires two lookups: one to
102 | Chapter 5: Indexing
C# PDF Text Extract Library: extract text content from PDF file in
XDoc.PDF ›› C# PDF: Extract PDF Text. C# PDF - Extract Text from PDF in C#.NET. Best C#.NET PDF text extraction library and component for free download.
pdf mail merge plug in; reader combine pdf
C# PDF insert image Library: insert images into PDF in, ASP
Merge several images into PDF. Insert images into PDF form field. Access to freeware download and online C#.NET class source code.
reader merge pdf; build pdf from multiple files
look at the index entry and one following the index’s pointer to the document. A table
scan only requires one: looking at the document. In the worst case (returning all of the
documents in a collection) using an index would take twice as many lookups and would
generally be significantly slower than a table scan.
Unfortunately, there isn’t a hard-and-fast rule about when an index helps and when it
hinders as it really depends on the size of your data, size of your indexes, size of your
documents, and the average result set size (Table 5-1). As a rule of thumb: if a query is
returning 30% or more of the collection, start looking at whether indexes or table scans
are faster. However, this number can vary from 2% to 60%.
Table 5-1. Properties that affect the effectiveness of indexes
Indexes often work well for r Table scans often work well for
Large collections
Small collections
Large documents
Small documents
Selective queries
Non-selective queries
Let’s say we have an analytics system that collects statistics. Your application queries the
system for all documents for a given account to generate a nice graph of all data from
an hour ago to the beginning of time:
> db.entries.find({"created_at" : {"$lt" : hourAgo}})
We index "created_at" to speed up this query.
When we first launch, this is a tiny result set and returns instantly. But after a couple
weeks, it starts being a lot of data, and after a month this query is already taking too
long to run.
For most applications, this is probably the “wrong” query: do you really want a query
that’s returning most of your data set? Most applications, particularly those with large
data sets, do not. However, there are some legitimate cases where you may want most
or all of your data: you might be exporting this data to a reporting system or using it for
a batch job. In these cases, you would like to return this large proportion of the data set
as fast as possible.
You can force it to do a table scan by hinting {"$natural" : 1}. As described in “Capped
Collections” on page 109$natural specifies on-disk order when used in a sort. In par‐
ticular, $natural forces MongoDB to do a table scan:
> db.entries.find({"created_at" : {"$lt" : hourAgo}}).hint({"$natural" : 1})
One side effect of sorting by "$natural" is that it gives you results in on-disk order.
This is generally meaningless for an active collection: as documents grow and shrink
they’ll be moved around on disk and new documents will be written in the “holes” they
left. However, for insert-only workloads, $natural can be useful for giving you the latest
(or earliest) documents.
When Not to Index | 103
C# PDF Page Insert Library: insert pages into PDF file in
RasterEdge offers detailed guidances for each of those page processing functions, such as how to merge PDF document files by C# code, how to rotate PDF
c# pdf merge; pdf merge documents
C# WinForms Viewer: Load, View, Convert, Annotate and Edit PDF
overview. It provides plentiful C# class demo codes and tutorials on How to Use XDoc.PDF in C# .NET Programming Project. Plenty
attach pdf to mail merge; attach pdf to mail merge in word
Types of Indexes
There are a few index options you can specify when building an index that change the
way the index behaves. The most common variations are described in the following
sections, and more advanced or special-case options are described in the next chapter.
Unique Indexes
Unique indexes guarantee that each value will appear at most once in the index. For
example, if you want to make sure no two documents can have the same value in the
"username" key, you can create a unique index:
> db.users.ensureIndex({"username" : 1}, {"unique" : true})
For example, suppose that we try to insert the following documents on the collection
> db.users.insert({username: "bob"})
> db.users.insert({username: "bob"})
E11000 duplicate key error index: test.users.$username_1  dup key: { : "bob" }
If you check the collection, you’ll see that only the first "bob" was stored. Throwing
duplicate key exceptions is not very efficient, so use the unique constraint for the oc‐
casional duplicate, not to filter out zillions of duplicates a second.
A unique index that you are probably already familiar with is the index on "_id", which
is automatically created whenever you create a collection. This is a normal unique index
(aside from the fact that it cannot be dropped as other unique indexes can be).
If a key does not exist, the index stores its value as null for that docu‐
ment. This means that if you create a unique index and try to insert
more than one document that is missing the indexed field, the inserts
will fail because you already have a document with a value of null. See
“Sparse Indexes” on page 106 for advice on handling this.
In some cases a value won’t be indexed. Index buckets are of limited size and if an index
entry exceeds it, it just won’t be included in the index. This can cause confusion as it
makes a document “invisible” to queries that use the index. All fields must be smaller
than 1024 bytes to be included in an index. MongoDB does not return any sort of error
or warning if a document’s fields cannot be indexed due to size. This means that keys
longer than 8 KB will not be subject to the unique index constraints: you can insert
identical 8 KB strings, for example.
104 | Chapter 5: Indexing
Compound unique indexes
You can also create a compound unique index. If you do this, individual keys can have
the same values, but the combination of values across all keys in an index entry can
appear in the index at most once.
For example, if we had a unique index on {"username" : 1, "age" : 1}, the following
inserts would be legal:
> db.users.insert({"username" : "bob"})
> db.users.insert({"username" : "bob""age" : 23})
> db.users.insert({"username" : "fred""age" : 23})
However, attempting to insert a second copy of any of these documents would cause a
duplicate key exception.
GridFS, the standard method for storing large files in MongoDB (see “Storing Files with
GridFS” on page 123), uses a compound unique index. The collection that holds the file
content has a unique index on {"files_id" : 1, "n" : 1}, which allows documents
that look like (in part) the following:
{"files_id" : ObjectId("4b23c3ca7525f35f94b60a2d"), "n" : 1}
{"files_id" : ObjectId("4b23c3ca7525f35f94b60a2d"), "n" : 2}
{"files_id" : ObjectId("4b23c3ca7525f35f94b60a2d"), "n" : 3}
{"files_id" : ObjectId("4b23c3ca7525f35f94b60a2d"), "n" : 4}
Note that all of the values for "files_id" are the same, but "n" is different.
Dropping duplicates
If you attempt to build a unique index on an existing collection, it will fail to build if
there are any duplicate values:
> db.users.ensureIndex({"age" : 1}, {"unique" : true})
E11000 duplicate key error index: test.users.$age_1  dup key: { : 12 }
Generally, you’ll need to process your data (the aggregation framework can help) and
figure out where the duplicates are and what to do with them.
In a few rare cases, you may just want to delete documents with duplicate values. The
"dropDups" option will save the first document found and remove any subsequent
documents with duplicate values:
> db.people.ensureIndex({"username" : 1}, {"unique" : true"dropDups" : true})
"dropDups" forces the unique index build, but it’s a very drastic option; you have no
control over which documents are dropped and which are kept (and MongoDB gives
you no indication of which documents were dropped, if any). If your data is of any
importance, do not use "dropDups".
Types of Indexes | 105
Sparse Indexes
As mentioned in an earlier section, unique indexes count null as a value, so you cannot
have a unique index with more than one document missing the key. However, there are
lots of cases where you may want the unique index to be enforced only if the key exists.
If you have a field that may or may not exist but must be unique when it does, you can
combine the unique option with the sparse option.
If you are familiar with sparse indexes on relational databases, Mon‐
goDB’s sparse indexes are a completely different concept. MongoDB
sparse indexes are basically indexes that need not include every docu‐
ment as an entry.
To create a sparse index, include the sparse option. For example, if providing an email
address was optional but, if provided, should be unique, we could do:
> db.ensureIndex({"email" : 1}, {"unique" : true"sparse" : true})
Sparse indexes do not necessarily have to be unique. To make a non-unique sparse index,
simply do not include the unique option.
One thing to be aware of is that the same query can return different results depending
on whether or not it uses the sparse index. For example, suppose we had a collection
where most of the documents had "x" fields, but one does not:
"_id" : 0 }
"_id" : 1"x" : 1 }
"_id" : 2"x" : 2 }
"_id" : 3"x" : 3 }
When we do a query on "x", it will return all matching documents:
>{"x" : {"$ne" : 2}})
"_id" : 0 }
"_id" : 1"x" : 1 }
"_id" : 3"x" : 3 }
If we create a sparse index on "x", the "_id" : 0 document won’t be included in the
index. So now if we query on "x", MongoDB will use the index and not return the
{"_id" : 0} document:
>{"x" : {"$ne" : 2}})
"_id" : 1"x" : 1 }
"_id" : 3"x" : 3 }
You can use hint() to force it to do a table scan if you need documents with missing
106 | Chapter 5: Indexing
Index Administration
As shown in the previous section, you can create new indexes using the ensureIndex
function. An index only needs to be created once per collection. If you try to create the
same index again, nothing will happen.
All of the information about a database’s indexes is stored in the system.indexes collec‐
tion. This is a reserved collection, so you cannot modify its documents or remove
documents from it. You can manipulate it only through ensureIndex and the dropIn
dexes database command.
When you create an index, you can see its meta information in system.indexes. You can
also run db.collectionName.getIndexes() to see all index information about a given
"v" : 1,
"key" : {
"_id" : 1
"ns" : "",
"name" : "_id_"
"v" : 1,
"key" : {
"y" : 1
"ns" : "",
"name" : "y_1"
"v" : 1,
"key" : {
"x" : 1,
"y" : 1
"ns" : "",
"name" : "x_1_y_1"
The important fields are the "key" and "name". The key can be used for hinting, max,
min, and other places where an index must be specified. This is a place where field order
matters: an index on {"x" : 1, "y" : 1} is not the same as an index on {"y" : 1,
"x" : 1}. The index name is used as identifier for a lot of administrative index opera‐
tions, such as dropIndex. Whether or not the index is multikey is not specified in its
Index Administration | 107
The "v" field is used internally for index versioning. If you have any indexes that do not
have a "v" : 1 field, they are being stored in an older, less efficient format. You can
upgrade them by ensuring that you’re running at least MongoDB version 2.0 and drop‐
ping and rebuilding the index.
Identifying Indexes
Each index in a collection has a name that uniquely identifies the index and is used by
the server to delete or manipulate it. Index names are, by default, key
name1_dir1_keyname2_dir2_..._keynameN_dirN, where keynameX is the index’s key
and dirX is the index’s direction (1 or -1). This can get unwieldy if indexes contain more
than a couple keys, so you can specify your own name as one of the options to ensur
>{"a" : 1"b" : 1"c" : 1, ..., "z" : 1}, 
... {"name" : "alphabet"})
There is a limit to the number of characters in an index name, so complex indexes may
need custom names to be created. A call to getLastError will show if the index creation
succeeded or why it didn’t.
Changing Indexes
As your application grows and changes, you may find that your data or queries have
changed and that indexes that used to work well no longer do. You can remove unneeded
indexes using the dropIndex command:
> db.people.dropIndex("x_1_y_1")
"nIndexesWas" : 3"ok" : 1 }
Use the "name" field from the index description to specify which index to drop.
Building new indexes is time-consuming and resource-intensive. By default, MongoDB
will build an index as fast as possible, blocking all reads and writes on a database until
the index build has finished. If you would like your database to remain somewhat re‐
sponsive to reads and writes, use the background option when building an index. This
forces the index build to occasionally yield to other operations, but may still have a
severe impact on your application (see “Building Indexes” on page 222 for more infor‐
mation). Background indexing is also much slower than foreground indexing.
If you have the choice, creating indexes on existing documents is slightly faster than
creating the index first and then inserting all documents.
There is more on the operational aspects of building indexes in Chapter 18.
108 | Chapter 5: Indexing
Documents you may be interested
Documents you may be interested