Моделирование Cassandra Data Struncture для работы в режиме реального времени и поиска для всех? - PullRequest
0 голосов
/ 15 февраля 2020

Мой проект обслуживает как данные в реальном времени, так и прошлые данные. Он работает как канал, поэтому он показывает данные в режиме реального времени через сокет и прошлые данные (если прокрутить вниз) через API REST. Для эффективного получения данных в режиме реального времени я установил дату в качестве ключа раздела, а время - в качестве ключа кластеризации. Для службы реального времени, я думаю, эта структура данных хорошо смоделирована. Но я также должен получить ограниченное количество последних данных (например, нумерацию страниц), которые должны показывать целые данные по запросу. Чтобы обслуживать данные, такие как недавние вызовы API REST 0 ~ 20/20 ~ 40/40 ~ 60 через мой REST-сервер, мой сервер обслуживания данных должен помнить то, что он показал прежде, чтобы загружать следующие 20 данных непрерывно, в качестве закладки. Если бы это было SQL, я бы использовал идентификаторы или страницы и смещения, но я не могу сделать это с Кассандрой. Поэтому я попытался:

SELECT * FROM examples WHERE date<='DATEMARK' AND create_at < 'TIMEMARK' AND entities CONTAINS 'something' limit 20 ALLOW FILTERING;

Но так как дата является ключом раздела, я не могу использовать операцию сравнения>, <. Прошлые данные могут быть созданы очень далеко от сегодняшнего дня. </p>

Могу ли я удовлетворить свои прошлые требования в реальном времени + с Cassandra? Интересно, нужно ли мне создать еще одну БД для доступа к прошлым данным?

Ответы [ 2 ]

1 голос
/ 16 февраля 2020

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

Created_date | Created_time | user_id | Страна | Имя | Упражнение

В этой схеме вы рассматриваете Created_date, create_time, user_id, country в качестве первичного ключа, но вам нужен идентификатор user_id определенной страны. В этом случае, даже если вы рассматривали столбец «Страна» в качестве первичного ключа, запрос нельзя выполнить следующим образом:

«ВЫБОР» из таблицы, где Created_date = '2020-02-14' и страна = ' Индия «разрешить фильтрацию»;

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

Created_date | Страна | Город | Created_time | user_id | Имя | Упражнение

"ВЫБРАТЬ * из таблицы, где create_date = '2020-02-14' и страна = 'Индия'"; Использование этой структуры даст вам очень согласованный результат и вы никогда не столкнетесь ни с какими ошибками. Предположим, вы хотите получить все данные за последние семь дней. В этом случае используйте l oop и просматривайте результаты каждого дня и сохраняйте их в некоторой структуре данных. Надеюсь, вы понимаете.

1 голос
/ 15 февраля 2020

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

...