Witam,
Muszę stworzyć aplikację która będzie zapisywała różnego rodzaju dane - po ok. 3 miesiącach będzie tego ok 45GB. Rozmiar bazy maksymalny to ok 50GB. Myślicie że MSSQL to wytrzyma (nie będzie mulił - da się na takiej bazie pracować)??
Northwest
Najlepiej stworz sobie przykladowa z losowymi danymi i przetestuj te operacje, na ktorych Ci zalezy.
ale fizycznie to będzie jako tako chodziło??:) a co myślisz o PostgreSQL - lepszy??
mam nadzieje że php się nie wyłoży przy obróbce wczytywaniu tych danych;)
nie jestem bazodanowcem ale skoro 45GB to podejzewam ze bedziesz trzymal w bazie rozne pliki, wiec w postgresie masz mechanizm large objects, w tabeli trzymasz jedynie numeryczny "identyfikator pliku", natomiast sama zawartosc plikow jest trzymana poza tabela, nie wiem jak to bedzie chodzic dla kilkudziesieciu GB ale z kilkaset MB radzi sobie bez pierdniencia :P
to są dane textowe.... ;)
Generalnie to mssql jest lepszy niz postgresql, choc ten drugi zwykle jest na topie jesli chodzi o darmowe rozwiazania. Fizycznie to wydaje mi sie, ze bardziej bedzie zalezalo od sprzetu (czas dostepu do dysku chociazby) niz od silnika. Nie robilem nigdy takich baz, wiec trudno mi stwierdzic. Ale skoro porownujesz postgresa do mssql to chcesz to robic na darmowej wersji mssql?
Pytanie tez jakie ilosci danych bedziesz w jednej transakcji pobieral. Bo php ma pewne ograniczenia jesli chodzi o wspolprace z mssql (dostepny jest tylko port w starszej wersji).
darmowa wersja MSSQL ma ograniczenie do 4GB wielkości bazy - więc odpada :(
Pytam o PostgreSQL dlatego że słyszałem że też jest ciekawy jeśli chodzi o obsługę baz danych - dużych baz danych (szybki, niezawodny). Ponoć SKYPE, PRACUJ.PL na nim chodzą..
wcześniej robiłem mniejsze rzeczy w php i mysql/postgresql i z tym nie było problemu, tylko teraz nie wiem czy php i baza podołają temu "olbrzymowi" ;)
johny_bravo napisał(a)
Pytanie tez jakie ilosci danych bedziesz w jednej transakcji pobieral.
jednorazowo to będzie ok 300 rekordów - czyli nic takiego (rekordy textowe i liczbowe)...;)
To moze na biegu wygeneruj sobie taka baze? Dla 300 wybieranych zwyczajnie rekordow z indeksami to powinno byc w porzadku. Gorzej jakbys przeprowadzal jakies statystyki, itp.
no to super:) czyli nie ma różnicy czy to będzie pracowało na MSSQL czy na PostgreSQL??
MySQL ponoć z dużymi bazami danych nie wyrabia i się zamula strasznie...
Generalnie sprawa nie jest taka prosta jakby się mogło wydawać. Wszystko zależy od wydajności utworzonego modelu fizycznego bazy danych. Docelowy DBMS nie załatwi Ci sprawy jeżeli będziesz miał nieoptymalny model fiziczny. Jeżeli miałbyś wybierać spośród tych dwóch, to uwzględnij liczbę jednocześnie korzystających użytkowników wykonujących tę samą transakcję. Prowadziłem testy porównawcze wykonywania transakcji (około 11 - modyfikowania, wstawiania, usuwania i wyszukiwania m.in. na tych dbms'ach) na różnych poziomach izolacji bazy danych, każda operacja symulowana była przez 10 jednocześnie korzystających userów, więc w danej chwili było podłączonych 110 userów. Wyniki były bardzo ciekawe. Jeżeli chodzi o sam czas wykonywania zapytania to MS SQL Server (2005) był o ponad rząd szybszy od PostgreSQL (8.0), ale (i tutaj ważne) nie obsłużył takiej liczby jednocześnie wykonujących daną transakcję użytkowników - pewnie jego poziom izolacji blokował DELETY, INSERTY i UPDATY. Weź pod uwagę ile będziesz miał operacji modyfikujących a ile odczytujących - ustaw odpowiedni poziom izolacji, weź pod uwagę typy atrybutów na jakich dodkonywane są złączenie (doda/usuń indeksy ) i pamiętaj, jeżeli będziesz miał więcej operacji modyfikujących niż odczytujących indeksy tylko spowalniają wykonywanie tych operacji.
Ostatnio coś robiłem w Postgre i doczytałem gdzieś, że obsługuje bazy do 200GB. Natomiast dla MSSQL (jak twierdzą autorzy) w wersjach wyższych niż Express rozmiar bazy jest nielimitowany (więc pewno znaczy to dużo TB ;)).
Postgresql tez nie ma limitu i MySQL pewnie tez nie, tylko pytanie jak to chodzi.
dokładnie, główny problem to wydajność...