2015-02-23 2 views
1

Я пытаюсь использовать Cassandra с простыми CRUD-операциями и не понимаю, как мне моделировать данные.CRUD in Cassandra

Допустим, нам нужно управлять простыми данными пользователя:

UserId | Email | Name

Мы хотим, чтобы иметь возможность получить информацию либо UserId или Email. Также мы хотим иметь возможность изменять информацию о пользователе, то есть Email и Name.

Это приводит меня к дилемме: по запросу Email, я должен добавить его в PRIMARY KEY. Но если я его проиндексирую, я не смогу ОБНОВИТЬ его.

Как изменить модель данных или индексирование, чтобы иметь возможность ОБНОВЛЯТЬ данные?

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

+0

«Вторичные индексы зла в Кассандре» - Любите это !!! – Aaron

ответ

3

Действительно, вы не должны использовать вторичные индексы, если вам не обязательно. Но если вам нужно искать по электронной почте, вы можете создать другую таблицу с двумя столбцами - Email и UserId. Первичный ключ будет Email, и именно так вы будете искать UserId по Email. Подумайте об этом как о индексе в традиционной реляционной базе данных. Поскольку значение Email должно быть уникальным, подход к таблице поиска должен быть более эффективным, чем вторичный индекс.

Как только вы нашли UserId по Email, вы можете использовать его в запросах к основному столу.

+0

Спасибо, Роман! Я думал об одном и том же решении, но факт многочисленных запросов заставляет меня сомневаться в этом. Является ли это «идиоматическим» способом решения ситуации, когда вам нужно редактировать и искать одни и те же данные, или это обходное решение для конкретной задачи, и я должен лучше изменить задачу (например, использовать события для операций CUD и агрегированные данные для чтения)? – Dima

+0

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

+0

Листовой уровень (опечатка) –