Phplx mongodb

MongoDB
Indexing and Query
Optimization
Quinta-feira, 8 de Agosto de 13

Agenda
Indexes in MongoDB
Optimizing Queries
Mistakes

About me
15 years programming experience
Software Developer and MSSQL DBA @ Com-
UT/Sedimap
playing around with MongoDB about 3 years

Com-UT/Sedimap an Fleet Management Company (Vehicle
track)
using MongoDB in Production about 2 years
replicaset with 5 nodes
about 3.5M of messages arrive from GPS devices and are
processed by our communication server (in Node.js) before
go to MongoDB
can check in http://www.mongodb.org/about/production-
deployments/ and ﬁnd by COMUT

MongoDB, some wiki
font: wikipédia
developed and supported by 10gen
NoSQL DB, document-oriented database
stores structured data as JSON-like documents
with dynamic schemas
BSON - binary-encoded serialization

Indexes

indexes are the single biggest
tunable performance factor in
MongoDB
absent or suboptimal indexes are
the most common avoidable
MongoDB performance problem

the application’s queries
the relative frequency of each query
in the application
which indexes the most common
queries use
Indexing Strategies

Create indexes
db.collection.createIndex({field_name: 1})
db.collection.ensureIndex({field_name: -1})
db.collection.ensureIndex(
{field_name: -1},
{background: true}
)

Manage indexes
db.collection.getIndexes()
db.collection.getIndexStats({index:”name”})
db.collection.dropIndexes()
db.collection.dropIndex(“index_name”)
db.collection.reIndex()

What can be indexed?
single field {a: 1}
compound keys / multiple fields {a: 1, b: -1}
multikeys indexes / arrays of values {a: [1,2,3]}
subdocuments
"address": {
"street": "Main”
"zipcode": 53511
"state": "WI"
}
embedded fields {“address.state”: 1}

_id index, is the primary key for the collection and
every doc must have a unique _id ﬁeld
ObjectId("5038050ef719dd2122000004")
Instead of using the ObjectID
_id: {a: 1, b: 1, c: 1}
_id

Options
Unique, dropDups
Sparse indexes
Geospatial indexes (2d)
TTL collections (expireAfterSeconds)

Unique & dropDups
db.collection.ensureIndex({a: 1}, {unique: true})
{a: 1},
{unique: true, dropDups: true}
)

Sparse indexes
db.collection.ensureIndex({b: 1}, {sparse: true})
{b: 1},
{sparse: true, unique: true}
)
Missing ﬁelds are stored as null(s) in the index
1 - db.collection.insert({a: 12})
2 - db.collection.insert({a: 122, b:12})
Attention with sort

Geospatial indexes
db.collection.ensureIndex({loc:“2dsphere”})
{
name:“phplx”,
loc: { type:“Point”, coordinates: [-9.145858, 38.731103]}
}
db.collection.ﬁnd({
loc: {$near: {
$geometry: {
$type:“Point”,
coordinates: [-9.145858, 38.731103]
}}}})

TTL collections
Document must have a BSON UTC Date ﬁeld
{
a: 12,
b: 455,
c: 2323,
status: ISODate(“2013-08-08T12:00:00Z”)
}
{"status": 1},
{expireAfterSeconds: 3600}
)
Documents are removed after ‘expireAfterSeconds’ seconds

Limitations
collections can not have > 64 indexes
queries can only use one index
indexes have storage requirements, and impacts
insert/update speed to some degree
operator $or

Optimizing
Queries

Explain - case A
> db.events.ﬁnd().explain()

Explain - case B
> db.events.ﬁnd({
tmx: ISODate("2012-09-09T17:00:50Z"),
mid: 41638,
eid: 46511
}).explain()

Explain - case C
db.events.ﬁnd({
tmx:ISODate("2012-09-09T17:00:50Z"), mid:41638, eid:46511
}, {
tmx: 1, mid: 1, eid: 1, _id: 0
}).explain()

Profiling operations
db.setProfilingLevel(level, slowms)
level
0 = profiler off
1 = record ops longer than slowms
2 = record all queries
db.system.profile.find()
the profile collection is a capped collection and fixed in size

Hint a index
we can tell the database what index to use
db.collection.ﬁnd({b: {$gt: 120}})
.hint({a: 1})
or tell the database to not use an index
db.collection.ﬁnd({b: {$gt: 120}})
.hint({$natural: 1})

The query optimizer
for each “type” of query, MongoDB periodically
tries all useful indexes
aborts the rest as soon as one plan win
the winning plan is temporarily cached for each
“type” of query

Mistakes

trying to use multiple indexes
db.collection.ensureIndex({a: 1})
db.collection.ensureIndex({b: 1})
// only one of the above indexes is used
db.collection.ﬁnd({a: 3, b: 10})

compound indexes
db.collection.ensureIndex({a: 1, b: 1, c: 1})
// can’t use the index
db.collection.find({c: 100})
// but this can’t
db.collection.find({a: 10, c: 20})
// and this ???
db.collection.find({c: 100}).sort({a: 1});

low selectivity indexes
db.collection.distinct(“a”)
[“java”,“php”,“c++”]
// low selectivity provide little benefit
db.collection.find({a:“php”})
db.collection.ensureIndex({a: 1, created: 1})
// good
db.collection.find({a:“php”}).sort({created: 1})

regular expressions
// left anchored regex queries can use index
db.collection.find({a: /^php/})
// but not generic regex
db.collection.find({a: /php/})
// or insensitive
db.collection.find({a: /Php/i})

negation
// not equal
db.collection.ﬁnd({a: {$ne:‘php’}})
// not in
db.collection.ﬁnd({a: {$nin: [‘java’,‘c++’]}})
// $not operador
db.collection.ensureIndex({a: {$not:‘c#’}})

TO REMEMBER
choosing the right indexes is
one of the most important
things you can do in
MongoDB

THANKYOU

MongoDB online courses
@
10genEducation
are
FREE
try....

QUESTIONS

Phplx mongodb

More Related Content

Viewers also liked

Similar to Phplx mongodb

Recently uploaded

Phplx mongodb