【解析】大数据环境下的数据库设计

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

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

大数据环境下的数据建模

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

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

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

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

数据库设计是质量的保证

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

  • 通过自动数据元素有效值检查来协助避免缺陷;
  • 在应用构建和测试期间允许缺陷检测和修复;
  • 尽可能让数据验证接近其源头;
  • 提供稳定性,可靠性,数据可访问性和系统扩展性。

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

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

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

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

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

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

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

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

大数据的数据库设计

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

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

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

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

  • 定期批量加载(每天,每小时)一体机,但要明白其中的数据并不完全是最新的。
  • 细流加载,基本表中的记录有过更新的地方会同步传送至一体机。这样就会保持一体机数据最新,但是记录的处理要比批量加载缓慢许多。

总结

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

原文发布于微信公众号 - 大数据挖掘DT数据分析(datadw)

原文发表时间:2014-07-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT大咖说

618大促,苏宁如何通过citus打造分布式数据库抗住DB高负载

内容来源:2017 年 10 月 20 日,苏宁云商IT总部资深技术经理陈华军在“PostgreSQL 2017中国技术大会”进行《苏宁citus分布式数据库应...

852
来自专栏CSDN技术头条

那些高级运维工程师,都是怎么给公司省机器的?

随着项目用户量的快速增长,前期可能由于应用程序设计、数据库设计及架构不当,大多项目会在用户量百万、日志/流水等表过千万、乃至过亿时,出现写入卡顿、查询缓慢、各种...

872
来自专栏PHP技术

mongodb与mysql相比的优缺点

与关系型数据库相比,MongoDB的优点: ①弱一致性(最终一致),更能保证用户的访问速度: 举例来说,在 传统的关系型数据库中,一个COUNT类型的操作会锁...

3995
来自专栏企鹅号快讯

分布式设计与开发-宏观概述

分布式可繁也可以简,最简单的分布式就是大家最常用的,在负载均衡服务器后加一堆web服务器,然后在上面搞一个缓存服务器来保存临时状态,后面共享一个数据库,其实很多...

1868

容器时代的分布式记录(第二部分)

欢迎回到我们的系列。在第一部分中,我们谈到了微服务和容器的最近兴起。我们介绍了这种类型的体系结构引起的日志记录问题以及可能的解决方案 - 聚合。既然之前我们已经...

1998
来自专栏Golang语言社区

高并发服务器的设计--架构与瓶颈的设计

做架构设计,难免有时候被人问及系统的瓶颈在哪,那首先来了解下什么是瓶颈? 打个形象的比方,人的嘴巴可以吞下一整个面包,但是却咽不下去,因为食管不给力,它比较细,...

4628
来自专栏北京马哥教育

正确评估SQL数据库性能,你必须知道的原理和方法!

作者:阿特 来源: http://blog.csdn.net/capsicum29/article/details/71480799 数据库是一个很重要的模块...

44511
来自专栏CSDN技术头条

围绕着内存数据库的4个流言

【编者按】作者Yiftach Shoolman是Redis Labs的联合创始人兼CTO,拥有着丰富的实践经验。Yiftach 之前曾是Crescendo Ne...

1757
来自专栏数据之美

CPU 100% 异常排查实践与总结

1、问题背景 昨天下午突然收到运维邮件报警,显示数据平台服务器cpu利用率达到了98.94%,而且最近一段时间一直持续在70%以上,看起来像是硬件资源到瓶颈需要...

2738
来自专栏数据和云

故障树分析法在数据库诊断分析中的应用

编辑手记:将知识转化为能力,除了需要经验的积累和时间的磨砺,更重要的是正确的方法和思维模式,学会应用知识才是真正的能力。本文试图通过方法的讨论使大家能够形成一个...

39814

扫描关注云+社区