fürtözött indexek
Fürtözött indexek 1 nem egy külön index típusát. Inkább ez a megközelítés az adatok tárolására. Részletek különböznek a különböző megvalósítások, de InnoDB fürtözött index valóban tartalmazza mind a B-fa-kód és a húr, hogy az azonos szerkezetű.
Ha a táblázat tetején épített fürtözött index, az index lapot az oldalak maguk tárolják sor. A „cluster” arra utal, hogy összhangba hasonló kulcsfontosságú tárolt értékek a környéken 2. Csak egy fürtözött index építhető az asztal fölött, mert lehetetlen, hogy ugyanazon a vonalon két helyen (de amely indexek versenyez több fürtözött indexe, ez lesz szó ebben a fejezetben).
Ami a végrehajtás a mutatók megfelelnek a tároló alrendszer, nem mindegyiket támogatja fürtözött indexek. Jelenleg csak dicsekedni solidDB és InnoDB. Ebben a részben fogunk beszélni csak a InnoDB, de a tárgyalt elveket, legalábbis részben, akkor lehet alkalmazni olyan tároló alrendszer, amely támogatja a fürtözött indexek most vagy a jövőben.
Ábra. 3.3 azt mutatja, hogyan bejegyzéseket található egy klaszter-index. Megjegyezzük, hogy a levél oldalakon is vonalak és csomópontok - csak indexelt oszlopok. Ebben a példában, egy indexelt oszlop tartalmazza egészek.
Néhány DBMS-ek lehetővé teszik, hogy kiválassza melyik index, hogy a klaszter, de abban a pillanatban sem a MySQL tároló alrendszer nem rendelkezik ezzel a képességgel. InnoDB klaszter adatait az elsődleges kulcsot. Ez azt jelenti, hogy „egy indexelt oszlop” ábrán. 3.3 egy oszlopra, amely egy elsődleges kulcs.
Ábra. 3.3. Elhelyezkedés bejegyzéseket a fürtözött index Ha nem határozza meg az elsődleges kulcsot, akkor InnoDB megpróbálja használni, ahelyett, hogy egy egyedi index, amely nem teszi lehetővé null értékeket. Ha az index nem létezik, InnoDB felismerni rejtett elsődleges kulcs az Ön számára, majd a klaszter az asztal rajta 1. InnoDB klaszterek a bejegyzések csak együtt az oldalon belül. Különböző oldalak hasonló kulcsfontosságú értékek lehetnek távol egymástól.
Az elsődleges kulcs klaszter néha javítja, esetenként jelentősen csökkenti azt. Így a döntés a csoportosítás kell tenni alapos megfontolás után, különösen, ha az asztal tároló alrendszer csere InnoDB néhány más, és fordítva.
A fürtözött adatok számos nagyon fontos előnye:
• tárolhat számos kapcsolódó adatot. Például, a végrehajtás a postafiók lehet fürtözött tábla oszlopon user_id, majd letölteni az összes üzenetet egy felhasználónak kell olvasni csak néhány oldalt a lemezről. Ha nem használja csoportosítás, minden üzenet lehet szükség egy külön lemez I / O
• Gyors hozzáférés az adatokhoz. A klaszter index tárolja az index és az adatok együtt egy B-fa szerkezet azonban kitermelése sorokat a klaszter index általában gyorsabb, mint a hasonló nem fürtözött index keresést.
• Foglalkoztató kiterjedő kódok kéréseket tudja szerezni az értéke az elsődleges kulcs a levél csomópont.
Ezek az előnyök jelentősen növeli a teljesítményt, ha megtervezzük a táblák és lekérdezések -fiókjukkal. Azonban fürtözött indexek, vannak hátrányai:
• Klaszterek jelentős javulást biztosít, ha a terhelés jellemzi nagyszámú I / O műveleteket. Ha az adatok kerül a memóriában, hogyan érheti el, hogy nem számít, majd fürtözött indexek nem hoz sok hasznot.
• Sebesség beillesztés műveletek erősen függ a feldolgozás érdekében. Beszúrása sorok megrendelést megfelelő elsődleges kulcs a leggyorsabb módja annak, hogy töltse be az adatokat a tábla InnoDB. Ha letölt egy csomó adatot más sorrendben, majd a végén a letöltés akkor van értelme, hogy átszervezi a táblát a OPTIMIZE TABLE paranccsal.
• frissítése fürtözött index oszlopok drága, mert InnoDB kényszerülnek minden sor frissített az új helyen.
• A táblázatok fürtözött index be új sorokat vagy elsődleges kulcs frissítést igényel sor mozgás vezethet felosztása az oldal. Ez történik, amikor a legfontosabb érték a sor, hogy sor került egy oldal tele adatokkal. Ahhoz, hogy illeszkedjen a vonal, a tároló alrendszer kényszerül ebben az esetben, hogy megtörje egy oldalra kettő. Mivel a felosztása a lap táblázat több helyet a lemezen.
• Teljes vizsgálat klaszter asztalok lassabb lehet, különösen, ha a húrok vannak csomagolva, kevésbé sűrűn tárolt vagy következetlen miatt hasítása oldalakon.
• Másodlagos (nem csoportos) indexek lehet a vártnál, mert az oszlop értékeit tárolja a levél csomópontok alkotják az elsődleges kulcs.
Ez azt jelenti, hogy közben a szekunder húr keresési index tároló alrendszer először meg kell találni azt levélcsomópont, majd a tárolt érték, ahol az elsődleges kulcsot találni rajta a húr is. Ez a kettős munka: két áthalad a B-fa egy helyett (InnoDB adaptív hash-index segít csökkenteni ezeket a veszteségeket).
Adatok összehasonlítása elhelyezés InnoDB és MyISAM
Különbségek a szervezet a fürtözött és nem fürtözött adatok elhelyezése, valamint bármilyen különbség az elsődleges és másodlagos indexek zavarhoz vezethet, és a váratlan. Fontolja meg, hogy az InnoDB és MyISAM fogja állítani az adatokat az alábbi táblázat tartalmazza:
CREATE TABLE layout_test (coll int NOT NULL, col2 int NOT NULL,
Tegyük fel, hogy 10 000 sor kerültek az asztalra. Az érték a elsődleges kulcs minden egyes sor beszúrva véletlenszerűen kiválasztunk az 1-től 10 000-Következő, optimalizálási végeztünk OPTIMIZE TABLE parancs. Más szóval, az adatok a lemezen tárolt optimálisan (töredezettségmentesített), de a vonal lehet elhelyezni véletlenszerű sorrendben. Elemei az oszlop col2 rendelt egy véletlen érték 1 és 100 között, így van egy csomó ismétli.
Forgalomba adatok MyISAM
A rendelkezésre álló adatok az alrendszer MyISAM könnyebb, így fogunk kezdeni vele. MyISAM tárolja az adatokat a lemezen abban a sorrendben, amelyben azokat be, az ábrán látható. 3.4.
Továbbá a sorok már adott nekik a számokat, a semmiből. Mivel húrok van egy fix méretű, MyISAM megtalálja bármelyikük által elmozdulása szükséges bájtok számát elejétől a táblázat (MyISAM nem mindig használ „sorszámok”, amely azt mutatja, attól függően, hogy a vonalak fix vagy változó méretű, ez az alrendszer tároló használ egy másik stratégia).
Ezzel az elrendezéssel az építőiparban az index nem okoz összetettségét. Mi illusztrálja ezt a segítségével szekvencia diagramok, elutasító ilyen fizikai tárgyak, mint például a lapok, és bemutatja az index csak a „csomópontok”. Minden egyes levél csomópont az index egyszerűen tartalmazhat a sor számát. Ábra. 3.5 ábra a elsődleges kulcs táblázatot.
Kihagytunk néhány részletet, mint az a tény, hogy az egyik a belső B-fa csomópont több belső gyermek csomópontok, de
Ábra. 3.4. A rendelkezésre álló adatok azonban a tábla MyISAM layout_test
Ábra. 3.5. Helyezzünk egy elsődleges kulcsot az asztalra layout_test MyISAM
Egy egységes értelmezése, amely az adatokat nem fürtözött tároló alrendszer nem lényeges.
Mit lehet mondani az index az oszlop col2? Van valami különleges? Kiderült, semmi - ez ugyanaz a kód, mint bármely más. Ábra. 3.6 ábra az index col2.
Ábra. 3.6. A szállás col2 oszlop index MyISAM táblákat layout_test
Tény, hogy a MyISAM nincs strukturális különbség egy elsődleges kulcsot vagy más indexet. Az elsődleges kulcs egy egyedi index, amely nem lehet üres elemzi az elsődleges.
A rendelkezésre álló adatok InnoDB
Alrendszer InnoDB ugyanazt az információt tárolja nagyon eltérő miatt klaszter szervezet. InnoDB létrehoz egy táblázatot ábrán látható. 3.7.
Ábra. 3.7. Helyezzünk egy elsődleges kulcsot a tábla InnoDB layout_test
Első pillantásra különösen különbségek ábrából. 3.5 nincs. De nézd közelebb és látni fogja, hogy az ábra a teljes táblázatot, nem csak az index. Mivel a fürtözött index InnoDB «van» az asztalon egy külön tároló húrok `MyISAM”, nincs.
Minden egyes levél csomópont a klaszter tartalmaz egy elsődleges kulcs index értéke és a visszaszorítás tranzakciós azonosító mutatót, amely felhasználja InnoDB tranzakciós támogatást és MVCC mechanizmust, és a többi oszlop (ebben az esetben, col2). Ha az elsődleges kulcs létrehozásakor oszlopon előtag, InnoDB tárolják együtt a többi, és a teljes értéke ebben az oszlopban.
Másodlagos indexek InnoDB nagyon különbözik a klaszter. Levélcsomópontokhoz másodlagos indexek a rendszer helyett áll „mutatókat húrok»elsődleges kulcs érték, ami jár, mint például«mutató”. Ez a stratégia csökkenti a szükséges munka a fenntartó a másodlagos index, amikor mozog a vonal vagy idején a felosztása az adatlap. Használja vanie elsődleges vonal kulcs értékei a mutató index mérete növekszik, de ez azt is jelenti, hogy a húr mozoghat InnoDB frissítése nélkül mutatókat is.
Ábra. 3.8 ábra az index col2 oszlopban a demonstrációs asztalra. Minden egyes levél csomópont tartalmaz az indexelt oszlopok (ebben az esetben csak a col2), majd elsődleges kulcs értékek (coll).
Ábra. 3.8. Elhelyezése egy másodlagos index a táblázat InnoDB layout_test
Ezek a diagramok szemléltetik a levél csomópontok B-fa index, de szándékosan kihagytuk a vonatkozó részleteket nem szárcsomóknál. Az egyes nem-levél csomópont az index B-fa InnoDB tartalmaz indexelt oszlopok plusz egy mutatót a következő-szintű csomópont (amely lehet akár egy nem-levél vagy levél csomópont). Ez vonatkozik minden indexek, mind csoportos és másodlagos.
Ábra. 3.9 ábra egy absztrakt ábrázolása a szervezet a táblázat InnoDB és MylSAM. Ez jól látható a különbség aközött, hogy az adatok és indexek vannak tárolva a két rendszer.
Ha nem érti a különbséget a klaszter és a klaszterhez nem tároló, és miért olyan fontos, ne aggódj. Ez világosabb lesz, ahogy többet, főleg a végén ezt a részt és a következő fejezetben. Ezek a fogalmak nagyon nehéz, és azok teljes megértéséhez időt vesz igénybe.
Sorok beszúrása érdekében az elsődleges kulcs InnoDB
Ha ön használ InnoDB és akkor nem kell semmilyen konkrét csoportosítás, érdemes meghatározni egy helyettesítő kulcs, hogy az elsődleges kulcs, amelynek értéke nincs közvetlen kapcsolatban az adatokat az alkalmazás. Általában a legegyszerűbb módja az, hogy egy oszlopot a AUTO_INCREMENT attribútumot. Ez biztosítja, hogy
Ábra. 3.9. A fürtözött és nem fürtözött tábla a mező értékét, amelyre az elsődleges kulcs épül ez a monoton növekszik, ami viszont jobb kapcsolat biztosítható teljesítményét az elsődleges kulcsot.
Ez jobb elkerülni random (nem egymást követő) klaszter kulcsokat. Például, a használata UUID értéke egy rossz választás a teljesítmény: ez teszi a behelyezés fürtözött index véletlen, ami a legrosszabb forgatókönyv, és nem vezet a hasznos adatokat csoportosítás.
A bemutató kedvéért végeztünk teljesítmény tesztek a két helyzetben. Az első esetben, a behelyezés az asztal UserInfo a egész szám azonosító meghatározása a következő:
CREATE TABLE UserInfo (
id int unsigned NOT NULL AUTO_INCREMENT,
név varchar (64) NOT NULL DEFAULT "
email varchar (64) NOT NULL DEFAULT '',
jelszó varchar (64) NOT NULL DEFAULT '',
dob időpont DEFAULT NULL,
cím varchar (255) NOT NULL DEFAULT '',
város varchar (64) NOT NULL DEFAULT '',
state_id tinyint unsigned NOT NULL DEFAULT '0'
zip varchar (8) NOT NULL DEFAULT '',
country_id smallint unsigned NOT NULL DEFAULT '0'
nem ( 'M', 'F') NOT NULL DEFAULT 'M',
account_type varchar (32) NOT NULL DEFAULT '',
Ellenőrzött tinyint NOT NULL DEFAULT '0'
allow_mail tinyint unsigned NOT NULL DEFAULT '0'
parrent_account int unsigned NOT NULL DEFAULT '0'
closest_airport varchar (3) NOT NULL DEFAULT '',
Egyedi kulcs (email),
KEY country_id (country_id),
KEY state_id (state_id),
KEY state_id_2 (state_id, város, cím)
Ügyeljen arra, hogy az automatikus növelésével egész elsődleges kulcs.
A második táblázat, userinfo_uuid, azonos UserInfo asztal, azzal az eltéréssel, hogy az elsődleges kulcs az UUID helyett egész:
CREATE TABLE userinfo_uuid (UUID varchar (36) nem nulla,
Megvizsgáltuk a két asztal. Először is, mindegyikbe millió sort a szerveren, ami elég memória tartalmaz indexek. Ezután rakjuk hárommillió sort ugyanannál az asztalnál, és ez növelte az indexek, így már nem fér a memóriába. Táblázat. 3.2 összehasonlítását mutatja a vizsgálati eredmények.
Megjegyzés: Ha az elsődleges kulcs típusa UUID nemcsak beszúrni sorokat tovább tartott, de a mérete az index jelentősen emelkedett. Ennek egyik oka a nagy méret az elsődleges kulcsot, de természetesen szintén az volt a hatása felosztása oldal, amely abból ered, ez a széttagoltság.
3.2 táblázat. beillesztjük a vizsgálati eredmények a táblázat sorait InnoDB
Ahhoz, hogy megértsük, miért van ez így, nézzük meg, mi történt az index, amikor beszúrni adatok az első táblázatban. Ábra. 3.10 Látható beillesztett vonal kezdetben töltve egyik oldalon, majd lépni a következő.
Ábra. 3.10. Behelyezése egymást követő index értékek fürtözött indexet az alábbi ábra. 3,10, InnoDB tárolja az új bejegyzést követően azonnal az előzőt, mert az elsődleges kulcs értékek összhangban. Ha a kitöltési tényező, az oldal eléri a maximális értéket (InnoDB kezdeti töltési tényező 15/16, hogy teret jövőbeni módosításokat), a következő bejegyzés kerül az új oldalra. Miután a végén egy progresszív letöltés oldalának adatok szinte tele rendelt bejegyzés, ami nagyon kívánatos.
Egészen más történt, amikor beszúrni adatok a második táblázatban a fürtözött index oszlopon, amely tartalmazza a UUID (ábra. 3.11).
Mivel az elsődleges kulcs értékét minden következő sorban nem feltétlenül nagyobb, mint az előző, a InnoDB nem mindig befogadni az új vonal végén az index. Azt kell keresni a megfelelő helyzetbe vonal - átlagosan valahol a közepén, a rendelkezésre álló adatok - és a szabad hely rá. Ez okozza a nagy mennyiségű extra munkát, és vezet az optimálistól elhelyezése adatokat. Íme egy összefoglaló hátránya:
Ábra. 3.11. Beírása nem egymást követő index értékek egy fürtözött index
• Az oldal, amely érintette a vonalat, ez lehet hagyni a lemezt, és eltávolítják a cache, akkor InnoDB meg kell találni, és olvasni a lemezről, mielőtt be egy új sort. Ez vezet a sok véletlenszerű I / O műveleteket.
• InnoDB néha meg kell lebontani az oldalt, hogy helyet adjon az új vonalak. Ez magában foglalja a mozgó nagy mennyiségű adat.
• Mivel a felosztása a lapok tele vannak véletlenszerűen és lazán, ami gyakran vezet töredezettség.
A betöltés után az ilyen véletlen értékek fürtözött index érdemes futtatni az OPTIMIZE táblázat, amely újjáépíti az asztalra, és töltse ki az oldal optimális.
A történet tanulsága az, hogy ha az InnoDB kell törekedni behelyezése adatait, hogy az összhangban áll az elsődleges kulcsot, és próbálja meg használni a klaszter kulcs, monoton növekszik az új vonalak.