NoSQL databases are there to solve several things, mainly:
(buzz) BigData => think TB, PB, etc..
Working with Distributed Systems / datasets => say you have 42 products, so 13 of them will live in Chicago datacenter, 21 in NY's and another and 8 somewhere in Japan, but once you query against all 42 products, you would not need to know where they are located: NoSQL DB will. This also allows to engage a lot more brain power ( servers ) to solve hard computational problems [ does not seem it would fit your use case, but it is an interesting thing to note ]
Partitioning => having your DB be easily distributed, besides those cool 8 products in Japan, also allows for an easy data replication, so those 42 products will be replicated with a factor of 3, for example, which would mean you DB would have 3 copies for every product. Hence if something goes down, no problem => here is a replica available. This is where NoSQL databases actually shine vs. RDBMS. Granted you can shard, partition and cluster Oracle / MySQL / PostgreSQL / etc.. BUT it is a several magnitudes more complicated process and usually a maintenance headache for most people you'd employ.
(to your questions)
There will be around daily minimum 1000 users
1000 users daily is an extremely low volume, unless you choose a NoSQL solution that was written yesterday at 3 a.m. as a proof concept, there should be no worries here. But if you are successful, and will have 100,000,000 users in a couple of months, NoSQL would be simpler to scale.
Will availability be a problem ?
Solid NoSQL solutions allow you to specify something that is called a quorum: "The quantity of replicas that must respond to a read or write request before it is considered successful". Some solutions also do something called a hinted handoff: "neighboring nodes temporarily take over storage operations for the failed node". In general, you should be able to control availability depending on your requirements.
(from your comments)
We are planning to expand. And dont want the database to be a constraint
Expanding is a very relative term. "Financial industry is pretty expanded", and they still mostly use RDBMS for day to day operations. Facebook uses MySQL. Major banks, I did work for, use Oracle / MySQL / PostgreSQL / DB2 / etc.. and only some of them do use NoSQL, but NOT for data that requires 100% consistency all the time. Even Facebook uses Cassandra only for things like "inbox search". But if by expand you mean more data and more users ( requests, connections, etc.. ), NoSQL will be a lot easier to scale. Again, it does not mean that you can't scale RDBMS, it is just more tedious/complicated.
From what I have read, in no SQL database we dont have to think about the schema a lot
In my experience, if I build a system that is any good, I ALWAYS have to think about the schema. NoSQL databases allow you to be a bit more flexible with the data you persist, but it does not mean you should think about the schema any less. Think of indexing the data for example, or sharding it over multiple clusters, or even contracts/interfaces that you may expose to clients, etc..
The maintenance required for NoSQL database is very less
I would not say this is true in general, unless we are talking about BigData. Take PostgreSQL for example. It is an extremely awesome piece of software, that is quite easy to work with and maintain. Another plus to RDBMS world => people feel A LOT more comfortable with SQL. For that reason, for example, Cassandra guys, released CQL in 0.8, which is a very limited subset of SQL. Terms like maintenance also should stand shoulder to shoulder with terms like Talent, Knowledge, Expertise. Since if you use Cassandra, for instance, that girl is a very "high maintenance", but not for guys from DataStax who do have Expertise, but you'd have to pay for that.
Your Main Question
I have read in a blog that NoSQL database are not so good for Online Money Transaction i.e. where data integrity is highest importance.( My product has Online money transactions )
Without truly knowing what your product is, it is hard to say whether a NoSQL database would / would not be a good fit. If the primary goal of the product is "Online Money Transaction", then I would suggest against NoSQL database ( at least today in the year of 2011 ). If "Online Money Transaction" is just one of the requirements, but not "the core" of your product, depending on what "the core" is, you can definitely give NoSQL database a try, and for example use an external service to process (e.g. Google Checkout, etc..) your transactions with a guaranteed consistency.
As a technical note, if the problem you are trying to solve benefits from being solved with distribution, I would recommend databases that are written in Erlang ( e.g. Riak, CouchDB, etc. ), since Erlang as a language already solves successfully most of distributed things for decades.
发布评论
评论（2）
NoSQL 数据库可以解决几个问题，主要是：
(buzz) BigData =>想想 TB、PB 等。
使用分布式系统 / 数据集 =>假设您有 42 个产品，因此其中 13 个位于芝加哥数据中心，21 个位于纽约，另外 8 个位于日本某个地方，但是一旦您查询所有 42 个产品，您就不需要知道它们位于哪里：NoSQL DB 将。这还允许投入更多的脑力（服务器）来解决困难的计算问题[似乎不适合您的用例，但值得注意]
分区 = >让您的数据库易于分发，除了日本那些很酷的 8 个产品之外，还可以轻松进行数据复制，因此这 42 个产品将以 3 倍的倍数进行复制，例如，这意味着您的数据库将拥有 3 个副本 < em>每件产品。因此，如果出现问题，没问题 =>这是可用的复制品。这就是 NoSQL 数据库相对于 RDBMS 的真正优势。当然，您可以对 Oracle / MySQL / PostgreSQL / 等进行分片、分区和集群。但这是一个复杂得多的过程，对于您雇用的大多数人来说通常是一个令人头痛的维护问题。
（针对您的问题）
每天至少有 1000 名用户左右
每天 1000 个用户是一个极低的数量，除非您选择昨天凌晨 3 点编写的 NoSQL 解决方案作为证明概念，否则这里应该不用担心。但如果你成功了，并且在几个月内拥有 100,000,000 个用户，NoSQL 的扩展会更简单。
可用性会成为问题吗？
可靠的 NoSQL 解决方案允许您指定称为“仲裁”的内容：“在读取或写入请求被视为成功之前必须响应的副本数量 ”。一些解决方案还执行称为
提示切换的操作：“相邻节点暂时接管故障节点的存储操作”。一般来说，您应该能够根据您的要求控制可用性。（来自您的评论）
扩展是一个非常相对的术语。 “金融业相当扩张”，他们仍然主要使用关系型数据库管理系统进行日常运营。 Facebook 使用 MySQL。我工作过的各大银行都使用 Oracle / MySQL / PostgreSQL / DB2 / 等。只有其中一些使用 NoSQL，但不适用于始终需要 100% 一致性的数据。甚至 Facebook 也仅将 Cassandra 用于“收件箱搜索”等用途。但如果扩展意味着更多的数据和更多的用户（请求、连接等），NoSQL 将更容易扩展。再次强调，这并不意味着您无法扩展 RDBMS，它只是更加乏味/复杂。根据我的经验，如果我构建一个好的系统，我总是必须考虑架构。 NoSQL 数据库让您可以更加灵活地处理所保存的数据，但这并不意味着您应该更少考虑架构。例如，考虑对数据进行索引，或者将其分片到多个集群，甚至是您可能向客户端公开的合约/接口等。
我不会说一般来说，这是正确的，除非我们谈论的是大数据。以 PostgreSQL 为例。这是一款非常棒的软件，非常易于使用和维护。 RDBMS 世界的另一个优点=>人们对 SQL 感到更加更加自在。出于这个原因，例如 Cassandra 人员在 0.8 中发布了 CQL，这是 SQL 的一个非常有限的子集。像
维护这样的术语也应该与像人才、知识、专业知识这样的术语并列。例如，如果你使用 Cassandra，那个女孩是一个非常“高维护”的人，但对于 DataStax 的那些确实拥有专业知识的人来说则不然，但你必须为此付费。您的主要问题
如果不真正了解您的产品是什么，很难说 NoSQL 数据库是否适合。如果产品的主要目标是“在线货币交易”，那么我建议使用 NoSQL 数据库（至少在 2011 年的今天）。如果“在线货币交易”只是需求之一，而不是你产品的“核心”，那么取决于“核心”是什么，你绝对可以尝试一下NoSQL数据库，例如使用外部服务来处理（例如Google Checkout等..）您的交易具有保证的一致性。
作为技术说明，如果您试图解决的问题可以通过分布式解决，我会推荐用 Erlang 编写的数据库（例如 Riak、CouchDB 等），因为 Erlang 作为一种语言已经成功解决了大多数分布式问题几十年的事情。
NoSQL databases are there to solve several things, mainly:
(buzz) BigData => think TB, PB, etc..
Working with Distributed Systems / datasets => say you have 42 products, so 13 of them will live in Chicago datacenter, 21 in NY's and another and 8 somewhere in Japan, but once you query against all 42 products, you would not need to know where they are located: NoSQL DB will. This also allows to engage a lot more brain power ( servers ) to solve hard computational problems [ does not seem it would fit your use case, but it is an interesting thing to note ]
Partitioning => having your DB be easily distributed, besides those cool 8 products in Japan, also allows for an easy data replication, so those 42 products will be replicated with a factor of 3, for example, which would mean you DB would have 3 copies for every product. Hence if something goes down, no problem => here is a replica available. This is where NoSQL databases actually shine vs. RDBMS. Granted you can shard, partition and cluster Oracle / MySQL / PostgreSQL / etc.. BUT it is a several magnitudes more complicated process and usually a maintenance headache for most people you'd employ.
(to your questions)
There will be around daily minimum 1000 users
1000 users daily is an extremely low volume, unless you choose a NoSQL solution that was written yesterday at 3 a.m. as a proof concept, there should be no worries here. But if you are successful, and will have 100,000,000 users in a couple of months, NoSQL would be simpler to scale.
Will availability be a problem ?
Solid NoSQL solutions allow you to specify something that is called a
quorum: "The quantity of replicas that must respond to a read or write request before it is considered successful". Some solutions also do something called ahinted handoff: "neighboring nodes temporarily take over storage operations for the failed node". In general, you should be able to control availability depending on your requirements.(from your comments)
Expandingis a very relative term. "Financial industry is pretty expanded", and they still mostly use RDBMS for day to day operations. Facebook uses MySQL. Major banks, I did work for, use Oracle / MySQL / PostgreSQL / DB2 / etc.. and only some of them do use NoSQL, but NOT for data that requires 100% consistency all the time. Even Facebook uses Cassandra only for things like "inbox search". But if by expand you mean more data and more users ( requests, connections, etc.. ), NoSQL will be a lot easier to scale. Again, it does not mean that you can't scale RDBMS, it is just more tedious/complicated.In my experience, if I build a system that is any good, I ALWAYS have to think about the schema. NoSQL databases allow you to be a bit more flexible with the data you persist, but it does not mean you should think about the schema any less. Think of indexing the data for example, or sharding it over multiple clusters, or even contracts/interfaces that you may expose to clients, etc..
I would not say this is true in general, unless we are talking about BigData. Take PostgreSQL for example. It is an extremely awesome piece of software, that is quite easy to work with and maintain. Another plus to RDBMS world => people feel A LOT more comfortable with SQL. For that reason, for example, Cassandra guys, released
CQLin 0.8, which is a very limited subset of SQL. Terms likemaintenancealso should stand shoulder to shoulder with terms likeTalent,Knowledge,Expertise. Since if you use Cassandra, for instance, that girl is a very "high maintenance", but not for guys from DataStax who do haveExpertise, but you'd have to pay for that.Your Main Question
Without truly knowing what your product is, it is hard to say whether a NoSQL database would / would not be a good fit. If the primary goal of the product is "Online Money Transaction", then I would suggest against NoSQL database ( at least today in the year of 2011 ). If "Online Money Transaction" is just one of the requirements, but not "the core" of your product, depending on what "the core" is, you can definitely give NoSQL database a try, and for example use an external service to process (e.g. Google Checkout, etc..) your transactions with a guaranteed consistency.
As a technical note, if the problem you are trying to solve benefits from being solved with distribution, I would recommend databases that are written in Erlang ( e.g. Riak, CouchDB, etc. ), since Erlang as a language already solves successfully most of distributed things for decades.
MarkLogic 是一个具有 ACID 事务的 NoSQL 数据库，用于管理游戏中的虚拟货币以及现实生活中的银行交易。
MarkLogic is a NoSQL database with ACID transactions that gets used to manage both virtual currency in games as well as real-life banking trades.