Elektronikus kormányzat

Én úgy gondolom, hogy a nyílt forráskód jobb, és olcsóbb. _Csak_ ebből is következik, hogy az _összes_ program előbb utóbb nyilt forráskodú lesz. Ami hátráltatja a terjedést az a hit és az emberi butaság. Kormányzati/cég vezetők azt _hiszik_ (anélkül hogy _tudnák_, vagy kimérnék), hogy a XY cég zárt forráskodu terméke jobb. ez még a jelenre néhány esetben igaz is, de a közel/közép jővőre már biztos, hogy nem! Minden egyes apró lépés amikor valamilyen cég/kormányzat nyilt forráskodura vált az jó. _TUTI_ nem fog visszatérni a "középkorba".

Saját tapasztalat a hit tarthatalanságára: egy 3 milliós IBM PC klaszteren, 300eFt adv. RedHat szerverene futó 10 milliós Oracle 2 nap optimalizálás után már csak kicsit volt lasabb, mint egy 300eFt-s laptopon futo default Debian, es Postgres _ugyanazon_ adatbazissal, es adatokkal!!!

El kéne már felejteni a _HIT_-et a számítástechnikában! Döntsenek a mérések.

>Egy példa nem támaszt alá soha egy elméletet. :)

Igaz, de képes megcáfolni egy másikat!;-))

>Amúgy meg ha nem lenne, lett volna hit az emberekben, akkor most nem lenne GNU, Linux, *BSD, stb.

Ez is igaz. Tehát pontosítok: A mi hitünk maradjoon az egyetlen hit a számítástechnikában.;-)))))

3 mill. IBM szerver:

P4 2Ghz (2 redundáns gép, _nem_ klaszter, elirtam az elobb)

1.5G RAM

Oracle 9i (minden veheto opcioval, gazdag ugyfel volt)

Amelyik tabla erdekes, az 150 mezo, 18000 rekord. A mezok atlagos szelessege 500 karakter. A query 6 join-t tartalmazott (azert nem tobbet, mert az Oracle 6 join felett _rendkivul_ lassu)

laptop:

0.9 GHz PIII Celeron

256M RAM

Debian sarge

Postgress 7.2

A mi szakertonk velemenye az okokrol (a szakerto altalaban adatbazis, es Postgres szakerto volt, elkepzelheto, hogy van meg magikus Oracle beallitas, ami gyorsitana):

1. az Oracle-nek alapbol lassu a query parser-e (nagyon(!) a Postgres-hez kepest)

2. Az Oracle-ben nincs limit, csak alselect-el lehet megcsinalni

3. Az Oracle optimalizalo buta: nem jon ra ara, hogy melyik szukiteseket kell eloszor megcsinalni

4. Az Oracle alapbeallitasok az "index betoltsegenek valoszinusege"=0%, ami miatt minden keresese linearis.

5. Magasabb joinszamok (12-60 db) az Oracle osszehasonlithatatlanul lassabb, mint a Postgress.

Az Oracle JDBC drivere kapásból szüri a HINT-eket.;-( A gond a TCO! Tehát 2 hét munka van egy bonyolultabb Oracle/SQL query-vel mire elfogadható sebességüre gyorsul, Oracle informaciot szerezni legalabbis problemas (a doksi olyan amilyen, olyan irta akinek fingja sincs rola). Amire szükség lenne az, hogy megoldja a problémámat. De csak a ködösítés megy. A Postgres listakon 10-20 perc alatt a parser iroja valaszolt, es a parser-be is hajlando volt beletenni cuccot (ha zaroljelbe kerul a from-ban levo cucc, akkor nem fut le az optimalizalo, elhiszi, hogy jobban tudja a query iroja, mint amit optimalizalassal el lehet erni.)

>elküldenéd a select mindkét változatát?

>(persze, ha nem titok)

Tudomasom szerint nem (de utana kell kerdeznem), ha igazam van, akkor meg ma megkapod.

>2. állítás mi az a limit?

select mezo1,mezo2 form tabla1 where feltetel1 limit 10;

hat a feltetelnek megfelelo rekordok kozul csak az elso 10 darabot adja vissza.

>3. állítás hamis, csak akkor igaz, ha nem készültek statisztikák.

Akkor frissen migralt adatbazis volt, nem volt mibol statisztikazni, azota meg nem en foglalkozom vele fogalmam sincs mi tortent, de utanakerdezek, ha lenyeges.

>4. állítást nem értem.

Amikor kerestuk az okat, hogy miert nem sokkal gyorsabb az Oracle (megvolt nekunk is a hitunk, hogy biztos gyorsabbnak kell lennie,mert piacvezeto), akkor 1-2 nap utan talaltunk egy beallitast, ami arra volt jellemzo, hogy milyen valoszinuseggel tart egy index-et a memoriaban. Ez alapbol 0-ra volt allitva. Most nem tudom a korrekt elnevezeset, de megkeresem ha lenyeges.