2012-02-09 11 views
14

Mam serwer Debiana z około 16 GB pamięci RAM, którego używam z nginx i kilkoma ciężkimi bazami danych mysql oraz niektórymi niestandardowymi aplikacjami php. Chciałbym zaimplementować pamięć podręczną pamięci między MySQL i PHP, ale bazy danych są zbyt duże, aby przechowywać wszystko w pamięci RAM. Myślę, że pamięć podręczna LRU może być lepsza, o ile ja badam. Czy to wyklucza Redis? Couchbase również jest brany pod uwagę.Memcached, Redis lub Couchbase

Odpowiedz

15

Załóżmy, że istnieje unikalny serwer z uruchomionymi instancjami nginx + php + mysql z pewną pozostałą wolną pamięcią RAM, najprostszym sposobem użycia tej pamięci RAM do buforowania danych jest po prostu zwiększenie buforów buforów instancji mysql. Bazy danych używają już mechanizmów podobnych do LRU do obsługi swoich buforów.

Teraz, jeśli konieczne jest przeniesienie części przetwarzania z baz danych, może być opcja buforowania wstępnego. Przed omówieniem memcached/redis, współdzielona pamięć podręczna zintegrowana z php, taka jak APC, będzie wydajna pod warunkiem, że rozważany jest tylko jeden serwer (w rzeczywistości bardziej wydajny niż redis/memcached).

Zarówno memcached, jak i redis można uznać za zdalne buforowanie (tj. Udostępnianie pamięci podręcznej między różnymi węzłami). Nie wykluczę tego w tym celu: można go łatwo skonfigurować w tym celu. Obie pozwolą zdefiniować limit pamięci i obsłużyć pamięć podręczną z zachowaniem podobnym do LRU.

Jednakże, nie używałbym tutaj bazy na kanapę, która jest elastyczna (tj. Powinna być używana na kilku węzłach) w magazynie klucz/wartość NoSQL (to znaczy nie w pamięci podręcznej). Prawdopodobnie możesz przenieść niektóre dane z instancji mysql do klastra typu couchbase, ale używanie go tylko do buforowania to nadinżynieria IMO.

+0

Użyłem APC, ale skrypty php cli, których używamy w aplikacji internetowej, nie mają dostępu do tych samych danych. Właśnie tam memcached stał się pierwszym następnym logicznym krokiem. Patrzyłem na couchbase, ponieważ przeczytałem, że był to nieulotny (w razie potrzeby) drop-in zastępujący memcached mniej więcej. – Poe

+19

Couchbase należy wziąć pod uwagę, ponieważ ma on zwykły, stary tryb memcached (zwany wiadrem), ale ułatwia zarządzanie, zarządza statystykami itp. Pełne ujawnienie: Pracuję dla Couchbase. –

1

Początkowo używaliśmy memcached do przechowywania danych w pamięci podręcznej. Wczytane dane partycjonowania dla różnych aplikacji w różnych zasobnikach były prawdziwym problemem. Musimy również spłukiwać dane z jednego wiadra. Dane z monitorowania to kolejne wymaganie. Przenieśliśmy się do CouchBase i użyj zapamiętywanego stylu wiadra.i zgadnij, że jest on znacznie bardziej elastyczny i efektywny w użyciu buforowania w stylu memcache do buforowania, niż używania memcahe.

+0

Jest to typowy przypadek użycia dla użytkowników pamięci podręcznej/pamięci podręcznej, aby przejść do Couchbase (z zasobnikiem memcache, a czasami z Couchbase).Zapraszam do obejrzenia strony http://www.couchbase.com/memcached –

0

Jak zauważył Matt Ingenthron, Hari zauważył, że Couchbase wspiera pracę jako bezpośredni zamiennik Memcached. Couchbase wykorzystuje memcached w sposób nieelastyczny, ponieważ każdy węzeł uczestniczący w klastrze memcache jest dyskretny i nie ma trwałości, tj. Tylko pamięć podręczna, ale baza podręczna oferuje również typy wiaderek "Couchbase", które zapewniają trwałość. Membase jest również częścią kodu, więc Couchbase nie tylko dostarcza danych z dysku, ale także z pamięci RAM i utrzymuje go tam podczas replikowania do innych węzłów i utrzymywania na dysku w miarę wprowadzania zmian. Gorąco polecam Couchbase 3.x zarówno dla buforowania i utrzymywania w jednym miejscu, jak i wielu footprintów, jeśli chciałeś tylko warstwy pamięci podręcznej oddzielonej od warstwy trwałości.

1

Czy kiedykolwiek rozważałeś przeniesienie swoich baz danych do pamięci RAM za pomocą jednego z wbudowanych w NoSQL rozwiązań z wytrwałością? Może to zająć mniej miejsca niż oryginalna baza danych MySQL, ponieważ wiele rozwiązań NoSQL zwykle ma mniejszą powierzchnię niż bazy danych SQL. Poza tym, jeśli logika po stronie serwera jest dla ciebie bardzo ważna, wypróbuj Tarantool, ponieważ ma wbudowaną obsługę Lua i powinien mieć dość mały ślad pamięci. W moich przypadkach te same dane w Tarantool zajęły dwa razy mniej niż w MySQL. Dzieje się tak dlatego, że mają mały narzut na wiersz i pole oraz używają pakietu komunikatów do przechowywania danych.