MongoDB iesācējiem/pieredze

[Wuu]

Man visu likās, ka man riebj PHP, bet beigās izsecināju ka pie vainas lielākoties ir MySQL.

Pēc meklējumiem un pāris testiem, ļoti iepatikās MongoDB.

 

Tīri teorētiski, API uz MongoDB uzrakstīt ir ļoti ātri. Tāda sajūta, ka tam arī viņa paredzēta.

 

Metu aci arī uz Cassandra, bet negribas redzēt neko tādu.

INSERT INTO users (user_id,  fname, lname)
  VALUES (1745, 'john', 'smith');

Varbūt - ir kas cits, ko notestēt?

 

MongoDB mīnusi:

Nav join'u (Dohh.. katra datubāze paredzēta savām vajadzībām), ir map reduce, bet neesot pietiekami ātrs lai lietotu reālā laika, der tik bacgraundo skaitļot.

Daudz datu replikācijas. Vai ja lieto ID, tas nozīme ka join'i jāveido aplikācijas pusē, vai klienta. (Beigās var izaugt par drausmīgām galvas sāpēm)

Insertu čupu nevar pārbaudīt un nekad nevar būt drošs vai ieraksts tiešām ir veikts. (Mīts?)

 

Varbūt kaut ko esmu palaidis garām?

Kā ar injektiem, kā uz MySQL. Vai var kaut ko ievadīt, kaut kas specifisks jāpārbauda?

 

Kāds varbūt lieto MongoDB production sistēmās, var padalīties ar pieredzi.

[daGrevis]

MongoDB silti neiesaku izmantot (http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/), bet ja esi drošs ka tev **vajag** document storage datubāzi, ir citas, labākas alternatīvas.

 

Anyway, kādi ir tavi iebildumi pret MySQL? Varbūt ar pārslēgšanos uz Postgres būs pietiekami?

[yuppio]

Līdz šim ir bijusi liela pieredze ar MySQL un gads ar MongoDB produkcijā.

 

Tas MongoDB hate, kas šur tur eksistē, pa lielam ir pārspīlēts, imho. Izmantojam produkcijā jau labu laiciņu, nesāp. Katrā ziņā sāp mazāk par MySQL noteikti, kas paralēli vēl eksistē legacy stuffa ziņā :)

 

Bet nu es arī izvēlētos Postgres sākot jaunas lietas, jo viņš līdz ar 9.4 piedāvā jsonb type laukus, kas dod iespēju pa lielam lietot document/json style laukus, tādējādi apvienojot abas divas pasaules. Lietām, kuras ir ļoti dinamiskas un/vai, lai izvairītos no tabulu alterošanas pie katrām sīkām izmaiņām un/vai taisīt 3 tabulas (lai saglabātu normālformas/relācijas), kur viņas pa īstam nevajag, imho JSON fieldi ir baigi laba štelle. Normālas transakcijas un relācijas mēdz būt noderīgas. Testi arī rāda, ka performance viņam ir krietni spēcīgāka par MongoDB (ja projekta scale`am tas vispār ir aktuāli).

 

Pats nesen vienā side projektā piešķīlu Postgresu, pagaidām esmu apmierināts. 

 

EDIT: Par injekcijām: atkarīgs kā izmanto, ja nedara neko īpaši intelektuālu, kā padodot visu WHERE nosacījumu (nevis tikai konkrētos parametrus) no getiem vai tamlīdzīgi, tad injekcijas dabūt nav īpaši viegli, bet protams riski pastāv tāpat, ja nepareizi lieto, bet ir īpaši jāmāk nepareizi lietot, lai uz to uzrautos, ar domu krietni sarežģītāk kā SQL gadījumā. Internetā ir šis tas atrodams, katrā ziņā, ja izmanto kkādu library pa starpu, tad lielākā daļā par to var nedomāt.

 

Vēl ko der atcerēties, "Field names cannot contain dots (i.e. .) or null characters, and they must not start with a dollar sign" http://docs.mongodb.org/master/reference/limits/, uz tā esmu uzrāvies 1x, kad vajadzēja importēt ārējus JSON datus, kur punkti sāpēja.

Edited September 22, 2015 by yuppio

[Wuu]

@deGrevis - lasīts, visus komentārus pat izlasīju. Godīgi sakot nepārliecināja. Izklausās, ka dizains viņiem vienkārši galīgi garām un pats rakstnieks ir vienkārši iedomīgs.

 

MySQL kaut arī risinājumi, es vairs neredzu jēgu dalīt JSON, saglabāt MySQL un tad pēc tam atkal veidot JSON. Viss tas pa vidam vel ir brutāli jāpārbauda.

Sintakse ir reāli debīla, katru reizi kad qwerijs jāraksta, zobi griežas. Ja vel joini klāt, beigās palags. Izlasīt to visu grūti...

 

Ar MongoDB, arrajs kā arrajs. Viss...

 

@yuppio Paldies! Tā kā pārsvara veidoju darba aplikācijas, man tās tabulas ir lieka. Postgres atkal tabulās lien iekšā, atkal jādefinē, jāpārbauda. Es tik nevaru saprast, vai tiešām es varēšu bez join'iem izdzīvot. Laikam būs jāuzkāpj uz grābekļa. 

Edited September 22, 2015 by Wuu

[Roze]

 

MySQL kaut arī risinājumi, es vairs neredzu jēgu dalīt JSON, saglabāt MySQL un tad pēc tam atkal veidot JSON. Viss tas pa vidam vel ir brutāli jāpārbauda.

https://dev.mysql.com/doc/refman/5.7/en/json.html

[codez]

... , bet negribas redzēt neko tādu.

INSERT INTO users (user_id,  fname, lname)
  VALUES (1745, 'john', 'smith');

 

Izmanto ORM.

[briedis]

Izmanto ORM.

 

O, beidzot arī kāds šo pasaka :)

 

ORM var izmantot praktiski visos gadījumos. Kad kaut kas specifisks jādabū - uzrakstam natīvu SQL vai izmantojam query builderi, kas principā ir tāpat kā ORM lietošana.

[Roze]

Bet īsumā pieredze/domas ir šādas (secībai nav nozīme):

 

- MongoDB ir interesants produkts - viegli/ātri uzliekams un samērā vienkārši uzsākt lietot

- Autoto(cluster)scalings reizē ir spožums un posts - ir jauki ka dinamiski iespējams audzēt datubāzi/klusteri "dzīvajā" un aplikācijai par to nav nojausmas, bet tad sākas problēmas ar shard keyiem / chunku migraacijaam utt

- Ir forši monitoringa rīki ( https://www.mongodb.com/cloud/ )

 

 

Pieredze ir apmēram tāda:
- bija paliels risinājums/db (pāris miljardi ierakstu) kas strādāja uz sadalīta (3 instances) MySQL (shārdots aplikācijas pusē) ~ kopā apjoms bija ap 800 Gb +-
- jaunu fīču un vajadzību dēļ tika pieņemts lēmums pāriet (mēģināt) uz Mongo sanāca (3 x 3 cluster instances (MongoDB nepieciešamas 3 replicas lai pieņemtu lēmumus) + apjoms izauga uz kādiem 2Tb (jo tanī brīdī 2.4-2.6.x Mongo nebija nekādu kompresijas iespēju - bija TokuMX, taču tas īsti nestrādāja kopā ar parastajām Mongo instancēm (dažādi oplog formāti) - 3.x Mongo parādijās WiredTiger engine ar kompresiju, bet tad vilciens jau bija garām)

- Tad kādu laiku tika lietots šis risinājums, taču dažādu iemeslu dēļ (nepārdomātas dokumentu struktūras - iekritām uz 16Mb dokumentu limitu utt) un visumā diezgan randomizētas performances (dažādu chunku migrācijas laikā varēja sanākt visādi) - līdz ar to ne prieka ne patikas
- Risinājums tika pārtaisīts atpakaļ uz MySQL + TokuDB engīni (ko tagad nopirka Percona) un ir 1 db instance ar ~280Gb datiem (reālo datu apjoms ir tikai audzis) un viss notiek.

 

Kaut kā tā .. 

[Kavacky]

Jā, ja vienīgais spēcīgais aruments mest nost SQL ir nevēlēšanās skatīties uz kverijiem, nevis specifiskas datu struktūras, tad tam ir labāks risinājums par NoSQL - ORM.

 

Pieredze ir apmēram tāda:

Hehehe, es pat zinu, par ko ir runa. :D

[spainis]

pre 3.0 #yolo database level locks #yolo

[Wuu]

https://dev.mysql.com/doc/refman/5.7/en/json.html

 

Kāds šo lieto? Izklausās pēc aizlāpīta cauruma, kurš jau pie 100mb tabulas aizrīsies ar 500ms pieprasījumu izpildīšanu.

[Roze]

Kāds šo lieto? Izklausās pēc aizlāpīta cauruma, kurš jau pie 100mb tabulas aizrīsies ar 500ms pieprasījumu izpildīšanu.

Kāpēc? Jebšu kādu caurumu?

Ja tik ļoti patīk JSON formāts neredzu iemeslu kāpēc lai nemēģinātu..  Kādi performances rādītāji būs droši vien atkarīgs no konkrēta risinājuma/prasībām/dzelžiem utt .. t.i. droši vien nekas maģisks nenotiks :)

 

 

Katrai rdbms ir daži savdabīgi risinājumi (tāpat piemēram MySQL ir Memcached protokols/interfeiss: http://dev.mysql.com/doc/refman/5.6/en/innodb-memcached.html vai MariaDB piem ir dynamic columns https://mariadb.com/kb/en/mariadb/dynamic-columns/ kurām ar ir JSON "izskats" utt ...

 

Izvirst var līdz nelabumam, piemēram, Handlersocket https://mariadb.com/kb/en/mariadb/handlersocket/ Spider storage engine http://mariadb.com/kb/en/mariadb/spider-storage-engine-core-concepts/  .. un ir NoSQLs uz MySQL bāzes.

 

 

 

Mēs gan neizmantojam konkrēti šo datu tipu bet storējam blobus MySQLā - priekšrocības ir:

- zināms/pierasts interfeiss

- datu kompresija

- replikācija (attiecīgi vienkārši backupi) utt

 

Šeit ir vēl viens Mongodb (no situācijas) mīnuss - ja nekas būtiski nav mainījies tad MongoDB ir apmēram tā, ka principā viņs darbojas pēc Copy-on-write principa, proti lai arī katram dokumentam ir zināms ekstra space/paddings (kādreiz tas kolekcijai tika rēķināts dinamiski kā koeficients tagad šķiet noklusēti ir power-of-2 ja specifiski neizslēdz ( http://docs.mongodb.org/manual/core/storage/#power-of-2-allocation) ) tad brīdī kad dokumenta izmaiņas pārsniedz šo ekstra brīvo vietu viss dokuments/objekts  tiek ierakstīts pa jaunu (ar lielāku padingu).

 

Attiecīgi risinājumos kur notiek bieža dokumentu maiņa vai objekti ir vienmēr augoši (nu piemēram lietotājam masīvā krājās klāt kaut kādi viņa posti utt) kādā brīdī var sanākt daudz izniekotas diskvietas defragmentācijas dēļ (MongoDB automātiski pats neko necompactē http://docs.mongodb.org/manual/reference/command/compact/ kas nav online operācija - attiecīgi jāizpilda replica setā uz sekundārajiem "biedriem" pēc tam mainot masteru.

 

Šobrīd manuprāt gan ir labāk bet 2.x versijā pie tam bija nepieciešams vismaz tikpat daudz diskvietas - proti ja DB aizņēma 500Gb tad tev vajadzēja vēl 500Gb brīvus jo tika taisīta pilna db kopija.

 

 

Protams arī InnoDB ir defragmentācija, bet ne tik lielā mērogā .. tagad šur tur eksperimentējam ar TokuDB kas izmanto fractal tree indeksu tādējādi (vismaz developeri apgalvo) nedefragmentējas (bet ir protams citas ķeskas).

[aaxc]

Negribas but nekrofilam, bet vajag padomu:

 

Tātad, projektā izmantojam mysql produktu tabulu ar papilddatiem.

 

+----------------+

| products       |

+----------------+

| id             |

| name           |

| type           |

| color          |

| image_id       |

| collection_id  |

+----------------+

 

Problēma rodas pievienojot jaunus produktus ar citu tipu, jo tiem ir citi papildus parametri, kā rezultātā nākas paplašināt tabulu:

 

+----------------+

| products       |

+----------------+

| id             |

| name           |

| type           |

| color          |

| image_id       |

| collection_id  |

| width          |

| height         |

| weight         |

| offset_x       |

| offset_y       |

| angle          |

| coordinates    |

| sex            |

| size           |

| ...            |

+----------------+

 

Tākā tuvākās nākotnes plānā ir produktu klāstu palielinat no pārdesmit tipiem uz vairākiem simtiem, šī tabula ātri vien izskatities nelietojama. Veidot subtable vai katram tipam atsevišķas tabulas arī nebūtu prāta darbs.

 

Līdz ar ko ir doma pariet uz MongoDB, kur noradīt produktu, tīpu un pārejo jau kā specifiska tipa/produkta veida parametrus.

Šādi katrs produkts saturētu tikai sev vajadzigo informāciju, kuras struktūre es vēlāk nolasu, lidz ar to man pat nav vairs svariga kopējā struktūra - es izmantoju tikai konkreta produkta parametrus.

 

Idejiski vis izskatas rožaini (pradukti satur tikai nepieciešamos datus, pievienojot jaunus produkturs tabula nav jāčakarē, viegli atfiltrēt, ielasot produktu es uzreiz iegūstu vajadzīgo struktūru, pat nav jāčeko kas tas par tipu), bet tākā pats produkcijā ar liela apjoma mongo datiem neesmu ņēmies ( uz konvertāciju patreiz vien jau aizies 400k+ produktu ar vairākiem miljoniem variāciju ), gribētos dzirdēt no pieredzējušiem lietotājiem potenciālās problēmas, lai nav tā, ka pēc dažiem mēnešiem ir jarauj mati no galvas ārā un jādomā kā to visu pārverst atpakaļ uz mysql.

[daGrevis]

> Veidot subtable vai katram tipam atsevišķas tabulas arī nebūtu prāta darbs.

 

Kāpēc? Vai produktu tipi būs dinamiski, tobiš produktu tipus varēs pievienot/noņemt izmantojot UI?

[aaxc]

Jā, nākotnes doma ir izveidot sistēmu, lai produktus un tipus var operators pats sadefinēt un ievietot pēc iedotās specifikācijas un no scripta līmeņa, nekas nav jāmaina. Šobrīd strādājam pie šīs pamatstruktūras izstrādes/pārveides.