数据仓库到底需不需要主键

数据仓库到底需不需要主键？最近有不少提出关于数据仓库的主键问题，经过与业内大神们的讨论，算是有些心得，这里整理出来给大家分享。1.主键的历史首先我们了解一下主键的历史。说到主键，需要提及一个基本的数据库概念，那就是范式。设计数据库的关系模型时，一定要满足某些规则，来降低数据库中的数据冗余，而这些规则就称之为范式。范式共有五级范式，级别越高，数据冗余越小。一般来说，数据库设计满足第三范式是最普遍的要求。其中，第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。在数据库中，为了实现第二范式的要求，主键就诞生了。可以看得出来，主键的作用是为了降低数据冗余存储，并对数据模型进行约束，防止破坏数据模型操作的执行。比如级联数据的更新删除操作时拒绝执行的。另外，通常我们为了加速检索过程，在主键上建立各种索引，如B-TREE或Hash，加快了数据库操作的效率，且保持了实体的完整性。可以看出在传统关系数据库系统中，主键的作用非常重要，即保证了实体完整性，提高了主键检索效率。2.主键给数据仓库带来的问题数据仓库的系统，与传统系统的区别还是很大的。传统系统是面向交易的在线数据，需要进行频繁的事务型操作，而数据仓库存储的一般是历史数据。由于一些开发人员的习惯，以及数据库使用惯性等原因，在一些数据仓库的系统中频繁使用主键。实际上在大数据时代的数据仓库场景下，主键有些用法值得我们重新考量。如果我们在数据仓库建设中，向传统数据库中的一样去使用主键，会出现什么效果呢？以下从几点上给出分析：管理成本主键在数据库内部需要有数据库引擎自己维护，这在数据量较小的交易类系统中，问题不大。但是在大数据量的数据仓库中，维护主键会给引擎带来很大的管理压力。存储空间为了加快数据库的检索效率，数据库引擎通常会在建立表的过程中，将主键自动建立索引。一般索引，像是B-TREE、Hash等索引类型，膨胀率都会在1.5~2倍左右。这给系统磁盘空间带来巨大的存储压力，从而降低磁盘的存储和计算（I/O）效率。由其在大数据环境下，这个问题尤为突出。查询效率数据仓库多为分析类的查询场景，因此，很多数据库引擎都会选择列存来面对数据仓库的查询请求。而主键的设计是面向对象（行存）的，因此主键会降低列存本身的查询优势。且在数据操作时，主键会对唯一性进行校验，校验需要逐条进行，虽然有索引进行优化，但是这在大表（几十亿至上百亿）中进行操作的话，会造成严重的性能问题。这实际上不是主键的问题，而是索引的问题。数据量越大，索引结构越复杂，性能问题越明显。而如果不要索引，性能更会无法接受了。3.需求如何满足从上面来看，主键似乎在数据仓库系统中，有些水土不服。那么什么情况下数据仓库需要用主键呢？是否有其他可选方案？实际上，数据仓库中使用主键，无非是以下几种情况：保持唯一性对于一些维度表，需要保持维度属性的唯一性。这种情况下，对于维度表的更新操作，可以在确定唯一字段上，建立精确查询索引（通常是Hash），以保证效率。操作前先查询，如果存在就update，如果不存在就insert。数据重复加的问题数据仓库存储的是各种历史数据，数据来源是不同的业务数据系统。为了避免重复加数据的问题，可以在数据入库前，对不同来源的数据进行清洗、合并，提高数据质量，之后再统一入库。进行事务性操作这个貌似不是数据仓库该干的事，还是建议读写分离，事务型的场景还是选用传统数据库比较靠谱，数据仓库专门做专题分析。这是数据库的最基本功能，我们就是需要这个。。。。那就用吧。。。。4.总结通过上面的分析，可以看出主键是传统关系型系统的产物，他的存在以及作用都有一定的前置条件。但是，数据仓库的应用特殊性，实际上是打破了这些条件。因此我们要酌情在数据仓库中使用主键。当然，数据仓库应用主键本身给我们开发过程带来了很多的便利性，同时也造成了一些性能和存储问题，我们在应用中，需要在便利性和造成的问题之间找到一个平衡。