Cross DB queries in Azure

[Vexxon]

Goededag,

Een aantal maanden geleden hebben we al onze websites, databases en overige software gemigreerd naar Azure. Het probleem alleen is dat er rapporten gegenereerd moeten worden met data uit verschillende databases. De definitie van de data die opgehaald moet worden veranderd continue en wordt vooral gegenereerd door queries te draaien vanuit SQL Management Studio.
Helaas is het niet meer mogelijk om cross DB queries te draaien in Azure, terwijl de databases wel op dezelfde server staan.
Nu is er een 'oplossing' via Elasic database queries, maar dat gaat er vanuit dat de schema's van de twee (of meer) databases hetzelfde zijn en dat is bij ons zeker niet het geval. Daarbij worden er zogenaamde shards aangemaakt wat een kopie is van de database die je wilt querien met nog wat extra management-tabellen en nog een gecombineerde database van alle data op 1 hoop. Oftewel erg veel overhead naar ons idee.

Heeft één van jullie al ervaring met bovenstaande oplossing of juist een heel andere oplossing gevonden?

bvd.

[Haan]

Dan kom je denk ik toch al snel op een data warehouse-achtige oplossing denk ik, waarbij je alle data (periodiek) vanuit al je databases naar de data warehouse stuurt.
Sowieso ben ik niet erg te spreken over het SQL Azure model van DTU's (data transaction units), 1 zware query en je zit over je DTU quotum heen en weg is je performance. Daarom alleen al wil je eigenlijk geen reporting doen op een azure database waar ook gewoon op gewerkt wordt.

Overigens zie ik dat er inmiddels ook een Azure data warehouse oplossing is. Daar al naar gekeken?

[ Voor 16% gewijzigd door Haan op 29-09-2015 22:33 ]

[Vexxon]

Bedankt voor je reactie!
Naar Datawarehousing had ik eigenlijk nog niet gekeken, maar ik had wel al van de oplossing gehoord.
We zijn sowieso van plan om een 'schaduwdatabase' op te zetten waar we reporting op gaan doen.
De vraag is alleen hoe we die up-to-date houden. Wellicht dat dit een optie is.

[Merethil]

Vexxon schreef op donderdag 01 oktober 2015 @ 12:50:
Bedankt voor je reactie!
Naar Datawarehousing had ik eigenlijk nog niet gekeken, maar ik had wel al van de oplossing gehoord.
We zijn sowieso van plan om een 'schaduwdatabase' op te zetten waar we reporting op gaan doen.
De vraag is alleen hoe we die up-to-date houden. Wellicht dat dit een optie is.

De meeste databases ondersteunen wel triggers op inserts/updates etc. Als je niet té veel werk via je database laat lopen kan je eventueel die triggers zo schrijven dat ze de schaduwdatabase bijwerken zodra er een insert/update plaatsvindt.

Een datawarehouse opzetten is vaak het meest performant maar je data realtime synchroniseren is wel een stuk lastiger. Dagelijkse jobs laten draaien die de data bijwerken (of uurlijk, of hoe vaak je het ook wilt) met delta-data is makkelijker, maar dan zou je bij alles een statusveld met timestamp oid moeten gaan bijhouden.

[Vexxon]

Ik ben even aan stoeien met Azure Data Warehouse en het lijkt erop dat dat de oplossing is.

[pedorus]

Merethil schreef op donderdag 01 oktober 2015 @ 13:24:
De meeste databases ondersteunen wel triggers op inserts/updates etc. Als je niet té veel werk via je database laat lopen kan je eventueel die triggers zo schrijven dat ze de schaduwdatabase bijwerken zodra er een insert/update plaatsvindt.

Klinkt als een optie die zeer foutgevoelig is (wat als trigger even niet kan)..

Overigens is Azure zelf voor ons ook nog te foutgevoelig voor de meeste productie bevonden. Voor data warehousing is beschikbaarheid niet zo'n issue, maar we hebben oa ervaringen dat er 25+ hosts down gingen en daarna oa een ander ip adres kregen... Dus ik zou de overstap van TS nog niet hebben gemaakt. (Dus de 'andere oplossing' is dan eenvoudigweg geen Azure gebruiken. )

[Merethil]

pedorus schreef op vrijdag 02 oktober 2015 @ 01:12:
[...]

Klinkt als een optie die zeer foutgevoelig is (wat als trigger even niet kan)..

Overigens is Azure zelf voor ons ook nog te foutgevoelig voor de meeste productie bevonden. Voor data warehousing is beschikbaarheid niet zo'n issue, maar we hebben oa ervaringen dat er 25+ hosts down gingen en daarna oa een ander ip adres kregen... Dus ik zou de overstap van TS nog niet hebben gemaakt. (Dus de 'andere oplossing' is dan eenvoudigweg geen Azure gebruiken. )

Een trigger die niet kan heb ik nog nooit van gehoord... In welke gevallen zou dit mogelijk zijn? Voor zover ik weet draait een trigger altijd na het specifieke triggerproces, en fouten kan je er natuurlijk in opvangen.

[pedorus]

Als je een trigger inzet om data naar een andere server te krijgen, dan kom er ongetwijfeld een moment waarop de netwerkverbinding faalt of de andere server uit staat, etc. Je kan dan wel die fouten gaan opvangen, maar wat doe je er dan mee?

(Replicatie werkt dan ook bijna altijd met logbestanden om te kunnen recoveren.)