12 leiðir til að fínstilla SQLite gagnagrunna – Prófaðu þá núna!

Birting: Stuðningur þinn hjálpar til við að halda vefnum í gangi! Við þénum tilvísunargjald fyrir sumar þjónusturnar sem við mælum með á þessari síðu.


SQLite er SQL-undirstaða venslagagnagrunnstjórnunarkerfi (RDBMS) útfærð sem innfellanlegt bókasafn. Það geymir gagnagrunna sem stakar skrár, frekar en að treysta á líkan viðskiptavinarþjónsins.

SQLite er almennt notað á þrjá vegu:

  • Auðvelt í notkun þess er tilvalið til að prófa og protoyping forrit með gagnabanka sem eru studd af.
  • Þar sem allt er geymt á staðnum og hægt er að fella bókasafnið sjálft inn í forrit er SQLite oft einnig notað sem aðal gagnageymsla fyrir lítil forrit sem rekin eru af einum notanda. Þetta felur í sér forrit eins og heimilisföng, verkefnalista eða jafnvel netlesara.
  • Að lokum eru SQLite gagnagrunnar oft notaðir sem forritssniðið skráarsnið. Þetta er sérstaklega gagnlegt í forritum þar sem vistuð skrá er flókið verkefni, frekar en tiltölulega einfalt skjal. Í þessu tilfelli er hver skrá búin til af forritinu í raun allur SQLite gagnagrunnur.

Þörfin fyrir hagræðingu

Oftast er það ekki mjög mikilvægt þegar það er notað til að prófa og frumgerð. Í þessum tilvikum er það ekki alltaf mögulegt að gera það þar sem þú gætir ætlað að keyra forritið þitt með öðrum gagnagrunni í framleiðslu. SQLite hér er einfaldlega notað sem stand-in fyrir eitthvað annað eins og PostgreSQL eða MySQL.

En þegar SQLite er notað „í framleiðslu“ eins og í seinni tveimur tilvikum skiptir árangur máli. Að nota nokkrar einfaldar aðferðir getur virkilega haft áhrif á hraða uppfærslna og fyrirspurna gagnagrunnsins.

Hér eru nokkur hagnýt ráð til að bæta SQLite árangur í forritunum þínum. Sumir þeirra eru SQL fyrirspurn hagræðingu sem myndi hjálpa til við að flýta fyrir SQL gagnagrunnskerfi. Aðrir eru sérstaklega að hámarka SQLite.

Þar sem SQLite er mjög vinsæll gagnageymsla í Android forritum höfum við einnig sett með nokkur sérstök ráð til að hámarka árangur SQLite á Android.

Notaðu viðskipti

Fyrsta ráðið sem allir veita til að flýta fyrir SQLite er „nota viðskipti.“

Allir segja þetta vegna þess að þetta er mjög góð hugmynd. En þú gætir velt því fyrir þér hvernig á að nota viðskipti í SQL.

Við skulum segja að þú hafir safnað gögnum í einhverri eftirbreytilegri uppbyggingu eins og lista eða fylki. Þú gætir freistast til að fara í gegnum gögnin þín og setja þau inn í SQLite gagnagrunninn á hverri endurtekningu lykkjunnar.

/ ************************************************** ***
Fáðu for- og eftirnöfn úr flipamarkaðri skrá.
Settu þá í SQLlite gagnagrunninn.
*************************************************** ** /

/ * vertu viss um að skilgreina þetta í raunveruleikanum…
#define DATABASE = // nafn gagnagrunns //
#define FILE_OF_NAMES = // leið til skjals //
#define CREATE_TABLE = // SQL staðhæfing til að búa til nafntöflu //
* /

sqlite3_open (DATABASE, &db);
sqlite3_exec (db, CREATE_TABLE, NULL, NULL, &sErrMsg);

pFile = fopen (FILE_OF_NAMES,"r");
meðan (! feof (pFile)) {

fgets (sInputBuf, BUFFER_SIZE, pFile);

sFirstName = strtok (sInputBuf, "t");
sLastName = strtok (NULL, "t");

sprintf (sSQL, "Settu inn nöfn GILDIR (NULL, ‘% s’, ‘% s’,)", sFirstName, sLastName, s);
sqlite3_exec (db, sSQL, NULL, NULL, &sErrMsg);

n ++;
}
fclose (pFile);
sqlite3_close (db);

Þetta er slæm hugmynd. Þetta atomizes hvert innskot í einni færslu – hver og einn með sinn kostnað. Ekki mikið mál ef þú ert bara með par sett, en jafnvel í C-kóða sem er í gangi hratt, getur þetta hægt á þig undir 100 settar sekúndu. Ef þú notar SQLite sem skráarsnið forrits gæti þetta hugsanlega þýtt að notendur upplifi nokkrar sekúndur af töf í hvert skipti sem þeir vista flókið skjal eða verkefni.

Í staðinn fyrir að setja gagnasettið hvert fyrir sig, settu allar settar inn í eina færslu. Þetta mun flýta fyrir settum þínum verulega. Og það er ákaflega auðveld breyting að gera.

/ * fyrir lykkjuna – hafið viðskipti * /
sqlite3_exec (db, "Byrjaðu viðskipti", NÚLL, NÚLL, &sErrMsg);

pFile = fopen (FILE_OF_NAMES,"r");
meðan (! feof (pFile)) {
.
.
.
}

fclose (pFile);

/ * eftir lykkjuna – enda viðskiptin * /
sqlite3_exec (db, "SLUTAÐUR", NÚLL, NÚLL, &sErrMsg);

Þú ert enn að keyra INSERT yfirlýsinguna innan lykkjunnar en þau uppfæra ekki gagnagrunninn á hverri endurtekningu. Í staðinn vistar SQLite allar staðhæfingar þínar í skyndiminni og keyrir þær allar í einu sem eina aðgerð þegar þú Lýkur TRANSACTION.

Þar sem innskotin eru öll geymd í skyndiminni gætirðu þurft að hækka skyndiminni til að fá hraðakostinn við að nota viðskipti á þennan hátt.

/ * eftir að db-tenging hefur verið opnuð,
áður en viðskipti hefjast * /
sqlite3_exec (db, "PRAGMA skyndiminni = stærð 10000", NÚLL, NÚLL, &sErrMsg);

Viðskipti í Android

Innbyggða SQLite forritaskil Android gerir það auðveldara að nota viðskipti.

// til að hefja viðskipti
db.beginTransaction ();

// til að ljúka viðskiptum
db.endTransaction ();

Þú gætir líka viljað athuga hvort það hafi verið undantekningar áður en þú framdi viðskiptin og skráðu þá villuna ef vandamálið var. Það er líka auðvelt í Android.

reyndu {
db.beginTransaction ();

/ * Gerðu efni í lykkju. * /

db.setTransactionSuccessful (); // Þetta skuldbindur viðskiptin ef engar undantekningar voru

} veiða (undantekning e) {
Log.w ("Undantekning:", e);
} loksins {
db.endTransaction ();
}

Undirbúið og bindið

Í síðasta dæminu var SQL staðhæfingin búin til aftur við framkvæmd hverrar lykkju. Þetta þýðir að það var einnig sent af SQLite í hvert skipti. Sú aðgreining hefur nokkra reikniskostnað sem hægir á hlutunum með hverri endurtekningu.

Þú getur flýtt fyrir hlutunum með því að útbúa SQL yfirlýsinguna þína utan lykkjunnar og síðan binda gögnin þín við þau í hvert skipti sem þú notar þau.

/ * áður en viðskipti hefjast * /
sprintf (sSQL, "Settu inn nöfn GILDIR (NULL, @Fyrsta nafn, @Lastnafn)");
sqlite3_prepare_v2 (db, sSQL, BUFFER_SIZE, &þm, &hali);

sqlite3_exec (db, "Byrjaðu viðskipti", NÚLL, NÚLL, &sErrMsg);

pFile = fopen (FILE_OF_NAMES,"r");
meðan (! feof (pFile)) {

fgets (sInputBuf, BUFFER_SIZE, pFile);

sFirstName = strtok (sInputBuf, "t");
sLastName = strtok (NULL, "t");

sqlite3_bind_text (stmt, 1, sFirstName, -1, SQLITE_STATIC);
sqlite3_bind_text (stmt, 2, sLastName, -1, SQLITE_STATIC);

sqlite3_step (stmt);

sqlite3_clear_bindings (stmt);
sqlite3_reset (stmt);

n ++;
}
fclose (pFile);
sqlite3_exec (db, "SLUTAÐUR", NÚLL, NÚLL, &sErrMsg);
sqlite3_close (db);

Þessa stefnu er einnig hægt að nota utan lykkjur. Ef þú ert með fyrirspurn inni í aðgerð geturðu útbúið hana einu sinni og síðan bundið hana í hvert skipti sem hún er notuð.

Unnin yfirlýsingar í Android

Android SQLite API veitir SQLiteStatement bekknum til að gera þetta auðveldlega.

// skrifa fyrirspurnina, með? fyrir gildi til að setja inn
Strengur sql = "Settu inn nöfn GILDIR (?,?)";

// setja saman yfirlýsinguna
SQLiteStatement yfirlýsing = db.compileStatement (sql);

/ ** lykkja í gegnum skrár ** /

/ ** fáðu nöfnin úr skránni og úthlutaðu í fornafn og eftirnafn ** /

// binda
statement.bindString (1, firstName);
staðhæfing.bindString (2, eftirnafn);

// exec
Long row_id = statement.executeInsert ();

Ekki samstilla við diskinn eftir hverja innsetningu

SQLite bíður sjálfgefið að stýrikerfið skrifi á disk eftir að hafa gefið út hverja af þessum innskotum. Þú getur slökkt á þessari hlé með einfaldri skipun.

sqlite3_exec (db, "PRAGMA samstilltur = OFF", NÚLL, NÚLL, &sErrMsg);

Settu þetta eftir að þú hefur opnað tenginguna við gagnagrunninn en áður en þú byrjar á viðskiptunum. Þú ættir líka að vita að þetta gæti valdið spillingu gagnagrunns ef um hrun eða rafmagnsleysi að ræða. Svo þú vilt vega og meta aukinn hraða hér gegn hugsanlegri áhættu.

Geymið afturbók í minni

Ef þú ert nú þegar búinn að vera hættulegur með PRAGMA samstilltur = OFF, og þú ert að reyna að kreista út öll auka millisekúndur, geturðu líka geymt afturbókardagbókina í minni í stað þess að vista það á disknum. Samanborið við fyrri hagræðingu er þetta svolítið áhættusamt.

sqlite3_exec (db, "PRAGMA journal_mode = MINNI", NÚLL, NÚLL, &sErrMsg);

Þú getur líka stillt journal_mode á OFF, ef þú ert að reyna að vinna hraðkeppni eða eitthvað. (Ekki er mælt með þessu til raunverulegra nota.)

Viðvörun dagbókarstillingar fyrir Android

Tímaritastilling SQLite er stjórnað með aðferð ActiveWriteAheadLogging () frá Android. Svo sem skjölin fyrir framkvæmd hrára SQL skipana segja:

Ekki stilla journal_mode með "PRAGMA tímarit_mode" yfirlýsing ef forritið þitt notar enableWriteAheadLogging ().

Aðeins vísitala þegar þú raunverulega þarfnast hennar

Naive gagnagrunni verktaki eins og til að búa til mikið af vísitölum “til að flýta fyrir hlutum.” En með því að gera það af tilviljun, eða verðtryggja bókstaflega allt, getur það verið mótvægislegur. Að setja innihald töflu yfir með ákveðinni röð gerir lestur hraðari og skrifar hægari. Og það gerir lesið aðeins hraðar fyrir fyrirspurnir sem eru að leita út frá þeim dálki.

Svo ef notendur ætla aldrei að leita að innihaldi töflu sem byggir á tilteknum dálki, ekki skrá það. Ennfremur, ef notendur eru einungis líklegir til að leita í tilteknum dálki sjaldan, þá skaltu ekki skrá það. Jafnvel þó að líklegt sé að þeir leita oft þarftu samt að hugsa um hvort borðið verði skrifað til eða leitað frá því oftar. Ef það verður skrifað oftar en leitað, eða ef skrifhraði er sérstaklega mikilvægur, ekki skráðu það.

Oft mun tegund umsóknar ráðleggja þessar þarfir. SQLite er ekki almennt notað í stórum gagnageymslum sem þurfa að styðja við margs konar aðgerðir. Ef það er notað sem forritsgerð, til dæmis, er notandi hæfileiki til að vista verkefni fljótt meðan hann vinnur mikilvægari en að geta leitað í innihaldi vinnuskjals eins hratt og mögulegt er. Aftur á móti getur gagnageymsluforrit sem venjulega eru með handvirkar uppfærslur með einni færslu (eins og tengiliðaskrá eða verkefnalista) líklega staðið við að hafa aðeins hægari skrif, en ætti að styðja mjög hratt við leit.

Vísitala eftir magninnsetningu

Þegar búið er að búa til vísitölu á töflu mun hvert innskot eftir það taka tíma að skrá nýja efnið. Ef taflan þín verður frumstilla með stóru innskoti af magngögnum (kannski í fyrsta skipti sem nýtt verkefni eða skjal er vistað, eða þegar flutt er inn gögn fyrir nýjan notanda) geturðu flýtt fyrir fyrsta stóra innskotinu með því að bíða eftir að búa til vísitöluna þar til eftir innskotið.

Aðrar PRAGMA stillingar

Það eru til nokkrar PRAGMA stillingar sem geta hjálpað til við að bæta SQLite árangur þinn.

Skyndiminni stærð

Eins og stutt er getið hér að ofan gætirðu þurft að auka skyndiminni. Stórum viðskiptum verður aðeins hraðað ef hægt er að geyma alla viðskiptin í skyndiminni.

Minni sem notað er í skyndiminni er úthlutað þegar þess er þörf, svo það er enginn kostnaður við að setja hann of hátt. Þú getur líka breytt aðlagi – hækkað það til að fínstilla fyrir ákveðnar fyrirspurnir og lækkað það síðan þegar þess er ekki þörf.

sqlite3_exec (db, "PRAGMA skyndiminni = stærð", NÚLL, NÚLL, &sErrMsg);

Tímabundin borðgeymsla

Þú getur sagt SQLite að geyma tímabundnar töflur í minni. Þetta mun flýta fyrir mörgum lestraraðgerðum sem treysta á tímabundnar töflur, vísitölur og skoðanir.

sqlite3_exec (db, "PRAGMA temp_store = MINNI", NÚLL, NÚLL, &sErrMsg);

Android og Pragma stillingar

Þú getur notað execSQL () aðferðina til að framkvæma hrátt SQL gegn SQL gagnagrunninum þínum. Það er beinasta leiðin til að breyta PRAGMA stillingum. Sumum þeirra (eins og journal_mode sem nefndur er hér að ofan) er þó stjórnað af öðrum flokkum eða aðstoðarmönnum í API.

Hraðari fyrirspurnir – síaðu meira fyrr

Ef þú ert að spyrja út frá mörgum forsendum geturðu oft flýtt því með því að endurraða því hvernig viðmiðunum þínum er raðað. Ef fyrsta HVAR-ákvæðið skilar sem fæstum árangri mun hver síðari hafa færri hluti til að takast á við.

Í fyrirspurn sem er með mikinn fjölda breytna skaltu prófa að gera tilraunir með nokkrar mismunandi permutations í röð til að sjá hver er með besta meðalhraðann.

Tilfelli ónæmar vísitölur fyrir eins

LIKE ákvæðið til að bera saman texta er mál-ónæmt. Vísitölur eru sjálfkrafa hástafar. Ef einu fyrirspurnirnar sem vísitölurnar þínar eru að fínstilla fyrir eru LIKE fyrirspurnir, þú getur sparað tíma í innskotum og fyrirspurnum með því að gera vísitöluna þína ónæmar.

Búðu til INDEX sLastName ON NAMES (KEY COLLATE NOCASE);

Notaðu nýjustu útgáfuna ef mögulegt er

Hver aðalútgáfa SQLite inniheldur aukahluti í frammistöðu. Sumar útgáfur hafa aukið hraðann verulega. Svo ef þú ert að nota minniháttar útgáfu sem er nokkurra ára gömul (eða það sem verra er, samt að nota v2), þá er einfaldasta leiðin til hraðari framkvæmd einfaldlega að uppfæra.

Ekki búa til nýjan gagnagrunn

Þetta er mikil hugsunarbreyting fyrir fólk sem kemur frá öðrum RDBMS kerfum.

Íhugaðu málið að nota SQLite sem snið forrits. Í hvert skipti sem þú vistar nýtt verkefni (skjal) í fyrsta skipti í appinu þarf nýtt dæmi um gagnagrunn.

Þú getur búið til nýjan gagnagrunn og framkvæmt röð af SQL staðhæfingum til að bæta við viðeigandi töflum og vísitölum. Þetta væri það sem þú myndir vilja gera ef þú byggir upp dreifanlegt forrit með (til dæmis) PostgreSQL – þú myndir skrifa kóðann til að setja upp gagnagrunninn og láta keyra hann við uppsetningu.

En það er hraðari leið.

Þar sem SQLite gagnagrunnur er stak skrá er tiltölulega léttvægt að klóna gagnagrunninn – hann er einfaldlega að afrita skrána. Þetta þýðir að venjulega er ekki nauðsynlegt að búa til nýjan gagnagrunn og keyra síðan allar SQL staðhæfingarnar sem krafist er. Venjulega geturðu bara búið til afrit.

Í Android gætirðu viljað nota SQLite Asset Helper til að stjórna gagnagrunnum sem eignum þegar þetta er gert.

Hugleiddu að afnema

Ef þú hefur reynslu af gagnakerfis gagnagrunnskerfum gætirðu haft mikið í huga að gera gögnin þín eðlileg. Það er miklu meira í þessu en þetta, en kjarninn í eðlilegum gögnum er: ein sannindi.

Í normaliseruðum gagnagrunni eru öll gögn, sama hversu léttvæg, táknuð nákvæmlega í eitt skipti. Svo til dæmis gæti plata sem táknar bók vísað til plötunnar sem er fulltrúi höfundar – en það myndi vissulega ekki stafa nafn höfundarins beint.

Þetta sparar pláss og er glæsilegra. En það gerir lestur úr gagnagrunninum líka tímafrekari. Ef þú vilt finna allar bækur höfundar þarftu að leita á höfundartöflunni til að fá kennitöluna og leita síðan í bókatöflunni og setja saman færslur.

Þú getur flýtt fyrir lestri af þessu tagi með því að afrita nafn höfundar í öllum bókaskrám. Þetta bætir frammistöðu en fórnar eðlilegum hætti. Þetta hefur tvær mögulegar hæðir, fyrir utan óreglu:

  • Rökfræði umsókna verður ábyrgt fyrir því að viðhalda heilleika gagna (það er, sannleiksgildi eða nákvæmni).
  • Gagnagrunnurinn verður að vera stærri til að geyma sama magn upplýsinga.

Afbrigðileiki í SQLite er sérstaklega góður

Allar þessar áhyggjur og viðskipti eru til staðar þegar þú vinnur með hvaða RDBMS kerfi, ekki bara SQLite. Hins vegar, í SQLite, eru einhverjir hugsanlega mótvægisatriði sem gera afnám gagna minna vandmeðfarin og gagnlegri.

  • Venjulega er SQLite forrit að hafa minna flókið gagnalíkan (stef) en mjög stórt forrit sem þarf gagnagrunnsmiðlara. Þetta gerir flækjurnar í forritinu sem þarf til að styðja óbreytta gögn minna íþyngjandi.
  • Gagnasett sem studd er af SQLite gagnagrunnum eru venjulega minni en þau sem geymd eru í öðrum gagnagrunnskerfum. Þetta þýðir að aukning í stærð úr tvíteknum gögnum er minna vandmeðfarin. Að auki, á mælikvarða flestra SQLite forrita (staðbundin skrágeymsla), er kostnaður við viðbótarstærð hverfandi.
  • Ólíkt stórum gagnagrunnsþjónum (sérstaklega þeim sem stofnanir hafa viðhaldið) er ólíklegt að annað forrit reyni að tengjast SQLite gagnagrunninum sem forritið þitt bjó til. Þess vegna þarftu ekki að verja fyrir slysni spillingu gagna og vandasömu liði.
  • Á sama hátt, vegna þess að SQLite er venjulega notað sem innbyggður gagnagrunnur, þá er oft þétt tenging milli forritsins og gagnagrunnsins. Þetta þýðir að hæðirnar við meðhöndlun á heilleika gagna í forritinu eru almennt minni en þær yrðu þegar gagnagrunnur og forrit eru lauslega saman líkamlega, en mjög háð innbyrðis..
  • Að lokum eru nokkrar af þeim árangri sem viðhalda eðlilegum árangri í öðrum gagnagrunnskerfum – svo sem veruleikasjónarmiðum – ekki tiltækar í SQLite.

Af þessum ástæðum er afbrigðilegt fyrir frammistöðu mun algengari framkvæmd með SQLite en með öðrum gagnabanka.

Yfirlit

Þessi ráð til að hámarka árangur SQLite eru einmitt þessi – ráð. Þetta er ekki nákvæm áætlun til að fylgja og þú flýtir ekki fyrir SQLite forritinu með því einfaldlega að bæta hverjum hlut frá þessum lista inn í kóðann þinn. Þetta eru hugmyndir sem gætu hjálpað ef þær eru notaðar á viðeigandi hátt. Hugsaðu svo um umsókn þína og sjáðu hvort einhver þeirra gæti hjálpað. Og próf. Þú verður að komast að því hvað gerir forritið hægt fyrir þig áður en þú getur gert það hratt.

Frekari upplestur og úrræði

Við höfum fleiri handbækur, námskeið og infografics sem tengjast forritun og þróun:

  • SQL Resources: almenna SQL vefsíðan okkar sem skiptir sköpum fyrir alla forritara sem tengjast gagnagrunni.
  • MySQL kynning og auðlindir: annað mjög vinsælt gagnagrunnskerfi.
  • PostgreSQL kynning og auðlindir: vinsælt gagnagrunnskerfi á eigin spýtur, SQLite byggir að hluta á því.

Ultimate Guide to Web Hosting

Skoðaðu Ultimate Guide okkar til vefhýsingar. Það mun útskýra allt sem þú þarft að vita til að taka upplýst val.

Ultimate Guide to Web Hosting
Ultimate Guide to Web Hosting

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map