Ja pēdējos gados esat izveidojis vidēja vai liela mēroga tīmekļa lietojumprogrammu, jūs, iespējams, apsvērāt iespēju balstīties uz atvērtā koda LAMP vai MEAN kaudzi. Vecākā LAMP kaudze izmanto Linux operētājsistēmu, Apache tīmekļa serveri, MySQL relāciju datu bāzi un PHP programmēšanas valodu. MEAN izmanto MongoDB NoSQL datu bāzi, Express back-end tīmekļa lietojumprogrammu ietvaru, Angular lietojumprogrammu platformu un Node.js JavaScript izpildlaiku. MEAN būtībā ir pilna gala JavaScript kaudze. Linux nav skaidri minēts saīsinājumā, bet parasti tā ir operētājsistēma zem mezgla.
Šajā pārskatā es apspriedīšu MongoDB datu bāzi, tagad ar 4. versiju. MongoDB ir ļoti mērogojama, operatīva datu bāze, kas pieejama gan atvērtā koda, gan komercuzņēmumu versijās, un to var palaist lokāli vai kā pārvaldītu mākoņpakalpojumu. Pārvaldīto mākoņpakalpojumu sauc par MongoDB Atlas.
MongoDB ir vispopulārākais no NoSQL datu bāzēm. Tās dokumentu datu modelis nodrošina izstrādātājiem lielu elastību, savukārt tā izplatītā arhitektūra ļauj nodrošināt lielu mērogojamību. Tā rezultātā MongoDB bieži izvēlas lietojumprogrammām, kurām jāpārvalda liels datu apjoms, kuras gūst labumu no horizontālās mērogojamības un kuras apstrādā datu struktūras, kas neatbilst relāciju modelim.
Tā kā MongoDB ir piemērots dažādiem lietojuma gadījumiem, to bieži izvirza kā relāciju datu bāzu aizstājēju. Tomēr, lai gan brīvība no stingriem shēmas ierobežojumiem bieži ir izdevīga, ir svarīgi paturēt prātā, ka neviena dokumentu datu bāze nav universāls risinājums - pat MongoDB.
MongoDB izcelsme
Uzņēmumu, kas atrodas aiz MongoDB, 2007. gadā kā 10gen nodibināja komanda, kas atradās aiz interneta reklāmas uzņēmuma DoubleClick. Sākotnējā MongoDB datu bāzes motivācija bija spēja tikt galā ar veiklību un mērogu, kas nepieciešams interneta reklāmai. Kā mēroga piemēru DoubleClick 2007. gadā rādīja 400 000 reklāmu sekundē un cīnījās par veiktspēju ar tā laika esošajām datu bāzēm.
MongoDB ir uz dokumentiem balstīts veikals, kuram virs tā ir ieviests arī uz diagrammām balstīts veikals. Citi NoSQL datu bāzu veidi ir atslēgas vērtību veikali un kolonnu veikali. Visu veidu NoSQL datu bāzēm ir kopīga spēja paplašināt veidus, kas nebija iespējami 2007. gada SQL relāciju datu bāzēs, taču dažādām NoSQL datu bāzu šķirnēm ir atšķirīgas stiprās puses, vājās puses un izmantošanas gadījumi.
Daži no galvenajiem NoSQL konkurentiem MongoDB kā operatīvajām datu bāzēm ir Amazon DynamoDB (atslēgu vērtību veikals), Google Cloud BigTable (kolonnu veikals), Google Cloud Datastore (dokumentu veikals), Redis (atmiņā, atslēgu vērtību veikals), Couchbase (vairāku modeļu atslēgu vērtību un dokumentu krātuve), DataStax / Cassandra (kolonnu krātuve) un Azure Cosmos DB (daudzmodelis, kas ietver SQL opciju, kā arī vairāki NoSQL veikali).
Kas ir MongoDB?
MongoDB Inc. apraksta MongoDB kā “dokumentu datu bāzi ar vajadzīgo mērogojamību un elastību, izmantojot vaicājumus un indeksēšanu, kas jums nepieciešama”. Lai to analizētu, mums vispirms ir jāsaprot dokumentu datu bāzes būtība, kas ir viens no NoSQL dizaina veidiem.
Tā vietā, lai stingri ierakstītus datus uzglabātu saistītās normalizētās tabulās ar fiksētām shēmām, piemēram, relāciju datu bāzi, dokumentu datu bāzē saistītie dati tiek glabāti nenormalizētā formā, kas iegulti JSON veida nosaukuma dokumentos. Tomēr MongoDB faktiski neglabā JSON: MongoDB glabā BSON (bināro JSON), kas paplašina JSON attēlojumu (virknes), iekļaujot tajā papildu veidus, piemēram, int
, ilgi
, datums
, peldošais punkts
, decimāldaļa128
un ģeotelpiskās koordinātas, kā parādīts zemāk redzamajā diagrammā. BSON dokumentos ir viens vai vairāki lauki, un katrā laukā ir noteikta datu veida vērtība, ieskaitot masīvus, bināros datus un apakšdokumentus. BSON izseko arī katra dokumenta lielumu, lai varētu efektīvi meklēt.
BSON rakstīšana ievada lauku indeksēšanu. MongoDB uz vienas datu kopijas var ģenerēt multimodālus grafiskos, ģeotelpiskos, B-koka un pilna teksta rādītājus, izmantojot datu tipu, lai ģenerētu pareizu indeksa tipu. MongoDB ļauj jums izveidot indeksus jebkurā dokumenta laukā.
MongoDBMongoDB ir datu bāzes, kolekcijas (tabulas), dokumenti (rindas), lauki (kolonnas), indeksi, $ uzmeklēšana
vai iegulti dokumenti (pievienošanās), primārās atslēgas, apkopošanas cauruļvads un darījumi. Lai nodrošinātu labāku veiktspēju un izvairītos no vairāku dokumentu transakcijām, iespējams, MongoDB vēlaties izmantot apakšdokumentus un masīvus, nevis glabāt datus normalizētā formā, kā to darītu SQL datu bāzē.
MongoDB 4 dara ir vairāku dokumentu darījumi, kas nozīmē, ka jūs joprojām varat iegūt ACID rekvizītus, pat ja jums ir jā normalizē datu dizains. Iepriekšējās versijas to nedarīja.
Par to, kas ir tā vērts, MongoDB pārstāvji man teica, ka ar viena dokumenta darījumiem tiek apstrādāti 90 procenti gadījumu, kuriem nepieciešamas ACID īpašības. Kad klientiem bija nepieciešama ACID vairāku dokumentu darījumiem pirms 4. versijas, viņi to galvenokārt ieviesa lietojumprogrammas līmenī.
Pēc noklusējuma MongoDB izmanto dinamiskas shēmas, kuras dažreiz sauc arī par shēmām mazāk. Dokumenti vienā kolekcijā to dara nē jābūt vienādam lauku kopumam, un lauka datu tips var atšķirties dažādos kolekcijas dokumentos. Jebkurā laikā varat mainīt dokumentu struktūru.
Shēmas pārvaldība tomēr ir pieejama. Sākot ar MongoDB 3.6, MongoDB atbalsta JSON shēmas validāciju. Lai to ieslēgtu, izmantojiet $ jsonSchema
operators jūsu validatora izteiksmē. Apstiprināšana notiek atjauninājumu un ievietošanas laikā.
Kā redzat dokumentācijas momentuzņēmumā un zemāk redzamajā MongoDB Atlas ekrānuzņēmumā, MongoDB ir sava vaicājuma valoda, kas ieviesta Mongo čaulā, 12 atbalstītās valodas draiveru API (un daudzās citās no kopienas), kā arī Compass GUI un Cilne Atlas kolekcijas (Datu pārlūks). MongoDB vaicājuma valoda nebūt nav tāda pati kā SQL, taču starp abiem ir vairāk vai mazāk tieša kartēšana. Es saku “vairāk vai mazāk”, jo relāciju datu bāzes neatbalsta iegultos dokumentus, bet MongoDB atbalsta. Tas nav obligāti visi labi, kā redzēsiet nākamajā sadaļā.
MongoDB MongoDBMongoDB apkopošanas sistēmā tiek izmantoti cauruļvadu operatori, kas vairāk vai mazāk ir līdzvērtīgi SQL GRUPA PĒC
un KUR
klauzulas. Piemēram, šāds vaicājums izmanto MongoDB lietotāju grupu datu bāzi, lai Mongo čaulā uzskaitītu iepriekšējo notikumu un katra notikuma kopējās atbildes:
> db.past_events.aggregate ([{'$ match': {'batchID': 101, 'event.status': 'past', 'event.group.urlname': {'$ in': ['Atlanta-MongoDB -User-Group ',' Austin-MongoDB-User-Group ',' Baltimore-MongoDB-Users-Group ',' Bangalore-MongoDB-User-Group ',' Belfast-MongoDB-User-Group ',' Bergen-NoSQL ',' Bordeaux-MongoDB-User-Group ',' Boston-MongoDB-User-Group ']}}},{'$ group': {'_id': {'urlname': '$ event.group.urlname', 'gads': {'$ year': '$ event.time'}}, 'event_count': {' $ sum ': 1},' rsvp_count ': {' $ sum ':' $ event.yes_rsvp_count '}}},
{'$ project': {'_id': 0, 'group': '$ _id.urlname', 'year': '$ _id.year', 'event_count': 1, 'rsvp_count': 1}}])
Vaicājumā tiek izmantots apkopot
funkcija ar $ spēles
, $ in
, $ grupa
, $ summa
, un $ projekts
operatori un atgriež:
{"event_count": 2, "rsvp_count": 27, "group": "Boston-MongoDB-User-Group", "gads": 2017}{"event_count": 5, "rsvp_count": 94, "group": "Boston-MongoDB-User-Group", "gads": 2016}
{"event_count": 5, "rsvp_count": 231, "group": "Boston-MongoDB-User-Group", "gads": 2015}
{"event_count": 3, "rsvp_count": 175, "group": "Boston-MongoDB-User-Group", "gads": 2014}
{"event_count": 10, "rsvp_count": 489, "group": "Boston-MongoDB-User-Group", "gads": 2013}
{"event_count": 12, "rsvp_count": 444, "group": "Boston-MongoDB-User-Group", "gads": 2012}
{"event_count": 2, "rsvp_count": 118, "group": "Boston-MongoDB-User-Group", "gads": 2011}
{"event_count": 6, "rsvp_count": 84, "group": "Atlanta-MongoDB-User-Group", "gads": 2011}
{"event_count": 3, "rsvp_count": 74, "group": "Baltimore-MongoDB-Users-Group", "gads": 2012}
{"event_count": 1, "rsvp_count": 5, "group": "Bergen-NoSQL", "gads": 2015}
{"event_count": 15, "rsvp_count": 286, "group": "Atlanta-MongoDB-User-Group", "gads": 2012}
{"event_count": 11, "rsvp_count": 321, "group": "Baltimore-MongoDB-Users-Group", "gads": 2013}
{"event_count": 8, "rsvp_count": 124, "group": "Bangalore-MongoDB-User-Group", "gads": 2015}
{"event_count": 6, "rsvp_count": 381, "group": "Bangalore-MongoDB-User-Group", "gads": 2013}
{"event_count": 7, "rsvp_count": 242, "group": "Bangalore-MongoDB-User-Group", "gads": 2012}
{"event_count": 13, "rsvp_count": 233, "group": "Atlanta-MongoDB-User-Group", "gads": 2013}
{"event_count": 10, "rsvp_count": 171, "group": "Baltimore-MongoDB-Users-Group", "gads": 2014}
{"event_count": 3, "rsvp_count": 28, "group": "Austin-MongoDB-User-Group", "gads": 2017}
{"event_count": 2, "rsvp_count": 52, "group": "Austin-MongoDB-User-Group", "gads": 2016}
{"event_count": 1, "rsvp_count": 8, "group": "Atlanta-MongoDB-User-Group", "gads": 2018}
Ierakstiet "it", lai iegūtu vairāk
>
MongoDB ir arī a mapSamazināt
funkciju. Compass GUI ir apkopošanas cauruļvadu veidotājs, kas padara tādu vaicājumu izveidi kā iepriekš minēto diezgan vienkāršu.
MongoDB atbalsta virkni servera datu konsekvences līmeņu, sākot ar lasīt bez saistībām un došanās uz cēloņsakarība. Cēloņsakarība tika pievienota tikai 3.6 versijā, un tā tiek atbalstīta arī klientu sesijās. Klients iestata lasīšanu un rakstīšanu bažas lai norādītu vēlamo konsistences līmeni.
Programmā MongoDB rakstīšanas operācija ir atoma viena dokumenta līmenī, pat ja šī darbība vienā dokumentā modificē vairākus iegultus dokumentus. Kad viena rakstīšanas operācija (piem., db.collection.updateMany ()
) modificē vairākus dokumentus, katra dokumenta modifikācija ir atomu, bet darbība kopumā nav atomu. Sākot ar 4.0 versiju, MongoDB situācijās, kad vairāku dokumentu atjauninājumiem ir nepieciešama atribūtika vai konsekvence starp lasījumiem uz vairākiem dokumentiem, nodrošina repliku kopu darījumus ar vairākiem dokumentiem, par veiktspējas izmaksām.