NOSQL表架构

时间:2012-07-07 20:40:32

标签: nosql azure-table-storage

我正在尝试规划NOSQL表架构。我的数据中存在关系,但它们大多数是关系数据库中的N:N;普通的1:N关系很少。

所以在这种情况下,我正在尝试创建隐式关系,这将允许我从关系的两端进行浏览。我正在使用Azure表存储,所以我知道全文搜索不可用;我只能通过Partition Key + Row Key组合检索“对象”。

想象一下,我有一个名为“People”的表和一个名为“Hamburgers”的表,表中的每个对象都可以与另一个表中的多个对象相关。汉堡包被许多人吃掉,每个人都吃很多汉堡包。

由于这种关系很可能与人们有关 - 即每个汉堡包的人数多于反之亦然,我会在这样的表格中处理这个问题:

汉堡包表

分区键:只有1个分区

行键:唯一ID

人员表

分区键:只有1个分区

行键:唯一ID

“Columns”:每个人吃的汉堡包的额外价值

汉堡人表

分区键:汉堡行键

行键:人行键

这样,如果我正在看一个汉堡包并想看到所有吃它的人,我可以去汉堡人餐桌并使用汉堡包的行键来分配所有吃的人汉堡包。

如果我是一个人并且想要看到他/她吃的所有汉堡包,那么我就会有人吃的汉堡包的行键的额外价值。

当将数据插入表格时,如果数据涉及汉堡包/人物关系,我会在适当的表格中插入两个值,然后创建汉堡包 - 人员表格。如果我试图保留一份无重复的汉堡包清单,我需要首先搜索汉堡包,以确保汉堡包不在那里(如“Whopper” - 如果它在那里,我不会插入它再次)。然后,我需要在Hamburger-People表中的汉堡包现有分区中插入一行。

但在大多数情况下,不存在不重复的要求。

这是一种很好的NOSQL架构最佳实践方法,还是以后会遇到问题?

UPDATE 此外,我希望以后能够对数据表进行分区,但我不知道如何使用这种结构进行分区。在汉堡包表中添加第二个分区需要我在汉堡包 - 人员表中存储一个额外的值,我不确定这是否会开始过于复杂。

1 个答案:

答案 0 :(得分:1)

好的,很好的问题,我认为大多数是每个RDMBS开发人员一旦遇到NoSQL世界就会遇到的问题:

<强> 1。如何对分区进行分组? 为了获得最好的分区,您需要考虑数据库的负载应该分布在您的服务器上,让我们看看您的方法会发生什么

有钥匙的人&#34; A&#34;进入餐厅,你将保存它和他的汉堡,这是一个经典美味(Key&#34; T&#34;)人员记录进入服务器X而汉堡去服务器Y,现在一个新客户进入使用Key&#34; B&#34;,并想要一些不同的东西,一个汉堡&#34; W&#34;再次,这个人去服务器X和burguer到服务器X,这次服务器X得到所有负载,如果你再说一遍,你会发现服务器X变成瓶颈,因为75%的记录都在那里(所有的人和50%的汉堡包),这会给你带来一些问题加载。但是......当您尝试查询时问题会更好,因为所有查询都会到达服务器X. 要解决这个问题,您可以使用人员的密钥作为关系分区的一部分,因此该人员将在burguers关系的同一服务器中进行分区,这样您的工作负载将得到平衡,如果一个人没有任何问题服务器的数量下降(人和汉堡将会失败并且#34;一起),这将是一种一致性和不一致性&#34;

<强> 2。我应该使用&#34;关系&#34;在NoSQL数据库中? 请记住,NoSQL意味着当您的问题需要解决方案以避免过度查询时,您被授予重复信息,因此,如果您可以存储通常一起查询的信息,您将避免往返于数据库。所以,如果你存储一个&#34;交易&#34;而不是&#34;人和burguers&#34;您将获得更好的性能并避免对数据库进行一些点击,让我们用您的方法做一个真实数据的示例,并将其与&#34; my&#34;进行比较。的方法:

  1. Joe Black来到餐厅并要求美味,在这里您将进行以下交易: 创建Joe Black记录 创建Burguer交易记录
  2. 如果您想列出您需要的每日交易:

    从&#34;表中获取当天的所有记录&#34;人格,然后去找人&#34;表&#34;并检索客户的名称,现在,转到hamburguer记录并检索他们的名字。 (您将无法进行跨表查询,因为某些记录可能位于一台服务器中而其他记录位于第二台服务器中)

    好的,如果你创建一个表&#34; Transactions&#34;并在那里存储以下json:

    {custid:&#34; AAABCCC&#34;,      名称:&#34; Joe&#34;,lastName:&#34; Black&#34;,      日期:&#34; 2012/07/07&#34;,      订单:{         代码:&#34; Burger0001&#34;,         名称:&#34;美味&#34;,         价格:3.5      }    }

    我知道你会有几张相同的记录&#34;美味&#34;描述,当您将NoSQL解决方案应用于这些类型的问题时,这非常有用,现在,您创建了多少个将信息存储到数据库的事务?只有一个!哇...在一天结束时你需要多少个查询来检索信息?再一次......只有一个,它会产生一些问题,但也会为你节省很多工作,比如......你能轻易地重印这个订单吗? (是的,你可以!)如果客户名称发生变化怎么办?甚至可能吗?

    我希望这会对你有所帮助,

    我是http://djondb.com的创建者所以我认为根据数据库能够做的事情,拥有内部知识可以让我对问题采取不同的方法,但我不知道如果您无法查询文档值和行键,azure将如何处理查询,但无论如何,我希望这能为您提供洞察力。