MongoDB iesācējiem/pieredze

[jurchiks]

Kāpēc neder:

CREATE TABLE `product_attributes` (

    product_id INTEGER NOT NULL,

    name VARCHAR(64) NOT NULL,

    value VARCHAR(255) NOT NULL,

    INDEX(name),

    FOREIGN KEY(product_id) REFERENCES products(id) ON DELETE CASCADE

)

?

Edited May 24, 2016 by jurchiks

[aaxc]

Patreiz, ar 18 produktiem, ir 397k šādi ieraksti (tie pie tam ir mēnesi veci dati, prodā ir 430k patreiz). Kas notiks, ja man produkti būs 180 ? 500? Un tas ir tikai pirmais vilnis. Man vajag ieilkt pamatu sistēmai, kas strādās ar 10k+ produktiem un tad šāda struktūra būs vēl mazāk pārskatāma.

[Kavacky]

Patreiz, ar 18 produktiem, ir 397k šādi ieraksti (tie pie tam ir mēnesi veci dati, prodā ir 430k patreiz). Kas notiks, ja man produkti būs 180 ? 500?

Tad būs attiecīgi 3.97 * 10^6 un 1.1 * 10^7 ieraksti. Kas tad tur tāds, kā arī kas tur būtu nepārskatāms? "SELECT * FROM `product_attributes` WHERE `product_id`=X" un tu visu redzi. Tāpat tu vari uztaisīt "WHERE `name`='color' AND `value`='red'" un dabūsi visus produktus sarkanā krāsā. Pagaidām viss izskatās ok.

[aaxc]

Protams, tas ir viens no variantiem, kā atrisināt šo situāciju, bet jautājums ir ātrdarbībā.

 

Kas būs ātrāk izfiltrēt: mongodb datus vai šādus? Cik es sapratu, monogo vajadzētu ātrāk apstrādāt šāda veida filtrēšanu.

[Kavacky]

Index sila, table scan mogila.

[Wuu]

Nav ko filozofēt, ir dati, taisi testus. Pats pārgāju no MySql un atpakaļ neskatos. Nu nav nepieciešama tā striktā SQL valoda un tabulu vide, ja vien nav svarīgās transakcijas. Pats šobrīd strādāju vienā projektā, kur ir PostgreSQL, nošaujiet mani ar tie qverijiem... PostgresSQL lepojas ar JSON atbalstu, dirsā tādu atbalstu.

 

Tie limiti vairs neatmaksājas, skaidrs, kādreiz bija dārgi procesoru cikli un cietā diska vieta, bet mūsdienās... Svarīgi, lai ātri strādā un viegli lietojama. Ja tev tupi vajag katalogu, kurā rakstīt un nolasīt, MongoDB ir tieši tam paredzēta.

Pats izgāju bezmaksas kursus https://university.mongodb.com/

 

No pēdējiem MongoDB testiem. Full text meklēšana, 400k ierakstos, izpildās 44ms. Ja nemaldos, index bija lielāks par pašu datubāzi :D

 

Bet principā, tu vari mysql tabulā uztaisīt json lauciņu, kur glabāt mainīgos datus. Es tavā vietā, tā arī darītu. Nav ko jaunus spieķus savos darba projektos vilkt.

Edited May 24, 2016 by Wuu

[Kavacky]

Sprunguļus, sprunguļus, nevis spieķus.

[F3llony]

Mongo lieto 2 veidu devi - tie, kam vajag document-store un tajā glabā document-alike datus, un tie, kas ir slinki nejēgas. 
 
Mongo spēks ir semi-schema-free agregācijas un map-reduce. Pilsoņi, kas mongo izmanto kā datubāzi vienkāršam CRUD ir pilnībā nafig saspiedušies. Tas ir tas pats, kas Casandrā glabāt blogpostus savam kaķu blogam vai Hadoop pirkumu sarakstus rakstīt. Un devi, kas izdomājuši glabāt Mongo jebko, ko nevar atļauties prosta izdzēst un/vai zaudēt imo ir pilnīgi tizleņi.

If you want to sleep at night, don't click here.
 
@aaxc Tava problēma ir ka Tu vēlies column-alike datus glabāt row-like struktūrā. Tātad, kas tie par datiem? Vai pēc visiem šiem datiem Tu jēlkad meklēsi vai kaut kā ar jamiem darbosies? Vai tev tiešām nepieciešamas 10,000 "kolonnas"? Varbūt viss ko tev vajag ir glabāt šos parametrus vienā kolonnā DB saserializētu + vienkārši tos barot kādam search engine, kas ir paredzēts meklēšanai, piemēram, Ellasticsearch? Jo tā tabula baigi jau nu izskatās pēc metadatiem, pret kuriem veic meklēšanu and stuff.

Edited May 24, 2016 by F3llony

[jurchiks]

Skaidrs ir viens - ja ir atribūti, kas ir vienam produktam, bet nav otram, tad kolonnas automātiski nav pareizais risinājums.

Varētu jau vēl darīt tā, ka definē produkta tipu un tam atbilstošos atribūtus, un katram produkta tipam ir sava tabula ar pareizajām atribūtu kolonnām, bet tas ir baigi nesmuki, ja tos tipus jādefinē caur UI, un vēl nesmukāk, ja atribūti var mainīties.

 

`product_attributes` ir normāls vidusceļš starp 2 galējībām; nav nekādu problēmu pielikt vai noņemt atribūtus, nav arī limita atribūtu skaitam. Ja vēl šo tabulu kaut kā kešo, tad vispār nav problēmu.

[Pats Toms]

Patreiz, ar 18 produktiem, ir 397k šādi ieraksti (tie pie tam ir mēnesi veci dati, prodā ir 430k patreiz). Kas notiks, ja man produkti būs 180 ? 500? Un tas ir tikai pirmais vilnis. Man vajag ieilkt pamatu sistēmai, kas strādās ar 10k+ produktiem un tad šāda struktūra būs vēl mazāk pārskatāma.

 

Nesaprotu par ko ir šī diskusija. Aši uzģenerēju demo.

 

https://gist.github.com/patsToms/8819abf751a5b0726c60094041b8edc5

 

Es esmu diezgan pārliecināts, ka šeit nevajadzētu būt problēmām, ja izmanto mysql, vai vienalga, nevis MS Excell.

Edited May 24, 2016 by Pats Toms

[jurchiks]

Kāpēc products_attributes tabulai ID kolonna? Unikalitāte rodas no product_id + attribute_id kombo, tāpēc vajag UNIQUE (product_id, attribute_id). Bez UNIQUE indeksa ID īstenībā var nemaz nebūt unikāls, ja 2 ieraksti ir ar vienādu product_id + attribute_id kombo.

 

Nu un vēl ir tā, ka ja vērtība atrodas tabulā products_attributes, kur katra vērtība ir piesaistīta katram produktam, tad sanāk, ka ja 10 produktiem ir vienāda atribūta vērtība, tad datubāzē ir 10 vienādi teksta ieraksti atribūta vērtībai. Not very nice. Labāk tad tā:

 

attributes:

   id, name

attribute_values:

   attribute_id, name

products:

   id, name, whatever else

product_attributes:

  product_id, attribute_value_id (+ join attribute_values.attribute_id, + join attributes.name pēc id)

 

Jā, varbūt nav diez ko smuki, toties nav data duplication, un nav katram produktam ar roku jāraksta atribūta vērtība.

Edited May 24, 2016 by jurchiks

[Pats Toms]

Piekrītu. Es tabulas taisīju diezgan automātiski, bet es pieņemu, ka tas neietekmē rezultāta izpildes ilgumu.

 

EDIT: es piekrītu tam, ko viņš apgalvoja pirms rediģēšanas, t.i., par pirmo teikumu. Tam tālāk es ne pārāk piekrītu, bet tās, iespējams, ir detaļas, kuras šoreiz, manuprāt, tik un tā nav svarīgas.

Edited May 24, 2016 by Pats Toms

[jurchiks]

Jā, izpildes ātrumu tas ietekmē minimāli, bet DRY gan datubāzēs ir svarīgs, it īpaši, ja ir plānoti 10k+ produkti ar tonnu atribūtu.

[Mr.Key]

Apmēram kā jurchiks.

 

Problēma ar custom produktu veidiem ir tipiska un jau kopš ekomercijas sākuma, kopš pirmajiem ERP. Diez vai tur kaut ko jaunu vajag izdomāt. Pameklē sources no Magento. Es pats šādu risinājumu veiksmīgi saveidoju pirms gadiem 10+, bija gan produktu veidi, gan katram veidam savi atribūti un katram atribūtam gan custom parametri, gan predefined sets, utml., respektīvi daudz iespēju un viss tas, kas te cilvēkam bija vajadzīgs viņa shop projektam. Arī toreiz paskatījos idejas citos tā brīža projektos. Ar pilnu pārliecību varu teikt, ka tā ir problēma, kurai vienkārši pietiek atrast vienu best practice un implementēt.

 

Pēc tam ātrdarbību var risināt ar ģenerēšanu, indeksiem un vēl visādi. 

 

Mysql un relāciju shēmas gadījumā vispār ir jāņem vērā, ka pievienot vienu kolonnu tabulai ar 100k ierakstiem būs daudz sāpīgāk, nekā pievienot 100k ierakstus pārdomātā struktūrā.

 

Ieteikums liekot mongodb, jo nav saprašanas pa relāciju db priekšrocībām ir vispār diezgan funny. Programmēt, neizprotot vispārīgus datubāžu konceptus (vnalga, vai mysql, pgsql vai random sql) - arī funny pieeja darbam.

 

Atrada "x ms" neko neizsaka. daudz ko nosaka cache siltums, utt., baigi daudz visa kā.

Edited May 25, 2016 by Mr.Key

[Wuu]

Es domāju vairākums projektu no tabulu datubāzēm, nekāda labuma. Tas ir vienkārši pieradums, ja vien neesi kaut kāds sociālais portāls un bez joiniem nu nekā... Protams, ir grūti pārslēgties no tabulu domāšanas uz dokumentu tipu. personīgi nodarbojos ar industriālo softu, tur MongoDB spīd. Neviena join'a pēdēja projektā, pieprasījums pēc izmaiņām ir visu laiku, paldies dievam ka man nav nekādās tabulās jālien.

 

Ja man būtu jāveido preču katalogs, kas principā ir dokumentu čupa. Tad tikai MongoDB.