NoSql data model for ecommerce

Question

I am searching for a best way to fit data db that can be produced in product/shop suggest + product order project.

I extracted main entities, which are manipulated in such a project.

1. costumer - to perform product suggest on customer data (previous orders) and data produced by his friends (gathered by facebook etc.) it is good idea to have it in graph format, which brought me to neo4j database.
2. order - this are simple things, but it will be too many orders writes. An order life cycle is create -> modify status(ready or not) -> read by shop -> delete. It means that the main feature of orders database is huge amount of write operations (write-read ratio is 3). May be DynamoDB is good choise for this task.
3. goods - they are unstructured (different products - different fields) and belong to some categories (hierarchical structure). This one is good for mongodb.
4. shop - the only thing about shop is its Geo location (if shop is a restaurant, than customer would like to visit it). This also can be handled by mongodb.

After such analysis I came that I need 3 different databases with different models: Neo4j, DynamoDB, mongoDB, which kind of strange. Is this solution seems to you good or may be you have a good suggestion for such tasks (relational databases are also possible options).

Answer 1

You've almost identified your databases correctly, but in my opinion, you should definitely let some kind of relational SQL db take care of the 'orders' related data. Since order information is probably a piece of information that is mission critical, and requires CRUD operations which should be atomic in nature, SQL databases prove to be extremely reliable in these cases. They not only guarantee atomicity but also all ACID properties. Information can be written to the database using transactions!

Now, its true that other NoSQL dbs also support transactions, but in general you would want a fairly high amount of reliability with you 'orders' database, which SQL can guarantee you. Don't let anyone tell you that databases like PostgreSQL cannot scale and handle large amounts of data. In fact, for all intents and purposes, whichever SQL database you choose will more than likely handle any amount of data you throw at it (millions of rows). If you do reach a point where the database gives you a performance bottleneck, then there exist many ways to scale them up.

Now as far as your unstructured 'goods' information is concerned, a NoSQL document store should be perfectly fine. MongoDB will be perfect!

Product suggestions and recommendations are generally suited for graph databases. You should definitely go ahead with Neo4j and I'm sure you'll will be surprised, or will have already been surprised, with how easy it is to get it up and running! And not to mention superimposing a social graph requires no extra effort.

For 'shops' with geo locations, you'll need to provide more information as to what you are trying to accomplish here along with any major constraints you have. As far as I know, if you are comfortable with Neo4j (which I think you will be), take a look at Neo4j spatial. The positive with using Neo4j here is that you can correlate you recommendations with geo locations easily without any overhead of extra computations required for making multiple database connections. Other relational, and document storage options can also be the answer to storing geo locations, but you will have to do some more research keeping in mind your constraints.

THE MOST IMPORTANT factor in all of this, is that when you end up selecting different databases to represent various kinds of information, you will need to identify a nice way to ensure data integrity. For instance, user ids in a mongo collection would need to somehow correlate with a property flag in a Neo4j user node. I'm pretty sure you'll face challenges in this aspect which will be fine tuned to your case. But you'll cross that bridge when you get to it I'm certain!

Its good that you are spending time early on trying to get your 'schema' right! It pays off in the end!