在任何情况下我都不会使用 NOSQl 数据库来处理与金融有关的任何事情。您根本不具备所需的数据完整性或内部控制。 Dow Jones 使用 SQL Server 进行交易，如果他们能够正确设计高性能、高交易关系数据库，那么您也可以。你必须投资于一些知道自己在做什么的人。
There is no conceivable circumstance where I would use a NOSQl database for anything to do with finance. You simply don't have the data integrity needed or the internal controls. Dow Jones uses SQL Server to do its transactions and if they can properly design a high performance, high transaction Relational datbase so can you. You will have to invest in some people who know what they are doing though.
One has to think about the problem differently. The notion of transaction consistency stems from the UD (update) in CRUD (Create, Read, Update, Delete). noSQL DBs are CRAP (Create, Replicate, Append, Process) oriented, working by accretion of time-stamped data. With the right domain model, there is no reason that auditability and the equivalent of referential integrity can't be achieved.
The global-storage based NoSQL databases - Cache from InterSystems and GT.M from FIS - are used extensively in financial services and have been for many years. Cache in particular is used for both the core database and for OLTP.
您需要企业版来通过 WAN 复制数据（例如用于灾难恢复/高可用性）。如果您不介意付费，那也没关系，但请记住，芭蕉的定价非常高。
I can answer regarding my experience with scaling Riak.
Riak scales smoothly to the extreme. Scaling is as easy as adding nodes to the cluster, which is a very simple operation in itself. You can achieve near linear scalability by simply adding nodes. Our experience with Riak as far as scaling is concerned has been amazing.
The flip side is that it is lacking in many respects. Some examples:
You can't do something like count(*) or list keys on a production cluster. That would require a work around if you want to do ETL from Riak into MySQL - or how would you know what to (E)xtract? (One possible work around would be to maintain a bucket with a known key sequence that map to values that contain the keys you inserted into your other buckets).
The free version of Riak comes with no management console that lets you know what's going on, and the one that's included in the Enterprise version isn't much of an improvement.
You'll need the Enterprise version of you're looking to replicate your data over WAN (e.g. for DR / high availability). That's alright if you don't mind paying, but keep in mind that Basho pricing is very high.
TigerBeetle redesigns the distributed database storage engine and consensus protocol for the OLTP workload. This solves the problem of OLTP write contention to unlock three orders of magnitude more performance than a general purpose (OLGP) database.
I work with the Starcounter (so I’m biased), but I think I can safely say that for a system processing financial transactions you have to worry about transaction consistency. Unfortunately, this is what the engines used for Facebook and Twitter had to give up allow their scale-out strategy to offer performance. This is not because engines such as MongoDb or Cassandra are poorly designed; rather, it follows naturally from the CAP theorem (http://en.wikipedia.org/wiki/CAP_theorem). Simply put, changes you make in your database will overwrite other changes if they occur close in time. Ok for status updates and new tweets, but disastrous if you deal with money or other quantities. The amounts will simply end up wrong when many reads and writes are being done in parallel. So for the throughput you need, a memory centric NoSQL database with ACID support is probably the way to go.
OLTP can be achieved using NoSQL with a custom implementation,
there are two things, 1. How are you going to achieve ACID properties that an RDBMS gives. 2. Provide a custom blocking or non blocking concurrency and transaction handling mechanism.
To take you closer to solution, Apache Phoenix,apache trafodion or Splice machine.
Cassandra can be used for both OLTP and OLAP. Good replication and eventual data consistency gives you the choice in your hand. Need to design the system properly. And after all it's free of cost but not free of developer, give it a try
发布评论
评论（10）
在任何情况下我都不会使用 NOSQl 数据库来处理与金融有关的任何事情。您根本不具备所需的数据完整性或内部控制。 Dow Jones 使用 SQL Server 进行交易，如果他们能够正确设计高性能、高交易关系数据库，那么您也可以。你必须投资于一些知道自己在做什么的人。
There is no conceivable circumstance where I would use a NOSQl database for anything to do with finance. You simply don't have the data integrity needed or the internal controls. Dow Jones uses SQL Server to do its transactions and if they can properly design a high performance, high transaction Relational datbase so can you. You will have to invest in some people who know what they are doing though.
人们必须以不同的方式思考这个问题。事务一致性的概念源于CRUD（创建、读取、更新、删除）中的UD（更新）。 noSQL 数据库面向 CRAP（创建、复制、追加、处理），通过添加时间戳数据来工作。有了正确的领域模型，就没有理由不能实现可审计性和等效的引用完整性。
One has to think about the problem differently. The notion of transaction consistency stems from the UD (update) in CRUD (Create, Read, Update, Delete). noSQL DBs are CRAP (Create, Replicate, Append, Process) oriented, working by accretion of time-stamped data. With the right domain model, there is no reason that auditability and the equivalent of referential integrity can't be achieved.
基于全局存储的 NoSQL 数据库（InterSystems 的 Cache 和 FIS 的 GT.M）已广泛应用于金融服务领域，并且已使用多年。缓存尤其用于核心数据库和 OLTP。
The global-storage based NoSQL databases - Cache from InterSystems and GT.M from FIS - are used extensively in financial services and have been for many years. Cache in particular is used for both the core database and for OLTP.
我可以回答有关我扩展 Riak 的经验。
Riak 可以平稳地扩展到极致。扩展就像向集群添加节点一样简单，这本身就是一个非常简单的操作。只需添加节点即可实现近乎线性的可扩展性。就扩展而言，我们在 Riak 方面的经验令人惊叹。
但另一方面，它在很多方面都有所欠缺。一些示例：
count(*)或list key之类的操作。如果您想从 Riak 到 MySQL 进行 ETL，则需要解决这个问题 - 或者您如何知道要 (E)xtract 哪些内容？（一种可能的解决方法是维护一个具有已知键序列的存储桶，该序列映射到包含您插入其他存储桶中的键的值）。
I can answer regarding my experience with scaling Riak.
Riak scales smoothly to the extreme. Scaling is as easy as adding nodes to the cluster, which is a very simple operation in itself. You can achieve near linear scalability by simply adding nodes. Our experience with Riak as far as scaling is concerned has been amazing.
The flip side is that it is lacking in many respects. Some examples:
count(*)orlist keyson a production cluster. That would require a work around if you want to do ETL from Riak into MySQL - or how would you know what to (E)xtract?(One possible work around would be to maintain a bucket with a known key sequence that map to values that contain the keys you inserted into your other buckets).
TigerBeetle：https://tigerbeetle.com/
TigerBeetle: https://tigerbeetle.com/
我使用 Starcounter（所以我有偏见），但我认为我可以有把握地说，对于处理金融交易的系统，您必须担心交易一致性。不幸的是，这是 Facebook 和 Twitter 使用的引擎必须放弃的，以便他们的横向扩展策略能够提供性能。这并不是因为 MongoDb 或 Cassandra 等引擎设计不佳；而是因为相反，它自然地遵循 CAP 定理 (http://en.wikipedia.org/wiki/CAP_theorem)。简而言之，您在数据库中所做的更改将覆盖及时发生的其他更改。对于状态更新和新推文来说还可以，但如果你处理的是金钱或其他数量的东西，那就是灾难性的。当许多读取和写入并行完成时，数量最终会出错。因此，对于您所需的吞吐量，具有 ACID 支持的以内存为中心的 NoSQL 数据库可能是最佳选择。
I work with the Starcounter (so I’m biased), but I think I can safely say that for a system processing financial transactions you have to worry about transaction consistency. Unfortunately, this is what the engines used for Facebook and Twitter had to give up allow their scale-out strategy to offer performance. This is not because engines such as MongoDb or Cassandra are poorly designed; rather, it follows naturally from the CAP theorem (http://en.wikipedia.org/wiki/CAP_theorem). Simply put, changes you make in your database will overwrite other changes if they occur close in time. Ok for status updates and new tweets, but disastrous if you deal with money or other quantities. The amounts will simply end up wrong when many reads and writes are being done in parallel. So for the throughput you need, a memory centric NoSQL database with ACID support is probably the way to go.
如果您使用事件源和 DDD 概念来实现应用程序，则可以使用一些 NoSQL 数据库（Cassandra、EventStore）作为金融服务的存储。我建议您阅读这本迷你书 http://www.oreilly.com/编程/免费/reactive-microservices-architecture.html
You can use some NoSQL databases (Cassandra, EventStore) as a storage for financial service if you implement your app using event sourcing and concepts from DDD. I recommend you to read this minibook http://www.oreilly.com/programming/free/reactive-microservices-architecture.html
OLTP 可以使用 NoSQL 和自定义实现来实现，
有两件事，
1. 您将如何实现 RDBMS 提供的 ACID 属性。
2.提供自定义的阻塞或非阻塞并发和事务处理机制。
为了让您更接近解决方案，
Apache Phoenix、apache trafodion 或 Splice 机器。
OLTP can be achieved using NoSQL with a custom implementation,
there are two things,
1. How are you going to achieve ACID properties that an RDBMS gives.
2. Provide a custom blocking or non blocking concurrency and transaction handling mechanism.
To take you closer to solution,
Apache Phoenix,apache trafodion or Splice machine.
Trafodion 对 HBase 有完整的 ACID 支持，你应该看看。
Trafodion has full ACID support over HBase, you should take a look.
Cassandra 可用于 OLTP 和 OLAP。良好的复制和最终的数据一致性为您提供了手中的选择。需要正确设计系统。毕竟它是免费的，但不是免费的，请尝试一下
Cassandra can be used for both OLTP and OLAP. Good replication and eventual data consistency gives you the choice in your hand. Need to design the system properly. And after all it's free of cost but not free of developer, give it a try