Temat: cache a płaska tabela baz danych - serwis internetowy

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 meniamizmu full text search.

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

Pozdrawiam

Temat: cache a płaska tabela baz danych - serwis internetowy

Roman Piekarski:
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 meniamizmu full text search.

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

Pozdrawiam

Zasadniczo w takich sytuacjach powinno się jednak tworzyć widoki, jednak akurat w MySQL-u nie są one zbyt dobrze zrealizowane.
http://www.mysqlperformanceblog.com/2007/08/12/mysql-v...

Gdybyś jednak zastosował widoki bardzo ważny jest wybór algorytmu:
http://dev.mysql.com/doc/refman/6.0/en/view-algorithms...

Jeśli koniecznie chcesz się bawić w tworzenie osobnej zdenormalizowanej tabeli to mechanizm synchronizujący mógłby być oparty o triggery a nie crona. Tylko znowu np. na home.pl nie można stosowac triggerów w bazie MySQL. Oto Polska właśnie ;-)

Temat: cache a płaska tabela baz danych - serwis internetowy

Wojtek A.:

Roman Piekarski:
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 meniamizmu full text search.

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

Pozdrawiam

Zasadniczo w takich sytuacjach powinno się jednak tworzyć widoki, jednak akurat w MySQL-u nie są one zbyt dobrze zrealizowane.
http://www.mysqlperformanceblog.com/2007/08/12/mysql-v...

Gdybyś jednak zastosował widoki bardzo ważny jest wybór algorytmu:
http://dev.mysql.com/doc/refman/6.0/en/view-algorithms...

Jeśli koniecznie chcesz się bawić w tworzenie osobnej zdenormalizowanej tabeli to mechanizm synchronizujący mógłby być oparty o triggery a nie crona. Tylko znowu np. na home.pl nie można stosowac triggerów w bazie MySQL. Oto Polska właśnie ;-)

Prawde mowiac w tym przypadku trigery w pelni niezrealizuja zadania z tego wzgledu iz istnieja powiazania n-m wielotabelowe. realizujac triger na tabeli n niedostane danych zaktualizowanych w tabelach m. Datego aktualizacje czesciowo realizuje na trigerach i czesciowo w kodzie aplikacji. Po za tym wystepowanie zmian w niektorych tabelach n-m jest zadkie jednak zmiana w tych tabelach wiaze sie z aktualizacja wielu tysiecy rekordow w tabeli zdenormalizowanej, dlatego cron odpalany raz dziennie w nocy jest dobra alternatywa.

Temat: cache a płaska tabela baz danych - serwis internetowy

Roman Piekarski:

Wojtek A.:

Roman Piekarski:
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 meniamizmu full text search.

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

Pozdrawiam

Zasadniczo w takich sytuacjach powinno się jednak tworzyć widoki, jednak akurat w MySQL-u nie są one zbyt dobrze zrealizowane.
http://www.mysqlperformanceblog.com/2007/08/12/mysql-v...

Gdybyś jednak zastosował widoki bardzo ważny jest wybór algorytmu:
http://dev.mysql.com/doc/refman/6.0/en/view-algorithms...

Jeśli koniecznie chcesz się bawić w tworzenie osobnej zdenormalizowanej tabeli to mechanizm synchronizujący mógłby być oparty o triggery a nie crona. Tylko znowu np. na home.pl nie można stosowac triggerów w bazie MySQL. Oto Polska właśnie ;-)

Prawde mowiac w tym przypadku trigery w pelni niezrealizuja zadania z tego wzgledu iz istnieja powiazania n-m wielotabelowe. realizujac triger na tabeli n niedostane danych zaktualizowanych w tabelach m. Datego aktualizacje czesciowo realizuje na trigerach i czesciowo w kodzie aplikacji. Po za tym wystepowanie zmian w niektorych tabelach n-m jest zadkie jednak zmiana w tych tabelach wiaze sie z aktualizacja wielu tysiecy rekordow w tabeli zdenormalizowanej, dlatego cron odpalany raz dziennie w nocy jest dobra alternatywa.

A te zadania za każdym razem są podobne i wyniki nie przekraczają np. 5mb pamięci? Bo jeśli tak proponuje użyć querycache. Tylko wtedy trzeba pamiętać o tym że MySQL sprawdza zapytania case-sensitive - więc muszą DOKŁADNIE być takie same.