国产数据库最有希望冲出重围的会有哪几家？GaussDB，OceanBase，TiDB，还会有哪些呢？
拼写错误 只说分布式数据库，原来替换O记的四大国产数据库很多年了，在传统的业务系统做得很好，暂且不表（人大金仓，南大通用，武汉达梦，神舟通用）。[*]华为的GaussDB，基于PG 9.2改造（可以选择不同数据库兼容模式，默认O）。在银行核心领域目前主要case是中国邮政储蓄银行核心系统、民生银行业务系统。
[*]阿里的OceanBase 完全自研，PolarDB 基于MySQL。OB用于交通银行信用卡核心，南京银行、西安银行、红塔银行、富滇银行、网商银行等核心业务。
[*]腾讯的TDSQL，基于MySQL。（主流为MySQL版本，TD有不同底层的适配版）主要案例为中国银行分布式新核心、张家港银行、微众银行。
[*]TiDB 完全自研，兼容MySQL，主要案例是北京银行信贷系统、在建的杭州银行核心系统。
[*]中兴GoldenDB，基于MySQL。主要案例是中信银行核心系统。
从整体来看，三条技术路线：完成从头自主研发的，基于MySQL，基于PG的三条路线，都有很大机会。上述的五家数据库，在金融特别是银行核心业务领域站稳脚跟以后，将会在全行业的IT基础设施国产化，数字化转型进程中大有作为。
========== 相关推荐阅读 ======
千亿数据的潘多拉魔盒：从分库分表到分布式数据库: 约1.8万字，讲述数据库以及数据中间件技术发展的历史和趋势，面对业务数据量飞速膨胀下所需要解决的问题等。
YY银行数据库选型方案，共计2.4万字。
kimmking：银行数据库选型：1-银行数据库选型要点kimmking：银行数据库选型：2-银行常用数据库介绍kimmking：银行数据库选型：3-同业数据库选型案例kimmking：银行数据库选型：4-YY银行数据库选型建议更多信息下载和阅读，参考： AP，看好 StarRocks
TP，看好 OceanBase
HATP，看好 TiDB
Vector DB，看好 Milvus 冲出什么重围？
在国内称王吗？国内市场，不取决于技术，地球人都知道。
有个易鲸捷数据库，由贵州布政使级的人物出面，把这个数据库成功打造为风头无两的数据库。还拿到了国家级的投资（好像只拿了部分，后来因为丑闻被爆出，投资停止）。这个数据库是个啥，可以去了解下。
冲出国内的重围，就看哪个数据库后面的人更高级了。你有布政使，我有巡按，他更不得了，是总督大人，那么，最终的胜利者，一定是总督数据库。要是半路上又杀出一个中堂大人当后台的数据库，那中堂数据库一定最后胜出。
如果 冲出重围，是冲出国内的圈子，到世界舞台上和Oracle等正面交锋，是凭数据库能出口创汇，这个不用我说，地球人都知道，目前没可能。（啥时候美帝要制裁国产数据库了，那就是有可能了，现在美帝看国产数据库估计和看小孩子过家家没啥区别）
------------------------------------------------------------------------------------
再补充一点，国产数据库热潮，开始自2018、2019，就是特郎普开始打击我们、国家提出自主可控的时候。
然后，短时间内，国产数据库从几家，发展到三、四百家。（有些小公司，没被统计进去，全部算进去，估计有400家左右）
国家这几年给政策、给资金，替换国外数据库，只是第一步。第二步一定是要求国内厂商出海，去挣外汇。毕竟出口、基建、地产是国家的支柱吗（有可能支柱不是这三个，不过出口依然很重要，这一点不展开讨论）。
阿里、华为、达梦……，一众厂商也在响应国家政策，出海作战。等个一、两年再看吧。哪家国产数据库在国际舞台上打出名气、打出威风，他就是最后的胜出者。如果被团灭，这波国产化闹剧也就渐近尾声了。
http://pic1.zhimg.com/50/v2-257868756d5f2da86af6c36a2e1dfc71_720w.jpg?source=1940ef5c
http://pica.zhimg.com/v2-e28d52fe82e4444d488897d5dd9467a3_r.jpg?source=1940ef5c
近一、两年，关注有无某国产数据库在国际舞台上大展拳脚的新闻。如，华为数据库在拉美市场击败Oracle、IBM、SQLServer，或成最大赢家。
阿里数据库成酋长最爱、成继东风daodang之后，又一最“硬”国货。
如果一直没有这样的新闻，那就是被团灭了，这波国产化闹剧也就渐近尾声了。 大厂三四款数据库最有希望。 都不看好
ob ti用来解决TP横向拓展方法不是工业方案 更像是学术探索 由此兼顾的hatp思路也不是惯例
tp横向拓展一直没有太好的思路 就是高速互联群集+分区表 剩下只能沿着业务轴拆分做分库 虽然在kv上面抽象理论拓展无上限 但热点问题永远会存在 单节点瓶颈最终还是会回到低延迟高速互联群集上 这就是50年前的东西了
说实话多数数据库做好俩工作 冷数据及时从实时库移出归档 新业务表结构独立设计以便后期拆分 99%的公司用不着分区表 稍微看看数据库厂商的建议都知道分区表是确实没办法的时候榨干最后性能的方式 不是当成常规手段使得
hatp工程上比较出色的两种思路 hana的内存并发列持久 mssql的列索引行持久
lsm最大优势仅理想情况可不降速读并高速写 说实话文件数据库或者nosql用完全可以理解 这两类产品压根没指望数据库堪多大用 不挂就行
但业务级数据库要很能抗 传统工程也为数据库插入性能做了很多努力 最基本内存页+日志写成功即为成功插入 是内存插入慢还是磁盘顺序写入慢？其次update是各类信息系统惯用场景 同样也是很基本 内存+temp+日志写入即成功 至于索引更新啥的内存先做了磁盘上再慢慢改呗 lsm优势在哪？b+树其实没啥问题哪怕内存数据库用性能也很出色 毕竟内存顺序读写一样也是比随机读写快出好几倍 学术快和工程上快是两码事
什么性能神话 成功案例都是扯淡 当年IOM三家都玩过 db2做银行清算 o上中情局 m抢交易所 好东西大家会抢着用 尤其是各种底层开发 哪怕弄个破解版也要用 因为做出来客户是真的买单 国内erp跑着多少没激活的mssql和Oracle 10年前n手小型机是多少公司的香饽饽
ob ti最大问题是技术战略有问题 产品力也起不来
gauss pg工程质量很不错的 但问题是pg短板是配套 pg就像是一套NB引擎和车架 车轮什么的凑合凑合就行了 方向盘风挡什么的开源有个用的就行了 gauss就是一家出色的装配商 搞出来的东西看着不像开源那么简陋 但也就这样 指望拉出去干架还差很远 对于gauss至少先把pg那一票零零总总的小厂扫平或者收编再说怎么和主分支掰腕子 等压制了pg影响 在找个hana那种的基本盘之后 才能和IOM干架
也别杠什么学院派 苹果给bsd写了多少代码了 bsd向gnu妥协了多少 产品拳头硬管你什么开源闭源名校大牛全都靠边罚站 iom当年就是这么杀出来的
当然gauss技术战略上没有犯错 但估计也没心思搅局 反倒是达梦 金仓什么的应该会受到很大冲击
一个是瞄准国产蛋糕搞内斗的
一个是畸形企业孕育的畸形产品
一个是觉得自己行但是好像没那么行
综上没有能打的
Q:这种shared nothing+2pc和学术探索有什么关系呢，不是挺工程的东西吗[思考]而且mssql也是内存索引+列存存储吧。
A:share nothing一开始是处理ap负载 后来发现类似flink那种结构处理tp也不错 但sharenothing的线性增长是有前提的 要么弱一致 要么不跨节点修改 要么mvcc+occ等 但你看这种系统执行方式 查询优化引擎生成少io的查询计划 然后事务处理引擎读取相应的页根据条件加锁和查询计划在某个节点内存中执行 执行结果写到本地tmpdb 通知各个节点标记脏数据 结果回写存储引擎回收锁
从物理结构上 最小数据搬运机制是提前确定io范围 优先选择io数据最密集的节点进行事务处理 请考虑1.如果单节点查询优化引擎无法一次性获取足够索引 需要远程内存访问或硬盘读取2.如果事务处理节点没有足够内存可能涉及到异地安置 为了减少这两点额外开销是不是各节点间更加紧密会提高性能 其次是不是可以引入logserver保持强一致且高速写入 这就是sql server超大规模的思路 如果我们把这个东西安置在16节点互联群集上 这就是rac或者always-on db2底层在z系列上也是类似
换句话说要么保证单次交易处理不超过节点上限 要么通过减少网络开销来减少数据往返延迟 前者对于谷歌是可以做到的 因为大多数都是孤立查询 而且索引的内存占用相对可预估 但企业信息系统要复杂的多 一味强调小事务会给上层开发造成不小的麻烦 而且企业信息系统可能兼具多种索引 要是涉及hatp的时候仅索引内存压力就不小 换句话说sharenothing是理想情况横向拓展 sharedisk是减轻并发副作用横向拓展的特例 可随着多年的发展sharedisk可以轻松模拟成单节点对外服务 多个sharedisk可以组成更大的sharenothing
而且为了减少sharenothing时并发副作用 可以手动划定节点 让同一业务领域的数据集中在某个节点上从而避免大部分OLTP负载的跨节点访问 也就是所谓沿业务轴拆分 也就是说sharenothing架构必须了解数据数据内容才能进行适当的分布调整 如果数据库框架这样做性能开销极大且数据合规性很难满足
到工程层面sharedisk已经40年历史了 sharenothing大规模使用也就10来年 mvcc大规模使用也没几年 很难讲sharenothing是一种成熟可靠的工程实践 再结合sharenothing本身的局限就更加属于错误的技术战略 然后你提到mssql的列存的问题 实际上有两种 聚集列索引是列存 非聚集列索引是行存+列索引前者适合olap也就是实例级别的hatp 后者适合OLTP实时分析也就是库表级hatp
页:
[1]