Расчет количества показов / кликов для большой нагрузки

Question

У нас есть партнерская система, которая подсчитывает миллионы показов / кликов баннера в день.
В настоящее время она записывает в SQL каждое число показов / кликов, которое происходит в режиме реального времени по каждому запросу.

Веб-приложение обслуживает эти запросы.

Мы сталкиваемся с двумя проблемами:

1. Если у нас много одновременных запросовв секунду SQL начинает работать очень усердно для вставки данных Impressons / Clicks и в результате приводит к проблеме № 2.

2. Если в данный момент SQL работает медленно, запросы накапливаются и ожидают в очереди на веб-сервере.В результате веб-приложение работает медленно, и запросы не обрабатываются.

Дизайн, о котором мы думали на высоком уровне:

В настоящее время мы рассматриваем возможность изменения дизайна путем удаления логики записи в SQL из веб-приложения (вместо записи в локальное хранилище) и создания автономного сервиса, который будет считывать данные из локального хранилища и в конечном итоге записывать агрегированные впечатления /Кликает данные (не в режиме реального времени) на SQL в фоновом режиме.

Наши ограничения:

• 10 веб-серверов (с балансировкой нагрузки)
• 1 SQL-сервер

Что вы думаете о предлагаемом дизайне?
Вы бы использовали NoSQL в качестве локального хранилища для каждого веб-сервера?
Предложите свой вариант.

Answer 1

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

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

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

• Очередь в памяти, быстрая, но не защищенная от сбоев.

• Очередь базы данных, имеет смыслесли запись необработанных данных запроса в простую структуру данных выполняется быстрее, чем запись окончательных данных в целевые структуры данных.

• Очереди с избыточностью для покрытия сбоев.

Answer 2

Я с Берндом, но я не уверен насчет использования очереди специально.

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