Cassandra обновляет предыдущие строки после вставки
У меня есть эта схема в кассандре:
create table if not exists
converstation_events(
timestamp timestamp,
sender_id bigint,
conversation_id bigint,
message_type varchar,
message text,
primary key ((conversation_id), sender_id, message_type, timestamp));
И есть тип сообщения со значением разговор_завершен, есть ли способ денормализовать данные, чтобы я мог делать запросы к тем разговорам, которые уже закончились?
Я думал о дополнительном поле, которое может обновляться с помощью триггера, когда в систему попадает сообщение разговора_завершено, имеет ли это смысл?
Ответы 1
В Cassandra вам нужно моделировать данные таким образом, чтобы они отвечали на ваши вопросы. Это не похоже на RDBMS, где вы сначала создаете свою модель, а затем создаете свои запросы. Так что думайте назад...
Когда вы выполняете запрос в cassandra (по большей части...), вам нужно выполнить запрос по первичному ключу, и вы можете использовать ключ(и) кластеризации для фильтрации или выбора диапазонов. отличный пост на нем.
Ваша таблица converstation_events даст вам ответы о разговоре, фильтрацию по отправителю, типу и времени. ** если вы хотите отфильтровать по времени, вы должны включить sender_id и message_type в запрос.
Но вам нужны все разговоры определенного типа, поэтому вам понадобится другая таблица, чтобы ответить на этот запрос. Если вам нужен весь разговор, который есть conversation_ended, вы можете создать вторую таблицу, чтобы сопоставить тип сообщения с разговором, например:
conversation_by_message_type (
message_type varchar,
conversation_id bigint,
timestamp timestamp,
primary key ((message_type), timestamp, conversation_id));
На стороне клиента вам придется добавлять запись в conversation_by_message_type каждый раз, когда вы вставляете событие converstation_events с заданным message_type, которое вы, возможно, захотите найти. У меня есть timestamp в этой таблице, поэтому вы можете сортировать или фильтровать по времени или time и conversation_id.
Чтобы найти все завершенные разговоры, вы можете выполнить такие запросы, как
<ids> = select conversation_id from conversation_by_message_type where message_type = 'conversation_ended'
select * from conversation_events where conversation_id IN (<ids>)
С cassandra вам нужно сначала определить свои запросы (вопросы) и спроектировать свою модель, чтобы иметь возможность отвечать на эти вопросы. Часть ключа раздела первичного ключа определяет, на каком узле находятся ваши данные. Вы хотите воздержаться от сканирования кластеров - поэтому второй индекс, вероятно, не очень хорошая идея. Использование второй таблицы (обычное дело ....), как указано выше, позволит вам делать то, что вы хотите. Вам просто нужно сделать это на стороне клиента
но у меня все еще та же проблема. на стороне клиента idk, когда это сообщение будет из закрытого разговора. Должен ли я добавить поле is_closed: в схему и вставить их в значение false, а затем, когда событие talk_close доберется до системного обновления, is_closed = true, где talk_id = разговор_ид из закрытого события? Имеет ли это смысл? можно так с триггером?
нет... это не имеет смысла. похоже, вы повесили трубку, пытаясь заставить кассандру действовать как что-то вроде MySql. вы не можете фильтровать неключевое поле, за исключением второго индекса. вам нужен индекс conversation_by_message_type для поиска сообщения данного типа. я собираюсь немного расширить свой ответ ..
что мне нужно, так это иметь возможность запрашивать все сообщения, в которых разговор закончился. (например, вариант: выберите * из сообщений, в которых id_сообщения (выберите id_преобразования, где тип_сообщения = «диалог_завершен»); и, поскольку вы не можете сделать это в Кассандре, я подумал добавить еще одно поле в строки, которые обновляются, когда вставляется событие разговора_завершенного, например, 'is_ended' или что-то в этом роде