14 რამ, რაც მინდა ვიცოდე MongoDB-ის დაწყებამდე

სტატიის თარგმანი მომზადდა კურსის დაწყების წინა დღეს "არარელატიური მონაცემთა ბაზები".

მაჩვენებლები:

• ძალზე მნიშვნელოვანია სქემის შემუშავება, მიუხედავად იმისა, რომ ის არჩევითია MongoDB-ში.
• ანალოგიურად, ინდექსები უნდა შეესაბამებოდეს თქვენს სქემას და წვდომის ნიმუშებს.
• მოერიდეთ დიდი ობიექტების და დიდი მასივების გამოყენებას.
• ფრთხილად იყავით MongoDB პარამეტრებთან, განსაკუთრებით მაშინ, როდესაც საქმე ეხება უსაფრთხოებას და საიმედოობას.
• MongoDB-ს არ აქვს შეკითხვის ოპტიმიზატორი, ამიტომ ფრთხილად უნდა იყოთ შეკითხვის ოპერაციების შესრულებისას.

მე ძალიან დიდი ხანია ვმუშაობ მონაცემთა ბაზებთან, მაგრამ ახლახანს აღმოვაჩინე MongoDB. არის რამდენიმე რამ, რაც ვისურვებდი ვიცოდე, სანამ მასთან მუშაობას დავიწყებდი. როდესაც ადამიანს უკვე აქვს გამოცდილება გარკვეულ სფეროში, მას აქვს წინასწარ ჩამოყალიბებული წარმოდგენები იმის შესახებ, თუ რა არის მონაცემთა ბაზები და რას აკეთებს. იმ იმედით, რომ სხვებს გაუადვილდებათ გაგება, წარმოგიდგენთ გავრცელებული შეცდომების ჩამონათვალს.

MongoDB სერვერის შექმნა ავთენტიფიკაციის გარეშე

სამწუხაროდ, MongoDB დაინსტალირებულია ავთენტიფიკაციის გარეშე ნაგულისხმევად. ლოკალურად ხელმისაწვდომი სამუშაო სადგურისთვის, ეს პრაქტიკა ნორმალურია. მაგრამ რადგან MongoDB არის მრავალ მომხმარებლის სისტემა, რომელსაც უყვარს მეხსიერების დიდი მოცულობის გამოყენება, უკეთესი იქნება, თუ მას დააყენებთ სერვერზე რაც შეიძლება მეტი ოპერატიული მეხსიერებით, თუნდაც მის გამოყენებას მხოლოდ განვითარებისთვის აპირებთ. სერვერზე ინსტალაცია ნაგულისხმევი პორტის საშუალებით შეიძლება იყოს პრობლემური, განსაკუთრებით იმ შემთხვევაში, თუ რაიმე Javascript კოდი შეიძლება შესრულდეს მოთხოვნაში (მაგალითად, $where როგორც იდეა ინექციები).

არსებობს ავთენტიფიკაციის რამდენიმე მეთოდი, მაგრამ ყველაზე მარტივი მომხმარებლის ID/პაროლის დაყენებაა. გამოიყენეთ ეს იდეა, სანამ ფიქრობთ ლამაზად ავთენტიფიკაციაზე დაფუძნებული LDAP. რაც შეეხება უსაფრთხოებას, MongoDB მუდმივად უნდა განახლდეს და ჟურნალები ყოველთვის უნდა შემოწმდეს არაავტორიზებული წვდომისთვის. მაგალითად, მე მომწონს სხვა პორტის არჩევა ნაგულისხმევ პორტად.

არ დაგავიწყდეთ თავდასხმის ზედაპირის MongoDB-თან მიბმა

MongoDB უსაფრთხოების შემოწმების სია შეიცავს კარგ რჩევებს ქსელში შეჭრისა და მონაცემთა გაჟონვის რისკის შესამცირებლად. ადვილია მისი ამოღება და იმის თქმა, რომ განვითარების სერვერს არ სჭირდება უსაფრთხოების მაღალი დონე. თუმცა, ეს არც ისე მარტივია და ეს ეხება ყველა MongoDB სერვერს. კერძოდ, თუ არ არსებობს გამოსაყენებლად დამაჯერებელი მიზეზი mapReduce, group ან $ სად, თქვენ უნდა გამორთოთ თვითნებური კოდის გამოყენება JavaScript-ში კონფიგურაციის ფაილში ჩაწერით javascriptEnabled:false. ვინაიდან მონაცემთა ფაილები არ არის დაშიფრული სტანდარტულ MongoDB-ში, აზრი აქვს MongoDB-ით გაშვებას თავდადებული მომხმარებელი, რომელსაც აქვს სრული წვდომა ფაილებზე, მხოლოდ მასზე შეზღუდული წვდომით და ოპერაციული სისტემის საკუთარი ფაილების წვდომის კონტროლის გამოყენების შესაძლებლობით.

შეცდომა მიკროსქემის შემუშავებისას

MongoDB არ იყენებს სქემას. მაგრამ ეს არ ნიშნავს იმას, რომ სქემა არ არის საჭირო. თუ გსურთ დოკუმენტების შენახვა რაიმე თანმიმდევრული ნიმუშის გარეშე, მათი შენახვა შეიძლება იყოს სწრაფი და მარტივი, მაგრამ მოგვიანებით მათი მოძიება შეიძლება იყოს რთული. ჯანდაბა მძიმე.

კლასიკური სტატია "6 ცერის წესი MongoDB სქემის დიზაინისთვის" ღირს წაკითხვა და მსგავსი თვისებები Schema Explorer მესამე მხარის ინსტრუმენტში Studio 3T, ღირს გამოყენება სქემების რეგულარული შემოწმებისთვის.

ნუ დაგავიწყდებათ დალაგების თანმიმდევრობა

დალაგების წესრიგის დავიწყებამ შეიძლება გამოიწვიოს მეტი იმედგაცრუება და მეტი დროის დაკარგვა, ვიდრე ნებისმიერი სხვა არასწორი კონფიგურაცია. სტანდარტულად MongoBD იყენებს ორობითი დალაგება. მაგრამ ნაკლებად სავარაუდოა, რომ ეს ვინმესთვის სასარგებლო იყოს. საქმეებისადმი მგრძნობიარე, აქცენტისადმი მგრძნობიარე, ორობითი ჯიშები გასული საუკუნის 80-იან წლებში მძივებთან, ქაფტანებთან და ხვეულ ულვაშებთან ერთად ცნობისმოყვარე ანაქრონიზმებად ითვლებოდა. ახლა მათი გამოყენება მიუტევებელია. რეალურ ცხოვრებაში „მოტოციკლი“ იგივეა, რაც „მოტოციკლი“. და "ბრიტანეთი" და "ბრიტანეთი" იგივე ადგილია. პატარა ასო უბრალოდ დიდი ასოს დიდი ექვივალენტია. და ნუ დამიწყებ დიაკრიტიკის დახარისხებას. MongoDB-ში მონაცემთა ბაზის შექმნისას გამოიყენეთ აქცენტისადმი მგრძნობიარე შეკრება და რეგისტრაცია, რომლებიც შეესაბამება ენას და სისტემის მომხმარებლის კულტურა. ეს გაადვილებს სიმებიანი მონაცემების ძიებას.

შექმენით კოლექციები დიდი დოკუმენტებით

MongoDB სიამოვნებით უმასპინძლებს დიდ დოკუმენტებს 16 მბ-მდე კოლექციებში და GridFS შექმნილია 16 მბ-ზე დიდი ზომის დოკუმენტებისთვის. მაგრამ მხოლოდ იმის გამო, რომ დიდი დოკუმენტები შეიძლება იქ განთავსდეს, მათი შენახვა არ არის კარგი იდეა. MongoDB საუკეთესოდ იმუშავებს, თუ შეინახავთ ცალკეულ დოკუმენტებს, რომელთა ზომაა რამდენიმე კილობაიტი, უფრო მეტად მოექცევით მათ რიგებს ფართო SQL ცხრილში. დიდი დოკუმენტები იქნება პრობლემების წყარო პროდუქტიულობა.

დოკუმენტების შექმნა დიდი მასივებით

დოკუმენტები შეიძლება შეიცავდეს მასივებს. უმჯობესია, თუ მასივის ელემენტების რაოდენობა შორს არის ოთხნიშნა რიცხვისგან. თუ ელემენტები მასივს ხშირად ემატება, ის გადააჭარბებს მის შემცველ დოკუმენტს და საჭირო იქნება გადაადგილება, რაც ნიშნავს რომ საჭირო იქნება განაახლეთ ინდექსებიც. დიდი მასივის მქონე დოკუმენტის ხელახალი ინდექსირებისას, ინდექსები ხშირად გადაიწერება, რადგან არსებობს ჩანაწერი, რომელიც ინახავს მის ინდექსს. ეს ხელახალი ინდექსირება ასევე ხდება დოკუმენტის ჩასმის ან წაშლისას.

MongoDB-ს აქვს რაღაც ე.წ "შევსების ფაქტორი", რომელიც უზრუნველყოფს დოკუმენტების გაზრდის ადგილს ამ პრობლემის მინიმუმამდე შესამცირებლად.
შეიძლება ფიქრობთ, რომ შეგიძლიათ გააკეთოთ მასივის ინდექსირების გარეშე. სამწუხაროდ, ინდექსების ნაკლებობამ შესაძლოა სხვა პრობლემები შეგიქმნათ. ვინაიდან დოკუმენტები სკანირებულია თავიდან ბოლომდე, მასივის ბოლოს ელემენტების ძებნას უფრო მეტი დრო დასჭირდება და ასეთ დოკუმენტთან დაკავშირებული ოპერაციების უმეტესობა იქნება ნელი.

არ დაგავიწყდეთ, რომ აგრეგაციის ეტაპების თანმიმდევრობა მნიშვნელოვანია

მონაცემთა ბაზის სისტემაში შეკითხვის ოპტიმიზატორით, თქვენს მიერ დაწერილი მოთხოვნები არის ახსნა იმისა, რისი მიღება გსურთ და არა როგორ მიიღოთ იგი. ეს მექანიზმი მუშაობს რესტორანში შეკვეთის ანალოგიით: ჩვეულებრივ, თქვენ უბრალოდ უკვეთავთ კერძს და არ აძლევთ დეტალურ მითითებებს მზარეულს.

MongoDB-ში თქვენ ავალებთ მზარეულს. მაგალითად, თქვენ უნდა დარწმუნდეთ, რომ მონაცემები გადის reduce რაც შეიძლება ადრე მილსადენის გამოყენებით $match и $projectდა დახარისხება ხდება მხოლოდ მას შემდეგ reduceდა რომ ძიება ხდება ზუსტად იმ თანმიმდევრობით, როგორც გსურთ. შეკითხვის ოპტიმიზატორის არსებობა, რომელიც გამორიცხავს არასაჭირო სამუშაოს, ოპტიმალურად აწესრიგებს ნაბიჯებს და ირჩევს შეერთების ტიპებს, შეიძლება გაგაფუჭოთ. MongoDB-ით თქვენ გაქვთ მეტი კონტროლი მოხერხებულობის ფასად.

ინსტრუმენტები, როგორიცაა სტუდია 3T გაამარტივებს აგრეგაციის მოთხოვნების აგებას MongoDB. აგრეგაციის რედაქტორის ფუნქცია საშუალებას გაძლევთ გამოიყენოთ მილსადენის განცხადებები ერთ ეტაპად და შეამოწმოთ შეყვანის და გამომავალი მონაცემები თითოეულ ეტაპზე, გამართვის გამარტივებისთვის.

სწრაფი ჩაწერის გამოყენება

არასოდეს დააყენოთ MongoDB ჩაწერის პარამეტრები მაღალი სიჩქარით, მაგრამ დაბალი საიმედოობით. ეს რეჟიმი "ჩაიწერეთ და დაივიწყეთ" სწრაფად ჩანს, რადგან ბრძანება ბრუნდება ჩაწერის დაწყებამდე. თუ სისტემა დაიშლება მონაცემების დისკზე ჩაწერამდე, ის დაიკარგება და არათანმიმდევრულ მდგომარეობაში აღმოჩნდება. საბედნიეროდ, 64-ბიტიან MongoDB-ს ჩართული აქვს შესვლა.

MMAPv1 და WiredTiger შესანახი ძრავები იყენებენ ანგარიშს ამის თავიდან ასაცილებლად, თუმცა WiredTiger-ს შეუძლია ბოლო თანმიმდევრულობამდე აღდგენა საკონტროლო წერტილი, თუ შესვლა გამორთულია.

Journaling უზრუნველყოფს მონაცემთა ბაზის თანმიმდევრულ მდგომარეობას აღდგენის შემდეგ და ინახავს ყველა მონაცემს, სანამ არ ჩაიწერება ჟურნალში. ჩანაწერების სიხშირის კონფიგურაცია ხდება პარამეტრის გამოყენებით commitIntervalMs.

ჩანაწერებში რომ დარწმუნდეთ, დარწმუნდით, რომ ჩანაწერი ჩართულია კონფიგურაციის ფაილში (storage.journal.enabled)და ჩანაწერების სიხშირე შეესაბამება იმ ინფორმაციის რაოდენობას, რომლის დაკარგვაც შეგიძლიათ.

დახარისხება ინდექსის გარეშე

ძიების და აგრეგაციისას ხშირად ჩნდება მონაცემების დახარისხების საჭიროება. ვიმედოვნებთ, რომ ეს კეთდება ერთ-ერთ ბოლო ეტაპზე, შედეგის გაფილტვრის შემდეგ, რათა შემცირდეს დახარისხებული მონაცემების რაოდენობა. და ამ შემთხვევაშიც კი დაგჭირდებათ დახარისხებისთვის ინდექსი. შეგიძლიათ გამოიყენოთ ერთი ან რთული ინდექსი.

თუ არ არის შესაფერისი ინდექსი, MongoDB გააკეთებს მის გარეშე. მეხსიერების ლიმიტია 32 მბ ყველა დოკუმენტის საერთო ზომაზე დახარისხების ოპერაციებიდა თუ MongoDB მიაღწევს ამ ლიმიტს, მაშინ ის ან შეცდომას გაუშვებს ან დაბრუნდება ცარიელი ჩანაწერების ნაკრები.

ძიება ინდექსის მხარდაჭერის გარეშე

საძიებო მოთხოვნები ასრულებენ SQL-ში JOIN ოპერაციის მსგავს ფუნქციას. საუკეთესოდ მუშაობისთვის მათ სჭირდებათ უცხო გასაღების სახით გამოყენებული გასაღების მნიშვნელობის ინდექსი. ეს არ არის აშკარა, რადგან გამოყენება არ არის ასახული explain(). ასეთი ინდექსები ემატება იმ ინდექსს, რომელიც ჩაწერილია explain(), რომელსაც თავის მხრივ იყენებენ მილსადენის ოპერატორები $match и $sort, როდესაც ისინი ხვდებიან მილსადენის დასაწყისში. ინდექსებს ახლა შეუძლიათ დაფარონ ნებისმიერი ეტაპი აგრეგაციის მილსადენი.

მრავალჯერადი განახლებების გამოყენებაზე უარის თქმა

მეთოდი db.collection.update() გამოიყენება არსებული დოკუმენტის ნაწილის ან მთელი დოკუმენტის შესაცვლელად, სრულ ჩანაცვლებამდე, თქვენს მიერ მითითებული პარამეტრიდან გამომდინარე update. რაც არც ისე აშკარაა არის ის, რომ ის არ დაამუშავებს კრებულში არსებულ ყველა დოკუმენტს, თუ არ დააყენებთ პარამეტრს multi განაახლოს ყველა დოკუმენტი, რომელიც აკმაყოფილებს მოთხოვნის კრიტერიუმებს.

ნუ დაივიწყებთ ჰეშის ცხრილის გასაღებების თანმიმდევრობის მნიშვნელობას

JSON-ში ობიექტი შედგება ნულოვანი ზომის ან მეტი სახელის/მნიშვნელობის წყვილების დაურიგებელი კოლექციისგან, სადაც სახელი არის სტრიქონი და მნიშვნელობა არის სტრიქონი, რიცხვი, ლოგიკური, null, ობიექტი ან მასივი.

სამწუხაროდ, BSON დიდ აქცენტს აკეთებს წესრიგზე ძიებისას. MongoDB-ში კლავიშების თანმიმდევრობა ჩაშენებულ ობიექტებში საკითხებიანუ { firstname: "Phil", surname: "factor" } - ეს არ არის იგივე { { surname: "factor", firstname: "Phil" }. ანუ, თქვენ უნდა შეინახოთ სახელის/მნიშვნელობის წყვილების თანმიმდევრობა თქვენს დოკუმენტებში, თუ გსურთ დარწმუნებული იყოთ მათ პოვნაში.

არ დაიბნე "ბათილია" и "განუსაზღვრელი"

ღირებულება "განუსაზღვრელი" არასოდეს იყო მოქმედი JSON-ში, შესაბამისად ოფიციალური სტანდარტი JSON (ECMA-404 Section 5), მიუხედავად იმისა, რომ ის გამოიყენება JavaScript-ში. უფრო მეტიც, BSON-ისთვის ის მოძველებულია და გარდაიქმნება $null, რომელიც ყოველთვის არ არის კარგი გამოსავალი. მოერიდეთ გამოყენებას "განუსაზღვრელი" MongoDB-ში.

გამოიყენეთ $limit() გარეშე $sort()

ხშირად, როდესაც თქვენ ვითარდებით MongoDB-ში, სასარგებლოა უბრალოდ ნახოთ შედეგის ნიმუში, რომელიც დაბრუნდება მოთხოვნიდან ან აგრეგაციისგან. ამ ამოცანისთვის დაგჭირდებათ $limit(), მაგრამ ის არასოდეს უნდა იყოს საბოლოო კოდში, თუ ადრე არ იყენებთ მას $sort. ეს მექანიკა აუცილებელია, რადგან სხვაგვარად თქვენ ვერ გარანტირებთ შედეგის თანმიმდევრობას და ვერ შეძლებთ მონაცემების საიმედოდ ნახვას. შედეგის ზედა ნაწილში თქვენ მიიღებთ სხვადასხვა ჩანაწერს დახარისხების მიხედვით. საიმედოდ მუშაობისთვის, მოთხოვნები და აგრეგაციები უნდა იყოს განმსაზღვრელი, ანუ აწარმოონ იგივე შედეგები ყოველ ჯერზე მათი შესრულებისას. კოდი, რომელიც შეიცავს $limit(), მაგრამ არა $sort, არ იქნება განმსაზღვრელი და შეიძლება შემდგომში გამოიწვიოს შეცდომები, რომელთა დადგენა რთული იქნება.

დასკვნა

MongoDB-ით იმედგაცრუების ერთადერთი გზა არის მისი პირდაპირ შედარება სხვა ტიპის მონაცემთა ბაზასთან, როგორიცაა DBMS, ან მისი გამოყენება გარკვეული მოლოდინების საფუძველზე. ეს ფორთოხლის ჩანგალთან შედარებას ჰგავს. მონაცემთა ბაზის სისტემები ემსახურება კონკრეტულ მიზნებს. უმჯობესია უბრალოდ გაიგოთ და დააფასოთ ეს განსხვავებები თქვენთვის. სირცხვილი იქნება MongoDB დეველოპერებზე ზეწოლა გზაზე, რომელმაც აიძულა ისინი დაეტოვებინათ DBMS გზაზე. მსურს ვნახო ძველი პრობლემების გადაჭრის ახალი და საინტერესო გზები, როგორიცაა მონაცემთა მთლიანობის უზრუნველყოფა და მონაცემთა სისტემების შექმნა, რომლებიც მდგრადია წარუმატებლობისა და მავნე თავდასხმების მიმართ.

MongoDB-ის მიერ ACID ტრანზაქციის დანერგვა 4.0 ვერსიაში არის მნიშვნელოვანი გაუმჯობესებების ინოვაციური გზით დანერგვის კარგი მაგალითი. მრავალდოკუმენტური და მრავალგანცხადებიანი ტრანზაქციები ახლა ატომურია. ასევე შესაძლებელია საკეტების შესაძენად და ჩარჩენილი ტრანზაქციების შეწყვეტისთვის საჭირო დროის კორექტირება, ასევე იზოლაციის დონის შეცვლა.

Წაიკითხე მეტი:

• როგორ ჩატვირთოთ მონაცემები Google BigQuery-ში

წყარო: www.habr.com