У нас есть веб-приложение для создания отчетов, в котором все данные хранятся в реляционной базе данных. Для большинства отчетов мы можем выполнять все вычисления с помощью встроенных функций агрегатора, предоставляемых движком, или путем предварительного расчета и кеширования результатов. Производительность создания этих отчетов для пользователей очень высокая.
Есть только два случая, когда нам нужно запустить очень сложный алгоритм, основанный на пробах и ошибках, который не может быть выполнен с помощью SQL, и что-то не может быть предварительно кэшируется в базе данных. Также существует слишком много вариантов ввода, поэтому результаты невозможно кэшировать. Алгоритм также требует всех данных одновременно, и поэтому невозможно разделить и обработать параллельно или получить фрагменты.
Итак, в настоящее время мы готовим эти отчеты, получая необработанные данные из базы данных и вычисление logi c в C#. Однако это происходит медленно, поскольку нам нужно получить все данные, которые могут достигать 8 ГБ на данный момент, на бэкэнд. Кроме того, многие тяжелые параллельные запросы могут вызвать ограничение доступной памяти на виртуальных машинах.
Мы уже получаем минимальное количество строк и столбцов (2 числовых c поля и 1 поле даты) для выполнения алгоритм, и на его основе мы не можем улучшить производительность за счет уменьшения размера передаваемых данных. Поэтому мы попытались ускорить его как Po C, выполнив следующие действия:
- Базы данных в памяти для кэширования необработанных данных (Redis, Memcached): хотя чтение из базы данных было очень быстрым, мы столкнулись с большая проблема в десериализации, которая может занять до 9 секунд для имеющихся у нас данных. Мы пробовали несколько алгоритмов десериализации, но ни один из них не был достаточно быстрым для больших объемов данных.
- Хранение необработанных данных в памяти (локальный кеш): это, очевидно, обеспечивало наилучшую возможную производительность, завершая вычисления менее чем за секунду . Однако это не идеальный вариант, поскольку он не масштабируется и может даже вызвать проблемы со сборкой мусора, согласно многим источникам в Интернете.
Мой вопрос в том, есть ли рекомендация с архитектурной точки зрения, в которой мы может ускорить отчеты до скорости, близкой к скорости локального кеша, без связанных с этим ограничений. Мы используем. NET Core и SQL сервер, если это помогает.