Сколько операций в день по заданным заданиям происходит в приложении онлайн школы?

Операции с заданиями в приложении онлайн школы: анализ нагрузки

Контекст: типичное онлайн образовательное приложение

В приложении онлайн школы ежедневно происходит большое количество операций с заданиями. Давайте разберём типичный объем и разные типы операций.

Типы операций

Основные операции:

1. Выдача заданий (Assignment Distribution) - создание и распределение новых задач
2. Получение заданий студентом (Fetch Assignment) - просмотр задания
3. Отправка решений (Submit Solution) - студент отправляет ответ
4. Проверка решений (Grade Assignment) - учитель/автомат проверяет ответ
5. Просмотр оценок (View Grades) - студент видит результат
6. Пересмотр задания (Review) - доступ к уже выполненному заданию

Типичные объемы в день

Сценарий: школа с 10,000 студентов

Предположим:
- Рабочие дни: 5 дней в неделю
- Средний класс: 30 студентов
- Среднее количество предметов: 6
- Среднее количество заданий в день на предмет: 2

Расчёт операций

1. Выдача заданий:

Количество классов: 10,000 студентов / 30 = ~333 класса
Предметов в день: 333 класса × 6 предметов = 1,998 ≈ 2,000
Заданий в день: 2,000 предметов × 2 задания = 4,000 заданий

Эта операция происходит ОДИН РАЗ в день:
4,000 операций распределения

Это 4,000 записей в БД + кэширование

2. Просмотр заданий студентами:

Каждый студент просматривает свои задания несколько раз:
- При входе в приложение: 1 раз
- В течение дня: 2-3 раза
- Перед отправкой: 1 раз

Средний просмотр на студента в день: 3-4 раза

Операции просмотра: 10,000 студентов × 3.5 просмотра = 35,000 операций

Это в основном READ операции из кэша или БД

3. Отправка решений:

Не все студенты отправляют все задания:
- Процент участия: 70-80%
- Среднее количество заданий на студента в день: 4-6
- Не все пытаются все задания сдать

Определим:
- Студентов активных: 10,000 × 0.75 = 7,500
- Среднее заданий на студента: 5
- Попытки на задание: 2 (первая попытка + пересдача)

Операции отправки: 7,500 × 5 × 1.5 = 56,250 операций

Это WRITE операции - дорогие
Каждая запись: сохранение в БД + индексирование + очередь проверки

4. Проверка решений:

Автоматическая проверка:

- Типовых тестов: 56,250 отправок
- Время проверки: 1-5 сек за задание
- Параллельные воркеры: 10-20

Это 56,250 операций обработки, выполняемых в background

Ручная проверка преподавателями:

Для открытых ответов (эссе, проекты):
- 20-30% всех заданий требуют ручной проверки
- 56,250 × 0.25 = 14,062 задания на проверку
- Учителей: 10,000 студентов / 25 студентов на учителя = 400 учителей
- Задания на учителя в день: 14,062 / 400 = ~35 заданий

Итого: 14,062 операции ручной проверки (асинхронные)

5. Просмотр оценок:

Студенты проверяют результаты:
- Студентов, проверяющих оценки: 7,500 (тех, кто сдавал)
- Проверок на студента в день: 1-2 (после получения оценки)

Операции просмотра оценок: 7,500 × 1.5 = 11,250 операций

Это READ операции

6. Пересмотр и аналитика:

- Студенты пересматривают уже выполненные задания: 5,000 операций
- Родители проверяют прогресс ребёнка: 3,000 операций
- Администраторы смотрят статистику: 200 операций
- Учителя анализируют результаты класса: 2,000 операций

Итого аналитики: ~10,000 операций

ИТОГОВАЯ ТАБЛИЦА: ОПЕРАЦИИ В ДЕНЬ

Распределение по времени

ЭТО ОЧЕНЬ ВАЖНО - не равномерное распределение

Пиковые часы (после учебного дня): 40% операций
186,812 × 0.40 = 74,724 операций в час
Это ~20 операций в секунду (RPS)

Обычные часы: 60% операций
186,812 × 0.60 / 18 часов = 6,227 операций в час
Это ~1.7 операций в секунду

Ночью: 0% (закрыто)

ПИК: 74,724 / 60 мин = 1,245 операций в минуту
      = 20-25 операций в секунду с учётом всплесков

Нагрузка на систему

READ операции (35,000 + 11,250 + 10,000 = 56,250):

• Можно кэшировать
• Redis/Memcached для горячих данных
• CDN для статических заданий

WRITE операции (4,000 + 56,250 + 14,062 = 74,312):

• Требуют записи в БД
• Message Queue для асинхронной обработки
• Batch inserts для оптимизации

PROCESS операции (56,250):

• Background workers
• Job queue (Celery, RabbitMQ, Kafka)
• Параллельная обработка

Архитектура для обработки нагрузки

// Обработка отправки решения
public class AssignmentSubmissionService {
    private final AssignmentRepository repo;
    private final MessageQueue queue;
    private final CacheService cache;
    
    // WRITE операция - синхронная, в главном пути
    public SubmissionResult submitAssignment(SubmissionRequest request) {
        // 1. Валидация
        validateSubmission(request);
        
        // 2. Сохранение в БД (быстро)
        Submission submission = repo.save(request);
        
        // 3. Очистить кэш результатов студента
        cache.invalidate("student:" + request.getStudentId());
        
        // 4. Отправить в очередь проверки (асинхронно)
        queue.publish("assignment.submitted", new Event(submission.getId()));
        
        return new SubmissionResult(submission.getId(), "Received");
    }
    
    // PROCESS операция - в background worker
    @MessageHandler("assignment.submitted")
    public void processSubmission(String submissionId) {
        Submission submission = repo.findById(submissionId);
        
        // 1. Автоматическая проверка (если возможна)
        if (submission.canBeAutoGraded()) {
            GradeResult grade = autoGrade(submission);
            submission.setGrade(grade);
        } else {
            // 2. Отправить учителю на ручную проверку
            queue.publish("assignment.needsReview", submissionId);
        }
        
        // 3. Обновить в БД
        repo.update(submission);
        
        // 4. Notify студента
        notificationService.notifyStudentGraded(submission);
    }
}

// READ операция - из кэша
public class AssignmentViewService {
    private final CacheService cache;
    private final AssignmentRepository repo;
    
    public AssignmentDetail getAssignment(String assignmentId) {
        // Проверить кэш первым
        AssignmentDetail cached = cache.get("assignment:" + assignmentId);
        if (cached != null) {
            return cached;  // O(1) из памяти
        }
        
        // Если нет в кэше, загрузить из БД
        AssignmentDetail detail = repo.findById(assignmentId);
        
        // Закэшировать на 1 час
        cache.set("assignment:" + assignmentId, detail, 3600);
        
        return detail;
    }
}

Оптимизация

1. Индексирование БД:

-- Быстрый поиск заданий студентом
CREATE INDEX idx_assignments_student_date 
ON assignments(student_id, created_date DESC);

-- Быстрый поиск решений на проверку
CREATE INDEX idx_submissions_teacher_status 
ON submissions(teacher_id, status) WHERE status = 'pending';

2. Партионирование:

-- Разделить таблицу submissions по дате
PARTITION BY RANGE (YEAR(created_date), MONTH(created_date))

3. Batch операции:

// Вместо 4,000 отдельных INSERT
repo.saveAll(listOf4000Assignments);  // одна batch операция

Мониторинг

Метрики для отслеживания:
- Requests per second (RPS): целевой 25 RPS на пике
- Latency: средняя < 200ms, p99 < 1s
- Error rate: < 0.1%
- Queue depth: мониторить длину очереди проверки
- DB connections: макс 50-100
- Cache hit rate: целевой > 80%

Вывод

В типичной онлайн школе (10,000 студентов) ежедневно происходит:

~186,812 операций в день

Разбивка:

• READ: ~56,250 операций (30%) - из кэша
• WRITE: ~74,312 операций (40%) - в БД
• PROCESS: ~56,250 операций (30%) - в background

Пиковая нагрузка: 20-25 RPS после учебного дня

Это требует:

• Кэширования для READ операций
• Message Queue для асинхронной обработки
• Параллельных воркеров для проверки
• Правильного индексирования БД
• Мониторинга и alerting

Без оптимизации система падает на пиках. С оптимизацией легко справляется с такой нагрузкой.