Подходящий способ денормализации таблиц Кассандры для поддержки аналогичных запросов с дополнительными параметрами - PullRequest
Новая
       23

Подходящий способ денормализации таблиц Кассандры для поддержки аналогичных запросов с дополнительными параметрами

0 голосов
/ 18 ноября 2018

Моя модель данных очень проста. Моделирует посещения веб-страниц.

Так выглядит моя модель посещений (синтаксис схема экспресс-кассандры синтаксис): 

fields: {
    id: {
        type: 'uuid',
        rule: {
            required: true,
            message: 'id is required'
        }
    },
    userId: {
        type: 'int',
        rule: {
            required: true,
            message: 'userId is required'
        }
    },
    dateOfVisit: {
        type: 'timestamp',
        rule: {
            required: true,
            message: 'dateOfVisit is required'
        }
    },
    urlPort: 'int',
    urlHost: {
        type: 'text',
        rule: {
            required: true,
            message: 'urlHost is required'
        }
    },
    urlPath: 'text',
    urlQuery: 'text',
    urlProtocol: {
        type: 'text',
        rule: {
            required: true,
            message: 'urlProtocol is required'
        }
    },
    urlHash: 'text',
    pageTitle: 'text'
},
key: [['id'], 'dateOfVisit'],
clustering_order: {'dateOfVisit': 'desc'}

У меня есть несколько вопросов об этой модели:

Вопрос № 1:

Я почти уверен, что хочу сохранить части URL-адреса вместо того, чтобы хранить весь URL-адрес в виде одной строки, поскольку это позволяет мне легче выполнять запросы на посещения определенного домена, посещения определенного пути в пределах домен, посещения защищенных страниц и посещения незащищенных страниц, ссылки с защищенных страниц на незащищенные (или обратные) и т. д.

Но, было бы лучше сохранить части URL как A) отдельные столбцы или B) как один столбец Map .

Кроме того, мне нужно будет создавать дополнительные таблицы с разными первичными ключами, просто чтобы поддерживать все различные запросы от запросов к различным частям URL?

Вопрос № 2

У меня будет несколько разных способов запросить данные.

  • Получить все посещения всех пользователей
  • Получить все посещения для одного пользователя
  • Получите все посещения в данный день или сгруппированы по часам в течение данного дня
  • Получить все посещения данного домена
  • Подсчет всех посещений данного домена, сгруппированных по пути

Итак, учитывая различные типы запросов, как хранить эту модель?

В настоящее время у меня в основном одни и те же поля, хранящиеся в нескольких таблицах только с разными первичными ключами (одна таблица с просто (id) для поддержки «всех посещений всех пользователей», другая таблица с (id, userId) для поддержки » получить все посещения для определенного пользователя "и т. д.

Такое ощущение, что создается несколько копий данных только для поддержки по существу одного и того же запроса, но с одним дополнительным условием к предложению where.

Есть ли лучший способ смоделировать это?

1 Ответ

0 голосов
/ 18 ноября 2018

По вопросу 1: поскольку компоненты URL-адреса всегда имеют одинаковые ключи (хост, порт, путь и т. Д.), Эффективнее иметь их как отдельные столбцы, а не как карту.Особенно в Cassandra 3 (или грядущей Scylla 3.0), где новый, более эффективный формат файла не требует повторения имен столбцов для каждой строки - но такие повторы будут необходимы для карты (которая, теоретически, может иметь разныеключи в каждом случае).

По вопросу 2: одну вещь, которую вы могли бы сделать вместо того, чтобы самостоятельно обслуживать несколько таблиц (и всегда беспокоиться, если содержимое этих разных таблиц согласованно), вы могли бы использовать функцию Materialized Views (опять же, добавлено в Кассандру 3 и в Сциллу 3), которая поддерживает все эти разные таблицы для вас.Это все еще потребует дополнительного места на диске для всех этих таблиц, но упростит ваше приложение.Другая вещь, которую вы можете сделать, - это использовать вторичные индексы, которые не дублируют все данные, а скорее создают дополнительные таблицы индексов, которые позволяют найти исходные данные в таблице.Например, такая вспомогательная таблица будет использоваться для получения, с учетом URL-пути, списка посещений (ключей к исходной таблице), имеющих этот путь.Но вам не нужно вести эту таблицу самостоятельно - все, что вам нужно сделать, это попросить проиндексировать определенный столбец, и Cassandra будет автоматически поддерживать эту таблицу для вас и использовать ее в запросах, которые ищут определенное значение этого столбца.

...