Store product information using the MongoDB database

A basic function module of e-commerce businesses is to store a wide range of product information, with different product features and parameters. MongoDB's flexible document model is very suitable for such businesses, this article mainly introduces how to use MongoDB to store Commodity Classification information. a basic function module of the e-commerce business is to store rich commodity information with different product characteristics and parameters, the flexible document model of MongoDB is very suitable for this type of business. This article mainly introduces how to use MongoDB to store product classification information.

Relational database solution

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

Create different tables for different products

For example, two types of products, music albums and movies, have some common attributes, but they also have many unique attributes. you can create two 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,    ...,    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 item category, a new table needs to be created.

2. Application developers must explicitly distribute requests to the corresponding tables for query. it is troublesome to query multiple products at a time.

Store all items in a single table

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,    ...    `title` varchar(255) DEFAULT NULL,    `rating` char(8) DEFAULT NULL,    ...,    PRIMARY KEY(`sku`))

Store all commodities in one table. This table contains the attributes required by all commodities. different commodities can be set as needed. this method makes commodity query easier, in addition, a query is allowed across multiple products, but the disadvantage is that there is a large waste of space.

Extract common attributes and inherit from multiple tables

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,    ...,    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 attributes of all commodities and stores them in a table. each commodity creates a new table based on its own needs. the new table only stores the unique information of the commodity.

Entity Attribute Values storage

All data is stored in the form of 3 tuples. this solution uses relational databases as KV storage, and the model is simple, but it is not very 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

Different from relational databases, MognoDB has no schema, and the document content can be customized flexibly to meet the requirements for classified storage of the above products. The product information is stored in a collection, you can customize document content for different products in the set.

For example, a music album can be similar to 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"    ],  },}

A movie can be stored

{  sku: "00e8da9d",  type: "Film",  ...,  asin: "B000P0J0AQ",  shipping: { ... },  pricing: { ... },  details: {    title: "The Matrix",    director: [ "Andy Wachowski", "Larry Wachowski" ],    writer: [ "Andy Wachowski", "Larry Wachowski" ],    ...,    aspect_ratio: "1.66:1"  },}

All products share some common basic information. specific products can expand their unique content as needed, which is very convenient. based on the above model, MongoDB can also serve all kinds of queries well.

Query all movies played by an actor and sort them by hair style logs.

db.products.find({'type': 'Film', 'details.actor': 'Keanu Reeves'}).sort({'details.issue_date', -1})

The preceding query can be accelerated by creating an index.

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

Query all movies whose titles contain specific information

db.products.find({    'type': 'Film',    'title': {'$regex': '.*hacker.*', '$options':'i'}}).sort({'details.issue_date', -1})

You can create the following indexes to accelerate queries.

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

Extension

When a single node cannot meet the needs of massive commodity information storage, you need to use MongoDB sharding for expansion. if a large number of queries are based on the commodity type, you can use the item type field for sharding.

db.shardCollection('products', { key: {type: 1} })

When sharding, try to use composite index fields to meet more query requirements. for example, after the product type is used, it is often queried based on the style tag of the product, the tag field of the product can be used as the second shard key.

db.shardCollection('products', { key: {type: 1, 'details.genre': 1} })

If there are many products with the same tag, jumbo chunk may occur, resulting in migration failure. you can further optimize the shard key to avoid this situation.

db.shardCollection('products', { key: {type: 1, 'details.genre': 1, sku: 1} })

After the 3rd Partition key is added, even if the type and style labels are the same, the sku information of the partition key must be different, so there will certainly be no super-large chunk.