### 1. Проблемная ситуация
При реализации функции просмотра списка определенных пользователей на странице администратора использовалась логика запроса с множеством условий и сложными критериями сортировки.
В процессе запроса выполнялись не только простые операции извлечения данных, но также расчет условий для целей, определение статуса, сортировка и т. д., и структура была такой, что одни и те же операции повторялись каждый раз, когда поступал запрос.
Сначала я думал, что это просто функция запроса, но на самом деле мне стало очевидно, что каждый раз при запросе одни и те же данные продолжают пересчитываться.
Хотя данные не изменялись в реальном времени из-за их характеристик, ощущалось, что способ формирования всех данных заново при каждом запросе неэффективен с точки зрения операционной эффективности.
Такая структура имела следующие проблемы.
- Повторное вычисление одинаковых данных
- Увеличение ненужных запросов к БД
- Повторное выполнение сложной логики сортировки и фильтрации
- Возможное ухудшение производительности при увеличении объема данных
Вместо того чтобы просто оптимизировать запросы, необходимо было переосмыслить сам поток создания и использования данных.
### 2. Подход
Данные имели особенность, что в течение дня не происходит значительных изменений.
Исходя из этого, вместо того, чтобы рассчитывать данные с каждым запросом, была применена структура **создания данных на ежедневной основе и последующего их повторного использования**.
То есть, была изменена структура, при которой данные создаются только в нужный момент, а уже созданные данные могут быть повторно использованы, а не рассчитываться в каждый момент обращения.
Наиболее важным аспектом этого процесса было: «Когда следует создавать новые данные?»
Я пришел к выводу, что необходимо создавать структуру, в которой можно четко управлять моментом создания, а не просто временно сохранять в памяти, как это делают в простом кэшировании.
### 3. Способ реализации
#### 3.1 Разделение структуры данных
Для применения структуры повторного использования по дням данные были разделены на два типа.
| разметка | роль |
|------|------|
| Дата 기준일 | Определение возможности создания данных в день обращения |
| Данные в поле запроса | Данные, используемые при фактическом запросе |
Дата справки служит для определения, была ли уже выполнена генерация данных на основе текущей даты.
С другой стороны, данные, подлежащие просмотру, хранят данные, которые будут повторно использованы во время фактического просмотра.
Таким образом, мы стремились упростить поток данных, отделив данные о создании от фактических данных для запроса.
Кроме того, в операционной среде могут возникать ситуации, такие как перезапуск приложения или множественные запросы, поэтому мы посчитали, что подход, основанный на базе данных, более целесообразен, чем управление на основе памяти.
#### 3.2 Генерация и повторное использование данных
Когда поступает запрос, сначала проверяется, существуют ли данные на текущую дату.
Если на указанную дату нет данных, то при первоначальном запросе создаются все данные.
В дальнейшем система настроена на использование уже созданных данных для запросов.
Поток обработки выглядит следующим образом.
1. Проверка наличия данных на текущую дату
Если данных нет, выполняется создание всех данных
Если данные существуют, выполняется выполнение запроса без процесса создания
4. Возврат результатов запроса
Эта структура позволяет создать данные только один раз, после чего следует использовать поток повторного использования.
#### 3.3 Логика генерации данных
При создании данных задача не состоит в том, чтобы просто удалить все существующие данные и создать новые, а в том, чтобы спроектировать их с учетом некоторого сохранения текущего состояния и переработать на основе самых актуальных данных.
В процессе создания выполняются следующие действия.
- Удаление устаревших существующих данных
- Реконструкция целевых данных по последним стандартам
- Сохранение некоторых значений текущего состояния
- Дата регистрации на основу
В частности, я уделял особое внимание части, которая поддерживает текущие значения.
Каждый раз, когда данные полностью сбрасываются, может исчезнуть даже информация, измененная администратором в процессе работы.
Поэтому было решено сохранить только необходимые значения, проверив существующие данные.
### 4. Намерение и эффект проектирования
Сравнив традиционный подход и улучшенную структуру, можно увидеть следующее.
| раздел | Существующий метод | Улучшенный метод |
|------|----------|----------|
| Способ обработки данных | Расчёт за каждый запрос | Повторное использование после первого создания |
| Запрос к БД | Происходит повторный запрос | Выполняется только запрос после создания |
| Ответный поток | Может изменяться в зависимости от запроса | Поддерживать постоянство |
| Операционные расходы | Происходит повторное вычисление | Выполняется только при первом создании |
| Способы управления данными | По времени запроса | По времени создания |
Эта структура позволила не только просто сократить количество запросов, но и разделить время создания данных и время запроса.
Особенно эта структура была разработана с учетом того, что реальное время не является критически важным для характеристик данных, и приоритет отдается эффективности повторного использования, а не вычислительным затратам.
Кроме того, управление данными на основе момента создания позволило удерживать сам поток запросов в простоте.
### 5. Ретроспектива
Сначала я думал, что это просто функция запроса, но в процессе реализации столкнулся с вопросом: «Почему мы продолжаем пересчитывать одни и те же данные?»
И, следуя этому вопросу, я понял, что важнее, чем простая оптимизация запросов, является то, «когда и как управлять данными».
Я смог узнать, что улучшение производительности — это не просто ускорение скорости запросов, а процесс перепроектирования самого потока данных.
Кроме того, я также смог убедиться, что для создания надежной операционной структуры необходимо учитывать не только логику выборки, но и время создания данных, способ поддержания состояния и структуру повторного использования.
zero