Mongodb

MongoDBThe fast (don’t think about this like an RDBMS) database alternative.

Wednesday, August 24, 2011

PROJECT

BUSINESS LOGIC DOMAIN MODEL

THE ROAD TO MONGODBRDBMS + ORM


Object Database

Attempted to accommodate the OO languages they were meant to support

Inheritance, associations, etc.

THEY FAILED

Too slow, too complicated, doomed!


The Google ProblemRelational databases are slow and don’t scale well

Distribution

Replication

ACID compliance

Vendor lock in

Atypical domain model didn’t require ACID transactions


The Google Solution

Big Table

http://labs.google.com/papers/bigtable.html

email the authors, they’re great!

Petabytes of data across thousands of commodity servers

Data separate from logic




JSON & BSON

Clear, concise and very AJAX friendly

Flexible and nestable (you can nest documents)

Ubiquitous language support


JSON & BSON cont.

BSON <> JSON translation can be awkward when dealing with language specific data types

Dates, _id fields, etc.

Well suited to text/numeric data, not much else


Common pitfalls

How to create a view or join

Enforce data integrity

Define data structure

Document vs. Table(s)


Normalization

RDBMS Normalization is intended to...

Reduce complexity

Discourage duplication of code/data

Provide logical mappings for domain elements

In mongodb, the document tells the whole story, including a definition of the data


Maturity Issues

No log file rolling mechanism

Awkward tools and querying

Accustomed to tabular data (try .pretty())

Very little (if any) feedback regarding outcome of commands


Queues

Many steps, each in it’s own collection

Keep high volume collections small & fast

Maintain large amounts of statistical data in low volume collections


Ready for Business?

Business logic must exist in code (including querying data)

Transaction boundaries and concurrency must exist in code

Speed and reliability are a go (so far :)


Questions?


Mongodb

Self Improvement

Transcript of Mongodb