首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

走好信创落地“最后一公里”

随着近些年来内外部形势的剧烈变化及企业自身发展诉求,国内企业愈发重视基础软件的自主可控。特别是对于某些涉及国计民生的重点行业,监管层面也提出了非常明确的指导意见,在指定时间内完成技术改造。作为核心技术软件之一,数据库在其中无疑扮演着重要的角色,且具有非常高的复杂性。一方面是作为基础软件之一,数据库自身复杂度就比较高;另一方面近些年数据库技术发展迅猛,以分布式、多模、HTAP为代表新型数据库架构不断涌现。这些都会带来较高的复杂度,同时我们也看到国内数据库发展活跃、厂商产品能力参差不齐,用户在选型、研发、迁移、使用上面临诸多痛点。特别是在整体改造的最后阶段,涉及将系统从原有技术栈迁移到新技术栈,这其中蕴含了较多工作及风险。本文尝试从信创改造角度出发,重点谈在改造中往往处于最后改造的数据库部分,即所谓信创改造“最后一公里”所面临的痛点问题及可能解决思路。

04

如何构建企业内的 TiDB 自运维体系

得物 App 从创立之初,关系型数据库一直使用的开源数据库产品 MySQL。和绝大部分互联网公司一样,随着业务高速增长、数据量逐步增多,单实例、单库、单表出现性能瓶颈和存储瓶颈。从选型和架构设计角度来看这很符合发展规律,一开始没必要引入过于复杂的架构导致资源成本和开发成本过高,而是逐步随着业务发展速度去迭代架构。为了应对这些问题,我们采取了诸多措施如单库按业务逻辑拆分成多个库的垂直拆分,分库分表的水平拆分、一主多从读写分离等。这些技改同时也使得整个业务层架构更加复杂,且无法做到透明的弹性,因此我们逐步把目光转向了已经趋于成熟的分布式关系型数据库 TiDB。

03

小红书微服务框架及治理等云原生业务架构演进案例

在互联网世界,变化与演进是业务架构永恒的主题。技术迭代、业务演变等多重因素,一再提升着系统架构设计的难度和复杂度,可以说,没有一种架构是永久适用的,要想让自己的业务具有快速响应、快速适应的能力,架构的设计往往起着决定性的作用。 于是,业务思维在业务架构设计中就显得举足轻重了。它不仅决定了技术架构的提前部署能力,很大程度上也影响业务迭代阶段的速度和稳定性。所谓架构先行,在企业业务为王的发展压力下,业务思维能很大程度上决定着业务的迭代和转型。 当信息技术发展到当下,拥有一套稳定的业务架构几乎是所有大型互联网公司

01

一文搞定MySQL的分区技术、NoSQL、NewSQL、基于MySQL的分表分库

◆ 分表分库 上文讲到,查询分离的方案存在三大不足,其中一个就是:当主数据量越来越大时,写操作会越来越缓慢。这个问题该如何解决呢?可以考虑分表分库。 这里先介绍一下真实的业务场景,而后依次介绍拆分存储时如何进行技术选型、分表分库的实现思路是什么,以及分表分库存在哪些不足。 接下来进入业务场景介绍。 ◆ 业务场景:亿级订单数据如何实现快速读写 这次项目的对象是电商系统。该系统中大数据量的实体有两个:用户和订单。每个实体涵盖的数据量见表3-1。 表3-1 数据量 某天,领导召集IT部门人员开会,说:“根据市场

02
领券