404 Posted March 23, 2009 Report Share Posted March 23, 2009 (edited) Ir vajadzība saveidot projektiņu,kas nodarbotos ar javascript bāzētu čatu hostēšanu,bet ir radušās dažas pārdomas,kā labāk nodrošināt datu glabāšanu(iekš MySQL) sākuma periodā,kamēr projekts attīstās. Ir ideja par 2 variantiem: 1. Sākotnējā doma bija izveidojot jaunu "īpašnieku",izveidot uzreiz atsevišķu datubāzi,pie kuras tad konektētos visi attiecīgo čatu izmantojošie useri.Pati db nebūtu liela,jo tekstu vēsture nav paredzēta.Doma ir iztikt ar 2 mazām tabulām.Vienā paša čata uzstādījumi,pieejas u.t.t,bet otrā teksti ierobežotā skaitā,teiksim 30-50 rowi.Bet tā kā čatu varētu būt daudz-pat ne vairs simtos (projekts paredz piedāvāšanu online spēļu vidēs un websaitos lietotāju grupām u.t.t),tad arī attiecīgi datubāžu skaits būs tikpat,un sākumā,kamēr nav izdalīta servera,tas varētu šausmās iedzīt ne vienu vien hosteri.Ja nemaldos,tad neierobežots db skaits šādā izpratnē nebūs tas,kā to redz parasta maksas hostinga sniedzējs vismaz iekš lv :) 2.variants: Visiem čatiem 1 datubāze tekstiem,un katram čatam tāpat iedalīt savu tabulu.Tad sanāk viena pamatīgi nogruzīta datubāze ar simtiem tabulām,kur slēgsies klāt n-tais skaits useru,ciklā selektējot katru tabulu.Par ātrumu tur arī nav nekādu ilūziju,bet tomēr interesē domas,cik apsverams būtu tieši šis variants.Pašlaik vadīšanās vairāk ir pēc hostinga pieejamības un izmaksām,ne ātruma,jo veiksmīga projekta gadījumā tiek ņemts izdalītais serveris,vai likts savs. Vēl viens jautājums būtu par rowu skaita uzturēšanu tekstu tabulā.Kāds variants būtu labāks čatam: 1. Pie katra jauna inserta dzēst pašu vecāko ierakstu (Nebūs bremzīgi?) 2. Krāt līdz noteiktam skaitam,un tad dzēst ar kaut kādu limitu daļu vecāko.Visu laiku sanāk COUNT(*) taisīt (Vēl lielāka bremze?) 3. Krāt neko neskaitot,un reizi noteiktā laikā (stunda/diena u.t.t) dzēst vecākos(tad atkal db izmēri krietni palielinās) Varbūt ir vēl kāds risinājums? Pats vairāk sliecos uz pēdējo variantu,bet interesē apsvērt arī citus. Jebkura ideja vai kritika būtu vērtīga,tāpēc ar interesi palasītos citu pieredzi vai ieteikumus :) Edited March 23, 2009 by 404 Quote Link to comment Share on other sites More sharing options...
bubu Posted March 23, 2009 Report Share Posted March 23, 2009 Čatam jau ierakstus DB glabāt nav vērts, ja nevajag tos pieglabāt vēsturei (log'i), vai arī lai katrs jaunpienākušais redzētu iepriekš runāto. Prātīgāk būtu turēt pēdējās čata rindiņas servera atmiņā. Piemēram ar kādu no šiem: http://php.net/memcache vai http://php.net/apc vai tml. Quote Link to comment Share on other sites More sharing options...
codez Posted March 24, 2009 Report Share Posted March 24, 2009 bubu jau ieteica labus variantus, bet, ja tomēr paliec pie MySQL, tad tabulas taisi memory. Un cik tad tev to jūzeru kopā būs, lai visus čatus neliktu vienā tabulā? Var darīt tā: Ja tev čātā tiek glabāti pēdējie 30 ieraksti, tad sākumā ieliec visus 30. Kad ienāk jauns ieraksts glabā to pa virsu pēdjējam. Tev tikai kautkur jāglabā norādītājs, kurš norāda, kur atrodas pēdējais ieraksts. Quote Link to comment Share on other sites More sharing options...
Klez Posted March 24, 2009 Report Share Posted March 24, 2009 (edited) man liekas ka pietiek ar vienu db ... vienā tabulā glabā čatu īpašniekus otrā čatu tekstus un trešajā istabas ... pirmā: id | ipasnieka nosaukums | citi dati otrā tabula varētu būt šāda: id | teksts | time_stamp | istabas_id trešā | id | ipasnieks_id | nosaukums un tad krāmē tajā tabulā tekstus. cron`ā plaid skriptu kas dzēsīs vecos datus ... delete from otrā_tabula where time_stamp < time() - cik_sekundes_vecus_ierakstus_dzēst ja ir bez niku reģistrācijas tad var pie ieiešanas čata istabā sesijā iecept niku un db gabāt: "[jānis]: jauks čats" ja īpašniekus nav paredzēts reģistrēt un istabas ģenerēt on the fly .. tad pietiek ar vienu tabulu varētu būt šāda: id | teksts | time_stamp | istabas_nosaukums [unique] ja ir baigi daudz teksti (daudz MB) tad var uztaisīt vairākas vienādas tabulas un pie čata izveidas randomā paņemt vienu ciparu tabula1, tabula2, tabulaN ja grib vēl smukāk tad var tus ciparus generēt lielākus piem kādus 6 simbolus vai daļu no md5 stringa, kas būtu pietiekami unikāli ... un tad pie čata izveidošanas izveidot tabulu .. create table if not exists .. un tad papildus cronā var ielikt skriptu kas vienu vai divas reizes dienā nolasa visas tabulas no DB un paskatās kad tabulai ir pēdējo reizi bijis update/access time , ja tabulai update time nav bijis piemēram 24 stundas tad to tabulu vienk dropo... tā pāt tad ir jāpamaina tas cron skripts kas dzēš vecākos ierakstus , tam ar būtu jānolasa visas tabulas no db un tad katrai skatās tos ierakstus .. Edited March 24, 2009 by Klez Quote Link to comment Share on other sites More sharing options...
mounkuls Posted March 24, 2009 Report Share Posted March 24, 2009 Ja nav paredzētas nekādas privātas sarakstes, tikai parasts čats, čata tekstus var mierīgi gabāt arī failā. Uztaisi folderi chata_dati un katram čata ID savu failu, to var būt tūkstošiem ar ja vajag. Ja vajag ielasīt failu ar 30 rindiņām, tur nekāda bremze nebūs. Arī cron tad nevajag, jo pārrakstīt tik mazu failu laiku tērē maz un to var darīt katru reizi, kad kāds lietotājs lieto failu. Nu vismaz man liekas ka bremze nebūtu. Quote Link to comment Share on other sites More sharing options...
404 Posted March 24, 2009 Author Report Share Posted March 24, 2009 Visi no ieteiktajiem variantiem būtu izmēģināmi.Tas Memcache izskatās interesants,un varētu,bet var parādīties vajadzība arī pēc vēstures un kaut kādām papildus fīčām,kur varētu savajadzēties pieglabāt datus ilgstošāk.Bet tiks pamēģināts,ja būs iespēja.Pašlaik struktūra arī ir līdzīga Klez ieteiktajai: 1 DB ir reģistracijām,kur glabājas visi īpašnieku dati,reģ laiks,termiņš,useru niki,pieejas.u.t.t.Vēl arī tabulas vēl neapstiprinātām regām un supportam.No šīs bāzes arī čata identifikācija un sesijas. Otrā DB ir tikai tekstiem: čata tabulai lauki: id | lietotāju grupas nosaukums | aktīvie useru niki | teksti | update timestamp | īpašnika uzstādījums pieejām | plānojas vēl daži lauki istabu tekstiem(lai nav vēl viena tabula vajadzīga) Šībrīža shēma: Čatu parāda,ka arī datus sūta un saņem pārlūka addons(Greasemonkey user scripts failiņš) No pirmās db tiek nočekots pēc sūtītā id,kurš čats tam atbilst,pārbaudīta sesija un nika atļauja pieslēgties,un pēc id izsaukta attiecīgā čata tabula,no kuras ciklā tiek izselektēti pēdējie 30 ieraksti.Pašlaik tekstu tīrīšana tiek realizēta dzēšot vienkārši reizi dienā,jo ierakstu apjoms nepārsniedz 2000 ierakstus dienā.Apkopojot ieteikumus,nonācu pie domas palaist cron teiksim reizi pāris stundās,pārskaitīt ierakstus,un padzēst tikai vecākos.Dropot vai truncate tabulu negribas,jo ņemot vērā čatu izmantoto vietu,tajos var būt info,kuru nebūtu vēlams dzēst (Piemēram iekš stratēģiskiem online geimiem,kā ikariam.lv u.t.t)Lielākas iespējas arī vēsturi realizēt,ja vajadzēs. Mounkula ieteiktais variants arī varētu derēt,un varētu kombinēt kopā-tekstus rakstīt failos,bet pārējo caur mysql.Bet par to perfomanci nez,vai nebūs bremzīgāk.Ja vienlaicīgi simtiem useru lasīs un pārrakstīs tos 30 rindu failus,nebūs lēnāk kā iekš mysql apstrādāt? Bet kā alternatīvu nebūtu grūti pamēģināt.Vēl jau laikam radīsies kādi jautājumi,bet pamata virziens būtu skaidrs.Paldies par ieteikumiem :) Quote Link to comment Share on other sites More sharing options...
mounkuls Posted March 24, 2009 Report Share Posted March 24, 2009 (edited) id | lietotāju grupas nosaukums | aktīvie useru niki | teksti | update timestamp | īpašnika uzstādījums pieejām | man tas aktivie useru niki kaut kā ne visai tur loģisks liekas.... .Bet par to perfomanci nez,vai nebūs bremzīgāk.Ja vienlaicīgi simtiem useru lasīs un pārrakstīs tos 30 rindu failus,nebūs lēnāk kā iekš mysql apstrādāt? Pārrakstīs jau tikai tie, kuri pievieno jaunus tekstus, ne visi. Tā es to biju domājis. Dzēst vecos jau nav vajadzība agrāk. Ja mysql ir apacim localhost, iespējams ka selektēt ir ātrāk, bet ja remote access, domāju ka faili būs ātrāks variants pat. Edited March 24, 2009 by mounkuls Quote Link to comment Share on other sites More sharing options...
404 Posted March 24, 2009 Author Report Share Posted March 24, 2009 (edited) Tas aktīvo useru niku lauks sākotnēji bija online statusu tabulā,bet to likvidējot tika pārnests uz šo.Faktiski nebūs nemaz laikam vajadzīgs,jo online statusi tiks ņemti pec lastact lauka. Par to failu variantu-it kā varētu būt pietiekami ātri,bet tie txt faili ja arī netiks visu laiku rakstīti,bet masīvā tos failus vienalga liks nepartraukti ielasīt visi lietotāji katru reizi pārlādējot lapu,un šā vai tā no cikla neizbēgt tekstus izvadot.Tad jājautā vai kāds var padalīties pieredzē,kas strādā ātrāk: file + foreach vai mysql_fetch_row + while .Mysql serveris būs manā gadījumā lokālais.Vismaz tā domāju ka iekš lv hosteriem tā parasti ir. Edited March 25, 2009 by 404 Quote Link to comment Share on other sites More sharing options...
xPtv45z Posted March 25, 2009 Report Share Posted March 25, 2009 Šis - https://blueimp.net/ajax/ likās tīri stilīgs, nezinu gan kā darbojas pie paliela useru skaita. Bet, domāju, kaut kādas idejas vari pasmelties. Quote Link to comment Share on other sites More sharing options...
404 Posted March 25, 2009 Author Report Share Posted March 25, 2009 Šis izskatās tīri smuki.Iekšējā struktūra gan ir rakstīta uz klasēm un neskaitāmām cita citu izsaucošām funkcijām,bet domāju,daudz ko vērtīgu izdabūšu.Ir daudz fīču,par ko pat iedomājies nebiju,un Javascript daļa ir interesesanta :) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.