Веб-приложение - архитектура кеша

Question

У меня есть приложение .Net и служба WCF, которые я использую для кэширования элементов в хронологическом порядке, используя SortedSet.Он хранит некоторые метаданные, которые я использую для получения DatabaseId, поэтому запрос к БД будет намного быстрее.Мне нужна помощь по лучшей / правильной / наиболее подходящей архитектуре.

Служба хранит SortedSet в единственном экземпляре.Сохраненные данные:

public class MyData : IComparable<MyData> {
    DateTime CreateDate {get; set;}
    List<int> AccountIds {get; set;}
    long DatabaseId {get; set;}

    // implementation to sort by CreateDate
}

У меня есть метод с контрактом

List<int> GetDatabaseIds( DateTime startRange, DateTime endRange, 
    List<int> accountIds )

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

Это ускоряет поиск в базе данных, но с увеличением количества записей возрастают и требования к памяти.Я экспериментировал с AppFabric Cache, MemCached и обнаружил, что их нельзя использовать, поскольку они хранят элементы в ключе / значении.Может быть, я ошибаюсь, но можно ли использовать эти продукты, если да, то как?Если нет, какие еще способы можно использовать для хранения последовательных данных (по дате) для получения соответствующих идентификаторов баз данных?

Обновление

Причина, по которой я это делаюДело в том, что прямой поиск в базе данных довольно медленный, а элементы, которые хранятся в базе данных, не всегда расположены в хронологическом порядке.Если я могу просто передать DatabaseId, базу данных нужно только искать на ПК.Это также позволило бы мне использовать MemCached для хранения данных, дополнительно минимизируя доступ к БД.Это высшая цель.Кроме того, мне нужно масштабировать веб-серверы, поэтому я переместил его из Runtime.Cache во что-то внешнее.

Я не уверен на 100%, что мне действительно нужно такое кэширование, но когда я выполнял запросы к базе данных напрямую, отставание было бы намного больше, даже если бы были правильные индексы.Используя этот метод, поиск WCF возвращает результаты примерно за 20 мс (с около 1 000 000 записей), и запрос БД будет очень быстрым (не может вспомнить время).Я также устал от того, что использование начинает расти, этот WCF не масштабируется.

Кроме того, я действительно думал о сохранении всего SortedList в Cache, но приведение к / from / constant добавило егодовольно медленно

Я ожидаю, что число строк увеличится как минимум на 10 000 в день, и записи будут добавлены в любое время с помощью другого метода WCF.

Возможно, то, что я сделал, совершенно неверно, ноВот несколько вещей, о которых я подумал:

1. Создайте новую таблицу в БД, которая будет хранить точно так же, как у меня в кеше.Это будет кластеризовано CreateDate и с высокой индексацией
2. Продолжайте пытаться оптимизировать запрос / базу данных, чтобы запрос был намного быстрее
3. Сохраните службу WCF, но создайте новое поле ExpiryDate,и если срок действия этой записи истечет, старый неиспользованный материал не будет задерживаться.

Идеи ??

Answer 1

Вы можете использовать пользовательский кеш, такой как у меня здесь: http://www.itsalltechnical.com/2011/01/non-web-expiring-generic-cache-in-c.html

Я упоминаю об этом, потому что вы можете настроить способ получения данных, если вам не нравится доступ в стиле словаря.Я думаю, что в большинстве структур кеширования вы увидите ту же методологию словаря, так что вы можете оказаться там.Вы можете рассмотреть возможность использования некоторых других типов персистентности на основе высокоскоростных объектов, таких как MongoDB или Cassandra (работает для facebook) для пропускной способности.К счастью, у вас есть много вариантов.