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.

Oddzielna baza dla kazdej aplikacji.

QFT

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.

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.

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)

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.

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...

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.

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.



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.

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.

Ale niby dlaczego?? Jakieś argumenty?

Podałem zaraz po kropce.



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