Скорость CTP: можем ли мы «искать» объекты?

Question

Фил, я очень ценю ваши ответы.

Что касается моих вопросов, касающихся регионов, я пытаюсь понять функциональность API, а не архитектуру или инфраструктуру службы / приложения / платформы.

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

Когда я изучаю API, я не вижу никакого «языка запросов», и единственные команды, которые, кажется, приближаются к описанной выше функциональности, связаны с «регионами».

Из жаргона, окружающего описание того, как регионы реализованы на платформе, я сделал вывод (правильно или неправильно?), Что когда регион был определен (создан?), Он будет развернут только на одном сервере кеша среди нескольких кешей. серверы в многосерверной реализации AppFabric.

То есть мне показалось, что описываемое было то, что «пространство имен» [регион] в AppFabric было основополагающим для любой возможности «индексации», которую демонстрирует платформа AppFabric. И что это «пространство имен» может быть реализовано только внутри границ одного сервера, что-то вроде того, как SharePoint Search изначально был одним сервером, а затем стал доступным на нескольких серверах.

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

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

И до сих пор вы ответили на многие мои вопросы, но не на этот точно.

Спасибо

Кимбалл

Похоже, что "теги" позволяют нам связать "поисковый термин" с объектами, помещенными в пространство кэша Velocity.

Однако их можно запрашивать только в «регионе».

Кроме того, регионы каким-то образом ограничивают локальность объектов в кэше одним сервером (или, может быть, что-то вроде этого).

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

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

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

Так что я был бы признателен за любую помощь по следующим вопросам:

1. В чем разница между «распределенным кешем» (называемым «разделенным» кешем ??) при использовании регионов и «локальным кешем»?

1.а. В частности, видны ли регионально-ориентированные значения в распределенном кэше через фабрику кэша, которая настроена на «просмотр» всего пространства кэша?

2. Достаточно ли эффективны операции создания и удаления «регионов», чтобы было разумно создать регион и группу тегов для каждого набора объектов, которые необходимо кэшировать?

2.а. Или же это просто подталкивает проблему определения области «поиска объектов» вверх по цепочке, поскольку способность объекта DataCache выполнять запросы вниз по регионам и тегам ограничена так же, как запрос к ключам кэша самих объектов.

Спасибо

* * Стата тысяча сорок-девять

Answer 1

В Release Candidate (и начиная с более поздних бета-версий) требование об использовании региона при добавлении элемента с тегами было снято (хотя у меня есть скрытое подозрение, что под прикрытием есть вызов на cache.GetSystemRegionName и регион используется ). Однако обратите внимание, что в выходные я играл с Release Candidate, и когда вы пытаетесь получить объект на основе тега / набора тегов, вам необходимо указать имя региона.

При каких обстоятельствах у вас в кеше будет объект, для которого у вас не будет постоянного уникального идентификатора где-то ? например ключ базы данных, AD guid и т. д.

С точки зрения «очистки» кэша, если вы используете регионы, есть метод ClearRegion, или вы можете просто удалить регион, который удалит из кэша все объекты внутри региона. Вы можете создать метод расширения, который выполняет сопоставление с образцом для ключа и объединить его с методами GetObjectsInRegion и GetSystemRegions, чтобы найти все объекты в кэше с некоторым токеном в ключе, но я думаю, что это будет ужасно неэффективно, так как вам придется перебирать каждый элемент для проверки ключа.

1а. В чем разница между «распределенный кеш» (называется «секционированный» кеш ??) при использовании регионы и «локальный кеш»?

(Необязательно) локальный кеш в AppFabric отличается от «центрального» кеша тем, что он находится прямо внутри вашего приложения. Всякий раз, когда вы запрашиваете кэшированный объект из «центрального» кэша, этот объект становится кэшированным в локальном кэше. Последующие запросы для этого объекта будут выполняться из локального кэша. В архитектуре, где ваши серверы AppFabric отличаются от ваших серверов приложений, это может сэкономить вам сетевой скачок.

1b. В частности, являются ориентированные на регион значения в распределенный кеш виден через фабрика кеша, настроенная на «увидеть» все пространство кэша?

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

1c. Являются ли операции создания и удаление "регионов" достаточно эффективно что было бы разумно создать регион и группа тегов для каждого пучок объектов, которые должны быть кэшируются

Области предназначены для удержания множества объектов, например Продукты, клиенты, следовательно, метод DataCache.GetObjectsInRegion, но вместо того, чтобы создавать регионы на разовой основе, я думаю, что лучше создать их все за один раз, скажем, на Application_Start в приложении ASP.NET. Тэги, однако, довольно эффективно создавать, так как они более или менее просто строки.