如果你一直在使用数据库,你就会知道NoSQL是热门话题。主要是因为NoSQL在很大程度上填补了SQL相当难以填补的空白。传统上,SQL数据库的成本往往很高,从其只能垂直扩展,到数据库还没做出来就需要对模式进行大量的设计。因此,NoSQL就是为了对抗SQL而开发的,它可以水平扩展,也不需要使用Schema,但是是不是真的不需要Schema呢?本来就来探讨一下。
NoSQL和Schemas
对于很多刚进入NoSQL的人来说,他们会被 "不需要SQL "和 "无Schema "这样的流行语所吸引,但却往往看不到森林中的树木。虽然NoSQL确实是作为对SQL的回应而产生的,但它并不是作为一种替代,而是作为一种增强和补充的方式。更具体地说,这种无模式意味着NoSQL是非常灵活的,可以用大量不同的NoSQL数据模型来存储数据。
不过这并不意味着NoSQL不能使用Schema,毕竟,NoSQL的数据可以是丑陋的、随机的、混乱的、无限重复的(SQL是专门为了路由出重复的数据而做的,而NoSQL没有)。因此,除非整个流水线只由计算机处理(不会的,因为数据科学并不完美),否则有一个Schema肯定是有用的。
为NoSQL设计Schema
由于NoSQL非常适合扩展性,所以在方案设计上主要考虑的可能是数据模型的可扩展性和性能。特别强调优化数据访问,而数据访问最终往往会非常依赖查询。因此,NoSQL中的Schema设计重点是规划专门配合工作流的键和索引,以便快速高效。
当然,选择主键或决定哪些字段应该被索引有几种方法。对于这一点,你一定要考虑用户是如何处理或将要处理数据的。回顾以前的查询可以给你一个很好的提示,让你知道用户日常是如何使用数据库的,并很好地作为一个启动点。这种查询驱动的设计一般至少需要包含业务数据实体、用户需求和规范,最后是所述用户的查询Schema(如果存在此类数据)。
为你的数据库编写完美的代码
一旦你有了这些基本的成分,你就可以开始设计模式了,一个很好的起点就是设计NoSQL数据库的自定义、类似表的结构。对于这一步,重要的是要在编写一个服务于单一功能的代码和可以满足多个功能的代码之间找到一个平衡点。毕竟,即使是NoSQL,帮助降低开销也是很重要的一步。
最后一点需要对数据进行去正常化,因为这对任何NoSQL Schema设计都是必不可少的。虽然这不一定是一门精确的科学,但两种最好的方法是通过引用或嵌入来实现数据的去正常化。这样就可以实现1:1、1:N或M-N关系等核心设计模式。
特定主键
在确定了这些之后,下一步就是设计主键。但是因为每个NoSQL数据库的架构都是不同的,了解每个架构如何实现其主键是这一步的根本,所以这里就不详细解释了。最后,你需要设计索引,和上面的步骤类似,根据你使用的NoSQL数据库不同,它的差别很大。尽管如此,有几个设计概念你应该考虑。
创建一个合并的属性列表作为查询的谓词,可以帮助你设计更高效的索引。当然,你应该避免创建过于细化的索引,因为那只会降低效率。
对于上面的观点,只有当数组中的所有属性都需要时,才应该设计数组索引。如果你计划进行索引,保持数组大小最小化是至关重要的(在数据类型复杂的索引上应避免使用特殊索引)。
编辑NoSQL Schemas
鉴于NoSQL的灵活性倾向,对Schema进行更改是很容易的,而且基本上会导致终身设计和实现Schema更改的过程。这在刚开始的时候听起来可能是个苦差事,但最终当你在几年后意识到需要做一个非常重要的改变时,就会变得很好。NoSQL在没有Schema的情况下单独离开往往会导致无政府状态,因此创建某种形式的Schema是有用的。你不必这样做,特别是对于小规模的应用,但不要以为走NoSQL路线就可以不用创建Schema了。
关于慧都数仓建模大师
慧都数仓建模大师能够快速、高效地帮助客户搭建数据仓库供企业决策分析之用。满足数据需求效率、数据质量、扩展性、面向主题等特点。基于企业的业务目标,进行数据理解、数据准备、数据建模,最后进行评价和部署,真正实现数据驱动业务决策。更多详情,请联系我们。
发表评论