Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Таблица для кэширования вычисляемых данных  [new]
sraider
Member

Откуда:
Сообщений: 325
Ситуация:
У приложения есть вычисляемые данные, которые считаются довольно долго. Изменения данных редки, запросы на вычисляемые данные - часты. Есть идея вычислять все один раз при первом запросе, потом кэшировать - складывать в отдельную таблицу. При последующих запросах - выдавать из таблицы. При обновлении данных - очищать таблицу по триггеру.

Но таким образом на КАЖДОЕ изменение основных данных в этой таблице будут удаляться данные (DELETE), а потом при запросе - заново считаться и сохраняться (INSERT около 10000 строк) в таблицу-кэш.

Планируется создать для кэша обычную таблицу внутри этой же базы данных. Вопрос - нет ли в этом каких-либо подводных камней? Конкретно - не будет ли раздуваться база данных или transaction log из-за постоянных удалений и вставок в таблице-кэше? Если да, то какая альтернатива? Отдельная БД для кэша или глобальная временная таблица (с префиксом ##) или еще что?
20 фев 14, 00:43    [15594592]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для кэширования вычисляемых данных  [new]
SERG1257
Member

Откуда:
Сообщений: 2827
sraider
При обновлении данных - очищать таблицу по триггеру.
Так прямо и всю таблицу очищать. Может только часть?
sraider
Конкретно - не будет ли раздуваться база данных или transaction log из-за постоянных удалений и вставок в таблице-кэше?
Не будет.
sraider
Если да, то какая альтернатива?
indexed view. Там конечно много ограничений, но посмотреть в эту сторону стоит
sraider
Вопрос - нет ли в этом каких-либо подводных камней?
Триггер можно отключить, а потом снова включить, то бишь синхронизация данных не гарантируется. Рекомендуется регулярно сверять ваш кэш или тупо его truncate
20 фев 14, 00:59    [15594674]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для кэширования вычисляемых данных  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31785
sraider
Планируется создать для кэша обычную таблицу внутри этой же базы данных.
Это же в принципе стандартный подход, используется везде. Всякие "регистры", "остатки" - это и есть кеш, дублирование данных для того, что бы избежать постоянных вычислений.
sraider
Но таким образом на КАЖДОЕ изменение основных данных в этой таблице будут удаляться данные (DELETE), а потом при запросе - заново считаться и сохраняться (INSERT около 10000 строк) в таблицу-кэш.
Конечно, нужно соблюсти баланс между ускорением чтения данных из за кеширования и замедлением из за необходимости обновлять кеш.
sraider
Вопрос - нет ли в этом каких-либо подводных камней?
Каких то "специальных" нет.
20 фев 14, 09:08    [15595412]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для кэширования вычисляемых данных  [new]
Сон Веры Павловны
Member

Откуда:
Сообщений: 6128
sraider
Конкретно - не будет ли раздуваться база данных или transaction log из-за постоянных удалений и вставок в таблице-кэше?

Если опасаетесь этого - поместите таблицу в отдельную базу с simple recovery model
20 фев 14, 10:00    [15595656]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для кэширования вычисляемых данных  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31785
Сон Веры Павловны
sraider
Конкретно - не будет ли раздуваться база данных или transaction log из-за постоянных удалений и вставок в таблице-кэше?

Если опасаетесь этого - поместите таблицу в отдельную базу с simple recovery model
Или получше продумать алгоритм:
sraider
Но таким образом на КАЖДОЕ изменение основных данных в этой таблице будут удаляться данные (DELETE), а потом при запросе - заново считаться и сохраняться (INSERT около 10000 строк) в таблицу-кэш.
Не удалять все данные и вставлять все данные, а менять только то, что нужно.
20 фев 14, 11:40    [15596478]     Ответить | Цитировать Сообщить модератору
 Re: Таблица для кэширования вычисляемых данных  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6723
alexeyvg
Это же в принципе стандартный подход, используется везде. Всякие "регистры", "остатки" - это и есть кеш, дублирование данных для того, что бы избежать постоянных вычислений.
Хочу немного сбалансировать понимание сути вещей.
1. Любое кеширование, т.е. фактически логическое дублирование, это лишний код и процессы.
Которые могут иметь баги, иметь побочные явления и что-то не учитывать и добавлять ограничения.
2. Есть разница - создать новое средство или использовать готовые решения/механизмы.
К примеру индексация (вьюшек) это готовый проверенный механизм или писать свою поделку.
3. Есть разница - где и когда использовать кеширование.
Не скулем единым! Если он будет на уровне приложения, то не будет всяких накладок типа логов (медленный IO дисков) и всех тех механизмов контроля и перестраховок, которые вам возможно и не нужны.
Поэтому и есть такие продукты как Memcashed (аналоги).
4. Довольно часто перерасчёт данных более эффективен чем хранение и перемещение (IO).
Поэтому есть такие вещи как сжатие таблиц, для увеличения производительности (а распаковать - это вычисления).
Тем более когда обычно процы простаивают, а IO самое тонкое место.

Это конечно если не сделано всё через здц. А такое часто бывает, и грамотно составленный код работает быстро даже казалось бы на сложных "формулах". Часто в коде каждый раз вычисляют одно и тоже, не замечая что это можно вычислить на другом этапе и оно потом не меняется. И такое встречается практически всегда когда человек не знает (не понимает) декларативное программирование.
(гора скляроки, да даже хотя бы одна и десятки и сотни отдельных команд в процедурах, курсоры и циклы и т.п. лапшекод)

alexeyvg
Или получше продумать алгоритм
+1
Если скомпоновать всё в небольшой набор команд (желательно одну) то "формула" очень вероятно будет скомпилирована в оптимальный набор машинного кода. Всяко лучше интерпретируемого T-SQL.
Пересмотр системы, разбитие на этапные куски к примеру - может кардинально повлиять на общую простоту.

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

ИМХО.
PS: Просто мне приходилось и не раз убивать систему кэширования, выравнивая корявый говнокод. В итоге и кода меньше на порядок и архитектура проще и железо стало простаивать.
Так что нужно соблюдать баланс.
21 фев 14, 04:11    [15602831]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить