2009-05-11 14 views
19

Strona, którą tworzę w php, powoduje, że wiele żądań baz danych MySQL na stronę jest przeglądanych. Chociaż wiele z nich to małe żądania z właściwie zaprojektowanymi indeksami. Nie wiem, czy warto byłoby opracować skrypt pamięci podręcznej dla tych stron.Prędkość dostępu do pliku w porównaniu do prędkości dostępu do bazy danych

1) Czy operacje we/wy pliku są ogólnie szybsze niż żądania bazy danych? Czy to zależy od serwera? Czy istnieje sposób sprawdzenia, z iloma serwerami może sobie poradzić?

2) Jedna ze stron sprawdza bazę danych dla pliku, a następnie sprawdza serwer, czy istnieje, a następnie decyduje, co wyświetlić. Zakładam, że skorzystałbym z widoku strony z pamięci podręcznej?

Również, jeśli są jakieś inne informacje na ten temat, które możesz przekazać mi do tego byłoby bardzo docenione.

Dzięki

Odpowiedz

10

Jeśli korzystasz z read-heavy (szukanie nazw plików itp.), Możesz skorzystać z memcached. Możesz przechowywać "najgorętsze" (ostatnio utworzone, ostatnio używane, w zależności od aplikacji) dane w pamięci, a następnie zapytać tylko DB (i ewentualnie pliki), gdy pamięć podręczna nie trafi. Dostęp do pamięci jest znacznie, znacznie szybszy niż baza danych lub plików.

Jeśli potrzebujesz dostępu do zapisu, baza danych jest drogą do zrobienia. Jeśli używasz MySQL, użyj tabel InnoDB lub innego silnika obsługującego blokowanie na poziomie wiersza.Pozwoli to uniknąć blokowania ludzi, podczas gdy ktoś inny pisze (lub, co gorsza, pisze w każdym razie).

Ale ostatecznie zależy to od danych.

4

To naprawdę zależy od wielu czynników. Jeśli masz szybką bazę danych z dużą ilością danych zapisanych w pamięci RAM lub szybkim systemie RAID, istnieje duża szansa, że ​​zyskasz wiele z prostego buforowania systemu plików na serwerze WWW. Pomyśl także o skalowalności. Przy dużym obciążeniu pracą prosty mechanizm buforowania może z łatwością stać się szyjką butelki, a baza danych jest dobrze zaprojektowana do obsługi dużych obciążeń roboczych.
Jeśli nie ma zbyt wielu żądań, a Ty (lub system operacyjny) jest w stanie utrzymać pamięć podręczną w pamięci RAM, możesz uzyskać pewną wydajność. Ale teraz pojawia się pytanie, czy naprawdę konieczne jest wykonywanie buforowania przy niskim obciążeniu pracą.

11

To zależy od struktury danych, ich ilości i częstotliwości ich zmiany.

Jeśli masz stosunkowo niewielkie ilości stosunkowo statycznych danych o względnie prostych relacjach - to płaskie pliki są właściwym narzędziem do pracy.

Relacyjne bazy danych stają się samodzielne, gdy połączenia między danymi są bardziej złożone. W przypadku podstawowych tabel "look up" mogą one być nieco przesadzone.

Ale jeśli dane stale się zmieniają, łatwiej będzie po prostu użyć bazy danych niż obsługiwać zarządzanie konfiguracją ręcznie - a przy dużych ilościach danych z plikami płaskimi masz dodatkowy problem jak sprawnie znaleźć to, czego potrzebujesz.

+2

Inną rzeczą, jaką oferują bazy danych, że pliki płaskie nie są kontrolą współbieżności. W kontekście zapisu ciężkiego wiele procesów zapisujących do pojedynczego pliku płaskiego może być problematyczne. Ładnym kompromisem między niestandardowymi, płaskimi plikami i pełnym RDBMS jest SQLite - istnieje więcej niż kilka witryn wspieranych przez SQLite. –

3

Z punktu widzenia wydajności, rozsądniej jest dostroić serwer bazy danych i nie komplikować logiki dostępu do danych z pośrednimi pamięciami podręcznymi plików. Dobry serwer bazy danych sam wykonałby buforowanie, jeśli wyniki są buforowalne. (Nie jestem pewien co to jest w przypadku mysql).

Jeśli masz problemy z wydajnością, powinieneś profilować strony, aby zobaczyć prawdziwe wąskie gardła. Nawet kiedy jesteś - jak ja - fanem zoptymalizowanych kodów, umieszczenie mocniejszego/większego sprzętu w równaniu jest tańsze na dłuższą metę.

Jeśli nadal potrzebujesz korzystać z pamięci podręcznych, rozważ użycie istniejącego rozwiązania, takiego jak memcached.

Powiązane problemy