Application Design per MongoDB

Except where otherwise noted, this work is licensed under: http://creativecommons.org/licenses/by/3.0/

Application Design

FOR MongoDB

Alessandro [email protected]

http://it.linkedin.com/in/alessandropalumbo/http://www.byte-code.com

Saturday, November 30,

mailto:[email protected]


http://it.linkedin.com/in/alessandropalumbo/

http://it.linkedin.com/in/alessandropalumbo/

http://www.byte-code.com

http://www.byte-code.com


Alessandro Palumbo - [email protected] - http://www.byte-code.com

MongoDB




MongoDB

NoSql




MongoDB

NoSql

OPEN-source




MongoDB

NoSql

OPEN-source

Document-OrientedJSON-style documents




MongoDB

from humongous “huge; enormous”

NoSql

OPEN-source

Document-OrientedJSON-style documents




JSON-style documents

{ "_id" : "6c85fa4c-fa64-44e2-89c9-e5eb7f306ed7", "code" : "CRS0001", "name" : "Test", "description" : "Test description", "active" : true, "scheduledDate" : { "from" : ISODate("2013-09-12T00:00:00.000Z"), "to" : ISODate("2013-10-31T00:00:00.000Z") }, "version" : NumberLong(1)}




don’t be relationaL





no joins





no joins

NO FULL transactions





no joins


no SCHEMA





no joins


no SCHEMA

WE CAN EMBED





no joins


no SCHEMA

WE CAN EMBED

DOCUMENT LEVELTRANSACTIONS





no joins


no SCHEMA

WE CAN EMBED

IS IT REALLY AN ISSUE?

DOCUMENT LEVELTRANSACTIONS








friendly fire(aka RTFM)

Write

Concern

READ

PREFERENCE

ATOMIC

DOCUMENT

OPERATIONS

AVOID

NATURAL

KEYS ASIDENTIFIERS





DESIGN

DESIGN

FOR

QUERYEMBEDDED

DATA

vsReferences

DBREFS

VS

MANUALREFERENCE

DYNAMIC

SCHEMA

VSstatic

languages

PURE DRIVER

VS

MAPPINGFRAMEWORKS

BE

CAREFUL

WITH DATES

SPLIT DATA

ON

MULTIPLECOLLECTIONS


Write

Concern

READ

PREFERENCE

ATOMIC

DOCUMENT

OPERATIONS

AVOID

NATURAL

KEYS ASIDENTIFIERS





DESIGN

DESIGN

FOR

QUERYEMBEDDED

DATA

vsReferences

DBREFS

VS

MANUALREFERENCE

DYNAMIC

SCHEMA

VSstatic

languages

PURE DRIVER

VS

MAPPINGFRAMEWORKS

BE

CAREFUL

WITH DATES

SPLIT DATA

ON

MULTIPLECOLLECTIONS


Write

Concern

READ

PREFERENCE

ATOMIC

DOCUMENT

OPERATIONS

AVOID

NATURAL

KEYS ASIDENTIFIERS

PERFORMANCE

PREALLOCATE

FIELDS?

be aware

of

the trees

PREPROCESS

HIGH

RESOLUTIONDATA

TUNING

UPDATES

ANDINSERTS

DOCUMENT

MOVING

SLOWSYOU




FRIENDLY FIRE




ATOMIC

DOCUMENT

OPERATIONS





ATOMIC

DOCUMENT

OPERATIONS

OPERATIONS ON MULTIPLE DOCUMENTS ARE NOT ATOMIC





ATOMIC

DOCUMENT

OPERATIONS


NO “ALL OR NOTHING”





ATOMIC

DOCUMENT

OPERATIONS



EMBEDding OR APPLIcaTION TRANSACTIONS CAN be used to handle the issue





ATOMIC

DOCUMENT

OPERATIONS



EMBEDding OR APPLIcaTION TRANSACTIONS CAN be used to handle the issue

RELATIONAL TRANSACTIONS ARE NOT TOTALLY SAFE





“Describes the guarantee that

MongoDB provides when reporting on the success of a write

operation”

Write

Concern







operation”

Write

Concern

IT IS SET BY THE CLIENT AND CAN BE SET FOR EACH OPERATION







operation”

Write

Concern


Errors Ignored







operation”

Write

Concern


Errors Ignored Unacknowledged







operation”

Write

Concern



Acknowledged (*)







operation”

Write

Concern



Acknowledged (*) Journaled







operation”

Write

Concern



Acknowledged (*) Journaled

Replica Acknowledged> 1 , majority , custom using tags





“IT describes how MongoDB clients

route read operations to members

of a replica set”

Read

Preference







of a replica set”

Read

Preference








of a replica set”

Read

Preference

primary (*)








of a replica set”

Read

Preference

primary (*) primary Preferred








of a replica set”

Read

Preference


secondary








of a replica set”

Read

Preference


secondary secondary PREFERRED








of a replica set”

Read

Preference

primary (*)

nearest

primary Preferred

secondary secondary PREFERRED






All collections have an index on the id field that exists by default. If ID IS NOT PROVIDED the driver or the mongod will create an _id field with an ObjectID value.

AVOID

NATURAL

KEYS ASIDENTIFIERS






AVOID

NATURAL

KEYS ASIDENTIFIERS

ADD AN UNIQUE INDEX ON THE NATURAL KEY, SOMETIMES THE APPLICATION REALM CAN EVOLVE IN AN UNEXPECTED WAY






AVOID

NATURAL

KEYS ASIDENTIFIERS

ADD AN UNIQUE INDEX ON THE NATURAL KEY, SOMETIMES THE APPLICATION REALM CAN EVOLVE IN AN UNEXPECTED WAY

REMEMBER THAT UNIQUE INDEXES FIELDS MUST BE PART OF THE SHARD KEY IF SHARDING IS ENABLED




DESIGN




DOCUMENT DESIGN IS FUNCTIONAL TO THE QUERIES THAT WILL EXISTS IN THE APPLICATION

DESIGN

FOR

QUERY






DESIGN

FOR

QUERY

REFERENCE OR EMBED DOCUMENTS,

“denormalized” is not always

a bad word






DESIGN

FOR

QUERY

REFERENCE OR EMBED DOCUMENTS,

“denormalized” is not always

a bad word

your document design will affect what kind of OPERATIONS will be safe or not





Embedded data models allow applications to store related pieces of information in the same database record

EMBEDDED

DATA

vsReferences






EMBEDDED

DATA

vsReferences

USUALLY there is a “contains” relation

between the embedding and the embedded object






EMBEDDED

DATA

vsReferences

The maximum BSON document size is 16 megabytes and embedding may lead to performance issues if not correctly used

USUALLY there is a “contains” relation

between the embedding and the embedded object





Normalized data models describe relationships using references between documents

EMBEDDED

DATA

vsReferences






EMBEDDED

DATA

vsReferences

References provides more flexibility than embedding but remember that client-side applications will have to lookup for referenced objects with multiple queries






EMBEDDED

DATA

vsReferences

NO Referential integrity is supported, references could point to a not existing object

References provides more flexibility than embedding but remember that client-side applications will have to lookup for referenced objects with multiple queries





DBRefs are a convention for representing a document, it will hold the collection name, the id, and optionally the db name

DBREFS

VS

MANUALREFERENCE






DBREFS

VS

MANUALREFERENCE

MANUAL REFERENCES are just fields that will hold the id of the related document, without the collection name or the db name






DBREFS

VS

MANUALREFERENCE

MANUAL REFERENCES are just fields that will hold the id of the related document, without the collection name or the db name

MANUAL REFERENCES are suitable for most of the use cases





BE

CAREFUL

WITH DATES

ALWAYS Use bson date when is related to an instant of time or you will never be able to use operators on that fields





BSON Date is a 64-bit signed integer that represents the number of milliseconds since the Unix epoch (Jan 1, 1970), Negative values represent dates before 1970.The official BSON specification refers to the BSON Date type as the UTC datetime.

BE

CAREFUL

WITH DATES

ALWAYS Use bson date when is related to an instant of time or you will never be able to use operators on that fields





split data on multiple collections to easily partition your data (a.k.a. Multitenancy)

SPLIT DATA

ON

MULTIPLECOLLECTIONS






SPLIT DATA

ON

MULTIPLECOLLECTIONS

use collections as namespaces for your data






SPLIT DATA

ON

MULTIPLECOLLECTIONS

use collections as namespaces for your data

remember once data is partioned it will be more hard to aggregate if needed





why use dynamic schema if we are not using a dynamic programming language?

DYNAMIC

SCHEMA

VSstatic

languages






DYNAMIC

SCHEMA

VSstatic

languages

inheritance is not only a matter of hierarchy, it could be also a matter of composition






DYNAMIC

SCHEMA

VSstatic

languages

inheritance is not only a matter of hierarchy, it could be also a matter of composition

composition is the key to introduce dynamic schema in a static programming language





using the mongo driver directly will give you great powers, but will force you to write a lot of boilerplate code

PURE DRIVER

VS

MAPPINGFRAMEWORKS






PURE DRIVER

VS

MAPPINGFRAMEWORKS

MAPPING FRAMEWORKS WILL HELP TO WRITE LESS CODE, but you will sacrifice the control on all the aspects of the persistence






PURE DRIVER

VS

MAPPINGFRAMEWORKS

MAPPING FRAMEWORKS WILL HELP TO WRITE LESS CODE, but you will sacrifice the control on all the aspects of the persistence

why not take the most from both?




PERFORMANCE




Indexes in MongoDB are defined at the collection level and can be on any field or sub-field of the document

be aware

of

the trees






be aware

of

the trees

Indexes are created using a b-tree and can be of different types






be aware

of

the trees


Single Field






be aware

of

the trees


Single Field Compound






be aware

of

the trees



Multikey






be aware

of

the trees



Multikey Geospatial






be aware

of

the trees



Multikey Geospatial

TEXT (BETA)






be aware

of

the trees



Multikey Geospatial

TEXT (BETA) Hashed






be aware

of

the trees



Multikey Geospatial

TEXT (BETA) Hashed

THEY COULD BE UNIQUE and sparse





MONGODB handle the space allocation of a RECORD considering also a PADDING FACTOR

DOCUMENT

MOVING

SLOWSYOU






DOCUMENT

MOVING

SLOWSYOU

WHEN AN UPDATED DOCUMENT DOES NOT FIT IN THE RECORD SPACE IT WILL BE MOVED






DOCUMENT

MOVING

SLOWSYOU

WHEN AN UPDATED DOCUMENT DOES NOT FIT IN THE RECORD SPACE IT WILL BE MOVED

DYNAMIC SCHEMA IS THE FIRST CAUSE OF DOCUMENT MOVING





FIELDS PREALLOCATION CAN FIX THE DOCUMENT MOVING ISSUES IN SOME USE CASES

PREALLOCATE

FIELDS?






PREALLOCATE

FIELDS?

Default values must be used to preallocate, this MUST BE HANDLEDin the application






PREALLOCATE

FIELDS?

Default values must be used to preallocate, this MUST BE HANDLEDin the application

NULL is not a default value :-) as it has its own type





MONGODB let you store the maximum resolution of your data

PREPROCESS

HIGH

RESOLUTIONDATA






PREPROCESS

HIGH

RESOLUTIONDATA

MAP REDUCE and aggregation ARE okbut you could also preprocess and have aggregated data that you can use for your queries






PREPROCESS

HIGH

RESOLUTIONDATA

MAP REDUCE and aggregation ARE okbut you could also preprocess and have aggregated data that you can use for your queries

MONGODB rocks for business intelligence





MongoDB stores BSON documents as a sequence of fields and values, not as aN hash table

TUNING

UPDATES

ANDINSERTS






TUNING

UPDATES

ANDINSERTS

WRITING THE FIRST FIELD OF A DOCUMENT (OR A NESTED DOCUMENT) is considerably faster than writing THE LAST






TUNING

UPDATES

ANDINSERTS

WRITING THE FIRST FIELD OF A DOCUMENT (OR A NESTED DOCUMENT) is considerably faster than writing THE LAST

Intra-Document Hierarchy could help to handle the issue




Any questions?



Any questions?


Date post:	27-Nov-2014
Category:	Technology
Upload:	codemotion
View:	661 times
Download:	5 times

Application Design per MongoDB

Technology