Deze uitdaging komt voort uit capaciteitsplanning en middelenallocatie, met name in systemen zoals hotelreserveringsplatforms, cloudinfrastructuur auto-scaling en planning van medische faciliteiten. Vroegere oplossingen vertrouwden op cursor-gebaseerde iteratie of externe applicatielogica om door tijdlijnen te itereren, met ernstige prestatieproblemen bij grote datasets tot gevolg. De opkomst van ANSI SQL:2003 vensterfuncties maakte puur relationele benaderingen van temporele analyse mogelijk, waardoor databases complexe intervalrekeningen efficiënt binnen de engine konden afhandelen.
Gegeven een tabel met middelenboekingen met start_time en end_time tijdstempels, is het doel om het maximale aantal gelijktijdige reserveringen te bepalen dat op een bepaald moment actief is, en de specifieke tijdvenster(s) te identificeren waarin deze piek zich voordeed. De complexiteit ontstaat omdat standaardaggregatie temporele gegevens verengt, terwijl eenvoudige joins een Cartesiaanse explosie creëren wanneer intervallen overlappen. Een robuuste oplossing moet intervalstart en -einde beschouwen als discrete gebeurtenissen, en een lopende telling van actieve middelen berekenen bij elk overgangspunt.
De canonieke benadering transformeert intervallen in discrete gebeurtenissen door UNION ALL te gebruiken om starts (gewicht +1) en eindes (gewicht -1) te scheiden, en vervolgens een cumulatieve som toe te passen via SUM() OVER (ORDER BY timestamp) om gelijktijdigheid bij te houden. Om gelijktijdige starts/eindes deterministisch te verwerken, moeten eindmomenten vóór startmomenten op dezelfde tijdstempel worden verwerkt (met een secundaire sorteersleutel). Wikkel dit tenslotte in een CTE om te filteren op de maximale gelijktijdigheid waarde.
WITH events AS ( SELECT start_time AS ts, 1 AS delta, 0 AS is_end FROM reservations UNION ALL SELECT end_time AS ts, -1 AS delta, 1 AS is_end FROM reservations ), concurrency AS ( SELECT ts, SUM(delta) OVER (ORDER BY ts, is_end, delta ROWS UNBOUNDED PRECEDING) AS concurrent_count FROM events ) SELECT MAX(concurrent_count) AS peak_concurrency FROM concurrency;
Om de specifieke tijdvensters van piekgebruik te vinden, join je terug om perioden tussen opeenvolgende tijdstempels te identificeren waar de telling gelijk is aan de maximale.
Een SaaS-platform volgde miljoenen video-transcoderingsjobs in een tabel jobs met started_at en completed_at tijdstempels. Het operationele team moest exacte perioden identificeren wanneer het GPU-gebruik 100% bereikte om de wachtrijplanning te optimaliseren.
Een overweging was om een cursor te gebruiken om chronologisch te itereren, een teller te verhogen bij starts en te verlagen bij eindes. Hoewel eenvoudig voor ontwikkelaars die vertrouwd zijn met imperatieve talen, verwerkte deze methode rijen sequentieel, waardoor het meer dan 45 minuten duurde op productiedata en tabellen vergrendeld werden. Het vereiste ook complexe transactiemanagement om leesconsistentie te waarborgen.
Een andere alternatieve benadering betrof het genereren van een tijdreeks tabel met één rij per minuut en deze te joinen tegen intervallen met behulp van BETWEEN predicates. Dit leverde nauwkeurige resultaten op, maar vereiste miljarden rijen voor minutenniveau precisie over een jaar, verbruikte terabytes aan tijdelijke opslag en slaagde er niet in om sub-minuut piekdips vast te leggen.
Het team selecteerde de gebeurtenis-gebaseerde UNION ALL benadering met ANSI SQL vensterfuncties. Door starts en eindes te beschouwen als +1/-1 gebeurtenissen, voerde de query uit in 12 seconden met behulp van standaard B-tree-indexen op de tijdstempel kolommen. Deze methode verhielp correct randgevallen waarin taken eindigden precies als andere begonnen.
De analyse onthulde dat de piek gelijktijdigheid zich voordeed tijdens nachtelijke batchverwerking tussen 02:00 en 02:07 UTC, met 847 gelijktijdige taken. Door dynamische wachtrijbeperking specifiek voor dit venster te implementeren, voorkwamen ze een cascade van fouten en verminderden ze overprovisionering van infrastructuur met 30%.
Hoe ga je om met intervallen van nulduur (start_time = end_time) zonder de gelijktijdigheid telling onterecht te verhogen?
Intervallen van nulduur vertegenwoordigen onmiddellijke gebeurtenissen die niet moeten bijdragen aan de gelijktijdige belasting. Als ze worden behandeld als standaardintervallen, kunnen ze mogelijk als actief worden geteld tijdens hun eigen eindgebeurtenis. De oplossing vereist het toekennen van een strikte sorteersleutel: verwerk eindgebeurtenissen (-1) vóór startgebeurtenissen (+1) wanneer tijdstempels samenvallen, en sluit intervallen van nulduur volledig uit de gebeurtenisstroom uit of ken ze een delta van 0 toe, afhankelijk van de bedrijfslogica. In ANSI SQL, wordt dit geïmplementeerd door een discriminator kolom toe te voegen: ORDER BY ts, is_end ASC, delta ASC, waarbij ervoor gezorgd wordt dat beëindigingen de telling verlagen voordat nieuwe toewijzingen deze op dezelfde tijdstempel verhogen.
Waarom kan de gebeurtenis-gebaseerde benadering potentieel onjuiste resultaten retourneren als je UNION in plaats van UNION ALL gebruikt bij het combineren van start- en eindgebeurtenissen?
UNION voert impliciet een DISTINCT operatie uit, waardoor dubbele tijdstempels worden samengevoegd. Als twee reserveringen precies om 2023-10-01 10:00:00 beginnen, reduceert UNION dit tot één rij, waardoor de cumulatieve som een +1 increment mist. Dit leidt tot ondertelling van gelijktijdigheid. UNION ALL behoudt elke afzonderlijke intervalgrens als een aparte gebeurtenis, wat wiskundig vereist is omdat elke reservering onafhankelijk bijdraagt aan de totale belasting. Kandidaten overzien vaak dit onderscheid, ervan uitgaande dat tijdstempel uniekheid waar multipliciteit essentieel is voor correcte aggregatie.
Bij het berekenen van de specifieke tijdvensters van piekgelijktijdigheid (niet alleen de maximale waarde), hoe vermijd je gaten in de output als meerdere opeenvolgende tijdsperioden dezelfde piekwaarde delen?
Nadat de maximale gelijktijdigheid waarde is vastgesteld, zal terugjoinen om alle tijdstempels te vinden waar dit voorkomt discrete punten opleveren. Om continue duurblokken te reconstrueren, moet je de Gaps and Islands techniek toepassen: gebruik LAG() om te controleren of de vorige rij ook op piek stond, en LEAD() om te controleren of de volgende rij op piek staat. Alleen rijen outputten waar de vorige waarde verschilt (eiland start) of de volgende waarde verschilt (eiland eindigt). Paar deze vervolgens met ROW_NUMBER() om start-eind paren te creëren. Kandidaten outputten vaak rauwe tijdstemplijsten of gebruiken GROUP BY op de tellingwaarde, wat de temporele nabijheidsinformatie verliest die nodig is om afzonderlijke piekincidenten van één doorlopende piekperiode te onderscheiden.