GoldenLine
Zaloguj się
Roman Piekarski

Roman Piekarski Programista do
wynajęcia

Temat: cache a płaska tabela baz danych

Witam,

Mam maly dylemat optymalizacyjny. Mam kilka tabel gdzie główna tabela łączy się z kilkoma innymi w zależnościach n do m. Biorąć pod uwagę , że wyświetlając listę powiedzmy "produktów" wraz prezentacją detali muszę wykonać joina na wielu tabelach.

Przypadek pierwszy. W celu optymalizacji stosuję cache odswierzany raz dziennie. Zyskuje na tym odciążenie bazy danych i ograniczenie się do wielotabelowego joina na danych pulach id do jednego razu (przy pierwszym razie dla danej akcji/ident generuje się cache)

Przypadek drugi. W celu optymalizacji stosuję cache odswierzany raz dziennie oraz tworzę proces crona, który uzupełnia mi "jedną" tabelę we wszystkie powiązane z nią dane (n - m) tworząc tabelę płaską wraz ze wszelkimi detalami (synchronizacja raz dziennie).
Zyskuję na tym ograniczenie się do prostego selekta raz dziennie dla danych pul id (przy pierwszym razie dla danej akcji/ident generuje cache).

Moje pytanie brzmi: czy warto w takim przypadku bawic się w mechanizm synchronizujący? Logicznie rzecz biorąc zastosowanie dynamicznego cache i tak w znacznym stopniu odciąża nam bazę danych. Z drugiej strony synchronizowana "tabela płaska"/myisam i tak zostanie stworzona dla mechanizmu full text search.

Jaka jest wasza opinia? Liczę na ciekawą dyskusją

PozdrawiamRoman Piekarski edytował(a) ten post dnia 14.06.09 o godzinie 18:20
Link do wypowiedziLink
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: cache a płaska tabela baz danych

o jakich ilościach rekordów tu dyskutujemy?
Link do wypowiedziLink
Roman Piekarski

Roman Piekarski Programista do
wynajęcia

Temat: cache a płaska tabela baz danych

od kilkunastu tysięcy do kilkudziesięciu dla tabeli plaskiejRoman Piekarski edytował(a) ten post dnia 14.06.09 o godzinie 18:19
Link do wypowiedziLink

konto usunięte

Temat: cache a płaska tabela baz danych

Roman Piekarski:
Jaka jest wasza opinia? Liczę na ciekawą dyskusją

Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć :)

Rozwiązanie z cache jest lepsze, ponieważ ogranicza w znacznym stopniu ilość operacji I/O na dysku.
Link do wypowiedziLink
Roman Piekarski

Roman Piekarski Programista do
wynajęcia

Temat: cache a płaska tabela baz danych

Krzysztof P.:
Roman Piekarski:
Jaka jest wasza opinia? Liczę na ciekawą dyskusją

Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć Odświeżyć :)

Rozwiązanie z cache jest lepsze, ponieważ ogranicza w znacznym stopniu ilość operacji I/O na dysku.

A co w przypadku dodatkowego splaszczenia danych, pozbywamy się zbednych joinow
Link do wypowiedziLink
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: cache a płaska tabela baz danych

Roman Piekarski:
od kilkunastu tysięcy do kilkudziesięciu dla tabeli plaskiejRoman Piekarski edytował(a) ten post dnia 14.06.09 o godzinie 18:19

IMHO, dla takiej ilości nie ma sensu robić żadnego cache...
Link do wypowiedziLink

konto usunięte

Temat: cache a płaska tabela baz danych

Wojciech Sznapka:
Roman Piekarski:
od kilkunastu tysięcy do kilkudziesięciu dla tabeli plaskiej

IMHO, dla takiej ilości nie ma sensu robić żadnego cache...

Ciekawe ze jestes w stanie to stwierdzic nie znajac ruchu na serwerze.

Rozwiazanie 2 ma tylko sens, jesli korzystasz tej z funkcji agregujacych. Inaczej to sie mija z celem.

Ale pobaw sie najpierw z cache'm wbudowanym w MySQL - mozliwe ze dobra konfiguracja bedzie wystarczajaca.Marcin Bachleda edytował(a) ten post dnia 14.06.09 o godzinie 21:50
Link do wypowiedziLink
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: cache a płaska tabela baz danych

Marcin Bachleda:
Wojciech Sznapka:
Roman Piekarski:
od kilkunastu tysięcy do kilkudziesięciu dla tabeli plaskiej

IMHO, dla takiej ilości nie ma sensu robić żadnego cache...

Ciekawe ze jestes w stanie to stwierdzic nie znajac ruchu na serwerze.

jeśli ruch jest wielki, to mysql sam zadba o cache. nie ma co strzelać z armaty do komarów.Wojciech Sznapka edytował(a) ten post dnia 14.06.09 o godzinie 22:05
Link do wypowiedziLink

konto usunięte

Temat: cache a płaska tabela baz danych

Wojciech Sznapka:
Marcin Bachleda:
Wojciech Sznapka:
Roman Piekarski:
od kilkunastu tysięcy do kilkudziesięciu dla tabeli plaskiej

IMHO, dla takiej ilości nie ma sensu robić żadnego cache...

Ciekawe ze jestes w stanie to stwierdzic nie znajac ruchu na serwerze.

jeśli ruch jest wielki, to mysql sam zadba o cache. nie ma co strzelać z armaty do komarów.Wojciech Sznapka edytował(a) ten post dnia 14.06.09 o godzinie 22:05

Przeciez wlasnie o to chodzi, zeby nie ciagnac z bazy tylko z ramu przy duzym obciazeniu (chyba ze master stoi na typie MEMORY)
Link do wypowiedziLink
Roman Piekarski

Roman Piekarski Programista do
wynajęcia

Temat: cache a płaska tabela baz danych

Marcin Bachleda:
Wojciech Sznapka:
Marcin Bachleda:
Wojciech Sznapka:
Roman Piekarski:
od kilkunastu tysięcy do kilkudziesięciu dla tabeli plaskiej

IMHO, dla takiej ilości nie ma sensu robić żadnego cache...

Ciekawe ze jestes w stanie to stwierdzic nie znajac ruchu na serwerze.

jeśli ruch jest wielki, to mysql sam zadba o cache. nie ma co strzelać z armaty do komarów.Wojciech Sznapka edytował(a) ten post dnia 14.06.09 o godzinie 22:05

Przeciez wlasnie o to chodzi, zeby nie ciagnac z bazy tylko z ramu przy duzym obciazeniu (chyba ze master stoi na typie MEMORY)

W moim przypadku akurat nie ma mowy o tabelach MEMORY. Robie wyszukiwanie na full text search gdzie wymogiem jest myisam. Chce ta sama tabele wykozystac przy listowaniu po kategoriach. Dlatego w celu maxymalenej optymalizacji chce splaszczyc dane n-m w jednej tabeli. Pytanie czy sie to oplaca? Osobiscie uwazam, ze tak bo jezeli w pewnym momencie projekt zacznie przekraczac obciazenie w ktorym wielotabelowe joiny zaczely by przeciazac server to przy prostych selektach na splaszczonej tabeli server ta tego nie odczuje.

Pytanie tylko, czy gromadzac wszystkie dane w jednej tabeli nie wplynie to negatywnie na mechanizm full text search ktory bedzie indexowal tylko dwie z kilkunastu kolumn?
Link do wypowiedziLink

konto usunięte

Temat: cache a płaska tabela baz danych

A dlaczego nie nie Sphinx czy Lucene?
Link do wypowiedziLink
Roman Piekarski

Roman Piekarski Programista do
wynajęcia

Temat: cache a płaska tabela baz danych

Marcin Bachleda:
A dlaczego nie nie Sphinx czy Lucene?

Niestety te mechanizmy niezostaly uwzglednione w specyfikacji, dlatego rozwiazuje problem wlasnie w ten sposob. Sam z checia skozystal bym z xapiana, ale w tym przypadku mam ograniczone mozliwosci.
Link do wypowiedziLink
Robert B.

Robert B. Web Development
Manager

Temat: cache a płaska tabela baz danych

Roman Piekarski:

Pytanie tylko, czy gromadzac wszystkie dane w jednej tabeli nie wplynie to negatywnie na mechanizm full text search ktory bedzie indexowal tylko dwie z kilkunastu kolumn?
Witam,

Nie do końca rozumiem zadany przez Ciebie probem, ale spróbuje sprecyzować rozwiązanie które być może Ci pomoże.

Liczba kolumn nie powinna mieć znaczenia, o ile jest założony index na primary key (a idea primary key zakłada nie-w-prost także istnienie indexu i baza danych wymusza index). Istnienie tabeli jako ENGINE=MEMORY także jest możliwe:

Zakładam, że masz bazę InnoDB, a tylko jedna tabela musi mieć MyISAM ze względu na full text search. Jak najbardziej słuszym rozwiązaniem jest zastosowanie snapshot'a (materialized view) i może on istnieć jako ENGINE=MEMORY. Sam napisałeś, że będziesz indeksował tylko dwie kolumny do wyszukiwania, więc proponuję zrobić
tabelę która będzie snapshotem z zapytania + dodatkowa tabela do wyszukiwania - nie wiem jak ją tworzysz, ale możesz ją utrzymywać za pomocą triggerów na tabeli(tabelach) w których są kolumny po których masz zamiar szukać.
Następnie użytkownikowi zwracasz join z tych dwóch tabel (szybki, bo JOIN będzie robiony na kolumnach primary key) i sprawę masz załatwioną.
Link do wypowiedziLink

konto usunięte

Temat: cache a płaska tabela baz danych

Roman Piekarski:
Pytanie tylko, czy gromadzac wszystkie dane w jednej tabeli nie wplynie to negatywnie na mechanizm full text search ktory bedzie indexowal tylko dwie z kilkunastu kolumn?

Chyba najlepiej by zrobić tabelę typu "ekstrakt" dla full-texta + dodatkowe tabele z atrybutami (nie znam tematu, ale być może "cena" lub "kolor"). Ta pierwsza byłaby uzupełniana raz na n (dni, godzin...). Chyba całkiem nieźle jest to zrobione w Drupalu.
Jest tam taki cache który obsługuje też w miarę zgrabnie (pod względem ideologicznym, nie wiem jak wydajnościowym) komendę "invalidate" - czyli usunięcie segmentu danych z cache'a.
Link do wypowiedziLink

konto usunięte

Temat: cache a płaska tabela baz danych

Roman Piekarski:
od kilkunastu tysięcy do kilkudziesięciu dla tabeli plaskiejRoman Piekarski edytował(a) ten post dnia 14.06.09 o godzinie 18:19

Przy takiej ilości danych, to nawet potrójny join nie powinien zbytnio obciążać bazy.
Czy mysql cache to łyka? Ile trwa zrobienie takiego zapytania za pierwszym razem a ile takiego samego za drugiem?
Moim zdaniem coś w zapytaniu jest skopane (np występuje rand() czy unix_timestamp()) albo indexów brakuje.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Wiele baz danych - jako jedna?




Wyślij zaproszenie do
Anuluj