MSSQL vs ORACLE
MP - 29-03-2007 00:03
MSSQL vs ORACLE
Czy ktoś, kto programuje na Oracle mógłby mi powiedzieć czy są jakieś
przewagi tego serwera nad MSSQL?
MP
Kurciok - 29-03-2007 00:03
> Czy ktoś, kto programuje na Oracle mógłby mi powiedzieć czy są jakieś
> przewagi tego serwera nad MSSQL?
http://www.mssqlserver.com/faq/general-sqlvsoracle.asp
A ogólnie rzecz biorąc to sama baza jako baza to jest drugorzędna rzecz
liczą się raczej umiejętności zespołu programistów, który coś w niej robi. A
tak się składa że programiści baz danych z wieloltenim doświadczniem siedzą
przeważne w Oraclu (choćby z tego powodu że MSSQL nie było gdy zaczynali).
W MySQL czy PostgreSQL też można stworzyć spokojnie bazę która obsłuży
kilkanaście terabajtów rozłożonych na różnych komputerach i nie będzie z nią
większych problemów, a będzie za darmo. Jednak płatne narzędzia mają bardzo
ważną rzecz, a mianowicie suport i szkolenia, który przy tworzeniu ważnych
systemów (takich w których nawet minimalne poprawienie wydajności czy
bezpieczeństwa się liczy) może się przydać. Możesz się ich radzić w bardzo
wielu sprawach jak co gdzie itd. Bez suportu nie będziesz wiedział nawet
jaki serwer kupić aby obsłużyć tyle, a tyle danych. Oracle ma nawet swoich
ludzi, którzy jak padnie ci baza mogą do ciebie przyjechać aby zdiagnozować
co się zrypało i jak to naprawić (oczywiście takie usługi nie są darmowe).
Osobiście np. nie widzę różnicy w tym czy robię bazę w PostgreSQL, czy w
Oraclu czy w MSSQL. I tak takich farfocli jak Java czy Oracle Forms i innych
dziadostw nie używam bo programuje w .NET (który sam z siebie ma o wiele
fajniejsze narzędzia do tworzenia stron interentowych i aplikacji niż to co
ma Oracle). To jest trochę tak że płaci się za markę jak zleceniodawca
usłyszy że użyjesz Oracla i sama baza danych musi kosztować parę tysięcy to
stwierdzi że jeśli narzędzia tyle kosztują to musi też dać ci na nie zarobić
:)
Ja jeśli bym miał wybierać to wybrał bym MSSQL głównie dlatego żę robie dużo
rzeczy w .NET drugi powód to to że jest darmowa wersja MSSQL której można
użyć do 4 GB danych (czyli do 90% przypadków :).
Marcin Przepiorowski - 30-03-2007 00:07
> Ja jeśli bym miał wybierać to wybrał bym MSSQL głównie dlatego żę robie dużo
> rzeczy w .NET drugi powód to to że jest darmowa wersja MSSQL której można
> użyć do 4 GB danych (czyli do 90% przypadków :).
>
Czesc,
Dla mnie to swieta wojna ;) bez jednoznacznego zwycięscy.
Ale popieram zdanie ze to zalezy od programistow,
no i wielkosci bazy.
Nie wyobrazam sobie powaznej bazy produkcyjnej wielkosci powiedzmy 20 TB na
serwerze Windowsowym a co za tym idzie wybor jest prosty -> Oracle, bo
najwieksza wada MS SQL jest jego przywiazanie do jednej platformy.
A co darmowych narzedzi to Oracle XE jest jak najbardziej darmowa wersja bazy.
pozdrawiam,
Marcin 'PIORO' Przepiorowski
--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl
Jaroslaw Zabiello - 30-03-2007 00:07
Dnia Wed, 28 Mar 2007 21:37:39 +0200, Kurciok napisał(a):
> W MySQL czy PostgreSQL też można stworzyć spokojnie bazę która obsłuży
> kilkanaście terabajtów rozłożonych na różnych komputerach i nie będzie z nią
> większych problemów, a będzie za darmo.
MySQL bardzo słabo znosi większe obciążenia (szczególnie zapis).
Niezliczoną ilość razy widziałem jak sobie niszczyła indeksty do tabel
MyISAM (z kolei INNODB są cholernie wolne) PostgreSQL, zwłaszcza nowa
wersja 8.2 rozbija na puch MySQL nie tylko możliwościami ale i wydajnością.
Robiłem prosty test (pod winxp) polegający na pobraniu listy tabel w bazie
i wyszło mi : MySQL5: 240req/s, MSSQL2K 350req/s i PostgreSQL8: 750 req/s
Podobno bardzo dobra jest DB2, która jest też w wersji darmowej. Ale
dokładniej się nie bawiłem.
--
Jarosław Zabiełło
http://blog.zabiello.com
wloochacz - 30-03-2007 00:07
>> W MySQL czy PostgreSQL też można stworzyć spokojnie bazę która obsłuży
>> kilkanaście terabajtów rozłożonych na różnych komputerach i nie będzie z nią
>> większych problemów, a będzie za darmo.
>
> MySQL bardzo słabo znosi większe obciążenia (szczególnie zapis).
> Niezliczoną ilość razy widziałem jak sobie niszczyła indeksty do tabel
> MyISAM (z kolei INNODB są cholernie wolne) PostgreSQL, zwłaszcza nowa
> wersja 8.2 rozbija na puch MySQL nie tylko możliwościami ale i wydajnością.
> Robiłem prosty test (pod winxp) polegający na pobraniu listy tabel w bazie
> i wyszło mi : MySQL5: 240req/s, MSSQL2K 350req/s i PostgreSQL8: 750 req/s
Pobraniem z pomocą czego? Rubego (jak to odmieniać? :-))?
Bo może wąskim gardłem jest middleware do danej bazy a nie baza sama w
sobie...
Bo mój MS SQL, bije Twój (req to żądnie - ilość wykonanych zapytań na
sekundę? Z FetchAll czy bez?) wynik na łeb na szyję. Poza tym, taki test
jest raczej na sprawność systemu cache danego silnika...
> Podobno bardzo dobra jest DB2, która jest też w wersji darmowej. Ale
> dokładniej się nie bawiłem.
No jest :)
--
wloochacz
Jaroslaw Zabiello - 30-03-2007 00:07
Dnia Thu, 29 Mar 2007 13:49:08 +0200, wloochacz napisał(a):
>> MySQL bardzo słabo znosi większe obciążenia (szczególnie zapis).
>> Niezliczoną ilość razy widziałem jak sobie niszczyła indeksty do tabel
>> MyISAM (z kolei INNODB są cholernie wolne) PostgreSQL, zwłaszcza nowa
>> wersja 8.2 rozbija na puch MySQL nie tylko możliwościami ale i wydajnością.
>> Robiłem prosty test (pod winxp) polegający na pobraniu listy tabel w bazie
>> i wyszło mi : MySQL5: 240req/s, MSSQL2K 350req/s i PostgreSQL8: 750 req/s
> Pobraniem z pomocą czego? Rubego (jak to odmieniać? :-))?
Odmienia się: Rubiego. Ale nie używałem tu Rubiego. Odczyt robił prosty
skrypt w Pythonie 2.5.
> Bo może wąskim gardłem jest middleware do danej bazy a nie baza sama w
> sobie...
Nie sądze. Python korzystał z ADO w wypadku MSSQL oraz binarnych driverów
dla MySQL (MySQLdb) i PG (psycopg2).
Różnice były ogromne (na niekorzyść MSSQL) jak otwierałem i zamykałem
połączenia. Ale wyniosłem to poza pętlę i tylko zamykałem i otwierałem
kursor. I to oczywiście był MSSQL2K a nie v2005.
> Bo mój MS SQL, bije Twój (req to żądnie - ilość wykonanych zapytań na
> sekundę? Z FetchAll czy bez?)
To było tylko proste wywołanie sp_tables. Ale o biciu (czy nie) można
powiedzieć dopiero jak zapuścisz test na tym samym kompie. Zainstaluj
PostgreSQL 8.2.3/win32 i porównaj sam. Od wersji 8 dostał dostał niezłe
przyśpieszenie.
--
Jarosław Zabiełło
http://blog.zabiello.com
Kurciok - 30-03-2007 00:07
> MySQL bardzo słabo znosi większe obciążenia (szczególnie zapis).
> Niezliczoną ilość razy widziałem jak sobie niszczyła indeksty do tabel
> MyISAM (z kolei INNODB są cholernie wolne) PostgreSQL, zwłaszcza nowa
> wersja 8.2 rozbija na puch MySQL nie tylko możliwościami ale i
> wydajnością.
> Robiłem prosty test (pod winxp) polegający na pobraniu listy tabel w bazie
> i wyszło mi : MySQL5: 240req/s, MSSQL2K 350req/s i PostgreSQL8: 750 req/s
>
> Podobno bardzo dobra jest DB2, która jest też w wersji darmowej. Ale
> dokładniej się nie bawiłem.
Jeżeli chodzi o testy to ciężko takie przeprowadzić bo wyniki mogą być
diametralnie różne w zależności od tego na jakim systemie pracujesz i na
jakim sprzęcie. Konkretne zapytanie też się liczy. Co do MySQL to tak ta
baza jest średnio ciekawa. Niektóre bardziej skomplikowane zagnieżdżone
zapytania nie chcą nawet na niej działać prawidłowo. Co prawda nie robiłem w
niej nic od wersji 4.1 ale pamiętam że niektóre GROUP BY zwracały mi
głupoty, ale wtedy robiłem po prostu inne :). Ale dać się w niej da wszystko
zrobić 40 Terabajtów też się obsłuży przy odpowiedniej konstrukcji bazy i
rozbiciu na parę serwerów.
Kurciok - 30-03-2007 00:07
> A co darmowych narzedzi to Oracle XE jest jak najbardziej darmowa wersja
> bazy.
Racja ... czyli ten argument odpada.
wloochacz - 30-03-2007 00:07
>> Pobraniem z pomocą czego? Rubego (jak to odmieniać? :-))?
>
> Odmienia się: Rubiego.
Zapamiętam.
> Ale nie używałem tu Rubiego. Odczyt robił prosty
> skrypt w Pythonie 2.5.
>
>> Bo może wąskim gardłem jest middleware do danej bazy a nie baza sama w
>> sobie...
>
> Nie sądze. Python korzystał z ADO w wypadku MSSQL oraz binarnych driverów
> dla MySQL (MySQLdb) i PG (psycopg2).
To istotne, ponieważ ADO domyślnie działa z kursorem po stronie klienta
i ściąga wszystko na klienta. Nie mam pojęcia jak opakowuje to Python...
Nie mam pojęcia z czego Pythonowe ADO korzysta do połączenia z MSSQL, bo
może z OLE DB lub ODBC...
> Różnice były ogromne (na niekorzyść MSSQL) jak otwierałem i zamykałem
> połączenia. Ale wyniosłem to poza pętlę i tylko zamykałem i otwierałem
> kursor. I to oczywiście był MSSQL2K a nie v2005.
>
>> Bo mój MS SQL, bije Twój (req to żądnie - ilość wykonanych zapytań na
>> sekundę? Z FetchAll czy bez?)
>
> To było tylko proste wywołanie sp_tables. Ale o biciu (czy nie) można
> powiedzieć dopiero jak zapuścisz test na tym samym kompie.
Ano
> Zainstaluj
> PostgreSQL 8.2.3/win32 i porównaj sam. Od wersji 8 dostał dostał niezłe
> przyśpieszenie.
Kusisz mnie, ale nie teraz. Poza tym musiałbym mieć to samo na serwerach
- w sumie z kilkoma tabelami będzie łatwo.
--
wloochacz
Jaroslaw Zabiello - 03-04-2007 00:07
Dnia Thu, 29 Mar 2007 17:12:55 +0200, wloochacz napisał(a):
>>> Bo może wąskim gardłem jest middleware do danej bazy a nie baza sama w
>>> sobie...
>>
>> Nie sądze. Python korzystał z ADO w wypadku MSSQL oraz binarnych driverów
>> dla MySQL (MySQLdb) i PG (psycopg2).
>
> To istotne, ponieważ ADO domyślnie działa z kursorem po stronie klienta
> i ściąga wszystko na klienta. Nie mam pojęcia jak opakowuje to Python...
> Nie mam pojęcia z czego Pythonowe ADO korzysta do połączenia z MSSQL, bo
> może z OLE DB lub ODBC...
Python bez problemu może podpinać się do windowsowych bibliotek com. Na
pewno tu nie używa ODBC (do tego ma oddzielną bibliotekę)
--
Jarosław Zabiełło
http://blog.zabiello.com
Robert Winkler - 03-04-2007 00:07
>>>> Bo może wąskim gardłem jest middleware do danej bazy a nie baza sama w
>>>> sobie...
>>>
>>> Nie sądze. Python korzystał z ADO w wypadku MSSQL oraz binarnych
>>> driverów
>>> dla MySQL (MySQLdb) i PG (psycopg2).
>>
>> To istotne, ponieważ ADO domyślnie działa z kursorem po stronie klienta
>> i ściąga wszystko na klienta. Nie mam pojęcia jak opakowuje to Python...
>> Nie mam pojęcia z czego Pythonowe ADO korzysta do połączenia z MSSQL, bo
>> może z OLE DB lub ODBC...
>
> Python bez problemu może podpinać się do windowsowych bibliotek com. Na
> pewno tu nie używa ODBC (do tego ma oddzielną bibliotekę)
COM'owe ADO stosuje prowidera OLEDB for ODBC
a następnie w nich sterowniki ODBC
w zależności od postaci zastosowanego ConnectionString
Podaj ConnectionString, to wyjaśnie jakie sterwniki zostały wykorzystane.
--
____________
Robert Winkler
Jaroslaw Zabiello - 03-04-2007 00:07
Dnia Mon, 2 Apr 2007 13:28:02 +0200, Robert Winkler napisał(a):
> Podaj ConnectionString, to wyjaśnie jakie sterwniki zostały wykorzystane.
Stworzyłem sobie od nowa ten skrypt. Poniżej podaję cały kod:
import adodbapi, MySQLdb, psycopg2, time
conn = [
( 'mysql', MySQLdb.connect(user='root', db='jdb273'), 'SHOW TABLES'),
('pgsql', psycopg2.connect("user='postgres' password='10f5ebe6'"), 'SELECT * FROM pg_tables jdb273'),
('mssql', adodbapi.connect('Provider=SQLNCLI.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=jdb273'), 'EXEC sp_tables'),
]
def test(repeat=100):
for c in conn:
dbtype, db, sql = c
print dbtype,
t = time.time()
for i in range(repeat):
cursor = db.cursor()
cursor.execute(sql)
rows = cursor.fetchall()
cursor.close()
print '%d req/s' % round(repeat / (time.time() - t))
if __name__ == '__main__':
test()
# Conf:
# --------------
# PC: WinXP Pro 2000 SP2, P4 3.2GHz, 1GB RAM.
# MySQL v5.0. 27, driver: MySQLdb v1.2.2
# PostgreSQL v8.2.3, driver: psycopg2 v2.0.6b1 (dec dt ext pq3)
# MSSQL 2000 SP4,
#
# Results:
# --------
# mysql 532 req/s
# pgsql 641 req/s
# mssql 9 req/s
Powtórzyłem test kilka razy. MSSQL nie mógł przekroczyć 9 req/s. To jakiś koszmar.
--
Jarosław Zabiełło
http://blog.zabiello.com
wloochacz - 04-04-2007 00:02
[ciach]
> Powtórzyłem test kilka razy. MSSQL nie mógł przekroczyć 9 req/s. To jakiś koszmar.
Koszmarne jest Twoje rozumowanie; wiele osób napisało Ci w komentarzach
na blogu, że taki test to se możesz w buty wsadzić... zobacz co tak
naprawdę robi sp_tables...
Zrobiłem to samo co Ty, tylko za pomocą Delphi:
WinXP Pro, 1 GB RAM, PIV HT 3,12 GHz
Microsoft SQL Server 2000 - 8.00.194 (Intel X86)
Aug 6 2000 00:57:48
Copyright (c) 1988-2000 Microsoft Corporation
Developer Edition on Windows NT 5.1 (Build 2600: Dodatek Service Pack 2)
I tak:
exec sp_tables: 164,2 reg/s
Ale już:
select O.id, O.name from SYSOBJECTS O where O.TYPE in ('U') option
(ROBUST plan)
daje 912 req/s
Może byś tak rozpoczął testy od zdefiniowania dokładnie tej samej bazy
danych z dokładnie takimi zapytaniami?
--
wloochacz
Jaroslaw Zabiello - 06-04-2007 00:03
Dnia Tue, 03 Apr 2007 16:09:44 +0200, wloochacz napisał(a):
> zobacz co tak naprawdę robi sp_tables...
[...]
>
> exec sp_tables: 164,2 reg/s
[..]
> Ale już:
> select O.id, O.name from SYSOBJECTS O where O.TYPE in ('U') option
> (ROBUST plan)
> daje 912 req/s
To dowodzi że ichnia systemowa procedura składowana jest do dupy i stawia
pod znakiem zapytania sens używania innych procedur systemowych... Dla
PostgreSQL też użyłem systemowej funkcji (pg_tables) i jest ona
wielokrotnie szybsza.
> Może byś tak rozpoczął testy od zdefiniowania dokładnie tej samej bazy
> danych z dokładnie takimi zapytaniami?
Przecież to niemożliwe aby użyć _takich samych_ zapytań, bo MSSQL, MySQL i
PostgreSQL uzywają innego dialektu SQL i sposobu pobierania danych o
tabelach w bazie. Ale z ciekawości porównam czyste operacje wkładania i
odczytywania rekordów. Tu dialekty są te same. Nie tyle aby pognębiać jakąś
bazę co raczej porównać wydajność różnych bibliotek w kontekście
interesującego mnie języka, tu Pythona.
--
Jarosław Zabiełło
http://blog.zabiello.com
=?ISO-8859-2?Q?Pawe=B3_Matejski?= - 06-04-2007 00:03
Jaroslaw Zabiello wrote:
> Dnia Tue, 03 Apr 2007 16:09:44 +0200, wloochacz napisał(a):
>
>> zobacz co tak naprawdę robi sp_tables...
> [...]
>> exec sp_tables: 164,2 reg/s
> [..]
>> Ale już:
>> select O.id, O.name from SYSOBJECTS O where O.TYPE in ('U') option
>> (ROBUST plan)
>> daje 912 req/s
>
> To dowodzi że ichnia systemowa procedura składowana jest do dupy i stawia
> pod znakiem zapytania sens używania innych procedur systemowych... Dla
> PostgreSQL też użyłem systemowej funkcji (pg_tables) i jest ona
> wielokrotnie szybsza.
Ale to jest jak kupowanie samochodu pod kątem szybkości obrotowej wiatraczka
dmuchawy. Rzecz jest tak mało istotna, że nikt na to nie zwraca uwagi.
>> Może byś tak rozpoczął testy od zdefiniowania dokładnie tej samej bazy
>> danych z dokładnie takimi zapytaniami?
>
> Przecież to niemożliwe aby użyć _takich samych_ zapytań, bo MSSQL, MySQL i
> PostgreSQL uzywają innego dialektu SQL i sposobu pobierania danych o
> tabelach w bazie. Ale z ciekawości porównam czyste operacje wkładania i
> odczytywania rekordów. Tu dialekty są te same. Nie tyle aby pognębiać jakąś
> bazę co raczej porównać wydajność różnych bibliotek w kontekście
> interesującego mnie języka, tu Pythona.
1. Różnią się coraz mniej.
2. Nie chodzi o używanie tych samych zapytań a takich samych. Mają zwracać te
same wyniki, a zapytania mają być takie, które najlepiej takie wyniki uzyskają w
w danym silniku. A żeby przygotować testy, które będą coś znaczyć, najlepiej
wyobrazić sobie jakiś system i wybrać z niego najczęściej wykonywane i
jednocześnie nietrywialne dla silnika, inaczej mówiąc ciekawe.
--
P.M.
wloochacz - 06-04-2007 00:03
[ciach]
>> To dowodzi że ichnia systemowa procedura składowana jest do dupy i stawia
>> pod znakiem zapytania sens używania innych procedur systemowych... Dla
>> PostgreSQL też użyłem systemowej funkcji (pg_tables) i jest ona
>> wielokrotnie szybsza.
Ale nie jest szybsza od mojego prostego selecta - zależy co komu
potrzebne i wie jak to osiągnąć.
Jak dla mnie ( i z tego co widze nie tylko dla mnie), to jedynie dowodzi
Twojego dziwnie tendencyjnego podejścia do testów, które de-facto są
bezużyteczne.
> Ale to jest jak kupowanie samochodu pod kątem szybkości obrotowej wiatraczka
> dmuchawy. Rzecz jest tak mało istotna, że nikt na to nie zwraca uwagi.
>
>>> Może byś tak rozpoczął testy od zdefiniowania dokładnie tej samej bazy
>>> danych z dokładnie takimi zapytaniami?
>> Przecież to niemożliwe aby użyć _takich samych_ zapytań, bo MSSQL, MySQL i
>> PostgreSQL uzywają innego dialektu SQL i sposobu pobierania danych o
>> tabelach w bazie. Ale z ciekawości porównam czyste operacje wkładania i
>> odczytywania rekordów. Tu dialekty są te same. Nie tyle aby pognębiać jakąś
>> bazę co raczej porównać wydajność różnych bibliotek w kontekście
>> interesującego mnie języka, tu Pythona.
>
> 1. Różnią się coraz mniej.
> 2. Nie chodzi o używanie tych samych zapytań a takich samych. Mają zwracać te
> same wyniki, a zapytania mają być takie, które najlepiej takie wyniki uzyskają w
> w danym silniku. A żeby przygotować testy, które będą coś znaczyć, najlepiej
> wyobrazić sobie jakiś system i wybrać z niego najczęściej wykonywane i
> jednocześnie nietrywialne dla silnika, inaczej mówiąc ciekawe.
Podoba mi się; takie same (w sensie efektu), ale nie te same (w sensie
zapisu) :)
A tak zupełnie poważnie - dlaczego nie oprzeć się na testach TPC?
(zawszę mogę zgnębić PostgreSQL w stosunku do MSSQL, tylko po co?)
Ot chociażby coś takiego:
http://benchw.sourceforge.net/
--
wloochacz
Jaroslaw Zabiello - 06-04-2007 00:03
Dnia Thu, 05 Apr 2007 13:16:34 +0200, wloochacz napisał(a):
> tendencyjnego podejścia do testów, które de-facto są
> bezużyteczne.
Bzdura. Mam gdzieś głupie komentarze. Po prostu MSSQL chodzi mi jak źółw i
chciałem zobaczyć co się dzieje, stąd na szybko to małe porównanie. A to że
jego sp_tables chodzi mi 60x wolniej of pg_tables PG po prostu mnie
wkurzyło stąd nazwałem to dosadnie. Okazało się, że że MSSQL dał ciała i
mają beznadziejną zaimplementację niektórych systemowych procedur
składowanych co wykazał twój test. Po to je chyba stworzyli aby je używać a
nie bawić się w analizę tabel systemowych.
> A tak zupełnie poważnie - dlaczego nie oprzeć się na testach TPC?
> (zawszę mogę zgnębić PostgreSQL w stosunku do MSSQL, tylko po co?)
> Ot chociażby coś takiego:
> http://benchw.sourceforge.net/
Eee tam, to jakaś prehistoria. Mają tam jakieś wyniki z 2004 roku. Zobacz
sobie lepiej wydajność PostgreSQL 8.3.2.
--
Jarosław Zabiełło
http://blog.zabiello.com
wloochacz - 06-04-2007 00:03
>> tendencyjnego podejścia do testów, które de-facto są
>> bezużyteczne.
>
> Bzdura. Mam gdzieś głupie komentarze.
I vice versa, ale przyznasz że SĄ BEZUŻYTECZNE, no chyba że Tobie...
Tak czy siak, mi tu pasuje jak ulał Twoja wypowiedź z pewnego wątku na
pewnej grupie:
"Człowiek się cofa w rozwoju jak co chwilę spotyka debilizmy w internecie."
> Po prostu MSSQL chodzi mi jak źółw i
> chciałem zobaczyć co się dzieje, stąd na szybko to małe porównanie. A to że
> jego sp_tables chodzi mi 60x wolniej of pg_tables PG po prostu mnie
> wkurzyło stąd nazwałem to dosadnie.
Może masz wirusa? Slammer się chyba nazywał ;-)
> Okazało się, że że MSSQL dał ciała i
> mają beznadziejną zaimplementację niektórych systemowych procedur
> składowanych co wykazał twój test.
Mój "test" (nie śmiem nazywać tego testem) wykazał, że trzeba myśleć, a
nie udawać że się coś wie i odkryło amerykę...
> Po to je chyba stworzyli aby je używać a
> nie bawić się w analizę tabel systemowych.
buahahahaa... mam dość, Ty słyszysz ale nie słuchasz.
>> A tak zupełnie poważnie - dlaczego nie oprzeć się na testach TPC?
>> (zawszę mogę zgnębić PostgreSQL w stosunku do MSSQL, tylko po co?)
>> Ot chociażby coś takiego:
>> http://benchw.sourceforge.net/
>
> Eee tam, to jakaś prehistoria.
Chodziło mi o narzędzie, którym sobie taki test możesz zrobić. Nie o
wyniki, nieaktualne, na stronie.
> Mają tam jakieś wyniki z 2004 roku. Zobacz
> sobie lepiej wydajność PostgreSQL 8.3.2.
Gdzie?
--
wloochacz
Jaroslaw Zabiello - 06-04-2007 00:03
Dnia Thu, 05 Apr 2007 16:00:48 +0200, wloochacz napisał(a):
>> Po prostu MSSQL chodzi mi jak źółw i chciałem zobaczyć co się dzieje,
>> stąd na szybko to małe porównanie. A to że jego sp_tables chodzi mi 60x
>> wolniej of pg_tables PG po prostu mnie wkurzyło stąd nazwałem to
>> dosadnie.
>
> Może masz wirusa? Slammer się chyba nazywał ;-)
Wątpię.
>> Po to je chyba stworzyli aby je używać a
>> nie bawić się w analizę tabel systemowych.
>
> nie słuchasz.
Tu ty nie słuchasz. Każda baza mi inne tabele systemowe, inne pola, inne
opcje. Jak naprawdę nie muszę, to nie interesuje mnie przedzieranie się
przez jakies books online aby wgryzać się w znaczenie poszczegolnych pól i
opcji. Ale widocznie systemowe procedury Microsoftu tak tak beznadziejne że
trzeba je będzie omijać szerokim łukiem. Dzięki za uświadomienie mi jakości
tego softu.
> Chodziło mi o narzędzie, którym sobie taki test możesz zrobić. Nie o
> wyniki, nieaktualne, na stronie.
Jaja sobie robisz? Kod w C i na dodatek pasujący raczej do POSIX a nie
win32. make; make install pod windozą? Walczyć z cygwinami, mingami i
kompilacją źródeł pod windozą? Kto ma na to czas? Chrzanić to.
>> Mają tam jakieś wyniki z 2004 roku. Zobacz
>> sobie lepiej wydajność PostgreSQL 8.3.2.
> Gdzie?
http://postgresql.org. Zainstaluj i sam sobie porównaj.
--
Jarosław Zabiełło
http://blog.zabiello.com
wloochacz - 07-04-2007 00:03
>>> Po prostu MSSQL chodzi mi jak źółw i chciałem zobaczyć co się dzieje,
>>> stąd na szybko to małe porównanie. A to że jego sp_tables chodzi mi 60x
>>> wolniej of pg_tables PG po prostu mnie wkurzyło stąd nazwałem to
>>> dosadnie.
>> Może masz wirusa? Slammer się chyba nazywał ;-)
>
> Wątpię.
>
>>> Po to je chyba stworzyli aby je używać a
>>> nie bawić się w analizę tabel systemowych.
>> nie słuchasz.
A to używanie to jest miarodajny test porównawczy bazy danych?
buahahaha... zrobiłeś ten test z lenistwa, ot co!
> Tu ty nie słuchasz.
Ja? Ciekawe...
> Każda baza mi inne tabele systemowe, inne pola, inne
> opcje. Jak naprawdę nie muszę, to nie interesuje mnie przedzieranie się
> przez jakies books online aby wgryzać się w znaczenie poszczegolnych pól i
> opcji.
Dokładnie! W końcu zrozumiałeś w czym sedno - właśnie dlatego, że tak
jest, tym Twoim testem możesz sobie dziury w drodze łatać...
Poza tym, ja uzyskałem wyniki znacznie lepsze od Twoich - może obsługa
MSSQL w Pythonie jest po prostu skopana? Bo chyba do wzorcowej to jej
"troszkę" brakuje...
> Ale widocznie systemowe procedury Microsoftu tak tak beznadziejne że
> trzeba je będzie omijać szerokim łukiem. Dzięki za uświadomienie mi jakości
> tego softu.
Dość, eot jak dla mnie...
>> Chodziło mi o narzędzie, którym sobie taki test możesz zrobić. Nie o
>> wyniki, nieaktualne, na stronie.
>
> Jaja sobie robisz? Kod w C i na dodatek pasujący raczej do POSIX a nie
> win32. make; make install pod windozą? Walczyć z cygwinami, mingami i
> kompilacją źródeł pod windozą? Kto ma na to czas? Chrzanić to.
A w czym ma być - w Pythonie?
Jak się chce mieć miarodajne wyniki, to trzeba się pomęczyć... Ale
Ciebie nie interesuje rzetelne porównanie szbd, tylko dlaczego Python
tak tragicznie działa z MSSQL; a z tym to już do mądrali od adodbapi...
lub innego api...
Java version:
http://sourceforge.net/projects/benchmarksql
>>> Mają tam jakieś wyniki z 2004 roku. Zobacz
>>> sobie lepiej wydajność PostgreSQL 8.3.2.
>> Gdzie?
>
> http://postgresql.org. Zainstaluj i sam sobie porównaj.
Gdzie są miarodajne testy PostgreSQL, najlepiej z rodziny TPC-x??
--
wloochacz
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
Oracle, SQL, PL/SQL. Jak =?ISO-8859-2?Q?napisa=E6_zapytanie=2C?==?ISO-8859-2?Q?_kt=F3re_zwr=F3ci_nazw=EA_atrybutu=2C_kt=F3reg o?==?ISO-8859-2?Q?_warto=B6ci_spe=B3niaj=B1_zadany_warunek?=
Oracle 19g +Insert +Insert +Insert...
[oracle] zapytanie dynamiczne z =?ISO-8859-2?Q?=22dynamiczn=B1_?==?ISO-8859-2?Q?nazw=B1_tabeli=22?=
[Oracle] jak =?ISO-8859-2?Q?ograniczy=E6_pami=EA=E6_dla_se?==?ISO-8859-2?Q?rwera=3F?=
=?ISO-8859-2?Q?=5BOT=5D_Zdany_egzamin_Oracle_1Z0-007_a?==?ISO-8859-2?Q?_brak_informacji_na_stronie_Prometric_-_czy?==?ISO-8859-2?Q?_co=B6_nie_tak=3F?=
[oracle] czy da =?ISO-8859-2?Q?si=EA_z_poziomu_procedury_?==?ISO-8859-2?Q?zrobi=E6_kopi=EA_zapasow=B1=3F?=
[oracle 10g] czy =?ISO-8859-2?Q?mo=BFna_wy=B3=B1czy=E6_wszys?==?ISO-8859-2?Q?tkie_wi=EAzy_w_schemacie=3F?=
=?iso-8859-2?q?[oracle]_Jak_sprawdzi=E6_wielko=B6=E6_tabeli_=3F=3F?=
=?ISO-8859-2?Q?Poszukjue_ksi=B1=BFki_"Oracle_?= =?ISO-8859-2?Q?optymalizacja_wydajno=B6ci"..?=
[Oracle] =?ISO-8859-2?Q?=A3=B1czenie_wierszy_z_zapytania_?==?ISO-8859-2?Q?w_jeden_string?=
zanotowane.pldoc.pisz.plpdf.pisz.pltejsza.htw.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
