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

Необходимо изобразить способ заставить ботов купить материал, который в широком масштабе переоценен: 12-миллиметровая крыльчатая гайка: 20$. Посмотрите, на сколько накидываются боты, прежде чем сценаристы решают, что Вы играете их.

Использование прибыль для покупки большего количества серверов и платы за пропускную способность.

51
задан Mike W 22 August 2009 в 09:20
поделиться

9 ответов

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

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

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

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

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

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

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

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

16
ответ дан 7 November 2019 в 10:15
поделиться

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

1
ответ дан 7 November 2019 в 10:15
поделиться

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

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

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

  • BDB поддерживает распределенную репликацию, но данные не разделены. Каждый узел хранит полный набор данных.
2
ответ дан 7 November 2019 в 10:15
поделиться

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

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

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

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

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


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

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

19
ответ дан 7 November 2019 в 10:15
поделиться

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

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

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

 * Управление памятью
* Переполнение диска (и дефрагментация)
* Управление пулом потоков
* Группировка элементов
* Минимальные зависимости
* Быстрое вложенное категориальное удаление
* Истечение срока действия данных (время простоя и максимальный срок службы)
* Расширяемый фреймворк
* Полностью настраиваемые параметры времени выполнения
* Разделение данных по регионам и конфигурация
* Параметры конфигурации мелкозернистых элементов
* Удаленная синхронизация
* Восстановление удаленного магазина
* Неблокирующий узор «зомби» (упирающийся фасад)
* Боковое распределение элементов через HTTP, TCP или UDP
* UDP Обнаружение других кешей
* Обработка событий элемента
* Объединение удаленных серверов (или кластеризация) и переключение при отказе
* Пользовательские перехватчики регистрации событий
* Пользовательское внедрение очереди событий
* Инъекция пользовательского сериализатора объектов
* Поиск соответствия шаблонов ключей
* Сетевой эффективный поиск нескольких ключей
4
ответ дан 7 November 2019 в 10:15
поделиться

А как насчет Terracotta ?

2
ответ дан 7 November 2019 в 10:15
поделиться

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

Guy Nirpaz, GigaSpaces

1
ответ дан 7 November 2019 в 10:15
поделиться

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

13
ответ дан 7 November 2019 в 10:15
поделиться

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

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

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

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

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

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

3
ответ дан 7 November 2019 в 10:15
поделиться
Другие вопросы по тегам:

Похожие вопросы: