Terveztem egy MariaDB adatbázist, aminél megpróbáltam ügyelni, hogy a táblák minél konzisztensebbek legyenek. Szerencsére az Oracle adatbázis modellezője jó társam volt ebben. Magas szinten lehet vele tervezni, de megengedi, hogy a fizikai táblák generálása után is módosítsuk az eredményt.
Elkészítettem a terveket, beimportáltam a nagy halom szöveges állományt, még dokumentációt is írtam. Tényleg mindent úgy csináltam, ahogy ebben a könyvben írták.
Azután magára hagytam...
Kicsivel több, mint egy év után az adatbázist frissíteni kellett, és ennek kapcsán újból felvettem a fonalat. Először is érdekes táblák jelentek meg, "new" prefixszel. Semmivel nem tudtak többet, mint a régiek, csak egy új oszlop volt bennük. De a legtöbb fejtörést egy kriptikus tábla okozta. A szerepe az volt, hogy gyorsítson egy lekérdezést, ami a sok tábla join miatt lassú volt. Volt benne egy azonosító mező, de az nem derült ki, hogy mit azonosít. Legalábbis egyetlen másik táblának az azonosítójának sem lehetett megfeleltetni. Volt még egy furcsa összeg is benne, ami viszont különbözött a "lassú" lekérdezésből származó összegtől, jóllehet igen erős korrelációt mutatott azzal. Természetesen ez sehol nem volt leírva és senki nem emlékezett, hogyan is készült.
Az adatbázishoz tartozó weboldal kódjából jöttem rá, hogy egyáltalán mit tartalmaz. Az azonosító két másik tábla elsődleges kulcsának a konkatenálása volt. A kódból viszont egy további furcsaság is kiderült. Nem értettem, miért kellett a konkatenálás előtt az egyik azonosítóhoz 100-t adni. Aztán rájöttem. Mivel az azonosító egytől 270-ig ment, azzal, hogy 100-t adtak hozzá, biztosították, hogy az első három szám minden esetben az első tábla azonosítója legyen.
Okos ötlet, de teljesen felesleges. Megkérdeztem miért volt erre szükség és a válasz az volt, hogy azt olvasták, "egyben kell indexelni, mert az gyorsabb". Ez bizonyos esetekben igaz, de az adatbázis kezelő ezt megcsinálja nekünk, nem kell okosabbnak lennünk:
CREATE INDEX index_name ON table_name (field1, field2)
Ez az "egyben indexelés".
Ugyan így, ha új mezőre van szükségünk, nem kell új táblát készíteni. De ha mégis új táblát készítünk, akkor a régire nincs szükség. Le lehet törölni. De akadtak döglött táblák is, amelyeket egyetlen lekérdezés sem használt.
Összeszedtem az összes adatbázis anekdotát - mert természetesen rendes dokumentáció sem volt - és leírtam. Átterveztem pár táblát, hogy ne legyen szükség a "new" kötőszóra, és ismét beimportáltam mindent. Illetve egy kicsit importáltam, egy kicsit kurkásztam a hibaüzeneteket, mert bár az importálandó adatok formátuma nem változott (legalábbis ezt állították), a gyakorlatban minden második fájl egy kicsit másmilyen volt.
Természetesen sok olyan hibát is észrevettem ami már a korábbi fájlokban is megvolt, nekem akkor mégsem tűntek fel. Ekkor ismét vissza kellett menni a modellező programba és módosítani a mezők típusát.
Végül az adatok viszonylag gyorsan be is jutottak az adatbázisba. Elkezdtem készíteni az indexeket. Az egyik nagyon lassan készült. Másnap már gyanús volt, hogy még nincs kész. A furcsaságok sorát tovább növelte, hogy az adatbázis szerver szinte nem is használt processzor időt.
Szerencsére a futó lekérdezéseket meg lehet nézni:
show full processlist;
A MariaDB sajátsága, hogy a process oszlopban mutatja, hány százaléknál tart a folyamat. Rendkívül hasznos dolog. Kiderült, hogy ez bizony állt! El nem bírtam képzelni, mi lehet a baj. Olyan volt, mint amikor egy konzolos program bemenetre vár. Ebből a megfontolásból megkerestem, hol tárolja az adatbázis a fájlokat. Mint kiderült, egy külön partíción voltak, amin nem volt szabad hely.
Megszámlálhatatlan mysql-bin.xxx fájl volt benne. Mint megtudtam, ezek bináris naplófájlok, jó része tavaly januári volt. Úgy döntöttem, nincs rájuk szükség. Rövid keresgélés után kiderült, hogy ezeket könnyen el lehet távolítani:
PURGE BINARY LOGS BEFORE DATE(NOW());
Amint felszabadult a hely, az index készítés azonnal beindult. Érdekes, nem volt semmi hibaüzenet, a rendszer türelmesen várta, hogy a probléma megoldódjon.
