银行交易监控实时分析数据库如何选型？

提到交易表50个属性字段，如果使用hbase进行存储查询，那么根据hbase的特性key/value存储形式以及底层存储key的有序性，在设计key上是否可以对经常进行需要关联的字段拼接成一个key，这样既保证查询速度，又保证sql的简便。如果上述路数行不通，那可以考虑使用hive，hive中数据的优化处理还是有很多方法的，尤其数据关联方面。最后提到表的建模优化，交易表50个属性字段，这些字段能否进行拆开成两张表，具体还得看这些字段在实际中数据的冗余度。

推荐你采用DB2数据库，有以下几个原因：
1. DB2数据库在银行金融行业使用比较广泛，大部分银行用的都是DB2数据库。
2. DB2数据库支持Share nothing和Share everyting两种架构，Share nothing的DPF功能多用于数据仓库系统，Share everything的pureScale技术多用于OLTP系统。因此不管你的系统是什么类型的，DB2都可以满足你的需求。（目前Oracle还只有Share everything的RAC一种架构）
3. 在性能上，DB2数据库无疑是表现最好的，根据我们做过的PoC，在性能上DB2很少有输给其他数据库的情形。
4. 针对你说的场景，银行交易数据的持久化，我想在大部分银行里面都已经有成功的案例，比如各大银行的网银系统，银联的交易系统，用的都是DB2数据库。
5. 再说一个百亿级的海量数据系统，移动的日志系统，数据量比你这个大多了，用的也是DB2数据库。

关于选型，DB2数据库在银行业肯定是首推的，这个没有什么问题。但我想，你的问题不光是选型这么简单，应该还需要一个完善的架构设计，比如你的系统除了数据入库以外还有哪些操作？pureScale与DPF采用哪种架构更合适？能否采用分区表来进行优化？能否采用random索引进行优化？如何优化入库速度？如何物化查询结果？是否需要进行workload管理？等等。所有这些问题都需要在了解业务之后才能进行设计。不妨再详细介绍一下业务，或者联系我们进行讨论。

只对DB2了解一些,随便说说

商务角度上来讲,金融,银行这个行当你选DB2就算不出彩也肯定不会出错.太新的技术不是 说不能选,这 个东西没经过验证,试错,拿过来直接用有风险.就算和其他DB可能在性能上讲互有所长,但是总不至于出现数量级的差别.你别说,真的有差两个数量级的.能 把单机SMP那么多核都压上去,可不是件容易的事,更别说组个集群了.等真选定了型了,再哭只能晚了.

另外,选型方案的时候,别追新,找案例参考很重要,只是嘴上保证能上的,最好留个心眼,金融这个行业,一怕拍板,二怕背黑锅.你选个可能让领导背黑锅的方案,请领导拍板,领导没准会不高兴.弄不好银监会发个文什么的,大家都尴尬.

技术角度上来说,虽然每秒新生数据量不高,但是分析要横跨半年数据,还要有所谓的实时性要求,对于分析的性能要求应该很高.应该是个典型的OLAP的应 用,pureScale就没必要上了,那个是给典型的OLTP准备的.而且一般OLAP对于高可用的要求也没有高到pureScale所提供的 Continuous Availability的程度.

下面还是讲讲DB2提供给OLAP的一些特色的功能,BLU,DPF,MDC,看看哪个适用你的情况?

BLU- 简单的说就是列式内存数据库,功能极其强悍,用同样的环境做benchmark,碾压O记的in-memory option.最适合做分析,而且速度肯定是最好的,一般来说性能是行存的40倍没问题.而且发布了一段时间,该趟的雷都趟完了,放心使用. 但是问题是不能组集群,BLU目前在10.5上只能在单机(SMP)上运行,单机推荐支持的数据量在30T左右.另外对机器的性能要求较高,内存也是越大 越能玩得转,我们做benchmark的机器是60cores,2.5G Hz IB,1T RAM,800G SSD,6x1.2TB HDD,2.5T的workload,每小时762个report,仅供参考

DPF-这个不多说了,MPP集群,分库,扩展性,对于单机性能要求没那么高,就我所知目前国内最大的DPF集群应该是广州移动,600T的数据

MDC-Multi-Dimension Clustering,多维聚簇,这个应该很适合你的情况,可以定义多个维度,并且每个维度上都有block index用来提升效率,无论你是在slice上还是cell上查询,都能有很好的效率,看图吧

另外这玩意能和DPF,Table Partitioning(分表/区表),一起使用,并行度一下子就上去了,还是看张图吧

另 外上面有同学提到大机,其实大机上的DB2z还是以OLTP为主,虽然推了好多OLAP的功能,还对OLAP的功能进行优惠比如zIIP.但是国内在分析 这块采用大机的还真不多.比如宇宙行现在应该用着最大的datasharing group了..但是OLAP还是放到开放来做..IBM是多希望大家都用大机,都留在大机上啊~

如果用oracle rac，我有以下建议：

一、如果有不同的应用，可以把每个应用对于ＲＡＣ中不同的节点，这样会减少RAC 节点之间的数据同步

二、搭建ＤＧ，报表分析在备库上操作。

三、存储可能会成为瓶颈，可以用高端点的存储，以及 raid 10陈列。

四、应用及表结构的设计很可能成为数据库的瓶颈。

注：每秒钟4000条的记录，对于数据库和存储来说，不算很多，应用的计设很有可能成为整个系统的瓶颈。。。

实时分析是指每时每刻都要进行分析吗？

这个4000TPS主要做什么？要实时入库吗? 交易分析的联合查询是什么样子的？ 初步看起来这个系统并不像是有很高可用性需求的，并且数据量大，分析要求比较高。暂时推荐DPF

支持海量数据TB级，又能满足RDBMS特性的数据库：

greenplum(postgreSQL转化而来），南大通用的GBase 8s(MySQL转化而来），HP 的vertica 都支持列式数据存储，又能分布式计算和数据存储。

可以试试db2 的BLU ，分析是他的强项， 多维度关联完全不是问题。

另外db2 的json 也是一个方向，可以解决你多表关联的问题。