1 、制定规范和标准,降低运维风险运维规章制度,如运维操作流程、应急处置规范和预案、完善的变更与回退流程等等,保障各项运维工作有条不紊开展。例如把升级、上线、备份、迁数等工作整理成标准模板文档,形成运维资产随时
第一步调研:市场调研产品调研,包括需求初应答、产品应用案例等同业调研,技术交流第二步测试:POC测试方案;测试产品关键功能点;可移植性测试。第三步综合选型采购:综合考虑技术测试结果、非技术因素,采购产品。
基本从数据库的功能、性能、可用性、可扩展性、兼容性等维度考虑,技术测试时考虑的点有下面这些: 功能、扩展性、兼容性,包括: SQL 语法 数据类型 数据库对象 多版本控制 锁和事务 动态伸缩 数据备份恢复数据复制
业务类型:线上交易or传统交易?业务特性:有无周期性?交易量:平稳or波动?成本:传统数据库优化成本,xc成本架构:为业务服务,业务系统分布式架构?技术发展:行内技术发展水平、支持度?
选型参与方内部:运维+开发+业务,选择测试主体,共同决策运维:高可用方案、存储方案、灾备方案、安全、监控、运维等。开发:数据库功能支持、代码改造量、可移植性。业务:系统移植对业务的影响评估。 外部:厂商+同业厂商:产品
(1)银行传统数据库在应对互联网金融场景时遇到了明显瓶颈,在面临交易复杂度和交易频率的大幅提升时,传统数据库能够采取的优化方案非常有限,若仅依靠软硬件升级来提升性能的话,成本非常昂贵。(2)另外,在应对双十一这类特殊交易
要考虑很多因素。包括技术因素,非技术因素。技术因素。基本从数据库的性能、可用性、可靠性、可扩展性、兼容性等维度考虑。非技术因素,包括业务、交易量、成本、架构、技术发展等因素。
分布式数据库的高可用依赖一致性协议+多副本机制。 故障发生后主从副本的切换,这部分工作可以由集群根据一致性协议自动选举leader后实现,无需进行人工干预,完全自动进行;当然,也可以手工进行切换。整个过程业务无感知,切换
从实践的角度总结几点建议,供参考: 1.传统稳态类系统都已经在集中式数据库上跑了很多年,进行分布式改造是件非常谨慎的事情。 如果要提高性能和可用性,可以采用业务拆分的方式,将业务分布在不同的应用节点上,每个应用节点
提供一个我司的选型思路供参考。首先,结合业务去考虑数据库选型。比如评估下业务代码中数据库语句类型和占比有哪些,有没有用到一些特殊的功能如存储过程。结合这些代码去测试数据库,评估下对业务代码的兼容性有多大,需要
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30