Почему в Cassandra нормально хранить одни и те же данные в нескольких таблицах?
- Почему в Cassandra одна таблица на запрос?
Моделирование идёт от запросов: эффективен только доступ по ключу партиции, JOIN нет. Поэтому под каждый сценарий — своя таблица с подходящим ключом, и дублирование — норма.
- «Сообщения чата» и «сообщения пользователя» — две таблицы с разными ключами
- Запись в несколько таблиц — batch (logged) для согласованности
- Вторичные индексы и материализованные представления в Cassandra ограниченно полезны
А ещё Место дешевле, чем запросы по всему кластеру
Подробно
Первичный ключ здесь состоит из ключа партиции, определяющего узел, и колонок кластеризации, задающих порядок внутри партиции. Запрос по произвольному полю потребовал бы обхода всех узлов, поэтому такой возможности фактически нет. Отсюда переворот привычной логики: сначала перечисляют запросы, потом проектируют таблицы под них. Дисковое пространство дёшево, а невозможность ответить на запрос — нет. Обратная сторона, о которой нужно сказать честно: согласованность копий обеспечивает приложение — при обновлении надо записать во все таблицы, и промежуточные расхождения возможны. Именно поэтому такой подход хорош для добавляемых данных и хуже для часто изменяемых.
Что хотят услышать
- Почему одна таблица на запрос.
- Как синхронизировать дубли.
- Ограничения вторичных индексов.
Частые ошибки
- Пытаться нормализовать схему и делать соединения на стороне приложения.
- Забывать, что синхронизацию дублей обеспечивает не база, а вы.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✓Запросы эффективны только по ключу, поэтому под каждый сценарий — своя таблица
- ✗Так обеспечивается отказоустойчивость вместо репликации
- ✗Cassandra сама синхронизирует такие таблицы между собой
- ✗Это временный обходной приём, устаревший в новых версиях
Что спросят дальше
- Из чего состоит первичный ключ и как он влияет на распределение?
- Почему вторичные индексы здесь используют с осторожностью?
Разбор темы
- Колоночные БД: wide-column и аналитические
Разница между wide-column (Cassandra) и column-oriented OLAP (ClickHouse), partition/clustering keys, LSM-дерево и зачем хранить по колонкам.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.