SaaS数据模型的设计.docVIP

SaaS数据模型的设计 　　SaaS数据模型设计有三种基本方案。考虑到技术和商业的因素。三种方案各有优劣。 　　SaaS系统的数据模型设计是一个复杂的工作，它不仅要考虑到技术因素，同时也必须将商业因素纳入考虑范围之中。 　　 　　SaaS系统常见数据模型独立数据库 　　 　　将每个客户的数据单独存放在一个独立数据库是实现数据隔离的一种最为简便的解决方案。 　　在应用这种数据模型的SaaS系统中，大部分系统资源和应用代码还是由所有的客户所共享使用，但物理上每个客户有自己的一整套数据，而且单独存放。系统将借由元数据(Metadata)来记录哪一个数据库属于哪一个特定客户，与此同时也可以部署一定的数据库访问策略来确保即使系统处于异常状况下，客户数据也不会被其它客户意外访问到。 　　 　　显而易见的是，一旦每个客户拥有其独立数据库，那他将可以轻易对其做个性化的修改来符合实际业务需求，而且如果系统出现异常情况需要将历史备份数据重新恢复的话，也将是一项轻而易举的工作。 　　但是，这种数据模型的最大问题是对应的部署和维护成本非常高，硬件资源的消耗将明显高于其它两种方案，一台服务器将只能支持有限数量的客户。 　　 　　共享数据库单独模式 　　 　　第二种方式则是所有客户使用同一数据库，但各自拥有一套不同的数据表组合存在于其单独的模式之内。 　　这种客户独立模式的方式相对比较容易实现，而且从数据扩展性而言，这种解决方案和独立数据库一样，客户可以相对自由地对其中的数据结构进行新增和修改。 　　这种客户独立模式的方式在数据共享和隔离之间获得了一定的平衡，它既借由数据库共享使得一台服务器就可以支持更多的客户，又在物理上实现了一定程度的数据隔离以确保数据安全。 　　但这种解决方案的一个不利之处就是当系统出现异常情况需要将历史备份数据重新恢复的话，流程将变得相对复杂。因为如果每个客户拥有独立数据库的话，那么只需恢复该客户最近的数据库备份即可。但在单独模式下，如果简单的恢复数据库备份，那就意味着数据库内所有客户的数据将一同被恢复，无论该客户是否数据受损或需要做数据恢复与否。 　　 　　因此，在独立模式下，如果系统管理员希望恢复某个特定客户的数据，需要将数据库的备份解压到某临时服务器空间内，然后选定特定客户的表数据将其覆盖到系统主数据库内，一般来说，这将是一项非常复杂且耗时的工作。 　　这种客户独立模式的方式比较适合应用在每个客户拥有比较少的表数量的情况下，比如每个客户只有100张表或更少。这种方式毫无疑问可以在每台服务器上支持比独立数据库方式更多的客户数量，减低了服务供应商的运营成本。 　　 　　共享数据库共享模式 　　 　　第三种方式是用一个数据库和一套数据表来存放所有客户的数据。在这种模式下一个数据表内可以包含了多个客户的记录，由一个客户ID字段来确认哪条记录是属于哪个客户的。 　　在所有这三种数据模型中，这种共享模式的方式具有最低的硬件成本和维护成本，而且每台服务器可以支持最大数量的客户。但是由于所有客户使用同一套数据表，因此可能需要在保证数据安全性上花费更多额外的开发成本，以确保一个客户永远不会因系统异常而访问到其它客户的数据。 　　在这种共享模式下，恢复备份数据的流程类似上文提到的共享数据库但独立模式的方式，系统管理员解压备份数据至临时服务器空，间，选定需要恢复的数据表，而且还需要额外的选定所需要恢复的客户记录，再导入到系统主数据库内。如果此时有大量记录需要导人，则系统的数据库服务的性能将受到很大影响，而且所有正在使用系统的客户也将受到影响。 　　 　　开发商的抉择 　　 　　上述三种SaaS系统的数据模型各有其利弊，因此在为特定的SaaS应用选择适合的数据模型时，必须考虑到下列因素。 　　 　　成本因素 　　基于数据共享设计的SaaS系统要求较高的开发成本(因为基于数据共享的系统架构相对比较复杂)，因此初始投入较大，但长期来看运营维护成本则相对较少。 　　而基于数据隔离设计的SaaS系统则由于所需要硬件会随着支持客户数的上升而快速上升，因此相对初始投入尚可，但长期来看会有一个比较高的运营维护成本。 　　总体而言，选择数据共享的方式从长远角度可以为SaaS服务供应商节省大量的金钱。但远在其最终开始盈利之前，该类系统在开发中就已经需要大量的初期投入。如果无法投入所需的开发资源，或者由于商业原因需要将所开发的SaaS系统尽可能快地投放到市场，则选择数据隔离的设计模式更为恰当。 　　 　　安全因素 　　通常在SaaS系统中会存放有很多敏感的客户业务数据，因此客户会对确保数据的安全性有很高的期望，SaaS服务供应商与客户签署的服务条款中会需要包含很多数据安全保障条款。当然，一般