Salve, Habr! Tibi operam tuam praebeo translationem articuli
"Quomodo opus database relationis habet".

Cum ad databases relativas venit, adiuvare non possum quin aliquid deesse putem. Adhibentur ubique. Multae variae databases in promptu sunt, ex parvis et utilibus SQLite potenti Teradata. Sed pauci sunt articuli qui quomodo opera datorum exponunt. Te ipsum quaerere potes utens "howdoesarelationaldatabase" utens quam pauci eventus sint. Hi autem articuli breves sunt. Si quaeris technologias novas buzzy (BigData, NoSQL vel JavaScript), plura in profundis explicandis articulis invenies quomodo operantur.

An relationes databases nimis veteres et nimis taediose explicandae sunt extra cursus universitates, chartas et libros investigationum?

Ut elit, odio utendo aliquid non intellego. Et si plus quam 40 annos database adhibitae sunt, ratio habenda est. Per annos centum horas egi ut vere intellexerim has cistas nigras peregrinas quibus cotidie utor. Relations Databases valde interesting quia secundum utile et reusable conceptibus. Si curae datorum intelligendi, sed tempus vel inclinatio in hanc latitudinem non habuit, hoc articulo frui debes.

Licet titulus huius articuli explicite sit; Intentio huius articuli non est intelligere quomodo uti database. igitur iam scire debes scribere simplici nexu petitio et postulatio fundamentalis crud; aliter hunc articulum non intelligas. Id solum quod scire debes, reliqua expediam.

Incipiam cum aliquibus fundamentalibus scientiarum computatrorum, ut temporis complexionem algorithmorum (BigO). Scio nonnullos ex vobis hunc conceptum odisse, sed sine eo ambages intra datorum intelligere non poteris. Cum hic locus ingens sit; Et focus in quod cogito sit amet: quomodo processus database SQL inquisitionis. Et sicut inducere basic database conceptusut in fine articuli quid agatur sub cucullo notionem habes.

Cum hic sit longus et technicus articulus multum algorithmarum et notitiarum structurarum involvit, accipe tempus tuum perlegere. Quidam conceptus difficile possunt intelligere; eas saltare potes, et tamen communem rationem obtine.

Pro notioribus inter vos, hic articulus dividitur in 3 partes;

Overview of low-level and high-level database components
Overview of the Inquisitionis Optimizationis Processus
Overview of transaction and Buffer Pool Management

Ad Basics

Annos abhinc (in via galaxia, procul, procul...), tincidunt numerum operationum coding scire debebant. Noverunt suas algorithmos et structuras cordi datas quia CPU tabescere et memoriam machinarum tardarum suarum perdere non poterant.

In hac parte commemorabo te aliquas harum notionum quas essentiales datorum intelligendi. Ego quoque conceptum inducere database index.

O(1) vs.

Nunc, multae tincidunt tempus multiplicitatem algorithmorum ... non curant et recte!

Sed cum multam notitiarum partem (mille non loquor) vel si in milliseconds luctaris, criticum fit conceptum hunc intelligere. Et, ut credis, databases cum utraque condicione agere! Non faciam te amplius tempus consumere quam necesse est ut summam. Hoc adiuvabit nos intelligere notionem sumptus-substructio ipsum postea (pecunia secundum optimization).

conceptu

Tempus complexionem algorithmus solebant videre quousque tollet datam quantitatem data algorithmus exequi. Ad hanc multiplicitatem describendam, magna notatio mathematicorum utimur, haec notatio adhibetur cum functione quae describit quot operationes algorithmus indiget dato numero inputum.

Exempli gratia, cum dico "hoc algorithmus complexionem habet O(some_function())", significat algorithmus opus quoddam functionis (a_certo-datarum) operationum ad aliquid notitiarum processum.

haec Non est moles notitia rerum **, secus ** quomodo crescit numerus operationum cum volumine notitiarum crescentium?. Tempus multiplicitas non exactam numerum operationum praebet, sed modus est bonus ad tempus exsecutionis aestimandum.

In hoc grapho videre potes numerum operationum versus quantitatem input datarum pro diversis generibus algorithmi temporis complexionum. Solebam logarithmica scala ad eas proponendas. Aliis verbis, copia notitiarum celeriter augetur ab 1 ad 1 sescenti. Hoc videre possumus:

O (1) vel constans multiplicitas constans (alioquin non diceretur constans multiplicitas).
O(stipes(n)) manet humilis etiam billions notitia.
Pessimus difficultas - O (n2), ubi numerus operationum celeriter crescit.
Reliqua duo inpedimenta tam cito augent.

exempla

Cum parva notitiarum copia, differentia inter O (1) et O (n2) neglegenda est. Exempli causa, dicamus te habere algorithmum quod MM elementa procedere oportet.

O (I) algorithmus 1 operatione cost tibi
The O(log(n)) algorithm cost you 7 operations
O(n) algorithmus 2 res tibi periculo
The O (n* log(n)) algorithm cost tibi 14 operationes
O(n2) algorithmus 4 operationes constant tibi

Discrimen inter O (1) et O(n2) magnum videtur (4 milliones operationum) sed maximam partem 2 ms perdes, sicut tempus oculos tuos ictu. Immo processus moderni possunt procedere centies decies centena millia operationum per alterum. Inde est quod effectus et ipsum non sunt exitus in multis IT inceptis.

Ut dixi, adhuc interest scire hunc conceptum cum ingentes notitiarum copia laborat. Si hoc tempore algorithmus elementa 1 processus habet (quod non est multum pro database);

O (I) algorithmus 1 operatione cost tibi
The O(log(n)) algorithm cost you 14 operations
O (n) algorithmus res 1 tibi constabit
O (n* log(n)) algorithmus 14 operationes constant
O (n2) algorithmus 1 res tibi periculosa est

Matham non feci, sed vellem dicere cum algorithmo O(n2) tempus bibere capulus (vel duos!). Si aliud 0 volumen notitiae addideris, tempus habebis somnum capiendi.

Eamus altius

Quia notitia;

Bona mensa vultus detrahens elementum invenit in O (1).
Arbor bene librata explorans eventus efficit in O(log(n)).
Quaestio ordinata efficit eventus in O (n).
Optima algorithmorum voluptua complexionem habent O (n* log(n)).
Malum genus algorithmus complexionem habet O(n2).

Nota: In partibus sequentibus has algorithmos et structuras notitias videbimus.

Plura sunt genera algorithmi temporis multiplicitatis;

Mediocris causa sem
optimus causa sem
ac Maxime in re sem

Temporis multiplicitas saepe pessimus casus missionis est.

Modo de multiplicitate temporis algorithm loquor, sed de multiplicitate etiam dicendum est;

consummatio memoriae algorithmus
orbis I/O consummatio algorithmus

Nempe inpedimenta deteriora sunt quam n2, exempli gratia:

n4: hoc est terribile! Nonnulli algorithmi memorati hanc complexionem habent.
3n: hoc peius est! Unum algorithmorum videbimus in medio huius articuli, hanc multiplicitatem habet (et actu in multis databases ponitur).
factorial n: nunquam proventum tuum vel cum parva notitia habebis.
nn: Si hanc multiplicitatem offendas, te ipsum interroges si vere hic est tuus campus activitatis...

Nota: non tibi ipsam definitionem magni O designationis, ideae tantum. Hoc articulum legere potes Vicipaedia ad veram (asymptoticam) definitionem.

MergeSort

Quid agas, cum collectionem digerere debes? Quid est? Dicis quale() munus... Bene, bonum responsum... Sed pro database, intellegendum est quomodo huiusmodi opera functionis sint.

Sunt plura algorithmorum genera bona, sic ego maxime intendunt; merge sort. Cur notitia voluptua nunc utilis est, non potes cognoscere, sed ex interrogatione optimizationis partem debes. Praeterea, intellectus merge modi adiuvabit nos postea ut communi datorum opera iungatur quae vocatur confundantur join (consociatio merger).

Merge

Sicut multi utiles algorithms, merge modi innititur dolis: coniungendo 2 ordinatae magnitudinis N/2 in N-elementum digesta ordinata tantum N operationes constat. Haec operatio dicitur bus.

Quid hoc sit exemplo simplici videamus.

Haec figura ostendit quod ultimum digestum 8-elementum ordinatum aedificare, tantum opus est ut semel in 2 4-elementum vestit. Cum utrumque 4-elementum vestit iam digestus est;

I) utrumque current elementa in duobus vestit comparas (primo ineunte vena =)
II) tunc sume minimum unum, ut pone illud in 2 elemento ordinata
3) et move ad elementum proximum in acie ubi minimum elementum tulisti
et repete 1,2,3 donec ad ultimum elementum unius vestit.
Tunc reliqua elementa alterius ordinata sumas ut eas in 8 elemento ordinatas ponas.

Hoc operatur quia utraque 4-elementum vestit ordinantur et ideo non oportet "regredi" in illis vestit.

Nunc dolum intelligimus, hic me pseudocode pro confundit.

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 genus problema in minora problemata erumpit et deinde eventus minorum problematum ad exitum problematum originalis invenit (nota: hoc genus algorithmus vocatur dividere et vincere). Si hoc algorithmum non intelligis, ne cures; Non intellexi primum vidi. Si potest adiuvare vos, hunc algorithmum video sicut algorithmum duos;

Divisio Phase, ubi ordo in minores vestes dividitur
Voluptua tempus est ubi parvae vestes coniunguntur (unio utens) ut maiorem aciem instruant.

Division tempus

In divisione scaenae, ordo in una vestit in 3 gradibus distinguitur. Formalis numerus graduum est log(N) (ex quo N=8, log(N) = 3).

Quid novi est?

Genius sum! In verbo — mathematica. Idea est quod quilibet gradus quantitatem originalis ordinatae per dividit 2. Numerus graduum est numerus pluries quam originale ordinata in duos dividere potes. Haec est exacta definitio logarithmi (basis 2).

Genus tempus

In periodo voluptua, unitatem (singulum elementum) vestit incipere. Per singulos gradus multiplices operationes mergae applicas et summa totalis sumptus operationes N = 8 est;

In primo gradu habetis 4 migrationes quae constant 2 operationes singulorum
In secundo gradu habes 2 migrationes quae constant 4 operationes singulorum
In tertio gradu 1 merge habes quod constat 8 operationes

Cum sint log(N) gradus, totalis sumptus N * * iniuriarum (N) res.

commoda merge sort

Quid est hoc algorithmus tam potens?

Quod:

Mutare potes illud ad memoriam vestigium reducere ut novas vestes non crees sed input aciem directe mutare.

Nota: hoc genus algorithmus appellatur in-loco (Sine additional genus memoriae).

Mutare potes illud ut usus orbis tractus et memoriae parva copia simul sine notabili disco I/O supra caput. Idea est solum illarum partium quae nunc processerunt in memoriam onerare. Hoc magni momenti est cum opus est mensam multi- gigabytae exponere cum tantum quiddam 100-megabyte memoriae.

Nota: hoc genus algorithmus appellatur externum genus.

Mutare potes eam ut in pluribus processibus/stamina/servientibus persequaris.

Exempli gratia: merge distributus est unus e partibus clavis Hadoop (quae est structura in magna notitia).

Hoc algorithmus in aurum vertere potest (vere!).

Hoc genus algorithmus in plerisque databases (si non omnibus) adhibetur, sed non tantum unum est. Si plura scire vis, hoc legere potes investigationis opus, quae disserit pros et cons algorithms communes datorum voluptua.

Ordina, lignum et detrahe mensam

Nunc ut intelligimus temporis notionem multiplicitatis et voluptua, de 3 structuris data tibi dicam. Hoc magni momenti est quod sunt ex modern databases. Ego quoque conceptum inducere database index.

ordinata

Duo dimensiva ordinata est simplicissima notitia structura. Mensa ordinata cogitari potest. Exempli gratia:

Hic ordo dimensiva 2 est mensa cum ordinibus et columnis;

Linea quamque rem
Columnarum proprietates reponunt quae entitatem describunt.
Singulae columnae notae speciei specificae (integer, chorda, date ....).

Hoc opportunum est ad notitias recondendas et visualisandas, tamen cum certum valorem invenire debes, hoc non convenit.

Exempli gratia, si omnes guys qui in UK operantur invenire voluisti, singulos ordines inspicere debes ut utrum ille ordo ad UK pertineat. Hoc tibi N transactions periculoquibus N - quot lineae, quae non malae, sed celerius esse potuit via? Iam tempus est arbores cognoscere.

Nota: Plurimi moderni databases vestes extensas praebent ad mensas reponendas efficienter: cumulo ordinatis et indicem organizatis. Sed hoc problema non mutat condicionem certae condicionis in circulo columnarum cito inveniendi.

Lignum Database ac index

Lignum quaesitum binarium est arbor binaria cum proprietate speciali, clavis in unaquaque nodo debet esse;

maior omnibus clavibus in laevo subtree repositae
minus quam omnes claves iure subtree condita

Videamus quid hoc modo uisum

idea

Haec arbor N = XV elementa habet. 15 Dicamus me quaeritis;

Ad radicem cuius clavis est 136. Cum 136<208 incipiam, aspicio ad dextram subtriti nodi 136.
398>208 igitur laevam subtritam nodi 398 . intueor
250>208 igitur laevam subtritam nodi 250 . intueor
200 <208, igitur spectant ad dextram subtriti nodi 200. Sed 200 subtree ius non habet; valorem non est (quia si existit, erit in dextra subtree 200).

Nunc dicamus quaero 40

Incipio ad radicem cuius clavis est 136. Quia 136> 40, laevam subtree nodi 136 aspicio.
80 > 40, hinc ad laevam subtriti nodi 80 . quaero
40= 40; nodi exstat. Ordinem ID intra nodi (non in imagine monstratum) capio et in tabula pro ordine dato ID.
Sciens ordinem ID permittit me scire exacte ubi data est in tabula, ut statim eam recuperare possim.

In fine, utraque inquisitione numerus graduum intra arborem mihi constabit. Si partem de merge sorti diligenter legas, videas gradus esse log(N). Vertit ex, quaerere pretium iniuriarum (N), non malus!

Redeamus ad problema

Sed hoc est valde abstractum, ut ad problema revertamur. Loco simplicis integri finge chorda repraesentans regionem alicuius in priore tabula. Dicamus te habere arborem quae campum continet "terrae" (Col. 3) tabulae;

Si vis scire, qui operatur in UK
te respice in ligno ad nodi, quae significat Great Britain
intus "UKnode" situm in monumentis laborantis UK invenies.

Haec quaestio reddet stipes(N) operationes pro N operationibus si acie directe uteris. Quod tibi sicut praesentatum erat database index.

Lignum indicem aedificare potes cuilibet agrorum coetui (nervum, numerum, 2 lineas, numerum et chordas, diem...) dum munus habes ut claves comparare (id est coetus campi) sic possis ponere ut inter claves (quod fit cuilibet generum fundamentalium in datorum).

B+TreeIndex

Dum haec arbor bene operatur ad valorem specificum acquirendum, magna quaestio est cum opus est ut multa elementa inter duo values. Hoc O(N) periculo erit quod singulas nodos in arbore intueri debebis et si inter hos duos valores sit (exempli gratia cum traversali arbore ordinato). Haec autem operatio non est disci I/O amica quia totam arborem legere debes. Nos postulo ut efficaciter exequi range petitionem. Ad hanc quaestionem solvendam, moderni databases versionem modificatam superioris arboris, quae vocatur B+Arbor, utuntur. In B + Lignum:

imo lymphaticorum (folia) copia notitia (Locus ordines in tabula cognata)
reliqui Nodorum hic sunt ad excitandas ad rectam nodi per quaerere.

Ut vides, plures nodos hic sunt (bis). Profecto nodi additi "nodos decisionis" habes, qui adiuvabit ut rectam nodi invenias (quae situm ordinum in tabula coniungitur). Sed investigationis multiplicitas adhuc O(log(N)) (una tantum planior est). Magna differentia est Nodorum in inferiore gradu ad successores suos connexa sunt.

Cum hoc B + Arbor, si valores inter 40 et 100 quaeris;

Tu modo quaere 40 (vel valorem artissimum post 40 si 40 non exsistit) sicut cum priore arbore fecisti.
Deinde collige 40 heredes haeredes utentes nexus directi donec ad 100 perveneris.

Dicamus te successores M invenire et lignum N nodos habet. Inveniens nodi certum stipes (N) constat sicut arbor prior. Sed cum hanc nodi veneris, successores M in operationibus M cum suis successoribus habebis. Haec quaestio nonnisi M+ stipes (N) constat operationes comparatae N operationibus in ligno praecedenti. Praeterea arborem plenam (solum M+log(N) nodis) legere non debes, quod usus disci minus significat. Si M est parvus (eg 200 ordines) et N magnus est (1 ordines), magna differentia erit.

Sed novae hic quaestiones sunt (iterum). Si ordinem addas vel delebis in database (et ideo in B+Froe indice coniungitur):

ordinem tenere debes inter nodos intra lignum B+, aliter nodos intra lignum insitum invenire non poteris.
quam minimum possibile est servare numerum graduum in B+ Arbor, alioquin O (log(N)) temporis complexio fit O(N).

Aliis verbis, B+Agnum se disponere et aequare debet. Feliciter hoc possibilis est cum deletione et operationibus captiosis inserta. Sed hoc sumptum est: insertas ac deletiones in arbore B+ O(log(N)). Ideo quidam ex vobis audiverunt per etiam plures indices non est bona idea. Itane, vos es retardans ieiunium inserta / update / delete de ordine in mensapropterea quod datorum opus est ut indices mensae utentes pretiosam O(log(N))) operationem singulis indicem. Additis etiam indicibus plus inposuit for . transaction procurator descriptus erit in fine articuli.

Pro magis details, articulum Wikipedia on . videre potes B+Arbor. Si vis exemplum exsequendi B+Ligni in database, vide hoc articulum и hoc articulum ex ducens MySQL elit. Ambo intendunt quomodo InnoDB (in MySQL engine) indices tractat.

Nota: Lector dixit mihi, propter humili gradu optimizations, lignum B+ omnino libratum esse.

Hashtable

Ultima nostra structura notitia magni momenti est mensa Nullam. Hoc valde utile est, cum vis cito bona suspicere. Praeterea, mensa Nullam intelligens adiuvabit nos postea intelligere communem datorum iungere operationem nomine Nullam copulam ( Nullam join). Haec data structura adhibetur etiam a database ad aliqua interna reponenda (v.g. cincinno mensam aut quiddam piscinaeutrumque postea videbimus).

Mensa Nullam est structura data quae celeriter elementum per clavem invenit. Nullam mensam aedificare debes definire:

clavem propter elementa
Nullam munus for clavium. Clavis computata hashes locum elementorum dare (dicitur segments ).
munus in comparet claves. Cum segmentum rectam invenisti, elementum debes invenire quod quaeris intra segmentum hac comparatione utens.

Simple exemplum

Sit exemplum clarum:

Haec mensa Nullam 10 segmenta habet. Quia piger sum, 5 segmenta tantum pingi, sed scio te sapias, ut ego te 5 alterum fingas tuo. Usus sum functione detrahendae modulo 10 clavis. Aliis verbis tantum digitum ultimi clavis elementi elementis condo ut eius segmentum invenias;

si digitus ultimus sit 0, elementum in segmentum 0 cadit;
si digitus ultimus sit 1, elementum in segmentum 1 cadit;
si ultimum digiti est II, elementum cadit in area II,
...

Comparatio functionis qua usus sum est simpliciter aequalitas inter duos integros.

Dicamus vis 78 elementum obtinere;

Nullam tabellam 78, quae est VIII, numerat.
Tabula Nullam segmentum 8 spectat, et primum elementum invenit 78 .
Item LXXVIII illa refert ad vos
Quaerere constat solum res II (unum valorem Nullam computare et alterum elementum intra segmentum suspicere).

Nunc dicamus elementum uis 59;

Nullam tabellam 59, quae est VIII, numerat.
Mensa Nullam in segmento quaesita 9, elementum primum inventum est 99. Cum 99!=59, elementum 99 elementum validum non est.
Eadem logica utens, secundum elementum (9), tertium (79), ..., ultimum sumuntur (29) .
Elementum non inveni.
Quaestionis VII res pretium.

Nullam munus bonum

Ut vides, secundum valorem quaeris, pretium non est idem!

Si nunc functionem in modulo 1 clavis mutare (hoc est, ultimis 000 digitis sumens), specula secunda tantum 000 operationem constat, quoniam in segmento 6 nulla sunt elementa. Provocatio realis est invenire munus nullum bonum quod situlas creabit continens minimum numerum elementorum.

In exemplo meo, invenire facile munus bonum Nullam. Sed hoc est simplex exemplum, invenire bonum Nullam functionem difficilius cum clavis est;

linea (exempli gratia - cognomen)
2 lines (exempli gratia - cognomen et praenomen)
2 lines and date (exempli gratia - cognomen, praenomen et tempus nativitatis)
...

Nullam munus cum bono, Nullam mensam lookups cost O (1).

Nullam mensam ordinata nobis

Cur non utimur acie?

Hmm, bona quaestio.

Nullam in mensa potest esse parte loaded in memoriareliquaque membra in disco.
Ordinato spatio contiguo uti debetis in memoria. Si onerant magnam mensam Difficillimum est satis continua spatium invenire.
Ad mensam Nullam, clavem quam vis eligere potes (exempli gratia, nomen patriae et personae).

Pro maiori, potes legere articulum de JavaHashMapquae est efficiens tabulae detrahendae; non debes intelligere Javam notiones in hoc articulo opertas intelligere.

Source: www.habr.com

Quomodo Relational Databases Opus (Part 1)