Hey Habr! Ech presentéieren Iech d'Iwwersetzung vum Artikel
"Wéi funktionnéiert eng relational Datebank".

Wann et ëm relational Datenbanken kënnt, kann ech net hëllefen, datt eppes fehlt. Si ginn iwwerall benotzt. Et gi vill verschidden Datenbanken verfügbar, vun der klenger an nëtzlecher SQLite bis zu de mächtege Teradata. Awer et ginn nëmmen e puer Artikelen déi erkläre wéi d'Datebank funktionnéiert. Dir kënnt fir Iech selwer sichen mat "howdoesarelationaldatabasework" fir ze kucken wéi wéineg Resultater et ginn. Ausserdeem sinn dës Artikele kuerz. Wann Dir no de leschte buzzy Technologien sicht (BigData, NoSQL oder JavaScript), fannt Dir méi detailléiert Artikelen déi erkläre wéi se funktionnéieren.

Sinn relational Datenbanken ze al an ze langweileg fir ausserhalb vun den Universitéitscoursen, Fuerschungsaarbechten a Bicher z'erklären?

Als Entwéckler haassen ech eppes ze benotzen wat ech net verstinn. A wann Datenbanken fir méi wéi 40 Joer benotzt ginn, muss et e Grond sinn. Iwwer d'Joren hunn ech Honnerte vu Stonnen verbruecht fir dës komesch schwaarz Këschte wierklech ze verstoen déi ech all Dag benotzen. Relational Datenbanken ganz interessant well se baséiert op nëtzlech a reusable Konzepter. Wann Dir interesséiert sidd fir eng Datebank ze verstoen, awer nach ni Zäit oder Neigung hat fir dëst breet Thema ze verdéiwen, sollt Dir dësen Artikel genéissen.

Och wann den Titel vun dësem Artikel explizit ass, Den Zweck vun dësem Artikel ass net ze verstoen wéi d'Datebank benotzt. Dofir, Dir sollt scho wësse wéi Dir eng einfach Verbindungsufro a Basisufroen schreift RAW; soss kënnt Dir dësen Artikel net verstoen. Dat ass dat eenzegt wat Dir wësse musst, ech erklären de Rescht.

Ech fänken un mat e puer Informatik Basis, wéi Zäit Komplexitéit vun Algorithmen (BigO). Ech weess, datt e puer vun iech dëst Konzept haassen, awer ouni et wäert Dir d'Intricacies an der Datebank net verstoen. Well dëst e grousst Thema ass, Ech konzentréieren op wat ech mengen ass wichteg: wéi d'Datebank veraarbecht SQL Ufro. Ech stellen Iech just vir Basis Datebank Konzeptersou datt Dir um Enn vum Artikel eng Iddi hutt wat ënner der Hood lass ass.

Well dëst e laangen an techneschen Artikel ass, dee vill Algorithmen an Datestrukturen involvéiert, huelt Är Zäit fir duerch et ze liesen. E puer Konzepter kënne schwéier ze verstoen sinn; Dir kënnt se iwwersprangen an ëmmer nach déi allgemeng Iddi kréien.

Fir déi méi Wëssen ënner Iech, ass dësen Artikel an 3 Deeler opgedeelt:

Iwwersiicht vun niddereg-Niveau an héich-Niveau Datebank Komponente
Iwwersiicht vum Query Optimization Prozess
Iwwersiicht vun Transaktioun an Buffer Pool Management

Zréck op d'Grondlage

Virun Joeren (an enger Galaxis wäit, wäit ewech...), hunn d'Entwéckler genee missen d'Zuel vun den Operatiounen wëssen, déi se codéieren. Si woussten hir Algorithmen an Datenstrukturen aus Häerz well se sech net leeschte konnten d'CPU an d'Erënnerung vun hire luesen Computeren ze verschwenden.

An dësem Deel erënneren ech Iech un e puer vun dëse Konzepter well se wesentlech sinn fir d'Datebank ze verstoen. Ech wäert och d'Konzept virstellen Datebank Index.

O(1) vs O(n2)

Hautdesdaags këmmeren sech vill Entwéckler net ëm d'Zäitkomplexitéit vun den Algorithmen ... a si hu richteg!

Awer wann Dir mat vill Daten ze dinn hutt (ech schwätze net Dausende) oder wann Dir a Millisekonnen kämpft, gëtt et kritesch dëst Konzept ze verstoen. A wéi Dir Iech kënnt virstellen, mussen Datenbanken mat béide Situatiounen ëmgoen! Ech wäert Iech net méi Zäit verbréngen wéi néideg fir de Punkt duerchzeféieren. Dëst hëlleft eis d'Konzept vun der Käschte-baséierter Optimiséierung spéider ze verstoen (kascht baséiert akeef).

Konzept

Zäit Komplexitéit vum Algorithmus benotzt fir ze kucken wéi laang en Algorithmus dauert fir eng bestëmmte Quantitéit un Daten ze kompletéieren. Fir dës Komplexitéit ze beschreiwen, benotze mir grouss O mathematesch Notatioun. Dës Notatioun gëtt mat enger Funktioun benotzt déi beschreift wéivill Operatiounen en Algorithmus fir eng bestëmmten Unzuel vun Input brauch.

Zum Beispill, wann ech soen "dësen Algorithmus huet Komplexitéit O (some_function ())", heescht et, datt den Algorithmus Some_function (a_certain_amount_of_data) Operatiounen erfuerdert fir eng gewësse Quantitéit un Daten ze veraarbecht.

Sou Et ass net d'Quantitéit un Daten déi wichteg ass **, soss ** wéi d'Zuel vun den Operatiounen eropgeet mat der Erhéijung vum Datevolumen. Zäitkomplexitéit bitt keng exakt Zuel vun Operatiounen, awer ass e gudde Wee fir d'Ausféierungszäit ze schätzen.

An dëser Grafik kënnt Dir d'Zuel vun den Operatiounen versus de Betrag vun Inputdaten fir verschidden Aarte vun Algorithmus Zäitkomplexitéiten gesinn. Ech hunn eng logarithmesch Skala benotzt fir se ze weisen. An anere Wierder, d'Quantitéit un Daten klëmmt séier vun 1 op 1 Milliard, mir gesinn dat:

O (1) oder konstant Komplexitéit bleift konstant (soss géif et net konstant Komplexitéit genannt ginn).
O(aloggen(n)) bleift niddereg och mat Milliarden vun Daten.
Schlëmmst Schwieregkeet - O(n2), wou d'Zuel vun den Operatiounen séier wiisst.
Déi aner zwou Komplikatioune vergréisseren grad esou séier.

Beispiller

Mat enger klenger Quantitéit un Daten ass den Ënnerscheed tëscht O(1) an O(n2) vernoléisseg. Zum Beispill, loosst eis soen datt Dir en Algorithmus hutt deen 2000 Elementer veraarbecht muss.

Den O(1) Algorithmus kascht Iech 1 Operatioun
Den O(log(n)) Algorithmus kascht Iech 7 Operatiounen
Den O (n) Algorithmus kascht Iech 2 Operatiounen
Den O(n*log(n)) Algorithmus kascht Iech 14 Operatiounen
Den O(n2) Algorithmus kascht Iech 4 Operatiounen

Den Ënnerscheed tëscht O(1) an O(n2) schéngt grouss (4 Millioune Operatiounen) awer Dir verléiert maximal 2 ms, just Zäit fir Äert Aen ze blénken. Tatsächlech kënne modern Prozessoren veraarbecht ginn Honnerte vu Millioune Operatiounen pro Sekonn. Dofir sinn d'Performance an d'Optimiséierung net en Thema a villen IT Projeten.

Wéi gesot, et ass ëmmer nach wichteg dëst Konzept ze kennen wann Dir mat enorme Quantitéiten un Daten schafft. Wann dës Kéier den Algorithmus 1 Elementer muss veraarbecht (wat net sou vill fir eng Datebank ass):

Den O(1) Algorithmus kascht Iech 1 Operatioun
Den O(log(n)) Algorithmus kascht Iech 14 Operatiounen
Den O (n) Algorithmus kascht Iech 1 Operatiounen
Den O(n*log(n)) Algorithmus kascht Iech 14 Operatiounen
Den O(n2) Algorithmus kascht Iech 1 Operatiounen

Ech hunn d'Mathematik net gemaach, awer ech géif soen datt Dir mam O(n2) Algorithmus Zäit hutt fir e Kaffi ze drénken (och zwee!). Wann Dir en aneren 0 zum Datevolumen bäidréit, hutt Dir Zäit fir eng Schlof ze huelen.

Loosst eis méi déif goen

Fir ze referenzéieren:

Eng gutt Hash-Tabelle Lookup fënnt en Element am O (1).
Sich no engem gutt ausgeglachene Bam produzéiert Resultater am O(log(n)).
Sich no engem Array produzéiert Resultater am O(n).
Déi bescht Sortéierungsalgorithmen hunn Komplexitéit O(n*log(n)).
E schlechte Sortimentalgorithmus huet Komplexitéit O (n2).

Notiz: An de folgenden Deeler wäerte mir dës Algorithmen an Datestrukturen gesinn.

Et gi verschidden Aarte vun Algorithmus Zäit Komplexitéit:

Moyenne Fall Szenario
beschte Fall Szenario
an am schlëmmste Fall Szenario

Zäit Komplexitéit ass dacks de schlëmmste Fall Szenario.

Ech hunn nëmmen iwwer d'Zäitkomplexitéit vum Algorithmus geschwat, awer d'Komplexitéit gëllt och fir:

Erënnerung Konsum vun der Algorithmus
Scheif ech / O Konsum Algorithmus

Natierlech ginn et Komplikatioune méi schlëmm wéi n2, zum Beispill:

n4: dat ass schrecklech! E puer vun den ernimmten Algorithmen hunn dës Komplexitéit.
3n: dat ass nach méi schlëmm! Ee vun den Algorithmen, déi mir an der Mëtt vun dësem Artikel gesinn, huet dës Komplexitéit (an et gëtt tatsächlech a ville Datenbanken benotzt).
factorial n: Dir wäert ni Är Resultater kréien och mat enger klenger Quantitéit vun Donnéeën.
nn: Wann Dir dës Komplexitéit begéint, sollt Dir Iech froen ob dat wierklech Ären Aktivitéitsfeld ass ...

Notiz: Ech hunn Iech net déi tatsächlech Definitioun vun der grousser O Bezeechnung ginn, just eng Iddi. Dir kënnt dësen Artikel liesen op Wikipedia fir déi richteg (asymptotesch) Definitioun.

MergeSort

Wat maacht Dir wann Dir eng Sammlung sortéiere musst? Waat? Dir rufft der Zort () Funktioun ... Ok, gutt Äntwert ... Mä fir eng Datebank, Dir musst verstoen wéi dës Zort () Funktioun Wierker.

Et gi verschidde gutt Sortéierungsalgorithmen, also konzentréieren ech mech op déi wichtegst: fusionéieren Zort. Dir verstitt vläicht net firwat d'Sortéierungsdaten elo nëtzlech sinn, awer Dir sollt nom Ufrooptimiséierungsdeel. Ausserdeem, d'Verständnis vun der Fusiounssort hëlleft eis spéider déi gemeinsam Datebankverbindungsoperatioun ze verstoen fusionéieren anzeschreiwen (Fusiounsverband).

Fusioun

Wéi vill nëtzlech Algorithmen hänkt d'Fusiounssort op engem Trick: d'Kombinatioun vun 2 zortéierten Arrays vu Gréisst N / 2 an en N-Element zortéiert Array kascht nëmmen N Operatiounen. Dës Operatioun gëtt Fusioun genannt.

Loosst eis kucken wat dëst mat engem einfache Beispill bedeit:

Dës Figur weist datt fir déi lescht zortéiert 8-Element-Array ze bauen, musst Dir nëmmen eemol iwwer déi 2 4-Element-Arrays iteréieren. Well béid 4-Element Arrays scho sortéiert sinn:

1) Dir vergläicht béid aktuell Elementer an zwee Arrays (am Ufank aktuell = éischt)
2) huelt dann dee klengste fir se an eng 8 Elementarray ze setzen
3) a gitt op dat nächst Element an der Array wou Dir dat klengst Element geholl hutt
a widderhuelen 1,2,3 bis Dir de leschten Element vun engem vun den Arrays erreecht.
Dann huelt Dir déi verbleiwen Elementer vun der anerer Array fir se an eng 8 Element Array ze setzen.

Dëst funktionnéiert well béid 4-Element Arrays zortéiert sinn an dofir musst Dir net "zréckgoen" an dësen Arrays.

Elo wou mir den Trick verstinn, hei ass mäi Pseudocode fir Fusioun:

array mergeSort(array a)
   if(length(a)==1)
      return a[0];
   end if

   //recursive calls
   [left_array right_array] := split_into_2_equally_sized_arrays(a);
   array new_left_array := mergeSort(left_array);
   array new_right_array := mergeSort(right_array);

   //merging the 2 small ordered arrays into a big one
   array result := merge(new_left_array,new_right_array);
   return result;

Merge Sort brécht e Problem a méi kleng Probleemer an fënnt dann d'Resultater vun de méi klenge Probleemer fir d'Resultat vum urspréngleche Problem ze kréien (Notiz: dës Zort Algorithmus gëtt Divisioun an Erober genannt). Wann Dir dësen Algorithmus net versteet, maach der keng Suergen; Ech hunn et net verstanen déi éischte Kéier ech et gesinn hunn. Wann et Iech hëllefe kann, gesinn ech dësen Algorithmus als zwee-Phase Algorithmus:

Divisiounsphase, wou d'Array a méi kleng Arrays opgedeelt ass
D'Sortéierungsphase ass wou kleng Arrays kombinéiert ginn (mat der Unioun) fir eng méi grouss Array ze bilden.

Divisioun Phase

An der Divisiounsstadium gëtt d'Array an Eenheetsarrays an 3 Schrëtt opgedeelt. Déi formell Zuel vu Schrëtt ass Log (N) (zënter N = 8, Log (N) = 3).

Wéi weess ech dat?

Ech sinn genial! An engem Wuert - Mathematik. D'Iddi ass datt all Schrëtt d'Gréisst vun der ursprénglecher Array duerch 2 deelt. D'Zuel vun de Schrëtt ass d'Zuel vun de Mol, déi Dir d'Original Array an zwee deelt. Dëst ass déi exakt Definitioun vun engem Logarithmus (Basis 2).

Sortéierungsphase

An der Sortéierungsphase fänkt Dir mat Eenheeten (Eenzelelement) Arrays un. Wärend all Schrëtt applizéiert Dir verschidde Fusiounsoperatiounen an d'Gesamtkäschte sinn N = 8 Operatiounen:

An der éischter Etapp hutt Dir 4 Fusioune déi all 2 Operatiounen kaschten
Am zweete Schrëtt hutt Dir 2 Fusioune déi all 4 Operatiounen kaschten
Am drëtte Schrëtt hutt Dir 1 Fusioun déi 8 Operatiounen kascht

Well et Log (N) Schrëtt sinn, Gesamtkosten N * log(N) Operatiounen.

Virdeeler vun fusionéieren Zort

Firwat ass dësen Algorithmus sou staark?

Well:

Dir kënnt et änneren fir de Memory Footprint ze reduzéieren sou datt Dir keng nei Arrays erstellt, awer direkt den Input Array ännert.

Notiz: Dës Zort Algorithmus gëtt genannt in-Plaz (Sortéieren ouni zousätzlech Erënnerung).

Dir kënnt et änneren fir Disk Space an eng kleng Quantitéit un Erënnerung zur selwechter Zäit ze benotzen ouni bedeitend Disk I / O Overhead ze maachen. D'Iddi ass nëmmen déi Deeler an d'Erënnerung ze lueden, déi am Moment veraarbecht ginn. Dëst ass wichteg wann Dir e Multi-Gigabyte Dësch mat nëmmen engem 100-Megabyte Memory Buffer sortéiere musst.

Notiz: Dës Zort Algorithmus gëtt genannt extern Zort.

Dir kënnt et änneren fir op verschidde Prozesser / Threads / Serveren ze lafen.

Zum Beispill, verdeelt Fusiounssort ass ee vun de Schlësselkomponenten Hadoop (wat eng Struktur a Big Data ass).

Dësen Algorithmus kann Blei a Gold ëmsetzen (wierklech!).

Dëse Sortéierungsalgorithmus gëtt an de meeschten (wann net all) Datenbanken benotzt, awer et ass net deen eenzegen. Wann Dir méi wësse wëllt, kënnt Dir dëst liesen Fuerschung Aarbecht, déi d'Virdeeler an Nodeeler vun gemeinsamen Datebanksortéierungsalgorithmen diskutéiert.

Array, Bam an Hash Dësch

Elo wou mir d'Iddi vun der Zäitkomplexitéit an der Sortéierung verstinn, sollt ech Iech iwwer 3 Datestrukturen soen. Dëst ass wichteg well se sinn d'Basis vun modernen Datenbanken. Ech wäert och d'Konzept virstellen Datebank Index.

Array

Eng zweedimensional Array ass déi einfachst Datestruktur. En Dësch kann als Array geduecht ginn. Zum Beispill:

Dës 2-zweedimensional Array ass eng Tabell mat Reihen a Kolonnen:

All Linn stellt eng Entitéit duer
Kolonnen späicheren Eegeschaften déi d'Entitéit beschreiwen.
All Kolonn späichert Daten vun engem spezifeschen Typ (ganz Zuel, String, Datum ...).

Dëst ass bequem fir Daten ze späicheren an ze visualiséieren, awer wann Dir e spezifesche Wäert muss fannen, ass dëst net gëeegent.

Zum Beispill, wann Dir wëllt all Kärelen ze fannen, déi an de UK schaffen, Dir musst op all Zeil kucken fir ze bestëmmen ob dës Zeil zum UK gehéiert. Et kascht Iech N Transaktiounenwou N - Zuel vun de Linnen, wat net schlecht ass, awer kéint et e méi séier Wee ginn? Elo ass et Zäit fir eis mat de Beem kennenzeléieren.

Notiz: Déi meescht modern Datenbanken bidden erweidert Arrays fir Tabellen effizient ze späicheren: Heap-organiséiert Dëscher an Index-organiséiert Dëscher. Awer dëst ännert net de Problem fir séier e spezifeschen Zoustand an enger Grupp vu Sailen ze fannen.

Datebank Bam an Index

E binäre Sichbaum ass e binäre Bam mat enger spezieller Eegeschafte, de Schlëssel bei all Node muss sinn:

méi grouss wéi all d'Schlësselen, déi am lénksen Subtree gespäichert sinn
manner wéi all Schlësselen am richtege Subtree gespäichert

Loosst eis kucken wat dat visuell bedeit

Idea

Dëse Bam huet N = 15 Elementer. Loosst eis soen, ech sichen no 208:

Ech fänke bei der Wuerzel un, deem säi Schlëssel 136 ass. Zënter 136<208 kucken ech op de richtege Subtree vum Node 136.
398>208 dofir kucken ech de lénksen Ënnerbaum vum Node 398
250>208 dofir kucken ech de lénksen Ënnerbaum vum Node 250
200<208, dofir kucken ech de richtege Subtree vum Node 200. Awer 200 huet kee richtege Subtree, Wäert existéiert net (well wann et existéiert, wäert et am richtege Subtree 200 sinn).

Loosst eis elo soen, ech sichen no 40

Ech fänken un der Wuerzel, deem säi Schlëssel 136 ass. Zënter 136 > 40 kucken ech op de lénksen Ënnerbaum vum Node 136.
80 > 40, dofir kucken ech de lénksen Ënnerbaum vum Node 80
40 = 40, Node existéiert. Ech recuperéieren der Rei ID am Node (net am Bild gewisen) a kucken an der Tabell fir déi uginn Rei ID.
Wësse vun der Rei ID erlaabt mir genee ze wëssen wou d'Donnéeën an der Tabell sinn, sou datt ech se direkt zréckzéien.

Um Enn wäerte béid Recherchen mech d'Zuel vun den Niveauen am Bam kaschten. Wann Dir den Deel iwwer fusionéieren Zort virsiichteg liesen, Dir sollt gesinn, datt et Log (N) Niveauen sinn. Et stellt sech eraus, Sich Käschten Log (N), net schlecht!

Komme mer zréck op eise Problem

Awer dëst ass ganz abstrakt, also loosst eis zréck op eise Problem kommen. Amplaz vun engem einfachen Ganzt, stellt Iech eng String vir, déi d'Land vun engem an der viregter Tabell duerstellt. Loosst eis soen datt Dir e Bam hutt deen d'"Land" Feld (Kolonn 3) vun der Tabell enthält:

Wann Dir wëllt wëssen, wien an de UK schafft
Dir kuckt op de Bam fir den Node ze kréien deen Groussbritannien duerstellt
bannen "UKnode" fannt Dir de Standuert vun UK Aarbechter records.

Dës Sich kascht Log (N) Operatiounen amplaz N Operatiounen wann Dir d'Array direkt benotzt. Wat Dir just presentéiert war Datebank Index.

Dir kënnt en Indexbaum fir all Grupp vu Felder bauen (String, Zuel, 2 Zeilen, Zuel a String, Datum ...) soulaang Dir eng Funktioun hutt fir Schlësselen ze vergläichen (dh Feldgruppen), fir datt Dir astellen kënnt Uerdnung ënnert de Schlësselen (wat de Fall ass fir all Basistypen an der Datebank).

B + TreeIndex

Och wann dëse Bam gutt funktionnéiert fir e spezifesche Wäert ze kréien, gëtt et e BIG Problem wann Dir braucht kréien verschidde Elementer tëscht zwee Wäerter. Dëst wäert O(N) kaschten, well Dir musst all Node am Bam kucken a kucken ob et tëscht dësen zwee Wäerter ass (zB mat enger bestallter Traversal vum Bam). Ausserdeem ass dës Operatioun net Disk I/O frëndlech, well Dir musst de ganze Bam liesen. Mir mussen e Wee fannen fir effizient auszeféieren Gamme Ufro. Fir dëse Problem ze léisen, benotzen modern Datenbanken eng modifizéiert Versioun vum fréiere Bam genannt B + Tree. An engem B + Bam Bam:

nëmmen déi ënnescht Noden (Blieder) Buttek Informatiounen (Plaz vun de Reihen an der verwandter Tabell)
de Rescht vun de Wirbelen sinn hei fir Routing zum richtegen Node während der Sich.

Wéi Dir gesitt, ginn et méi Wirbelen hei (zweemol). Tatsächlech hutt Dir zousätzlech Wirbelen, "Decisiounsknäppchen", déi Iech hëllefen dee richtegen Node ze fannen (deen d'Plaz vun de Reihen an der assoziéierter Tabell späichert). Awer d'Sichkomplexitéit ass ëmmer nach O(log(N)) (et gëtt nëmmen een Niveau méi). De groussen Ënnerscheed ass dat Noden um ënneschten Niveau si mat hiren Nofolger verbonnen.

Mat dësem B + Bam, wann Dir no Wäerter tëscht 40 an 100 sicht:

Dir musst just no 40 sichen (oder den nootste Wäert no 40 wann 40 net existéiert) wéi Dir mam fréiere Bam gemaach hutt.
Da sammelt 40 Ierwen mat direkten Ierwe Links bis Dir 100 erreecht.

Loosst eis soen, Dir fannt M Nofolger an de Bam huet N Wirbelen. Fannt e spezifesche Node kascht Log (N) wéi de fréiere Bam. Awer eemol Dir dësen Node kritt, kritt Dir M Nofolger a M Operatiounen mat Referenzen op hir Nofolger. Dës Sich kascht nëmmen M+log(N) Operatiounen am Verglach zu N Operatiounen op der viregter Bam. Ausserdeem musst Dir net de ganze Bam liesen (nëmmen M+log(N) Noden), dat heescht manner Diskverbrauch. Wann M kleng ass (zB 200 Zeile) an N grouss ass (1 Zeile), da gëtt et e BIG Ënnerscheed.

Mee et ginn nei Problemer hei (erëm!). Wann Dir eng Zeil an der Datebank addéiert oder läscht (an dofir am verbonne B+Tree Index):

Dir musst Uerdnung tëscht den Wirbelen an engem B + Bam behalen, soss kënnt Dir d'Knuet net an engem ongesortéierte Bam fannen.
Dir musst déi minimal méiglech Unzuel vun Niveauen am B + Tree halen, soss gëtt d'O(log(N)) Zäitkomplexitéit O(N).

An anere Wierder, B + Tree muss selwer bestallt a equilibréiert sinn. Glécklecherweis ass dëst méiglech mat Smart Läschen an Insert Operatiounen. Awer dëst kënnt op Käschten: Insertiounen an Läschen an engem B+ Bam kaschten O(log(N)). Dofir hunn e puer vun iech dat héieren zevill Indexen benotzen ass keng gutt Iddi. Wierklech, Dir verlangsamt séier Insert / Update / Läschen vun enger Zeil an enger Tabellwell d'Datebank muss den Index vun der Tabell aktualiséieren mat enger deierer O(log(N)) Operatioun fir all Index. Ausserdeem bedeit d'Additioun vun Indexen méi Aarbechtsbelaaschtung fir Transaktioun Manager (gëtt um Enn vum Artikel beschriwwe ginn).

Fir méi Detailer, kënnt Dir de Wikipedia Artikel op B+Tree. Wann Dir e Beispill wëllt fir B + Tree an enger Datebank ëmzesetzen, kuckt weg dësen Artikel и dësen Artikel vun engem féierende MySQL Entwéckler. Si fokusséieren allebéid op wéi InnoDB (de MySQL-Motor) Indexen handhabt.

Bemierkung: E Lieser huet mir gesot datt wéinst nidderegen Niveau Optimisatiounen de B + Bam komplett ausgeglach sollt sinn.

Hastable

Eis lescht wichteg Datestruktur ass den Hash-Tabelle. Dëst ass ganz nëtzlech wann Dir séier Wäerter wëllt sichen. Ausserdeem, d'Verstoe vun engem Hash-Tabel hëlleft eis spéider eng gemeinsam Datebank-Joint-Operatioun ze verstoen, genannt Hash Join ( hash matmaachen). Dës Datestruktur gëtt och vun der Datebank benotzt fir e puer intern Saachen ze späicheren (z. Spär Dësch oder Puffer Pool, mir wäerte béid vun dëse Konzepter spéider gesinn).

En Hash-Tabelle ass eng Datestruktur déi séier en Element duerch säi Schlëssel fënnt. Fir en Hash Dësch ze bauen musst Dir definéieren:

Hiweis fir Är Elementer
hash Funktioun fir Schlësselen. Déi berechnen Schlësselhashen ginn d'Plaz vun den Elementer (genannt Segmenter ).
Funktioun fir Schlësselen ze vergläichen. Wann Dir de richtege Segment fonnt hutt, musst Dir dat Element fannen deen Dir am Segment sicht mat dësem Verglach.

Einfach Beispill

Loosst eis e kloert Beispill huelen:

Dësen Hash Dësch huet 10 Segmenter. Well ech faul sinn, hunn ech nëmmen 5 Segmenter opgestallt, awer ech weess datt Dir schlau sidd, also loossen ech Iech déi aner 5 eleng Foto. Ech hunn eng Hashfunktioun modulo 10 vum Schlëssel benotzt. An anere Wierder, ech späicheren nëmmen déi lescht Ziffer vum Schlëssel vum Element fir säi Segment ze fannen:

wann déi lescht Ziffer 0 ass, fällt d'Element an de Segment 0,
wann déi lescht Ziffer 1 ass, fällt d'Element an de Segment 1,
wann déi lescht Ziffer 2 ass, fällt d'Element an Gebitt 2,
...

D'Vergläichsfunktioun déi ech benotzt hunn ass einfach Gläichheet tëscht zwee ganz Zuelen.

Loosst eis soen datt Dir Element 78 wëllt kréien:

Den Hash-Tabelle berechent den Hashcode fir 78, dat ass 8.
Den Hash-Tabelle kuckt op Segment 8, an dat éischt Element dat et fënnt ass 78.
Si gëtt Element 78 fir Iech zréck
Sich kascht nëmmen 2 Operatiounen (eent fir den Hashwäert ze berechnen an deen aneren fir d'Element am Segment ze kucken).

Loosst eis elo soen datt Dir Element 59 wëllt kréien:

Den Hash-Tabelle berechent den Hashcode fir 59, dat ass 9.
Den Hash-Tabelle sicht am Segment 9, dat éischt Element dat fonnt gëtt ass 99. Zënter 99!=59 ass Element 99 kee valabelt Element.
Mat der selwechter Logik gëtt dat zweet Element (9), dat drëtt (79), ..., dat lescht (29) geholl.
Element net fonnt.
D'Sich kascht 7 Operatiounen.

Gutt Hash Funktioun

Wéi Dir gesitt, ofhängeg vum Wäert deen Dir sicht, sinn d'Käschte net déiselwecht!

Wann ech elo d'Hashfunktioun modulo 1 vum Schlëssel änneren (dat ass, déi lescht 000 Zifferen huelen), kascht déi zweet Lookup nëmmen 000 Operatioun well et keng Elementer am Segment 6 sinn. Déi richteg Erausfuerderung ass eng gutt Hash Funktioun ze fannen déi Eemer erstellt déi eng ganz kleng Unzuel vun Elementer enthalen.

A mengem Beispill, eng gutt Hash Funktioun ze fannen ass einfach. Awer dëst ass en einfacht Beispill, eng gutt Hash Funktioun ze fannen ass méi schwéier wann de Schlëssel ass:

String (zum Beispill - Familljennumm)
2 Zeilen (zum Beispill - Familljennumm a Virnumm)
2 Zeilen an Datum (zum Beispill - Familljennumm, Virnumm a Gebuertsdatum)
...

Mat enger gudder Hash-Funktioun kaschten Hash-Tabelle Lookups O(1).

Array vs Hash Dësch

Firwat net eng Array benotzen?

Hmm, gutt Fro.

Den Hash Dësch kann sinn deelweis an d'Erënnerung gelueden, an déi reschtlech Segmenter kënnen op der Scheif bleiwen.
Mat engem Array musst Dir kontinuéierlech Plaz an der Erënnerung benotzen. Wann Dir e groussen Dësch lued et ass ganz schwéier genuch kontinuéierlech Plaz ze fannen.
Fir engem hash Dësch, Dir kënnt de Schlëssel wielt Dir wëllt (Zum Beispill, Land an Persoun Familljennumm).

Fir méi Informatiounen, kënnt Dir den Artikel iwwer liesen JavaHashMap, wat eng effizient Ëmsetzung vun engem Hash-Table ass; Dir musst Java net verstoen fir d'Konzepter an dësem Artikel ze verstoen.

Source: will.com

Wéi Relational Datenbanken funktionnéieren (Deel 1)