Andris Reinman

Olen juba üle kuu olnud Tallinna Ülikooli IT Juhtimise magistriõppes, õppekava sisaldab muuhulgas ka mitmeid juhtimis ja strateegia alaseid aineid. Igatahes, täna üht vastavat loengut kuulates meenus mulle asjakohane näide, kuidas uus tulija, uute ja selgelt paremate tehnoloogiatega, seniseid parimaid praktikaid hüljates, võib tugevalt muuta ja mõjutada juba väljakujunenud ja ennast tõestanud turgu.

Milles küsimus?

Nimelt näide, kuidas Google oma GMail nimelise teenusega muutis veebipõhist e-mailindust.

Traditsiooniline veebipõhine e-posti klient (mail.ee, hot.ee jne) töötab lihtsalt vahekihina mailiserveri ja kasutaja vahel. Täpselt samamoodi nagu töölaua e-posti kliendid, mis suhtlevad serveriga läbi IMAP või POP3 vormingu, töötavad ka veebipõhised e-maili teenused.

Reeglina käib see järgnevalt. E-kiri tuleb läbi SMTP protokolli saatjalt mailiserverisse ning salvestatakse kasutaja kausta. Kasutaja logib veebilehitsejas oma kasutajatunnusega e-posti kontole sisse ja näeb saabunud e-kirja ja saab seda lugeda.

Tegelikkuses annab kasutaja sisse logides lihtsalt oma kasutajatunnused veebiserveris olevale skriptile, too ühendab ennast mailiserveri külge (reeglina IMAP, kuna see võimaldab arvet pidada loetud/lugemata kirjade üle, pluss kaustade haldus) ja kuvab mailiserverilt saadud nimekirja postkastist. Kasutaja klikib mõnel e-kirjal, veebiserveris skript võtab uuesti mailiserveriga ühendust ja pärib sellelt vastava e-kirja kasutajale kuvamiseks.

Probleemid

Kasutatavad protokollid (POP ja IMAP) on juba aastakümneid vanad ja seega end tõestanud, usaldusväärsed vahendid. Samas aga seesama vanus osutub prototkollide konnasilmaks - nad on arendatud ajal, kui emailid olid peamiselt tekstipõhised ja seega mahult väikesed. Tänapäeval aga, kui pannakse kirjadele kaasa äsja digifotokast võetud 5MB pildifaile võib protokoll kitsaks jääda.

Suureks probleemiks on kirjade kustutamine

Kuna traditsioonilised veebipõhised e-posti teenused (mail.ee jne) pakuvad kasutajatele väga väikest kettaruumi (näiteks 10MB) ja tehnoloogilistel põhjustel polegi võimalik väga palju suuremat pinda pakkuda - kasutaja failid peavad asuma ühes kaustas ja seega ühel kettal serveris, aga kunagi pole teada, palju mingi klient ketast tulevikus täpselt kasutab - siis kustutatakse kirju pidevalt.

Kui kirjad olid suuruses 1-2 kilobaiti, ei olnudki kustutamine väga aktuaalne. Sellisel juhul mahub kirju postkasti päris palju. Kui aga potsatab sinna üks kiri 5MB pildifailiga, on postkast kiirelt täis. Kui meenutada veel hiljaaegset hotmail.com 2MB piirangut, siis tundub see isegi naeruväärne, antud postkasti ei mahuks ükski “moodne” fail ära, ei pilt ega suurem Wordi dokument.

Seega kirjad kustutatakse kiirelt. Igasugune failide kustutamine kettalt aga fragmneteerib selle kiirelt. Windowsi kasutajad teevad aegajalt oma arvuti kõvakettale defragmendi, aga serveri ketastel, kus on igal suvalisel hetkel sisse kirjutatud suur hulk kasutajaid, on see võimatu. Tulemuseks on fragmenteerunud kettad ja see omakorda tähendab kõvaketta aeglustumist - iga faili lugemiseks tuleb teha mitu tiiru, osa faili on võbolla ketta alguses, aga teine pool on kuskil lõpus.

Kettad on raskesti koormatud (mh. risk füüsiliste kettavigade tekkeks (rohkem liikumist) ja seega on tarvis soetada kallimaid kettaid) ning kasutajad on kindlas kettas kinni, kuna nende e-posti konto failid asuvad ühes kohas. Kunagi oli tore, aga täna on probleemne.

Gmaili lahendus

Gmaili erilisus ei tulene sugugi heast kasutajaliidesest, see kõigest kiirendas muutusi - tõeline revolutsioon toimus Gmaili tulekuga aga e-posti hoidmisega serveris. Nimelt on Gmail-i puhul protsess järgmine: Gmail võtab emaili sisse, indekseerib selle otsingu jaoks ning asetab selle (nb! pakitud kujul ehk et ruumisäästlikult) hetkel sobivasse serverisse, sobivale kõvakettale.

Kui nüüd Gmaili kasutaja logib oma kontole sisse, siis keskserver võtab ette nimekirja kasutaja e-kirjadest ja vaatab, kus mingi kiri asub. Kui kasutaja tahab kirja lugeda, tõmmatakse kirja andmed soovitud serverist, pakitakse lahti ja näidatakse kasutajale.

Kuna kirjad ei pea asuma füüsiliselt samas kohas, saab kasutaja postkast olla suvalise suurusega, kasvõi praegu jagatava 7 GB suurune. Kuna kettad pole niivõrd fragmenteeritud ja ei saa suurt füüsilist koormust - kiri asub alati ühes kohas, ketta pea hakkab lugema algaadressilt A ning lõpetab aadressil B ilma vahepeal ringi hüppamata - saab kasutada ka odavamaid kettaid.

Kirja kustutades märgib Gmail selle lihtsalt andmebaasi kirjena kustutatuks, reaalselt jääb kiri alles. Faile (sh. ka kirju) hoitakse Google failisüsteemis (GFS) (mitte nagu näiteks Windowsi puhul NTFS või FAT), mille omaduseks on hoida faile 64MB kogumitena. Kui üks selliste failide kogu koosneb failidest, mis on kõik kustutatuks märgitud, kustutakase ka see kogum ning vabatatakse ruum uuele. Ehk et ei kustutata mitte kunagi kettalt suvalise pikkusega faili, vaid alati kindel suurus, 64MB. Seega ei saa tekkida ka ketta fragmentatsiooni.

Kokkuvõte

Niikaua kuni Eesti e-maili pakkujad ei hakka kasutama sarnast tehnologiat, jäävad tasuta postkastid vähemalt mainstream pakkujatel igaveseks 10MB suuruseks (alternatiivsed pakkujad võivad ka suuremaid mahtusid pakkuda, aga kohe kui nad muutuvad mainstream pakkujaks, ei tule sellest enam midagi välja - mahud kasvavad liiga suureks).

Ilmselt seda aega aga ei tule - ise oleks vastava tehnoloogia arendamine raske, sisse osta aga kallis. Pealegi puudub selleks motivatsioon - kõik ju toimib niisamagi.

Momendi kõige populaarsemaks andmebaasiks võib tõenäoliselt pidada vabavaralist MySQL andmebaasi. Muidugi on sellel andmebaasil omad oponendid, viidates, et tegu pole tegelikult üldse andembaasiga, MySQL on lihtsalt üks vahekiht “päris” andmebaasi ja kasutaja vahel. Reaalselt pole see aga oluline, enamus MySQL-i kasutajatest ei taha sellest mis “kasti sees” toimub midagi teada ning jätavad filosoofilised küsimused selle ala ekspertidele.

Kui aga rääkida probleemist lähemalt, siis paljud MySQL-i peale tehtud PHP rakendused - külalisteraamatud, blogid, infosüsteemid - kasutavad oma andmete esitamiseks UTF-8 kodeeringut. Põhjus on ka lihtne, sel viisil pole vaja muretseda näiteks kirillitsa ning “õ” tähe koos kuvamise pärast. Kuna UTF-8 on piisavalt mahukas (vähemalt Lääne sümbolite jaoks, Aasia hieroglüüfidega tekib juba probleeme), siis mahutab ta väga kenasti ära nii ladina-, kirillitsa-, kui täpitähed.

PHP puhul saab UTF-8 määrata veebilehele kahte moodi. Esiteks PHP koodiga

Header("Content-type: text/html; Charset=UTF-8");

Või teise variandina seesama HTML meta-tag’i abil

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Teoorias on kõik ilus, praktikas aga teevad algajad kõike veebis leiduvate tutorialide abil. Need aga tavaliselt arvestavad vaid ingliskeelsete sümbolitega ja seega ladina tähestikuga. Selle esitamiseks kõlbab kõigest Latin-1 ehk ISO-8859-1 kodeeringust ja see on ka MySQL tabelite vaikimisi kodeering.

Ja siit kerkibki algajatel veebiprogrammeerijatel esmalt triviaalsena paistev probleem - andmed on MySQL tabelis salvestatud vales kodeeringus. Veebilehel on Content-type: UTF-8. Ja kui inimene midagi mõnda vormi sisestab ja “Salvesta” nupule vajutab, liiguvad andmed serverisse UTF-8 kujul. Edasi salvestatakse need täpselt samamoodi MySQL-i tabelisse. Aga tabel on Latin-1.

Milles on siis lõpuks küsimus? Kui me võtame Latin-1 tabelist andmed ja esitame need uuesti veebilehel, on ju kõik korrektne, veebilehele läheb ju ikkagi UTF-8. Ainus probleemi avaldumiskoht on, kui vaatame phpMyAdmin või muud sarnast tööriista kasutades andmebaasi sisse ja näeme seal näiteks “ä” tähe asemel arusaamatut kombinatsiooni “ä”.

Mida me sellest tabelist ikka niiväga vahime, tahaks küsida, peaasi, et see “ä” veebilehel korrektne oleks. Ja see on täiesti õige. Kõige olulisem on, et veebileht korras oleks. Asi kisub imelikuks aga juhul, kui meil on vaja nende andmetega midagi ette võtta. Näiteks sorteerida või eksportida/importida.

Probleem

Fulltext indeksi ning LIKE %% päringu puhul võib selline kodeerimisviga üsna kiirelt saatuslikuks saada - täpitähtedega andmeid lihtsalt ei leita üles. Viga ilmneb peamiselt asjaolus, et tekstiotsingus konverteeritakse mõlemad pooled, nii “heinakuhi” kui “nõel” ühte vormingusse, näiteks kõik tähed muudetakse suurtähtedeks. Kuna tekstivõrdlus on tõstutundlik, AEG!=aeg, aga leida tahetakse tähenduse, mitte vormi järgi, siis on see oluline samm.

Kuidas aga muuta suurtäheks “ä” ehk sümbolite jada “ä”? Õige vastus oleks “Ä”, reaalsus aga on “ä”. Kui ä täht on heinakuhjas ja nõelas eri tõusuga (n: tekstis “Ärkasin vara”, otsing “ärkasin”), siis otsing tulemusi ei anna. Samuti ei anna tulemust MySQL-i tekstifunktsioonid. Näiteks võtame igast väljast esimese tähe ja siis opereerime selle infoga. Ä-ga algava sõna esimene täht oleks hoopis “Ô. Sama oleks ka öüõ tähtede puhul. Ja vastuse PHP poolele saanult, ei suuda me kuidagi enam tuletada, et mis tähega tegelikult tegu oli.

Teine asi on andmete import. Kui me näiteks phpMyAdmin export/import funktsioone kasutades üritame andmebaasi tabeleid kuhugi mujale ümber tõsta, avastame üllatuslikult veebisaiti vaadates, et kõik täpitähed on valesti - mis juhtub, on et tähed kodeeritakse topelt ümber ja edaspidi hakkab Latin 1 vaates ä täht välja nägema juba nii: “ä”.

Lahendus

Lahendus on lihtne - tuleb kodeering õigeks seada. Esiteks tuleb jälgiida, et andmebaasi tabeli kõik tekstiväljad oleks märgitud utf8 kodeeringusse, näiteks utf8_unicode_ci. Mõistlik oleks panna see ka andmebaasi vaikimisi kodeeringuks, siis tabelite lisamisel on see kohe korras.

Teiseks tuleb peale andmebaasiga ühendumist määrata ära, et edaspidi tegeleme justnimelt UTF-8 tekstiga. PHP 5-s on selle jaoks vastav funktsioon (selle võiks panna kohe millalgi mysql_connect() funktsiooni järel - enne kui hakkavad peale tavapäringud):

mysql_set_charset('utf8');

Ja muud keerulist polegi - edaspidi toimuvad kõik täpitähti sisalduvad otsingud, saab vaevata importida/eksportida ja nii edasi. Head kasutamist!

Tere tulemast WordPressi. See on sinu esimene postitus. Muuda seda või kustuta see ning alusta blogimist! LFUAYUJM