Question

我在学习HBase的同时尝试参加会议/与会者计划。

我正在讨论是否将关系从第3范式转化为第1范式（原子力/列中没有值集）到0范式（不存在原子/值组）在一栏内）。

本质上，我试图确定如何将以下关系模式转换为HBase：

CREATE TABLE customer (
    customer_id INT PRIMARY KEY
    ,capacity INT
);
CREATE TABLE attendee (
    attendee_id INT PRIMARY KEY
    customer_id INT REFERENCES customer (customer_id)
);
CREATE TABLE customer_dedicated_hosts (
    customer_id INT REFERENCS customer (customer_id)
    ,dedicated_host_attendee_id INT REFERENCES attendee (attendee_id)
);
CREATE TABLE meeting (
    meeting_id INT PRIMARY KEY
    ,host_attendee_id INT REFERENCES attendee (attendee_id)
);
CREATE TABLE meeting_attendee (
    meeting_id INT
    ,attendee_id INT
    ,CONSTRAINT ... PRIAMRY KEY (meeting_id, attendee_id)
);

A＆＃34;客户＆＃34;有1：M参加者。

参加者有M：N会议。

会议由与会者主持，因此通过host_attendee_id FK链接到与会者。

客户有许多被允许举办会议的与会者 - 在CustomerDedicatedHosts中列出。如果客户的与会者主持不是专门主持人的会议，他应该被罚款。

每次会议都有特定客户的与会者身份。如果客户超过他参加一次会议的能力，他应该被罚款。

我很好奇这是否应该在一个或两个表中使用一个列族进行 - 非规范化表，重复次数很多。相当于

CREATE TABLE hostapp (
    customer_id INT
    ,capacity
    ,dedicated_host_attendee_id
    --ROWKEY == customer_id, dedicated_host_attendee_id
);
CREATE TABLE meetingapp (
    customer_id INT
    ,attendee_id INT
    ,meeting_id INT
    ,host_attendee_id INT
    --ROWKEY == customer_id, meeting_id, attendee_id
);

在这种情况下，我无法完全理解非规范化。为什么不拆分＆＃34; hostapp＆＃34;分为两个表，一个有两列（customer_id，capacity），另一个有两列（customer_id，dedicated_host_attendee_id）。我想我可以使用meetingapp表中重复的host_attendee_id，但为什么不将会议应用分成两个表（customer_id，meeting_id，host_attendee_id）和（meeting_id，attendee_id）？

这是设计此架构的正确方法，还是应该采用不同的方式？

我也很好奇我可以滥用列族中的列，将它们用作oracle中的嵌套表。

CREATE TABLE meetingapp (
    customer_id INT
    meeting_id INT
    host_attendee_id INT
    attendees VARRAY(<INT>)
);

在hbase术语中，一个列族始终具有以下三列：customer_id，meeting_id，host_attendee_id。相同或另一个列系列将具有以下列：attendee1，attendee2，... attendeeN;换句话说，可变数量的列取决于列族的数量，类似于Oracle中的嵌套表或varray。

如何最好地接近这个？

Answer 1

HBase具有很大的灵活性，您可以完成所有描述和更多（例如将实际数据放入密钥等）。要设计正确的模式，您需要考虑数据的访问模式（读取和写入）

例如，当您必须一起更新大量列时，您可能希望将它们保存在同一行（以获得原子性），如果您需要通过Hive（或其他SQL前端）进行访问，则需要更多保守的你如何使用列，键等。如果你更频繁地访问某些维度的数据，你可以将其提升到密钥或推广一些数据等等。

从本质上讲 - 如果您需要有关正确设计的建议，您需要提供更多上下文，您将尝试使用数据

Hbase架构设计 - 完全非正常化（1NF）或使用可变数量的列作为内部表/列表（0NF）？

1 个答案: