Мембазный сервер и Enyim - интеграция LINQ и / или коллекций - PullRequest
Новая
       31

Мембазный сервер и Enyim - интеграция LINQ и / или коллекций

1 голос
/ 29 октября 2011

Я только что установил мембрану и клиент enyim для .NET и наткнулся на статью, в которой упоминается этот метод интеграции linq: 

    public static IEnumerable<T> CachedQuery<T>
        (this IQueryable<T> query, MembaseClient cache, string key) where T : class
    {
        object result; 
        if (cache.TryGet(key, out result))
        {
            return (IEnumerable<T>)result;
        }
        else
        {
            IEnumerable<T> items = query.ToList();
            cache.Store(StoreMode.Set, key, items);
            return items;
        }
    }

. Сначала он проверит, находятся ли необходимые данные в кеше, иесли не кешировать, то вернуть.

В настоящее время я использую Dictionary<'String, List'> в своем приложении и хочу заменить его на подход с типом membase / memcached.

А как насчет аналогичного шаблона для добавления элементов в список <'T'> или использования операторов Linq в кэшированном списке?Мне кажется, что может быть плохой идеей хранить весь List <'T'> в кеше под одним ключом и получать его, добавлять к нему, а затем переустанавливать каждый раз, когда вы хотите добавитьэлемент.Или это приемлемая практика? 

    public bool Add(T item)
    {
        object list;
        if (cache.TryGet(this.Key, out list))
        {
            var _list = list as List<T>;
            _list.Add(item);
            return cache.Store(StoreMode.Set, this.Key, _list); 
        }
        else
        {
            var _list = new List<T>(new T[] { item });
            return cache.Store(StoreMode.Set, this.Key, _list); 
        }
    }

Как коллекции обычно обрабатываются в такой ситуации кэширования?Используются ли вместо этого алгоритмы хеширования или какая-то система префиксов ключей для идентификации «списков» типа T в хранилище значений ключей кеша?

1 Ответ

1 голос
/ 29 октября 2011

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

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

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

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

Вам необходимо:

  1. Иметь ключ, который содержит длину списка.
  2. Иметь возможность создавать составной ключ (например, одно или несколько полей из вашего объекта).
  3. Выберите значение, которое вы хотите сохранить (например, другое поле).

например:

list_length = 3

prefix1_0-> prefix2_ [field1.value] [field2.value] [field3.value] -> field4.value

prefix1_1-> prefix2_ [field1.value] [field2.value] [field3.value] -> field4.value

префикс1_2-> префикс2_ [field1.value] [field2.value] [field3.value] -> field4.value

Чтобы выполнить последовательный доступ, вы перебираете ключи с помощью «prefix1». Для произвольного доступа вы используете ключи с «prefix2» и полями, составляющими ключ.

Надеюсь, это достаточно ясно.

...