PHP.EE FOORUM   
Nimi:   Pass:   Mäleta mind! 
   Teemad | php.ee esilehele | registreeri | Märgi kõik teemad loetuks | #php.ee Skype vestlus | RSS
UUS TEEMA  OTSI  Lehekülgi: 1
Andmebaasi mootorid
Postitaja: Möku 2017-06-19 08:00:19
Hei, oleks küsida, millised võiksid olla paremad/võimsamad andmebaasi mootorid kui MySql? Olen kuulnud, et mingi Oracle ja/või Sybase olevad kiired, kuid need olevat tasulised ja kallid. Kas keegi teab ka tasuta ja kiireid andmebaase, mis suudaksid hallata suuremaid andmemahte? Aitäh!
RE: Andmebaasi mootorid
Postitaja: koll, 2017-06-19 15:59:07
99.9999% sõltub rakenduse kiirus ikka rakenduse kirjutajast, mitte kasutatavast andmebaasist. optimeerimata Oracle rakendus on kordades aeglasem kui optimeeritud SQLite rakendus sama andmemahu juures.

RE: Andmebaasi mootorid
Postitaja: - 2017-06-20 09:01:31
Postgres?
RE: Andmebaasi mootorid
Postitaja: keegel 2017-06-23 12:39:28
Nodejs ja mongo
RE: Andmebaasi mootorid
Postitaja: Osiris 2017-07-01 02:42:25
TSITEERITUD:
Hei, oleks küsida, millised võiksid olla
paremad/võimsamad andmebaasi mootorid kui MySql?
Olen kuulnud, et mingi Oracle ja/või Sybase olevad kiired,
kuid need olevat tasulised ja kallid. Kas keegi teab ka tasuta
ja kiireid andmebaase, mis suudaksid hallata suuremaid andmemahte? Aitäh!



Mina soovitan praeguseks pankrotti läinud idu firma
poolt ~7 aastat arenduses olnud RethinkDB andmebaasimootorit:

https://www.rethinkdb.com/

https://www.youtube.com/watch?v=qKPKsBNw604

https://www.youtube.com/watch?v=cnpSi9qI02E

Andmebaasimootori valikuga eksimine pole nii suureks
probleemiks kui Te pöördute oma rakenduses andmebaasi
poole vaid läbi oma enda rakenduse spetsiifilise
teegi ("application specific database access layer").
Selle arendusmustri idee seisneb selles, et kuniks
kogu Teie rakenduse "äriloogika" salvestab ja loeb
andmeid vaid Teie enda rakenduse spetsiifilise API
kaudu, võite hiljem andmebaasimootori välja vahetada
ja targalt koostatud API korral ka lausa andmete
salvestamise formaati muuta.

Üks asi, mida Te seal API-s teha ei tohi, on ehitada
see API sellisena, et Teil tuleb teha andmebaasi
ühe lõppkasutaja kohta "palju" pärnguid.
Andmed tuleb salvestada viisil, et paari
andmebaasimootori jaoks "odava" päringuga saate vajaliku
kätte ning kuna igasugune kõvaketta ja andmebaaside poole
pöördumine on RAM-pöördumistega võrreldes tiguaeglane, siis
kindlasti tasub proovida päringute teostamist, sõltumata
andmebaasimootori tüübist, ajaliselt hajutada, nõnda, et
võimalikult palju arvutustööd toimuks ajal, mil kasutajatele
pole tarvis midagi kiiresti tarnida. Näiteks, panete mõne
cron-töö taustale käima.


Tarkvara kirjutama asudes soovitan alguses luua see
rakenduse spetsiifiline andmebaasi-kiht SQLite toega,
sest sedasi on hea testida ja enam-vähem iga peavoolu-programmeerimiskeele
jaoks on stdlib'is SQLite olemas. Vähemalt
Python'is, PHP-s, Ruby's, Java's, C#'is, Perl'is, ...

Siis, kui rakenduse "äriloogika" on valmis ja skaleerimiseks
läheb, alles siis vaadata, et kas Teie kasutajate hulga
ja serveri-koormuse korral on tarvis midagi kobedamat.
Kuna Teie rakenduse spetsiifiline andmebaasi-liides
võimaldab andmebaasimootori ja ka andmete salvestamise
formaadi hiljem välja vahetada ilma, et muud rakendust
üldse muuta tuleks, siis saate hiljem valida omale
just sellise andmebaasimootori, mida Teie poolt kasutatavad
serverid kõige väiksema vaevaga toetavad või mis just
Teile endale mingil põhjusel rohkem meeldib.

Kahju küll, et lõbusa andmebaasimootorite uurimise
Teil siin praegu ära rikkusin, aga aus vastus on,
et Teil on alguses vaja andmebaasimootorit välja vahetada
võimaldavat tarkvara arhitektuuri ja alles siis andmebaasimootorit.

Kui eksootikat tahate, võite uurida teadus-arvutustes
üle 10 aasta kasutuses olnud binaar-jadade salvestamiseks
mõeldud "konteinerite-konteinerite-konteiner-formaati"

HDF5
https://www.hdfgroup.org/

mis on umbes nagu XML või JSON või YAML, kuid
binaar-jadade ("blob") jaoks. Ka HDF5'ele on paljude
programmeerimiskeelte jaoks teegid olemas, eriti
just Python'i korral, sest Python'it kiputakse viimasel
ajal palju teadusarvutustes kasutama.


Tänan lugemast :-)

P.S. Jumala eest, VÄLTIGE Oracle't !!!

http://archive.is/3zbOb

https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.



RE: Andmebaasi mootorid
Postitaja: blaa 2017-07-01 13:08:41
Need "andmebaasi mootori väljavahetamist võimaldavad tarkvarad" on kõik ühe suure puudusega. Nad ei kasuta konkreetse andmebaasi häid omadusi ära. Ei saa teha sellist universaalset. Sama moodi võiks ehitada sisepõlemismootori, mis ühel päeval tarbib bensiini ja teisel päeval diislit, kokkuvõttes on tegemist ühe jurakaga, milles on sisuliselt kaks mootorit ja kaks korda rohkem probleeme ja kummagi kütuse eeliseid ei suudeta 100% ära kasutada.
RE: Andmebaasi mootorid
Postitaja: Pitsatarnekuukulgur 2017-07-02 03:56:57
TSITEERITUD:
Need "andmebaasi mootori väljavahetamist võimaldavad
tarkvarad" on kõik ühe suure puudusega. Nad ei kasuta konkreetse
andmebaasi häid omadusi ära. Ei saa teha sellist universaalset.
Sama moodi võiks ehitada sisepõlemismootori, mis ühel päeval tarbib
bensiini ja teisel päeval diislit, kokkuvõttes on tegemist ühe
jurakaga, milles on sisuliselt kaks mootorit ja kaks korda rohkem
probleeme ja kummagi kütuse eeliseid ei suudeta 100% ära kasutada.



Nõustun Teie väitega, et
adaptri arendusmustrit ("adapber design pattern") kasutades
ei ole andmebaasimootori kõiki võimalusi võimalik nii efektiivselt
ära kasutada kui otse andmebaasimootori spetsiifilist
koodi kirjutades, kuid oponerin Teie väitele argumendiga,
et inimesed ei kirjuta süsteemitarkvara assembleris, sõltumata sellest,
et assembleris kirjutatult oleks tarkvara palju efektiivsem.
Linux'i kernel on kirjutatud programmeerimiskeeles C põhjusel,
et siis on võimalik Linux tööle lasta erinevate CPU-de peal,
millel on väga erinev "assembleri käsustik"
("instruction set architecture"). Äärmisel juhul lisatakse
optimiseerimiseks vaid mõnda, hästi piiritletud, kohta natuke
assemblerit.


Andmebaasi-abstraktsioonikihiga on sama lugu: jah, ta muudab
koodi ebaefektiivsemaks, aga tarkvara äriloogika osa muutmine
ja testimine iga uue andmebaasimootori kasutuselevõtul on
töömahult mahukam ja seega ka rahaliselt kallim kui arvutiklastrisse
lisa-arvutite ühendamine ning juba ainuüksi kõvaketaste
andmevahetus-kiiruse piiratuse tõttu tuleb nii kui nii
andmete salvestamiseks/lugemiseks, isegi kui neid andmeid on vaid paar GiB,
kõvakettaid kuidagi moodi paralleelselt ühendada, kas
ühte arvutisse RAID-i või arvutiklastris olevatesse eri arvutitesse
laiali jaotada, nagu seda Google arvutuskeskustes tehtud on.
Kel rahalisi võimalusi rohkem ja elektritarve pole probleemiks,
kasutab lausa RAID-idega arvutiklastrit.


Andmebaasimootori väljavahetamise põhjus tuleneb tegelikult
sellest, et riistvara ei pea vastu ja tuleb aja jooksul välja vahetada.
Vana riistvara peal jooksvat operatsioonisüsteemi
ei pruugi olla uue riistvaraga kohaldatud ja isegi kui
operatsioonisüsteem on uue riistvara jaoks ära uuendatud/kohaldatud,
ei pruugi andmebaasimootor operatsioonisüsteemi uue versiooni
peal jooksta. Teoorias ta muidugi peaks ka operatsioonisüsteemi
uuema versiooni peal jooksma, sest operatsioonisüsteemi üks
peamistest eesmärkidest on riistvara abstrahheerimine, kuid
idee, et tarkvarakomponendi uuem versioon on tagasiühilduv
tema vanema versiooiga, praktikas ei kehti, sõltumata siirastest
püüdlustest tagasiühilduvust tagada.


Teisisõnu öeldes, andmebaasimootori vahetus osutub vajalikuks
seoses sellega, et vana riistvara mitte pelgalt ei jää "aeglaseks",
vaid sõna otseses mõttes lakkab toimimast ja uuema riistvara
peal toimiva operatsioonisüsteemiga ei pruugi sama andmebaasimootori
uuemat versiooni enam võtta olla või on andmebaasimootori
uuem versioon vana versiooniga tagasiühildumatu. Andmed aga
peavad kättesaadavad, kasutatavad, olema kauem kui neid
hoidev, töötlev, riistvara. Samal ajal riistvara uuendus
läheb jube kalliks kui vana riistvara väljavahetamisega
tuleb hakata tegelema ka tarkvara-arendusega. Targem on siis
tarkvara kohe nii kirjutada, et tulevikus olev tarkvara-arendustöö
maht oleks võimalust mööda minimiseeritud, eriti arvestades
asjaolu, et hästi vana süsteemi eripärasid tundvad
tarkvara-arendajad/progrejad võivad olla juba vanadussurma
surnud, nagu mitmete COBOL-süsteemidega praktikas on.

See probleem on nii õudne, et osad inimesed on selle
leevendamiseks lausa äri püsti pannud, pakkudes vanade
arvutite tarkvaralisi simulaatoreid:

https://www.lzlabs.com/
(arhiivkoopia: https://archive.is/clvCY )


(Guugeldamisfraas.)
https://en.wikipedia.org/wiki/Legacy_system


©weitslaste LzLabs'i tootetutvustus sisaldab antud probleemi
ülevaatlikku kirjeldust:

https://www.youtube.com/watch?v=IAJmisvn8HQ

Ainuke asi, mida nad seal oma tootetutvustuses rääkimata
jätavad ja mille kohta internetiavarustest otsides
mõne ajaveebi-postituse saab leida, on see, et vanaaegse
arvuti simulaator simuleeribki vaid toda vana-aegset
arvutit, mis võimaldas jooksutada vaid nii mitut
lõime paralleelselt kui tooo vana-aegne arvuti CPU-tuumi
omas ja kui tahta neid vana-aegsel arvutil olevaid
andmeid kiiremini sealt arvutist kätte saada, tuleb
ikka hakata kuidagi vana-aegsete arvutite klastrit moodustama.
Kuna vanaaegse arvuti simuleerimise ainuke mõte oli
seal vanaaegsel arvutil jooksva tarkvara ümberkirjutamise
vältimine, siis ainukene viis päringute lugemist kiirendada
on panna mitu vanaaegset, simuleeritavat, arvutit
paralleelselt, RAID-sarnaselt, klastrisse ja keelata
ära vanaaegsel arvutil jooksvasse infosüstemi andmete
lisamine. Simuleeritavasse vanaaegsesse arvutisse
andmete salvestamine pole võimalik ka põhjusel, et
simulatsiooni täpsuse huvides peab simulaator simuleerima
ka vana-aegset, viletsa mahutavusega, salvestusseadmeid
ja simuleeritaval arvutil saab "kõvaketas täis", rääkimata
siis eri arvutite andmestike sünkroniseerimisprobleemist.
See tähendab, et kui vanadel arvutitel jooksvat infosüsteemi
uuemal, jõudsamal, arvutil tööle lasta ei saa, siis tuleb
uued andmed tuleb nii kui nii uude infosüsteemi salvestada,
millega kaasneb uue infosüsteemi arendustööde maksumus.


Kaabakad projektivehkimisfirmad teevad muidugi, löraki,
kähku mingi andmebaasi-abstraktsioonikihita infosüsteemi
ära, klient on kah omas lolluses õnnelik, et kähku ja
odavamalt sai ja mõnede aastate pärast hakkab toimuma
ÄRI-INFOSÜSTEEMIDE KLASSIKA, a la Siljaline'i vana
infosüsteem, kus väriseti, et vanasse käkki
infosüsteemi on nii palju investeeritud, et me ei saa
seda minema visata ja uue infosüsteemi loomine võtab
kaua aega ja kui see vana ikka täitsa otsad annab,
siis võidab uue infosüsteemi loomise hanke jälle
selline osapool, kes tarnib uue võimalikult kähku,
et äriprotsessid saaks võimalikult kähku vana, tuksi läinud,
infosüsteemi pealt uue peale ümber kolida, aga
võimalikult kähku tarnimine tähendab põhjalikuma,
kasutajale mitte-nähtava, töö tegemata jätmist ja
andmebaasi-abstraktsioonikihi tegemata jättev osapool
suudab tarnida lühemat tarne-aega kui tööd korralikult
tegev osapool, kuid samal ajal "tehniline võlg" ("technical debt")
muudkui akumuleerub, arendus-kulud infosüsteemi tellijale
muudkui akumuleeruvad ja kuna käkk-arendust viib läbi
ilmselgelt mitte kõige kõrgema erialase moraaliga
osapool, sest sellise hange ongi võidetav ju vaid
kohe alguseest saadik, teadlikult, üle nurga lastes,
siis see, et tellija projektis tehniline võlg kasvab
ja tellija arved vaid suurenevad, on tarnija silmis
vaid positiivne nähtus, sest siis "tööprotsess ju käib",
progrejad "teevad midagi" ja kliendile saab selle "millegi"
eest arveid välja kirjutada ja sellise progrejate töö pealt
protsenti korjata ja tarkvara-arendus-firmaomanike kasumit,
tulu, suurendada. Seega, klient on loll ja maksab oma
kärsituse ja rumaluse eest RÄIGET HINDA, umbes nagu
SMS-laenu-võtjad.


Kuna kõik tarkvara-arendajad ei ole nii moraalitud, et
sellises skeemis osaleda, siis ilmselgelt kõik ka
suurkorporatiivsesse äritarkvara-arendusse oma iseloomult
ei sobi.


Tänan lugemast.

Leheküljed: 1

©2002-2013 Martin Rebane & PHP.ee kaasautorid
  0.434460878372