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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

Здесь приведены числа производительности, полученные с помощью 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 доступны на странице страница загрузки.

Ответ 5

Взгляните на 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

Ответ 6

Я думаю, membase - это то, что вы хотите.

Ответ 7

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

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

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

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

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

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

Ответ 8

Как насчет Terracotta?

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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

Ответ 12

Вы посмотрели BerkeleyDB?

• Быстрое, встроенное, управление процессами в процессе.
• Хранилище ключей/значений, нереляционное.
• Постоянное хранилище.
• Свободный, открытый источник.

Однако он не отвечает одному из ваших критериев:

• BDB поддерживает распределенную репликацию, но данные не секционируются. Каждый node хранит полный набор данных.

Ответ 13

Мы используем OSCache. Я думаю, что он отвечает почти всем вашим потребностям, за исключением периодического сохранения кеша на диске, но вы должны иметь возможность создавать 2 менеджера кэша (один на основе памяти и один на основе hdd) и периодически запускать java cronjob, который проходит через весь ключ кеша в памяти/пары значений и помещает их в кеш hdd. Что приятно о OSCache, так это то, что он очень прост в использовании.

Ответ 14

Вы можете использовать GigaSpaces XAP, который является зрелым коммерческим продуктом, который отвечает вашим требованиям и многое другое. Это самая быстрая распределенная сетка данных в памяти (cache ++), она полностью распределена и поддерживает несколько стилей методов сохранения.

Гай Нирпас, GigaSpaces

Ответ 15

Просто для завершения этого списка - я только что нашел couchbase. Однако я еще не тестировал его.