Как реализовать кэширование EAV/CR большого объёма данных?

Question

[Владимир]

Добрый день, имеется база инженерных данных в MS SQL , реализуемая в виде EAV/CR с 3k классов, 8к атрибутов, 200 типов связей, 50m сущностей и тд и тп...
с увеличением объёмов, возрастает нагрузка многократно из-за десятков join'ов и тд и тп...

Есть идея реализовать кэш запроса в виде запросов к read-only SQLite'а (+ аггрегированный хэш сущностей, которые получаем из INNER SELECT, чтобы отследить необходимость обновления этого read-only SQLite'а)

пример :

pseudo-sql:
select att1, att2, att3 
from 
    equipment e
    join security s on s.role = 'current_user_role' and s.acl = e.acl
where e.id in (
    select t_e.id  
    from 
        equipment t_e 
        join relationships r on r.type = 'eq_vendor'  and r.left = t_e.id
        join vendors v  on v.name = 'Рога и Копыта' and r.right = v.id
    )

1. убираем фильтрацию по security:
2. делаем общий хэш найденных сущностей
и запихиваем результат во flat sqlite
3. перенаправляем запросы этому sqlite'у
4. "регулярно" пересчитываем хэш найденных сущностей и сравниваем с хэшем сохраннённой sqlite

Вопросы:
Впринципе, имеет ли смысл такой подход? или прирост производительности будет незначительным по сравнению со сложностью "управления"/реализации?

Answer 1

[mayton2019]

В принципе имеет. Почему нет? Но есть нюансы.

Вот самое слабое утверждение .

"регулярно" пересчитываем хэш найденных сущностей и сравниваем с хэшем сохраннённой sqlite

Регулярно это как? Каждую секунду? Или минуту. Вобщем тут нет единого правильного ответа. Нужно разговаривать с бизнесом и понимать где можне чем пожертвовать. Или точно знать что работаем с архивными данными. Следовательно кеш - вечен. Или работаем со справочником товаров которые обновляются раз в сутки. Тогда обновление или переасчет кеша можно просто привязать к старту системы. И каждый день перегружать ее.
Короче инвалидация кеша - это главная проблема в любых инициативах с кешом.

Далее объем. Надо быть очень удачливым или иметь очень строгое ТЗ чтобы гарантировать что кеш будет иметь разумный объем. Если кеша будет не хватать или он будет в ротации в памяти с другими кешами то вреда от него будет больше чем пользы.

Далее идеология. Может ваша система уже давно переросла реляционку (EAV как признак) и ей просто нужно волевое архитектурное решение. Затащите документную БД. Mongo, CouchDb. Может вам с ней будет проще работать. EAV никогда не была эффективной в смысле скорости.

Comments

[Владимир]

"регулярно" - когда я определю необходимость... например:
1. имеем список аля cache-definitions определяющий контент кэша и хэш:

sqlite-uid-1     "select abc"    hash:abcdef1234
sqlite-uid-2     "select def"    hash:1234abcdef

2. в систему пришёл Insert/update/delete для объектов: id1,id2,id3
3. в pre-event выполняем select'ы из cache-definitions с join'ами id1,id2,id3, если есть совпадения, то инвалидируем кэш

А у Вас сайт MongoDB открывается? у меня только через Tor )

[mayton2019]

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