2022年4月27日,联通支付有限公司发布《国产数据库选型采购项目》招标公告,最高限价 100 万元。 项目概况:联通支付目前正在使用的数据库包含了国外商业数据库Oracle和开源数据库MySQL,采用了Active Standby方式双机房部署。同机房内Oracle采用RAC高可用架构,MySQL采用MGR高可用架构。基于联通集团及联通支付公司对自主知识产权的要求及规划,需要将国外商业数据库Oracle稳步迁移至国产化数据库平台。 功能与性能要求: (1)投标人需参加含功能和性能场景的选型测试,且选型测
技术选型是由技术方向和业务场景 trade-off 决定的,脱离业务场景来说技术选型是没有任何意义的,所以本文只是阐述了伴鱼技术团队数据库选型的过程,这并不是 MySQL、MongoDB 和 TiDB 之间直接的比较,只能说明 TiDB 更适合伴鱼的业务场景和技术规划,另外由于 TiDB 是非常新的数据库技术,所以这也能体现出伴鱼技术团队对新技术的态度、技术后发优势的理解、成本与效率的衡权和技术生态与红利的思考。
首先是运维成本,包括监控告警是否完善、是否有备份恢复机制、升级和迁移的成本是否高、社区是否稳定、是否方便调优、排障是否简易等;
对于很多程序员来说,公司选择什么样的数据库,基本不需要你来决定。当你加入一个公司的时候,公司的大部分技术选型已经确认,特别是数据库选型,因为数据库一旦选择,后期迁移的代价还是很大的。
我们做数据库选型的时候首先要问:需求是谁提出的,也就是说谁选型?是负责采购的同学、 DBA 还是业务研发?
今年国产数据库在国际舞台上大放异彩相信大家都有目共睹,更多国产数据库加入到数据库市场的队列,对于企业来说也就有了更多的选择。根据2019 DeveloperWeek上的数据库趋势调查,企业的数据库选型已趋向多元化,其中使用率最高的虽然是MySQL,但紧跟其后的MongoDB、PostgreSQL等占比也不容小觑。 从调查中还可以了解到,将近一半的受访者正在使用多数据库类型的组合,因此数据库的兼容性无疑也越来越受到企业的重视。 *以上调查结果来源自:https://scalegrid.io/blog
A云Polardb-x 1.0现已全面升级为Polardb-x 2.0,但Polardb-X 1.0有其自有特色,仍然有很多企业在使用Polardb-X 1.0方案。那么,当这些企业想将业务系统迁移至腾讯云时,该如何进行数据库选型?怎么样进行数据同步?其中又会涉及到哪些问题呢?
谁来决定数据库技术选型?从这篇数据中我们可以发现,在企业进行数据库技术选型中,不同角色的权重不同。调研结果揭示架构师>开发者>DBA>管理者,这与我之前认为的管理者、DBA为选型的主导者大相径庭。当然这篇调研报告,应是来自国外,跟国内的情况还是有些差异;但从中也可观察到在技术选型的某种趋势。
上文讲到,查询分离的方案存在三大不足,其中一个就是:当主数据量越来越大时,写操作会越来越缓慢。这个问题该如何解决呢?可以考虑分表分库。
最近,ChatGPT火爆全网,介绍其产品、公司、作者、技术和应用等方面信息,占据着整个互联网,似乎不谈GPT好像就落伍了。NineData 是多云数据管理平台(NineData-让每个人用好数据和云-玖章算术),致力于让每个人用好数据和云。作为数据库领域的技术创新团队,面对这么火ChatGPT,我们 NineData 是的工程师也针对ChatGPT,做了一些关于数据库领域的相关测试,测试结果,真的是智商狂飙。不管是从SQL编写、SQL优化、数据库选型、表设计、理论认识、行业认识都有比较高质量的回答。
随着互联网和移动互联网的发展,各个机构都需要支撑远超过以往的数据。而在这个需求的刺激下,IT领域出现了大量数据处理技术,其中之一就是NoSQL。灵活的数据类型,高效的处理能力,让NoSQL已占据数据管理系统的一席之地,比如人气NoSQL数据库MongoDB。然而在Wix工程实践中,他们发现,大量场景中其实并不需要NoSQL,反而成熟的RDBMS更具效益,比如MySQL。下面一起看Wix工程主管 Aviran Mordo的分享,由OneAPM工程师翻译。 以下为译文 开发人员选择NoSQL数据库一般都是根据主
昨天面试了一个MYSQL的DBA, 在面试的过程中有一个项目经营,某银行的MYSQL数据到MONGODB 的数据迁移. 我比较好奇,多问了两句
随着近些年来内外部形势的剧烈变化及企业自身发展诉求,国内企业愈发重视基础软件的自主可控。特别是对于某些涉及国计民生的重点行业,监管层面也提出了非常明确的指导意见,在指定时间内完成技术改造。作为核心技术软件之一,数据库在其中无疑扮演着重要的角色,且具有非常高的复杂性。一方面是作为基础软件之一,数据库自身复杂度就比较高;另一方面近些年数据库技术发展迅猛,以分布式、多模、HTAP为代表新型数据库架构不断涌现。这些都会带来较高的复杂度,同时我们也看到国内数据库发展活跃、厂商产品能力参差不齐,用户在选型、研发、迁移、使用上面临诸多痛点。特别是在整体改造的最后阶段,涉及将系统从原有技术栈迁移到新技术栈,这其中蕴含了较多工作及风险。本文尝试从信创改造角度出发,重点谈在改造中往往处于最后改造的数据库部分,即所谓信创改造“最后一公里”所面临的痛点问题及可能解决思路。
点击上方“芋道源码”,选择“设为星标” 管她前浪,还是后浪? 能浪的浪,才是好浪! 每天 10:33 更新文章,每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路,很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
一句话:能像关系型数据库如 Mysql 中使用 SQL 方式一样方便的实现 Elasticsearch 增、删、改、查(尤其是检索、聚合)等的操作。
用于产品业务相关数据存储,兼容mysql,支持弹性自动水平扩容(实际上是因为接手的时候,已经用了这种数据库)TDSQL for MySQL。
基于Netty开发系统处理前端用户请求,实际存储在Mysql中,为了支持扩展性,Mysql分为多个组,每个组有相应的主实例和从实例,当主实例挂掉后通过切换机制将从提升为主,以保证高可用。
2019 Gdevops全球敏捷运维峰会广州站:由上海市经信委指导、dbaplus社群主办的年度收官之站,汲全年之精华,取热点技术之核心,重点围绕智慧运维、DevOps、数据库领域,邀请来阿里、腾讯、京东、蚂蚁金服、新浪微博、甜橙金融、联通大数据、微众银行、贝壳找房、新炬网络、巨杉、爱可生、JFrog等名企技术大咖,11月他们将从全国各地汇聚至广州,一起展开年度技术总结与发展趋势展望。 2019 Gdevops广州站 ---- 时间:2019年11月15日 地点:广州阳光酒店 指导单位:上海
2018年启动的一个新项目,项目初期,作为探索项目,基于两点考虑,部分数据存储选用了mongo,理由如下
标题的这个问题是我去年面天猫,在交叉面的时候一个数据库出生的大佬问的:你会怎样去设计一个数据库。
“去O”,是近些年来一直很火的一个话题,随之也产生了各种疑惑,包括现有数据库评估、技术选型等。去O是项系统工程,需要做好充分的评估。本文通过自研工具,生成数据库画像,为去O评估提供一手数据,希望给大家带来借鉴。
本文是我在中生代技术群分享的话题《创业一年经历的技术风雨》中的第一部分《产品架构与技术选型》的第二部分。我要谈的是我们产品研发过程中的技术选型。 开发语言的选型 我们选择的语言是Scala。选择它的一个主因是因为Spark;另一个原因呢?或许是因为我确实不想再写Java代码了。 其实有时候我觉得语言的选型是没有什么道理的。除了特殊的应用场景,几乎所有的程序设计语言都能满足如今的软件开发需求。所以我悲哀地看到,语言的纷争成了宗教的纷争。 在我们团队,有熟悉Java的、有熟悉JavaScript包括NodeJ
Hello 我是Austin,目前在从事数据库架构与数据库管理方面的工作,目前也在维护一个公众号,进行数据库知识的分享和讨论。今天会和大家来分享数据库选型方面的一些个人看法。
一般情况下,会考虑到MySQL与MongoDB如何做技术选型的时候,你一定是遇到了类似于非结构化数据JSON的存取难题,否则大家都直接MySQL开始搞起了。
得物 App 从创立之初,关系型数据库一直使用的开源数据库产品 MySQL。和绝大部分互联网公司一样,随着业务高速增长、数据量逐步增多,单实例、单库、单表出现性能瓶颈和存储瓶颈。从选型和架构设计角度来看这很符合发展规律,一开始没必要引入过于复杂的架构导致资源成本和开发成本过高,而是逐步随着业务发展速度去迭代架构。为了应对这些问题,我们采取了诸多措施如单库按业务逻辑拆分成多个库的垂直拆分,分库分表的水平拆分、一主多从读写分离等。这些技改同时也使得整个业务层架构更加复杂,且无法做到透明的弹性,因此我们逐步把目光转向了已经趋于成熟的分布式关系型数据库 TiDB。
由于我们在开发的过程中难免会遇到数据库选型的问题,那么数据库的选型那我们必须通过结合我们的业务场景还有他们的设计初衷,及各自在各个方面的优势。现在我们就在业务开发中遇到了选择 mongoDB还时MYsql。之前没有怎么了解过mongoDB,那今天就开始我的mongoDB第一步。
而数据库作为软件系统的核心组成部分,尤其是面对当下很多基于微服务、容器化的服务层可以无限弹性扩展的云原生时代,了解不同数据库的基本原理和适用场景,对很多技术人来说避免瓶颈、解决瓶颈,从一开始就能选择好适合自己业务场景的数据库,都是很有帮助的。
很多公司在考虑去O的时候,经常面临这样的问题—"对自己的数据库不够了解",也不免有这样一些疑惑:
在互联网世界,变化与演进是业务架构永恒的主题。技术迭代、业务演变等多重因素,一再提升着系统架构设计的难度和复杂度,可以说,没有一种架构是永久适用的,要想让自己的业务具有快速响应、快速适应的能力,架构的设计往往起着决定性的作用。 于是,业务思维在业务架构设计中就显得举足轻重了。它不仅决定了技术架构的提前部署能力,很大程度上也影响业务迭代阶段的速度和稳定性。所谓架构先行,在企业业务为王的发展压力下,业务思维能很大程度上决定着业务的迭代和转型。 当信息技术发展到当下,拥有一套稳定的业务架构几乎是所有大型互联网公司
MYSQL 版本的一直在更新迭代,这是一个好事情,新的功能对老的问题进行修改补丁,但这需要一个过程,一个产品的核心是用户, 众多MYSQL 的用户到目前为止有几个进入到了MYSQL 8(我是进了踩了无数的坑,包括各种与开发的PK), 这里的说说MYSQL 8 的N 宗罪.
物联网云平台是一个连接设备和互联网的系统,通过传感器、设备和网络进行数据采集和传输,需要一个可靠和高效的存储系统来存储和管理大量的物联网数据。存储的意义在于提供数据的持久性和可访问性,使得数据可以在任意时间被查询、分析和应用。
陈某的知识星球开通了,一个相互交流的技术圈子,陈某会在星球中定期分享干货,如果你也想和球友一起打卡学习进阶,戳链接加入
InfoQ极客传媒旗下官方账号。面向数字化管理者、从业者、洞察者,提供数字化企业案例、政策解读、研究报告,做数字时代的「记录者」。
本次分享将结合多个大数据项目与产品研发的经验,探讨如何基于不同的需求场景搭建通用的大数据平台。内容涵盖数据采集、存储与分析处理等多方面的主流技术、架构决策与技术选型的经验教训。 大数据平台内容 数据源
前两天 GitHub 的博客上发布了一篇题为「Partitioning GitHub’s relational databases to handle scale」[1] 讲述他们如何拆分自己的数据库。相关内容在 Hacker News[2] 上也引起了大家的关注。
携程是一家中国领先的在线票务服务公司,从 1999 年创立至今,数据库系统历经三次替换。在移动互联网时代,面对云计算卷积而来的海量数据,携程通过新的数据库方案实现存储成本降低 85% 左右,性能提升数倍。本文讲述携程在历史库场景下,如何解决水平扩容、存储成本、导入性能等痛点,以及对于解决方案的制定和思考过程。
随着移动互联网的崛起,金融客户更广泛地使用电子货币和移动支付技术,金融消费习惯的改变使得金融服务更加注重方便、快捷和客户体验。生态圈金融、场景金融等新模式带来了业务场景和后台设计的变化,使得银行的基础架构和服务方式要做到与时俱进,应需而变。
◆ 分表分库 上文讲到,查询分离的方案存在三大不足,其中一个就是:当主数据量越来越大时,写操作会越来越缓慢。这个问题该如何解决呢?可以考虑分表分库。 这里先介绍一下真实的业务场景,而后依次介绍拆分存储时如何进行技术选型、分表分库的实现思路是什么,以及分表分库存在哪些不足。 接下来进入业务场景介绍。 ◆ 业务场景:亿级订单数据如何实现快速读写 这次项目的对象是电商系统。该系统中大数据量的实体有两个:用户和订单。每个实体涵盖的数据量见表3-1。 表3-1 数据量 某天,领导召集IT部门人员开会,说:“根据市场
之前写过一篇文章《数据库的使用你可能忽略了这些》,主要是从一些大家使用使用时容易忽略的地方,如:字段长度、表设计等来说明,这篇文章同样也是这样的主题,只是从另外的几个方面来说说数据库使用中,容易忽略,导致入坑的地方。
财富管理行业的数字化转型近些年主要面临着哪些环境因素的影响?整个过程存在哪些难点?对数据库的要求具体是什么?为什么要建设分布式数据体系?迁移之前做了哪些方面的准备?最终效果如何?作为国家首批五家基金投顾业务试点公司之一,中欧财富过去多年数字化转型的过程中对人才、技术、业务等做了哪些思考?本文,InfoQ 采访了中欧财富的技术总监伍春兰,试图寻求上述问题的答案。
当你提到数据库,就不得不提Oracle。整个数据库行业,谈论技术无出Oracle其右者,Oracle浸淫数据库领域多年,早已将这个行业吃透。几乎所有的数据库,不管是商用数据库还是开源数据库,都是照着Oracle模式在走,包括交易模型中的数据处理等层面更是如此。
在国内数字化转型以及信创建设持续推进的大背景下,众多厂商入局国内数据库市场,为企业提供了面向多种应用场景的数据库,以及相关的生态工具或服务。国内数据库市场因此迎来了诸多新的变化,新的产品类型、新的技术、新的服务,以及新的市场格局,而这些变化也让企业在选择数据库时需要考虑更多复杂的因素。
数据应用,是真正体现数仓价值的部分,包括且又不局限于 数据可视化、BI、OLAP、即席查询,实时大屏,用户画像,推荐系统,数据分析,数据挖掘,人脸识别,风控反欺诈等等。
1、我们一般把中间件跟MySQL高可用分开讨论,从您的分享话题来看,中间件指导高可用选型有什么特殊意义吗?
最近业务部门在选择新的AF 系统(具体不能说的太细,能明白AF在某个行业代表什么的估计能看的懂)。之前业务部门购买系统一直是平自己的喜好,功能满足,几百万就花出去。可惜的是功能是满足了,但性能满足不了,在整体的应用中,成为了一个瓶颈。业务部门吸取了相关的教训,在采购新的AF系统的情况下,将数据库方面作为一个考虑的对象,当然我自己也深知为什么,之前的两年一直在和老的AF系统的供应商PK 数据库方面的问题。
计费组是为网易互娱产品提供统一登录和支付高效解决方案的公共支持部门,对内是互娱的各个游戏工作室,对外是国内外数百个渠道。由于业务场景的特殊性,我们为各个游戏产品部署了不同的应用服务,其中大产品环境独立,小产品集中部署。
jeeplus 是一款基于代码生成器的快速开发平台。 前后端分离、maven多模块开发,方便多人协同开发 后端选型:springboot2 + mybatis + shiro + jwt token + flowable 前端选型:vue + element-ui + es6 + webpack 代码生成器支持连接不同的数据库,生成的模块可以连接指定的数据库,支持自定义模板,可以无限扩展,生成各种复杂的代码 一套代码支持mysql, oracel, postgresql,sqlserver数据库 html5
如果你真的要做微服务,那你一定逃不掉这个阶段。(如果你连这个都没到,那就别瞎想了哈)
Mysql 作为互联网中非常热门的数据库,其底层的存储引擎和数据检索引擎的设计非常重要,尤其是 Mysql 数据的存储形式以及索引的设计,决定了 Mysql 整体的数据检索性能。
大家好,我是陆金所数据库团队的负责人王英杰。这次的分享主要集中在陆金所去O在线换库的技术特点上,之后详细给大家剖析陆金所设计的在线换库方案以及方案如何在一个庞大的金融系统里通过多个团队的紧密配合稳妥落地。
领取专属 10元无门槛券
手把手带您无忧上云