PDA

Pogčedajte punu verziju : SQL (sve baze) = nema binarne pretrage?


bojan_bozovic
15. 02. 2006., 09:32
Palo mi je u oci da zbog DELETE upita mozete imati primarne kljuceve koji nisu po redu, tj da RDBMS ne moze da vrsi binarnu pretragu po primarnim kljucevima = mora da prolazi kroz sve recorde - imate ih milion - milion. Idealno je da se izsortira pa vrsi binarna pretraga, ali to ne moze ako svi kljucevi nisu prisutni, tj imate bar jedan koji fali+dobro je da su po redu ako ih mnogo ima. Flatfile db koji je dobro dizajniran uz binarnu pretragu ima da bije SQL kad je pretraga po primarnim indeksima po sredi - a za sve ostalo ne moze biti sporija jer takodje mozemo da napravimo virtuelnu tabelu, izsortiramo po koloni i vrsimo binarnu pretragu. Naravno da za komplikovaniji upit (dovoljno je WHERE NAME="Pera") mora da se prolazi kroz celu bazu. Zeleo bih malo da prodiskutujem o ovome, mada ne spada u SQL vec dizajn samog RDBMS. Naravno, ovde mislim na flatfile db koji nije na Perlu ili sl. jezicima vec npr. C/C++

Edit: prakticno pri trazenju po primarnom kljucu ne moze da otpadne sortiranje, sto je problem za veliku bazu. Mnogo bi bilo bolje da nema uopste DELETE upita i da su indeksi po redu.

Pedja
15. 02. 2006., 09:52
Flatfile db koji je dobro dizajniran uz binarnu pretragu ima da bije SQL kad je pretraga po primarnim indeksima po sredi - a za sve ostalo ne moze biti sporija jer takodje mozemo da napravimo virtuelnu tabelu, izsortiramo po koloni i vrsimo binarnu pretragu.

Uvek stojim kod misljenja da je svaki RDBMS rezultat dugotrajnog rada velikog broja eksperata u oblasti RDBMS, a to je nauka za sebe (sa sve gomilom high-tech matematike i teorije) i da je malo verovatno da jedan covek moze da na brzaka napravi nesto sto moze da se meri sa optimizovanoscu i tacnoscu rada RDBMS.

S druge strane, svaki RDBMS, na kraju krajeva, radi sa datotekama, razlika je smao u tome da li korsinik datteokama pristupa direktno ili preko servera.

Uzmimo na primer FoxPro DMBS, koji se po karakteristikama i mogucnostima moze meriti i sa naprednijim SQL serverima, a radi na flat file sistemu.

bojan_bozovic
15. 02. 2006., 10:08
Svaki RDBMS pise u fajl. Ne znam sta si zeleo reci za FoxPro?

Samo moram reci da se moze zabiti nos u istu matematicku teoriju, uz priznavanje cinjenice da PC igra ne moze da koristi RDBMS za smestanje podataka (ne mislim tu na teksture i modele, vec na podatke o samoj igri koji se menjaju, a ima ih mnogo). BTW RDBMS pise sve na disk uz logovanje, mozes primeniti i logovanje transakcija cak, mada kome to treba, uz podatke smestene u memoriji, takodje. jel' ti je velicina baze manja od velicine memorije? Ako jeste, sve u memorju pa menjaj i trazi podatke. To RDBMS ne moze. (MySQL moze sa HEAP tabelama, ali da li je onda to brze od direktnog pristupanja podacima, bez overheada za konekciju sa bazom?) Transaction safe baza mora da loguje sve na disk da ako negde pukne, podaci ne budu ugrozeni. Tu je pisanje na disk vrlo sporo. Prakticno, dobro napravljena (tu je teorija nuzna!) flatfile baza moze da bije SQL zato sto ti ne treba logovanje na disk, uspostavljanje konekcije sa serverom i sl., pod uslovom da ne moras da otvaras bazu svakicas (CGI)
Ovo mi je palo na pamet zato sto RDBMS podrzava mnogo toga sto nije potrebno na Webu (transakcije npr. snapshote, strane kljuceve i sl.) ako se to izbaci iz izoptimizuje mislim da bi to moglo biti nesto brze od MySQL, a svakako, uz manji load na serveru.

Pedja
16. 02. 2006., 12:21
Ja sam tvoju prvu poruku razumeo kao ideju da mozes da napravis RDMBS umesto RDBMS-a pa sam ti tako i odgovorio. FoxPro sam naveo kao primer RDBMS koji radi nad flat tabelama.

E sad, ova tvoja druga poruka potpuno menja smer diskusije. Tebi dakle ne treba RDBMS nego ti treba nesto slicno ali specificno uz poprilicna ogranicenja, odnosno nesto sto je baza podataka u prilicno sirokom smislu te reci (toliko sirokom da recimo svaki niz mozemo smatrati bazom).

Ak pravis igricu i treba ti da u memoriji baratas podacima, onda moras razviti svoj sistem, koji ce sigurno raditi brze od RDBMS iz par razloga od kojih najvise uticaja ima to da se radi o specificnom resenju koje je optimizovano da radi samo taj konkretan speicifican posao u specificnim i vidoko kontrolisanim uslovima. RDBMS-u u toj situaciji nema mesta, vec ti preostaje da porucis kako RDBMS radi neke stvari pa implementiras takve tehnike u svoju aplikaciju.

To i dalje ne znaci da je RDBMS inferioran, nego da ti radis aplikaciju koja po svojoj sustini ne moze da koristi RDBMS.

jablan
16. 02. 2006., 12:46
da RDBMS ne moze da vrsi binarnu pretragu po primarnim kljucevima
A... ovaj... odakle ti to da RDBMS-ovi uopšte koriste binarnu pretragu da bi došli do podatka?

Dejan Topalovic
16. 02. 2006., 13:44
@bojan bozovic: Da je Flat DB brza, sigurnija i konzistentnija od nekog RDBMS-a (Oracle, MySQL, MS SQL, IBM DB2, PostgreSQL i td.), zar ne mislis da bi taj princip vec neko razradio i na njemu zgrnuo lovu? Sve to sto pricas - jednostavno ne pije vodu.

Jos se nisam u zivotu susreo sa situacijom u kojoj bi mi umjesto nekog RDBMS-a bolje bilo koristiti flat-text file za cuvanje podataka...

ivanhoe
16. 02. 2006., 15:14
sta zoves binarnom pretragom? Vecina baza koristi B stabla, ali to nema nikakve veze sa binarnim pretrazivanjem...mozda te samo nisam dobro shvatio, ajde pojasni malo sta si tacno mislio?

Takodje unosi u B stablima se obicno ne brisu stalno, nego se samo markiraju kao obrisani, pa se onda sa vremena na vreme uradi brisanje i balansiranje celog stabla...AFAIK...mada posto mi nije jasno sta si hteo da kazes, ne znam da li to ima ikakve veze sa ovim sto ti kazes :)

@Dejan: nerelacione baze kao sto je DBM jesu znatno brze od relacionih baza, mada mislim da nije ovo sto Bojan kaze u pitanju, nego su naprosto jednostavnije (imaju samo jedan kljuc i prakticno ni jednu drugu naprednu funkciju baze osim podrske za konkurentne upise)..

bojan_bozovic
16. 02. 2006., 17:06
B-tree je upravo metod sa smestanje podataka u sortiranom obliku, da bi mogla da se koristi binarna pretraga (Hint: http://www.semaphorecorp.com/btp/algo.html http://en.wikipedia.org/wiki/Binary_search) Jednostavno baza izsortira sve i smesti u B-tree prilikom svakog UPDATE querija (i ako je transaction-safe pise na disk) sto moze da se oduzi. Primer su MyISAM i InnoDB tabele u MySQL i koliko brze ide kad ne mora da se obezbede transakcije, snapshoti, strani kljucevi i sve ostalo (hint - bez provere da li postoji vec kljuc vec dobijas na brzini) Samo u jedan niz izsortiraj podatke i imas rudimentaran B-tree koji dalje mozes da prosirujes :)

@jablan

Ne nego koriste brute-force pretragu :) Vidis da je koriste. Mora, to je teorijski najbolje.

@pedja

Nisam mislio da se nista budzi. Dakle, podaci bi opet bili izsortirani za binarnu pretragu (B-tree), ali bez snapshotova, transakcija, logovanja querija na disk i sl (cak i query ne bi morao da bude SQL query - otpada SQL parser)

jablan
16. 02. 2006., 17:28
B stabla nemaju puno veze sa binarnim pretraživanjem - kad imaš B stablo nemaš potrebe za pretraživanjem, već samo prolazak kroz već sortirano stablo. tačno je da se onda produžava insert i update, ali je to cena koju plaćaš za brži select. ta cena bi bila još veća da podatke držiš sortirane negde sekvencijalno. Ne razumem baš tvoju poentu.

bojan_bozovic
16. 02. 2006., 17:31
Binarna pretraga nije sortiranje. Dovoljno je da imas sledeci b-tree

[a-m] [n-z]
! ...................... !
bojan - jablan pedja

i trazis pedja. da li je p<=m ili nije (binarna pretraga :))

Prakticno, zasto imamo nesto kao MySQL koji podrzava mnogo onoga sto nam te treba (sa DBM prve generacije nisam radio, ali bi mozda tu trebao da bude start neke web baze, ne znam)

@Dejan Topalovic

Perl ili PHP su suvise spori. Dobro je samo ako imas vrlo malo podataka. Moralo bi ovo o cemu pricam da se implemetira u kompajliranom jeziku - bas kao neki RDBMS

zextra
16. 02. 2006., 18:45
Koja je uopste poenta te tvoje price? Uzmi MySQL, osakati ga malo, nemoj da koristis stvari koje po tebi usporavaju rad, i problem resen. Tacno da sve te stvari usporavaju rad same baze (sta mislis zasto je MyISAM najbrzi za proste SELECT upite? E, a kada dodje do relacionih zadataka, tu su negde i MySQL i svi ostali RDBMS-i)

Ako smatras da su connectionless i flatfile baze bolje, probaj nesto kao SQLite (koji, uzgred budi receno, radi i na perlu i na php-u)...

Na osnovu cega konstatujes da je Perl ili PHP suvise spor? Nije problem u kolicini podataka - problem je u nacinu na koji pristupas podacima, a to nije razlog da jezik osudis kao spor.

Moram da navedem ilustrativan primer - ako hoces da preneses recimo stolicu iz jednog stana u drugi, nije logicno unajmljivati sleper za slican posao, osim ako ne mislis da ce se u medjuvremenu javiti potreba da prevezes 100 stolica, za sta ti ne bi bio dovoljan automobil, kojim bi mogao ceo posao da zavrsis da je jedna stolica u pitanju... Ti sad upravo govoris da ne treba da koristimo slepere za male stvari - zasto, ako ti sleperi ne kostaju vise od automobila? Naravno, ako hoces nesto srednje-veliko ili srednje-malo da jako brzo prevezes na odrediste, sleper otpada...

jablan
16. 02. 2006., 18:48
Najgore je što je, koliko razumem, ovde u pitanju izbor između toga da koristiš postojeći šleper ili da praviš auto. ;)

bojan_bozovic
16. 02. 2006., 18:48
@zextra

Ja sam siguran da Perl ima implementiranu (bas kao i PHP) f-ju za quicksort - ali ti to sa milion recorda nece mnogo pomoci. Prakticno, da bazu implementiras u Perlu, jel' to mislis? SQLLite je (sad sam cuo za njega) upravo ono o cemu sam i mislio.

@jablan

To si mislio na Ferrari? Mozda je dobro da se isti strorage engine koristi i za desktop aplikaciju?

jablan
16. 02. 2006., 18:56
To si mislio na Ferrari? Mozda je dobro da se isti strorage engine koristi i za desktop aplikaciju?
Ne znam da li te dobro razumem - MS sa svojom paletom servera ide upravo u tom pravcu: isti se endžin koristi i za heavy-duty veb servere i desktop aplikacije (MSDE).

Ako sam te dobro razumeo - ti predlažeš bazu koja bi čuvala podatke u memoriji. Ne znam zašto brineš o tome - OS i DBMS se staraju o tome da neke delove baze keširaju u memoriji kako bi se upiti brže izvršavali.

A ako ti uopšte nije potrebno da se nešto čuva na disku, što uopšte potežeš DBMS?

zextra
16. 02. 2006., 18:57
Ne, ja nisam mislio na sortiranje milion zapisa, vec na tvoju konstataciju da su perl i php spori jezici.

bojan_bozovic
16. 02. 2006., 19:08
@jablan


A ako ti uopšte nije potrebno da se nešto čuva na disku, što uopšte potežeš DBMS?

To za MSDE ce da radi sa wordpadom. A sto se ovoga tice, mozda mi treba biblioteka kojom cu sam da odlucujem kad je nesto u memoriji a nije? (ako mi sad ne treba mozda mi zatreba, a ima kome treba). DBMS potezem zbog b-tree i binarne pretrage.

@zextra
To je relativno. Za regex Perl ce najverovatnije da bude brzi od svega ostalog. Zavisi od konkretnog problema sta koristis kao optimalno.

Evo sta hocu reci - nema biblioteke koja je i za deo RDBMS i standalone lib za implementaciju trazenja i menjanja podataka na niskom nivou za desktop. Transakcije ti ne trebaju na desktopu npr. a SQLLite ih podrzava - opet idu na nivo podrske za SQL koji je potreban knjigovodstvu u Deutsche Bank, mada cu da pogledam tu biblioteku.

zextra
16. 02. 2006., 22:17
Starije verzije nisu imale transakcije kad sam ja gledao koristio (sto znaci da nisam gledao vec neko vreme).

ivanhoe
17. 02. 2006., 00:48
pa to o cemu ti pricas vec postoji, ima veoma brzo pretrazivanje po jednom kljucu, odlicno odradjeno keshiranje, a i programirano je na izuzetno niskom nivou i veoma efikasno... zove se fajl sistem :D

DejanVesic
12. 03. 2006., 01:29
Htedoh da sve spojim u jedan post, ali ne vredi, idemo redom:

Palo mi je u oci da zbog DELETE upita mozete imati primarne kljuceve koji nisu po redu, tj da RDBMS ne moze da vrsi binarnu pretragu po primarnim kljucevima = mora da prolazi kroz sve recorde - imate ih milion - milion. Idealno je da se izsortira pa vrsi binarna pretraga, ali to ne moze ako svi kljucevi nisu prisutni, tj imate bar jedan koji fali+dobro je da su po redu ako ih mnogo ima.

Apsolutno netačno. Kod svakog RDBMS postoji indeks nad primarnim ključem, koji je u formatu B stabla najčešće i koji se ažurira kako se menjaju slogovi. Ono što je bitno je da kada se koristi indeks ovog tipa, za operaciju pretraživanja (nalaženja sloga) za dalju operaciju nikada ne treba više od log(N) u vremenu - što jako sporo raste u odnosu na broj slogova u tabeli.


Flatfile db koji je dobro dizajniran uz binarnu pretragu ima da bije SQL kad je pretraga po primarnim indeksima po sredi - a za sve ostalo ne moze biti sporija jer takodje mozemo da napravimo virtuelnu tabelu, izsortiramo po koloni i vrsimo binarnu pretragu. Naravno da za komplikovaniji upit (dovoljno je WHERE NAME="Pera") mora da se prolazi kroz celu bazu. Zeleo bih malo da prodiskutujem o ovome, mada ne spada u SQL vec dizajn samog RDBMS. Naravno, ovde mislim na flatfile db koji nije na Perlu ili sl. jezicima vec npr. C/C++
Edit: prakticno pri trazenju po primarnom kljucu ne moze da otpadne sortiranje, sto je problem za veliku bazu. Mnogo bi bilo bolje da nema uopste DELETE upita i da su indeksi po redu.

FlatfileDB? Koji je dobro dizajniran uz binarnu pretragu? Pa ti implicitno radiš isto što i RDBMS - imaš podatke (FlatFile) i indeks (sortiran binarno) i koristiš indeks da nađeš slog; samo što je daleko lakše dodati novi slog na kraj tabele i njegov ključ u b-stablo indeks nego dodati novi slog u FlatFileDB, jer ovaj FlatFile u najgorem slučaju moraš da sortiraš ceo.

DejanVesic
12. 03. 2006., 01:33
jel' ti je velicina baze manja od velicine memorije? Ako jeste, sve u memorju pa menjaj i trazi podatke. To RDBMS ne moze. (MySQL moze sa HEAP tabelama, ali da li je onda to brze od direktnog pristupanja podacima, bez overheada za konekciju sa bazom?) Transaction safe baza mora da loguje sve na disk da ako negde pukne, podaci ne budu ugrozeni. Tu je pisanje na disk vrlo sporo. Prakticno, dobro napravljena (tu je teorija nuzna!) flatfile baza moze da bije SQL zato sto ti ne treba logovanje na disk, uspostavljanje konekcije sa serverom i sl., pod uslovom da ne moras da otvaras bazu svakicas (CGI)
Ovo mi je palo na pamet zato sto RDBMS podrzava mnogo toga sto nije potrebno na Webu (transakcije npr. snapshote, strane kljuceve i sl.) ako se to izbaci iz izoptimizuje mislim da bi to moglo biti nesto brze od MySQL, a svakako, uz manji load na serveru.

Očigledno mešaš babe i žabe: ako ti treba sigurna baza, koja prilikom pucanja (recimo tvoje aplikacije za prodaju na webu) ostavi sistem u konzistentnom stanju (pare si ili skinuo sa kartice i prodao proizvod, ili nisi i nisi umanjio stanje na lageru) ILI može da ga vrati u konzistentno stanje (kroz logove) onda koristiš RDBMS.

Ako ti to ne treba, nego ti treba lookup file, spremiš lepo file, sortiraš i eto tebi sve lepo taman za učitavanje u memoriju.

DejanVesic
12. 03. 2006., 01:38
@jablan
To za MSDE ce da radi sa wordpadom. A sto se ovoga tice, mozda mi treba biblioteka kojom cu sam da odlucujem kad je nesto u memoriji a nije? (ako mi sad ne treba mozda mi zatreba, a ima kome treba). DBMS potezem zbog b-tree i binarne pretrage.


Huh? MSDE _odlično_ radi posao do 10-tak konekcija i do 2Gb podataka; to je punokrvni SQL 2000 motor, oslabljen na gornji način. Site od 2000+ aktivnih poseta (log in / rad sa sajtom itd) dnevno sasvim solidno radi sa MSDE (kada jednom lepo napraviš connection pool da poštuje gornja ograničenja).


Evo sta hocu reci - nema biblioteke koja je i za deo RDBMS i standalone lib za implementaciju trazenja i menjanja podataka na niskom nivou za desktop. Transakcije ti ne trebaju na desktopu npr. a SQLLite ih podrzava - opet idu na nivo podrske za SQL koji je potreban knjigovodstvu u Deutsche Bank, mada cu da pogledam tu biblioteku.

Ako ti trebaju transakcije, onda SQL RDBMS; ako ti ne trebaju, eno ti DBF / Access / MySQL - mnogo brzo, ali nema garantovanih commit / rollback tačaka u transakcijama - ako tebi i tvom klijentu to ne smeta, super ... samo ne bih stavio moje pare na takav sajt :)