Fort sinn d'Deeg wou Dir keng Suergen iwwer d'Optimisatioun vun der Datebankleistung hutt. D'Zäit steet net roueg. All neien Tech Entrepreneur wëll déi nächst Facebook schafen, iwwerdeems probéiert all d'Donnéeën ze sammelen se kënnen hir Hänn op kréien. D'Geschäfter brauchen dës Donnéeën fir besser Modeller ze trainéieren déi hinnen hëllefen Suen ze maachen. An esou Konditiounen mussen d'Programméierer APIen erstellen, déi et hinnen erlaben séier an zouverlässeg mat enorme Quantitéiten un Informatioun ze schaffen.
Wann Dir Applikatioun oder Datebank Backends fir eng laang Zäit designt hutt, hutt Dir wahrscheinlech Code geschriwwen fir paginéiert Ufroen auszeféieren. Zum Beispill, wéi dëst:
SELECT * FROM table_name LIMIT 10 OFFSET 40
Wéi ass et?
Awer wann dat ass wéi Dir Är Paginatioun gemaach hutt, et deet mir leed ze soen datt Dir et net op déi effizientest Manéier gemaach hutt.
Wëllt Dir géint mech protestéieren? . , и Si benotze schonn d'Techniken iwwer déi ech haut wëll schwätzen.
Nennt op d'mannst ee Backend Entwéckler deen ni benotzt huet OFFSET и LIMIT fir paginéiert Ufroen auszeféieren. A MVP (Minimum Viable Product) an a Projete wou kleng Quantitéiten un Daten benotzt ginn, ass dës Approche ganz applicabel. Et "wierkt just", souzesoen.
Awer wann Dir zouverlässeg an effizient Systemer vun Null muss kreéieren, sollt Dir Iech am Viraus oppassen op d'Effizienz vun der Ufro vun den Datenbanken, déi an esou Systemer benotzt ginn.
Haut schwätze mir iwwer d'Problemer mat allgemeng benotzten (ze schlecht) Implementatioune vu paginéierten Ufromotoren, a wéi een héich Leeschtung erreechen wann Dir esou Ufroen ausféiert.
Wat ass falsch mat OFFSET a LIMIT?
Wéi scho gesot, OFFSET и LIMIT Si Leeschtunge gutt a Projeten déi net mat grousse Quantitéiten un Daten musse schaffen.
De Problem entsteet wann d'Datebank esou eng Gréisst wiisst datt se net méi an d'Erënnerung vum Server passt. Wéi och ëmmer, wann Dir mat dëser Datebank schafft, musst Dir paginéiert Ufroen benotzen.
Fir datt dëse Problem sech manifestéiere muss, muss et eng Situatioun sinn, an där d'DBMS op eng ineffizient Full Table Scan Operatioun op all paginéiert Ufro zréckgräift (während Insertiouns- a Läschoperatioune kënnen optrieden, a mir brauche keng aktuell Daten!).
Wat ass e "Voll Dësch Scan" (oder "sequenziell Dësch Scan", Sequential Scan)? Dëst ass eng Operatioun während där d'DBMS sequenziell all Zeil vun der Tabell liest, dat heescht d'Donnéeën, déi dra enthale sinn, a kontrolléiert se op d'Konformitéit mat enger bestëmmter Konditioun. Dës Zort Dësch Scan ass bekannt als de luesste. D'Tatsaach ass datt wann et ausgefouert gëtt, vill Input / Output Operatioune gemaach ginn, déi den Disk-Subsystem vum Server involvéieren. D'Situatioun gëtt verschlechtert duerch d'Latenz verbonne mat der Aarbecht mat Daten, déi op Disken gespäichert sinn, an d'Tatsaach datt d'Iwwerdroung vun Daten vun der Disk an d'Erënnerung eng Ressourceintensiv Operatioun ass.
Zum Beispill hutt Dir Rekorder vun 100000000 Benotzer an Dir leeft eng Ufro mam Konstrukt OFFSET 50000000. Dëst bedeit datt d'DBMS all dës Opzeechnungen muss lueden (a mir brauche se net emol!), se an d'Erënnerung setzen, an duerno huelen, soen, 20 Resultater gemellt an LIMIT.
Loosst eis soen datt et esou ausgesäit: "wielt Reihen vun 50000 bis 50020 vun 100000". Dat ass, de System muss als éischt 50000 Reihen lueden fir d'Ufro ofzeschléissen. Gesitt Dir wéi vill onnéideg Aarbecht si wäert maachen?
Wann Dir mir net gleeft, kuckt op d'Beispill, dat ech mat de Funktiounen erstallt hunn .
Beispill op db-fiddle.com
Do, lénks, am Feld Schema SQL, et gëtt Code deen 100000 Reihen an d'Datebank setzt, a riets am Feld Query SQL, ginn zwou Ufroe gewisen. Déi éischt, lues, gesäit esou aus:
SELECT *
FROM `docs`
LIMIT 10 OFFSET 85000;
An déi zweet, déi eng effektiv Léisung fir dee selwechte Problem ass, ass esou:
SELECT *
FROM `docs`
WHERE id > 85000
LIMIT 10;
Fir dës Ufroen ze erfëllen, klickt einfach op de Knäppchen Run uewen op der Säit. Nodeems mir dëst gemaach hunn, vergläichen mir Informatioun iwwer d'Ufro Ausféierung Zäit. Et stellt sech eraus datt d'Ausféierung vun enger ineffektiver Ufro op d'mannst 30 Mol méi laang dauert wéi d'Ausféierung vun der zweeter (dës Zäit variéiert vu Laf zu Laf; zum Beispill kann de System mellen datt déi éischt Ufro 37 ms gedauert huet fir ze kompletéieren, awer d'Ausféierung vum zweet - 1 ms).
A wann et méi Daten gëtt, da gesäit alles nach méi schlëmm aus (fir dovunner iwwerzeegt ze sinn, kuckt op meng mat 10 Millioune Reihen).
Wat mir just diskutéiert hunn, sollt Iech e bëssen Abléck ginn wéi d'Datebankufroen tatsächlech veraarbecht ginn.
Maacht weg datt de Wäert méi héich ass OFFSET - wat méi laang d'Ufro dauert fir ze kompletéieren.
Wat soll ech benotzen amplaz vun der Kombinatioun vun OFFSET an LIMIT?
Amplaz vun enger Kombinatioun OFFSET и LIMIT Et ass derwäert eng Struktur ze benotzen no dem folgende Schema gebaut:
SELECT * FROM table_name WHERE id > 10 LIMIT 20
Dëst ass Ufro Ausféierung mat Cursor baséiert Pagination.
Amplaz déi aktuell lokal ze späicheren OFFSET и LIMIT a vermëttelt se mat all Ufro, musst Dir de leschte kritt primäre Schlëssel späicheren (normalerweis ass dëst ID) an LIMIT, Als Resultat ginn Ufroen ähnlech wéi déi uewe kritt.
Firwat? De Punkt ass datt andeems Dir den Identifizéierer vun der leschter Zeil gelies explizit spezifizéiert, sot Dir Är DBMS wou et muss ufänken no den néidegen Donnéeën ze sichen. Ausserdeem gëtt d'Sich, dank der Notzung vum Schlëssel, effizient duerchgefouert, de System muss net vu Linnen ausserhalb vum spezifizéierte Beräich ofgelenkt ginn.
Loosst eis de folgende Leeschtungsvergläich vu verschiddene Ufroen kucken. Hei ass eng ineffektiv Ufro.
Lues Ufro
An hei ass eng optimiséiert Versioun vun dëser Ufro.
Quick Ufro
Béid Ufroen ginn genau déiselwecht Quantitéit un Daten zréck. Awer déi éischt dauert 12,80 Sekonnen fir ze kompletéieren, an déi zweet dauert 0,01 Sekonnen. Fillt Dir den Ënnerscheed?
Eventuell Problemer
Fir déi proposéiert Ufromethod effektiv ze funktionnéieren, muss den Dësch eng Kolonn (oder Spalten) hunn, déi eenzegaarteg, sequentiell Indizes enthält, sou wéi en ganz Zuelen Identifizéierer. An e puer spezifesche Fäll kann dëst den Erfolleg bestëmmen fir sou Ufroen ze benotzen fir d'Geschwindegkeet vun der Aarbecht mat der Datebank ze erhéijen.
Natierlech, wann Dir Ufroen konstruéiert, musst Dir d'spezifesch Architektur vun den Dëscher berücksichtegen an déi Mechanismen auswielen, déi am beschten op existéierenden Dëscher funktionnéieren. Zum Beispill, wann Dir an Ufroe mat grousse Volumen vun Zesummenhang Donnéeën ze schaffen muss, Dir kënnt et interessant fannen Artikel.
Wa mir mam Problem konfrontéiert sinn e primäre Schlëssel ze fehlen, zum Beispill, wa mir en Dësch mat enger vill-zu-vill Relatioun hunn, dann ass déi traditionell Approche fir ze benotzen OFFSET и LIMIT, passt eis garantéiert. Awer seng Notzung kann zu potenziell luesen Ufroe féieren. An esou Fäll géif ech recommandéieren en auto-inkrementéierende primäre Schlëssel ze benotzen, och wann et nëmme gebraucht gëtt fir paginéiert Ufroen ze handhaben.
Wann Dir un dësem Thema interesséiert sidd - , и - e puer nëtzlech Materialien.
Resultater
D'Haaptconclusioun, déi mir zéien, ass datt, egal wéi eng Gréisst vun den Datenbanken mir schwätzen, et ëmmer néideg ass d'Geschwindegkeet vun der Ufro Ausféierung ze analyséieren. Hautdesdaags ass d'Skalierbarkeet vu Léisungen extrem wichteg, a wann alles richteg aus dem Ufank vun der Aarbecht op engem bestëmmte System entworf ass, kann dëst an Zukunft den Entwéckler vu ville Probleemer retten.
Wéi analyséiert an optiméiert Dir Datebank Ufroen?
Source: will.com