Maison > Article > développement back-end > Utiliser la base de données MongoDB pour stocker les informations sur le produit
Un module fonctionnel de base du commerce électronique consiste à stocker des informations sur les produits avec des catégories riches. Différents produits ont des caractéristiques et des paramètres différents. Le modèle de document flexible de MongoDB est très adapté à ce type d'entreprise. pour stocker les informations de classification des produits.
Solutions de bases de données relationnelles
Les problèmes ci-dessus peuvent également être résolus à l'aide de bases de données relationnelles traditionnelles, telles que les solutions suivantes
Pour différents produits, créez des tableaux différents
Par exemple, deux produits, des albums de musique et des films, ont des attributs communs, mais ont également de nombreux attributs uniques. Vous pouvez créer deux tableaux différents avec des attributs différents.
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`)) ...
Le principal problème de cette approche est que
Pour chaque nouvelle catégorie de produits, un nouveau tableau doit être créé
Les développeurs d'applications doivent explicitement distribuer les requêtes aux tables correspondantes pour les interrogations. L'interrogation de plusieurs produits en même temps est lourde à mettre en œuvre
Tous les produits sont stockés dans une seule 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`))
Stockez tous les produits dans un tableau. Ce tableau contient les attributs requis par tous les produits. Différents produits définissent différents attributs en fonction des besoins. Cette méthode rend la requête de produit relativement simple et permet qu'une requête s'étende sur plusieurs produits, mais présente l'inconvénient. c'est que cela gaspille beaucoup d'espace.
Extraire les attributs publics, héritage multi-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`)) ...
Le schéma ci-dessus extrait les attributs communs de tous les produits et stocke les attributs communs dans une table pour chaque produit. crée une nouvelle table en fonction de ses propres besoins, et seules les informations propres au produit sont stockées dans la nouvelle table.
Stockage des valeurs d'attribut d'entité
Toutes les données sont stockées sous la forme de 3 tuples. Cette solution utilise en fait la base de données relationnelle comme stockage KV, modèle Simple. , mais pas très pratique pour les requêtes complexes.
ENTITÉ Type Audio Album sku_00e8da9b titre A Love Supreme sku_00e8da9b … … … …
sku_00e8da9b artiste John Coltrane
sku_00e8da9b Genre
…
La solution MongoDBMognoDB est différente de bases de données relationnelles. Il n'a pas de schéma et le contenu du document peut être personnalisé de manière très flexible. Il peut faire bon usage du stockage de classification de produits ci-dessus Exigence : stocker les informations sur les produits dans une collection, et différents produits de la collection peuvent personnaliser le contenu du document.
Par exemple, un album de musique peut avoir une structure de document similaire à la suivante
et un film peut être stocké sous{ 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" }, }
所有商品都拥有一些共同的基本信息,特定的商品可以根据需要扩展独有的内容,非常方便; 基于上述模型,MongoDB 也能很好的服务各类查询。
查询某个演员参演的所有电影,并按发型日志排序
db.products.find({'type': 'Film', 'details.actor': 'Keanu Reeves'}).sort({'details.issue_date', -1})
上述查询也可以通过建立索引来加速
db.products.createIndex({ type: 1, 'details.actor': 1, 'details.issue_date': -1 })
查询标题里包含特定信息的所有电影
db.products.find({ 'type': 'Film', 'title': {'$regex': '.*hacker.*', '$options':'i'}}).sort({'details.issue_date', -1})
可建立如下索引来加速查询
db.products.createIndex({ type: 1, details.issue_date: -1, title: 1 })
扩展
当单个节点无法满足海量商品信息存储的需求时,就需要使用MongoDB sharding来扩展,假定大量的查询都是都会基于商品类型,那么就可以使用商品类型字段来进行分片。
db.shardCollection('products', { key: {type: 1} })
分片时,尽量使用复合的索引字段,这样能满足更多的查询需求,比如基于商品类型之后,还会经常根据商品的风格标签来查询,则可以把商品的标签字段作为第二分片key。
db.shardCollection('products', { key: {type: 1, 'details.genre': 1} })
如果某种类型的商品,拥有相同标签的特别多,则会出现jumbo chunk的问题,导致无法迁移,可以进一步的优化分片key,以避免这种情况。
db.shardCollection('products', { key: {type: 1, 'details.genre': 1, sku: 1} })
加入第3分片key之后,即使类型、风格标签都相同,但其sku信息肯定不同,就肯定不会出现超大的chunk。