альтернатива memcached, которая может сохраняться на диске

Question

В настоящее время я использую memcached с моим java-приложением, и в целом он работает отлично.

Наиболее важными для меня являются особенности memcached:

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

Однако есть одна вещь, которую я хотел бы сделать, что memcached не может сделать. Я хочу периодически (возможно, один раз в день) сохранять содержимое кэша на диск. И я хочу иметь возможность восстановить кеш из сохраненного образа диска.

Сохранение диска не должно быть очень сложным. Если новый ключ / значение добавляется во время сохранения, мне все равно, включено оно в сохранение или нет. И если существующий ключ / значение изменяется во время сохранения, сохраненное значение должно быть либо старым, либо новым значением, но мне все равно, какое именно.

Может ли кто-нибудь порекомендовать другое решение для кэширования (бесплатное или коммерческое), которое имеет все (или значительный процент) важные для меня функции memcached, а также позволяет сохранять и восстанавливать весь кэш с диска?

Answer 1

Я никогда не пробовал, но как насчет redis ?
На домашней странице (цитата) написано:

Redis - это база данных ключ-значение. это похож на memcached но набор данных не является изменчивым, и значения могут быть строки, как в memcached, но также списки и наборы с атомным операции над элементами push / pop.

Чтобы быть очень быстрым, но на в то же время постоянный весь набор данных берется в память и время от времени время и / или когда ряд изменений к набору данных выполняются это записывается асинхронно на диск. Вы может потерять несколько последних запросов, приемлемо во многих приложениях, но это так же быстро, как в памяти БД (Redis поддерживает неблокирующее master-slave репликация для того, чтобы решить эту проблему проблема с резервированием).

Кажется, это отвечает на некоторые вопросы, о которых вы говорили, так что, может быть, это может быть полезно в вашем случае?

Если вы попробуете это, мне очень интересно, что вы узнаете, кстати; -)

В качестве примечания: если вам нужно записать все это на диск, возможно, система cache не совсем то, что вам нужно ... в конце концов, если вы используете memcached в качестве cache вы должны быть в состоянии повторно заполнить его по требованию, когда это необходимо - тем не менее, я признаю, могут быть некоторые проблемы с производительностью, если весь кластер memcached падает сразу ...

Так, может быть, может помочь какое-то "больше" программного обеспечения, ориентированного на хранилище ключей / значений? Например, что-то вроде CouchDB ?
Вероятно, это будет не так быстро, как memcached, поскольку данные хранятся не в ОЗУ, а на диске ...

Answer 2

Может быть, ваша проблема, как моя: у меня есть только несколько машин для memcached, но с большим количеством памяти. Даже если один из них выходит из строя или нуждается в перезагрузке, это серьезно влияет на производительность системы. В соответствии с оригинальной философией memcached я должен добавить гораздо больше машин с меньшим объемом памяти на каждой, но это не является экономически эффективным и не совсем «зеленым»;)

Для нашего решения мы создали интерфейсный уровень для системы Cache таким образом, чтобы поставщики для базовых систем кэширования могли быть вложенными , как вы можете делать с потоками, и написали поставщика кэша для memcached как а также наш собственный очень простой поставщик хранилища ключей Key-Value-2. Затем мы определяем вес для элементов кэша, который показывает, насколько затратным является восстановление элемента, если его невозможно извлечь из кэша. Вложенный дисковый кеш используется только для элементов с весом выше определенного порога, возможно, около 10% всех элементов.

При сохранении объекта в кэше мы не потеряем время, так как сохранение в один или оба кэша в любом случае ставится в очередь для асинхронного выполнения. Так что запись в дисковый кеш не должна быть быстрой. То же самое для чтения: сначала мы обращаемся к memcached, и только если его там нет и это «дорогой» объект, затем мы проверяем дисковый кеш (который на несколько медленнее чем memcached, но все же намного лучше, чем пересчитывает 30 ГБ данные после одной машины вышли из строя).

Таким образом, мы получаем лучшее из обоих миров, не заменяя memcached чем-то новым.

Answer 3

EhCache имеет режим «постоянный диск», который при завершении работы сбрасывает содержимое кэша на диск и восстанавливает данные при повторном запуске. Что касается ваших других требований, при работе в распределенном режиме он реплицирует данные на все узлы, а не хранит их только на одном. кроме этого, он должен хорошо соответствовать вашим потребностям. Он также все еще находится в активной разработке, чего нет у многих других фреймворков Java-кэширования.

Answer 4

Попробуйте go-memcached - сервер memcache, написанный на Go . Сохраняет кэшированные данные на диск из коробки. Go-memcached совместим с клиентами memcache. В оригинальном memcached отсутствуют следующие функции:

• Кэшированные данные выживают при сбоях и / или перезапусках сервера.
• Размер кэша может превышать доступный объем ОЗУ на несколько порядков.
• Размер ключа не может быть меньше 250 байт.
• Нет предела в 1 МБ для размера значения. Размер значения на самом деле ограничен 2Gb.
• Это быстрее, чем оригинал memcached . При обслуживании входящих запросов также используется меньше ресурсов ЦП.

Вот номера исполнения, полученные с помощью go-memcached-bench :

-----------------------------------------------------
|            |  go-memcached   | original memcached |
|            |      v1         |      v1.4.13       |
| workerMode ----------------------------------------
|            | Kqps | cpu time |  Kqps  | cpu time  |
|----------------------------------------------------
| GetMiss    | 648  |    17    |  468   |   33      |
| GetHit     | 195  |    16    |  180   |   17      |
| Set        | 204  |    14    |  182   |   25      |
| GetSetRand | 164  |    16    |  157   |   20      |
-----------------------------------------------------

Статически связанные двоичные файлы для go-memcached и go-memcached-bench доступны на странице загрузок .

Answer 5

Я думаю мембрана это то, что вы хотите.

Answer 6

Взгляните на Apache Java Caching System (JCS)

JCS - распределенная система кеширования написано в Java. Предназначен для ускорить приложения, предоставляя средства для управления кэшированными данными различных динамические натуры. Как и любое кеширование система, JCS наиболее полезна для высоких читать, низко ставить приложения. Задержка времена резко падают и узкие места отойти от базы данных в эффективно кэшированная система. Узнать, как начать использовать JCS.

JCS выходит за рамки простого кэширования объекты в памяти. Это обеспечивает многочисленные дополнительные функции:

* Memory management
* Disk overflow (and defragmentation)
* Thread pool controls
* Element grouping
* Minimal dependencies
* Quick nested categorical removal
* Data expiration (idle time and max life)
* Extensible framework
* Fully configurable runtime parameters
* Region data separation and configuration
* Fine grained element configuration options
* Remote synchronization
* Remote store recovery
* Non-blocking "zombie" (balking facade) pattern
* Lateral distribution of elements via HTTP, TCP, or UDP
* UDP Discovery of other caches
* Element event handling
* Remote server chaining (or clustering) and failover
* Custom event logging hooks
* Custom event queue injection
* Custom object serializer injection
* Key pattern matching retrieval
* Network efficient multi-key retrieval

Answer 7

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

Вы можете масштабировать записи путем разделения между несколькими экземплярами общего доступа. Вы можете масштабировать чтения N-кратно, используя решение, такое как repcached (replicated memcached).

Если это не тривиально для вас, вы все равно можете использовать sharedanced в качестве базовой замены memcached. Это быстро, большинство вызовов файловой системы в конечном итоге кэшируются - использование memcached в сочетании с совместным использованием позволяет избежать чтения из общего доступа, пока не истечет срок действия некоторых данных в memcache. Перезапуск серверов memcached приведет к тому, что все клиенты будут читать из экземпляра общего доступа по крайней мере один раз - на самом деле это не проблема, если только вы не обладаете чрезвычайно высоким параллелизмом для одних и тех же ключей и клиенты конкурируют за один и тот же ключ.

Существуют определенные проблемы, если вы имеете дело со средой с высокой интенсивностью трафика, одна из них - выбор файловой системы (reiserfs работает в 5-10 раз лучше, чем ext3 из-за некоторого внутреннего кэширования дерева fs), она не поддерживает udp (Keepalive TCP - это непроизводительные затраты, если вы используете только совместное использование, memcached имеет udp благодаря команде Facebook), и масштабирование обычно выполняется для вашего приложения (путем разделения данных между несколькими экземплярами серверов совместного использования).

Если вы можете использовать эти факторы, то это может быть хорошим решением для вас. В нашей текущей настройке один общий сервер / сервер memcache может масштабировать до 10 миллионов просмотров страниц в день, но это зависит от приложения. Мы не используем кэширование для всего (например, для Facebook), поэтому результаты могут отличаться в зависимости от вашей заявки.

И вот, спустя 2 года, Membase - отличный продукт для этого. Или Redis, если вам нужны дополнительные функции, такие как хеши, списки и т. Д.

Answer 8

Вы можете использовать Tarantool (http://tarantool.org). Это база данных в памяти с постоянством, репликацией мастер-мастер и правилами истечения срока действия ключа в сценариях - https://github.com/tarantool/expirationd

Answer 9

memcached можно заменить на Couchbase - это открытый исходный код и коммерческое продолжение этой линейки продуктов. Он содержит данные на диске (очень эффективный и настраиваемый). Также оригинальные авторы memcached работали над Couchbase и его совместимостью с протоколом memcached - так что вам не нужно менять код вашего клиентского приложения! Это очень эффективный продукт, включающий кластеризацию 24/7 и перекрестную репликацию центра обработки данных (XDCR) . См. техническую документацию .

Answer 10

Oracle NoSQL основан на BerkeleyDB (решение, на которое указал Билл Карвин), но добавляет шардинг (разделение набора данных) и эластичное масштабирование. Смотри: http://www.oracle.com/technetwork/products/nosqldb/overview/index.html

Я думаю, что он отвечает всем требованиям исходного вопроса.

Ради полного раскрытия я работаю в Oracle (но не над продуктом Oracle NoSQL). Мнения и взгляды, выраженные в этом посте, являются моими собственными и не обязательно отражают мнения или взгляды моего работодателя.