[alg] locking en databases artikel

[Alarmnummer]

Ik ben bezig met een blog/artikel over locking en databases. Ik ben er bijna mee klaar, maar de laatste loodjes wegen het zwaarst. Ik hoop het deze week (echt) af te kunnen ronden, maar zou graag nog wat feedback van jullie krijgen over het artikel.

Het artikel gaat dus over pessimistic locking, technieken die db gebruiken om te locken, hoe ze om gaan met performance problemen gerelateerd aan locking en wat voor andere problemen er door locking kunnen ontstaan (deadlocks bijvoorbeeld). Verder staat er een heel stuk in over isolation levels en hoe die locking aansturen. Het is dus echt bedoelt voor mensen die geinteresseerd zijn in concurrency control en hoe databases hier mee om gaan.

Verder is het artitikel naar html geexporteerd, dus er de html is een zootje. Uiteindelijk ga ik dit document nog opmaken zoals het hoort. Dus daar aub ook niet op letten.

De url naar het artikel is:
http://www.phonetech.nl/alarmnummer/draft.htm
en thanks Phonetech voor het hosten.

[Mithrandir]

Redelijk interessante post, maar ik zou je aanraden om de tekst nog een keer te lezen. Er zitten aardig wat slecht lopende zinnen enzo in, die je zeker eruit zou halen als je 't nog een keer aandachtig doorleest.

Inhoudelijk ben ik niets vreemds tegengekomen (alhoewel ik in no means een databaseexpert ben), maar hier wel een paar taalverbeteringetjes:

I like to reason about it and I think I have a more than average understanding of the subject. It is feared because it is so complex: you have to deal with a whole new dimension of problems.

Beetje vaag waarnaar je verwijst op deze plaats.

When code is executed by a single thread, you know exactly the order of the instructions being executed, but with multithreaded code, every instruction from one thread, can be executed parallel next to any instruction of another thread.

De bold komma hoort hier niet

An important concept to understand, while reasoning about performance related issues, is lockcontention.

Is "While reasoning about performance realted issues, is lockcontention an important concept to understand." niet beter te lezen?

Don't expect this to be a complete summary of techniques because this isn't.

Dit soort zinnen zijn erg grof om te lezen... is iets als 'This is by no means a complete summary of techniques, but here are some possibilities.' misschien beter?

Verder een interessant stuk, maar ik moet weg naar college. Zal vanmiddag nog even wat meer lezen.

[Alarmnummer]

Schrijven is niet mijn sterkste punt (afgezien van Java code ) Het gaat me voornamelijk om de inhoud van het stuk.

[ Voor 4% gewijzigd door Alarmnummer op 06-03-2006 12:17 ]

[megamuch]

Je voorbeeld van lost update is niet helemaal goed gekozen denk ik, omdat je update query wat ongelukkig gekozen is.

ipv

code:

update Account (amount) values (5) where id=1;

zou ik

code:

update Account set amount= amount + 5 where id=1;

doen.

Nou ben ik by no means een SQL expert (verre van zelfs), maar dit zou je lost update probleem volgens mij wel voorkomen.

(Maar misschien praat ik wel keihard peop @ the moment).

[Verwijderd]

Ik keek dus gelijk naar wat je over multiversioning te melden had. Eigenlijk erg weinig aangezien het toch grote voordelen heeft ten opzichte van het traditionele row locking. Ik zou daar in ieder geval wat meer werk van maken dan wat er nu staat. Zo mis je de oervader van de multiversioning engines (interbase) en is de uitleg over hoe het werkt wel erg summier (als het al niet compleet incorrect is, erg duidelijk wordt het niet wat je bedoeld. Meerdere rows? Meerdere versies van een Row klinkt al een stuk logischer)

Maar er bestaat veel documentatie over hoe de interbase/firebird engine werkt en de verschillen met row locking. Ook heeft IBM een artikel gepubliseerd over wat er volgens hen allemaal mis is met de multiversioning engine van Oracle. En dat is best veel Maar gegeven het Nederlands in dat stuk denk ik dat je daar sowieso nog mee bezig bent.

O, ja je voorbeeld aan het begin. Ik vind het altijd een stuk duidelijker als dat een beetje grafisch opgeleukt wordt. Elk database boek heeft wel zo'n voorbeeld en door grafisch te laten zien hoe de volgorde precies in elkaar zit komt dat duidelijker over. Het voorbeeld klopt trouwens ook niet

[code]
time5,trans1:update Account (amount) values (5) where id=1;

time6,trans1:commit

time7,trans2:update Person (amount) values (10) where id=1;
[/quote]
Ik neem aan dat time7,trans2:update Account (amount) values (10) where id-1; bedoeld wordt

Edit: Hum, ik kijk net naar je voorbeeld van een Phantom read en daar klopt eigenlijk ook weinig van.
De 1e transactie is nog niet gecommit als je hem uitleest. Gegeven dat die nog niet gecommit is, is het resultaat van de select dus 0. Ik begrijp wat je wilt uitleggen maar je uitleg breekt het principe van transacties. Dat is waarschijnlijk ook weer niet de bedoeling. Ook bij een Dirty Read speelt dit "probleem" In mijn ogen zul je dus moeten in gaan op transacties en wat de gevolgen van de verschillende isolation levels zijn voor verschillende scenario's.

Zo zijn bij je dirty read en phantom read voorbeelden de waarde die de select teruggeeft afhankelijk van het gekozen isolation level. Nu lijkt het erop alsof je een standaard transactie gebruikt en kloppen je voorbeelden simpelweg niet. Je zult de lezer IMHO dus moeten leren hoe transacties werken voordat je deze voorbeelden kan geven.

[ Voor 26% gewijzigd door Verwijderd op 06-03-2006 12:58 ]

[Alarmnummer]

Verwijderd schreef op maandag 06 maart 2006 @ 12:40:
Ik keek dus gelijk naar wat je over multiversioning te melden had. Eigenlijk erg weinig aangezien het toch grote voordelen heeft ten opzichte van het traditionele row locking. Ik zou daar in ieder geval wat meer werk van maken dan wat er nu staat.

Multiversioning is zeker nog niet klaar. Er staat nog een heel stuk nederlandse tekst in, dus die gaat zeker nog uitgediept worden.

Zo mis je de oervader van de multiversioning engines (interbase) en is de uitleg over hoe het werkt wel erg summier (als het al niet compleet incorrect is, erg duidelijk wordt het niet wat je bedoeld. Meerdere rows? Meerdere versies van een Row klinkt al een stuk logischer)

Yep.. maar dat komt er dus nog aan.

Maar er bestaat veel documentatie over hoe de interbase/firebird engine werkt en de verschillen met row locking. Ook heeft IBM een artikel gepubliseerd over wat er volgens hen allemaal mis is met de multiversioning engine van Oracle. En dat is best veel Maar gegeven het Nederlands in dat stuk denk ik dat je daar sowieso nog mee bezig bent.

Ik heb het Oracle boek tot mijn beschikking (expert to expert), high performance MySql van O'Reilly (staat ook heel stuk in over multiversioning) en boek van de microsoft site waarin ook het een en ander staat over multiversioning. Dus het komt er nog aan.

O, ja je voorbeeld aan het begin. Ik vind het altijd een stuk duidelijker als dat een beetje grafisch opgeleukt wordt. Elk database boek heeft wel zo'n voorbeeld en door grafisch te laten zien hoe de volgorde precies in elkaar zit komt dat duidelijker over. Het voorbeeld klopt trouwens ook niet

[code]
time5,trans1:update Account (amount) values (5) where id=1;

time6,trans1:commit

time7,trans2:update Person (amount) values (10) where id=1;

Ik neem aan dat time7,trans2:update Account (amount) values (10) where id-1; bedoeld wordt
[/quote]
Oeps

Edit: Hum, ik kijk net naar je voorbeeld van een Phantom read en daar klopt eigenlijk ook weinig van.
De 1e transactie is nog niet gecommit als je hem uitleest. Gegeven dat die nog niet gecommit is, is het resultaat van de select dus 0. Ik begrijp wat je wilt uitleggen maar je uitleg breekt het principe van transacties. Dat is waarschijnlijk ook weer niet de bedoeling.

Ik zal dit voorbeeld nog even goed onder de loep nemen. Vooral mbt het locking gedrag van de transactie (het is eigelijk geen volledige transactie, maar alleen een 'start/commit/rollback' markering (dus zonder enige vorm van isolatie: die wil ik er dus stap voor stap aan toe gaan voegen). Maar het is een goed punt.. ik zal even kijken hoe ik het beste dit er aan toe kan voegen.

[edit]
Als je een lagere isolation level gebruikt dan serialized, dan kan dit probleem zich bij iedere transactie voordoen. Het is dus zeker geen onmogelijke zaak als je transacties gebruikt. Alleen SERIALIZED geeft de enige echte 'klassieke' vorm van isolatie: totale isolatie.

Ook bij een Dirty Read speelt dit "probleem" In mijn ogen zul je dus moeten in gaan op transacties en wat de gevolgen van de verschillende isolation levels zijn voor verschillende scenario's.

Dat is dus de definitie van een dirty read: het uitlezen van rows die nog niet zijn gecommit. En verder kom ik bij de isolation levels terug op de voorbeelden en leg daar uit welke fouten je dus kunt krijgen.

Zo zijn bij je dirty read en phantom read voorbeelden de waarde die de select teruggeeft afhankelijk van het gekozen isolation level. Nu lijkt het erop alsof je een standaard transactie gebruikt en kloppen je voorbeelden simpelweg niet. Je zult de lezer IMHO dus moeten leren hoe transacties werken voordat je deze voorbeelden kan geven.

Het probleem is dat ik niet meteen bij de isolatie nivo`s wil uitkomen. Eerst wil ik de basis isolatie problemen uitleggen en oplossen en vervolgens wil ik ingaan hoe dit met een isolation level geautomatiseerd kan worden. Ik zal nog even goed uitleggen wat het locking gedrag van transactie uit de voorbeelden is. Het locking gedrag is dus anders dan een 'echte' transactie: ik wil hiermee alleen de grens van de transactie aangeven (start en rollback/commit). Maar ik kan me voorstellen dat dit wat onduidelijkheid schept.

[ Voor 26% gewijzigd door Alarmnummer op 06-03-2006 13:56 ]

[Alarmnummer]

megamuch schreef op maandag 06 maart 2006 @ 12:30:
Je voorbeeld van lost update is niet helemaal goed gekozen denk ik, omdat je update query wat ongelukkig gekozen is.

ipv

code:

update Account (amount) values (5) where id=1;

zou ik

code:

update Account set amount= amount + 5 where id=1;

doen.

Nou ben ik by no means een SQL expert (verre van zelfs), maar dit zou je lost update probleem volgens mij wel voorkomen.

(Maar misschien praat ik wel keihard peop @ the moment).

Als je van databases gebruik maakt binnen een applicatie, krijg je meestal dit soort dingen:

code:

Account account = accountDao.findById(1);//de select
... eventueel nog allerlei andere acties
account.setAmount(account.getAmount()+5);
... eventueel nog allerlei andere acties
accountDao.save(account);//de update

Als je in dit geval Account 1 niet lockt bij de findById, dan loop je de kans op een lost update.

[ Voor 5% gewijzigd door Alarmnummer op 06-03-2006 13:28 ]

[Verwijderd]

Alarmnummer schreef op maandag 06 maart 2006 @ 13:08:

[..]

Het probleem is dat ik niet meteen bij de isolatie nivo`s wil uitkomen. Eerst wil ik de basis isolatie problemen uitleggen en oplossen en vervolgens wil ik ingaan hoe dit met een isolation level geautomatiseerd kan worden. Ik zal nog even goed uitleggen wat het locking gedrag van transactie uit de voorbeelden is. Het locking gedrag is dus anders dan een 'echte' transactie: ik wil hiermee alleen de grens van de transactie aangeven (start en rollback/commit). Maar ik kan me voorstellen dat dit wat onduidelijkheid schept.

Dat kan ik goed begrijpen. Maar als een lezer al wat basiskennis heeft van wat een transactie is komt dit IMHO redelijk onlogisch over.

Maar dat is mijn $0.02

[JKVA]

Prima verhaal. Ben benieuwd naar het uiteindelijke resultaat.

[whoami]

P&W -> SE&A

[D4Skunk]

Kan je me een voorbeeld geven van een applicatie die veel concurrency problemen heeft ?

offtopic:
Ik zit al jaren professioneel met Oracle bezig, maar ik kan me toch nog steeds geen enkele concrete 'normale' app voorstellen die concurrency issues heeft ?

Meestal wordt er imho :
(a) al dan niet dmv versioning bij alle belangrijke data een log bijgehouden (denk maar aan loonberekening etc).
(b) met een soort van staging en productieomgeving gewerkt, waardoor je al sneller concurrency issues vermijdt. Vanop de staging wordt dan alles 1 per 1 via een job queue gesubmit, en al je concurrency issues zijn verdwenen...
(c) intensievere apps die data gaan locken worden meestal - wanneer je alles goed plant - gedraaid op het moment dat er zo min mogelijk/geen sessies zijn, omdat de gebruikers anders toch gelocked worden en niks kunnen presteren.
(d) Volatiele data (zoals aantal artikels in voorraad etc) kan je imho maar beter iedere keer uit de db ophalen (evt. dmv een materialized view of zo, mochten er performantieissues zijn )
(e) In veel geval duiden concurrency issues op een verkeerde aanpak, en hoort er eigenlijk een logische scheiding te zijn tussen de onderlinge transacties; maw ze mogen niet elkaars data gaan gebruiken....

Voor zover ik het kan inschatten, zijn er niet zoveel apps die echt concurrency issues zouden mogen geven.... Als dit toch zo is, had ik hier graag eens een voorbeeld van gezien...
Meestal wordt bij een concurrency gewoon de hele transactie teruggerold, en moet de gebruiker opnieuw beginnen. Kritieke zaken werken bijna altijd met een queue om dit probleem te vermijden...

[ Voor 36% gewijzigd door D4Skunk op 06-03-2006 21:22 . Reden: de inspiratie blijft maar komen :p ]

[Alarmnummer]

D4Skunk schreef op maandag 06 maart 2006 @ 21:09:
Kan je me een voorbeeld geven van een applicatie die veel concurrency problemen heeft ?

offtopic:
Ik zit al jaren professioneel met Oracle bezig, maar ik kan me toch nog steeds geen enkele concrete 'normale' app voorstellen die concurrency issues heeft ?

In principe heeft iedere applicatie waarbij er concurrent users zijn, te maken met concurrency issues. In de meeste gevallen heb je als developer zijnde daar niet zo veel mee te maken. Je applicatieserver/servletcontainer zorgt voor de threads en je (database) transacties zorgen (mbv je isolation level) voor de juiste isolatie. Het gaat mij erom wat er achter de schermen gebeurt.

Meestal wordt er imho :
(a) al dan niet dmv versioning bij alle belangrijke data een log bijgehouden (denk maar aan loonberekening etc).

Versioning (optimistic locking) is een techniek die veel gebruik word, maar het is niet altijd toepasbaar. In PEAA staat het een en ander of optimistic vs pessimistic locking, anders moet je dat eens door bladeren.

(b) met een soort van staging en productieomgeving gewerkt, waardoor je al sneller concurrency issues vermijdt. Vanop de staging wordt dan alles 1 per 1 via een job queue gesubmit, en al je concurrency issues zijn verdwenen...

Dit snap ik niet.

(c) intensievere apps die data gaan locken worden meestal - wanneer je alles goed plant - gedraaid op het moment dat er zo min mogelijk/geen sessies zijn, omdat de gebruikers anders toch gelocked worden en niks kunnen presteren.

Dat ligt dus aan het systeem. Er zijn genoeg webapplicaties te bedenken waarbij locking noodzakelijk is (bv omdat er gewoon concurrent users zijn).

(e) In veel geval duiden concurrency issues op een verkeerde aanpak, en hoort er eigenlijk een logische scheiding te zijn tussen de onderlinge transacties; maw ze mogen niet elkaars data gaan gebruiken....

Dat ligt dus aan de applicatie. Waar het mij om gaat is dat zo gauw je er mee te maken krijgt, je weet wat er achter de schermen gebeurt, wat de consequenties zijn van bepaalde keuzes. En je kunt gewoon niet garanderen dat je mbv applicatie logica geen concurrency issues over shared data kunt krijgen.

Voor zover ik het kan inschatten, zijn er niet zoveel apps die echt concurrency issues zouden mogen geven.... Als dit toch zo is, had ik hier graag eens een voorbeeld van gezien...

Goed punt. Maar wat dacht je van het account voorbeeld? Dat is een goed praktisch voorbeeld waar je de gevolgen van een te lage isolatie kunt zien (je raakt namelijk informatie kwijt).

Meestal wordt bij een concurrency gewoon de hele transactie teruggerold, en moet de gebruiker opnieuw beginnen. Kritieke zaken werken bijna altijd met een queue om dit probleem te vermijden...

Ik mag niet hopen dat transacties worden terug gerold bij concurrency En niet in alle gevallen is het mogelijk om met een 'queue' te werken. Als je echt volledige isolatie wilt, kan je alijd serialized isolation level gebruiken (geeft dezelfde isolatie als executie door een enkele thread). En verder krijg je met een queue een extreem slechte response time (dito als bij serialized) en is voor veel OLTP systemen gewoon onacceptabel. Concurrency is dus iets waar je gegarandeerd mee te maken krijgt als je met databases gaat werken icm webapplicaties.

[ Voor 11% gewijzigd door Alarmnummer op 07-03-2006 08:53 ]

[Alarmnummer]

Verwijderd schreef op maandag 06 maart 2006 @ 20:24:
[...]


Dat kan ik goed begrijpen. Maar als een lezer al wat basiskennis heeft van wat een transactie is komt dit IMHO redelijk onlogisch over.

Maar dat is mijn $0.02

Ik heb het al aangepast. Ik heb de opzet van de read inconsistencies iets anders opgezet, uitgelegd dat je bij de transactie dus geen enkele vorm van isolatie krijgt, en uitgelegd hoe je mbv locking wel een specifieke read inconsistency kunt oplossen. Ik zal ff kijken of ik vandaag het artikel kan updaten.

Het voorbeeld van de lost update was trouwens idd niet correct. Ik heb dat ook gefixt.

[D4Skunk]

Interessant onderwerp !!

Alarmnummer schreef op dinsdag 07 maart 2006 @ 08:38:
[...]

[...]

[...]

Dit snap ik niet.

Een staging omgeving wordt in redelijk wat (grotere) productie-omgevingen gebruikt. Beschouw het al een transactie waarbij de gegevens in een voorlopige database worden opgeslagen, en waarvan de gegevens bij commit naar de productie-database gaan.

[...]

Dat ligt dus aan het systeem. Er zijn genoeg webapplicaties te bedenken waarbij locking noodzakelijk is (bv omdat er gewoon concurrent users zijn).

Een concreet voorbeeld aub ?

[...]

Dat ligt dus aan de applicatie. Waar het mij om gaat is dat zo gauw je er mee te maken krijgt, je weet wat er achter de schermen gebeurt, wat de consequenties zijn van bepaalde keuzes. En je kunt gewoon niet garanderen dat je mbv applicatie logica geen concurrency issues over shared data kunt krijgen.

dito hierboven

[...]

Goed punt. Maar wat dacht je van het account voorbeeld? Dat is een goed praktisch voorbeeld waar je de gevolgen van een te lage isolatie kunt zien (je raakt namelijk informatie kwijt).

Dit is imho een duidelijk voorbeeld van hoe ik het niet zou aanpakken. Voor amount zou ik en materialized view gebuiken die de transacties samentelt.

[...]

Ik mag niet hopen dat transacties worden terug gerold bij concurrency En niet in alle gevallen is het mogelijk om met een 'queue' te werken. Als je echt volledige isolatie wilt, kan je alijd serialized isolation level gebruiken (geeft dezelfde isolatie als executie door een enkele thread). En verder krijg je met een queue een extreem slechte response time (dito als bij serialized) en is voor veel OLTP systemen gewoon onacceptabel. Concurrency is dus iets waar je gegarandeerd mee te maken krijgt als je met databases gaat werken icm webapplicaties.

interessant...

[Alarmnummer]

D4Skunk schreef op dinsdag 07 maart 2006 @ 10:54:
Interessant onderwerp !!
[...]
Een staging omgeving wordt in redelijk wat (grotere) productie-omgevingen gebruikt. Beschouw het al een transactie waarbij de gegevens in een voorlopige database worden opgeslagen, en waarvan de gegevens bij commit naar de productie-database gaan.

Staging omgevingen ken ik alleen vanuit het testen. De staging omgeving is de laatste omgeving op getest gaat worden voordat het naar de productie omgeving wordt verplaatst.

Een concreet voorbeeld aub ?

Ik zal even kijken of ik voor alle inconsistensies praktische voorbeelden kan bedenken.

Dit is imho een duidelijk voorbeeld van hoe ik het niet zou aanpakken. Voor amount zou ik en materialized view gebuiken die de transacties samentelt.

Ik ken het concept materialized view niet. Zou je dit eens kunnen toelichten?
[edit]
Ik zie dat het een Oracle specifiek concept is:
http://en.wikipedia.org/wiki/Materialized_view

Ik weet niet hoe materialized views om gaan met concurrency problematiek. Maar leuk om te zien dat er nog meer wegen naar Rome zijn.

[ Voor 13% gewijzigd door Alarmnummer op 07-03-2006 11:57 ]

[PrisonerOfPain]

Wellicht dat je hier nog wat aan hebt? Het behandeld grofweg dezelfde materie op dezelfde manier, heb ik de indruk.

[MSalters]

Alarmnummer schreef op dinsdag 07 maart 2006 @ 11:41:
Staging omgevingen ken ik alleen vanuit het testen. De staging omgeving is de laatste omgeving op getest gaat worden voordat het naar de productie omgeving wordt verplaatst.

Ik weet niet extreem veel van databases, maar ik ken de term ook wel in deze context.
Grofweg gezegd: als je een tabel met een miljoen entries hebt, dan kan de DB engine daar een schaduwtabel voor zetten met circa 100 entries. Elke modificatie gaat naar die schaduwtabel, en pas als die vol is wordt die in 1 keer geflushd naar de daadwerkelijke tabel. Elke read uit de daadwerkelijke tabel moet natuurlijk nog wel worden "gepatched" met de uitstaande wijzigingen in de schaduwtabel, maar dat ding is zo klein dat die in RAM past.

Ik zou moeten nadenken over de exacte consequenties voor locking, maar hte lijkt me duidelijk dat je in 99% van de gevallen toekunt met alleen een read-lock op de echte tabel, terwijl de write-lock op de kleine tabel maar kortstondig hoeft te zijn.

[zeroxcool]

Leuk onderwerp Alarmnummer. Op de Fontys Hogescholen in Eindhoven (Hogere Informatica) hebben ze een compleet vak (GB4+) aan database concurrency besteed. Als je wilt, kan ik het dictaat ter leen opsturen. Zo'n beetje ieder onderwerp wat je aansnijdt, wordt behandeld.

[Verwijderd]

D4Skunk schreef op dinsdag 07 maart 2006 @ 10:54:
Interessant onderwerp !!


[...]


Een staging omgeving wordt in redelijk wat (grotere) productie-omgevingen gebruikt. Beschouw het al een transactie waarbij de gegevens in een voorlopige database worden opgeslagen, en waarvan de gegevens bij commit naar de productie-database gaan.

Dit lost principieel je locking probleem niet op. Als er twee gebruikers in dezelfde voorlopige database werken, kun je nog altijd (in je voorlopige database) locking issues krijgen. Werken ze in verschillende databases, krijg je locking problemen (inconsequente data) wanneer je de beide databases gaat committen.

[...]


Een concreet voorbeeld aub ?

Dit meen je toch niet? Databases 101. Bel eens naar amazon.com zou ik zeggen. Elke applicatie waarin 2 of meer concurrent users werken moet rekening houden met locking Een rollback wanneer de data door een andere user gewijzigd is, is één van de potentiele oplossingen. De applicatie merkt dat de data is aangepast en de gebruiker mag opnieuw beginnen. Als dit gebeurd is er dus al een concurrency probleem. De transactie kan namelijk niet voltooid worden.

[...]

dito hierboven

[...]


Dit is imho een duidelijk voorbeeld van hoe ik het niet zou aanpakken. Voor amount zou ik en materialized view gebuiken die de transacties samentelt.

Dat maakt feitelijk niet uit. Die view werkt op een (tijdelijke) tabel maar in dezelfde transactiescope als een losse update. Zodra er twee concurrent transacties zijn die de data wijzigen kan één van beide niet correct worden uitgevoerd. Het is namelijk niet zo dat elke gebruiker een eigen tabel krijgt. Daarnaast is het gebruik van materialized views in veel OLTP situaties "not done". Je gegevens worden hierdoor namelijk onbetrouwbaar. Stel je veranderd een prijs via een materialized view. Die update komt dan niet direct in je basistabel. Afhankelijk van hoe je de prijs opvraagt krijg je de oude of nieuwe prijs. Handig als je 1.000.000 stuks wil verkopen. Bij data warehousing (waar jij mij mee bezig lijkt) is dat een veel kleiner probleem.

[...]


interessant...

[zeroxcool]

D4Skunk schreef op dinsdag 07 maart 2006 @ 10:54:
Interessant onderwerp !!
[...]
Een staging omgeving wordt in redelijk wat (grotere) productie-omgevingen gebruikt. Beschouw het al een transactie waarbij de gegevens in een voorlopige database worden opgeslagen, en waarvan de gegevens bij commit naar de productie-database gaan.

Dan even een ander punt uit het ACID-model. Hoe wordt er rekening gegouden met consistentie? Wat nou als tijdens een commit naar je solid memory (harde schijf) je systeem een stroomuitval kent?

[D4Skunk]

Verwijderd schreef op donderdag 09 maart 2006 @ 08:42:
[...]


Dit lost principieel je locking probleem niet op. Als er twee gebruikers in dezelfde voorlopige database werken, kun je nog altijd (in je voorlopige database) locking issues krijgen. Werken ze in verschillende databases, krijg je locking problemen (inconsequente data) wanneer je de beide databases gaat committen.

Je staging omgeving bevat dan ook niet de werkelijke data, maar de commando's om de productie data aan te passen, maw de stappen die nodig zijn om je transactie uit te voeren.

[...]

Dit meen je toch niet? Databases 101. Bel eens naar amazon.com zou ik zeggen. Elke applicatie waarin 2 of meer concurrent users werken moet rekening houden met locking Een rollback wanneer de data door een andere user gewijzigd is, is één van de potentiele oplossingen. De applicatie merkt dat de data is aangepast en de gebruiker mag opnieuw beginnen. Als dit gebeurd is er dus al een concurrency probleem. De transactie kan namelijk niet voltooid worden.

In theorie komt dit veel voor, maar in praktijk zijn er meestal niet echt lock issues, omdat de applicatie hierop voorzien is.
Ok, een voorbeeld : bestellingen bij "amazon.com".
Het enige dat ik me zou kunnen voorstellen, is dat bv de prijs van een artikel verandert, terwijl er een bestelling geplaatst wordt. Oplossing : voorzie in de tabel artikel een veld "GeldigTot", dat de datum bevat tot wanneer dit record geldig is, en maak een nieuw record aan voor de gewijzigde versie. Zo kan je ook effectief de transacties in het verleden verifiëren, en blijft je logische structuur consistent. Als je hiervan geen historiek bijhoudt, dan is het imho ook niet echt nodig om de gegevens te locken.
De truc is net om locks te vermijden, door in je app historieken in te bouwen.

[...]


Dat maakt feitelijk niet uit. Die view werkt op een (tijdelijke) tabel maar in dezelfde transactiescope als een losse update. Zodra er twee concurrent transacties zijn die de data wijzigen kan één van beide niet correct worden uitgevoerd. Het is namelijk niet zo dat elke gebruiker een eigen tabel krijgt. Daarnaast is het gebruik van materialized views in veel OLTP situaties "not done". Je gegevens worden hierdoor namelijk onbetrouwbaar. Stel je veranderd een prijs via een materialized view. Die update komt dan niet direct in je basistabel. Afhankelijk van hoe je de prijs opvraagt krijg je de oude of nieuwe prijs. Handig als je 1.000.000 stuks wil verkopen. Bij data warehousing (waar jij mij mee bezig lijkt) is dat een veel kleiner probleem.

[...]

Zie voorbeeld hierboven. Die prijsverandering is selechts van toepassing op het moment dat die gecommit wordt. Alle transacties die ervoor opgestart zijn moeten imho met de oude prijs(-record) werken

[ Voor 6% gewijzigd door D4Skunk op 09-03-2006 09:39 . Reden: een paar kleine aanpassingen ]

[D4Skunk]

ZeRoXcOoL schreef op donderdag 09 maart 2006 @ 08:52:
[...]


Dan even een ander punt uit het ACID-model. Hoe wordt er rekening gegouden met consistentie? Wat nou als tijdens een commit naar je solid memory (harde schijf) je systeem een stroomuitval kent?

Hmmz, dit is bij geen enkele 'echte' db een probleem, gezien je altijd op je transaction logs/archivelogs kan terugvallen... Misschien is het interessant voor jou om eens te bestuderen hoe een database 'under the hood' werkt...

[zeroxcool]

D4Skunk schreef op donderdag 09 maart 2006 @ 09:29:
[...]

Hmmz, dit is bij geen enkele 'echte' db een probleem, gezien je altijd op je transaction logs/archivelogs kan terugvallen... Misschien is het interessant voor jou om eens te bestuderen hoe een database 'under the hood' werkt...

Ah ok, die staging database heeft dus zijn eigen binlog engine zeg maar? Of bedoel je de transaction log van de onderhuidse 'echte' database? Want dan zit je toch nog met de gegevens in je vluchtig geheugen, of ben ik gewoon verkeerd aan het denken?

[D4Skunk]

ZeRoXcOoL schreef op donderdag 09 maart 2006 @ 10:37:
[...]

Ah ok, die staging database heeft dus zijn eigen binlog engine zeg maar? Of bedoel je de transaction log van de onderhuidse 'echte' database? Want dan zit je toch nog met de gegevens in je vluchtig geheugen, of ben ik gewoon verkeerd aan het denken?

Normaliter worden alle transacties die je doet weggeschreven in een transaction log.

Gezien de staging database ook een database is, heeft die dus dezelfde opzet...

[MSalters]

Nee, niet helemaal: omdat alle changes door je staging DB heen gaan heb je alleen nog een log nodig voor je staging DB. De slag van staging DB naar echte DB is natuurlijk zo opgezet dat de rows pas uit de staging DB gaan als ze gecommit zijn in de echte, en dan heb je geen log meer nodig.

(En eigenlijk zijn logs ontzettend primitieve staging DBs voor het geval de spanning uitvalt)

[Verwijderd]

D4Skunk schreef op donderdag 09 maart 2006 @ 09:25:
[...]

Je staging omgeving bevat dan ook niet de werkelijke data, maar de commando's om de productie data aan te passen, maw de stappen die nodig zijn om je transactie uit te voeren.

Je kan je staging area op tig manieren inrichten. De hierboven beschreven methode serialiseert de transacties (1 staging area doet alle updates) en kost nogal wat performance. Leuk met weinig gebruikers maar niet echt geschikt voor taken met duizenden verschillende gebruikers. Ook kun je hierdoor in de problemen komen met transacties die achter elkaar binnen komen. Als de eerste faalt en de tweede is afhankelijk van de eerste kan de tweede ook falen. Feitelijk weet je dus pas zeker of je tweede commando geldig is als het eerste gecommit is in de productie data. De tweede transactie (en de gebruiker) moet dus wachten op de eerste.

Voorbeeld. Neem een user tabel met een unieke key op het sofinummer.

T1 Begin
T1 insert USER (ID, sofinummer, naam)
T1 select @@Identity
T1 Commit

T2 Begin
T2 Update USER Set Naam = "willekeurige naam" where ID is HetID.
T2 Commit

Goed, T1 voegt een gebruiker toe en retourneert het ID van die gebruiker.
Daarna update T2 de naam van de gebruiker. Niets mis mee en het zou moeten werken.

Helaas zit er in de basisdataset al een user met hetzelfde sofinummer. Transactie 1 wordt dus teruggedraaid bij het verplaatsen naar productie. Echter de gebruiker krijgt dit niet te zien bij het invoeren van de User. De invoer gaat immers naar de staging area en die bevat niet de werkelijke data. Maar Transactie 2 is daar wel van afhankelijk! Dit voorbeeld geeft aan dat je dus een hoop zaken die normaal de database controleert zelf zult moeten doen. Nóg erger wordt het als beide users zich in de staging area bevinden (bv werknemer voert per ongelijk twee keer dezelfde user in, twee werknemers doen hetzelfde enz enz.) Dan zijn controles op de productie data onmogelijk, want beide nieuwe gebruikers ontbreken in eerste instantie in die data. Ook in de staging area kun je lastig zien of de gebruiker bestaat. je weet namelijk slechts na controle van alle records in je stagingtabellen wat de huidige waarde van de gegevens is. Misschien was het sofinummer wel al verbetert.

Op deze manier zit je dus een hoop werk wat de databaseserver voor je kan doen handmatig over te doen. Lijkt me niet handig, noch efficient.

Je kan vaak om dit soort probleem heen werken. Echter elke bekende methode heeft nadelen. Er is geen standaard methode die Oracle en IBM eventjes in hun engine kunnen implementeren om voorgoed van het locking probleem af te zijn.

Als ontwikkelaar dien je dus zélf voor een oplossing te zorgen. Serialiseren is daar één van (en is feitelijk wat jou "staging" methode doet) maar dat gaat ten kosten van de concurrency en performance. Leuk voor Data Warehousing maar compleet onacceptabel bij OLTP. Juist doordat dit geen simpele problemen zijn, dien je de fundamenten mbt concurrency te begrijpen voordat je een goed multi user systeem kan ontwerpen.

[...]


In theorie komt dit veel voor, maar in praktijk zijn er meestal niet echt lock issues, omdat de applicatie hierop voorzien is.
Ok, een voorbeeld : bestellingen bij "amazon.com".
Het enige dat ik me zou kunnen voorstellen, is dat bv de prijs van een artikel verandert, terwijl er een bestelling geplaatst wordt. Oplossing : voorzie in de tabel artikel een veld "GeldigTot", dat de datum bevat tot wanneer dit record geldig is, en maak een nieuw record aan voor de gewijzigde versie. Zo kan je ook effectief de transacties in het verleden verifiëren, en blijft je logische structuur consistent. Als je hiervan geen historiek bijhoudt, dan is het imho ook niet echt nodig om de gegevens te locken.
De truc is net om locks te vermijden, door in je app historieken in te bouwen.

Ook dit is weer een voorbeeld van om het probleem heen werken. Bij de ontwikkeling los je die problemen zoveel mogelijk op. Daar zijn dus vele manieren voor. Je noemt er ondertussen zelf al een hoop op (transactie terugdraaien, historische tabellen, staging,....) Juist door te begrijpen wat de potentiele problemen zijn en met kennis van de applicatie kun je de oplossing optimaliseren. Misschien is een Dirty Read in een situatie de oplossing. Maar dan moet je wel het verschil kennen tussen een transactie met Dirty Reads enabled en een transactie zonder die functies. Er zijn veel applicaties geschreven waarbij de performance belabberd was omdat er niet goed nagedacht was over de concurrency issues. Alarmnummer probeert deze problemen in een kort(?) document uit te leggen. En dat is zeker niet eenvoudig.


[...]

Zie voorbeeld hierboven. Die prijsverandering is slechts van toepassing op het moment dat die gecommit wordt. Alle transacties die ervoor opgestart zijn moeten imho met de oude prijs(-record) werken

Bedoel je gecommit in de productie data? Of gecommit in je staging data? Want alweer creëer je im mijn ogen meer problemen dan je oplost. De meeste mensen vinden dat een prijsverandering (of elke andere verandering) in een OLTP systeem doorgevoerd moet worden op het moment dat de gebruiker denkt dat die doorgevoerd is. De gebruiker voert een nieuwe prijs in (desnoods met een periode waarin die geldig is) en verwacht dat die wijziging na het opslaan doorgevoerd wordt. Niet dat die doorgevoerd wordt op een later moment als de view gesynchroniseerd wordt. De commit naar de view is vanuit het gebruikersperspectief het moment dat de nieuwe prijs in het systeem staat. Met een materialized view creeër je een periode tussen het invoeren van de gebruiker en het doorvoeren in de basistabel. Alle transacties die in de tussentijd worden opgestart krijgen dus de oude prijs terwijl de gebruiker de nieuwe prijs al heeft ingevoerd. Maar heel raar. De gebruiker krijgt wél de nieuwe prijs te zien als die de prijs nogmaals wil wijzigen (want hij begrijpt er natuurlijk geen bal van.) Tenminste dat hoop ik. Anders ziet de gebruiker zijn weiziging helemaal niet meer terug. Inconsequent en dus onwenselijk. Nu kun je jezelf indekken door in een TO de regel opnemen dat alle veranderingen aan producten pas na (bv) middennacht worden doorgevoerd, maar daar maak je geen vrienden mee.

Een Materialised View creëert data inconsistancy. Wat je in OLTP applicaties niet wilt is data inconsistancy. Als jij deze twee basiseisen kan combineren hoor ik het graag.

[D4Skunk]

Verwijderd schreef op vrijdag 10 maart 2006 @ 04:44:
[...]
... Prachitge uitleg van staging principes met voorbeelden etc ...

Ik denk dat we beiden hetzelfde doel voor ogen hebben, maar dat daarbij onze focus misschien een beetje anders ligt...
Waar ik in mijn initiële post verkeerd gegaan ben, is dat ik het onderwerp van de oplossingen interessanter vond dan de oorzaak van het probleem.

offtopic:
Het voordeel van zo'n staging-omgeving is imho dat de transacties nog steeds bschikbaar zijn, en dat je manueel steeds de transactie kan reconstrueren, maar genoeg ot

[...]

Ook dit is weer een voorbeeld van om het probleem heen werken. Bij de ontwikkeling los je die problemen zoveel mogelijk op. Daar zijn dus vele manieren voor. Je noemt er ondertussen zelf al een hoop op (transactie terugdraaien, historische tabellen, staging,....) Juist door te begrijpen wat de potentiele problemen zijn en met kennis van de applicatie kun je de oplossing optimaliseren. Misschien is een Dirty Read in een situatie de oplossing. Maar dan moet je wel het verschil kennen tussen een transactie met Dirty Reads enabled en een transactie zonder die functies. Er zijn veel applicaties geschreven waarbij de performance belabberd was omdat er niet goed nagedacht was over de concurrency issues. Alarmnummer probeert deze problemen in een kort(?) document uit te leggen. En dat is zeker niet eenvoudig.


[...]

Idd

[...]
...en nog een stukje...

* D4Skunk trekt zich in alle bescheidenheid terug, en zal stoppen met offtopic geneuzel ...

Alarmnummer, mijn excuses voor de topickaping, en doet u rustig verder

[Verwijderd]

D4Skunk schreef op vrijdag 10 maart 2006 @ 13:53:
[...]


Ik denk dat we beiden hetzelfde doel voor ogen hebben, maar dat daarbij onze focus misschien een beetje anders ligt...
Waar ik in mijn initiële post verkeerd gegaan ben, is dat ik het onderwerp van de oplossingen interessanter vond dan de oorzaak van het probleem.

De oplossingen zijn ook interessant Maar helaas meestal situatiespecifiek. Daarnaast moet je om een goede oplossing te kunnen bedenken, ook een goed inzicht hebben in de potentiele locking problemen. Ook het gebruik van multiversioning is bijvoorbeeld geen perfecte oplossing. (Zeker niet Oracles implementatie) Een artikel als dat wat Alarmnummer aan het schrijven is, kan een hoop mensen bewust maken van de problemen. En dat is alleen maar goed. Maar als je een topic wil starten over het oplossen van locking problemen. Ga je gang!

[Alarmnummer]

Ik heb besloten om het artikel op te delen in meerdere kleinere aangezien de stof complex genoeg is en kleinere artikelen gewoon beter lezen. Verder heb ik heb besloten om nog een aantal onderwerpen er aan toe te voegen: offline vs online locking en optimistic vs pessimistic locking, om het verhaal completer te maken. En verder ga ik een aantal stukken nu beter uitdiepen omdat er nu meer ruimte voor is.

Dus iedereen die geinteresseerd is in het ontwerp, hou deze pagina in de gaten.
http://peter.jteam.nl/?p=8

En ik zal ook nog even kijken naar die materialized views. In het Expert one on one Oracle boek staat wel een stuk over materialized views, maar had niet de indruk dat ze erg geschikt waren om concurrency problematiek mee op te lossen, eerder om data warehouses sneller van info te voorzien. Maar ik moet het onderwerp nog eens goed bestuderen om hier echt iets zinnigs over te zeggen.

[ Voor 5% gewijzigd door Alarmnummer op 20-03-2006 10:31 ]

[Verwijderd]

Alarmnummer schreef op maandag 20 maart 2006 @ 10:30:
En ik zal ook nog even kijken naar die materialized views. In het Expert one on one Oracle boek staat wel een stuk over materialized views, maar had niet de indruk dat ze erg geschikt waren om concurrency problematiek mee op te lossen, eerder om data warehouses sneller van info te voorzien. Maar ik moet het onderwerp nog eens goed bestuderen om hier echt iets zinnigs over te zeggen.

Materialized views geven je een resultaat. Niet altijd de correcte, meest recente waarde maar vaak is de waarde "goed genoeg" (Denk bijvoorbeeld aan een omzetcijfer) Doordat ze dus de daadwerkelijke tabel niet gebruiken heb je geen read locks op de tabel nodig en voorkom je locking problemen. Complexe queries voor data mining kunnen op deze manier dus gelijktijdig plaatsvinden met je online transactie verwerking.

[Alarmnummer]

Verwijderd schreef op maandag 20 maart 2006 @ 13:15:
[...]
Materialized views geven je een resultaat. Niet altijd de correcte, meest recente waarde maar vaak is de waarde "goed genoeg" (Denk bijvoorbeeld aan een omzetcijfer) Doordat ze dus de daadwerkelijke tabel niet gebruiken heb je geen read locks op de tabel nodig en voorkom je locking problemen. Complexe queries voor data mining kunnen op deze manier dus gelijktijdig plaatsvinden met je online transactie verwerking.

Maar dat geeft geen antwoord op het feit hoe concurrency problemen (zie verhaal D4Skunk) dus geresolved kunnen worden. Op het moment dat je niet gaat locken, krijg je hoe dan ook concurrency problemen en het is mij dus niet duidelijk hoe Materialized views deze problemen kunnen oplossen. Hoe ga je bv om met een lost update? Of met een deleted item? Ik zal vanavond het hoofdstuk eens doorploegen.

[Verwijderd]

Alarmnummer schreef op maandag 20 maart 2006 @ 13:56:
[...]

Maar dat geeft geen antwoord op het feit hoe concurrency problemen (zie verhaal D4Skunk) dus geresolved kunnen worden. Op het moment dat je niet gaat locken, krijg je hoe dan ook concurrency problemen en het is mij dus niet duidelijk hoe Materialized views deze problemen kunnen oplossen. Hoe ga je bv om met een lost update? Of met een deleted item? Ik zal vanavond het hoofdstuk eens doorploegen.

Je werkt feitelijk met twee losse tabellen. Wordt in de hoofdtabel een record verwijderd, geen probleem. Je query in de materialised view heeft dat record namelijk gewoon nog. Lost updates? Idem dito. Je offert dus accuratesse op voor de mogelijkheid om een (min of meer correct) antwoord te kunnen retourneren. In principe wordt er dus wel gelocked maar omdat de locks op verschillende tabellen werken heb je daar geen last van. (Of in ieder geval minder, updates zullen toch in de hoofdtabel moeten terechtkomen)