Модель данных Cassandra для простого приложения обмена сообщениями

Я пытаюсь узнать Кассандру и всегда найти лучший способ-начать с создания очень простого и небольшого приложения. Поэтому я создаю базовое приложение для обмена сообщениями, которое будет использовать Cassandra в качестве бэк-энда. Я хотел бы сделать следующее:

• пользователь создаст учетную запись с именем пользователя, электронной почтой и паролем. Этот электронной почты и пароль могут быть изменены в любое время.
• пользователь может добавить другого пользователя в свой контакт. Пользователь добавит ля контакт путем поиска их имени пользователя или электронной почты. Контакты не нужны взаимно то есть, если я добавляю пользователя в мой контакт, я не нужно ждать, пока они примут / одобрят что-либо, как в Facebook.
• сообщение отправляется от одного пользователя другому пользователю. Отправитель должен иметь возможность видеть сообщения, которые они отправили (упорядоченные по времени) и сообщения, которые были отправлены им (упорядоченные по времени). Когда пользователь открывает приложение, которое мне нужно проверить базу данных для любых новых сообщений для этого пользователь. Я также нужно отметить, если сообщение было прочитано.

поскольку я пришел из мира реляционных баз данных, моя реляционная база данных будет выглядеть примерно так:

UsersTable
    username (text)
    email (text)
    password (text)
    time_created (timestamp)
    last_loggedIn (timestamp)
------------------------------------------------ 
ContactsTable
    user_i_added (text)
    user_added_me (text)
------------------------------------------------     
MessagesTable
    from_user (text)
    to_user (text)
    msg_body (text)
    metadata (text)
    has_been_read (boolean)
    message_sent_time (timestamp)

прочитав пару учебников Кассандры, я подумал о том, как смоделировать базу данных. Моя главная задача-очень эффективно моделировать базу данных. Поэтому я стараюсь избегать таких вещей, как вторичные индексы и т. д. Это моя модель до сих пор:

CREATE TABLE users_by_username (
    username text PRIMARY KEY,
    email text,
    password text
    timeCreated timestamp
    last_loggedin timestamp
)

CREATE TABLE users_by_email (
    email text PRIMARY KEY,
    username text,
    password text
    timeCreated timestamp
    last_loggedin timestamp
)

для распространения данные равномерно и читать минимальное количество перегородок (надеюсь только один) я могу найти пользователя по его имени или электронной почте. Недостатком этого, очевидно, я удваиваю свои данные, но стоимость хранения довольно дешева, поэтому я считаю, что это хороший компромисс вместо использования вторичных индексов. Последний вход в систему также должен быть записан дважды, но Кассандра эффективна при записи, поэтому я считаю, что это хороший компромисс.

для контактов я не могу придумать ни одного другой способ смоделировать это, поэтому я смоделировал его очень похожим на то, как я бы в реляционной базе данных. Это довольно денормализованный дизайн, который должен быть хорош для производительности в соответствии с книгами, которые я прочитал?

CREATE TABLE "user_follows" (
  follower_username text,
  followed_username text,
  timeCreated timestamp, 
  PRIMARY KEY ("follower_username", "followed_username")
);

CREATE TABLE "user_followedBy" (

  followed_username text,
  follower_username text,
  timeCreated timestamp,
  PRIMARY KEY ("followed_username", "follower_username")
);

Я застрял на том, как создать эту следующую часть. Для обмена сообщениями я думал об этой таблице, поскольку она создала широкие строки, которые позволяют упорядочивать сообщения. Мне нужно сообщение, чтобы ответить на два вопроса. Он сначала должен иметь возможность показать пользователю все сообщения, которые они иметь, а также иметь возможность показать пользователю сообщения, которые являются новыми и непрочитанными. Это базовая модель, но я не уверен, как сделать ее более эффективной?

CREATE TABLE messages (
    message_id uuid,
    from_user text,
    to_user text,
    body text,
    hasRead boolean,
    timeCreated timeuuid,
    PRIMARY KEY ((to_user), timeCreated )
) WITH CLUSTERING ORDER BY (timeCreated ASC);

Я также рассматривал использование таких вещей, как статические столбцы, чтобы "склеить" пользователя и сообщения, а также наборы для хранения контактных отношений, но из моего узкого понимания до сих пор способ, который я представил, более эффективен. Я спрашиваю, есть ли идеи по повышению эффективности этой модели, есть ли лучшие практики делайте то, что я пытаюсь сделать, или если есть какие-то скрытые проблемы, с которыми я могу столкнуться с этим дизайном?

в заключение, я пытаюсь моделировать вокруг запросов. Если бы я использовал базы данных отношений, это были бы по существу запросы, на которые я хочу ответить:

To Login:
SELECT * FROM USERS WHERE (USERNAME = [MY_USERNAME] OR EMAIL = [MY_EMAIL]) AND PASSWORD = [MY_PASSWORD];
------------------------------------------------------------------------------------------------------------------------
Update user info:
UPDATE USERS (password) SET password = [NEW_PASSWORD] where username = [MY_USERNAME];
UPDATE USERS (email) SET password = [NEW_PASSWORD ] where username = [MY_USERNAME];
------------------------------------------------------------------------------------------------------------------------ 
To Add contact (If by username):
INSERT INTO followings(following,follower)  VALUES([USERNAME_I_WANT_TO_FOLLOW],[MY_USERNAME]);
------------------------------------------------------------------------------------------------------------------------
To Add contact (If by email):
SELECT username FROM users where email = [CONTACTS_EMAIL];
    Then application layer sends over another query with the username:
INSERT INTO followings(following,follower)  VALUES([USERNAME_I_WANT_TO_FOLLOW],[MY_USERNAME]);
------------------------------------------------------------------------------------------------------------------------
To View contacts:
SELECT following FROM USERS WHERE follower = [MY_USERNAME];
------------------------------------------------------------------------------------------------------------------------
To Send Message:,
INSERT INTO MESSAGES (MSG_ID, FROM, TO, MSG, IS_MSG_NEW) VALUES (uuid, [FROM_USERNAME], [TO_USERNAME], 'MY MSG', true);
------------------------------------------------------------------------------------------------------------------------
To View All Messages (Some pagination type of technique where shows me the 10 recent messages, yet shows which ones are unread):
SELECT * FROM MESSAGES WHERE TO = [MY_USERNAME] LIMIT 10;
------------------------------------------------------------------------------------------------------------------------
Once Message is read:
UPDATE MESSAGES SET IS_MSG_NEW = false WHERE TO = [MY_USERNAME] AND MSG_ID = [MSG_ID];

Ура