我正在研究用NoSQL来替代数据库进行扩展。如果我需要基于事务的操作,而且这些操作对数据完整性要求很高,应该怎么做?
我正在研究用NoSQL来替代数据库进行扩展。如果我需要基于事务的操作,而且这些操作对数据完整性要求很高,应该怎么做?
一般来说,与关系型数据库相比,NoSQL的解决方案具有较轻的事务语义,但仍然在某个级别上提供原子操作的功能。
通常情况下,那些进行主-主复制的解决方案在一致性方面提供的较少,可用性则更高。因此,应该选择正确的工具来解决相应的问题。
许多解决方案在单个文档(或行等)级别上提供事务支持。例如,在MongoDB中,单个文档可以实现原子性,但文档可以相当丰富,所以这通常可以很好地工作——更多信息请参见此处。
如果您熟悉Node.js或Ruby/Rack,可以使用Heroku.com快速创建小型模拟。
总体思路似乎非常简单,并且比使用嵌入式在数据库中的事务要好得多,这使得它难以扩展。
免责声明:我尚未以任何方式实施此功能。我只是出于好奇心阅读这些内容,即使我没有实际需要。是的,@gbn正确,具有事务的关系型数据库可能已足够满足Timmy和我的需求。尽管如此,使用开源工具和名为“A Tornado of Razorblades”的how-to网站来推动NoSQL数据库的发展到哪个程度将是有趣的。
NoSQL 涵盖了一系列不同的工具和服务,包括键值存储、文档存储、图形数据库和宽列存储。它们通常试图通过分布式数据处理来提高数据存储的可扩展性。
事务需要数据库执行用户操作的 ACID 特性。ACID 限制了如何提高可扩展性:大多数 NoSQL 工具放松了操作的一致性标准以获得容错性和可用性,这使得实现 ACID 事务非常困难。
分布式数据存储的一个常被引用的理论原因是 CAP 定理:一致性、可用性和分区容错性不能同时实现。根据放弃哪些特性,可以将 SQL、NoSQL 和 NewSQL 工具进行分类;可以在这里找到一个好的图表。
替代 ACID 的一组较弱要求是 BASE("基本可用、软状态、最终一致性")。然而,最终一致性的工具("最终所有对项目的访问将返回最后更新的值")在银行等事务应用中几乎不可接受。在这里,一个好的想法是使用内存、列式和分布式 SQL/ACID 数据库,例如VoltDB;我建议看看这些 "NewSQL" 解决方案。
在这个帖子中,我想评论有关金钱转账建议的问题。交易是您真正想要与货币转移一起使用的东西。
给出的关于如何排队传输的示例非常好和整洁。
但是在现实生活中,转移资金可能包括向其他帐户支付费用或付款。人们可以因使用来自另一个帐户的某些卡而获得奖金,或者他们可能需要从他们的帐户中向同一系统中的另一个帐户缴纳费用。这些费用或付款可能因财务交易而异,您可能需要保持簿记系统以显示每个交易的借方和贷方。
这意味着您想要同时更新多行,因为一个帐户的贷方可能是一个或多个帐户的借方。首先,您锁定行,以便在更新之前不会更改任何内容,然后确保所写入的数据与交易一致。
这就是为什么您真正想要使用事务。如果对一行写入的任何内容出了问题,您可以回滚整批更新,而不会使财务交易数据无法匹配。
在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,它是一个具有强一致性和实现事务的NoSQL数据库。