Zastanawiam się czy jest możliwość sprawdzenia optymalnej (lub maksymalnej) ilości baz danych na serwerze (serwer przeznaczony jedynie na bazy danych)? Jeżeli jest taka możliwość proszę o wskazówki... Oczywiście zależnie od konfiguracji serwera (procesor, pamięć etc.).

Każda baza to maksymalnie 15 tabel, głównie informacje takie jak imię, nazwisko, adres. Przewidywana ilość zapytań dla każdej bazy to 1/5 minut - czyli nie wiele.

Planuję ograniczyć liczbę baz do 500set na serwer co da około 100 zapytań na minutę - czyli raczej dobrze (zależy mi na wydajności). Ale to są znaki zapytania...

Z góry dziękuję za każdą konstruktywną odpowiedź. Nie ważne jaka baza danych, sam myślę o MySql, ale postgre też nie jest mi obce (ms odpada - mam uraz przez sqlsrv)

Witam!

Jezeli chcesz powielic ilosc tych samych baz do 500 to nic bardziej blednego zrobic nie mozna ( albo i mozna ). Niezaleznie od tego czy masz jedna czy 500 pracuja one na jednym serwerze. Wiec mysql bedzie w kwestii zapytan dokladnie tak samo obciazony. Wazne przy serwerze Baz Danych sa :

1. ilosc i szybkosc procesorow, co pozwala na jednoczesne startowanie wiekszej ilosci watkow
2. Dostepna ilosc pamieci RAM, ktora pozawala na cachowanie wynikow przez mechanizm mysql
3. Szybki dysk, ktory nie zameczy sie przy duzej ilosci dostepu do danych na nim zapisanych. Ostatnim rozwiazeniem, zastosowanym w mojej firmie jest wykorzystanie do mysql pamieci SSD zamiast dostepu do dysku.
4. Poprawne ustawinia w pliku konfiguracyjnym , ktore powinny byc po strestestch dodstosowane indywidualnie do potrzeb.

Mialem przyjemnosc uczestniczenia w szkoleniu prowadzonym przez praconikow z MYSQL i uslyszalem u zrodla, ze dwuprocesorowa myszyna spokojnie wytrzymuje od 500-1000 zapytan na sekunde.

Ale :

Po piersze drugie trzecie i czwarte to optymalizacja zapytan !!!!!!!!!!
Po piate indexy tam gdzie sa potrzebne
Po szoste dopasowanie typow kolumn do typow przchowywanych w nich danych ( Kolumna nie musi by INTEGER jezeli zakres liczb bedzie np 100 )
Po siodme sortowanie, grupowanie indeksowanych wartosci najlepiej numerycznych.
Po osme ograniczenie warunku OR na rzecz UNION.
Po dziewiate starac sie przniesc SUBQUERY z warstwy danych do warstwy logiki ( niekoniecznie SELECT * FROM cos WHERE id IN ( SELECT id FROM cos innego WHERE cos ) , a raczej SELECT * FROM cos WHERE id IN ( 2, 5, 6, 48 ) , gdzie id generujemy w logicznej czesci aplikacji )
Po dziesiate typy Tabel. Jezeli spodzeiwamy sie w jakiejs tabeli setki zmian na sekunde ( updatow ), np przy ogromnym trafiku tabele przechowujace dane sesyjne sa updajtowane na biezaco stosujmy INNODB a nie MYISAM, poniewaz MYISAM blokuje dostep dla innego watku do momentu zakonczenia operacji co moze wygenerowac piramide oczekujacych watkow a w efekcie " TO MANY CONNECTIONS "

Mozna tak wymieniac jeszcze bardzo dlugo

Dla informacji dodam ze nasze Serwery DB to dwie maszyny 16 procesorowe z pamiecia 24GB polaczone w konfiguracji Master-Master ( tak tak - nie Master-Slave ). Skonfigurowany sprzet wytrzymuje bez najmniejszych problemow ok 8-12 milinow odlon stron dziennie.

Pozdrawiam

Dzięki zbig rozjaśniłeś mi to.

Czyli podsumowując nie ma różnicy, czy na maszynie będzie np. 500 baz * 15 tabel czy po prostu jedna baza i 500*15 tabel?

Z tego co napisałeś, maszyna 4proc, 8gb ram, ssd spokojnie pociągnie bez bólu nawet i 200 zapytań / sekundę. Czyli spokojnie mogę utworzyć 2000 baz lub jedną bazę z 30000 tabelami? Chyba wolę 2k baz, nie każdy będzie płacił za backup, a tak mogę łatwo tym zarządzać a jedynie raz na miesiąc robić backup wszystkiego. Serwery będą pełniły rolę magazynu - żadna strona nie będzie pobierała z nich danych, głównie będą rekordy dodawane, a jedynie od czasu do czasu użytkownik będzie pobierał listę osób, do których chce np. wysłać maila.

A co z bezpieczeństwem? Tzn. Jak ktoś wbije się na jedną bazę, to ucierpi tylko 1 klient, a tak ucierpią wszyscy... Chyba że się mylę. Fakt jak ktoś zdobędzie cudem listę serwerów, baz i haseł to d***, ale to już inna kwestia - ostatnio sonny nieźle dał D***. Teraz czekam na facebooka

Witam ponownie.

Niezupelnie to mialem na mysli, co napisales. Tzn. jakbym nie patrzyl to 30000 tabel w DB, albo 2000 DB na jednym servie to extremum. Ja myslalbym o czyms inym. Jezeli te bazy maja taka sama strukture, zrob z nich np. 100 * 15 tabel i pogrupuj dane w tych tabelach, a wposzczegolnych bazach daj userom dostep tylko do tych danych do ktorych maja oni prawo ( Zakladajac oczywiscie ze moga oni READ_ONLY ) . Zrobienie 2000 baz pozbawi Cie kontroli nad tym co dzieje sie faktycznie na serwerze. Drugi problem to ograniczenia zwiazane z maksymalna iloscia otwartych plikow zdefiniowanych w /etc/mysql/my.cnf - open-files-limit. Zobacz ten link : http://serverfault.com/questions/233614/my...pen-files-limit i http://www.geeksww.com/tutorials/database_...it_on_linux.php . Poza tym istnieje limit systemowy ograniczajacy ilosc otwartych jednoczesnie plikow co wynika posrednio z drugiego artykulu .

Rozwaz dobrze wszystkie za i przeciw zanim wpakujesz sie w klopoty z placzacymi klientami

Pozdrawiam.