Мы используем Кассандру для хранения счетчиков времени.
Таблицы будут содержать события, подобные этому:
{
ServerTimestamp, // unix timestamp when it was analized
GeneratedTimestamp, // unix timestamp when it was generated
CounterType, // short int determining what is the type of event here
CounterId, // unique for event,
City,
Region,
ShopId,
Value // some monetary value in bigint
}
Основные допущения:
- Мы разрабатываем эту таблицу для отчетности.
- Мы должны провести все мероприятия в течение 5 лет
- Отчеты обычно создаются за периоды от 1 до 30 дней.
- Отчеты могут фильтроваться по CounterType, City, Region и ShopId
- Сама запись не должна превышать 1000 записей в секунду.
Моей первой мыслью было создание двух таблиц, разделенных по дневной части отметки времени (например, yyyyMMdd):
First table with key: (ServerTimestampDay), ServerTimestamp, CounterId
Second table with key: (GeneratedTimestampDay), GeneratedTimestamp, CounterId
Может ли запись быть проблемой здесь? (Я знаю, что все будет записано в один узел из-за дневного ключа раздела).
Что мне делать с остальными полями? (CounterType, City, Region и ShopId).
Сначала я подумал о том, чтобы поместить их в ключ разделения ... но наиболее распространенным поведением будет поиск значений 1, 2 или ВСЕХ для этих полей.
У нас будет около 1000 магазинов, поэтому размещение всех из них в запросе (или запуск одного запроса для каждого ключа раздела день / shopId или комбинация день / город или подобное будет кошмаром).
На данный момент мне нужны такие отчеты:
(каждый раз, когда вы выбираете Город, Регион, ShopId - это опция множественного выбора)
Набор фильтров отчета 1:
ServerTimestamp (from-to)
CounterType = [1,2,3]
SiteId = [...]
Набор фильтров Report 2:
GeneratedTimestamp (from-to)
CounterType = [1,3]
City = [...]
SiteId = [...]
Я знаю, что это много информации, но я хотел быть максимально ясным о своих мотивах. Большое спасибо за помощь!