数据架构简史:转换中的范式

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
数据管理 DMS,安全协同 3个实例 3个月
推荐场景:
学生管理系统数据库
简介:


数据架构简史:转换中的范式

据架构是一系列决定收集哪些数据,如何在数据库系统中使用、处理和存储数据的规则、策略以及模型。例如,数据集成是依赖于数据架构用于集成过程中的指令。如果没有从编程范式转换到数据架构范式,现代计算机将会变得更加笨拙迟钝。

对于早期的计算机,创建过分简单化的程序是为了处理特定类型的计算机问题,甚至没有考虑过数据集成的概念,每个程序之间都是单独分开的。二十世纪四十年代至七十年代,程序处理是最主要的问题,有关建立数据架构的问题根本考虑得少之又少,甚至不在考虑的范围之内。程序员致力于让计算机通过执行特定的操作,以支持组织的短期目标。只有定义为“程序需要”的数据被使用,计算机才不会被用于长期的数据存储,恢复数据需要能够编写、检索特定信息的程序,而这相当耗费时间和金钱。

编程范式转换为数据库架构范式

1970年,Edgar F. Codd公开发表题为“大型共享数据库数据的关系模型”的论文,文中提到了组织起数据的相关步骤,Codd的理论基于运用于集合论里面的数学运算,结合了一列规则,以确保数据被存储在最小冗余里。他的方法成功的创建了数据库架构,简化了计算机的效能。在Codd的理论之前,COBOL程序和大多数其他的程序都是按等级排列的,这样的排列使得搜索有必要从总类别开始,然后再逐渐缩小搜索类别。而Codd提供的相关途径则允许用户更加有序、有效地利用二维表储存数据。(Codd 称之为“关系法”)

1976年,在麻省理工学院工作的Peter Chen发表题为“实体-关系模型对数据的统一视图”的论文,文中介绍了实体/关系建模,也就是今天被广泛熟知的“数据建模”。他以图表的形式生动形象地呈现了数据架构,两年后,Oracle宣布推出首款涉及业务的关系数据库管理系统(RDBMS)。

以计算机为工具工作的人们开始意识到数据架构比程序架构更加靠谱。它的稳定性源自重新设计系统的中间部分,并将进程彼此隔离(类似于程序员将程序隔离的方式),重新设计的关键在于添加了数据缓冲区。

缓冲区最初是一个临时记忆储存系统,旨在从原始计算机的内存中快速移除数据,这样计算机就不会陷入运阻,并能继续解决问题。 然后,数据从缓冲区传输到打印机,“慢慢”打印出最新的计算结果。今天的数据缓冲区的版本是一个由设备共享的区域,或者一个程序的进程,它们以不同的速度运行,或者有不同的优先级。现代缓冲区允许每个进程(或设备)在没有冲突的情况下运行,与缓存类似,缓冲区充当“中间存储空间”,但也有助于协调不同的活动,而不是简单地简化内存访问。

商业界很快就意识到Edgar F. Codd和Peter Chen的见解的优势,新的数据架构设计显而易见的比程序结构更快更灵活更稳定。此外,他们的见解促使计算机编程社区发生了文化上的转变,数据结构现在被认为是远比程序重要得多。

假设:数据在范式转换中丢失

数据架构的进化需要消除三个基本的假设(假设的定义:一些被认为是理所当然的事情;一种缺乏有力证据的猜测,却被当作事实来看待。)

假设1:每个程序必须和其他程序隔离开来。这种隔离论导致了程序代码、数据定义和数据条目的重复。Codd的关系法解决了不必要的副本麻烦,他的模型将数据库的模架或布局从物理信息存储中分离出来(成为数据库系统的标准)。他的关系模型指出,数据不需要存储在单独的、孤立的程序中,数据条目和程序编码不需要不必要地复制。一个单独的关系数据库足以用于存储所有的数据,所以,一致性可能(几乎可以)得到保证,并且也更易于查找错误。

假设2:输入和输出是对等的,设计上应该让他们相匹配。目前,输出和输入设备的数据处理速率有很大差异,这与预想着两者以相同速度运行的期望是完全不同的。缓冲区的使用开启了实现输出、输入的区别对待,Peter Chen的革新揭示了数据创造者和数据用户之间的差异。数据用户通常希望从潜藏在数据库下的不同部分看到大量的信息以作比较,并从中提取最有用的信息。数据创造者,从另外一方面来说,则专注于处理数据,一次一个进程。数据创造者(输入)和数据用户(输出)两者的目的是截然不同的。

假设3:企业组织应该反应在他们的计算机程序里面。随着缓冲区和关系数据库的运用,“程序”这个概念应该会逐渐模仿公司的结构,更加灵活的数据库取代了企业在提供有用结构方面的角色,同时收集和处理信息。现代数据模型既反映了企业的组织结构,也反映了用于实现目标的工具。

SQL和数据架构

Codd的关系法导致结构化的查询语言(SQL),在上世纪八十年代成为了标准的查询语言。关系数据库变得非常受欢迎,促进了数据库市场的发展,这反过来又导致了等级数据库模型的没落。

二十世纪九十年代早期,许多主要的计算机公司仍然专注于程序,试图销售昂贵而复杂的数据库产品。回以他们的则是新的、更具竞争力的企业开始发布工具和软件(如:Oracle开发人员、PowerBuilder)用来增强系统数据架构。二十世纪九十年代中期,互联网的使用推进了数据库行业的显著增长以及计算机的总体销售情况。

数据库架构性的设计,引领了数据管理的蓬勃发展。企业已经发现了信息本身对公司的价值,二十世纪九十年代以后,诸如“数据管理员”、“数据库管理员”的标题开始出现。数据管理员的职责在于保证数据使用中的高质量和完整性。

关系数据库管理系统使创建一个呈现概念模式(某种类型的映射)的数据库成为可能,然后提供数据库的不同透视图,这是为数据创建者和数据使用者设计的。另外,每个数据库管理系统都可以将其物理存储参数与列结构和表分开。

NoSQL和数据架构

NoSQL不是一个程序,它是一个数据库管理系统,使用的是相当简单的架构。在处理大数据和不需要关系模型时,它是很有用的。NoSQL数据库系统在管理和存储数据的方法和过程中是非常多样化的。SQL系统在功能方面通常比NoSQL系统具有更大的灵活性,但是缺乏NoSQL系统的可伸缩性。但是,现在有许多商业软件包可以结合“两个世界的最佳方式”,而且更多的软件包将会一直进入市场。

最近,一些机构组织在DATAVERSITY的文章和访谈中(还有许多其他的可能性)提供了一种数据架构解决方案,利用关系数据库中常见的工具来处理大数据。Kyvos Insights公司销售与hadoop存储系统兼容的软件,它们的“Hadoop/OLAP ”组合在不同程度上促进了非结构化和结构化数据的处理,使得人们可以相对轻松地对大数据进行分析。

Hackolade公司也销售一款软件包,采用一种用户友好数据模型提供了“高功能”的工具来处理NoSQL。该软件将NoSQL融合了可视化图形的简明性,结合Hackolade其他工具一起使用,既减少开发时间,又提高了应用程序的质量。他们的软件目前和Couchbase、DynamoDB、MongoDB 模式兼容(他们计划未来能囊括更多NoSQL数据库)。

RedisLabs将他们的云计算与他们的软件包Redis Pack结合在一起,提供另一个架构解决方案。Redis Pack和它的云计算提供了三种优势:速度、持久性(保存您的信息),以及他们提供的数据类型的多样性。从本质上来说,Redis是一个“非常快”的NoSQL、键值数据存储,同时可以充当数据库、缓存和消息代理。

Reltio提供服务。他们已经创建了一个云管理平台,并提供完成处理大数据所需的工具和服务。他们提供研究人员,将来自多个来源的大数据与主数据管理(MDM)合并在一起,并开发统一的目标。Reltio的系统支持多种行业领域,包括零售、生命科学、娱乐、医疗保健和政府。

数据架构从早期就完全改变了,并且很可能是由于一些新的趋势,例如物联网、云计算、微服务、高级分析、机器学习和人工智能,以及像Blockchain这样的新兴技术,将会继续改变未来的发展方向。 


本文作者:佚名

来源:51CTO

相关实践学习
MySQL基础-学生管理系统数据库设计
本场景介绍如何使用DMS工具连接RDS,并使用DMS图形化工具创建数据库表。
相关文章
|
2月前
|
机器学习/深度学习 数据采集 人工智能
揭秘!47页文档拆解苹果智能,从架构、数据到训练和优化
【8月更文挑战第23天】苹果公司发布了一份47页的研究文档,深入解析了其在智能基础语言模型领域的探索与突破。文档揭示了苹果在此领域的雄厚实力,并分享了其独特的混合架构设计,该设计融合了Transformer与RNN的优势,显著提高了模型处理序列数据的效能与表现力。然而,这种架构也带来了诸如权重平衡与资源消耗等挑战。苹果利用海量、多样的高质量数据集训练模型,但确保数据质量及处理噪声仍需克服。此外,苹果采取了自监督与无监督学习相结合的高效训练策略,以增强模型的泛化与稳健性,但仍需解决预训练任务选择及超参数调优等问题。
137 66
|
14天前
|
Cloud Native 持续交付 云计算
探索云原生架构:构建现代应用的新范式
在当今数字化浪潮中,云原生架构以其敏捷性、弹性和可扩展性成为企业技术转型的核心驱动力。本文将引领读者深入理解云原生的概念,剖析其关键技术组件——微服务、容器化、DevOps实践及持续交付/持续部署流程,并揭示这些技术如何相互协作,共同构建高效、可靠且易于管理的现代软件系统。通过对云原生架构的全面解读,我们旨在为开发者、架构师乃至企业决策者提供有价值的见解与指导,助力其在快速变化的市场环境中保持竞争力。
|
28天前
|
存储 搜索推荐 数据库
MarkLogic在微服务架构中的应用:提供服务间通信和数据共享的机制
随着微服务架构的发展,服务间通信和数据共享成为关键挑战。本文介绍MarkLogic数据库在微服务架构中的应用,阐述其多模型支持、索引搜索、事务处理及高可用性等优势,以及如何利用MarkLogic实现数据共享、服务间通信、事件驱动架构和数据分析,提升系统的可伸缩性和可靠性。
26 5
|
2月前
|
安全 网络安全 数据安全/隐私保护
云原生技术探索:容器化与微服务架构的实践之路网络安全与信息安全:保护数据的关键策略
【8月更文挑战第28天】本文将深入探讨云原生技术的核心概念,包括容器化和微服务架构。我们将通过实际案例和代码示例,展示如何在云平台上实现高效的应用部署和管理。文章不仅提供理论知识,还包含实操指南,帮助开发者理解并应用这些前沿技术。 【8月更文挑战第28天】在数字化时代,网络安全和信息安全是保护个人和企业数据的前线防御。本文将探讨网络安全漏洞的成因、加密技术的应用以及提升安全意识的重要性。文章旨在通过分析网络安全的薄弱环节,介绍如何利用加密技术和提高用户警觉性来构建更为坚固的数据保护屏障。
|
2月前
|
存储 监控 安全
大数据架构设计原则:构建高效、可扩展与安全的数据生态系统
【8月更文挑战第23天】大数据架构设计是一个复杂而系统的工程,需要综合考虑业务需求、技术选型、安全合规等多个方面。遵循上述设计原则,可以帮助企业构建出既高效又安全的大数据生态系统,为业务创新和决策支持提供强有力的支撑。随着技术的不断发展和业务需求的不断变化,持续优化和调整大数据架构也将成为一项持续的工作。
|
2月前
|
消息中间件 NoSQL 持续交付
构建高效微服务架构:后端开发的新范式
【7月更文挑战第50天】在数字化转型的浪潮中,微服务架构已成为推动企业敏捷开发和维护的关键。本文深入探讨了如何构建一个高效的微服务架构,包括选择合适的技术栈、确保服务的可伸缩性与弹性、以及实现持续集成和持续部署(CI/CD)。通过分析具体案例,文章揭示了后端开发者如何在不断变化的技术环境中保持竞争力,并提出了优化策略以提升系统整体性能和可靠性。
|
2月前
|
机器学习/深度学习 自然语言处理 数据处理
|
2月前
|
缓存 程序员 调度
第3章-图形处理单元-3.1-数据并行架构
第3章-图形处理单元-3.1-数据并行架构
29 1
|
2月前
|
Java 数据库连接 微服务
揭秘微服务架构下的数据魔方:Hibernate如何玩转分布式持久化,实现秒级响应的秘密武器?
【8月更文挑战第31天】微服务架构通过将系统拆分成独立服务,提升了可维护性和扩展性,但也带来了数据一致性和事务管理等挑战。Hibernate 作为强大的 ORM 工具,在微服务中发挥关键作用,通过二级缓存和分布式事务支持,简化了对象关系映射,并提供了有效的持久化策略。其二级缓存机制减少数据库访问,提升性能;支持 JTA 保证跨服务事务一致性;乐观锁机制解决并发数据冲突。合理配置 Hibernate 可助力构建高效稳定的分布式系统。
52 0
|
2月前
|
存储 XML 数据管理
数据架构规划与设计
数据库在数据管理方面具有管理方便、存储占用空间小、检索速度快、修改效率高和安全性好等优点。
45 1