一个系统在设计之初,是不是需要考虑未来几年内的数据量,并发量,故障中的恢复的时间,(故障恢复的便捷性), 系统架构层是不是的考虑,架构是不是能进行解耦, 应用系统的冗余,和数据库方面的高可用的冗余, 在什么状态下的...的平衡性, 因为在数据库系统中,你在怎么备份,遇到CRASH 的情况,都不能保证能百分之百的恢复数据....一些高优先级的应用程序只能宕机几秒钟,要不......
RTO
恢复时间目标是一个指标,它帮助计算在发生灾难后恢复应用程序(App +数据库)和服务以维持业务连续性所需的速度。...自然是没有
2 任何系统都有可能CRASH在CRASH 的时候,操作的日志记录信息,可能是你能恢复数据的一个救命稻草,但你将他放到业务系统的数据库中, 试问是何道理, 是要一损俱损, 这样的应用一定要进行解耦...,----不解耦数据的安全方面方面是一种问题,不知道这样设计的架构师,考虑没有考虑这样的问题.
3 数据的查询和数量之间的关系,自然操作日志的数据,大部分是不规则的,并且量也是比较大的,查询数据的时候却要定位准确