Are There Ecommerce Sites That Use NoSQL Databases

Question

Recently, I read a lot about NoSQL databases such as CouchDB, MongoDB, etc. Most of the websites I've seen use mostly text-based websites such as The New York Times and Source forge.

I was wondering if you can apply this on sites where payment is a huge problem. I think about the following issues:

• How well can you protect the data.
• Do these systems provide easy copy / restore of machanism.
• How commit / rollback transactions are handled

I read the following articles that cover some aspects:

• Can I do transactions and locks in CouchDB?
• Pros / cons of a document-based and relational database

These posts deal with the aspect of transactions. However, security and backup issues are not considered. Can someone shed light on this topic?

And if possible, does anyone know about some e-commerce sites that have successfully implemented a document-based database.

Answer 1

EDIT: March 2013

I initially posted a link to an article I wrote in MongoDB and e-commerce, but I no longer agree with all the points I made there. I still believe that the MongoDB data data model can work very well on the e-commerce site directory management side, and possibly for shopping. But there are obvious cases where transactions are important, and MongoDB does not give you this data. The answer to this question with the most votes gives a lot of questions that are worth considering.

Here is an original article for those interested:

http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/(link archive.org)

Answer 2

The overhead that makes RDBMS so slow guarantees atomicity, consistency, isolation, durability, also known as ACID . Some of these properties are quite important for money-making applications. You do not want to lose one order when the lights go out.

NoSQL databases typically sacrifice some or all of the ACID properties in return for greatly reduced overhead. For many applications, this is normal - if several "diggs" disappear when the lights go out, it does not really matter.

For an e-commerce site, you need to ask yourself what you really need.

• Do you really need a performance level that RDBMS cannot fulfill?
• Do you need the reliability that DBMS provides?

Honestly, the answer to # 2 is probably yes, which excludes most NoSQL solutions. And if you are not dealing with traffic levels comparable to amazon.com, then RDBM, even on modest hardware, is likely to satisfy your performance needs just fine, especially if you limit yourself to simple queries and index correctly. Which makes the answer to No. 1 "no."

However, you might consider using RDBMS for transaction data and a NoSQL database for non-critical data such as product pages, user reviews, etc. But then you will have twice as much data warehousing software to install, and any relationship between the data in the two data warehouses must be managed in code - there would be no CREATION of your NoSQL database against your RDBMS. This is likely to lead to an unnecessary level of difficulty.

After all, if RDBMS offers features that you should have for reliability, and it is suitably suitable for the types of downloads that you will experience, RDBMS is probably the best option.

Answer 3

Processing financial information is one area where SQL really is the right tool for the job. Most NOSQL systems have been designed to increase scalability by taking a higher risk of data loss or inconsistency. They also have limited ability to run reports on all records, since on a typical large website you only need enough data in the index to search and display one record - the rest may be completely inaccessible until you find out which record you are looking for for.

When working with money, any data inconsistency is a big problem, and if you need more scalability than a single sql server can give you, you will have enough money so you can afford the higher cost of sql scaling. In addition, the special reporting available from sql is what you would miss if you didn’t use sql — almost any information you want about sales history is trivial to get from sql, but potentially requires complex custom code from the store object .

Answer 4

I do not think that security in a NoSQL database would be different than in a relational database. After all, security is an orthogonal question about how data is actually stored. In addition, it is not as if you allowed access to the database from nothing but business-level servers from a network point of view.

As for backups, most NoSQL databases, which, as I know, allow you to create hot backups, like a regular database.

The real question, IMO, is whether you can live with the restrictions that the NoSQL database puts on you, in particular, due to the lack of special queries. For example, if you ever wanted to know all the people who have ever bought the product "X", then you would need to build in your data access level a counter for this from the first day (or run a very expensive serial search of all past deals ) In a regular SQL database, you can simply add the index and execute the query, and you're done (or even don't add the index if it is a one-time one). Or maybe you want to know all the people who bought the product “Y” before the latest version was released (so you can send them an update reminder or something else): again you need to plan this using the database NoSQL, but this is trivial with a relational database.

I think it makes sense when you can plan your schema and your usage model in advance, and where rescanning records is acceptable to add a new field or metric. But for an e-commerce website, I think special requests are just too valuable to lose. Of course, this is just my opinion, and, of course, there are no reasons why you could not mix parts of the application between the two databases. I would personally choose a relational database with memcached between them to improve performance, though ...

Answer 5

You guys should check this out:

Confirmation of replication via getlasterror

MongoDB is on the verge of providing long-term recording. I think this is the main problem with which people are discussing this topic wrt Money. The transactional part is less important due to the nested functions of the document.

Answer 6

Gilt.com uses Voldemort to handle baskets / inventory under tremendous strain. See this presentation from London QCon 2010 for details - http://www.infoq.com/presentations/Project-Voldemort-at-Gilt-Groupe

I would also repeat the fact that “NoSQL” does not mean “No SQL”, but “Not only SQL”, and that instead of looking at any technology to completely copy / replace any other, you should look at the best tool for work. NoSQL data warehouses do not create very good data warehouses and are probably not suitable for storing user transactions, but they are very good in certain niche areas - see the example above, Gilt Groupe.

Another outstanding example - the BBC homepage - is not transactional, but interesting nonetheless. They use CouchDB to store user preferences. Unfortunately, they seem to have crashed under load.

[UPDATE: I can also confirm that ASOS Marketplace uses some NoSQL components - http://bagcheck.com/bag/9206-asos-marketplace-technology ]

Answer 7

Here are a bunch of commercial web applications that use MongoDB , which is one of the most popular NoSQL databases.

http://www.mongodb.org/display/DOCS/Production+Deployments

These are not exactly e-commerce sites as such, but many of them are based on the NoSQL aspects that companies depend on. I can confirm that ChatPast is fully run on MongoDB. We do e-commerce, but it’s disconnected from Chargify due to security and processing issues, and is not afraid to do business on MongoDB.

Answer 8

Yes, http://myestoreapp.com uses MongoDB for everything. Check this; Feel free to remove any questions.