Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: MySQL - klucze obce oraz priorytety zapytań
Forum PHP.pl > Forum > Bazy danych > MySQL
1stfrog
Witam!

Zwracam się do szanownego grona specjalistów o pomoc w dwóch ( jak na razie) sprawach :

1. Na serwerze umieszczona jest baza MySQL oraz serwer aplikacji, z ktorym połączonych jest kilkaset urządzen, ktore co kilka-kilkanście sekund przysyłają dane, ktore wymagają aktualizacji bazy danych (zapisywanie wyników oraz aktualizacja danych o stanie urządzenia). Na tym serwerze umieszczone są także skrypty php, które pozwalają na monitorowanie stanu poszczególnych urządzeń oraz tworzenie statystyk. Problem polega na tym, że w momencie gdy zażyczymy sobie zrobienia statystyk ze wszystkich urządzeń na raz, ogrom danych, które muszą być wyszukane, sortowane itp jest tak duza (tabela logów zawiera kilkaset tysięcy - kilka milionów rekordów), że przez kilka minut serwer aplikacji ma problem z obsłużeniem połączeń z urządzeniami (na urządzeniach wyskakują timeouty związane z nieodpowiedzeniem serwera aplikacji w zadanym czasie, co jest spowodowane (wg mnie) niewykonaniem aktualizacji bazy danych w zadanym czasie w związku z czasochłonnymi wątkami zapytań statystycznych ).
Moje pytanie brzmi: czy możliwe jest ustawianie priorytetu dla poszczególnych odwołań do bazy danych, tzn. czy np zapytaniom związanym ze statystyką można przydzielić niższy priorytet niż zapytaniom aktualizującym dane?

2. Bardziej szczegółowe:
Mamy tabele urządzeń i systemów składających się z 3 urządzeń:

tbl_urzadzenie
ID_urzadzenia int (PRIMARY KEY)
...

tbl_system
ID_system int (PRIMARY KEY)
ID_urz1 int
ID_urz2 int
ID_urz3 int

ID_urza1-3 są kluczami obcymi wskazującymi na ID_urzadzenia w tbl_urzadznie.
Moje pytanie brzmi:

czy dla każdego z pol ID_urz1-3 tworzyć osobny klucz obcy czy też 1 klucz obcy powinien składać się z tych 3 pól. Dla tego drugiego przypadku MySQL Workbench wygenerował taki kod:

CONSTRAINT `FOREIGN_URZ1`
FOREIGN KEY (`ID_urz1` , `ID_urz2` , `ID_urz3` )
REFERENCES `main_srv`.`tbl_urzadzenie` (`ID_urzadzenia` , `ID_urzadzenia` , `ID_urzadzenia` )
ON DELETE NO ACTION
ON UPDATE NO ACTION)

Nie za bardzo rozumię jak to działa w przypadku złożonego klucza obcego więc jakby ktoś mógł mi to wytłumaczyć to byłbym bardzo zobowiązany.

Pozdrawiam
Artur
1stfrog
Dzieki za odpowiedź smile.gif

Opcja ciekawa,pobawie się nią trochę, niestety nie działa z InnoDB, nie za bardzo jest też do zastosowania w momencie, gdy jako odpowiedz urządzenie dostaje nie tylko status zapisu do logow, ale także informacje wymagające wykonania zapytania SELECT ( pobranie informacji typu wyłącz, zrestartuj, przejdź w inny tryb lub podobne).

Jest możliwe ( zapewne jest ) tworzenie tabel z rożnymi silnikami (jedna InnoDB, druga MyISAM)?
No i jak to się ma do pracy całej bazy (wydajność itp)?

Ktoś wie coś może na temat drugiego pytania?

Pozdrawiam
Artur
sn1p3r
Cytat(1stfrog @ 11.03.2011, 15:11:15 ) *
Jest możliwe ( zapewne jest ) tworzenie tabel z rożnymi silnikami (jedna InnoDB, druga MyISAM)?
No i jak to się ma do pracy całej bazy (wydajność itp)?


Jest możliwe smile.gif
Wydajność zależy od tylu rzeczy, że nie można jednoznacznie powiedzieć czy będzie lepiej czy wolniej.
Odnośnie Twojej bazy - zobacz czy nie masz za mało/za dużo indeksów.

W Twoim przypadku postawiłbym drugą maszynkę z bazą slave - na niej możesz wykonywać te długie, wolne operacje.



Cytat(1stfrog @ 11.03.2011, 00:53:51 ) *
2. Bardziej szczegółowe:
Mamy tabele urządzeń i systemów składających się z 3 urządzeń:

tbl_urzadzenie
ID_urzadzenia int (PRIMARY KEY)
...

tbl_system
ID_system int (PRIMARY KEY)
ID_urz1 int
ID_urz2 int
ID_urz3 int


Proponuje dodać tabelkę

Tabelka Urzadzenie_System
|id_urzadzenie | id_system|


i z tabelki system wywalic te ID_urz*
1stfrog
Dzieki śliczne za odpowiedź i sugestie smile.gif

Ma ktoś może pojęcie jak dużym obciążeniem dla bazy głównej będzie replikacja na slave-ie przy zapisach kilkuset logów na sekundę? Ktoś ma z tym jakieś doświadczenia? Byłbym bardzo wdzięczny za odpowiedź smile.gif

Pozdrawiam
Artur
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.