@TopLayer

Здравствуйте! Решаю учебную задачу по написанию сервера учёта статистики. В его обязанности входит приём запросов на добавление информации, а также на получение различных статистических данных. Все сущности решил хранить в локальной БД SQLite. Схема БД состоит из восьми взаимосвязанных таблиц, содержащих достаточно мелкие сущность (менее 100 символов текста) - ничего особенного.

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

У меня пока есть только одна идея насчёт этого. Заключается она в поддержании дубликата базы данных. Так, одна БД служит источником информации для запросов, вторая для записи полученной информации. Полученная информация также буферизируется в ОЗУ. После прошествии некоторого времени, запросы на статистику перенаправляются на актуальную БД, а устаревшая актуализируется при помощи буферизированной в ОЗУ информации. И так по очереди.

Но у меня есть сомнения относительно этого решения: а не упрётся ли вся производительность в скорость жёсткого диска, тогда ведь ведение копии данных лишь замедлит программу?

Хотел бы услышать ваши комментарии по этому поводу. Может кто-нибудь уже решал подобную проблему и подскажет какие варианты оптимизаций могут быть применены в подобных обстоятельствах. (использую C#, EF6, если это имеет значение)

Заранее благодарю за ответ!

0

@Anvano

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

Каким способом это достигается - зависит от конкретной реализации базы данных.

Например, в Oracle для этого служит внутренний механизм материализованных представлений или вообще Oracle Data Warehouse (DWH) с его предрасчитываемыми аналитическими кубами и срезами.


Для SQLite можно предложить какой-нибудь фоновый процесс, который будет асинхронно обновлять необходимую статистическую информацию, соответственно её получение будет сводиться к обычному запросу из сводной таблицы, в которой буду лежать как раз "не супер свежие данные на ту дату, когда фоновый процесс в последний раз обновлял статистику".

1

@TopLayer

Anvano, дельное предложение! Наверное на нём и остановлюсь, хоть и придётся эту таблицу в рантайме создавать, из-за требования к лёгкому масштабированию (добавление новых статистических свойств). Спасибо!

0