巨杉数据库:金融级数据库是怎样炼成的
巨杉数据库:金融级数据库是怎样炼成的
巨杉数据库SequoiaDB是一家特立独行的金融级数据库厂商。大型企业客户需要“原厂”金融级数据库产品和服务,巨杉数据库坚持以此为宗旨,历经6年从1.0到3.0的不断迭代创新,目前已经广泛应用于银行、证券、保险、政府、电信等大型企业的核心生产系统。
巨杉联合创始人王涛表示,在业务量爆炸性增长的今天,传统数据库正面临着巨大的挑战,例如Oracle、DB2,其扩展能力和性价比都存在相当的局限性。大型企业需要的是既有分布式能力,又如Oracle这样能达到金融级水准的数据库产品。
因此,在6年不断成长创新迭代中,巨杉改变了国产数据库长期低迷的状态。在分布式领域,巨杉数据库已经走在Oracle 12c的前面。
“金融级”的核心来自于原厂的产品能力
大型企业IT的管理是个非常复杂的过程,既要考虑技术的先进性,也要满足各种系统的兼容、合规以及风控的要求。因此,大型企业在选择技术产品时,首先要判断该产品是否满足企业级需求。
除了高性能与可靠性以外,企业级最根本的核心是产品化,适用于多种负载及业务场景;以及原厂支持能力,并且提供源代码及内核开发人员级别的技术支撑。
互联网公司的技术发展路线是以解决自身业务的特定场景和功能为目的,并不考虑产品化,这和面向大型企业的产品发展路线相比,是两种不同的模式。这也是为什么互联网巨头也很难推出金融级产品的原因。
所以说,满足金融级需求的核心要素是原厂产品能力,即完全自主掌控产品代码和产品的发展路线。
银行是金融级应用的标杆
以银行为首的金融行业占据了50%以上的企业级IT投入,接着才是政府、运营商等行业。一般来说,一家银行通常拥有超过百种以上的业务系统,而且历经几十年的法律和业务规则的演进。因此,业界公认银行在选择技术产品过程中,对于安全性、可靠性、复杂度等企业级功能要求最为严苛。
银行作为企业级软件应用的标杆行业,被其采用的产品达到了金融级产品的最高标准,自然更能够满足其他行业的要求。
1、银行用户对于产品的选择非常严苛,为什么这么多银行会选择巨杉数据库呢?
这得益于巨杉的企业级基础软件基因。巨杉的研发技术以IBM DB2数据库和华为分布式技术团队为班底,是中国最好的“原厂”数据库产品团队。
巨杉数据库经过6年从1.0到3.0的不断迭代创新,历经了大中型银行核心生产系统的严格验证和洗礼,厚积薄发,才成为被银行金融业界所信任的金融级数据库产品。
2、数据库产品的发展曲线和生命周期都比较长,这是什么原因呢?巨杉对于此的观点怎么样的呢?
的确如此,数据库是基础性软件,好比汽车的引擎一样,是任何系统的_关键部件,具有“牵一发而动全身“的特性。这就要求数据库具有相当高的成熟度。这种成熟度需要在技术、产品、工程、支持以及行业经验上具有相当长时间的积累。
传统的关系型数据库中,例如Oracle、IBM DB2等,都历经20多年才达到现在的版本。任何一款数据库从研发到产品都是一个历经磨难的过程,一般需要6年以上的时间才能走出0到1 的阶段,然后再在行业和实际应用场景中不断地历炼打磨,逐步过渡到成熟期。
另外,金融级数据库产品面对的是诸如银行、证券、保险等头部行业大型企业,对产品上的复杂度和成熟度又提出了更高层次的要求。因此,其生命周期还要更长。
SequoiaDB作为金融级数据库产品历经6年发展,进入3.0时代,得到上百家大型银行等大型客户的采用和信任。这标志着巨杉数据库已经进入了数据库生命曲线的成熟期。
3、巨杉一直坚持“原厂”,这是为什么?
这和巨杉的商业模式息息相关。巨杉主营是数据库产品及服务,服务于很上百家大型的企业,上千的业务系统,每年还在不断地增长。数据库作为基础工具型软件,要满足各种系统需求,而不为单一特定的场景服务。做到这点的核心就是“原厂”掌握核心代码,掌控产品路线,能够快速应对客户需求的同时也能保证产品化。
我们都知道,细节定成败,实践出真知,技术实力的背后是产品能力。一个成熟的产品需要不断的在大规模的金融级应用中实践与砺炼。这个过程就是不断爬坑、不断积累经验和不断完善细节。
这对一个产品研发的工程及管理能力提出了相当高的要求。例如巨杉数据库产品的测试,产品达到99%以上自动化测试覆盖率,为保障质量,每个小版本的测试都涉及12,000个以上的测试用例,横跨超1000个服务器节点。
只有这样,我们的产品才能做到只用一个产品、一个研发团队来满足所有的客户,提供“原厂”代码级别的支撑服务。
4、巨杉数据库和Oracle, MySQL这样的传统关系型数据库的关系和对比是怎么样的?有何优势?”
巨杉的发展目标就是想成为“分布式”的“Oracle”。怎么解释呢,就是说从金融级产品能力和服务能力要达到Oracle的水准,但又是分布式的新一代数据库。巨杉在分布式领域已经处于领跑地位,跑在了Oracle 的前面。
例如,巨杉数据库在同一个分布式架构下支持非结构化的对象存储,能够在高并发场景下处理多种结构数据,大规模地降低了运维成本。这相比传统数据库是个独特的优势。
对比MySQL则大不相同,巨杉数据库专注服务于大型的企业,MySQL则是更偏向于互联网、创业阶段的中小企业市场,金融级产品标准和服务对象都不一样。
5、分布式数据库真的是未来的方向吗?
这点毋庸置疑。分布式的研究来自于并行计算,这其实很早就有,不是个新鲜事物。只不过过去网络、存储、计算成本比较高的时候,分布式的成本和性价高。造成做分布式数据库从成本和应用角度上不合适。
现在网络、存储、计算成本都大幅降低,这就是摩尔定律的威力。也是造成互网联网在过去20年内的高速发展。发展到了现在,这种利用x86服务器做分布式计算的能力已经大幅度超越了传统集中式的能力。加之现在数据使用的量级也是每年技术级的增长,传统数据库力不从心,因此从需求和技术能力两个方面都使得分布式数据库成为必然。
6、现在大型企业就需要“两地三中心”的说法,分布式数据库能解决这个问题吗?
两地三中心是指跨地域的数据中心,是分布式的最重要的应用场景。Oracle在1992年开始就研究跨地域的数据同步,结果因为关系型的特点,优势也成了劣势,在分布式发展上非常失败,所以回归到集中模式了。
这里面在术语上有“一致性”的问题,就是如何保证不同地域节点的数据相同。其中强一致指任何时候不同节点的数据都相同,而最终一致性指经过很短的时间延迟后,不同节点的数据最后终会相同。这在过去传统数据库里不可调和。分布式解决这个问题的能力非常强大,可配置的一致性是分布式数据库的重要部分,可以解决不同业务场景对不同一致性的需求。
所以巨杉数据库的特点之一就是支持两地三中心的架构。
7、国外很多分布式的数据库也开始提供SQL支持了,巨杉也支持是吧,这是为什么?
巨杉支持SQL要回到2014年了,比国外同行起步早很多。巨杉当时虽然在性能上独树一帜,但是很快发现客户的开发和运维都太习惯SQL了。SQL是个非常好的语言和工具,历经40年培养了大量的用户人才和应用习惯。可以说,99%的企业用户都需要SQL。
巨杉的技术驱动来自于用户和市场,所以当机立断,我们就开始增强对SQL的支持,到现在,我们同时支持高并发的标准SQL也支持分析型的Spark SQL,满足不同的用户需求。
8、巨杉是NoSQL数据库还是NewSQL,很多人都混淆,能解释一下吗?
巨杉数据库在经历了多年的发展以来,经历了从NoSQL向NewSQL再向关系型数据库不断演进的过程,如今已经支持标准SQL、OLTP、对象存储以及JSON存储等多种模式。
根据Gartner的定义,如今的巨杉数据库是一个典型的多模数据库(Multi-Model Database),可以被当做关系型OLTP数据库使用的同时,也支持半结构化数据与非结构化数据的存储。
9、在产品上,目前巨杉数据库的对标目标已经是Oracle而超越了MongoDB,在企业级市场特别是银行,为什么能够比MongoDB更为成功?
巨杉数据库 3.0是一款分布式对象存储、分布式文档型和分布式OLTP全覆盖的多模(Multi-Model)金融级分布式数据库,而MongoDB,couchbase等产品仅相当于巨杉数据库的一个子集。
SequoiaDB从开始之初就定位于原厂的金融级产品,1.0版本起就直接被银行企业采用。MongoDB是面向开发者、程序员的数据库产品,帮助开发快速迭代。所以SequoiaDB和MongoDB的出发点截然不同。
SequoiaDB从2.0版本开始,向着分布式多模数据库不断演进,大力发展SQL支持能力。不管从功能上还是性能上都超越MongoDB。
巨杉数据库的商业模式对标Oracle,以大型企业为服务对象,而MongoDB则服务于长尾的中小型企业市场,双方的用户领域大不相同。因此巨杉并没有把MongoDB作为对标产品和竞争对手。
10、2012年成立至今,巨杉数据库经历哪几个发展阶段?整个产品打磨经历了多长时间?
2012年,巨杉数据库在公司成立之初,利用分布式的特征提高性能,解决传统关系型的性能瓶颈。最早的版本是分布式文档型数据库,分布式架构下主要以高并发性能为优势特点。
2015年初 2.0版本开始向多模(Multi-Model)的分布式数据库发展,包括OLTP和SQL的支持,增加高并发查询的SQL引擎和分析为主的Spark SQL引擎,并成为了Spark的全球14个发行商之一。
同时,巨杉也开发分布式对象存储引擎,在同一个分布式架构下能同时管理操作记录型数据和非结构化的块结构数据。
2017年巨杉数据库全面支持高性能海量数据处理,事务处理,数据库级别的HTAP以及对象存储等多种应用场景,并继续加强分布式OLTP的能力。
巨杉数据库:金融级数据库是怎样炼成的相关推荐
- 巨杉数据库:金融级数据库未来方向
引言 近年来,全球金融科技每年的投入已经超过500亿美元,中国的金融科技发展更是引领世界潮流.在金融科技不断发展的今天,中国金融互联网化和零售化的发展愈加激烈,使得我国金融业务与科技的有机结合应用模式 ...
- 【演讲实录】金融级数据库技术与实践
近期,巨杉数据库 受邀在第七届数据技术嘉年华中做了"金融级数据库技术与实践"为主题的演讲,分享了巨杉数据库有关金融行业数据库管理以及金融级数据库技术与应用的一些实践及思考. 新一代 ...
- 为数据赋能:腾讯TDSQL分布式金融级数据库前沿技术
作者简介:李海翔,网名"那海蓝蓝",腾讯金融云数据库技术专家.中国人民大学信息学院工程硕士企业导师.著有<数据库事务处理的艺术:事务管理和并发访问控制>.<数据库 ...
- 腾讯金融级数据库TDSQL的架构与应用
腾讯金融级数据库TDSQL的架构与应用 字数4064 阅读358 评论2 喜欢0 腾讯云金融级数据库CDB for TDSQL (Cloud DataBase for Tecent Distribut ...
- 腾讯潘安群:腾讯云金融级数据库TDSQL分析
SDCC 2015将于2015年11月19-21日在北京.朗丽姿西山花园酒店召开.在大会召开之际,笔者采访到了腾讯高级软件工程师潘安群,请他分享TDSQL在腾讯云金融领域的实践经验. SDCC 201 ...
- 【SDCC讲师专访】腾讯潘安群:腾讯云金融级数据库TDSQL分析
摘要:SDCC 2015将于2015年11月19-21日在北京.朗丽姿西山花园酒店召开.在大会召开之际,笔者采访到了腾讯高级软件工程师潘安群,请他分享TDSQL在腾讯云金融领域的实践经验. SDCC ...
- 成为金融级数据库,腾讯TDSQL 的底气是什么?
作者 | 宋慧 14.1178 亿,是第七次人口普查,全国人口总数.全国 700 万普查员,首次线上完成普查数据采集,数据直接上报至国家统计局.普查员所使用的线上系统,需要完成数据采集.流转.脱敏.处 ...
- 我理解的金融级数据库
杨祥合 北京奥星贝斯金融行业解决方案架构师 & 北京金融科技产业联盟高级专家 最近,关于金融级数据库的话题,行业内讨论热烈.在这方面我想抛砖引玉,分享下自己的观点. 10多年来,我一直在分布式 ...
- tdsql完全兼容mysql吗_金融级数据库 TDSQL:已支持日 3.6亿+ 的交易量,TPS 10万+
原标题:金融级数据库 TDSQL:已支持日 3.6亿+ 的交易量,TPS 10万+ 作者: 胡盼盼:微众银行数据库平台负责人.硕士毕业于华中科技大学,毕业后加入腾讯,任高级工程师,从事分布式存储与云数 ...
最新文章
- 军团要塞2正版服务器,专用服务器配置 - Official TF2 Wiki | Official Team Fortress Wiki
- 倚天·屠龙——唯我独尊
- dp、sp和px的区别
- Python 中文注释报错解决方法
- Manacher 求最长回文子串算法
- uniapp的目录结构反思与整理 app.vue【base】pages.json【配置】main.json【框架入口文件】
- Ubuntu 18.04 LTS环境下 MNN 的编译与使用
- linux知识(二)互斥量、信号量和生产者消费者模型
- linux db2 归档,DB2的归档模式设置方法
- 吉士丁与新潮传媒达成亿级战略合作,打造国产奶酪新势力
- 一场价值4500亿的抉择
- CoreOS coreos-assembler文档
- 第一个servlet
- 布客·ApacheCN 翻译校对活动进度公告 2020.5
- python机器人仿真软件_最火的Python语言也能做机器人仿真,你会不?
- 作为程序员你应该会的软件
- 模拟电路实验 01 - | 基本共射放大电路
- imac起死回生,在iMAC 27 2011 mid 上裸机安装windows10
- 经典重写alert方法
- matlab安装c盘吗,matlab的安装步骤(附winC盘“用户”文件夹下账户名的更改方法).doc...
热门文章
- python construct 字符串_通过字符串变量在Python中设置和获取@property方法
- Java为啥不建议用通配符_为什么在Java导入语句中使用通配符不好?
- flume java_Flume的安装及简单的使用(一)
- linux shell 脚本 2,理解Linux Shell和基本的Shell脚本(2)
- ipad鼠标圆圈变成箭头_【附视频指南】iPad 只能刷剧?来看看我是如何把它武装成生产力工具的!...
- deepfm算法思维导图和代码
- 在有序旋转数组中找到最小值
- 判断一个点是否在三角形内部
- 开启大数据时代谷歌三篇论文-BigTable
- 论文笔记 Hierarchical Reinforcement Learning for Scarce Medical Resource Allocation