OpenSource sux ?

Rozwiazanie Adama jest calkiem fajne, tansze (wydaje mi sie) i jak najbardziej sensowne. Z drugiej strony centrala moze chciec miec u siebie wszystko z jakichs powodow. Po drugie sa tez przyklady duzej ilosci danych niekoniecznie w sieci. Moj kumpel pracowal do niedawna w duzym wojweoszkim szpitalu, gdzie zbiera sie dane z rentgenow, tomografow, dane pacjentow, lekow, itp. Wiadomo ile tego w szpitalach jest. Mieli problem z dolozeniem kolejnych dyskow (lacznie 4TB), bo system juz nie obslugiwal tyle. Wiec sa sytuacje, gdzie to co pisze jmail jest niestety konieczne. Chociaz wedlug mnie te sytuacje, jak jest ich duzo, tak stanowia jednak maly procent aplikacji uzywanych powszechnie w przedsiebiorstwach. W koncu wiekszosc przedsiebiorstw to male i srednie, a nie molochy typu microsoft, tpsa, czy chocby Biedronka.
Wtedy aplikacje open source jednak sie przydaja - wystarczy popatrzec jak wiele hostingow oferuje apache+php+mysql, a nie np. IIS+ASP.NET+MSSQL. Owszem mssql jest bez porownania lepszy od mysql'a (chocby funkcjonalnoscia) - sam zreszta kiedys napchalem 1,5mln rekordow w baze dla testow. Czas dostepu ponizej krytyki...

pozdrawiam
johny

Wracajac do MySQLa to jeszcze do niedawna portal allegro.pl byl oparty bodajze o ten serwer (ostatnio przeszli na wiekszego vendora, czyli mozna sie domyslac, ze jest to ktos z trojcy IBM, Oracle lub Microsoft).

Jezeli chodzi o to, ze linux jest do bani to mam taki przyklad: 99% uzytkownikow internetu korzysta z wyszukiwarki google. Wyszukiwarka dostaje ok 100 000 000 zapytan dziennie wiec jest co mielic, a wszystkie serwery sa oparte o Linuxa. Zapewne jest to jakas wlasna, wyspecjalizowana dystrybucja ale to wlasnie jest zaleta opensource. ;-P

PS> Firefox daje rade? Poczytajcie: http://www.g2zero.com/2006/09/examining_defects_in_the_firef ;) po lekturze strach pomyslec jak napisany jest IE ;)

Baza danych 1,5 TB jest zastosowaniem IMHO specjalistycznym - jesli ktos ma taka baze, to wydatek kilkuset tys. zl to dla niego pryszcz. Zapewne hardware kosztuje wiecej. Jesli to byla hurtownia, no to jail, zle narzedzie wybralisie. Po prostu Postgres nie sluzy do budowy hurtowni danych i juz.
Hurtownie rzadza sie specyficznymi prawami. Transakcyjny Oracle 10g tez by polegl.

Podobnie Postgres nie potrafi obslugiwac rozproszonych baz danych, ale do diabla, to tez jest rozwiazanie bardzo specjalistyczne. 99% klientow tego nie potrzebuje lub wystarcza im prosta replikacja. Szybkosc samego silnika bazy nie ustepuje Oracle'owi czy MS SQL. Indeksy wszedzie dzialaja tak samo.

To o czym pisze Krolik, to klasyczny problem wyboru odpowiedniego narzedzia. Wiadomo, ze jak ktos chce narysowac kwadrat to nie bedzie kupowal Autocada (chociaz sa i tacy). Na tych bazach, o ktorym pisze jmail mysql i posgresql wymiekaja na starcie i nie ma o czym dyskutowac. Ale to dlatego, ze nie sa do takich zastosowan. W tym wypadku mowi sie trudno i inwestuje sie w mssql czy oracle'a i w sprzet, bo za bardzo innego wyjscia nie ma. Ta dyskusja raczej powinna byc o tym co wybrac jezeli JEST wybor. Dla wiekszosci ten wybor jest i opensource potrafi calkiem niezle uratowac finanse :) A finanse to serce firmy.

pozdrawiam
johny

Adam.Pilorz napisał(a)

jmail: No to moment moment, zaczynasz tu nawijać o hurtowniach danych, nie o standardowych bazach danych. To całkiem inna historia. Swoją drogą rozpatrz sobie taką sytuację: Każdy ze sklepów (uwaga - supermarketów, tudzież stacji benzynowych, dla których jeden komputer mniej, jeden więcej to żadna różnica) ma swój serwer i każdy z nich gromadzi dane szczegółowe o wszystkich tranzakcjach. Pozwalają one na kontrolę pracowników, analizę zależności mikroekonomicznych i tak dalej. Jednak w celu uzyskania konkretnych danych statystycznych na jakimś centralnym serwerze nie potrzeba bynajmniej wszystkich tych danych i operacji na nich. Serwer w każdym sklepie tworzy dane statystyczne danego sklepu podporządkowane pod konkretne zapytania w przyszłości i przesyła te dane (obliczone ilości rekordów, przychody, zyski, whatever, zależnie od potrzeb) do głównej hurtowni danych. I tam te dane są analizowane w dużo prostszy sposób (również zależny od tego, co się chce osiągnąć na wyjściu). Tak funkcjonują hurtownie danych, że nie obchodzi ich wszystko, tylko konkretne statystyki. Jak do ich otrzymania się doprowadzi, to już kwestia implementacji. Jest alternatywa.

P.S. Jeśli chcecie mi powiedzieć, że to są gigantyczne koszty na skalę krajowej sieci, żeby każdy z takich sklepów wyposażyć w serwer bazy danych dla jednostki - odpowiedź jest prosta - nie trzeba, bo każdy z tych sklepów już taki serwer ma. Potrzebuje go, by gromadzić swoje "prywatne" dane odnośnie tranzakcji, które są w nim wykonywane. Trzeba mu tylko dorzucić jedno zadanie do wykonania więcej.

Widzisz. Co to jest hurtownia danych? Albo jeszcze inaczej. Czy hurtownią nazwiemy dużą ilośc danych czy może kostkę zbudowaną w oparciu o MOLAP ROLAP czy OLAP.

I czym się charakteryzuje hurtownia danych? Przede wszystkim dekompozycją danych, wszystko ładujemy do jednego wora i tym że dane często się nie zmieniają. No i tu się zaczyna rodzić problem. Bo ktoś bardzo genialny wpadł na pomysła że chce mieć wszystkie dane do przeglądania od początku istnienia firmy. Bzdura kompletna. nie pozwolono nam kostki zbudować. A jak zacząłem to robić to mi powiedziano żebym się pierdołami nie zajmował tylko za robotę wziął.

Ale ja pocichu sobie coś tam udłubałem ;) i dałem ludziom pivot table przez stronę netową. No i się okazało że nie możemy pisać niczego w kostkach. Bo język MDX znam tylko ja i nikt więcej "nie ma czasu" się go nauczyć :/ no i zostaliśmy przy standardowej bazie danych. bezsens. Ale jak wspomniałem. Ilośc rekordów jest w niektórych tabelkach wręcz niewyobrażalna. :(

Co do Twojego rozwiązania opartego o bazę danych na każdym sklepie..... nie wyobrażam sobie tego żeby każdy sklep miał bazę danych. wyobraź sobie teraz aktualizachję cennika w takim sklepie jak biedronka, informacje o dostawach i inne takie. Selgros -> 11 hal w cały kraju. jeden serwer w Poznaniu.

no ale właśnie wszystkim chcę powiedzieć. MACIE WYBÓR. TEŻ MOŻECIE SKORZYSTAĆ Z SILNIKA MS SQL. Może to nie jest OpenSource ale można wziąć i normalnie uruchomić MS SQL 2005 Express. Jest za darmo DLA WSZYTSKICH. Jedyna ograniczenie to takie że nie obsługuje więcej niż 20 połączęń. Licząc przeciętną firmę zatrudniającą do 50 pracowników biurowych to można sobie na takim serwerku poradzić z bazką dla księgowości, bazką pod intranet :P odpowiednia konfiguracja doprowadzi do otwarcia jednego połączenia z serwerem db. i mamy co? profesjonalny silnik nie za kilkaset tysięcy złotych ale za darmo od tego jakże przklinanego Microsoftu.

Tak samo było przecież z silniekiem MSDE do SQL Servera 2000. I gdzie tu narzekanie? Bo w kodzie nie można pogrzebać? A po co grzebać w kodzie? Jestem ciekawy ile z piszących tutaj osób zmieniało silnik MySQL'a...

jmail napisał(a)

i mamy co? profesjonalny silnik nie za kilkaset tysięcy złotych ale za darmo od tego jakże przklinanego Microsoftu.

jmail napisz mi od kiedy takie rozwiazanie stosuje microsoft? od 2 lat? od 3? Dostepne sa rowniez za darmo silniki od Oracle czy IBMa ale to nie jest rozwiazanie stosowane od zawsze, dopiero niedawno "wielcy" zauwazyli, ze moga cos dac za darmo :)

BTW. czy na MSSQL jest tylko ograniczenie odnosnie ilosci jednoczesnych polaczen? Mi sie wydaje, ze takze organiczenie w ilosci procesorow, ramu w serwerze oraz wielkosci samej bazy. Jezeli mam bledne dane to prosze, popraw mnie :)

Uuu, jeśli ktoś pisze, że wrzucil 1,5 mln rekordów i mu baza OpenSourcowa zdechła, to mimo wszystko chyba coś źle zrobił... Z tego co pisza na ich stronie, MySQLa testuja ponoć na 50 mln rekordow...

Taki mały teścik:
Jest tabela na 50 mln rekordów zawierająca transakcje z sieci supermarketów z ostatnich 3 lat. Każdy rekord zawiera id transakcji, datę, kwotę transakcji. Kwoty są z przedziału typowo 5 zł do 1000 zł, dla uproszczenia załóżmy, że rozłożone w miarę równomiernie. Chcemy dostać ile było transakcji w ostatnim roku za mniej niż 50 zł. Pytanie: jak to zrobić, żeby było szybko (ktore parametry podkrecic, jakie indeksy, zapytanie)?

Od razu powiem, że, mimo iż to zagadnienie hurtowniane, dla Postgresa to kaszka z mleczkiem. Pod warunkiem oczywiście że użytkownik trochę zna się na tym jak działa baza danych, a nie tylko umie SQLa. Czekam na propozycje rozwiązań (jest wiele różnych, jedne są lepsze, inne gorsze, a inne zabójcze).

W większości przypadków wystarcza MySQL, w pozostałych wystarcza PostgreSQL, a w bardzo nielicznych potrzebne jest coś więcej. System transakcyjny supermarketów Biedronka spokojnie na Postgresie pociągnie.

// BTW. Żeby dyskusja była bardziej rzeczowa, obrońcy baz closed-source niech napiszą konkretnie, w czym silnik MS SQL jest lepszy od Postgresowego. Ale nie teksty w stylu załadowałem ileś tam rekordów i zdechło, tylko wyjaśnienie, dlaczego zdechło i dlaczego MS SQL sobie poradził. Chętnie wzbogacę swoją wiedzę.

Krolik napisał(a)

Uuu, jeśli ktoś pisze, że wrzucil 1,5 mln rekordów i mu baza OpenSourcowa zdechła, to mimo wszystko chyba coś źle zrobił... Z tego co pisza na ich stronie, MySQLa testuja ponoć na 50 mln rekordow...

Nie pisalem, ze zdechla, tylko zapytanie trwalo jak dla mnie dosc dlugo. Oczywiscie test byl tak z ciekawosci, wiec nie robilem jakichs optymalizacji. Jesli juz kierowac sie jakimis przykladami, to tymi podawanymi przez jmaila, bo sa z zycia wziete. To moje to taka ciekawostka, zupelnie nie zaslugujaca na miano 'test wydajnosci zapytania' a co dopiero silnika bazy... :)

pozdrawiam
johny

johny_bravo napisał(a)

Krolik napisał(a)

Uuu, jeśli ktoś pisze, że wrzucil 1,5 mln rekordów i mu baza OpenSourcowa zdechła, to mimo wszystko chyba coś źle zrobił... Z tego co pisza na ich stronie, MySQLa testuja ponoć na 50 mln rekordow...

Nie pisalem, ze zdechla, tylko zapytanie trwalo jak dla mnie dosc dlugo. Oczywiscie test byl tak z ciekawosci, wiec nie robilem jakichs optymalizacji.

No wlaśnie. EXPLAIN pewnie powiedziałby dlaczego. Może był skan sekwencyjny całej tabeli? :> Jeśli baza ma kilkadziesiąt tysięcy rekordów, to komputer jest tak szybki, że nawet beznadziejny plan wykona szybko i nie będzie nikomu to przeszkadzać. Schody się zaczynają gdy rekordów są miliony. Wtedy optymalizacja jest konieczna. Zadanie, które napisałem w poprzednim poście jest banalne dla 10 tys. rekordów. Przy kilkudziesięciu/kilkuset milionach rekordów pomyłka może oznaczać wydłużenie wykonywania zapytania o wiele godzin lub nawet dni. Dobre bazy komercyjne mają tę przewagę że skorygują wiele błędów (np. nie użyją głupich indeksów, albo zasugerują swoje), potrafią też przerwać wykonywanie zapytania w połowie, zmienić plan i wykonać ponownie, lepiej. Natomiast

OpenSourcy pozwalają się łatwo "nabrać", szczególnie osobom bez zbyt głębokiej wiedzy. Wtedy się pojawiają pytania na forach: "Czemu gdy dołożyłem indeks na klumnie p októrej wyszukuję, baza nie używa go?" (baza była mądrzejsza niż użytkownik), albo jeszcze lepiej "Czemu gdy dołożyłem indeks na kolumnie po której wyszukuję, zapytanie wykonuje się kilkadziesiąt razy wolniej?!" (baza dała się nabrać)

yacooh napisał(a)

jmail napisał(a)

i mamy co? profesjonalny silnik nie za kilkaset tysięcy złotych ale za darmo od tego jakże przklinanego Microsoftu.

jmail napisz mi od kiedy takie rozwiazanie stosuje microsoft? od 2 lat? od 3? Dostepne sa rowniez za darmo silniki od Oracle czy IBMa ale to nie jest rozwiazanie stosowane od zawsze, dopiero niedawno "wielcy" zauwazyli, ze moga cos dac za darmo :)

BTW. czy na MSSQL jest tylko ograniczenie odnosnie ilosci jednoczesnych polaczen? Mi sie wydaje, ze takze organiczenie w ilosci procesorow, ramu w serwerze oraz wielkosci samej bazy. Jezeli mam bledne dane to prosze, popraw mnie :)

Jest ograniczenie dotyczące i ramu i procesorów i bazy. Express obsłgujue 1 procesor i 1 GB Ramu jest w stanie zaadresować i z tego skorzystać i obsługuje bazy do 4 GB (ale kiedy taą bazę osiągniesz używając go jako silnika np do forum?). Tylko pytanie czy rozmawiamy o małej firmie której i tak nie stać na zakup bardzo drogiego serwera czy mówimy o firmie gdzie na serwer wydziela się jakąś jednostkę centralną? a jak chodzi o OpenSource. Z tego co wiem to jedynie FireBird w wersji 2 dopiero obsługuje multiprocesorowość. Więc to ograniczenie niczego nie dowodzi. A jak będzie stać firmę na wydanie 15000 tysięcy na bardziej zaawansowany serwer to się znajdą i pieniądze na oprogramowanie. :P

A dalej. No cóż. Z moich obserwacji wynika że oszczędności (nie kupujmy czegoś droższego tylko dlatego że jest lepsze) w firmach rzadko kiedy zdają egzamin.

A jak chodzi o czas udostępniania. Microsoft poprzednią darmową wersję SQL Server 2000 MSDE udostępnił już w 2001 roku więc.... Dalej chyba nie musze mówić?

królik -> a tu masz swoje zapytanie, które w locie ci napiszę :P tak to się rozwiązuje. to jest kod dla MSSQL'a da się to jakoś przepisać do MySQL'a? nie wiem. w postgresie dałoby się :P ze spokojem tylko przy obrobieniu tych 50 mln rekordów trochę czasu by mu zeszło.

Z resztą zobaczymy :P dajcie jakieś zapytanie na postgresa które do jakiejś tabelki włoży 50 mln rekordów. podejmuję się przetestować MS SQL'a FireBirda i PostgreSQL'a na jednej i tej samej maszynie w takich samych warunkach. trzeba tylko to zapytanie do wygenerowania tabeli mieć :D. hmmmmm. a może sam napiszę ;) dobra biorę się do roboty :P

Wyniki testu niebawem :)

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
begin transaction
create table #tmp(
    id_transakcji int not null
    ,kwota decimal (9,2)
    ,data smallDateTime;
)

declare @data_do smallDateTime;
declare @data_od smallDateTime;
set @data_do = getDate();
set @data_od = dateAdd(y, -1, @data_do);
--załóżmy że tabela z transakcjami nazywa się transakcje ;)

insert into 
    #tmp
select
    id_transakcji
    ,kwota
    ,data
from
    transakcje
where
    data between @data_od and @data_do

alter table #tmp add indeks int not null primary key identity(1,1);

select 
    *
from
    #tmp
where
    kwota < 50;

drop table #tmp;

commit;    

W zadaniu chodzi bardziej o to, jak przygotować dane i skonf. bazę aby zapytanie typu:

SELECT count(*), sum(kwota) FROM transakcje WHERE data > '09-09-2005' AND kwota < 50;

wykonało się jak najszybciej. Wariant bez sumy jest prostszy. Przy czym nie chodzi o jednorazowe zapytanie, tylko wyobraźmy sobie, że gość wykonuje kilka, bo nie jest pewien jakie dane wpisać: np. takie:

SELECT count(), sum(kwota) FROM transakcje WHERE data > '09-09-2005' AND kwota < 30;
SELECT count(), sum(kwota) FROM transakcje WHERE data > '09-09-2005' AND kwota < 40;
SELECT count(), sum(kwota) FROM transakcje WHERE data > '09-09-2005' AND kwota < 50;
SELECT count(), sum(kwota) FROM transakcje WHERE data > '09-09-2005' AND kwota < 80;
SELECT count(*), sum(kwota) FROM transakcje WHERE data > '01-12-2005' AND kwota < 60;

Gość wpisuje każde następne, po otrzymaniu wyników poprzedniego (w trybie interaktywnym).
Zwykle przecież wiemy, ze zapytań jakiegoś typu będzie dużo i chcemy tak zoptymalizować, by działały najszybciej. Oczywiście zamiast zapytania może być procedura (parametryzowana datą i kwotą), która robi to samo.

Twój sposób dla każdego zapytania robi skan sekwencyjny po całej tabeli, co nie jest najgorsze, ale nie jest też najlepsze:

insert into
#tmp
select
id_transakcji
,kwota
,data
from
transakcje
where
data between @data_od and @data_do

1/3 rekordów wrzucasz do tabeli tymczasowej. Baza i tak zrobi skan po calej tabeli, żeby znaleźć te rekordy. O indeksie na dacie nic nie napisałeś, chyba że MSSQL jest tak mądry że sam go założy i to na dodatek dobry indeks :>

Zauważ że wybieramy i podsumowjemy niewielki % rekordów. Jestem ciekaw czasu wykonannia Twojej procedury, ale spodziewam się że będzie dość długi i można na pewno dużo lepiej zarówno w Postgresie jak i MS SQL.

Jeśli możesz poeksperymentować też na Postgresie, to byłoby bardzo fajnie. Ja nie mam takiego dużego dysku, choć kilka milionów rekordów powinno się zmieścić (sprawdzę). Żeby wpisać dużo rekordów do tabeli szybko, trzeba użyć polecenia COPY, bo INSERTY będą wolne (każdy w jedenj transakcji brrrr... - to kolejna rzecz o której trzeba wiedzieć w Postgresie, bo można się naciąć). Pobawię się tym.

widzisz. pierwsze i zasadnicze ;) żeby coś takiego zrobić to wcale inserty nie będą wolniejsze :P poza tym ja sobie wygeneruję gotowy plik dla MSSQL'a Postgre i FireBirda. i zrobię testy :)

a co do tego że to co ja zaproponowałem będzie wolniejsze..... mówiłeś o transakcjach poniżej 50 PLN z poprzedniego roku. to co napisałeś powyżej jest hmmmmm czymś zupełnie innym? ;)

później ci napisze takie zpaytanie.

A najpierw wrzucam do hasha bo dzięki temu uzyskuję mneijszą ilośc rwekordów do następnego filtrowania.

jmail napisał(a)

widzisz. pierwsze i zasadnicze ;) żeby coś takiego zrobić to wcale inserty nie będą wolniejsze :P poza tym ja sobie wygeneruję gotowy plik dla MSSQL'a Postgre i FireBirda. i zrobię testy :)

a co do tego że to co ja zaproponowałem będzie wolniejsze..... mówiłeś o transakcjach poniżej 50 PLN z poprzedniego roku. to co napisałeś powyżej jest hmmmmm czymś zupełnie innym? ;)

Przecież to są transakcje mniejsze niż 50 zł od rok temu do teraz. Ale nie ma znaczenia. Chodzi o to, żeby mniej więcej 1/3 rekordów odsiać po dacie, a z nich 1/10 odsiać po kwocie. I wynik policzyć/podsumować. Gdyby trzeba było to policzyć raz, to żadne indeksy, hashe itp nie pomogą, bo skan sekwencyjny byłby najszybszy, czyli prosty SELECT zadziała i IMHO będzie szybszy na MS SQLu od Twojej procedury z kopiowaniem rekordów do hasha. Po co torzyć indeks, jeśli użyjemy go tylko raz? Zadanie wtedy nie miałoby sensu.

Ugadajcie sie na prv a potem zrobcie temat z wynikami i podsumowaniem.

Obadajcie: http://4programmers.net/Forum/325720