很多大数据应用的实施似乎都是在一个现有的数据仓库上，添加一个或多个新的大容量数据流，还有一些支持数据存储和业务分析的专业软硬件。数据存储问题通常是通过部署一个专门的硬件一体机来协调，这样就可以在存储大量数据的同时还能够提供超快的数据访问。

     在这样的情况下，我们还需要考虑数据库设计的问题么?

大数据环境下的数据建模

    大多数DBA认为：良好的数据库设计是系统和应用程序设计的一部分。很多的业务需求，如数据可用性，清理处理，还有应用性能都可以利用特定的数据库设计加以解决。

    那么对于大数据又如何呢?有趣的是，为大数据业务分析提供软硬件解决方案的供应商总是宣称数据库设计并不是那么重要。他们认为，由于数据是以专门的格式进行存储的，所以大多数数据库设计便没有了用武之地。

    在这个问题上的困惑通常是源于对解决方案要以何种特殊的方式执行大数据查询的误解。简单来说就是，在大多数情况下，数据会存储在两个地方：你当前的生产数据库管理系统(DBMS)和新型专用的一体机。当前的生产流程是提取，转换并加载数据到当前DBMS，继续按原样操作，还有一个额外步骤：每当你加载数据到一个表的时候，你还要确保新数据也能被加载到新一体机中去。

    在DBMS加载成功后，便可以马上把数据加载到一体机，或者可以供后续执行分批处理。而重要的是，在任何大数据查询使用已加载数据来获得性能改善之前，必须先把数据加载到一体机。

数据库设计是质量的保证

    有质量的数据库设计意味着什么呢?一般来说，数据库设计开始于数据模型和定义之间关系的业务规则。例如，订单总是与客户相关的，并且客户可能没有订单或者有多个订单。有了这些东西以及数据元素定义和属性，数据库设计就可以在以下领域解决，处理或是降低风险：

1.通过自动数据元素有效值检查来协助避免缺陷;

2.在应用构建和测试期间允许缺陷检测和修复;

3.尽可能让数据验证接近其源头;

4.提供稳定性，可靠性，数据可访问性和系统扩展性。

     数据库设计人员的做法有什么差别?

     糟糕的数据库设计对技术支持的影响非常之大，他们必须实时处理系统问题，这样就会抬升定位和解决问题的成本。其在产品行为上还会体现为惹恼或是赶走客户。而与糟糕设计相关的常见的问题就是非常差得应用性能和数据冲突。

     典型的修复方法包括数据库重组或重新设计，如添加表索引和改变表分区和聚簇。然而，在大数据环境中，这些方法在专用一体机中通常是行不通的。它们只会存在于数据库的基本表中。这是问题的症结所在：尽管供应商声称你所有的数据都可以迁移至专用一体机，但这绝不是优先的解决方案。

      让数据在主数据库管理系统和一体机之间共存是较好的方法，其原因如下：

1.避免单点故障。专用一体机往往存折一个单点故障。虽然有供应商和支持人员的努力，但是一体机中的软硬件，网络连接和流程都可能会发生故障。如果是这样，如何才能进行满意的查询呢?数据协同定位在数据库管理系统中，查询结果可以通过访问基本表得以满足。当然，性能肯定会受到影响;但是，如果不这样做的话，在有人修复这一问题之前，你的大数据应用都会是不可用的。

2.提供数据卸载。查询并非是数据的为数不过消费方。一种常见的用法是将生产数据卸载到测试环境。此外，某些第三方供应商软件工具会直接访问本地数据库中的数据，而这在一体机中是不可用的，因为数据是以专门的格式进行存储的。

3.备份和恢复。常见的备份和恢复工具都是以那些驻留在数据库中的数据为基础的。而第三方供应商工具通常用于高性能备份和恢复，包括索引恢复。这些备份是针对基本表和表空间执行的，而非一体机。

4.某些性能状况。在某些情况下，SQL查询在一体机中无法执行。这些限制都是定义在手册中的，并且随着供应商一体机和版本的不同而不同。在这些情况下，你别无选择;你必须访问基本表并接受性能的下降。其中一些限制包含了特定的SQL语法，例如可滚动游标，动态SQL，使用多个字符编码方案，某些相关表表达式，以及使用某些内置函数。

　　大数据的数据库设计

     因为你要同时在DBMS和专用一体机中保存数据，所以标准数据库设计规则对你来说仍然适用。有趣的是，由于一体机的存在，如今某些规则得以扩展或是变得更加复杂。下面是一些注意事项：

     对索引的需求。索引服务于多种需求：它们可以赋予数据元素为数不过性，它们可以赋予参照完整性关系，它们可以定义主键，并且它们可以定义额外访问路径。后一项是十分重要的。在大数据环境中，我们的想法是把长时间运行的查询放进一体机中以进行高速处理。如果某些存在的索引仅仅是提供可选访问路径，那么可能就不再需要它们了。数据库设计或是重新设计应该包括对所谓性能索引的检查。如果此索引不再被查询所用，那么就可以删除它们，从而节省表数据恢复所需要的磁盘空间，处理时间和恢复时间。

     删除一体机的SQL限制。通常来说，数据的业务规则决定着数据库设计的部分内容。这包括进行物理分区以允许更快的查询和更简便的数据清理，诸如字段约束在内的数据元素域检查，以及用于支持参照完整性规则的主键和外键定义。接着，应用程序开发人员会编写SQL查询来访问数据。此外，用户可能拥有的报告工具会自动为查询和报告生成SQL代码。因为SQL查询语法和功能取决于数据库设计，所以设计人员需要对一体机限制熟稔于胸。

    为高速一体机的数据加载进行设计。现在正常的数据库加载过程包含一个额外步骤：将数据加载进一体机。如何才能对此以优先的方式实现呢?这主要取决于你的应用和数据波动程度，因此要考虑以下变量：

      定期批量加载(每天，每小时)一体机，但要明白其中的数据并不完全是前沿的。

      细流加载，基本表中的记录有过更新的地方会同步传送至一体机。这样就会保持一体机数据前沿，但是记录的处理要比批量加载缓慢许多。

总结

     虽然数据库软硬件方面的进步可以将数据查询的速度提升一个档次，但大数据和一体机并没有把对良好数据库设计的需求弃之不用。实际上，设计人员有更多的事情需要去考虑：备份和恢复，索引管理，多途径数据访问，以及SQL限制。