JP摩根在金融衍生品交易系统中引入NoSQL数据库技术

JP摩根通过将关系型数据库切换成NoSQL数据库系统，来降低其金融衍生品处理系统的复杂度, 以便于处理更多样性的数据并且满足日益增长的需求.

通过各类非常复杂的金融工具，该美国银行业巨头每日会产生成百上千的并且价值以亿计甚至兆计的金融衍生交易，但目前的关系型数据库并不适合存储并处理这些交易。

为降低系统压力，也为整合不同的数据库，以便于处理某些特定的功能，该银行与其合作伙伴MarkLogic软件一同开发实施了他们的NoSQL数据库技术。

在伦敦Gartners EI MDM;峰会上，负责公司衍生产品以及外汇交易的首席技术官Keith Pritchard说道，“起初，由于金融衍生品有着许许多多的产品，我们根据各产品类型设计了各类复杂的基础架构，以至于我们最终的架构变得零散化，并且实施代价昂贵。而我的任务就是将这些整合到同一个基础架构中去。”

“因此我们对于能带来横向扩展能力的NoSQL数据库技术非常感兴趣，因为以后我们只需增加数据库容量，而不用大规模替换系统架构。

灵活性与可扩展性

NoSQL（即非关系型数据技术）数据库，不同与于传统SQL关系型数据库系统，它能允许业务人员更加方便地分析庞大的非结构化数据。JP摩根实施该技术的原因之一就是由于该类数据库技术的灵活性，它可以灵活的处理各种各样的交易数据。

“从一个数据的视角，我们处理的许多金融衍生品工具是非常灵活善变的。”他说道，“特别在OTC[WD1] (场外交易)市场，交易员需要能够在一个交易中放入相当多的他们所需要的功能，以至于我们输出的输入数据是多种多样性的。”

“同样，我们也有非常多样的输出数据。特别是现在，监管机构特别关注于各银行在干什么，会每天向我们提出各式各样不同的问题。”

“因为我们不知道输入的数据结构，我们也不知道数据的使用模式，而关系型数据又是相对固定的，所以我们需要摆脱关系型的技术。因为通过我25年的金融服务生涯得出的结论，这类技术一直企图将我固化在一个特定的模式中，导致我无法灵活应对。”

然而，Pritchard警告道，在向非关系型数据库迁移的过程中，往往会伴随着挑战，因为它需要开发人员改变原有的思维。

“对我而言，最大的教训就是不要低估我们对于技能改变的需要，至少涉及到开发团队的思维过程和处理方式的改变。”

“由于公司内绝大多数的开发人员从入行开始就使用关系型数据库，因此他们带有着关系型数据模型思想并且了解如何处理该类数据，然而一旦改变至NoSQL数据结构，我们就将给自己带来各种问题。”

“有时我们常常工作事倍功半并且数据查询非常低效，因为我们在本不需要使用非结构型数据库的时候，试着使用NoSQL数据库来处理这些事情。所以之后，我会更多的考虑如何事先去组织准备工作。”

侦测市场的操作行为

虽然银行现在已经使用NoSQL技术多年，但Pritchard认为公司仍可以利用该技术做更多的事情。

“对我们而言，下一步更大的革新将是我们要做很多工作去拓展该平台上的产品组合和所在领域。但是我的下一个挑战是如何开始有组织化的有区别的使用这些数据。”他说道。

“目前我们在交易过程中已经真正的使用了这些技术，但有些价值还没有被好好开发。例如，我们应该在自然语义能力方面做很多工作，将它运用到了寻找交易模式中。这也许可以被用来即时识别市场操作，比如交易员试图做空市场来压低价格的时候。”

“也正由于我们已经得到了这种整合所有产品的能力，我们能使用该技术来做这类事情。那将是我们未来使用的方向。”

译者分析：

以下译者解析只代表译者个人观点，欢迎讨论

NoSQL数据库技术现今已经在很多领域使用，但从国内银行金融领域来看似乎并没有很好的运用起来。似乎国内银行与文中的JP摩根相比有一定的差距。其实并不是如此。

了解NoSQL技术的话，可以知道目前NoSQL技术运用最多的是分布式文件系统，而分布式文件系统的运用更适合一次存储多次读取的分析应用，而传统关系型数据库更适合持续更新的数据处理。[WD2]

从应用场景来看，银行金融的交易场景是频繁的，导致实际的交易是持续更新的。这也就是为什么BAT们持续在叫嚷着去IOE，而银行却没有相应的措施去改变他们的core banking系统，这不是银行的技术能力不行（在所有行业中，金融行业的IT力量是比较强的），而是技术真的无法完全适应银行的交易场景。

另外由于银行通过交易系统产生的绝大多数的数据都是结构化数据，因此对于绝大部分的数据没有必要转换成非结构化数据或半结构化数据去特意的使用NoSQL技术。

因此从新闻中，我们可以发现JP摩根丝毫没有提利用该技术进行交易过账，只是说将NoSQL技术作为了金融衍生产品交易系统的数据存储技术，通过该技术进行数据分析。这也是因为金融衍生交易的多样性和多变性，导致该类数据更趋向于半结构化数据，更易于被NoSQL技术加以分析。

目前国内银行也是如此应用的，采用了传统数据仓库技术+NoSQL数据库技术作为数据库存储及处理技术。

当然现在的技术日新月异，NoSQL的技术发展也异常迅速，可能再过不长的时间也会有新技术出现，帮助银行金融行业更快更高效的进行交易。

[WD2]我觉得SQL或NoSQL主要看存储的数据是结构型还是非结构型，而不在存储次数。所以理论上讲即便是高频交易，只要产生或需要的数据类型是非结构型的，也可以用NoSQL.NoSQL数据库在以下的这几种情况下比较适用：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性；5、对于给定key，比较容易映射复杂值的环境。

当然以银行现有的交易系统产生的数据来看，的确没必要转换成非结构化数据。

原文发布时间为：2015-03-31

本文来自云栖社区合作伙伴“大数据文摘”，了解相关信息可以关注“BigDataDigest”微信公众号

OceanBase携手天阳科技推出新一代信用卡核心系统联合解决方案，为信用卡业务稳健增长提供创新活力与数据动力 1985 年，中国银行发行我国第一张人民币信用卡。经过 30 余年的发展，信用卡已经从少数精英才能持有向大众普及，据央行数据显示，截至 2022 年一季度末，我国人均持有信用卡和借贷合一卡 0.57 张。
阿里云Lindorm联合智臾科技发布金融高频交易数据量化分析与处理方案 阿里云原生多模数据库Lindorm联合浙江智臾DolphinDB发布金融高频交易数据量化分析与处理方案，通过云原生方式整合DolphinDB实时高效的数据处理能力和Lindorm多模海量数据融合存储分析能力，集成了功能强大的编程语言和高容量高速度的流数据分析系统，为金融场景海量时序数据的量化分析计算提供一站式解决方案。方案操作简单，可扩展性强，具有良好的容错能力及优异的多用户并发访问能力。
带你读《区块链工程实践 行业解决方案与关键技术》之二：电力市场交易结算智能合约 本书是一部能全方位指导区块链项目落地的实操性著作。通过5个经典的行业案例，从总体设计、业务设计、功能接口设计、架构设计这4个维度详细讲解了如何构建一个完整的区块链行业解决方案，同时讲解了实现每个解决方案需要的关键技术和方法。