我正在寻找NoSQL来扩展数据库的替代方案。如果我想要对此类事物敏感的基于事务的事物，该怎么办？
Answers:
一般而言，NoSQL解决方案的事务语义比关系数据库更轻巧，但在某种程度上仍具有原子操作的便利。
通常，执行主-主复制的服务器提供的一致性较少，而可用性更高。因此，应该为正确的问题选择正确的工具。
许多提供单个文档（或行等）级别的事务。例如，在MongoDB中，单个文档具有原子性-但是文档可以相当丰富，因此通常可以很好地工作-在此处提供更多信息。
这是我发现的最接近的答案，适用于任何NoSQL数据库。它在Heroku.com的Adam Wiggins的2007年博客文章中：
使用数据库事务来将资金从一个银行帐户转移到另一个银行帐户的旧示例是“总牛市”。正确的解决方案是存储分类帐事件的列表（帐户之间的转帐），并将当前余额显示为分类帐的总和。如果您使用功能性语言编程（或以这种方式思考），这是显而易见的。
来自：http : //adam.heroku.com/past/2007/12/17/a_world_without_sql/（他的网站非常适合可扩展性方面的想法。）
我将以上段落解释为：
更多信息。在队列/后台工作者上：http : //adam.heroku.com/past/2009/4/14/building_a_queuebacked_feed_reader_part_1/
客户（又名会员或客户）按照以下步骤提取资金：
如果您对Node.js或Ruby / Rack感到满意，则可以使用Heroku.com快速创建一个小型模型。
总的想法似乎很容易，并且比使用数据库中难于扩展的事务更好。
免责声明：我尚未以任何方式实施此操作。我出于好奇而阅读了这些内容，尽管我实际上并不需要它们。是的，@ gbn是对的，带有事务的RDBMS可能足以满足Timmy和我的需要。不过，很高兴看到您可以使用开源工具和一个名为“ Razorblades的龙卷风”的入门网站将NoSQL数据库带到多远。
NoSQL涵盖了各种各样的工具和服务，包括键值，文档，图形和大列存储。他们通常尝试通过分布数据处理来提高数据存储的可伸缩性。事务需要数据库如何执行用户操作的ACID属性。ACID限制了如何提高可伸缩性：大多数NoSQL工具放宽了操作的一致性标准，以获取容错性和可扩展性，这使得实施ACID事务非常困难。
CAP定理通常被认为是分布式数据存储的理论依据：一致性，可用性和分区容忍性不能同时实现。SQL，NoSQL和NewSQL工具可以根据它们放弃的方式进行分类。在这里可以找到一个好身材。
代替ACID的一组新的，较弱的需求是BASE（“基本上可用的，软状态，最终的一致性”）。但是，最终一致的工具（“最终对项目的所有访问将返回最后更新的值”）在银行等交易应用程序中几乎是不可接受的。这里的一个好主意是使用内存中，面向列的分布式SQL / ACID数据库，例如VoltDB；我建议查看这些“ NewSQL”解决方案。
只是想评论此线程上的货币交易建议。交易是您真正想与转帐一起使用的东西。
给出的如何进行传输的示例非常整洁。
但是在现实生活中，转帐可能包括向其他帐户收费或付款。人们会因使用来自其他帐户的某些卡而获得奖金，或者他们可能会从其帐户收取的费用转至同一系统中的另一个帐户。费用或付款可能因金融交易而异，您可能需要保持簿记系统，该系统会在每次交易发生时显示其贷方和借方。
这意味着您要同时更新多个行，因为可以从一个或多个帐户上借记一个帐户的贷方。首先，您锁定行，以便在更新之前不能进行任何更改，然后确保写入的数据与事务一致。
这就是为什么您真正想要使用事务的原因。如果在写入一行时出现任何问题，则可以回滚整个更新，而不会导致财务交易数据不一致。
一笔交易和两项操作（例如一笔支付5,000美元，第二笔收取5,000美元）的问题是您有两个优先级相同的帐户。您不能使用一个帐户来确认第二个帐户（或以相反的顺序）。在这种情况下，您只能保证一个帐户是正确的（已确认），第二个帐户（确认）可能会失败。让我们看一下它为什么会失败（使用消息提示，发送者被接收者确认）：
它将保证除了＃1。但是，如果＃2失败了，谁能保证？反向顺序相同。
但这可以实现没有事务和NoSQL的安全。始终允许您使用将由发送方和接收方确认的第三实体，并保证已执行您的操作：
此交易记录将确保可以发送/接收消息。现在，您可以按事务ID检查每条消息，以及它的状态是否已收到或已完成-您可以考虑将其用于用户余额。
您始终可以在SQL DB中使用NoSQL方法。NoSQL似乎通常使用“键/值数据存储”：您始终可以在首选的RDBMS中实施此操作，从而保留诸如事务，ACID属性，友好的DBA的支持之类的好东西，同时实现NoSQL的性能和灵活性优势，例如通过诸如
CREATE TABLE MY_KEY_VALUE_DATA
(
id_content INTEGER PRIMARY KEY,
b_content BLOB
);
值得一提的是，您可以在此处添加额外的字段，以将您的内容链接到其他适当关系的表中，同时仍将大容量内容保留在主BLOB（或TEXT，如果适用）字段中。
我个人比较喜欢TEXT表示形式，因此您不会被用于处理数据的语言所束缚，例如，使用序列化Java意味着您可以从Perl访问内容进行报告。TEXT也更易于调试，通常可以作为开发人员来使用。
看看scalaris它具有强大一致性和已实现事务的无SQL数据库。
这就是为什么我要创建NoSQL文档存储解决方案，以便能够借助非结构化数据方法在企业应用程序上使用“真实”事务。请访问http://djondb.com，并随意添加您认为可能有用的任何功能。
肯定还有其他