Продолжайте отвечать на вопросы водных друзей.
абстракция проблемы:
(1) Система членства пользователей;
(2) Пользователи будут иметь поток оценок, и статистика оценок будет выполняться один раз в месяц, а для участников с разными уровнями оценок будет выполняться различная бизнес-обработка;
Предположения о данных:
(1) ПредположениеПользовательНа уровне 100 Вт;
(2) ПредположениеСреднее количество пользователей в день1 проточной воды, то есть ежедневное увеличение объема данных проточной воды находится на уровне 100 Вт, а ежемесячная новая проточная вода находится на уровне 3 кВт.Объем текущих данных за 3 месяцана уровне миллиарда;
Общие решения:
При задании на время он рассчитывается один раз в первый день каждого месяца.
//(1) Запросить всех пользователей
uids[] = select uid from t_user;
//(2) Обходим каждого пользователя
foreach $uid in uids[]{
//(3) Запрос потока оценок пользователя в течение 3 месяцев
scores[]= select score from t_flow
где uid=$uid и time=[в течение 3 месяцев];
//(4) Проходим по дробному конвейеру
foreach $score in scores[]{
//(5) Подсчитаем общий балл
sum+= $score;
}
//(6) Делаем бизнес-обработку в соответствии с оценкой
switch(sum)
Апгрейд и даунгрейд, выдача купонов, выдача вознаграждений;
}
В чем проблема с запланированным заданием, которое выполняется раз в месяц?
Объем вычислений огромен, объем обрабатываемых данных огромен, и это занимает много времени, по словам водного друга, это занимает 1-2 дня.
Голос за кадром: пользователи уровня 100 Вт во внешнем контуре; поток уровня 9 кВт во внутреннем цикле; для обработки бизнес-данных требуется 10 взаимодействий с базой данных.
Возможна ли многопоточная параллельная обработка?
Да, конвейерная обработка для каждого пользователя не связана.
Перейдите на многопоточную параллельную обработку, например разделение по пользователям, какие проблемы возникнут?
Каждый поток должен получить доступ к базе данных для бизнес-обработки, и база данных может не справиться с этим.
таких вопросовНаправление оптимизацииДа:
(1) Одни и те же данные уменьшают количество повторных вычислений;
(2) Распределить вычислительное время ЦП и попытаться рассредоточить обработку вместо централизованной обработки;
(3) Уменьшить объем данных для одного расчета;
Как уменьшить количество повторных вычислений для одних и тех же данных?
Как показано на рисунке выше, предполагается, что каждый квадрат представляет собой данные о частичном расходе за 1 месяц (около 3 кВт).
При расчете в конце марта необходимо запросить и рассчитать данные 9 кВт за три месяца: январь, февраль и март;
При расчете в конце апреля необходимо запросить и рассчитать данные 9 кВт за три месяца: февраль, март и апрель;
…
Вы обнаружите, что данные за февраль и март (розовые части) многократно запрашивались и вычислялись.
_Голос за кадром: _Для этого бизнеса ежемесячные данные будут рассчитаны 3 раза.
новыйСводная таблица ежемесячных потоков баллов, каждый разРассчитать только приращение текущего месяца:
flow_month_sum(month, uid, flow_sum)
(1) В конце каждого месяца подсчитывается только оценка текущего месяца, количество данных уменьшается до 1/3, а время также сокращается до 1/3;
(2) В то же время сложите проточную воду за первые 2 месяца, чтобы получить общий балл за последние 3 месяца (это действие почти не занимает времени);
Голос за кадром: Порядок величины таблицы такой же, как объем данных пользовательской таблицы, уровень 100w.
Таким образом, каждый частичный поток будет рассчитываться только один раз.
Как распределить вычислительное время процессора и уменьшить объем данных для одного расчета?
Бизнес-требование — пересчитывать балл раз в месяц, но расчет централизован в месяц, объем данных слишком большой, и занимает слишком много времени, поэтому расчет можно распределить на каждый день.
Как показано на рисунке выше, сводная таблица ежемесячных кредитных потоков была обновлена до сводной таблицы ежедневных кредитных потоков.
Если централизованный расчет раз в месяц разбить на 30 распределенных расчетов, а объем данных для каждого расчета сократить до 1/30, то обработка займет всего несколько десятков минут.
Даже если он рассчитывается один раз в час, количество данных для каждого расчета может быть уменьшено до 1/24, и обработка каждый раз занимает всего несколько минут.
Хотя время сокращается, в конце концов, это задача на время.Можно ли рассчитать в реальном времениА как насчет потока очков?
Каждый день добавляется только 100 Вт очков, а «сводка ежедневного потока очков» может накапливаться и рассчитываться в режиме реального времени.
Используйте DTS (или канал), чтобы добавить монитор расходомера, когда оценка пользователя изменяется,в реальном времениНакапливайте ежедневный поток оценок, вычисляйте временную задачу один раз в час, равномерно распределяйте ее на «каждый момент», добавляйте 100 Вт потока каждый день, а нагрузка на запись в базу данных составляет более 10 раз в секунду, что вполне терпимо.
Голос за кадром: Если вы не можете использовать DTS/канал, вы можете использовать MQ.
Суммировать, для такой временной задачи, которая централизованно обрабатывает большой объем данных за один раз, идея оптимизации такова:
(1) Одни и те же данные уменьшают количество повторных вычислений;
(2) Выделите вычислительное время ЦП и попытайтесь рассредоточить обработку (даже в реальном времени) вместо централизованной обработки;
(3) Уменьшить объем данных для одного расчета;
Надеюсь, у всех вас есть вдохновение,идеиважнее вывод.
домашнее задание после уроков:
Предположим, журнал входа в систему (журнал сложнее, чем база данных, базу данных можно индексировать и извлекать) выглядит следующим образом:
2019-08-15 23:11:15 uid=123 action=login
2019-08-15 23:11:18 uid=234 action=logout
…
Ask, 2019-8-15 В этот день кривая количества одновременных онлайн-пользователей в системе с точностью до секунды.
проиллюстрировать:
(1) действием может быть только вход/выход из системы;
(2) Онлайн-пользователь определяется как пользователь, который вошел в систему, но еще не вышел из нее и использует систему;
(3) Пользователи, которые вошли в систему до 8-15 и не вышли из системы 8-15, также считаются онлайн-пользователями дня (подтекст в том, что одного сканирования журнала дня недостаточно);