SQL Query's simultaan laten draaien

[Jan20]

Op dit moment zit ik een aantal Query's te draaien op een server (64 cores) waarbij een groot aantal rijen worden opgehaald rond de 6.6 miljoen per maand en heb ik een splitsing gemaakt met where statements naar periode en entiteit.

Nu zou ik graag:

Select


test1 as [tablesource],
kolom1 As [kolom1],
kolom2 AS [kolom2]

FROM database1
where ReportingPeriodDate in ('2016-01-31') AND
ReportingEntityName = 'Entiteit1'
Order by V_CounterpartyRepresentativeId ASC

Select


test1 as [tablesource],
kolom1 As [kolom1],
kolom2 AS [kolom2]

FROM database1
where ReportingPeriodDate in ('2015-12-31') AND
ReportingEntityName = 'Entiteit1'
Order by V_CounterpartyRepresentativeId ASC

Nu zou ik deze graag SQL Queries simultaan naast elkaar laten draaien, maar nu krijg ik niet echt duidelijk hoe ik dit zou moeten inprogrammeren in de Query en of dit uberhaupt mogelijk is?

[Voutloos]

Over welke SQL server gaat het precies?

Waarom 2 queries als het uit 1 tabel komt? Vanwaar de aanname dat 2 queries parallel sneller is dan 1 query over hele periode met fatsoenlijke index en group by?

[Jan20]

Voutloos schreef op woensdag 23 maart 2016 @ 20:09:
Over welke SQL server gaat het precies?

Waarom 2 queries als het uit 1 tabel komt? Vanwaar de aanname dat 2 queries parallel sneller is dan 1 query over hele periode met fatsoenlijke index en group by?

Bovenstaande punten ga ik ook toepassen, maar als ik bijvoorbeeld: 3 maanden zou willen ophalen praten wij rond de 18 miljoen rijen en dan duurt het executen van de Query erg lang.

Ik dacht eventueel dat het misschien efficient zou zijn om op verschillende cores de verschillende queries te draaien? Voor mij is het ook een beetje uitzoeken wat tot verbeteringen zou kunnen leiden

[Fish]

Wat doe je met al die sloten aan data? als het voor een rapportage is moet je kijken of ej niet veel meer kan doen met sql. als je werkelijk elke regel nodig hebt voor iets is het mischien handiger om dat beetje bij beetje te doen. maar leg eerst eens uit

[Jan20]

Fish schreef op woensdag 23 maart 2016 @ 20:24:
Wat doe je met al die sloten aan data? als het voor een rapportage is moet je kijken of ej niet veel meer kan doen met sql. als je werkelijk elke regel nodig hebt voor iets is het mischien handiger om dat beetje bij beetje te doen. maar leg eerst eens uit

Goed punt ik zelf gebruik de ruwe data maar er worden inderdaad ook rapportages op gebouwd. Zal morgen eens door die rapportages heen gaan en kijken of die functies niet ingebouwd kunnen worden in SQL zelf

[Fish]

Help me ff uit, wat doe jij met 6miljoen regels ruwe data ?

Klinkt alsof je wel goed gereedschap hebt, maar niet weet hoe je die moet gebruiken

[ Voor 40% gewijzigd door Fish op 23-03-2016 21:10 ]

[Douweegbertje]

Jan20 schreef op woensdag 23 maart 2016 @ 20:13:
[...]


Bovenstaande punten ga ik ook toepassen, maar als ik bijvoorbeeld: 3 maanden zou willen ophalen praten wij rond de 18 miljoen rijen en dan duurt het executen van de Query erg lang.

Ik dacht eventueel dat het misschien efficient zou zijn om op verschillende cores de verschillende queries te draaien? Voor mij is het ook een beetje uitzoeken wat tot verbeteringen zou kunnen leiden

Nou, begin eerst eens met welke SQL je gebruikt?
Bijvoorbeeld mssql zou niet eens 64 cores gebruiken, tenzij je de super de luxe versie hebt.. en dan nog is het niet eens zo efficient als gewoon een bak geheugen hebben.

6 miljoen regels stelt ook eigenlijk geen reet voor. Het enige wat boeit is dat je een order erop hebt zitten. Er zitten niet eens joins of 'spannende' dingen in je query.

Om mijn punt te bewijzen net even een select gedaan op een table met 25mil records. Hier 2 kolommen uitgehaald met een order by op één van die kolommen. Iets meer dan 1 minuut op 1 core en ~ 6 gig geheugen en ik heb niets geoptimaliseerd om zulke 'domme' queries uit te voeren. Met dom bedoel ik dat het voor het systeem ook geen slimme queries zijn. In feite ook niet voor de user.. maar toch

Ik zou dus even kijken naar je indexes en dat soort zaken. Optimaliseren voor je doeleind en kijken wat je nu echt wilt.

[Gomez12]

Jan20 schreef op woensdag 23 maart 2016 @ 20:13:
[...]
Bovenstaande punten ga ik ook toepassen, maar als ik bijvoorbeeld: 3 maanden zou willen ophalen praten wij rond de 18 miljoen rijen en dan duurt het executen van de Query erg lang.

Waarom duurt het erg lang om die 18 miljoen rijen te produceren? Traag netwerk? Slechte/geen indexen? Wat zegt je explain?

Ik dacht eventueel dat het misschien efficient zou zijn om op verschillende cores de verschillende queries te draaien? Voor mij is het ook een beetje uitzoeken wat tot verbeteringen zou kunnen leiden

Wat is je RDBMS, want menig RDBMS regelt multi-core dingen tig keer beter dan jij handmatig doet alleen hangt er veelal wel een hoog prijskaartje aan.
Dit handmatig uitzoeken is moeizaam werk wat nog wel eens tot lockings kan leiden en dan ben je nog verder van huis. Oftewel laat je RDBMS het afhandelen als je er het budget voor hebt.

[Avalaxy]

Als beide queries dezelfde tabellen aanspreken dan gaat parallel uitvoeren sowieso niet werken omdat de eerste query een lock zal nemen op de tabel (of rows, of page, maar aangezien je alles wilt ophalen wordt het waarschijnlijk geëscaleerd naar een table lock). Dit betekent dat query 2 moet wachten tot query 1 klaar is en het dus sequentieel wordt uitgevoerd.

Je hebt dan dus twee opties:
- Queries uitvoeren zonder locking (zou ik je niet aanreden, zeker niet voor rapportages, dit levert namelijk inconsistente data op).
- Partitioning. Verdeel je data over meerdere partities en query de partities parallel in meerdere threads.

[Douweegbertje]

Avalaxy schreef op donderdag 24 maart 2016 @ 00:27:
Als beide queries dezelfde tabellen aanspreken dan gaat parallel uitvoeren sowieso niet werken omdat de eerste query een lock zal nemen op de tabel (of rows, of page, maar aangezien je alles wilt ophalen wordt het waarschijnlijk geëscaleerd naar een table lock). Dit betekent dat query 2 moet wachten tot query 1 klaar is en het dus sequentieel wordt uitgevoerd.

Je hebt dan dus twee opties:
- Queries uitvoeren zonder locking (zou ik je niet aanreden, zeker niet voor rapportages, dit levert namelijk inconsistente data op).
- Partitioning. Verdeel je data over meerdere partities en query de partities parallel in meerdere threads.

uh, een select gooit echt geen volledige lock op de gehele table of uberhaupt op iets. Select heeft een shared lock, maar dat maakt dan niets uit als je een tweede select uitvoert. Immers zijn de shared locks compatible met elkaar en wordt zo'n lock direct gereleased op het moment dat hij ingelezen is(per row..).

Weet je wel niet wat voor impact het zou hebben als 'read' queries een full lock op de table/rows zouden hebben? Dan kun je eigenlijk niet meer dan 1 user op je site/applicatie hebben omdat constant alles permanent gelocked is... Dus nee.

Eigenlijk merk je er niets van, tenzij je een update naast een select doet. Zelfs dan maakt het niet super veel uit omdat ze redelijk naast elkaar kunnen werken. Een update wordt alleen vast gezet op het moment dat hij een veld wilt updaten die nog niet door de select is gegaan. Volgens mij (citation needed) pakt de select dan snel die kolom zodat de update verder kan. Indien de row al gelezen is door de select kan de update per direct worden uitgevoerd.

In elk geval heeft TS het over 2 selects, in feite hoef je het dan al niet over locks te hebben. TENZIJ beide selects inherent aan elkaar zijn (dus exact dezelfde data nodig hebben) dan moet je verplichten dat beide selects een lock gaan zetten...

[ Voor 3% gewijzigd door Douweegbertje op 24-03-2016 00:43 ]

[RobIII]

Avalaxy schreef op donderdag 24 maart 2016 @ 00:27:
Als beide queries dezelfde tabellen aanspreken dan gaat parallel uitvoeren sowieso niet werken omdat de eerste query een lock zal nemen op de tabel (of rows, of page, maar aangezien je alles wilt ophalen wordt het waarschijnlijk geëscaleerd naar een table lock). Dit betekent dat query 2 moet wachten tot query 1 klaar is en het dus sequentieel wordt uitgevoerd.

Waarom zou er een lock genomen worden bij deze twee selects
http://dba.stackexchange.com/a/50029/8200

@douweegbertje is me voor Ik zie de notificatie terwijl ik 'tzelfde verhaal zit te typen (Hoewel dat stukje vanaf "(citation needed)" niet helemaal klopt, maar dat is hier verder ook helemaal niet relevant dus laten we ons dat besparen )

Over parallelism: https://www.simple-talk.c...arallelism-in-sql-server/ of natuurlijk gewoon de documentatie
en meer van dat soort zaken die je in 3 minuten had kunnen googlen: behalve even controleren of 't aan staat en geconfigureerd is _{(default = aan & goed geconfigureerd voor de meest basic gevallen; soms wil je wat tweaken en sleutelen maar alleen als je weet wat je doet)} hoef je doorgaans niets te doen en zal SQL Server zélf veel beter bepalen wat te paralleliseren is en waar dat niet handig is dan dat jij dat kunt (zeker als je met de "botte bijl" probeert iets te paralleliseren "omdat snel").

[ Voor 60% gewijzigd door RobIII op 24-03-2016 01:00 ]

[Douweegbertje]

RobIII schreef op donderdag 24 maart 2016 @ 00:42:
[...]

Waarom zou er een lock genomen worden bij deze twee selects
http://dba.stackexchange.com/a/50029/8200

@douweegbertje is me voor Ik zie de notificatie terwijl ik 'tzelfde verhaal zit te typen (Hoewel dat stukje vanaf "(citation needed)" niet helemaal klopt, maar dat is hier verder ook helemaal niet relevant dus laten we ons dat besparen )

Ach nu ben ik wel benieuwd..

Overigens zal je dat vast vaker gaan krijgen nu.. dat andere sneller zijn..

[sig69]

Om de TS een beetje te beantwoorden: je kan niet een query "programmeren" om twee queries parallel uit te voeren. Ik zie niet eens een reden om deze queries op te splitsen. Dus:
Indien MySql: Explain
Indien MsSql: Execution plan
Laat dat eerst maar eens zien
Indien anders: zullen ook wel soortgelijke functies voor zijn

[Caelorum]

sig69 schreef op donderdag 24 maart 2016 @ 00:59:
[...]
Indien anders: zullen ook wel soortgelijke functies voor zijn

Voor compleetheid van het topic.
Indien Sybase: set showplan on