这个问题从两个方面去看: 1. 技术层面,选择TOP 5的厂商,他们规模大、资金足、人员多,组织架构相对稳定,就算对接你们的技术人员跑路,也能快速的补充,能不选小众数据库就不选小众。另外产品使用广,其实践案例多,问题库相对大也
1. 国产数据库肯定能全面替换Oracle,再困难刀架在你脖子上你也必须得替换。 2. 国产分布式数据库一定不能全面替换,分布式架构的数据离散,分布式事务等特性带来的使用问题只能得到优化,不能得到彻底解决的。只有在部分场
看大家也比较活跃....我再认真的重新写一下: 1.同业案例 确切的来说是同等规模银行相同业务系统的数据库案例,像核心系统的数据库选型,最好能多走访几家银行,坐下来聊聊技术,有些东西线下能说,网上可不能写。 另
国内厂商很多,市场份额最大的应该是迪思杰,另外英方软件,九桥软件也都有。当然不限于这些厂家,日志抓取技术也算是相对成熟的技术和市场了
华为从2021年以后全线存储都应该都符合信创了,他们存储在各个银行的生产环境使用案例还是比较多的。 当然,你要做好信创产品同样性能配置比如IBM贵不少的准备
首先,要明确该技术选型的侧重点,是仅仅作为影像内容管理平台的存储选型,还是所有非结构化资源存储池的选型,明确这个侧重点非常重要。下面我大概说下自己的想法: 如同你描述的几个考虑维度,当侧重点不同的时候,这几个维度的
galaxy.ansible.com 去看看吧,非常多的案例可以下载,什么ansible部署oracle,部署mysql、ngnix之类的
我认为,是否建立中台,需求是其次,最重要的是数据治理工作是否已完成。 如果数据治理已经较为成熟的实施了,那么,数据中台只是一个自然而然的事情,因为你有了标准化的数据,自然会去想到如何应用。而如果数据治理工作不到位,那
我大概划了一下重点:核心系统;中小型银行。 1. 业务以大量OLTP+少量OLAP为主,那么根据这个业务模型来看,所对应的IO特点应该为: 1)需要一定的IO吞吐量保证OLAP的效率; 2)对IO延迟非常敏感; 3)IO chunk(IO block)相对较小,IOPS相
基本上大部分你想要的监控都可以做到,无非就是多写几个模版,多写几个脚本,多写几个触发器。 PC层面:数据库服务器CPU、内存、网络流量等,alert日志、ASM、GRID日志这类日志; 通过脚本执行SQL:像数据库表空间、锁、会话、阻塞
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30