Стратегия сохранения данных об использовании приложений для анализа и статистики - PullRequest
Новая
       16

Стратегия сохранения данных об использовании приложений для анализа и статистики

0 голосов
/ 25 марта 2020

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

Краткий обзор системы: веб-приложение C# с двумя типами пользователей: читателями и издателями. Издатели загружают документы в разных категориях, и Читатели могут открывать / загружать эти документы. Они также могут искать Документы по категориям и подписываться на документы в разных категориях.

Цель текущего проекта - начать сбор данных об использовании системой Readers, что они ищут, что они читают / загрузить и предоставить сводные данные для издателей.

Мы хотим сохранить данные о каждом поиске, выполняемом Читателями, чтобы ответить на вопросы типа «Сколько Читателей отфильтровало поиск с категорией X или Y»?

Мы также хотим иметь возможность сообщать агрегированные данные издателям и сообщать им: «Ваш документ появился за X запросов в течение последнего месяца», «X человек открыли документ Z за последний месяц».

Я пытаюсь выяснить, как подойти к этой проблеме, вот несколько идей

  • Мы могли бы сохранить каждый поиск и его фильтры как запись в базе данных.
  • При отображении результата поиска мы можем сохранить запись в базе данных, чтобы знать, что документ X был включен в результат поиска.
  • Мы также можем сохранять записи таким же образом, когда Reader просматривает / загружает документ.

Если бы мы реализовали вышеуказанную стратегию, это означало бы, что нам придется много писать. Для страницы результатов поиска я думаю что-то вроде 21 новой записи - одна запись для подробностей о поисковом запросе и 20 записей для каждого «попадания» в документ).

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

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

  1. Я думаю, я в правильном направлении? Что-то пропустили? Или как я мог подойти к этому? Любое рекомендуемое чтение? Шаблоны или практики?
  2. Если вышеприведенный подход является подходящим, будет ли целесообразным хранить его на ie SQL Сервер? Я немного обеспокоен этим, поскольку не хочу, чтобы база данных была постоянно занята написанием этих записей статистики. Есть ли другое хранилище данных, которое было бы лучше?

1 Ответ

0 голосов
/ 25 марта 2020

Ну, это звучит как классический c чехол для RabbitMq. Net. RabbitMq идеально подходит для обработки очень большого количества событий (для обработки в очередях), когда вы действительно не хотите сохранять все эти строки в БД. В конце концов, все, что вам нужно, это сохранить какой-то куб данных (какой-то куб OLAP). Это намного меньше данных, чем исходные строки. Чтобы привести простой пример - предположим, у вас есть 50 000 запросов в день, и каждый из них производит в среднем 20 просмотров, вы просматриваете 1 миллион строк в день. Но у вас есть только 1000 издателей, каждый из которых, скажем, 50 публикаций. Это всего 50000 строк. И не на один день. На все дни. Единственное, что будет расти, это общее количество попаданий (обновления в этих строках). Вот потрясающее c руководство по RabbitMq. Net - как практическое, так и теоретическое

На сегодняшний день лучший курс по RabbitMq, который я когда-либо видел, - и он бесплатный

...