Регистрация больших объемов действий в производственном приложении MVC / SQL

Question

Мы являемся счастливыми пользователями платформы ASP.NET MVC и SQL Server, которые в настоящее время используют LINQ-to-SQL.Он хорошо отвечает нашим потребностям благодаря приложению, ориентированному на потребителя, с 1,4 миллионами пользователей и более 2 миллионами активных пользователей в месяц.

Нам давно пора начать регистрировать все действия пользователя (просмотры статей, поиски на нашем сайте и т. Д.), И мы пытаемся найти подходящую архитектуру для этого.

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

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

Мои вопросы: (1) Существует ли асинхронный способ выгрузки условий поиска в удаленное поле?Поддерживает ли LINQ асинхронность для этого?

(2). Вы бы порекомендовали создать кэш, состоящий, скажем, из 1000 элементов (userId, searchTerm, date), регистрирующих в кэш-памяти RAM, и затем периодически сбрасывать их в базу данных?Я предполагаю, что этот метод уменьшит количество открытых / закрытых соединений.

Или я думаю об этом совершенно неправильно?Мы хотели бы найти баланс между простотой реализации и надежностью.

Answer 1

1) Я бы предложил вам создать HttpModule, который "ловит" все поисковые термины, используемые пользователями. Как и где вы будете сбрасывать эту информацию (вы сказали, что будете использовать окно SQL) - это другой вопрос, который выходит за рамки модуля, который должен просто перехватывать команды поиска. Затем вы можете создать компонент, содержащий логин для хранения этой информации, используя асинхронный вызов (или даже компонент третьей части, такой как Log4Net)

2) если вы хотите создать пакетную вставку, кэширующую всю информацию, которая вам нужна для хранения, и в какой-то момент сбросьте ее на SQL, я бы использовал MSMQ или любую другую технологию, поддерживающую Reliability: я думаю, вы хотите потерять всю эту информацию в случае сбоя системы и т. д.

Answer 2

1) Конечно, вы можете, есть разные решения для достижения этой цели. Linq не тот инструмент, который вам нужен. 2) Не должно быть никакого существенного улучшения, делая это, «регистрация» будет запущена только тогда, когда будет выполнен поиск. В итоге вы получите два звонка вместо одного, ничего страшного.

Рекомендуется использовать AOP

Вы можете создать чистый и отдельный слой для ведения журнала, используя Postsharp (хотя есть и другие альтернативы). Затем вы будете украшать свои действия требуемым атрибутом ведения журнала, только когда вам нужно отследить, что передано действию. Основные преимущества этого подхода:

• Логика ведения журнала не находится внутри вашего кода (вам не нужно изменять код методов), но выполняется до / после вашего метода.
• Чистое отделение Аспекта от целевого метода.
• Вы можете легко включать / выключать аспекты

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