blocks|key|1649833|text|在任何与金融有关的事情上，我都不会使用NOSQl数据库，这是不可想象的。您只是没有所需的数据完整性或内部控制。Dow使用SQL+Server进行事务处理，如果它们能够正确地设计高性能、高事务关系数据库，您也可以这样做。不过，你必须投资于一些知道自己在做什么的人。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1649834|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|318146|text|我们必须以不同的方式来看待这个问题。事务一致性的概念源于CRUD中的UD+(更新)(创建、读取、更新、删除)。noSQL数据库是以垃圾(创建、复制、附加、处理)为导向的，通过增加时间戳数据来工作.在正确的领域模型下，没有理由不能实现可审计性和引用完整性的等价性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|318147|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|1649843|text|基于全局存储的NoSQL数据库--来自InterSystems的缓存和来自FIS的GT.M+--在金融服务领域得到了广泛的应用，并且已经有很多年了。特别是，缓存既用于核心数据库，也用于OLTP。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1649844|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|1649797|text|我可以回答我的经验与缩放里亚克。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1649798|里亚克的鳞片平滑地达到了极致。缩放就像向集群添加节点一样容易，这本身就是一个非常简单的操作。您可以通过简单地添加节点来实现近乎线性的可伸缩性。我们与Riak的经验，就规模而言，是令人惊叹的。|1649799|另一方面，它在许多方面都缺乏。下面是一些例子：|1649800|1649801|您不能在生产集群上执行count(*)或list+keys之类的操作。如果你想从Riak做ETL到MySQL，或者你怎么知道(E)X域是什么，那就需要做一些工作。(一种可能的方法是使用已知的密钥序列来维护一个桶，它可以映射到包含插入到其他桶中的键的值)。improvement.|unordered-list-item|offset|length|style|CODE|1649802|You'll的免费版本|1649803|没有提供管理控制台，可以让您知道发生了什么事情，而企业版中包含的管理控制台并不太需要企业版的Riak，因为您希望通过WAN复制数据(例如，对于DR+/高可用性)。如果你不介意付钱的话，那也没关系，但要记住，Basho的价格很高。|1649804|1649805|entityMap^0|0|0|0|0|B|8|K|9|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|Y|8|@$J|Z|K|10|L|M]|$J|11|K|12|L|M]]|9|@]|A|$]]|$1|N|3|O|5|I|7|13|8|@]|9|@]|A|$]]|$1|P|3|Q|5|I|7|14|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|T|$]]

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:

<ul>
<li>You can't do something like <code>count(*)</code> or <code>list keys</code> 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).</li>
<li>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.</li>
<li>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.</li>
</ul>

blocks|key|1671888|text|我使用Star计数器(所以我有偏见)，但我认为我可以放心地说，对于一个处理金融交易的系统，您必须担心事务的一致性。不幸的是，这正是Facebook和Twitter所使用的引擎不得不放弃的，允许它们的扩展策略来提供性能。这并不是因为像MongoDb或Cassandra这样的引擎设计不当，而是自然地遵循了CAP定理(http://en.wikipedia.org/wiki/CAP_theorem)。简单地说，您在数据库中所做的更改将覆盖其他更改，如果这些更改发生的时间较短。好的状态更新和新的推特，但如果你处理金钱或其他数量灾难性的。当许多读和写同时进行时，这些数量将是错误的。因此，对于您需要的吞吐量，一个支持ACID的以内存为中心的NoSQL数据库可能是可行的。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1671889|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/CAP/_theorem^0|4D|14|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

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.

blocks|key|1649906|text|如果您使用事件源和DDD的概念来实现应用程序，您可以使用一些NoSQL数据库(Cassandra，EventStore)作为金融服务的存储。我建议你读这本迷你书http://www.oreilly.com/programming/free/reactive-microservices-architecture.html|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1649907|entityMap|0|LINK|mutability|MUTABLE|url|http://www.oreilly.com/programming/free/reactive-microservices-architecture.html^0|28|28|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

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 <a href="http://www.oreilly.com/programming/free/reactive-microservices-architecture.html" rel="nofollow">http://www.oreilly.com/programming/free/reactive-microservices-architecture.html</a>

blocks|key|318255|text|可以使用带有自定义实现的NoSQL来实现OLTP，|type|unstyled|depth|inlineStyleRanges|entityRanges|data|318256|有两件事，1.如何实现RDBMS给出的ACID属性。2.提供自定义阻塞或非阻塞并发和事务处理机制。|318257|要使您更接近解决方案，请使用Apache凤凰、apache+trafodion或Splice机器。|318258|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

blocks|key|1671942|text|Trafodion对HBase有完全的ACID支持，您应该看看。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1671943|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Trafodion has full ACID support over HBase, you should take a look.

blocks|key|1649890|text|Cassandra可用于OLTP和OLAP。良好的复制和最终的数据一致性为您提供了选择。需要正确设计系统。毕竟，它是免费的，但不是免费的开发人员，试试看|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1649891|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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

We're designing an OLTP financial system. it should be able to support 10.000 transactions per second and have reporting features.

So we have come to the idea of using:

<ul>
<li>a NoSQL DB as our main storage</li>
<li>a MySQL DB (Percona server actually) making some ETLs from the NoSQL DB for store reporting data</li>
</ul>

We're considering MongoDB and Riak for the NoSQL job. we have read that Riak scales more smoothly than MongoDB. And we would like to listen your opinion.

<ul>
<li>Which NoSQL DB would you use for a
OLTP financial system?</li>
<li>How has been
your experience scaling MongoDB/Riak?</li>
</ul>

Which NoSQL DB is best fitted for OLTP financial systems?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我们正在设计一个OLTP金融系统。它应该能够支持每秒10.000个事务，并具有报告功能。因此，我们有了这样的想法：a NoSQL DB作为我们的主要存储空间a MySQL DB (实际上是Percona服务器)从NoSQL DB中生成一些ETL用于存储报告数据我们正在考虑MongoDB和Riak的NoSQL工作。我们已经读到里亚克音阶比MongoDB更平滑。我们想听听你的意见。Which NoSQ

问哪一个NoSQL DB最适合OLTP金融系统？
EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问哪一个NoSQL DB最适合OLTP金融系统？EN

回答 9

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问哪一个NoSQL DB最适合OLTP金融系统？
EN