Memcached, Redis или Couchbase

Ответ 1

Предположим, что существует уникальный сервер, на котором запущены nginx + php + mysql экземпляры с некоторой оставшейся свободной оперативной памятью, самый простой способ использовать эту RAM для кэширования данных - просто увеличить кеширование буферов экземпляров mysql. Базы данных уже используют LRU-подобные механизмы для обработки своих буферов.

Теперь, если вам нужно переместить часть обработки в сторону от баз данных, предварительное кэширование может быть опцией. Прежде чем говорить о memcached/redis, кеш общей памяти, интегрированный с php, такой как APC, будет эффективен, если будет рассмотрен только один сервер (фактически более эффективный, чем redis/memcached).

Как memcached, так и redis можно считать выполненными для удаленного кэширования (то есть для совместного использования кеша между различными узлами). Я бы не исключал redis для этого: его можно легко настроить для этой цели. Оба позволят определить ограничение памяти и обрабатывать кеш с LRU-подобным поведением.

Однако я бы не использовал couchbase здесь, который является эластичным (т.е. предполагается, что он используется на нескольких узлах), хранилище ключей/значений NoSQL (т.е. не кеш). Вероятно, вы могли бы перенести некоторые данные из ваших экземпляров mysql в кластер couchbase, но использовать его только для кеширования - это надстройка IMO.

Ответ 2

Мы сначала использовали memcached для кэширования данных. В memcahed данные разбиения на разные приложения в разных ведрах были реальной проблемой. Также у нас есть требование, чтобы очистить данные только от одного ведра. Мониторинг данных - еще одно требование. Мы переместились в CouchBase и используйте ведро memcahed style.i, угадывая его гораздо более гибкое и эффективное использование куба стиля memcache couchbase для кеширования, а не использование memcahe.

Ответ 3

Вы когда-нибудь считали, что ваши базы данных полностью загружены в ОЗУ с использованием одного из решений NoSQL в памяти с постоянством? Это может потребовать меньше памяти, чем исходная база данных MySQL, потому что многие решения NoSQL обычно имеют меньше возможностей, чем базы данных SQL. Кроме того, если для вас очень важна логика на стороне сервера, попробуйте Tarantool, поскольку он имеет сценарий Lua на борту и должен иметь довольно небольшой объем памяти. В моих случаях те же данные в Tarantool занимали вдвое меньше, чем в MySQL. Это связано с тем, что они имеют небольшие накладные расходы для каждой строки и для каждого поля и используют почтовый пакет для хранения данных.

Ответ 4

Как отметил Мэтт Ингенттрон, и Хари отметил, что Couchbase поддерживает работу как прямая замена Memcached. Couchbase использует memcached неэластичным способом, так как в каждом node, участвующем в кластере memcache, сдержанно, без сохранения, т.е. Просто кеш, но couchbase также предлагает типы ковша Couchbase, которые обеспечивают постоянство. Membase также является частью кода, поэтому Couchbase не только обслуживает данные с диска, но также и из ОЗУ и сохраняет его там, реплицируя на другие узлы и сохраняя диск, когда применяются изменения. Я бы настоятельно рекомендовал Couchbase 3.x как для кэширования, так и для сохранения на одном расстоянии или нескольких следов, если вам нужен только слой кеширования, отдельный от вашего уровня персистентности.