Memcached, Redis или Couchbase

Question

У меня есть сервер Debian с объемом памяти 16 ГБ, который я использую с nginx и несколькими тяжелыми базами данных mysql, а также с некоторыми настраиваемыми php-приложениями. Я хотел бы реализовать кеш памяти между Mysql и PHP, но базы данных слишком велики, чтобы хранить все в ОЗУ. Я думаю, что кеш LRU может быть лучше, если я исследую. Это исключает Redis? Couchbase также рассматривается.

Answer 1

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

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

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

Тем не менее, я бы не использовал couchbase здесь, который является эластичным (т. Е. Предполагается использовать на нескольких узлах) NoSQL key/value store (т. Е. Не кэш). Вероятно, вы могли бы переместить некоторые данные из ваших экземпляров mysql в кластер couchbase, но использовать его только для кеширования - это чрезмерная инженерная IMO.

Answer 2

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

Answer 3

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

Answer 4

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