完善的ERP数据库：NOSQL的崛起

全球金融危机之后的后恐慌时代，带来的是更多谨慎与精细。刹那间，事无巨细一切都需要控制，原因之一就是“见贤思齐”之后，仿佛大彻大悟，每个业务的每个流程的每个节点似乎都暗藏着闪闪金沙。当把流程梳理、业务优化、管理提升、素质训练与流行的SOA\SaaS\ERP\EAM等等组合起来之后，管理的标准、制度，需要撰写的报告、统计、分析、汇总等等空前爆炸，丝毫不逊于信息爆炸。雪片一样飞舞的文档希望能够造就一批格式化且僵化的“克隆战士”。

之所以如此，原因之一在于大干快上的信息化建设，或者说是ERP建设，往往关注核心业务更多一些。这些核心数据被写进著名的缓慢而昂贵的关系型数据库中，而这些关系型数据库所能提供的如事务一致性、写实时性和读实时性、复杂的SQL查询，特别是多表关联查询等重要特征，解决的只是如上所述的格式化数据，也就是业务事件的记录。最多也不过是通过字典表赋予数据意义的“高级”记录，展现出来即为信息。

然而，这并不是ERP的精神实质。换句话说，这是一种偏执的爱好，甚至是惧怕混乱的爱好。几乎100%的ERP解决方案都是基于关系型数据库来存储、查询、增、删、改业务记录，在B/S模式垄断了整个桌面的时代里，管理人员和决策者所能得到的，仅仅是系统提供的格式化的机械式的冰冷数据，其价值仅仅在于将数据的意义固化进每一个应用系统，让它们看上去提供了信息，告诉盯着屏幕的那双眼睛，“哦，业务就是这样”。

在OA已经被企业广泛应用于公文收发之后，文档管理、知识管理开始进入议事日程。最初的动机很简单，解决文档的保存、共享、交流、查询、下载及权限管理，其本质理念是认为每名员工在工作中生成的每一个电子文档都是企业的资源。然而这个资源并没有被纳入到ERP中，所谓的企业资源管理中。即便是集成文档管理(Integrated Document Management，IDM)所基于的也不过对上传到FTP服务器上的数据，套上若干TAG，实现将分散的文档管理起来-安全保护-文档的生命周期（文档创建、多人编辑、版本控制、审批流程、存储、搜索及重新使用）-知识管理。但是，这样的结果仍然不理想。因为那些文档就像被关进笼子里囚犯，受到权限、角色、密码、签名、审批等等层层限制，一种“被共享”的文档，虽然能够提供解决某方面问题的技能，但无法让每一个员工自己的知识以一种表现形式转化而为整个公司所用，也不可能建立起一个让企业家们津津乐道的具有自我学习能力的学习型组织。

所以，关系型数据库（包括实时数据库）解决了数据（Data 描述事实的记录）、信息（Information有意义的数据）问题，ERP的应用系统（包括DCS、FCS、ECM等等）解决了智能（Intelligence对信息格式化理解并进行逻辑化推理，输出执行或者决策的依据）问题。而目前的公司内部基于web1.0的网站，辅之以企业应用文档管理（IDM）或者知识管理(KM)也不过像公司内部的超级电子字典，仅仅解决了Q&A的知识（Knowledge）问题。

而今，像门户Portal、Wiki百科、Blog、Twitter微博客、Facebook类SNS、Dotwide即时通讯等这些新技术带给ERP新的希望。能够实时生成动态页面和提供动态信息的这些Web2.0技术，对数据库并发读写有很高的需求，同时对海量数据的高效率存储和访问的需求，尤其在集中式管理日渐风行的今天，面对下属更多分公司、子公司，几何级数增长的业务数据、文档，面对集团疆域的飞速拓展，更多的员工，更高的信息化要求，自然而然会对数据库提出高可扩展性和高可用性需求。然而“在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。”（Robbin 2009年11月25日）。

在 2009 年初NoSQL作为非关系型数据存储的广义定义得到了广泛认同。它打破了长久以来关系型数据库与 ACID 理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势，以满足数据存储在横向伸缩性上应用体系结构的需要。如Google 的 BigTable 、 Amazon 的 Dynamo 、Facebook的 Cassandra、Apache的HBase，NoSQL 实现也得到了广泛认同。此外还有Redis，Tokyo Cabinet， Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB，等等。这些NoSQL数据库根据不同的用途和环境大致可以分为以下的三类：

满足极高读写性能需求的Kye-Value数据库：Redis，Tokyo Cabinet， Flare

满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB

满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort

NOSQL非关系型数据库的好处首先是简单，比关系型数据库伸缩自如，这就加快了开发部署速度。其次基于键/值的NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间，能够高速处理TB甚至PB级数据。这对精打细算过紧日子的企业是个好消息，因为它可以运行在便宜的PC服务器集群上，而PC集群扩充起来非常方便并且成本很低，避免了“shareing”操作的复杂性和成本。通过执行速度变得更快。尽管与关系型数据库（DBMS）相比，NOSQL有其优势，但也存在一些缺陷，而这些缺陷正是DBMS的优势。如，关系数据库固有的约束，保证数据在最低层次拥有完整性。再比如，关系型数据库中的数据从某种程度上是独立于应用的，它的标准性兼容性比NOSQL更好。所以，NOSQL非关系型数据库应该更适合比如企业的IDM这类需要处理大量面向文档的数据，或者在开发环境严重地面向对象时，键/值数据库能尽量减少对“管道”代码的需求，或者集团级的电子商务平台、智能电网的用户营销系统等等。

因此，伴随着云时代的炒作，伴随着智能一词成为热点，在ERP重擎电力信息化大旗的时候，除了早已熟知的叫DBMS之腿外，要开始认识自己的另一条叫NOSQL之腿，它们各有千秋又各有不足。尽管DBMS目前唱着独脚戏，但是通过统筹分析认识应用需求的特质，WEB的架构，就能够扬长避短将两者之间有机地融合在一起，协同共舞。如果能够实现让自由格式的NOSQL容纳自由的思想，聚集来自全体员工脑海里的隐性知识，并对知识提供选择的平台，让DBMS成为企业的业务处理平台，那么ERP就会成为汇聚企业人员智慧的平台。至此方才成就ERP的梦想，体现ERP的价值，而员工就不再是格式化且僵化的“克隆战士”。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友