Правильный способ создания приложения в реальном времени с Cassandra - PullRequest
Новая
       46

Правильный способ создания приложения в реальном времени с Cassandra

3 голосов
/ 22 сентября 2019

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

Клиент подключается к веб-сокету, вставляет сообщение, сообщение сохраняется в базе данных, а затем сообщение отправляется пользователям, если запись в базу данных успешна. 

const cassandra = require('cassandra-driver');
const client = new cassandra.Client({ contactPoints: ['127.0.0.1'], 
localDataCenter: 'datacenter1' });

const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 3000 });

wss.on('connection', function connection(ws) {
  ws.on('message', function incoming(message) {

   //Insert message into Cassandra DB
   //Send message to other users if record to database with a consistency 
      level of one is successful
   //Then send messages to users connected to the websocket in chatroom

});

Редактировать: Я также не могу найти какие-либо учебные пособия на что-то вроде этого, поэтому, если у вас есть какие-либо ссылки, пожалуйста, поделитесь

Ответы [ 2 ]

1 голос
/ 25 сентября 2019

Плюсы Кассандры для ваших целей.

  1. Кассандра хороша в обработке записей с высокой нагрузкой благодаря использованию деревьев LSM.
  2. Cassandra относительно относительно прост в обслуживании в качестве распределенного хранилища.С одной стороны, в отличие от СУБД, Cassandra имеет репликацию входящих сообщений, уровни согласованности и т. Д. С другой стороны, в отличие от узлов Hbase Cassandra, такие же ранги (без мастеров, серверов регионов и т. Д.).

Минусы Cassandra.

  1. Если высокая нагрузка отсутствует, Cassandra вызывает огромные накладные расходы по сравнению с одноузловым решением СУБД, как с точки зрения потребления оборудования (особенно ОЗУ), так и с точки зрения удобства обслуживания.

  2. Кассандра в распределенном режиме имеет так называемый eventual consistency.В двух словах это звучит нормально, но иногда возникают проблемы с упорядочением строк, которые могут иметь решающее значение для истории чата.Вот ссылка на старую статью https://aphyr.com/posts/299-the-trouble-with-timestamps, но только для объяснения общей идеи.

  3. Вы ограничены исходной моделью данных.Любые запросы на чтение с предложениями where, включающими поля, отсутствующие в первичном ключе или ключе кластеризации, не выполняются.Поддержка SQL очень плохая, с ограничением любых запросов агрегации и т. Д.

1 голос
/ 25 сентября 2019

Нет простого ответа на ваш вопрос, и не очень понятно, о чем идет речь.«Если запись в БД успешна» не так просто в контексте распределенных систем, как Cassandra, потому что вы можете иметь много копий ваших данных.Это всегда компромисс между согласованностью данных и доступностью.Прежде всего вам необходимо понять теорему CAP перед использованием Cassandra.

Я не уверен, что приложение чата требует строгой согласованности, но было бы хорошо иметь 2 или 3 репликиданных.В случае с кассандрой вы можете выбрать более подходящий уровень консистенции .Я думаю, что для сеансов чата это может быть ONE или ANY, в этом случае Csaandra обеспечит непротиворечивую согласованность, но у вас будет больше доступности и производительности по сравнению с более «сильными» уровнями согласованности.

...