Page 2 of 2 FirstFirst 1 2
Results 16 to 30 of 30

Thread: Inladen grote datasets

  1. #16
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Het afstappen van een fat client model en overstappen naar een thin client model maakt het werken met databases van deze omvang behoorlijk sneller. De gebruiker gaat dan niet meer merken dat er enorme hoeveelheden records in de database zitten.
    Wat is sneller? Met de client zal ik nog steeds een query moeten uitvoeren op de server om mijn resultaat te krijgen. Het enige voordeel kan zijn dat als 2 of meerdere pc's de hele ratplan ophaalt, deze gecached is en daarom minder druk op de SQLServer geeft.
    Delphi is great. Lazarus is more powerfull

  2. #17
    Hallo,

    Dank je voor de bijkomende antwoorden !!

  3. #18
    Quote Originally Posted by jkuiper View Post
    Wat is sneller? Met de client zal ik nog steeds een query moeten uitvoeren op de server om mijn resultaat te krijgen. Het enige voordeel kan zijn dat als 2 of meerdere pc's de hele ratplan ophaalt, deze gecached is en daarom minder druk op de SQLServer geeft.
    Hadden het hier over een fat en thin client. dat is nogal een verschil in de hoeveelheid data die opgestuurd wordt. In de meest extreme definitie van een fat client is er geen aparte sql server maar wordt de database (sql) engine in de client geladen en de volledige database over het network van een locale shared drive ingelezen. De server in dit model is dan een file server en niet een sql server.

  4. #19
    Ik kreeg niet de indruk dat het daarom ging, aangezien er al over queries gesproken werd.
    Maar als je het omdraait kan het juist wel sneller lijken. Maar lokaal cachen, wat jkuiper noemt, kan wel handig zijn, zeker als je bijvoorbeeld met je productcatalogus langs klanten moet en niet altijd een beste verbinding hebt. Je kan 'm dan synchroniseren als je verbinding hebt, en je lokale cache gebruiken.
    1+1=b

  5. #20
    Maar lokaal cachen, wat jkuiper noemt, kan wel handig zijn, zeker als je bijvoorbeeld met je productcatalogus langs klanten moet en niet altijd een beste verbinding hebt. Je kan 'm dan synchroniseren als je verbinding hebt, en je lokale cache gebruiken.
    Volgens mij doelde John op cachen van de results op de server, waardoor niet steeds alles vanuit de DB moet komen. Briefcase wat jij hier beschrijft kan handig zijn, maar ik heb nog geen out of the box oplossingen gezien.

    We moeten er denk ik hier geen discussie over starten, maar bij een thin client doet de client meestal niets direct op de database maar via een middleware laag. De meeste middleware frameworks hebben een vorm van paging, waardoor de client niet de hele resultset zal ontvangen maar slechts een of enkele pages en de rest indien nodig. Verfijnt de gebruiker zijn zoekactie zal dat in een nieuwe query resulteren en opnieuw slechts een deel naar de client sturen. Omdat de server en de databse meestal vlak bij elkaar staan of in ieder geval in een afgestemde setup zal de performance (meestal) beter zijn dan bij een fat client.

    Nadeel van die opzet ten opizchte van alles eerst lokaal halen en daarin lokaal zoeken is de roundtrip naar de server. Maar ook bij een fat client die dynamisch een query doet zoals in de diverse voorbeelden zal een roundtrip gedaan moeten worden.

    Voor lokale cache in memory zijn overigens alternatieven beschikbaar die ook met sql zijn uit te vragen. kbmMemtable is daar een voorbeeld van. De TS zou dus ook nog een mechanisme kunnen bedenken waarbij een lokale kopie van een dergelijke grote tabel kan worden bijgehouden gecombineerd met een query om alleen de wijzigingen op te halen en verwerken. Het zou niet mijn voorkeur zijn, maar voor sommige use cases, waaronder de briefcase, wel een oplossing.

  6. #21
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by Miep View Post
    Het afstappen van een fat client model en overstappen naar een thin client model maakt het werken met databases van deze omvang behoorlijk sneller. De gebruiker gaat dan niet meer merken dat er enorme hoeveelheden records in de database zitten.
    Zover hoeft het niet te gaan. De paar gevallen met zeer hoge cardinaliteit kunnen op de fat client ook gewoon verder gemanaged worden (door geparameterizeerde zoek oplossingen, TOP of andere beperkingen in queries enz), zonder dat je direct een 3-tier structuur invoert en alles met de hand uitschrijft. Alle kleine entiteiten kunnen nog steeds met een simpel grid+navigator naar de tabel beheerd wordne.

  7. #22
    Quote Originally Posted by marcov View Post
    ...TOP...
    Alleen deze er even uitgehaald omdat die wel duidelijk gedefinieerd is in de meeste engines. In de door mij gebruikte database (DBISAM, >TB sized databases) wordt bij het gebruik van TOP de alsnog de volledige data verwerkt om tot de TOP te komen. Als de fat client de engine in de client heeft moet dus alsnog eerst de volledige dataset over het network waarna de opdracht wordt verwerkt en daarna pas de TOP word aangeboden.

    Dit is zover ik weet het geval bij alle beperking via query's omdat alle data eerst bekend moet zijn voordat de fat client database engine de beperking kan toepassen.

    Had zelf zo'n fat client gemaakt omdat het makkelijker in de onderhoud was. Nadat er gebruikers waren die jaren lang de software gebruikte en de database over de TB heen kregen letterlijk minuten moesten wachten overgestapt op een thin client model en samen met de query plan info verder getuned. Nu is de performance altijd hetzelfde (voor de gebruiker) met als opmerking dat de "free query form" wel beperkt is gehouden en de dataset met grote records (images) vertraagd gelinkt worden.

  8. #23
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by Miep View Post
    Alleen deze er even uitgehaald omdat die wel duidelijk gedefinieerd is in de meeste engines. In de door mij gebruikte database (DBISAM, >TB sized databases) wordt bij het gebruik van TOP de alsnog de volledige data verwerkt om tot de TOP te komen.
    Hoeft niet. De sql engine kan indexen gebruiken. Ik heb overigens normale DBs als SQL Server en postgres in het achterhoofd.

    Als de fat client de engine in de client heeft moet dus alsnog eerst de volledige dataset over het network waarna de opdracht wordt verwerkt en daarna pas de TOP word aangeboden.
    Welk netwerk? Als er iets over het netwerk moet, dan is de SQL engine toch _VOOR_ het netwerk? En als het filebased is, dan gaat het toch niet over het netwerk? Ik heb het over de basis query, niet over extra client side filtering (al dan niet in SQL).

    Of bedoel je file based databases op een gedeelde share? Dat is sowieso de minst schaalbare optie, maar zelfs dan zou het backend via indexen nog kunnen beperken met gerichte seeks naar blokken waar geldige entries in zitten, en stoppen zogauw het aantal verwerkt is (b.v. als een van de andere condities geindexed is, en erg selectief is). Alleen als er ook nog een sortering bijkomt, heb je dan alle records nodig.

    Dit is zover ik weet het geval bij alle beperking via query's omdat alle data eerst bekend moet zijn voordat de fat client database engine de beperking kan toepassen.
    Ik denk dat je eerst je definitie van fat/thin client eens moet gaan uitwerken. Ik kom er niet helemaal wijs uit in de context van database applicaties. Ik heb fat een beetje geinterpreerd als een applicatie die direct op de db engine toegrijpt (two-tier), en thin als een minimaal client tier van een 3 tier applicatie.
    Last edited by marcov; 27-May-20 at 16:40.

  9. #24
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by GolezTrol View Post
    Ik kreeg niet de indruk dat het daarom ging, aangezien er al over queries gesproken werd.
    Maar als je het omdraait kan het juist wel sneller lijken. Maar lokaal cachen, wat jkuiper noemt, kan wel handig zijn, zeker als je bijvoorbeeld met je productcatalogus langs klanten moet en niet altijd een beste verbinding hebt. Je kan 'm dan synchroniseren als je verbinding hebt, en je lokale cache gebruiken.
    Een trucje dat ik eens gedaan heb voor een stambestand dan maar langzaam muteerde maar veel nodig is.
    - alle tabel entries hebben een last mutated timestamp.
    - oude records niet verwijderen maar op disabled zetten en mutated timestamp updaten bij deletion.
    - mogelijk Index op het time stamp

    Als je dan de timestamp van de laatste update onthoudt, dan is je cache delta is select * where mutated>lastupdate. De deleted records in deze delta kan je dan gebruiken om verouderde records uit je cache te deleten.

    - cache delta draaien bij opstart, en met een timer of indien een watch op de tabel fired.

    Enig probleem was dat het stam bestand uit meerdere zulke tabellen bestond, en soms niet consistent was. (b.v. bij verwerking waren bepaalde records waar naar gerefereerd werd er niet). Aangenomen werd dan dat er een update in progress was, en met een timer werd de delta een x tijd later nog eens gedraaid.

  10. #25
    Quote Originally Posted by marcov View Post
    Ik denk dat je eerst je definitie van fat/thin client eens moet gaan uitwerken. Ik kom er niet helemaal wijs uit in de context van database applicaties. Ik heb fat een beetje geinterpreerd als een applicatie die direct op de db engine toegrijpt (two-tier), en thin als een minimaal client tier van een 3 tier applicatie.
    Zal wel een leeftijd ding zijn, ooit (je weet wel lang geleden toen alles beter was ) was de definitie van een fat client een desktop applicatie die zijn database ergens op een file server had staan.

  11. #26
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Wat mij bijstaat in abstracte zin: Fat clients hebben zelf state en implementeren ook de meeste business rules (e.g. gecachte tabellen/queries, stambestanden dropdown lijstjes e.d.), thin clients hebben geen tot weinig (eigen) state, en meeste businessrules zitten op de server (in het middle tier)

    De ultieme thin client was de webbrowser (in het pre ajax tijdperk), die zelfs de formulieren van het netwerk krijgt, en alle state volledig herlaadt.

  12. #27
    thin clients hebben juist wel een state, de servers met de business rules zijn stateless.

  13. #28
    Alles hangt ook heel sterk af hoe je database structuur in elkaar zit, zeker als je veel joins moet doen. Joins die aan elkaar hangen via Id-nummers en geclusterde indexen zijn een pak sneller dan een koppeling van via een index bestaande uit 3 varchar velden

    Hoe je de joins maakt speelt ook een rol. Right outer joins zijn meestal trager dan left outer joins.

    Daarnaast speelt ook het aantal velden dat je gaat ophalen een rol, niet enkel het aantal records.
    De verbazing begint waar de kennis ophoudt

  14. #29
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    En dan zijn er nog dingen als NOLOCK op sql server.

    Benno (iets verlaat): nee, thin clients zijn niet per se stateless/REST. Thin webclients zijn dat vaak wel, omdat http stateless is, maar het is geen vereist vziw.

  15. #30
    Quote Originally Posted by marcov View Post
    En dan zijn er nog dingen als NOLOCK op sql server.

    Benno (iets verlaat): nee, thin clients zijn niet per se stateless/REST. Thin webclients zijn dat vaak wel, omdat http stateless is, maar het is geen vereist vziw.
    Well the point of being thin is not to hold business code in the client, but only presentation code.
    As such there can be some level of state in a client (to handle the presentation), but there should not be a state held in the client related to the business code.
    That state (if needed) should be held on the server. In Web servers it is usually called a session.
    In kbmMW it can also be a state ID, which results in a kbmMW based application server to keep specific service instances tied to a client. Those service instances will not be reused until the state is relinguished.

    Hence there are multiple ways to handle state. Some leave the state as cookies on the client, some leaves the state as a datablob in a database on the server and yet some leaves the state as live code running on the server.

    But to boil it down, a thin client should not hold any business code related state.

Page 2 of 2 FirstFirst 1 2

Thread Information

Users Browsing this Thread

There are currently 2 users browsing this thread. (0 members and 2 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •