управление версиями SQL-запроса - PullRequest
1 голос
/ 17 декабря 2010

У меня есть ферма серверов, каждый сервер регулярно делает идентичный запрос к базе данных. Эти результаты запроса кэшируются в общем кэше, доступном для всех серверов.

Как я могу гарантировать, что новый запрос не будет перезаписан более старым запросом? Есть ли способ версии запросов как-то, например, по времени, чтобы это не бывает? Как бороться с параллельными запросами?

Спасибо!

Редактировать: БД является SQL Server. Запрос является оператором выбора. И механизм кэширования очень прост: простая запись без блокировки. И это потому, что в настоящее время нет способа определить порядок запросов select.

Ответы [ 2 ]

0 голосов
/ 18 декабря 2010

Где находится кеш?Это файл на диске?Или таблица в базе данных?

И что это значит, когда вы говорите, что старый запрос может перезаписать более новый?Не правда ли, что самый последний завершенный запрос (или, может быть, самый последний запущенный) является самым новым?

Вы должны заблокировать контейнер кэша перед выполнением каждого запроса, будь то файл илистол.Каждый сервер должен выполнять запрос только в том случае, если он может получить блокировку, в противном случае он должен ожидать заблокированный ресурс.Таким образом, кеш будет содержать только самые последние результаты.

Это соответствует тому, что вы спрашиваете?

0 голосов
/ 18 декабря 2010

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

Таким образом, при каждом обновлении также увеличивайте глобальный счетчик. При каждом чтении считывайте глобальный счетчик и помещайте данные в кэш вместе со значением счетчика. Перезаписывать содержимое кэша только в том случае, если значение счетчика больше.

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

...