Blending MongoDB and RDBMS for ecommerce

Blending MongoDB
with RDBMS
for e-commerce

My name is
Steve Francia

@spf13

• 15+ years building e-commerce
• Long time open source contributor
• Entrepreneur
• Hacker, father, husband, skate punk
• VP Engineering @ OpenSky

My name is
Justin Hileman

@bobthecow

• 10+ years making the Internet
awesomer

• Open Source contributor
• Vespa rider, swing dancer,
coder, standardista

• Software Engineer @ OpenSky

We work for OpenSky

http://opensky.com

OpenSky is
a new way to shop

OpenSky connects you with innovators,
trendsetters and tastemakers.You choose
the ones you like and each week they invite
you to their private online sales.

OpenSky Loves
Open Source
• PHP 5.3
• Apache2
• Symfony2
• Doctrine2
• jQuery
• Mule
• HornetQ
• MongoDB
• nginx
• varnish

We contribute to many
open source projects and
pioneer innovative
solutions using them

OpenSky was the ﬁrst
e-commerce site built
on MongoDB
... also the ﬁrst e-commerce site built on Symfony2

Why NoSQL for
e-commerce?

Using the right solution for each situation

Data dilemma of
e-commerce
Pick One

Data dilemma of
e-commerce
Pick One

• Stick to one vertical (Sane schema)

Data dilemma of
e-commerce
Pick One

• Stick to one vertical (Sane schema)
• Flexibility (Insane schema)

Sane schema

• Works ... for a while

Sane schema

• Fine for a few types of products

Sane schema

• Fine for a few types of products
• Not possible when more product types
introduced

Let’s Use an Example
How about we start with books

Book Product Schema
Product {

id:
sku: General Product
product dimensions:
shipping weight: attributes
MSRP:
price:
description:
...
author: Orson Scott Card
title: Enders Game
binding: Hardcover
publication date: July 15, 1994 Book Speciﬁc
publisher name: Tor Science Fiction attributes
number of pages: 352
ISBN: 0812550706
language: English
...

Seems simple enough

What happens when we add another vertical...
say music albums

Album Product Schema
Product {

id:
sku: General Product
product dimensions: attributes stay the
shipping weight:
MSRP:
same
price:
description:
...
artist: MxPx
title: Panic Album Speciﬁc
release date: June 7, 2005 attributes are
label: Side One Dummy
track listing: [ The Darkest ... different
language: English
format: CD
...

Okay, it’s getting hairy but
is still manageable, right?

Okay, it’s getting hairy but
is still manageable, right?

Now the business want to sell jeans

Jeans Product Schema
Product {

id: General Product
sku:
product dimensions:
attributes stay the
shipping weight: same
MSRP:
price:
description:
...
brand: Lucky
gender: Mens
Jeans speciﬁc
make: Vintage attributes are totally
style: Straight Cut different ... and not
length: 34
width: 34
consistent across
color: Hipster brands & make
material: Cotten Blend
...

We need a ﬂexible
schema in RDBMS

We need a ﬂexible
schema in RDBMS

We got this ... right?

Many approaches
dealing with unknown
unknowns in RDBMS

Many approaches
dealing with unknown
unknowns in RDBMS

None work well

EAV
as popularized by Magento
“For purposes of ﬂexibility, the Magneto database heavily utilizes
an Entity-Attribute-Value (EAV) data model.

As is often the case, the cost of ﬂexibility is complexity -
Magento is no exception.

The process of manipulating data in Magento is often more
“involved” than that typically experienced using traditional
relational tables.”
- Varien

EAV

• Crazy SQL queries

• Hundreds of joins in a query...
or

• Hundreds of queries joined in
the application

• No database enforced integrity

Did I say crazy SQL
(this is a single query)

Did I say crazy SQL
(this is a single query)

You may have trouble reading this in the back

Single Table Inheritance
(insanely wide tables)

• No data integrity enforcement

• Only can use FK for common
elements

• Very wasteful (but disk is cheap!)

• Can’t effectively index

Generic Columns

• No data type enforcement

• Only can use FK for common
elements

• Wasteful (but disk is cheap!)

• Can’t index

Serialized in Blob
• Not searchable

• No integrity

• All the disadvantages of a document
store, but none of the advantages

• Never should be used

• One exception is Oracle XML
which operates similar to a
document store

Concrete Table Inheritance
(a table for each product attribute set)

• Allows for data integrity

• Querying across attribute
sets quite hard to do (lots of
joins, OR statements and full
table scanning)

• New table needs to be
created for each new
attribute set

Class table inheritance
(single product table,
each attribute set in own table)
• Likely best solution within the
constraint of SQL

• Supports data type enforcement


• Easy querying across categories (for
browse pages) since common data
in single table

• Every set needs a new table

• Requires a ton of forsight, as
changes are very complicated

MongoDB to the
Rescue
• Flexible (and sane) Schema

MongoDB to the
Rescue
• Easily searchable

MongoDB to the
Rescue
• Easily accessible

MongoDB to the
Rescue
• Easily accessible
• Fast

{ {
sku: "00e8da9c", sku: "00e8da9d",
type: "Audio Album", type: "Film",
title: "Hoss", title: "The Matrix",
description: "by Lagwagon", description: "Set in the 22nd century, Th
asin: "B0000007QG", asin: "B000P0J0AQ",

shipping: { shipping: {
weight: 6, weight: 6,
dimensions: { dimensions: {
width: 10, width: 10,
height: 10, height: 10,
depth: 1 depth: 1
}, },
}, },

pricing: { pricing: {
list: 1000, list: 1200,
retail: 800, retail: 1100,
savings: 200, savings: 100,
pct_savings: 20 pct_savings: 8.5
}, },

details: { details: {

pct_savings: 20 pct_savings: 8.5
}, },

details: { details: {
artist: "Lagwagon", director: [ "Andy Wachowski", "Larry Wa
genre: [ "Punk", "Hardcore", "Indie Rock" ], [ "Andy Wachowski", "Larry Wach
writer:
label: "Fat Wreck Chords", actor: [ "Keanu Reeves" , "Lawrence Fis
number_of_discs: 1, genre: [ "Science Fiction", "Action" ],
issue_date: "November 21, 1995", number_of_discs: 1,
format: "CD", issue_date: "May 15 2007",
alternate_formats: [ 'Vinyl', 'MP3' ],original_release_date: "1999",
tracks: [ disc_format: "DVD",
"Kids Don't Like To Share", rating: "R",
"Violins", alternate_formats: [ 'VHS', 'Bluray' ],
"Name Dropping", run_time: "136",
"Bombs Away", studio: "Warner Bros",
"Move The Car", language: "English",
"Sleep", format: [ "AC-3", "Closed-captioned", "
"Sick", aspect_ratio: "1.66:1"
"Rifle", },
"Weak", }
"Black Eye",
"Bro Dependent",
"Razor Burn",
"Shaving Your Head",
"Ride The Snake",
],

db.products.find( { 'name': "The Matrix" } );

db.products.find( { 'name': "The Matrix" } );

{
"_id": ObjectId("4d8ad78b46b731a22943d3d3"),
"sku": "00e8da9d",
"type": "Film",
"name": "The Matrix",
"description": "Set in the 22nd century, The Matrix...",
"asin": "B000P0J0AQ",
"shipping": {
"weight": 6,
"dimensions": {
"width": 10,
"height": 10,
"depth": 1
}
},
"pricing": {

db.products.find( { 'details.actor': "Groucho Marx" } );

db.products.find( { 'details.actor': "Groucho Marx" } );

},
"pricing": {
"list": 1000,
"retail": 800,
"savings": 200,
"pct_savings": 20
},
"details": {
"title": "A Night at the Opera",
"director": "Sam Wood",
"actor": ["Groucho Marx", "Chico Marx", "Harpo Marx"],
"genre": "Comedy",
"number_of_discs": 1,
"issue_date": "May 4 2004",
"original_release_date": "1935",
"disc_format": "DVD",

db.products.find( {
'details.genre': "Jazz", 'details.format': "CD"
} );

db.products.find( {
'details.genre': "Jazz", 'details.format': "CD"
} );

"list": 1200,
"retail": 1100,
"savings": 100,
"pct_savings": 8
},
"details": {
"title": "A Love Supreme [Original Recording Reissued]",
"artist": "John Coltrane",
"genre": ["Jazz", "General"],
"format": "CD",
"label": "Impulse Records",
"issue_date": "December 9, 1964",
"alternate_formats": ["Vinyl", "MP3"],
"tracks": [
"A Love Supreme Part I: Acknowledgement",

db.products.find( { 'details.actor':
{ $all: ['James Stewart', 'Donna Reed'] }
} );

db.products.find( { 'details.actor':
{ $all: ['James Stewart', 'Donna Reed'] }
} );

},
"details": {
"title": "It's a Wonderful Life",
"director": "Frank Capra",
"actor": ["James Stewart", "Donna Reed", "Lionel Barrymore"],
"writer": [
"Frank Capra",
"Albert Hackett",
"Frances Goodrich",
"Jo Swerling",
"Michael Wilson"
],
"genre": "Drama",
"issue_date": "Oct 31 2006",
"original_release_date": "1947",

Wanna Play?

• grab products.js from
http://github.com/spf13/mongoProducts
• mongo --shell products.js

• > use mongoProducts

Embedded documents
are great for orders
• Ordered items need to be ﬁxed at the time
of purchase
• Embed them right in the order
db.order.find( { 'items.sku': '00e8da9f' } );
db.order.find( {
'items.details.actor': 'James Stewart'
} ).count();

Why not NoSQL?


Data (like people) are
really sensitive when it
comes to money

Stricter data
requirements for $$

Stricter data
requirements for $$

• For ﬁnancial systems any data inconsistency
is unacceptable

Stricter data
requirements for $$

• For ﬁnancial systems any data inconsistency
is unacceptable
• Perhaps you’ve heard of ACID?

What about ACID?

Q: Is MongoDB ACID?

What about ACID?

Q: Is MongoDB ACID?
A: Kinda

Atomicity

• MongoDB does atomic writes

Atomicity

... for single document changesets

Atomicity

... for single document changesets

• $set, $unset, $inc, $push,
$pushAll, $pull, $pullAll, $bit

Consistency

• MongoDB can enforce unique keys

Consistency

... but only on keys shared by every
document in the collection

Consistency

... but only on keys shared by every
document in the collection
• MongoDB can't enforce referential integrity

Isolation
• // Pseudo-isolated updates
db.foo.update( { x : 1 } , { $inc : { y : 1 } } , false , true );

Isolation

• // Isolated updates
db.foo.update( { x : 1 , $atomic : 1 } , { $inc : { y : 1 } } , false ,
true );

Isolation

true );

• But there are caveats...

Isolation

true );


• Despite the $atomic keyword, this is not an atomic update,
since atomicity implies “all or nothing”

Isolation

true );


• Despite the $atomic keyword, this is not an atomic update,
since atomicity implies “all or nothing”

• An isolated update can only act on a single collection. Multi-
collection updates are not transactional, thus not isolatable.

Durability

• Mongo has this one covered

Blending MongoDB and RDBMS for ecommerce

• Atomic single document writes
• If you need atomic writes across multi-document
transactions don't use Mongo
• Many e-commerce transactions could be
accomplished within a single document write

• Unique indexes
• This only works on keys used by the entire collection

• Unique indexes
• Isolated (not atomic) single collection updates.
• Mongo does not support locking
• There are ways to work around this

• Unique indexes
• Isolated (not atomic) single collection updates.
• Mongo does not support locking
• There are ways to work around this
• It’s durable

There are ways to
guarantee ACID properties
in inconsistent databases

There are ways to
guarantee ACID properties
in inconsistent databases
(or, as we call them, consistency impaired databases)

Optimistic concurrency
• Read the current state of a product

• Read the current state of a product
• Make your changes with the assertion that
your product has the same state as it did
when you last read it

in MongoDB

in MongoDB
We’ll use an update-if-current strategy.

in MongoDB
This example is straight from the documentation:

in MongoDB

> t = db.inventory
> p = t.findOne({sku:'abc'})
> t.update({_id:p._id, qty:p.qty}, {'$inc': {qty: -1}});
> db.$cmd.findOne({getlasterror:1});

{"err" : , "updatedExisting" : true , "n" : 1 , "ok" : 1}
// it worked

in MongoDB

> t = db.inventory
> p = t.findOne({sku:'abc'})
> t.update({_id:p._id, qty:p.qty}, {'$inc': {qty: -1}});
> db.$cmd.findOne({getlasterror:1});

{"err" : , "updatedExisting" : true , "n" : 1 , "ok" : 1}
// it worked

... If that didn't work, try again until it does.

• Read the current state of a product.
when you last read it.

• It's possible to use OCC to bootstrap
pessimistic concurrency and fake row level
locking

• It's possible to use OCC to bootstrap
pessimistic concurrency and fake row level
locking
... ask me about this some time

control assumes an
environment with low
data contention

OCC works great for
companies like Amazon

• Amazon has a long-tail catalog
• A long tail catalog lends itself well to
optimistic concurrency, because it has low
data contention

OCC fails miserably for
• eBay

• eBay
• Gilt

• eBay
• Gilt
• Groupon

• eBay
• Gilt
• Groupon
• OpenSky

• eBay
• Gilt
• Groupon
• OpenSky
• Living Social

• eBay
• Gilt
• Groupon
• OpenSky
• Living Social
• InsertFlashSaleSiteOfTheMinute

Flash sales and auctions
are deﬁned by high data
contention

contention

• The model doesn't work otherwise

contention

• The model doesn't work otherwise
• They can't afford to be optimistic

Can we use pessimistic
concurrency with a
distributed NoSQL
database?

Blending
NoSQL & RDBMS


Our goal is to put as much
in Mongo as possible

• What makes more sense in RDBMS?
• Inventory
• Orders

Inventory requires

• Row level locking (or table level locking)

Orders require

• Row level locking (or table level locking)
• Atomic writes (inventory decremented)
• Transactions (3rd party processing)

Inventory & checkout
transactions

Commerce is ACID
In Real Life

1. I go to Barneys and see a pair of shoes I just have to
buy.

buy.
2. I call “dibs” (by grabbing them off the shelf).

buy.
3. I take them up to the cash register and purchase them:

buy.
• Store inventory has been manually decremented.

buy.
• I pay for them with my trusty AmEx.

buy.
4. If all goes according to plan, I walk out of the store.

buy.
5. If my card was declined, the shoes are “rolled back”

buy.
5. If my card was declined, the shoes are “rolled back”
... out onto the shelves and sold to the next customer
who wants them.

We follow the same
model for e-commerce

1. Select a product.

2. Lock the row or table and conﬁrm inventory.



3. Purchase the product:




• Decrement product inventory





• Process payment





• Process payment

4. Commit the transaction.





• Process payment

4. Commit the transaction.

5. Roll back if anything went wrong.

Doctrine (ORM/ODM)
to the rescue

Doctrine (ORM/ODM)
to the rescue
It would be possible without them,
but we're not that masochistic

Data we store in SQL

• Order
• Order/Shipment
• Order/Transaction
• Inventory

Data we store in
MongoDB
• User • Event

• Product • TaxRate

• Product/Sellable • ... and then I got tired of
typing them in
• Address
• Just imagine this list has
• Cart 40 more classes

• CreditCard • ...

We have the
most boring SQL
schema ever

CREATE TABLE `product_inventory` (
`product_id` char(32) NOT NULL,
ìnventory` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`product_id`)
);

CREATE TABLE `sellable_inventory` (
`sellable_id` char(32) NOT NULL,
ìnventory` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`sellable_id`)
);

CREATE TABLE òrders` (
ìd` int(11) NOT NULL AUTO_INCREMENT,
ùserId` char(32) NOT NULL,
`shippingName` varchar(255) DEFAULT NULL,
`shippingAddress1` varchar(255) DEFAULT NULL,
`shippingAddress2` varchar(255) DEFAULT NULL,
`shippingCity` varchar(255) DEFAULT NULL,
`shippingState` varchar(2) DEFAULT NULL,
`shippingZip` varchar(255) DEFAULT NULL,
`billingName` varchar(255) DEFAULT NULL,
`billingAddress1` varchar(255) DEFAULT NULL,
`billingAddress2` varchar(255) DEFAULT NULL,
`billingCity` varchar(255) DEFAULT NULL,

Wait. How does
inventory live in SQL?
Isn’t that a property in one of your Mongo collections?

I thought you’d
never ask!

Inventory is transient
• Product::$inventory is effectively a
transient property
• Note how I said “effectively”? ... we cheat
and persist our transient property to
MongoDB as well
• We can do this because we never really
trust the value stored in Mongo

Accuracy is only important
when there’s contention

• For display, sorting and alerts, we can use
the value stashed in MongoDB
• It’s faster
• It’s accurate enough

• For display, sorting and alerts, we can use
the value stashed in MongoDB
• It’s faster
• It’s accurate enough
• For ﬁnancial transactions, we want the
security and comfort of our RDBMS.

We keep inventory in
sync with listeners

sync with listeners
• Every time a new product is created, its
inventory is inserted in SQL

sync with listeners
• Every time an order is placed, inventory is
veriﬁed and decremented

sync with listeners
• Every time an order is placed, inventory is
veriﬁed and decremented
• Whenever the SQL inventory changes, it is
saved to MongoDB as well

Be careful what you lock
1. Acquire inventory row lock and begin transaction
2. Check current product inventory
3. Decrement product inventory
4. Write the Order to SQL
5. Update affected MongoDB documents
6. Commit the transaction
7. Release product inventory lock

Making MongoDB
and RDBMS relations
play nice

Products are
documents stored
in MongoDB

/** @mongodb:Document(collection="products") */
class Product
{
/** @mongodb:Id */
private $id;

/** @mongodb:String */
private $title;

public function getId()
{
return $this->id;
}

public function getTitle()
{
return $this->title;
}

public function setTitle($title)
{
$this->title = $title;
}
}

Orders are entities
stored in an RDBMS

/**
* @orm:Entity
* @orm:Table(name="orders")
* @orm:HasLifecycleCallbacks
*/
class Order
{
/**
* @orm:Id @orm:Column(type="integer")
* @orm:GeneratedValue(strategy="AUTO")
*/
private $id;

/**
* @orm:Column(type="string")
*/
private $productId;

/**
* @var DocumentsProduct
*/
private $product;

// ...
}

So how does an
RDBMS have a
reference to something
outside the database?

Setting the Product
class Order {

// ...

public function setProduct(Product $product)
{
$this->productId = $product->getId();
$this->product = $product;
}
}

• $productId is mapped and persisted

• $product which stores the Product
instance is not a persistent entity property

OrderPostLoadListener
use DoctrineORMEventLifecycleEventArgs;

class OrderPostLoadListener
{
public function postLoad(LifecycleEventArgs $eventArgs)
{
// get the order entity
$order = $eventArgs->getEntity();

// get odm reference to order.product_id
$productId = $order->getProductId();
$product = $this->dm->getReference('MyBundle:DocumentProduct', $productId);

// set the product on the order
$em = $eventArgs->getEntityManager();
$productReflProp = $em->getClassMetadata('MyBundle:EntityOrder')
->reflClass->getProperty('product');
$productReflProp->setAccessible(true);
$productReflProp->setValue($order, $product);
}
}

All Together Now
// Create a new product and order
$product = new Product();
$product->setTitle('Test Product');
$dm->persist($product);
$dm->flush();

$order = new Order();
$order->setProduct($product);
$em->persist($order);
$em->flush();

// Find the order later
$order = $em->find('Order', $order->getId());

// Instance of an uninitialized product proxy
$product = $order->getProduct();

// Initializes proxy and queries the monogodb database
echo "Order Title: " . $product->getTitle();
print_r($order);

Read more about
this technique
Jon Wage, one of OpenSky’s engineers, ﬁrst
wrote about this technique on his personal
blog: http://jwage.com

You can read the full article here:
http://jwage.com/2010/08/25/blending-the-
doctrine-orm-and-mongodb-odm/

Questions?
http://spf13.com
@spf13

http://justinhileman.com
@bobthecow

http://opensky.com

PS: We’re hiring!! Contact us at jobs@opensky.com

Blending MongoDB and RDBMS for ecommerce

More Related Content

What's hot (20)

Similar to Blending MongoDB and RDBMS for ecommerce (20)

More from Steven Francia (20)

Blending MongoDB and RDBMS for ecommerce

Editor's Notes