java+数据模型策略_java – 版本控制数据库的正确策略

首先,DB升级是邪恶的,但是

blog描述了一个完全的恶梦.

可以根据升级方法创建一个程序员能力矩阵：

> 0级：没有升级.客户非常害怕,并使用应用程序或第三方数据库管理解决方案提供的UI手动移动数据(相信我,这是真的可能).

>级别1：有一个脚本来升级数据库转储.客户感到安全,但他们会在未来1-2年内解决微小和非常刺激的问题.系统正在工作,但不允许更改.

> 2级：表改变.特别是在升级过程中出现问题时,会出现异常停机.巨大的问题,几乎没有保证获得100％的安全性.数据转换由错误脚本管理.客户不高兴

> 3级：无架构设计：一小时停机时间可让错误脚本翻译DB中的配置(在许多情况下,此步骤可能会损坏数据库).支持者们全部咖啡储备完全耗尽.

> 4级：懒惰透明升级：零停机,但还有一些问题是可能的.客户几乎快乐,但还记得以前的经验.

> 5级：理想的架构,不需要明确的升级.总幸福客户不知道升级程序是什么.开发人员富有成效和平静.

我将介绍所有的技术问题,但在此之前,我可以说明以下内容(请原谅我相当长的答案)：

>当今的开发周期非常压缩,数据库很大

>几乎任何功能可能会引入方案更改和中断兼容性,以便我们有一个简单和稳定的升级过程,或者我们可能推迟功能

>客户可能会发现一个问题,所以有机会通过一些需要的升级步骤来进行紧急修复

>一般来说,避免您和客户之间的任何障碍好得多

0级和1级

这两种情况都是明显的,愚蠢的.任何人都应该避免这种情况.

2级

改变对于小桌子来说不是那么糟糕,但是对于大桌子来说可能是一个问题.在真正的大桌子(> 1Gb)上,ALTER TABLE可能需要几个小时甚至几天才能完成.此外,它只解决了模式升级问题,但是存储数据呢？我还建议考虑物理数据布局,以了解这种方法背后的实际障碍.整个过程可能不安全,因此请确保您有备份.

解决方案：

3级

通过将模式移动到更高层来解决模式升级的问题.无模式解决方案有限,主要是因为它禁用了关系模型背后的全部功能.可以提出一种混合方法来具有快速升级和使用关系代数的能力.有一些有趣的文章：

请注意,升级程序的复杂性仍然存在,它只是移动到应用程序级别.有很多相关的场景,但是我将会描述一段时间以来一直在使用的混合系统.我可以将数据模型描述为“具有关系的实体”.实体之间的关系在DB级别表示,实体本身存储为XML blob.

这个系统是成熟的,有足够的客户.有很多功能要求,所以研发和质量保证小组有点强调.最初升级过程是作为独立的Java应用程序实现的,它从DB中读取XML blob,并使用DOM API进行升级并将其写回数据库.实际的做法看起来很简单,但背后有几个隐藏的问题：

>升级逻辑可能有点错误,所以有机会写出错误的XML数据,显着增加了客户的停机时间

>可能需要一些时间才能读取 – 转换1-2GB的XML

>所有的升级程序步骤都应该包含在自动测试中(我会说CI是必须的)

>可能会在一两天内发现隐藏的毛刺,因此,由于插入了新的数据,所以备份没有任何帮助

>升级代码可能会变得有点凌乱,特别是如果你想/需要升级之间的构建(任何敏捷团队的正常要求)

我试图通过使用更严格的升级程序定义,验证规则和CI系统针对现实生活中的数据(在所有客户中收集)进行的广泛测试来减轻所有潜在风险.我很惊讶地看到一些步骤失败,因为旧的问题很久以前由旧的升级脚本引入.为了解决隐藏的问题,开发了单独的升级步骤.还进行了一些优化,将升级时间缩短到合理的20-30分钟.基于控制台的进度条执行其余.

快速注意：任何最终用户都渴望看到任何长时间运行(> 2分钟)操作的进度.请不要忘记实行这样的“快乐”.

最初DB版本存储在单独的表中.请不要使用这种方法,因为实体更新版本更好,并且在升级过程中避免整个数据库锁定.

将显示一个升级过程作为示例(所有验证和验证步骤都隐藏在< build />和< version />处理逻辑之后). ‘ – ‘意味着更少,’*’ – 任何构建

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

每个脚本都是一个小的Java或Groovy实现(也使用XSLT).

后来又开发了一个降级程序,但这是完全不同的故事.

4级

应用层上的数据方案允许做很多有趣的事情.例如,可以用protobuf替换XML.像往常一样,有几个原因(它更简单,更快等).如果你不喜欢建筑师的概念,可以使用thrift.

无论如何,protobuf允许创建一个向后兼容的系统(在存储的数据方面)几乎没有头痛.好的优点,顺便说一句.使您的系统向后兼容,您可以轻松实现延迟和完全透明的升级.它可以是后台进程或根据请求进行升级等.好消息是零停机,快乐的用户和更频繁地进行升级的能力.这意味着您可以快速开发,及时响应客户的要求,以其他方式更成功.

5级

对不起,不是这个时候.请注意升级策略.它是qutie容易卖一个系统与一些模式定义和锁定你自己.没有新功能 – 没有客户.

简单但非常实用的清单：

>您能否及时解决客户端的问题？

>客户升级系统是安全的(至少至关重要的是什么)？

>需要多少时间来识别问题？

>是否有自动验证？

谢谢你的阅读.