nosql 数据库是否适合在线货币交易管理 [英] Is nosql Database good for Online Money Transaction management

问题描述

我打算使用 nosql 数据库作为我的 Web 产品的后端.我有几个非常基本的疑问.

I am planning to use nosql Database as the back-end for my Web Product. I have a few very basic doubts.

1) 我在博客中读到 Nosql 数据库不太适合在线货币交易，即数据完整性最重要的地方.(我的产品有在线货币交易)

1) 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)

2) 每天至少有 1000 名用户.

2) There will be around daily minimum 1000 users.

3)可用性会成为问题吗?

3)Will availability be a problem ?

能否请您说明更多与 Nosql 数据库相关的优缺点.我打算使用 MongoDb.这能满足我上面的疑问吗.

Can you please state any more pros and cons related to Nosql database.I am planning to use MongoDb. Can this satisfy my above queries.

我的问题清楚还是我需要提供更多信息?请发表评论，我将进行必要的更改.

Is my question clear or do i need to give more info? Please comment and i will make the necessary changes.

推荐答案

NoSQL 数据库是用来解决几个问题的，主要是:

NoSQL databases are there to solve several things, mainly:

• (嗡嗡声)BigData => 想想 TB、PB 等等.

• (buzz) BigData => think TB, PB, etc..

使用分布式系统/数据集 => 假设您有 42 个产品，因此其中 13 个将位于芝加哥数据中心，21 个位于纽约，另外 8 个位于日本的某个地方，但一次您查询所有 42 种产品，您不需要知道它们的位置:NoSQL DB 会.这也允许使用更多的脑力(服务器)来解决困难的计算问题[似乎不适合您的用例，但这是一件有趣的事情要注意]

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 ]

分区 => 让您的数据库易于分发，除了日本的 8 款酷炫产品外，还可以轻松进行数据复制，因此这 42 款产品的复制系数为例如，3，这意味着您的数据库将为每个产品拥有 3 个副本.因此，如果出现问题，没问题 => 这里有一个可用的副本.这就是 NoSQL 数据库与 RDBMS 相比真正发挥作用的地方.当然，您可以对 Oracle/MySQL/PostgreSQL/等进行分片、分区和集群.但这是一个复杂得多的过程，并且对于您雇用的大多数人来说通常是一个维护难题.

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.

(回答你的问题)

• 每天至少有 1000 名用户

每天 1000 个用户是极低的数量，除非您选择昨天凌晨 3 点编写的 NoSQL 解决方案作为证明概念，否则这里应该没有后顾之忧.但是，如果您成功了，并且在几个月内将拥有 1 亿个用户，那么 NoSQL 的扩展会更简单.

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.

可用性会成为问题吗?

可靠的 NoSQL 解决方案允许您指定称为 quorum 的内容:在认为成功之前必须响应读取或写入请求的副本数量".一些解决方案还做了一些称为hinted handoff 的事情:相邻节点暂时接管故障节点的存储操作".一般来说，您应该能够根据自己的要求控制可用性.

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.

(来自你的评论)

• 我们正计划扩展.并且不希望数据库成为约束

Expanding 是一个非常相对的术语.金融业相当发达"，他们仍然主要使用 RDBMS 进行日常运营.Facebook 使用 MySQL.主要银行，我确实工作过，使用 Oracle/MySQL/PostgreSQL/DB2/等等.只有其中一些使用 NoSQL，但不适用于需要 100% 一致性的数据.甚至 Facebook 也仅将 Cassandra 用于诸如收件箱搜索"之类的事情.但是如果扩展意味着更多的数据和更多的用户(请求、连接等)，NoSQL 将更容易扩展.同样，这并不意味着您不能扩展 RDBMS，它只是更加乏味/复杂.

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.

• 据我所知，在没有 SQL 数据库的情况下，我们不必过多考虑架构

根据我的经验，如果我构建了一个好的系统，我总是必须考虑架构.NoSQL 数据库允许您在处理持久数据时更加灵活，但这并不意味着您应该减少对架构的考虑.例如，考虑对数据进行索引，或将其分片到多个集群，甚至是您可能向客户公开的合同/接口等.

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..

• NoSQL 数据库所需的维护非常少

我一般不会说这是真的，除非我们谈论大数据.以 PostgreSQL 为例.这是一款非常棒的软件，非常易于使用和维护.RDBMS 世界的另一个优点 => 人们对 SQL 感到很多更舒服.出于这个原因，例如，Cassandra 人在 0.8 中发布了 CQL，这是 SQL 的一个非常有限的子集.像maintenance这样的术语也应该与Talent、Knowledge、Expertise这样的术语并驾齐驱.例如，如果你使用 Cassandra，那么那个女孩是一个非常高维护"的人，但对于 DataStax 拥有Expertise 的人来说不是，但你必须为此付出代价.

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.

您的主要问题

• 我在博客中读到 NoSQL 数据库不太适合在线货币交易，即数据完整性最重要的地方.(我的产品有在线货币交易)

如果不真正了解您的产品是什么，就很难说 NoSQL 数据库是否适合/不适合.如果产品的主要目标是在线货币交易"，那么我会建议反对 NoSQL 数据库(至少在 2011 年的今天).如果在线货币交易"只是需求之一，而不是您产品的核心"，那么取决于核心"是什么，您绝对可以尝试使用NoSQL数据库，例如使用外部服务进行处理(例如 Google Checkout 等)您的交易有保证的一致性.

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.

作为技术说明，如果您尝试解决的问题得益于分发解决方案，我会推荐用 Erlang 编写的数据库(例如 Riak、CouchDB 等)，因为 Erlang 作为一种语言已经成功解决了几十年来大多数分布式事物.

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.

这篇关于nosql 数据库是否适合在线货币交易管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！