commerce websites that use NoSQL databases
I have read a lot lately about 'NoSQL' databases such as CouchDB, MongoDB etc. Most of the websites I have seen using this are mainly text based websites such as The New York Times and Source forge.
I was wondering if you could apply this to websites where payment is a huge issue. I am thinking of the following issues:
I have read the following articles that cover some aspects:
In these posts the aspect of transactions if covered. However the questions of security and backups is not covered. Can someone shed some light on this subject?
And if possible, does anyone know of some e-commerce websites that have successfully implemented the document based database.
EDIT: March, 2013
I had originally posted a link to an article I wrote on MongoDB and e-commerce, but I no longer agree with all the points I made there. I still believe that MongoDB's document data model can work very well for the catalog management side of an e-commerce site and perhaps for shopping carts. But there are clearly cases where transactions are important, and MongoDB doesn't give you these. The answer to this question with the next-highest number of votes makes a lot of points worth considering.
Here's the original article for those interested:
http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/ (archive.org link)
The overhead that makes RDBMS's so slow, is guaranteeing atomicity, consistency, isolation, durability, also known as ACID. Some of these properties are pretty critical for applications that deal with money. You don't want to lose a single order when the lights go out.
NoSQL databases usually sacrifice some or all of the ACID properties in return for severely reduced overhead. For many applications, this is fine -- if a few "diggs" go missing when the lights go out, it's no big deal.
For an ecommerce site, you need to ask yourself what you really need.
Honestly, the answer to #2 is probably "yes", which rules out most NoSQL solutions. And unless you're dealing with traffic levels comparable to amazon.com's, an RDBMs, even on modest hardware will probably satisfy your performance needs just fine, especially if you limit yourself to simple queries, and index properly. Which makes the answer to #1 "no".
You could however, consider using a RDBMS for transaction data, and a NoSQL database for non-critical data, like product pages, user reviews, etc. But then you'd have twice as much datastore software to install, and any relationships between the data in the two datastores would have to be managed in code -- there'd be no JOINing your NoSQL database against your RDBMS. This would likely result in an unnecessary level of complexity.
In the end, if an RDBMS offers features you must have for reliability, and it performs acceptably for the sorts of load you'll be experiencing, an RDBMS is probably the best bet.
Handling financial information is one of the areas where SQL really is the right tool for the job. Most of the NOSQL systems were designed to improve scalability by accepting a higher risk of data loss or inconsistency. They also tend to have limited abilities to run reports over all records, since on a typical large website you only need enough data in the index to find and display a single record - the rest can be completely inaccessible until you know the record you are looking for.
When dealing with money, any data inconsistency is a big problem, and if you need more scalability than a single sql server can give you, you have enough money that you can afford the higher cost of scaling sql. Also, the ad-hoc reporting available from sql is something you'd miss if you don't use sql - pretty much any information you want about sales history is trivial to get from sql, but potentially requires complex custom code from an object based store.
链接地址: http://www.djcxy.com/p/86386.html上一篇: 为什么像Lucene / Solr这样的文档商店不包含在NoSQL对话中？
下一篇: 使用NoSQL数据库的电子商务网站