cilveks Posted September 13, 2007 Report Share Posted September 13, 2007 Ir pieejama viena tabula(orāklī) kur ir 90 miljoni ieraksti. Un vaicājums SELECT count(id) FROM tabula aizņem vismaz pāris minūtes, vai tas ir normāli šāda apjoma tabulai? Link to comment Share on other sites More sharing options...
andrisp Posted September 13, 2007 Report Share Posted September 13, 2007 Nezinu vai tas ir normāli, bet pamēģini vienkārši COUNT(*). Link to comment Share on other sites More sharing options...
Delfins Posted September 13, 2007 Report Share Posted September 13, 2007 uztais statistikas. A vispār nepareizi pajautāts... mēs taču nezinam, vai tu liec kaut kādu klāt WHERE vai ORDER, vai GROUP BY.. vai vispār ir indeksi un t.t. Link to comment Share on other sites More sharing options...
Grey_Wolf Posted September 13, 2007 Report Share Posted September 13, 2007 (edited) Ir pieejama viena tabula(orāklī) kur ir 90 miljoni ieraksti. Un vaicājums SELECT count(id) FROM tabula aizņem vismaz pāris minūtes, vai tas ir normāli šāda apjoma tabulai? netkartoshos shis ir labs piemers.... + velams lai butu salikti normali index + tabulu velams ari laiku pa laikam atsvaidzinat.... , bet atbildot konkreti uz jautajumu --> Nee tas NAV normali... vaicajumam nevajadzetu but garakam par paris sek... ja ne sec daljam... --- piem : tabula kuraii ir 500K ierakstu count(id) /tieski taa nevis count(*) // ilgst ~~~ 0,001 sec... Vel ljoti svarigi ir cik liela ir compja atminja ... -- UN PATS SVARIGAKAIS ORAKLim ir VAI TAS IR LICENZETS !!!! 5 useru softs (haljavnijs ) labi strada tika 5 useriem --> kad ir 6 tiek pieslegtas nenormalaas bremzes.... tas pats ir ar education, un istradataju versijaam... ------------------ aizmirsu piebilst, ka haljavnijam versijam ir ierobezots ierakstu skaits (stradat stradaas tikai Ljoti, ljoti lenu...) Edited September 13, 2007 by Grey_Wolf Link to comment Share on other sites More sharing options...
cilveks Posted September 17, 2007 Author Report Share Posted September 17, 2007 (edited) Tabula ir indeksēta. Es mēģinu dažādus nosacījumus, gan bez, gan ar WHERE, gan dzēšot ierakstu - rezultāts tāds pats. andrisp nedomāju ka count(*) ir ātrāks, jo, manuprāt, tas ietver sevī visus laukus un līdz ar to teorētiski tam vajadzētu ilgāk laika paņemt. Testa pēc pamēģināju un uz aci mērot šķita ka ir ilgāk. Bet to tā objektīvi nevar noteikt, jo tā datubāze nepārtraukti tiek lietota, respektīvi noslogota. Grey_Wolf: es īsti neticu ka tā ir. Un ar' cik orāklis var būt haļavnijs? Cik es zinu viņam "haļavnijām" versijām ir tikai noteiktas prasības pret dzelžiem (kādi max dzelži var būt). Vai arī otrs variants, tas ka datubāze nepārtraukti tiek lietota, tas arī ir tas bremzējošais faktors. Jo kā nekā vienlaikus tik daudz pieprasījumi. Tādā gadījumā tur noteikti kaut kas nav uztaisīts tā lai optimāli strādātu, bet nu to es neizmainīšu. Edited September 17, 2007 by cilveks Link to comment Share on other sites More sharing options...
andrisp Posted September 17, 2007 Report Share Posted September 17, 2007 andrisp nedomāju ka count(*) ir ātrāks, jo, manuprāt, tas ietver sevī visus laukus un līdz ar to teorētiski tam vajadzētu ilgāk laika paņemt. Nezinu par orākli, bet uz mysql zvaigznīšvariants ir ātrāks. Link to comment Share on other sites More sharing options...
Roze Posted September 17, 2007 Report Share Posted September 17, 2007 Nezinu par orākli, bet uz mysql zvaigznīšvariants ir ātrāks. Nav gluži viennozīmīgi.. uz MySQL atšķiras ātrums atkarībā no tabulas tipiem (MyISAM vs Inno) gan arī no countojamajiem laukiem: http://www.mysqlperformanceblog.com/2007/0...nt-vs-countcol/ Testa pēc pamēģināju un uz aci mērot šķita ka ir ilgāk. Bet to tā objektīvi nevar noteikt, jo tā datubāze nepārtraukti tiek lietota, respektīvi noslogota. Oracli (nevienu db) "uz aci" nemēra.. Oraclim ir kveriju izpildes profilings (execution plan) u.c. performances monitoringa iespējas.. Iesaku googlee pameklēt oracle+autotrace piem http://www.oracle-base.com/articles/8i/ExplainPlanUsage.php Šādi biku nenopietni izskatās.. Link to comment Share on other sites More sharing options...
cilveks Posted September 17, 2007 Author Report Share Posted September 17, 2007 Roze: mans mērķis nav(nebija) uzzināt cik ilgi izpildās. Tikai dotajā bridī interesēja vai tiešām būs būtiskas atšķirības starp count(id) un count(*), būtiskas nebija. Par autotrace, nemaz nezināju(nezinu) ka var ko sīkāk uzzināt par vienu kveriju. Oriģinālais kverijs ir garāks, es vienkārši viņu centos maksimāli novienkāršot, lai izslēgtu nebremzējošos faktorus. Paldies par norādi uz autotrace. Pameklēšu sīkāku info. Link to comment Share on other sites More sharing options...
Delfins Posted September 17, 2007 Report Share Posted September 17, 2007 Oriģinālais kverijs ir garāks, es vienkārši viņu centos maksimāli novienkāršot, lai izslēgtu nebremzējošos faktorus Piedod, bet tādām RDBMS kā ORacle/MSSQL/PgSQL katrs mazs sīkumņš ir ziloņa vērts.. Ir jāredz SQL, ir jāredz izpildes plāns (nevis pie mums, bet pie jums), ir jāizprot, kāpēc ir jātaisa katru reizi COUNT(*) /ar domu visi ieraksti/... Vai tiešām nevar saglabāt to visu kaut kā citādāk? Nokešot to ciparu... vai tml... Link to comment Share on other sites More sharing options...
cilveks Posted September 17, 2007 Author Report Share Posted September 17, 2007 Delfins ne tur tā problēma. Problēma ka dzēšot ierakstus no šis tabulas, šis process aizņēma laiku. Tad saku meklēt cēloni un uzgāju to ka ne tikai dzēšana bremzē. Ka ir arī pāris citas "lietas" attiecibā uz šo DB, kas iebremzē šajā projektā. Kur varēšu, izmantošu kešošanu. Ir šajā projektā jau izmantota kešošana, bet acīmredzot vajag vēl dažās vietās. Šobrīd nav skaidrs ko darīt ar dzēšanu :/ Dažreiz dzēšot izmet kļūdu, integrity constraint. DELETE FROM liela_tabule WHERE kautka_id = xx Sheit viņš var izdzēst pat 3000 ierakstus. Datubāzes ir mana vājā puse. Bet padoties ar netaisos, mācos. Būs jāizlasa kāda nopietna grāmata par orākli, nevis sagrābstīt ziņas no forumiem && googles. No googles esmu dzirdējis par tādiem dzēšanas paņēmieniem kur visa dzēšana tiek "apvienota" kā viena lielā dzēšana, ja nemaldos šķiet tas vārds bija autonomā dzēšana, bet baidos kļūdīties. Sīkāk nemācēšu pastāstīt, ar' tikai no googles dzirdēts. Link to comment Share on other sites More sharing options...
andrisp Posted September 17, 2007 Report Share Posted September 17, 2007 To man shkjiet sauc par cascade delete vai kaut kaa taa. Link to comment Share on other sites More sharing options...
Roze Posted September 17, 2007 Report Share Posted September 17, 2007 Nu ja DB nav stiprā puse, manuprāt, tad vajadzēja tomēr sākt ar MySQLu vai PostgreSQL.. noklusēti webprojektiem u.c. figņām minētās DB būs krietni vienkāršākas / ātrākas utt.. (faktiski kaut lietas ar instant-clientu ir gājušas uz labo pusi man līdz šim nepatīk Oracle priekš web/php projektiem). Jo Oracle kā tāds ir baiss veidojums.. tur ir 100 un viena figņa kas jāzin.. tad Oraclim vēl nāk visādi savi keshoshanas mehānismi (ar domu biežāk accesojamie dati tiek bīdīti vienā vietā citi citur). Ja faktiski nav kāds zinoš DBA pie rokas tad ar Oracli var ilgi un dikti nomocīties un nekādā jēgā netikt. Link to comment Share on other sites More sharing options...
Delfins Posted September 17, 2007 Report Share Posted September 17, 2007 Lielai tabulai pie dzēšanas var bremzēt pārindeksācija... Arī esmu ar to saskāries iekš MSSQL. Nedrīkst būt daudz un lieli indeksi.. ir jādomā vnk cits piegājiens. Pareizi jau teica, bez DBA konkrētai RDBMS neiztikt, viņam jābūt klāt kā kreisā roka. Link to comment Share on other sites More sharing options...
cilveks Posted September 17, 2007 Author Report Share Posted September 17, 2007 andrisp: nē tas nebija cascade delete, tur bija nedaudz citādāka doma. PostgreSQL tiek aktīvi lietots, bet vienkārši ir liels projekts kur izmantots orāklis. Un ir pāris labojumi šim projektam jāveic, neba viss no nulles jāuztaisa. Un es jūtu ka orākļa zināšanas man var noderēt arī nākotnē, kas ir ļoti liels pluss tam, un uz priekšu ar iet, nav tā ka esmu galīgi iestrēdzis kaut kur orāklī. Link to comment Share on other sites More sharing options...
Grey_Wolf Posted September 18, 2007 Report Share Posted September 18, 2007 Grey_Wolf: es īsti neticu ka tā ir. Un ar' cik orāklis var būt haļavnijs? Cik es zinu viņam "haļavnijām" versijām ir tikai noteiktas prasības pret dzelžiem (kādi max dzelži var būt). cik zinu tad ORACLim ... haljavnijas ir : Studentu versijas ( tjipa macities vinju) Izstradaataju versijas ... un apgriestaa versija (5 useri) Un jaa, maksas vers jau atkariiga cik prochiem utt.... --- Taa kaa 5 useru versija straada arii uz vairaak useriem , BET LJOTI LENAAM --> alje protieties un peerciet maksas variantu .... Un skjiet kaa tai arii bija ierobezots ierakstu skaits....... -------- Ielien vinju lapaa un palasi --> pazudiis lieki jautajumi..... ---- A stdutentu versija (alje tie pashi 5 useri , stabilii ir 'haljavnija' .... Ja netici --> pieregistrejies un njem par briivu --> pat Suports ir.... Link to comment Share on other sites More sharing options...
Recommended Posts