Store commodity information using a MongoDB database

E-commerce Business a basic function module is to store a wide range of commodity information, a variety of product characteristics, parameters, MongoDB flexible document model is very suitable for such business, this article mainly describes how to use MongoDB to store commodity classification information.

Relational database Solutions

The above problems can be solved using traditional relational databases, such as the following scenarios

Create different tables for different products

For example, music albums, movies, 2 kinds of goods, there are some common attributes, but there are many unique properties, you can create 2 different tables, with different schemas.

CREATE TABLE ' product_audio_album ' (    ' SKU ' char (8) Not NULL,    ...    ' Artist ' varchar (255) default NULL,    ' genre_0 ' varchar (255) default NULL,    ' genre_1 ' varchar (255) Default null,< c5/> ...,    PRIMARY KEY (' sku ') ... CREATE TABLE ' product_film ' (    ' SKU ' char (8) Not NULL,    ...    ' title ' varchar (255) default NULL,    ' rating ' char (8) default NULL,    ...,    PRIMARY KEY (' sku ')) ...

The main problem with this approach is that

1. For each new product category, you need to create a new table

2. Application developers must explicitly distribute the request to the corresponding table query, one query multiple products to achieve a more troublesome

Store all items in a single sheet

CREATE TABLE ' product ' (    ' SKU ' char (8) Not NULL,    ...    ' Artist ' varchar (255) default NULL,    ' genre_0 ' varchar (255) default NULL,    ' genre_1 ' varchar (255) Default null,<    c5/> ... ' title ' varchar (255) default NULL,    ' rating ' char (8) default NULL,    ...,    PRIMARY KEY (' SKU '))

Store all the goods in a table, this table contains all the attributes required for the goods, different products according to the need to set different properties, this method makes the product query is relatively simple, and allows a query across multiple products, but the disadvantage is that more wasted space.

Extracting public properties, multiple table inheritance

CREATE TABLE ' product ' (    ' SKU ' char (8) NOT null,    ' title ' varchar (255) DEFAULT NULL,    ' description ' varchar ( 255) DEFAULT NULL,    ' price ', ...    PRIMARY KEY (' SKU ')) CREATE TABLE ' product_audio_album ' (    ' SKU ' char (8) Not NULL,    ...    ' Artist ' varchar (255) default NULL,    ' genre_0 ' varchar (255) default NULL,    ' genre_1 ' varchar (255) Default null,< c10/> ...,    PRIMARY key (' SKU '),    FOREIGN key (' SKU ') REFERENCES ' product ' (' SKU ')) ... CREATE TABLE ' product_film ' (    ' SKU ' char (8) Not NULL,    ...    ' title ' varchar (255) default NULL,    ' rating ' char (8) default NULL,    ...,    PRIMARY KEY (' sku '),    FOREIGN KEY (' sku ') REFERENCES ' product ' (' SKU ')) ...

The above scheme extracts the public properties of all commodities, stores the public properties in a table, and creates new tables according to their own needs, and stores only the information that is unique to the product.

Entity Attribute Values Form Store

All data is stored in the form of a 3-tuple, which is actually a relational database used as KV storage, the model is simple, but it is not convenient to deal with complex queries.

ENTITY ATTRIBUTE VALUES

sku_00e8da9b type Audio Album

sku_00e8da9b title A Love Supreme

sku_00e8da9b ...

sku_00e8da9b artist John Coltrane

sku_00e8da9b genre Jazz

sku_00e8da9b Genre General

... ... ...

MongoDB Solution

Mognodb and relational database, it has no schema, the document content can be very flexible customization, good use of the above commodity classification storage requirements; Store the product information in a collection where different items in the collection can customize the contents of the document.

For example, a music album can resemble the following document structure

{  SKU: ' 00e8da9b ',  type: ' Audio Album ',  title: ' A Love Supreme ',  Description: ' by John Coltrane ',  ASIN: "b0000a118m",  shipping: {    weight:6,    dimensions: {      width:10,      height:10,      depth:1    },  },  pricing: {    list:1200,    retail:1100,    savings:100,    pct_savings:8  },  Details: {    title: "A Love Supreme [Original recording reissued]",    artist: "John Coltrane",    Genre: [ "Jazz", "General"],        ...    Tracks: [A Love      Supreme part i:acknowledgement, '      a love Supreme part ii-resolution ',      ' a love Supreme, Part iii:pursuance ",      " A love Supreme, part Iv-psalm "    ],  },}

And a movie can be stored as

{  SKU: "00e8da9d",  Type: "Film",  ...,  ASIN: "B000p0j0aq",  shipping: {...},  pricing: {...},< C6/>details: {    title: "The Matrix",    Director: ["Andy Wachowski", "Larry Wachowski"],    Writer: ["Andy Wachows Ki "," Larry Wachowski "],    ...,    aspect_ratio:" 1.66:1 "  },}

All products have some common basic information, the specific products can expand the unique content according to the need, very convenient, based on the above model, MongoDB can also be a good service for all kinds of queries.

Query all movies that an actor is in and sort by the hairstyle journal

Db.products.find ({' type ': ' Film ', ' details.actor ': ' Keanu Reeves '}). Sort ({' Details.issue_date ',-1})

The above query can also be indexed to speed up

Db.products.createIndex ({type:1, ' details.actor ': 1, ' details.issue_date ':-1})

Query all movies with specific information in the title

Db.products.find ({    ' type ': ' Film ',    ' title ': {' $regex ': '. *hacker.* ', ' $options ': ' I '}}). sort ({' Details.issue_date ',-1})

The following index can be established to speed up the query

Db.products.createIndex ({type:1, details.issue_date:-1, title:1})

Extended

When a single node fails to meet the demands of a massive commodity information store, it needs to be extended using MongoDB sharding, assuming that a large number of queries will be based on the commodity type, then the commodity Type field can be used for sharding.

Db.shardcollection (' products ', {key: {type:1}})

Sharding, as far as possible to use composite index fields, so as to meet more query requirements, such as based on the product type, but also often based on the product style tag query, you can put the product's label field as the second Shard key.

Db.shardcollection (' products ', {key: {type:1, ' details.genre ': 1}})

If a certain type of commodity, with the same label is particularly many, there will be jumbo chunk problems, resulting in the inability to migrate, you can further optimize the Shard key to avoid this situation.

Db.shardcollection (' products ', {key: {type:1, ' details.genre ': 1, Sku:1}})

After adding the 3rd Shard key, even if the type, style tags are the same, but their SKU information must be different, there will certainly not be a huge chunk.

