正确使用数据架构的五条规则 - infoworld


通过在数据架构过程的早期解决关键考虑因素,您可以避免将来出现严重问题。
构建合适的数据架构对于所有现代架构的长期成功至关重要。为了协助您的应用程序现代化过程,在构建或重新构建应用程序数据时,请遵循以下五个规则。
 
使用正确类型的数据库
构建数据的第一个也是最重要的决定是了解存储和访问数据所需的数据库类型。您是否需要:

  • 存储高度结构化的数据还是简单的键值数据?
  • 永久保留数据还是仅保留一小段时间?
  • 随机或顺序访问数据?
  • 使用固定模式、灵活模式还是简单的平面文件?
  • 使用支持 SQL 查询的关系数据库?

您需要回答这些问题来确定您需要使用的数据库类型。根据这些答案,您可以选择 SQL 数据库、简单的键值存储、内存驻留缓存、简单的对象存储或高度结构化的数据存储。
您选择的数据库类型将决定您的数据库最终能够做什么以及它在您的应用程序用例中的表现如何。确定您的可扩展性和可用性要求等对您的应用程序来说不可或缺的事情会受到您的数据库选择的显着影响。
 
将数据存储在正确的位置
一个看似简单但很重要的问题是,数据应该存储在哪里?根据数据和您的应用程序,您是否需要存储数据,例如,在您的应用程序的前端还是在后端?您可以将数据存储在消费者本地,还是需要与许多其他消费者共享数据?
 
从一开始就考虑扩展
现代应用程序必须能够扩展以满足企业客户不断增长的需求。这适用于所有企业和所有应用程序。
构建可扩展以满足您不断扩展的需求的应用程序绝对最困难的部分是扩展数据存储。无论是扩展以增加您需要为不断增长的客户群存储的数据量,还是扩展以允许更多人同时使用您的应用程序而不会降低性能,除非您从一开始就计划好,否则数据扩展很难。
然而,大多数应用程序架构似乎将数据缩放视为可以留待以后使用的副需求。一旦建立了主要的应用程序架构,应用程序开发人员就会考虑这一点。
稍后将强制拟合扩展到数据架构中是一项极其困难的任务,并且随着数据集规模的增长变得更加困难。到目前为止,构建可扩展性最简单的时间是在开始时,在您的应用程序需要扩展之前。如果没有主要的数据重构,等到以后可能会使扩展变得更加困难,并且可能是不可能的。
 
跨服务分发数据
许多云专家建议集中应用程序数据是管理大型应用程序的大型数据集的正确模型。他们认为,集中数据可以更轻松地应用机器学习和其他高级分析,从数据中获取更有用的信息。
但这种策略是错误的。集中式数据是无法轻松扩展的数据。扩展数据的最有效方法是将其分散并将其存储在拥有数据的单个服务中。您的应用程序,如果由数十个或数百个分布式服务组成,会将您的数据存储在数十个或数百个分布式位置。
此模型可以更轻松地扩展并支持完整的服务所有权模型。服务所有权使开发团队能够更加独立地工作,并鼓励服务之间建立更强大的 SLA。这促进了更高质量的服务,并通过本地化使数据更改更安全、更高效。
但是,如果您的企业需要对所有这些数据执行分析或机器学习怎么办?我仍然推荐这里描述的分布式数据模型。但是,为了使您的数据对分析和机器学习有用,请将相关数据的副本发送到后端数据仓库系统。在该数据仓库系统中,以适合您的分析目的的方式构建数据,并将此版本用于您的分析和机器学习算法。此数据仓库版本与您的应用程序记录数据分开且不同,后者仍存储在各个服务中。
 
在地理上分布您的数据
最后,确定谁将使用数据,以及他们将在地理上的位置。随着全球商业带来更多机会,而区域数据治理限制使管理全球数据变得更加困难,确定数据和用户位置变得越来越重要。
在创建数据架构之前,您必须回答以下关键问题:
  1. 您的数据在全球范围内可用是否重要,还是区域版本的数据对您的业务更重要?例如,您希望在美国和德国获得相同还是不同的数据?许多应用程序发现两种模型的混合很重要,这个答案是可以接受的,只要您知道哪些数据必须全球化,哪些必须区域化。
  2. 您是否对可以存储的数据和存储位置有区域限制?一些地方有限制,防止客户数据离开客户所在的国家/地区。其他人对可以跨越国家和地区边界传输的数据有限制。某些区域比其他区域具有更严格的隐私限制。哪些数据限制适用于您数据的哪些部分?
  3. 对于跨区域共享的数据,在每个区域显示完全相同的数据有多重要?换句话说,数据是否必须在区域之间完全同步?不同的模型给你的数据集带来了不同的负担。最终一致性模型与符合[url=https://en.wikipedia.org/wiki/ACID]ACID 的[/url]事务完整性模型具有非常不同的性能特征。

这些问题的答案将决定您是提供全球数据还是区域数据,可以和不可以在何处使用这些数据,以及何时以及如何在区域之间同步数据。
数据架构是构建高度可扩展、高度可用、全球可访问的现代应用程序的关键部分。数据架构中的错误可能会导致可扩展性、可用性甚至法律一致性问题。在应用程序增长后更改数据架构既困难又痛苦。预先解决关键数据需求要容易得多。
通过在数据架构过程的早期遵循这五个规则,您可以避免将来出现严重问题。