Ваша реализация звучит так, как будто вам нужен простой механизм кэширования значения ключа, и вы можете использовать контейнер типа std::unordered_map из C ++ 11 или его двоюродного брата, boost::unordered_map.unordered_map обеспечивает реализацию хеш-таблицы.Если в какой-то момент вам нужна была еще более высокая производительность, вы также можете взглянуть на Boost.Intrusive , который обеспечивает высокопроизводительные стандартные библиотеки-совместимые контейнеры.
Если вы прокручиваете кэш с указанными выше рекомендациямиВторой проблемой будет истечение срока действия записей в кэше, так как вероятность того, что ваши кэшированные данные станут устаревшими.Я не знаю, на что похожи ваши данные, но вы можете реализовать стратегию кеширования, как любой из этих:
- после определенного времени / количества использований, срок действия кэшированной записи истекает
- по истечении определенного времени / числа использований истекает весь кэш (экстремальный)
- использовался реже всего - есть вопрос переполнения стека по этому поводу: Дизайн кэша LRU
Многопоточный / параллельный доступ также может быть проблемой, хотя, как предлагается в приведенной выше ссылке, можно было бы заблокировать кэш при доступе, а не беспокоиться о гранулярной блокировке.
Теперь, если вы говорите о масштабировании и переходе к нескольким процессам, а также о распределении серверных процессов по нескольким физическим машинам, простое внутрипроцессное кэширование может больше не быть подходящим способом (каждый может иметь разные копии данных в любой данный момент).время, несоответствие производительности, если некоторые серверы кэшировали данные, а другие нет).
Вот где Redis / Memcached /Membase / др.блеск - они созданы для масштабирования и выгрузки работы из базы данных.Они могут быть побиты производительностью базы данных и кэша в памяти (в конце концов, есть задержка и множество других факторов), но когда дело доходит до масштабирования, они очень полезны и сохраняют нагрузку на базу данных, иможет быстро обслуживать запросы.Они также поставляются с истечением срока действия кэша (реализации различаются между собой).
Лучше всего?Их легко использовать и вставлять. Вам не нужно выбирать redis / memcache с самого начала, поскольку само кэширование - это всего лишь оптимизация, и вы можете быстро заменить код кэширования, используя, скажем, кэш в памятивы сами можете использовать redis или что-то еще.
Между серверами кэширования все еще есть некоторые различия - мембрана и memcache распределяют свои данные, в то время как в redis есть репликация master-slave.
Для записиЯ работаю в компании, где мы используем серверы memcached - у нас есть несколько из них в центре обработки данных, а на остальных наших серверах около 16 ГБ ОЗУ полностью выделено для кэширования.
edit:
А для сравнения скорости я адаптирую кое-что из презентации Херба Саттера, которую я давно наблюдал:
- обработка в памяти -> очень быстрая
- получение данных изданные локального процесса в памяти -> все еще очень быстрые
- данные с локального диска -> зависит от вашего устройства ввода-вывода, SSD может быть быстрым, номеханические приводы леденят
- получение данных от удаленного процесса (данные в памяти) -> fast-ish, и ваши серверы кеша должны быть ближе
- получение данных от удаленного процесса (диска) ->айсберг