Кэширование данных
Так как частота изменений или константность данных в SQL словаре в целом известна, то мы можем существенно оптимизировать работу слоя доступа к данных. Под оптимизацией я подразумеваю не только ускорение доступа к элементам словаря, но и уменьшение нагрузки на СУБД.
Оптимизация реализуется за счет кэширования объектов некоторых классов на уровне слоя доступа. Другими словами, C++ код грамматического словаря, обслуживающий запросы на загрузку из базы данных, в некоторых случаях запоминает единожды загруженные объекты в своих списках. Повторный запрос на загрузку тех же объектов выполняется уже без обращения к БД.
Разумеется, СУБД продолжает при этим кэшировать данные на своем уровне.
Некоторые особенности кэша слоя доступа:
1. Идентификация объектов осуществляется на основе естественного признака каждого объекта - первичного ключа.
2. Объекты в кэше не синхронизируются с базой данных. Поэтому в случае изменения в БД закэшированных данных необходимо перезапустить клиентское приложение. При проектировании слоя доступа была идея ввести специальную процедуру - сброс кэшей, но пока я от нее отказался, так как необходимость в такой операции будет очень редкой. В аналогичном механизме поисковой системы при работе с описаниями индексных баз движок постоянно отслеживает метки последней модификации данных в БД, и при необходимости сам "на ходу" подгружает изменившиеся данные. Поэтому поисковая система допускает в принципе одновременную работу двух движков на одном хосте - они будут корректно синхронизироваться.
3. В кэше нет механизмов устаревания объектов.
4. Кэш многопоточный, с блокировками потоков по классам объектов.
5. Кэшируются следующие объекты: языки, части речи, грамматические атрибуты, словарные статьи.
6. Вообще не кэшируются следующие объекты: фразы и их компоненты; связи, их теги и флаги; N-грамы.
(Немного расширенный вариант статьи на сайте ...)
Оптимизация реализуется за счет кэширования объектов некоторых классов на уровне слоя доступа. Другими словами, C++ код грамматического словаря, обслуживающий запросы на загрузку из базы данных, в некоторых случаях запоминает единожды загруженные объекты в своих списках. Повторный запрос на загрузку тех же объектов выполняется уже без обращения к БД.
Разумеется, СУБД продолжает при этим кэшировать данные на своем уровне.
Некоторые особенности кэша слоя доступа:
1. Идентификация объектов осуществляется на основе естественного признака каждого объекта - первичного ключа.
2. Объекты в кэше не синхронизируются с базой данных. Поэтому в случае изменения в БД закэшированных данных необходимо перезапустить клиентское приложение. При проектировании слоя доступа была идея ввести специальную процедуру - сброс кэшей, но пока я от нее отказался, так как необходимость в такой операции будет очень редкой. В аналогичном механизме поисковой системы при работе с описаниями индексных баз движок постоянно отслеживает метки последней модификации данных в БД, и при необходимости сам "на ходу" подгружает изменившиеся данные. Поэтому поисковая система допускает в принципе одновременную работу двух движков на одном хосте - они будут корректно синхронизироваться.
3. В кэше нет механизмов устаревания объектов.
4. Кэш многопоточный, с блокировками потоков по классам объектов.
5. Кэшируются следующие объекты: языки, части речи, грамматические атрибуты, словарные статьи.
6. Вообще не кэшируются следующие объекты: фразы и их компоненты; связи, их теги и флаги; N-грамы.
(Немного расширенный вариант статьи на сайте ...)