моделирование Cassandra- данных для UserProfilie

Question

У меня есть модель пользователя, имеющие атрибуты, следующие: -

class User(Model): 
    user_id = columns.Integer(primary_key=True) 
    username = columns.Text() 
    email = columns.Text() 
    fname = columns.Text() 
    lname = columns.Text() 
    age = columns.Text() 
    state = columns.Text() 
    city = columns.Text() 
    country = columns.Text() 
    gender = columns.Text() 
    phone = columns.Text() 
    school_name = columns.Text() 
    created_at = columns.Text() 
    race = columns.boolean() 

Это моя нормальная модель РСУБД. Мои запросы являются следующим: -

1) Get all users with city = 'something' 

2) Get a user with email = 'something' 

3) Get a user with username = 'something' 

4) Get all users with phones IN ('something') 

5) Get all users with state = 'something' 

6) Get all users with age > something 

7) Get all users with gender = 'something' 

8) Get all users with race = 'something' 

9) Get count(*),school_name users Group By schoolname 

10) Get all users with created_date > 'something' LIMIT 1000 

11) Get all users with username IN ('something') AND age IN ('something') AND phone IN ('something') AND state IN ('something') AND so on LIMIT 1000 

я могу получить вышеуказанные результаты для запросов с простыми запросами на выборку в РСУБДЕ, но проблема заключается в Кассандре.

Поскольку для получения результатов для вышеуказанных запросов в Кассандре рекомендуется иметь другую модель для каждого запроса, что ускорит возможности чтения. В этом дне и возрасте диск намного дешевле, чем раньше. При этом я понимаю, что не всегда легко просто бросать больше диска в проблему. Большая проблема, которую я вижу, заключается в настройке уровня DAO вашего приложения, чтобы поддерживать 10 разных таблиц в синхронизации. (Кроме того, мой внутренний инстинкт не убежден, что у вас 10 моделей для разных запросов.: P)

Может ли кто-нибудь объяснить мне подходящую модель в Кассандре, чтобы получить результат для этих запросов?

PS: Действия над указанной моделью могут быть прочитаны/записаны/обновлены/удалены. Запрос 11 - самый важный вопрос.

Самое важное - сделать эти запросы очень быстрыми на больших объемах данных, учитывая, что информация об определенном пользователе может быть обновлена.

Answer 1

Вы столкнулись с настоящим ограничением Кассандры: если вы обязательно поедете с Кассандрой, вы необходимо следовать «Правилам Кассандры». Среди них есть

• Денормализовать
• Выбрать индексы благоразумно

Итак, давайте начнем. Каждый пользователь должен иметь уникальный идентификатор, имя пользователя, адрес электронной почты и телефон. Это означает, что эти столбцы не являются хорошим кандидатом для индексирования (read here why), поэтому денормализация является правильным способом.

Из ваших запросов вы будете иметь user_by_username, user_by_email и user_by_phones. Вы можете подумать, что повторение данных каждый раз может быть обременительным с точки зрения обновления и использования диска: поэтому вы можете иметь компромисс, создавая каждый из них, содержащий в качестве значения только идентификатор пользователя. е.г:

user_email  | user_id 
--------------+------------------- 
some@thing.com | 123-456-7aa |  
girl@hello.org | efg-123-ghi | 

В другой таблице внутри КС нужна таблица, которая по идентификатору будет извлекать всю информацию относительно пользователя. Это позволит решить update problem, если вам нужно обновить адрес электронной почты или телефон, вы можете обновлять только пары таблиц вместо N. Темная сторона заключается в том, что вам нужно выполнить два запроса, чтобы иметь свои данные.

Продолжим.

state, gender и race являются хорошим кандидатом для индексации по следующим причинам:

1. Низкая Cardinality
2. Многие строки будут содержать эти значения

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

select * from users where age > xyz 

Этот вид запроса не допускается в Кассандре, так как вы должны выполнить ! «Равно» операции на кластеризацию часть. Для этого вам нужно «упорядочить» пользователей каким-то общим ключом: например, состояние или «группа состояний» - это означает, что для того, чтобы знать всех пользователей с определенным возрастом, вам придется запрашивать каждый раздел.

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

НТН,
Карло

Answer 2

Возможно, самым простым способом является использование Datastax Enterprise с опцией Search (Solr) или Analytics (Spark). Вы можете скачать его для тестирования с www.datastax.com бесплатно. Пока ваш SLA для данных, доступных для запроса, составляет более 1 секунды, индексы lucene должны иметь возможность обрабатывать эти разнообразные параметры поиска.

Чем больше вопрос, почему вы хотите использовать Кассандру здесь? И что вы подразумеваете под большими объемами данных? Как правило, Cassandra лучше всего обслуживается, когда ваше приложение имеет требования к чтению и записи с малой задержкой, возможность репликации на многие серверы и многие центры обработки данных и имеют нулевое время простоя. Это обычно не требуется в хранилище данных/хранилище или аналитической базе данных, которое по типу запросов и вашей потребности сделать это на «Большие объемы данных», похоже, указывает на это. Вы не хотите, как правило, вводить более 1 - 3T данных на узел Кассандры, хотя есть некоторые выбросы ...