Onderwerp: Einde van de relationele databases is nabij

Jan Ehrhardt:
>In MySQL is het vaak sneller om 1 maal alles uit een tabel te selecteren
>en dat in PHP-variabelen op te slaan dan telkens een nieuwe query uit te
>voeren op dezelfde tabel. Daar kan je veeeeel tijd mee winnen.

Het moment komt inderdaad steeds dichterbij dat we voor alledaagse
toepassingen afscheid kunnen neman van de database. Want waarom zouden we
data nog langer heen en weer converteren tussen hiërarchie (XML), objecten
(memory) en tabellen (database)?

Modelleer je objecten in een hiërarchie zoals in XML, gebruik transparante
persistentie van een OODBMS, zorg voor genoeg geheugenruimte zodat alle
objecten in geheugen gecached kunnen worden en voorwaar! Het geneuzel met
tabellen, queries, indexen en andere kaartenbakconcepten uit de
mainframe-tijd ligt achter ons.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman wrote:
> Jan Ehrhardt:
>
>>In MySQL is het vaak sneller om 1 maal alles uit een tabel te selecteren
>>en dat in PHP-variabelen op te slaan dan telkens een nieuwe query uit te
>>voeren op dezelfde tabel. Daar kan je veeeeel tijd mee winnen.
>
>
> Het moment komt inderdaad steeds dichterbij dat we voor alledaagse
> toepassingen afscheid kunnen neman van de database. Want waarom zouden we
> data nog langer heen en weer converteren tussen hiërarchie (XML), objecten
> (memory) en tabellen (database)?
>
> Modelleer je objecten in een hiërarchie zoals in XML, gebruik transparante
> persistentie van een OODBMS, zorg voor genoeg geheugenruimte zodat alle
> objecten in geheugen gecached kunnen worden en voorwaar!

Alles in het geheugebn cachen?? Weet je wel hoe groot databases kunnen worden.
Ik neem dat je bedoelt dat je objecten die je vaak gebruikt laat cachen.
Dat klopt wel maar dat cachen dat hoef jezelf niet te doen dat doet het OS.
En natuurlijk is de keuze van hardware ook van belang, want de cache bevindt zich natuurlijk
in het snelle, dure geheugen.

> Het geneuzel met
> tabellen, queries, indexen en andere kaartenbakconcepten uit de
> mainframe-tijd ligt achter ons.
>

Hier heb je gedeeltelijk gelijk. Maar databases zullen we nooit verliezen, en queries ook niet.
Wel sql queries, maar xpath is ook een query langauge.
Weet je wat cool is, ze zijn bezig op o.a. UniversiteitTwente bezig met een razendsnelle xml database,
deze database moet ondersteuning gaan beiden voor ZQuery.
XML-Databases zijn volgens mij de toekomst.

Rene Pijlman wrote:
> Het moment komt inderdaad steeds dichterbij dat we voor alledaagse
> toepassingen afscheid kunnen neman van de database. Want waarom zouden we
> data nog langer heen en weer converteren tussen hiërarchie (XML), objecten
> (memory) en tabellen (database)?

Hmm het heen en weer converteren is nog steeds nodig, van Hard-Disc informatie naar
software-objecten maar waar je wel gelijk in hebt is het punt dat de data al hierarchisch is opgeslagen
in de database. Het converteren tussen hierarchien (XML) is wel nodig, want een browser leest bijvoorbeeld XHTML in.
De ene xml-formaat wil je over het algemeen omzetten in de andere, indien nodig.

Tjerk Wolterink:
>Rene Pijlman:
>> Modelleer je objecten in een hiërarchie zoals in XML, gebruik transparante
>> persistentie van een OODBMS, zorg voor genoeg geheugenruimte zodat alle
>> objecten in geheugen gecached kunnen worden en voorwaar!
>
>Alles in het geheugebn cachen??

Nou en of.
http://sourceforge.net/projects/prevayler

>Weet je wel hoe groot databases kunnen worden.

Weet je wel hoe groot geheugen tegenwoordig kan zijn?

>Ik neem dat je bedoelt dat je objecten die je vaak gebruikt laat cachen.

Als ik dat zou bedoelen dan zou ik dat zeggen :-)

>Dat klopt wel maar dat cachen dat hoef jezelf niet te doen dat doet het OS.

Die conclusie klopt niet. Caching vindt plaats op verschillende niveaus,
om goede redenen. Het feit dat een lager niveau cachet wil niet zeggen dat
je het op hogere niveaus kunt laten. Dat is namelijk minder efficiënt, en
efficiëntie is het doel van caching.

>Weet je wat cool is, ze zijn bezig op o.a. UniversiteitTwente bezig met een
>razendsnelle xml database, deze database moet ondersteuning gaan beiden voor
>ZQuery. XML-Databases zijn volgens mij de toekomst.

Het is een interessante ontwikkeling. Want de huidige driedeling in de
dominante modellen (1. XML = hiërarchisch voor uitwisseling 2.
objectgeoriënteerd in geheugen 3. relationeel in de database) is zo krom
als een hoepel.

>Hmm het heen en weer converteren is nog steeds nodig, van Hard-Disc
>informatie naar software-objecten

Dat duurt natuurlijk niet lang meer. Hard-disk is een archaïsch concept.
In de tijd dat het magnetisch spoor onder de kop een rondje draait heeft
een hedendaagse webserver zo'n 96.000.000 CPU cycles staan wachten, om na
de eerste de beste dereferentie van een pointer in het lang verwachtte
disk block direct weer geïnterumpeerd te worden om minstens nog eens
96.000.000 cycles te wachten. Hard disks worden vervangen door solid
state.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman wrote:

> disk block direct weer geïnterumpeerd te worden om minstens nog eens
> 96.000.000 cycles te wachten. Hard disks worden vervangen door solid
> state.

Weet je wel wat dat kost? De prijs voor bulkopslag is bij harddisks nog
steeds veruit het laagst.

--
ir. J.C.A. Wevers // Physics and science fiction site:
johanw@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

Johan Wevers:
[hard disk -> solid state]
>De prijs voor bulkopslag is bij harddisks nog steeds veruit het laagst.

Zeker, nog wel. 30 jaar geleden was een buis goedkoper dan een transistor.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman in nl.internet.www.server-side (Wed, 02 Feb 2005 01:17:11
+0100):

>Johan Wevers:
>[hard disk -> solid state]
>>De prijs voor bulkopslag is bij harddisks nog steeds veruit het laagst.
>
>Zeker, nog wel. 30 jaar geleden was een buis goedkoper dan een transistor.

Ach, kom nou toch. De transistor was toen al 20 jaar oud. En de laatste
buizenradio's werden rond 1966 geintroduceerd. Iets veel complexers als
de 8088 kostte in 1975 110 dollar.

Jan
--
Look, Ma. No tables - http://enbio.steenbergen-stichting.nl/

Jan Ehrhardt:
>Rene Pijlman:
>30 jaar geleden was een buis goedkoper dan een transistor.
>
>Ach, kom nou toch. De transistor was toen al 20 jaar oud. En de laatste
>buizenradio's werden rond 1966 geintroduceerd.

Nou ja, laat het dan 40 a 50 jaar zijn.

>Iets veel complexers als de 8088 kostte in 1975 110 dollar.

Is het werkelijk? Waren die dingen toen al zo goedkoop? Mijn
inkoopervaring begon met een Z80 in 1982 en die waren toen inderdaad ook
al niet zo duur meer.

Goed, ik zat er anderhalf decennium naast :-)

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman in nl.internet.www.server-side (Wed, 02 Feb 2005 12:03:26
+0100):

>Jan Ehrhardt:
>
>>Iets veel complexers als de 8088 kostte in 1975 110 dollar.
>
>Is het werkelijk? Waren die dingen toen al zo goedkoop?

In 1977 was-ie zelfs al 20 dollar.
http://www.euronet.nl/users/schuurma...ws/sv/tnsv.htm

>Goed, ik zat er anderhalf decennium naast :-)

Time flies when you are having fun.

Jan
--
Look, Ma. No tables - http://enbio.steenbergen-stichting.nl/

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
> Het moment komt inderdaad steeds dichterbij dat we voor alledaagse
> toepassingen afscheid kunnen neman van de database. Want waarom zouden we
> data nog langer heen en weer converteren tussen hi?rarchie (XML), objecten
> (memory) en tabellen (database)?
>
> Modelleer je objecten in een hi?rarchie zoals in XML, gebruik transparante
> persistentie van een OODBMS, zorg voor genoeg geheugenruimte zodat alle
> objecten in geheugen gecached kunnen worden en voorwaar! Het geneuzel met
> tabellen, queries, indexen en andere kaartenbakconcepten uit de
> mainframe-tijd ligt achter ons.

Precies. Een dual opteron met 24 GByte ram kost minder dan 8000 Euro.
Weg met de oude troep!

Stephan

Rene Pijlman wrote:
> Tjerk Wolterink:
>
>>Rene Pijlman:
>>
>>>Modelleer je objecten in een hiërarchie zoals in XML, gebruik transparante
>>>persistentie van een OODBMS, zorg voor genoeg geheugenruimte zodat alle
>>>objecten in geheugen gecached kunnen worden en voorwaar!
>>
>>Alles in het geheugebn cachen??
>
>
> Nou en of.
> http://sourceforge.net/projects/prevayler
>

Ok het kan alleen als je genoeg geheugen hebt, maar
meestal wil je software schrijven die *gedeeltelijk* anafhankelijk is
van de hoeveelheid geheugen die aanwezig is.
Het hele idee van virtuel memory is daarop gebaseerd.

>
>>Weet je wel hoe groot databases kunnen worden.
>
>
> Weet je wel hoe groot geheugen tegenwoordig kan zijn?
>

Tuulk in theorie kan dat ook groot zijn, maar het is gewoon nog te duur.
Ik neem aan dat je over de 'verre' toekomst praat.
Goedkope snelle geheugen is er neit.

En dan nog. Wat als er een systeem uitvalt?
Als je alles in het vluchtig geheugen plaatst dan ben je alles kwijt.
Je moet het gewoon wel naar de hd weg schrijven.

>
>>Ik neem dat je bedoelt dat je objecten die je vaak gebruikt laat cachen.
>
>
> Als ik dat zou bedoelen dan zou ik dat zeggen :-)
>
>
>>Dat klopt wel maar dat cachen dat hoef jezelf niet te doen dat doet het OS.
>
>
> Die conclusie klopt niet. Caching vindt plaats op verschillende niveaus,
> om goede redenen. Het feit dat een lager niveau cachet wil niet zeggen dat
> je het op hogere niveaus kunt laten. Dat is namelijk minder efficiënt, en
> efficiëntie is het doel van caching.
>

Ok je kunt objecten zelf 'cachen'. Dus gewoon in het geugen laden en niet telkens
overnieuw instantieren.... maar met bijvoorbeeld java dan weet je nog niet of het nou echt wel
sneller is. Teveel zelf cachen -> memmory loopt vol --> ramdisk wordt gebruikt via virtual memory.

>
>>Weet je wat cool is, ze zijn bezig op o.a. UniversiteitTwente bezig met een
>>razendsnelle xml database, deze database moet ondersteuning gaan beiden voor
>>ZQuery. XML-Databases zijn volgens mij de toekomst.
>
>
> Het is een interessante ontwikkeling. Want de huidige driedeling in de
> dominante modellen (1. XML = hiërarchisch voor uitwisseling 2.
> objectgeoriënteerd in geheugen 3. relationeel in de database) is zo krom
> als een hoepel.
>
>
>>Hmm het heen en weer converteren is nog steeds nodig, van Hard-Disc
>>informatie naar software-objecten
>
>
> Dat duurt natuurlijk niet lang meer. Hard-disk is een archaïsch concept.
> In de tijd dat het magnetisch spoor onder de kop een rondje draait heeft
> een hedendaagse webserver zo'n 96.000.000 CPU cycles staan wachten, om na
> de eerste de beste dereferentie van een pointer in het lang verwachtte
> disk block direct weer geïnterumpeerd te worden om minstens nog eens
> 96.000.000 cycles te wachten. Hard disks worden vervangen door solid
> state.
>

Dat klopt.. maar..
huidige computer-systemen zijn multitasking/timesharing systemen.
Als het ene process met i/o bezig is mag het andere process even de processor gebruiken.
Dus uiteindelijk wordt de processor toch veel gebruikt.
Nu heb je gelijk dat het voor 1 process voordelig zou zijn als het geheugen net zo snel
als de processor zou zijn.
Dit is helaas nu nog niet het geval, daarom is er hardware caching ingevoerd.

Tjerk Wolterink:
>Ok het kan alleen als je genoeg geheugen hebt, maar
>meestal wil je software schrijven die *gedeeltelijk* anafhankelijk is
>van de hoeveelheid geheugen die aanwezig is.
>Het hele idee van virtuel memory is daarop gebaseerd.

Dat is inderdaad ook een goed idee.

>En dan nog. Wat als er een systeem uitvalt?
>Als je alles in het vluchtig geheugen plaatst dan ben je alles kwijt.
>Je moet het gewoon wel naar de hd weg schrijven.

Ik vraag me af of RAM zelfs niet al betrouwbaarder is dan hard disk, maar
ik voel met je mee :-)

De opvolger van de harddisk zal natuurlijk een min of meer permanent
geheugen zijn. Hoewel je ook aan redundant opslaan in meerdere
onbetrouwbare geheugens via het netwerk kunt denken.

>huidige computer-systemen zijn multitasking/timesharing systemen.

Maar zijn huidige applicaties dat ook? De mijne niet of nauwelijks.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Tjerk Wolterink <tjerk@wolterinkwebdesign.com> wrote:
> Ok het kan alleen als je genoeg geheugen hebt, maar
> meestal wil je software schrijven die *gedeeltelijk* anafhankelijk is
> van de hoeveelheid geheugen die aanwezig is.
> Het hele idee van virtuel memory is daarop gebaseerd.

Nee hoor. Soms moet je het, maar ik wil liever helemaal
geen rekening houden met de hoeveelheid beschikbaar
geheugen. Dat maakt het programmeren alleen maar nodeloos
ingewikkeld.

Stephan