Jakie rozwiązanie lepsze wydajnościowo ?, Wiele baz, jeszcze więcej tabel czy miliony rekordów ? Opcje

[ramol]

Witam,

nie jestem specjalistą od baz danych dlatego postanowiłem zapytać tutaj. Proszę o wypowiedzi osób, które mają doświadczenie w tym temacie. Teoretyzować sam mogę

Problem:
Na serwerze należy zainstalować, na początek, 1000 aplikacji jednego typu ( np. forum phpBB, joomla, wordpess ). Faktem jest, że ostatecznie będzie używana tylko i wyłącznie ta jedna wybrana aplikacja. Przyjmijmy w przykładzie, że będzie to jakieś forum aby zasygnalizować problem wydajności.
Można wykonać takie zadanie na trzy sposoby:
1. Instalacja każdej instancji aplikacji na osobnej bazie
2. Jedna baza danych i wiele prefixowanych tabel
3. Jedna baza danych, jeden prefix tabel ale za to dodatkowe pole rozróżniające instancje aplikacji.

Nie można założyć, że wszystkie aplikacje będą pracować pod dużym obciążeniem - mogą być używane nawet bardzo sporadycznie. Może również dojść do sytuacji gdy będzie potrzebny drugi serwer - należy więc zwrócić uwagę na ciągłość danych.

Jeżeli ktoś pracował nad podobnym zagadnieniem to chętnie poznam sugestie i uwagi.

[wookieb]

Oddzielna baza dla kazdej aplikacji.

[Mchl]

Oddzielna baza dla kazdej aplikacji.

QFT

[mkozak]

W sumie jeżeli chodzi o MySQL-a to nie ma to takiego dużego znaczenia.

Porozkładanie po różnych bazach to jedynie szybszy listing wszystkich tabel no i tak wizualnie łatwiejsze do ogarnięcia (bkpy, dumpy, dropy). W mysql baza danych to katalog (upraszczając - bo jeszcze są dane przechowywane w tabelach systemowych), a tabela i jej index to dwa pliki.
Jeżeli masz dużo dysków to część tabel/baz możesz poprzesuwać na inne woluminy. Np.: połowa baz/tabel systemów na jednym dysku, a druga na drugim.

Rozwiązanie nr 3 jest najgorsze - wszystko w jednej tabeli (np.: 4 fora phpbb z takimi samymi tabelami i pole rozróżniające) - dużo danych do zarządzania/przeszukania.

W dokumentacji od create table (http://dev.mysql.com/doc/refman/5.1/en/create-table.html) masz opisane opcje DATA DIRECTORY, INDEX DIRECTORY.

[Mchl]

W sumie jeżeli chodzi o MySQL-a to nie ma to takiego dużego znaczenia.

Nie zgodzę się. Z 1000 instancji tej samej aplikacji niemożliwe jest, żeby wszystkie były wykorzystywane w jednakowym stopniu. Podział na wiele baz ułatwi na przykład migrację mocniej obciążonych instancji na osobne serwery. Gdyby siedziało to w jednej bazie trzeba by się bawić w klastrowanie.

Ten post edytował Mchl 28.07.2010, 12:50:26

[everth]

Skłaniam się ku rozwiązaniu 2. Tylko dlatego że ciężko mi się zarządza setkami baz w mysql. Rozwiązanie 3 sobie skreśl (za dużo kombinowania, czytaj błędów)

[wookieb]

To może odpowiedzią na pytanie będzie. Czy ktokolwiek z was tworzył wszystkie swoje aplikacji na JEDNEJ bazie danych? Odpowiedź zapewno 1%, który nie znał składni polecenia CREATE DATABASE. Po prostu 1 projekt = 1 baza i utrzymujesz czysty logiczny porządek.

[everth]

Zakładając przy tym że ma się takie uprawnienia. Ja zakładam że zazwyczaj takich uprawnień się nie ma (jedna baza -> jeden użytkownik). Ale pomijając to, to masz rację

[Mchl]

Zakładając przy tym że ma się takie uprawnienia. Ja zakładam że zazwyczaj takich uprawnień się nie ma (jedna baza -> jeden użytkownik). Ale pomijając to, to masz rację

Bardzo dziwne założenie...

[ramol]

Dzięki za odpowiedzi.
Ja sam pkt.3 od razu skreśliłem bo to niesamowity bałagan .. no ale musiałem spytać.
Co do punktów 1 i 2 - ja obstawiałbym 1 z tego powodu, jak pisał Mchl, że można spokojnie przenieść bardziej obciążoną instancję na inny serwer. Jest to też jakby logiczne z punktu widzenia sensu baz danych. Ogólnie ciężko mi sobie wyobrazić 1k baz danych i stąd to pytanie.

[mkozak]

Nie zgodzę się. Z 1000 instancji tej samej aplikacji niemożliwe jest, żeby wszystkie były wykorzystywane w jednakowym stopniu. Podział na wiele baz ułatwi na przykład migrację mocniej obciążonych instancji na osobne serwery. Gdyby siedziało to w jednej bazie trzeba by się bawić w klastrowanie.

Ułatwi migracje i logiczny porządek, ale o wydajność było pytanie, więc jeżeli każda tabela w mysql ma swój oddzielny plik to nie ma znaczenia, czy jest to w jednej, czy w 1000-cu tabel.

To może odpowiedzią na pytanie będzie. Czy ktokolwiek z was tworzył wszystkie swoje aplikacji na JEDNEJ bazie danych? Odpowiedź zapewno 1%, który nie znał składni polecenia CREATE DATABASE. Po prostu 1 projekt = 1 baza i utrzymujesz czysty logiczny porządek.

Ja stawiałem ileś tam CMS-ów (takich samych) na jednej bazie, bo akurat tak sobie to wymyśliłem podział na swoim servie.
Bazy były od różnych systemów, a w ramach bazy chodziły sobie np fora na różnych prefixach, a w innej bazie CMS-y na różnych prefixach.
To też ułatwiało mi migracje pomiędzy wersjami fora, bo tworzyłem nowy prefix w tej samej bazie i przy migracji nie musiałem bawić się z prawami dostępu.
Dodatkowo stare tabele były zawsze pod ręką w razie jakiegoś fuckupu.

Ten post edytował mkozak 28.07.2010, 14:17:35

[Mchl]

Ułatwi migracje i logiczny porządek, ale o wydajność było pytanie, więc jeżeli każda tabela w mysql ma swój oddzielny plik to nie ma znaczenia, czy jest to w jednej, czy w 1000-cu tabel.

Będę się nadal upierał, że ma to związek z wydajnością. Jeżeli migracja nie jest łatwa w przeprowadzeniu, zazwyczaj się ją odwleka do ostatniego możliwego momentu, a użytkownicy coraz bardziej narzekają...

Osobny problem pojawia się, jeśli aplikacja korzysta z funkcji/procedu skłądowanych. W jednej bazie mamy możliwość zdefiniowania jednej funkcji/procedury o danym identyfikatorze. Przy 1000 instalacjach tej samej aplikacji w tej samej wersji, problemu nie ma, ale niech się pojawi update obejmujący te procedury składowane. Część instalacji nie będzie kompatybilna z kodem w bazie. Na szczęście (?) mało która aplikacja korzysta z procedu składowanych.

[mkozak]

Będę się nadal upierał, że ma to związek z wydajnością.

Ale niby dlaczego?? Jakieś argumenty?

[Mchl]

Podałem zaraz po kropce.

Jeżeli migracja nie jest łatwa w przeprowadzeniu, zazwyczaj się ją odwleka do ostatniego możliwego momentu, a użytkownicy coraz bardziej narzekają...

Może nie jest to związek bezpośredni, ale moim zdaniem jest