Niente viene pre-generato
La disponibilità, come i prezzi, si risolve nel momento in cui viene richiesta, a partire da regole ed eccezioni. Non esiste un job di manutenzione che crea righe in anticipo, e nulla su cui rimanere indietro.
Velocità e affidabilità
Veloce oggi. Altrettanto veloce a dieci volte il traffico.
Un calendario di dieci anni costa esattamente quanto interrogare domani. Le operazioni in blocco girano come singoli round trip, non una query per riga. E gli indici da cui dipendono reportistica e prezzi esistevano già prima del volume che li avrebbe richiesti.
- Zero pre-generazione Un calendario di dieci anni costa esattamente quanto interrogare domani
- 1 round trip Le operazioni in blocco girano come singole query raggruppate, verificate da test che contano il log delle query reali
- In coda, non bloccanti Import CSV ed email di conferma girano in background, a blocchi, senza mai far attendere chi le ha avviate
Quattro pezzi per restare veloci.
Ognuno elimina un modo diverso in cui le prestazioni di solito degradano silenziosamente, finché non lo fanno più.
A blocchi, mai riga per riga
Caricare i pool di capienza per un calendario, risolvere prezzi su un intervallo di date, o importare un CSV di codici stock girano tutti come un numero limitato di query, indipendentemente da quante righe sono coinvolte.
Gli indici esistono prima che servano
Le query di reportistica, disponibilità e prezzi sono supportate da indici progettati insieme alla funzionalità stessa, non aggiunti più tardi una volta che qualcosa è diventato lento in produzione.
Il lavoro in background resta fuori dalla richiesta
Import di grandi dimensioni ed email di conferma girano tramite una coda, così caricare diecimila codici stock o inviare una ricevuta non fa mai attendere nessuno sulla pagina.
Come la velocità viene dimostrata, non solo dichiarata
Cinque pratiche dietro il motivo per cui la piattaforma resta veloce man mano che i dati crescono, non solo al lancio in piccolo.
- 1
Un conteggio di query viene verificato, non presunto
Il report vendite viene testato con 3 ordini e di nuovo con 30, verificando lo stesso identico numero di query entrambe le volte, così "questo scala" è qualcosa che un test controlla davvero, non solo una speranza.
- 2
Un import CSV gira in blocchi limitati
Un import di stock scorre il file 1.000 righe alla volta, inserendo ogni blocco come una singola scrittura raggruppata invece di una riga alla volta, così un file con decine di migliaia di righe non tiene mai aperta un'unica transazione enorme.
- 3
Un job in coda attende che la transazione si confermi davvero
I job legati a qualcosa appena scritto, un'email di conferma ordine, un import di stock, partono solo dopo che la transazione del database che ha creato i loro dati si è effettivamente confermata, mai prima.
- 4
Un indice viene costruito per la forma della query che serve
Un indice composito su organizzazione, stato e data di ricevuta serve ogni filtro di report contemporaneamente; uno separato su soggetto e stato serve specificamente le query "chi ha raggiunto questo stato in questo intervallo", perché sono pattern di accesso genuinamente diversi.
- 5
Un nuovo tentativo dopo un duplicato non corrompe mai i dati
Se un job di import in coda viene ritentato, un controllo di duplicati per blocco più il vincolo di unicità del database impediscono che lo stesso codice stock venga inserito due volte, così ritentare è sempre sicuro.
Velocità che puoi verificare, non solo dichiarare
Lo stesso test di regressione sul conteggio delle query che protegge il report vendite, eseguito su due volumi di ordini diversi, verificando un conteggio di query identico entrambe le volte.
TEST BuildsSalesReportTest.php
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
{
"test": "sales report query count",
"orders_in_range": [
3,
30
],
"queries_executed": [
14,
14
]
}Verificato da test automatico
Un report su 3 ordini esegue esattamente tante query quanto uno su 3 milioni
Il modo più comune in cui un report rallenta silenziosamente è una query in più nascosta dentro un ciclo, invisibile con una manciata di ordini di test e visibile solo in produzione, su larga scala. La suite di test di Tiqory fissa il numero esatto di query per 3 ordini e riverifica lo stesso identico numero per 30, individuando una query vagante per riga nel momento stesso in cui viene introdotta, non mesi dopo quando la cronologia ordini di un cliente è cresciuta abbastanza da farsene accorgere.
Domande frequenti
No. Nulla nella disponibilità è pre-generato o memorizzato in anticipo; ogni data e fascia si risolve da regole ed eccezioni nel momento in cui viene richiesta, così una query a dieci anni di distanza costa quanto una per domani.
Viene elaborato in background, a blocchi di mille righe, inseriti come scritture raggruppate invece che una alla volta, e non blocca mai chi lo ha caricato dall'usare il resto del pannello.
Un test costruisce il report con 3 ordini, poi con 30, e verifica che il numero esatto di query al database resti identico entrambe le volte. È una proprietà dimostrata, non un'ipotesi.
No. Un controllo di duplicati per blocco, sostenuto da un vincolo di unicità del database come ultima rete di sicurezza, fa sì che ritentare un job di import fallito sia sempre sicuro e non crei mai due volte lo stesso codice stock.
Prima. Gli indici per le query di reportistica, disponibilità e prezzi sono progettati insieme alla funzionalità che ne ha bisogno, come parte della sua costruzione, non aggiunti più tardi come correzione una volta che una query inizia ad andare in timeout.
Più prenotazioni. Più canali. La stessa calma.
Tiqory mantiene disponibilità, prezzi, pagamenti e accessi allineati mentre la tua operazione cresce. Dicci dove vuoi arrivare: ti mostriamo come farlo senza ricominciare da zero.