Как построить масштабируемую статистическую систему?

Question

Предположим, у меня есть таблица с именем products, и я хочу знать, сколько раз продукты искали, просматривали и покупали. Я хочу также знать , когда продукты были просмотрены, просмотрены и куплены.

Мой первый подход должен был составить таблицу с product_id, поле, указывающее, если элемент был 0=searched, 1=viewed и 2=purchased и другое поле поддержания'datetime' события, так что я могу фильтровать по времени.

Это работает очень хорошо, но НЕ масштабируется. Если у меня есть 50 000 продуктов в базе данных и 1000 пользователей, каждый из которых выполняет 5 запросов каждый день, то у меня есть 50,000 * 1,000 * 5 = 250'000,000 новые записи в день, поэтому это не выглядит идеальным решением для меня.

У меня есть несколько идей о том, как улучшить это, но я бы очень хотел прочитать о лучших способах, так как я не доволен своим.

Answer 1

Сохраните эти данные (хранение будет дешевым и относительно масштабируемым, если вам не нужно его получить).

Составьте то, что вам интересно.

Как только вы узнаете, какие статистические данные вам интересны, вы можете сгенерировать их с помощью агрегатов минимального промежутка времени. Чтобы взять простой пример: если вас интересует общий объем продаж для товара, но только на ежегодной основе, вы можете агрегировать «продажи в 2010 году», «продажи в 2009 году». По возможности работайте с этими агрегатами.

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

Answer 2

* Если у меня есть 50 000 продуктов в базе данных и 1000 пользователей, каждый из которых выполняет 5 запросов каждый день, то у меня есть 50 000 * 1000 * 5 = 250 000 000 новых записей в день, поэтому это не похоже на идеальное решение для меня. *

Этот расчет представляется неправильным для меня. Почему вы хотите включать 50000 повторений для каждого пользователя каждый день? Даже если мы рассмотрим примеры/продукты/пользователей, у вас будет одна главная таблица для всех продуктов, и когда пользователь действительно просмотрит продукт, у вас будет одна запись со следующими подробностями.

create table product_views 
(
product_id number, 
user_id varchar2(50), 
view_time date); 

Колонки PRODUCT_ID, user_id будет ссылаться на продукт и пользователей родительских таблиц, соответственно, которые будут иметь подробные описания одного и того же.

Итак, в приведенном вами сценарии будет 500 поисковых запросов (по 1000 пользователей и по 5 поисковых запросов), и в этой таблице будет 5000 вставок.