用于聊天存档的 Cassendra 模式设计建议

Question

我已经阅读了这篇文章，这是我从中获得的模式。这对我维护用户状态的应用程序很有帮助，但是如何扩展它以维护一对一的聊天存档和用户之间的关系，关系意味着人们属于我的特定组。我对此很陌生，需要一种方法。

要求 ：

我想将用户-用户之间的消息存储在一个表中，每当用户想要加载用户的消息时，我想检索它们并将其发送给用户。我想在用户请求时检索来自不同用户的所有消息。并且还想存储用户类。我的意思是例如 user1 和 user2 属于“家庭” user3，user4，user1 属于朋友等等......这个组可以是用户给的自定义名称。

这是我尝试过的

CREATE TABLE chatarchive (
   chat_id uuid PRIMARY KEY,
   username text,
   body text
)

CREATE TABLE chatseries (
username text,
    time timeuuid,
    chat_id uuid,
    PRIMARY KEY (username, time)
) WITH CLUSTERING ORDER BY (time ASC)

CREATE TABLE chattimeline (
    to text,
username text,
    time timeuuid,
    chat_id uuid,
    PRIMARY KEY (username, time)
) WITH CLUSTERING ORDER BY (time ASC)

以下是我目前拥有的架构，

CREATE TABLE users (
   username text PRIMARY KEY,
   password text
)    

CREATE TABLE friends (
    username text,
    friend text,
    since timestamp,
    PRIMARY KEY (username, friend)
)

CREATE TABLE followers (
    username text,
    follower text,
    since timestamp,
    PRIMARY KEY (username, follower)
)

CREATE TABLE tweets (
    tweet_id uuid PRIMARY KEY,
    username text,
    body text
)
CREATE TABLE userline (
    username text,
    time timeuuid,
    tweet_id uuid,
    PRIMARY KEY (username, time)
) WITH CLUSTERING ORDER BY (time DESC)

CREATE TABLE timeline (
    username text,
    time timeuuid,
    tweet_id uuid,
    PRIMARY KEY (username, time)
) WITH CLUSTERING ORDER BY (time DESC)

Answer 1

不久前我创建了一个聊天程序，可在 github 上找到

https://github.com/akc42/MBChat

它具有您正在谈论的一些特征。尤其是它既提供了人们可以进入并以开放方式讨论的房间，也提供了几个人可以聚在一起讨论事情的耳语箱。

当人们进入一个房间，或加入耳语时，他们可以看到一点过去的谈话。

在进一步解释模式之前，值得指出的是，我有两种验证用户的方法。这是因为正常使用是 smf 论坛的聊天扩展 - 因此用户已经登录到论坛，并且他们携带相同的身份进行聊天（并且具有一些源自论坛成员组的特征）。然而，聊天可以在没有论坛的情况下单独使用，有一个单独的用户数据库可以在登录阶段进行查询，以识别用户及其能力。

首先，该数据库位于存储库中的 inc/user.sql 中。

BEGIN;

CREATE TABLE users (
  uid integer primary key autoincrement NOT NULL,
  time bigint DEFAULT (strftime('%s','now')) NOT NULL,
  name character varying NOT NULL,
  role text NOT NULL DEFAULT 'R', -- A (CEO), L (DIRECTOR), G (DEPT HEAD), H (SPONSOR) R(REGULAR)
  cap integer DEFAULT 0 NOT NULL, -- 1 = blind, 2 = committee secretary, 4 = admin, 8 = mod, 16 = speaker 32 = can't whisper( OR of capabilities).
  password character varying NOT NULL, --raw password
  rooms character varying, -- a ":" separated list of rooms nos which define which rooms the user can go in
  isguest boolean DEFAULT 0 NOT NULL
);
CREATE INDEX userindex ON users(name);
-- Below here you can add the specific users for your set up in the form of INSERT Statements


-- This list is test users to cover the complete range of functions. Note names are converted to lowercase, so only put lowercase names in here
INSERT INTO users(uid,name,role,cap,password,rooms,isguest) VALUES
(1,'alice','A',4,'password','7',0),
(2,'bob','L',3,'password','8',0),
(3,'carol','G',2,'password','7:8:9',0),
(4,'dave','H',0,'password','10',0),
(5,'eileen','R',8,'password','',0),
(6,'fred','R',16,'password','',0),
(7,'gail','R',0,'password','',0),
(8,'harry','R',0,'password','',1),
(9,'irene','R',32,'password','',0);




COMMIT;
VACUUM;
-- set it all up as Write Ahead Log for max performance and minimum contention with other users.
PRAGMA journal_mode=WAL;

但是，一旦他们登录，这些凭据就会复制到正在使用的实际聊天数据库中

以下是可能对您有所帮助的架构元素（取自该存储库的 data/chat.sql 文件）。

首先是开放的房间（实际上并非所有房间都是平等的，有一些限制 - 请参阅评论）

CREATE TABLE rooms (
  rid integer primary key NOT NULL,
  name varchar(30) NOT NULL,
  type integer NOT NULL -- 0 = Open, 1 = meeting, 2 = guests can't speak, 3 moderated, 4 members(adult) only, 5 guests(child) only, 6 creaky door
) ;

INSERT INTO rooms (rid, name, type) VALUES 
(1, 'The Forum', 0),
(2, 'Operations Gallery', 2), --Guests Can't Speak
(3, 'Dungeon Club', 6), --creaky door
(4, 'Auditorium', 3), -- Moderated Room
(5, 'Blue Room', 4), -- Members Only (in Melinda's Backups this is Adults)
(6, 'Green Room', 5), -- Guest Only (in Melinda's Backups this is Juveniles AKA Baby Backups)
(7, 'The Board Room', 1), --various meeting rooms - need to be on users room list
(8, 'Marketing', 1),
(9, 'Engineering',1),
(10, 'IT Dept', 1),
(11, 'Finance', 1);

现在用户自己是从以前的数据库（或从论坛和有一个匹配表）结转的

CREATE TABLE users (
  uid integer primary key NOT NULL,
  time bigint DEFAULT (strftime('%s','now')) NOT NULL,
  name character varying NOT NULL,
  role char(1) NOT NULL default 'R',
  rid integer NOT NULL default 0,
  mod char(1) NOT NULL default 'N',
  question character varying,
  private integer NOT NULL default 0,
  cap integer NOT NULL default 0,
  rooms character_varying 
);

但这还不是全部 - 我还有另一个概念 - 即对话中的参与者- 对话只是一个 ID。

CREATE table wid_sequence ( value integer);
INSERT INTO wid_sequence (value) VALUES (1);

CREATE TABLE participant (
  uid integer NOT NULL REFERENCES users (uid) ON DELETE CASCADE ON UPDATE CASCADE,
  wid integer NOT NULL,
  primary key (uid,wid)
);

没有一个wid_sequence 表，当有人创建新对话时，我的代码会手动递增 - （我称之为耳语盒，但有时它会变成我所说的私人房间），然后在对话进行时参与者表中的记录到位。

最后，我有一个消息存档 - 我可以在以后参考和回放（当有人进入房间时，最近消息的简短列表，或者具有秘书能力的人可以进入房间并获得打印输出整个对话——例如会议纪要）。

我认为这张表是您在问题中提到的档案

这个模式是

CREATE TABLE log (
  lid integer primary key,
  time bigint DEFAULT (strftime('%s','now')) NOT NULL,
  uid integer NOT NULL,
  name character varying NOT NULL,
  role char(1) NOT NULL,
  rid integer NOT NULL,
  type char(2) NOT NULL,
  text character varying
);

这里的重要项目是类型字段。它本质上是动作和对话的重播，因此我们还可以重播开始的新对话（其中rid然后映射到从wid_sequence 创建的wid），以及人们进出房间等。

我相信这会让您知道如何继续。随意检查我在 github 上的代码，并提出您可能对它有任何疑问。

作为后记，有一个我没有提到的表格叫做“参数”，它控制着很多事情的工作方式。其中之一是是否需要使用加密。进入这个答案超出了这个答案的范围 - 因为它相当复杂 - 但是您可能需要考虑您希望私人对话的私密性以及它们是否应该加密存储在您的档案中。