Дизайн разделения времени создания для повторного использования запросов

1. Проблемная ситуация

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

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

Сначала я думал, что это просто функция запроса, но вскоре заметил, что она продолжает пересчитывать одни и те же данные при каждом запросе.

Хотя данные не изменялись в реальном времени из-за характера данных,Создание новых данных при каждом запросе неэффективно с точки зрения операционной эффективностиЯ так чувствовал.

Эта структура имела следующие проблемы.

• Повторный расчет одинаковых данных

• Увеличение ненужных запросов к БД

• Повторное выполнение сложной логики сортировки и фильтрации

• Возможность ухудшения производительности при увеличении объема данных

Вместо того чтобы просто оптимизировать запросы, необходимо было переосмыслить сам процесс создания и использования данных.

2. Подход

Данные имеют характер, при котором в течение одного дня не происходит значительных изменений.

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

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

Самая важная часть этого процесса заключается в том, что“Когда будут созданы новые данные” было.

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

3. Способ реализации

3.1 Разделение структуры данных

Для применения структуры повторного использования на дневной основе данные были разделены на две категории.

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

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

Таким образом, отделение данных, управляющих состоянием создания, от фактических данных запросаЯ старался сохранить поток данных простым.

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

3.2 Генерация и повторное использование данных

Когда поступает запрос, сначала проверяется, существуют ли уже данные на текущую дату.

Если данные за указанную дату отсутствуют, то при первом запросе создаются все данные.

В дальнейшем система настроена на использование уже созданных данных для запросов.

Поток обработки следующий:

1. Проверка наличия данных на текущую дату

2. Если данных нет, выполните создание всех данных

3. Если данные существуют, выполните запрос без создания

4. Возврат результатов запроса

Через эту структуру Данные создаются только один раз, а затем следуют процессу повторного использования сделали.

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

3.3 Логика генерации данных

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

В процессе создания выполняются следующие действия.

• Удаление устаревших данных

• Реконструкция целевых данных согласно актуальным стандартам

• Некоторые значения предыдущего состояния сохраняются

• Регистрация данных контрольной даты

Я особенно уделил внимание тому, чтобы сохранить значения существующего состояния. Если каждый раз полностью инициализировать данные, то в процессе эксплуатации Информация, измененная администратором, может исчезнуть.Это так. Поэтому я настроил данные, чтобы сохранить только необходимые значения после проверки существующих данных.

4. Намерение дизайна и эффекты

Сравнив старый метод и улучшенную структуру, можно отметить следующее.

Эта структура не только уменьшает количество запросовВремя создания данных и время запроса разделеныЭто удалось.

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

Также удалось управлять данными, основываясь на времени создания, и тем самым упростить поток запросов.

5. Ретроспектива

Сначала я думал, что это просто функция просмотра, но в процессе реализации я столкнулся с вопросом: «Почему я продолжаю пересчитывать одни и те же данные?»

И следуя этому вопросу, я понял, что более важным, чем простая оптимизация запросов, является вопрос «когда и как создавать и управлять данными».

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

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

zero