Jump to content
php.lv forumi

Par 1 000 000 teksta gabalu glabaashanu


Toms

Recommended Posts

  • Replies 62
  • Created
  • Last Reply

Top Posters In This Topic

starp citu saados gadijumos praatiigaak ir veidot tikai laukus ar fikseetu garumu -

respektiivi tikai kura sadaljai pieder:

id/user_id/inbox_autbox_send_utt(kas ir fikseets skaitlis/texta_id/

 

noindexeet peec _user_id - apmeeram 500,000,000 tabuulaai - mekleesana -

nebuus ilgaaka par 1-2 sek. (padomaa - kaa notiks mekleesana)

 

pashus tekstus (vestules tekstu un subj) glabaat atseviskji:

pasu tekstu atrast aiznjems ap 0,01 sek ;) (protams jaizveido indexi)

 

Ar garantiju saads varjants straadaas aatraaknekaa nekaa ja visu veestuli glabaasi vienaa tabulas rindaa ;)

 

P.S. Palasi taks par datubaazu uzbuuvi :) un datu glabaashanu tajaas

Edited by Grey_Wolf
Link to comment
Share on other sites

un kā ar č ģ ņ Ā? mīkstinājumus un garumzīmes domāju.

14644[/snapback]

 

Cik sistēmās tu vari loginu veidot no mīkstajiem burtiem?

 

Es personīgi visur lietoju tikai latīņu alfabēta burtus, skaitļus un underscore (_) simbolus vai kādus citus specifiskos simbolus, kā @, ja login==email.

Link to comment
Share on other sites

Aha, mekleeju un lasu DB uzbuuvi.

 

Bet taa Tava doma - tekstus atsevishkji, citaa tabulaa domaji?

14652[/snapback]

 

Jaa :)

pareekjini pats - vai SQLam katru reizi jjapparbauda Katra teksta garums (preciizaak jaanolasa baits kur tas ir pierakstiits) - vai

peec vienkaarshas matemaatikas uzreiz atrod kur saakas vajadziigais ieraksts -

otrkaart saada (1 tabula) buus ieveerojami mazaaka apjoma zinjaa - liidz ar to

Varbuut pat visa ielasiisies op atminjaa - un straadaas DAUDZ aatraak-

 

2 tabula vienkaarshi parbauda (peec indexa) kur saakas teksta lauks un vinju nolasa (tjipa text.1 saakas ar xxx baitu) - nu kaa peec logikas - buus aatraak?

;)

 

Taapeec pamat tabulaa izmanto tikai integer -(inbox,uutt nosaukumus vari glabaat atseviskji - piedevaam vareesi izmantot N-valodas).

Un skaties cik plaanoto nosaukumu buus (varbuut neizmanto integer, bet smalinteger) - vardu sakot ekonomee uz katru baitu :)

Link to comment
Share on other sites

Cik sistēmās tu vari loginu veidot no mīkstajiem burtiem?

 

Es personīgi visur lietoju tikai latīņu alfabēta burtus, skaitļus un underscore (_) simbolus vai kādus citus specifiskos simbolus, kā @, ja login==email.

14649[/snapback]

 

veidot var daudz kur, arī šajā forumā, kad reģistrējos, tad varēja, tagad nezinu kā ir. ļoti daudz aizmirst par šāda fakta esamību, gribēju tikai atgādināt.

Link to comment
Share on other sites

table1

 

id <- auto,primary

user_id <-indekseets

msg_id <- indekseets

from

when

 

table2

 

id <- auto,primary

msg_id <-indekseets

text

 

Piemeers:

Vajag atrast 67-taa usera (user_id) visas veestuliites = kas suutiitas vinjam.

 

querijs kjeras pie table1 un panjem visus ierakstus ar user_id = 67, tai pashaa laikaa piefiksee arii msg_id un from, un when.

 

tad kjeras pie table2 un sameklee peec msg_id vajadziigo text.

 

 

Nu shitaa es sapratu Tavu domu... Bet nu table2 buus LJOTI liela. Ja saki, ka 500 000 000 nav nekas iipashs, tad itkaa dereetu...

Link to comment
Share on other sites

Piemeers:

Vajag atrast 67-taa usera (user_id) visas veestuliites = kas suutiitas vinjam.

 

... Bet nu table2 buus LJOTI liela. Ja saki, ka 500 000 000 nav nekas iipashs, tad itkaa dereetu...

14657[/snapback]

 

Tu gribi teikt ka tu VIENLAICIIGI raadiisi teiksim VISAS vestules ar pilniem textiem? :lol:

ja tev pirmajaa tabulaa buus iekodeets arii vai shii veestule ir jauna/lasiita/atbildeeta (1/2/3 ;) ) tad nav nekaadu probleemu (teiksim info par pirmajaam 20-50 noglabaat sesiijaa) un kad lietotaajs grib vinju izlasiit tad nosuutiit pieprasijumu tabulai 2 kas atgriezj visu paareejo info .....

piedevaam eksistee Dazaadi tabulu apvienoshanas principi ....

Jebkuraa gadijumaa saadi buus aatraak......

 

P.S. aizmirsu piebilsts - nu vel tacju paliek iespeeja sho varjantu sadaliit peec vairaakaak tabulaam - sk augstaak (tjipa a-z - vai katram n tuukstotim veidot sauvu......

Edited by Grey_Wolf
Link to comment
Share on other sites

jautājums radās:

kas būtu, ja visu to smuki strukturētu iekš to FS?

sadalam visus 100k lietotājus daudz maz vienādās proporcijās, tad vēl un tad katram inbox failiņu izveidojam.

manuprāt strādās ātrāk nekā searchs pa miljons ierakstiem. vai arī es kļūdos?

Link to comment
Share on other sites

Toms

būtu baigi feini, ja tu tiešām pieķertos klāt un tā kārtīgi palasītu kādu grāmatu par relāciju datu bāzēm. Ja jau esi pielaists pie tik megaliela projekta, būtu jauki, ja nemākulības dēļ tas nenogrimtu. Labu veiksmi, un atcerieties seno teicienu - mācīties, mācīties un vēlreiz - mācīties. :)

Link to comment
Share on other sites

hmnc

man ir aizdomas, ka tev varētu būt taisnība. Uz nekrutas kastes ar vienkāršāku dbvs datu atlasīšana no 1M ierakstu tabulas varētu būt lēnāka nekā no failu sistēmas. Cita lieta, ka sistēmās parasti lietotāju dati tiek sasaistīti ar citām db lietām, tāpēc jau izgudroja dbvs.

Nezinu tikai, vai pie lielas servera noslodzes failu sistēma spētu tikt galā ar noslodzi; datu bāzes gadījumā maksimāli daudz biežāk pieprasīto datu tiek ielasīti operatīvajā atmiņa, bet failu sistēmas gadījumā pie katra pieprasījuma tiek grabināts hdd.

Link to comment
Share on other sites

Njaa, patiktos arii Rozes un Grey_Wolf komentaari par shiim peedeejaam trim domaam...

 

 

Tad man veel ieshaavaas prataa doma -

 

Ir 7 tabulas. Visas vienliidz svariigas un vienliidziigi daudz queriji tajaas notiek.

No kodeeshanas viedoklja buutu forshi, ja DB1 satureetu 4 tabulas un DB2 satureetu 3 tabulas. Piebilde, ka taas 4 ar taam trim nav savstarpeeji saistiitas.

 

Nuja, kaa buutu ar aatrumu, mosh tomeer labaak ir atstaat visas vienaa datubaazee?

 

 

off-topic: Heh, nuja, rokos pa netu lasu visaadas lietinjas saistiibaa ar MySQL DB aatrumu...

Link to comment
Share on other sites

qued:

jā. tā varētu būt problēma, ka aptuveni 10k lietotāju onlainā lūr savu pastkasti, bet nu bik varētu paanlizēt:

* visi 10k uzreiz nelūrēs pastakasti. sliktākajā gadijumā 5k lūrēs, citi darīs, ko citu (ja vien projekts nav tēmēts uz šo vēstuļu joku)

* pie ielogošanās varam samest pirmos 20 vēstuļgabalus iekš RAM vai kaut kā tā.

* jāskatās lai lietotājiem būtu vēstuļu glabāšanas limits (lai nebūtu tā ka vienam būs 2 vēstules, bet citam 10k vēstuļu)

* neaizmirstam arī, ka db atronas uz FS :)

 

domājams, ka ļoti rūpīgi izpētot visus variantus, var nonākt pie kāda optimālākā galarisinājuma.

Link to comment
Share on other sites

Toms

kāda p. pēc dalīt tabulas divās datu bāzēs? :) Kādēļ tas būtu forši no kodēšanas viedokļa?

hnmc

>visi 10k uzreiz nelūrēs pastakasti. sliktākajā gadijumā 5k lūrēs, citi darīs, ko citu (ja vien projekts nav tēmēts uz šo vēstuļu joku)

Paskaties uz draugiem.lv dienas vidū. Cik zinu, ļoti liela daļa no tiem ļautiņiem izmanto draugiem.lv iekšējo meilu kā čatu (lai arī diez vai kāds uz to tēmēja). Tā ka nevar paļauties uz to, ka "visi 10k uzreiz nelūrēs" - dzīvē ar tādu pieeju var ieberzties :) Nu ok, katram projektam ir savi apstākļi un noteikumi, dažreiz var gadīties, ka noslodze būs ierobežota. Tomēr, ja noslodze var būt dinamiska (neierobežota), labāk meklēt elastīgāku risinājumu.

Jā, db arī atrodas uz fs, tomēr, kamēr fs pēc idejas ir plika fs ar minimālu kešošanu, dbvs tomēr uztura papildus mehānismus ātrdarbības uzlabošanai lielas datu plūsmas gadījumiem.

Link to comment
Share on other sites


×
×
  • Create New...