1
00:00:03,710 --> 00:00:08,700
اسمحوا لي أن أقدم لكم لمحة سريعة عن MongoDB.

2
00:00:08,700 --> 00:00:10,875
لماذا هو مونغودب مثيرة للاهتمام؟

3
00:00:10,875 --> 00:00:13,165
كيف هو مفيد لطلبنا؟

4
00:00:13,165 --> 00:00:16,290
وما هي بعض الميزات البارزة لـ MongoDB

5
00:00:16,290 --> 00:00:19,845
على النقيض من قواعد بيانات SQL التقليدية؟

6
00:00:19,845 --> 00:00:23,190
لذلك لن تكون هذه معاهدات أو قواعد بيانات كاملة.

7
00:00:23,190 --> 00:00:25,890
أفترض أن لديك معرفة كافية لقواعد البيانات.

8
00:00:25,890 --> 00:00:31,050
لذلك ما أود أن أعرض ما MongoDB سيكون من السهل عليك اتباعه.

9
00:00:31,050 --> 00:00:34,695
من معرفتك السابقة بقواعد البيانات،

10
00:00:34,695 --> 00:00:40,235
أفترض أنك تفهم بالفعل أن قواعد البيانات تستخدم لتخزين البيانات المنظمة

11
00:00:40,235 --> 00:00:42,515
وأيضا تمكنك

12
00:00:42,515 --> 00:00:46,455
من تنفيذ عمليات مختلفة للبيانات بما في ذلك الاستعلام عن البيانات،

13
00:00:46,455 --> 00:00:48,740
وإدراج السجلات في قاعدة البيانات،

14
00:00:48,740 --> 00:00:53,870
وتحديث سجل موجود في قاعدة البيانات أو حذف سجل من قاعدة البيانات.

15
00:00:53,870 --> 00:00:58,795
عمليات crud النموذجية التي يتم دعمها في قواعد البيانات.

16
00:00:58,795 --> 00:01:02,870
لقد كانت لغة الاستعلام المنظمة أو قواعد البيانات المستندة إلى SQL

17
00:01:02,870 --> 00:01:07,330
شائعة جدًا لفترة طويلة كوسيلة لتخزين البيانات.

18
00:01:07,330 --> 00:01:13,760
ميسكل هو مثال واحد من قاعدة البيانات المستندة إلى سكل.

19
00:01:13,760 --> 00:01:16,850
وقد كانت فعالة جدا في تخزين

20
00:01:16,850 --> 00:01:20,230
البيانات ومن ثم تلبية العديد من احتياجات التطبيقات.

21
00:01:20,230 --> 00:01:27,650
في الواقع، العديد من المواقع تستخدم بالفعل قواعد بيانات SQL كخلفية لتخزين البيانات بالنظر إلى

22
00:01:27,650 --> 00:01:30,630
أن السبب في عدم وجود قواعد بيانات SQL

23
00:01:30,630 --> 00:01:35,610
مهمة مع أنواع جديدة من التطبيقات التي تأتي عبر الإنترنت.

24
00:01:35,610 --> 00:01:37,850
هناك طلب متزايد على

25
00:01:37,850 --> 00:01:43,170
ميزات جديدة ليس كل من قواعد البيانات المستندة إلى SQL يمكن أن تعالج.

26
00:01:43,170 --> 00:01:46,400
لذلك هذا هو المكان الذي قاعدة البيانات المستندة إلى NoSQL ليست فقط

27
00:01:46,400 --> 00:01:51,485
قاعدة البيانات المستندة إلى SQL تكتسب الكثير من المنح،

28
00:01:51,485 --> 00:01:54,720
MongoDB كونها أحد الأمثلة على ذلك.

29
00:01:54,720 --> 00:01:58,745
لذلك تم تصميم قواعد بيانات NoSQL

30
00:01:58,745 --> 00:02:03,305
لمعالجة بعض أوجه القصور في قواعد البيانات المستندة إلى SQL.

31
00:02:03,305 --> 00:02:08,935
يمكن تصنيف قواعد بيانات NoSQL نفسها إلى أربع فئات مختلفة.

32
00:02:08,935 --> 00:02:13,315
لدينا قواعد بيانات تستند إلى المستندات مثل MongoDB،

33
00:02:13,315 --> 00:02:17,820
لدينا قواعد بيانات أكثر بساطة تستند إلى القيمة الرئيسية مثل Redis،

34
00:02:17,820 --> 00:02:24,710
وقواعد البيانات المستندة إلى العمود العائلي مثل Cassandra ثم أحدث قواعد بيانات الرسم البياني مثل

35
00:02:24,710 --> 00:02:32,210
Neo4J وبالفعل هناك الآن أكثر في السوق من هذه الأمثلة التي أعطيتها.

36
00:02:32,210 --> 00:02:34,370
ولكن بالطبع في هذه الدورة،

37
00:02:34,370 --> 00:02:40,050
سوف نركز في المقام الأول على قواعد البيانات المستندة إلى الوثائق، MongoDB على وجه الخصوص.

38
00:02:40,050 --> 00:02:44,855
لذلك سأراجع المزيد عن MongoDB في بقية هذه المحاضرة.

39
00:02:44,855 --> 00:02:48,095
قواعد بيانات المستندات، كما يوحي الاسم،

40
00:02:48,095 --> 00:02:50,200
مبنية حول المستندات.

41
00:02:50,200 --> 00:02:56,530
الوثيقة هي وحدة معلومات مستقلة ويمكن أن تكون في العديد من الأشكال المختلفة،

42
00:02:56,530 --> 00:03:03,425
JSON هي واحدة من الأشكال الأكثر شعبية لتخزين الوثائق في قاعدة بيانات المستندات.

43
00:03:03,425 --> 00:03:07,535
على سبيل المثال، يتم عرض مستند JSON هنا

44
00:03:07,535 --> 00:03:12,215
وهذا سيكون شيئًا يتم منحه في قاعدة بيانات مستندات نموذجية.

45
00:03:12,215 --> 00:03:15,730
يمكن تنظيم الوثائق نفسها في مجموعات.

46
00:03:15,730 --> 00:03:20,830
لذا فإن المجموعة عبارة عن مجموعة من المستندات، وبدورها،

47
00:03:20,830 --> 00:03:26,205
يمكن اعتبار قاعدة البيانات نفسها كمجموعة من المجموعات.

48
00:03:26,205 --> 00:03:31,970
لذا ستحدث هذه المصطلحات، «مجموعات المستندات» و «قاعدة البيانات»

49
00:03:31,970 --> 00:03:39,290
بشكل متكرر عندما نناقش حول قواعد بيانات المستندات و MongoDB على وجه الخصوص.

50
00:03:39,290 --> 00:03:42,910
لماذا قواعد بيانات NoSQL ذات أهمية بالنسبة لنا؟ على

51
00:03:42,910 --> 00:03:45,890
وجه الخصوص، قابلية التوسع هي واحدة من

52
00:03:45,890 --> 00:03:49,560
الأسباب التي تجعل قواعد بيانات NoSQL قد ألقت بشكل جيد للغاية.

53
00:03:49,560 --> 00:03:52,015
الآن من حيث قابلية التوسع،

54
00:03:52,015 --> 00:03:53,630
عندما ننظر إلى المتطلبات اثنين؛

55
00:03:53,630 --> 00:03:56,990
توافر واتساق قواعد البيانات، عادة،

56
00:03:56,990 --> 00:04:02,390
تجد قواعد بيانات SQL أنه من الصعب جدا تلبية كلا المتطلبات في وقت واحد.

57
00:04:02,390 --> 00:04:05,239
لذلك هناك مقايضة بين التوافر والاتساق.

58
00:04:05,239 --> 00:04:08,690
لذلك هذا هو المكان الذي كانت قواعد بيانات NoSQL

59
00:04:08,690 --> 00:04:12,175
أكثر نجاحًا في تلبية كلا المتطلبات.

60
00:04:12,175 --> 00:04:14,705
هذا هو المكان الذي يبرز الجانب الثالث هنا،

61
00:04:14,705 --> 00:04:17,465
التسامح التقسيم، ويأتي أيضا حيز التنفيذ.

62
00:04:17,465 --> 00:04:23,660
الآن تقسيم قاعدة بيانات SQL ثم توزيعها ليس بسيطًا.

63
00:04:23,660 --> 00:04:29,239
في حين أن قاعدة بيانات NoSQL أكثر قابلية

64
00:04:29,239 --> 00:04:34,755
للتقسيم الفرعي ثم توزيعها عبر خوادم متعددة.

65
00:04:34,755 --> 00:04:40,990
الجانب الثاني من سبب شعبية قواعد بيانات NoSQL هو سهولة النشر.

66
00:04:40,990 --> 00:04:43,165
عند استخدام قاعدة بيانات SQL،

67
00:04:43,165 --> 00:04:48,200
هناك حاجة لمطابقة السجلات في قاعدة بيانات SQL الخاصة بك مرة أخرى

68
00:04:48,200 --> 00:04:53,410
إلى كائنات بلغتك الأصلية مثل Java أو Javascript وما إلى ذلك.

69
00:04:53,410 --> 00:04:56,810
لذلك هناك حاجة لرسم الخرائط العلائقية للكائن وهذا هو

70
00:04:56,810 --> 00:05:00,920
المكان الذي تحتاج فيه بوابة وسيطة لملء هذا الشرط.

71
00:05:00,920 --> 00:05:07,950
مع قاعدة بيانات NoSQL مثل قاعدة بيانات تستند إلى المستند تخزن البيانات في شكل JSON،

72
00:05:07,950 --> 00:05:12,200
يصبح التعيين مستقيمًا تمامًا وهذا أحد الأسباب التي جعلت

73
00:05:12,200 --> 00:05:17,900
قواعد بيانات NoSQL تحظى بشعبية كبيرة في منطقة تطوير الويب.

74
00:05:17,900 --> 00:05:20,680
القادمة إلى MongoDB على وجه الخصوص،

75
00:05:20,680 --> 00:05:23,820
MongoDB هي قاعدة بيانات وثيقة.

76
00:05:23,820 --> 00:05:27,150
يمكن للخادم نفسه دعم قواعد بيانات متعددة.

77
00:05:27,150 --> 00:05:31,790
قاعدة البيانات على وجه الخصوص هي مجموعة من المجموعات

78
00:05:31,790 --> 00:05:36,620
والمجموعة نفسها كما ناقشنا في وقت سابق هي مجموعة من الوثائق.

79
00:05:36,620 --> 00:05:41,705
لذلك يصبح المستند وحدة المعلومات في حالة MongoDB.

80
00:05:41,705 --> 00:05:46,825
المستند في MongoDB ليس سوى مستند JSON.

81
00:05:46,825 --> 00:05:53,470
في الواقع، يقوم MongoDB بتخزين المستند في شكل أكثر إحكاما يسمى بتنسيق BSON.

82
00:05:53,470 --> 00:05:56,495
سنتحدث عن ذلك في الشريحة التالية

83
00:05:56,495 --> 00:06:00,175
في حين أن MongoDB عبارة عن قاعدة بيانات تستند إلى المستند،

84
00:06:00,175 --> 00:06:04,160
فإنها تخزن مستندات JSON في نموذج مضغوط

85
00:06:04,160 --> 00:06:09,125
يسمى بتنسيق BSON أو تنسيق JSON الثنائي.

86
00:06:09,125 --> 00:06:12,920
الآن يدعم هذا بادئة الطول على كل قيمة

87
00:06:12,920 --> 00:06:16,870
بحيث يصبح التخطي عبر حقل أكثر سهولة.

88
00:06:16,870 --> 00:06:23,365
كما ترى، يدعم MongoDB ميزات إضافية من قاعدة بيانات مستندات بسيطة.

89
00:06:23,365 --> 00:06:27,835
يتم أيضًا تخزين المعلومات حول نوع قيمة الحقل.

90
00:06:27,835 --> 00:06:31,280
وبالإضافة إلى ذلك، داخل وثيقة JSON،

91
00:06:31,280 --> 00:06:35,405
يتم تخزين أنواع بدائية إضافية والتي تكون مفيدة

92
00:06:35,405 --> 00:06:39,860
عند تنفيذ عمليات على قاعدة البيانات.

93
00:06:39,860 --> 00:06:43,190
أشياء مثل تنسيق تاريخ UTC،

94
00:06:43,190 --> 00:06:48,920
فإنه يدعم أيضًا ثنائي خام ويستخدم أيضًا تنسيق معرف

95
00:06:48,920 --> 00:06:54,790
الكائن لتخزين معرف كل مستند في قاعدة البيانات إذا اخترت ذلك.

96
00:06:54,790 --> 00:06:58,745
دعونا نتحدث عن ذلك بمزيد من التفصيل في الشريحة التالية.

97
00:06:58,745 --> 00:07:02,330
دعونا نتحدث عن معرف كائن MongoDB.

98
00:07:02,330 --> 00:07:07,000
يجب أن يكون لكل مستند في قاعدة بيانات MongoDB حقل

99
00:07:07,000 --> 00:07:08,985
معرف، حقل معرف تسطير سفلي،

100
00:07:08,985 --> 00:07:14,055
والذي يعمل كمفتاح أساسي للمستند.

101
00:07:14,055 --> 00:07:17,465
وهذا الحقل فريد لكل مستند.

102
00:07:17,465 --> 00:07:20,810
يمكن استخدام حقل المعرف نفسه في

103
00:07:20,810 --> 00:07:25,955
العديد من التنسيقات وتنسيق معين

104
00:07:25,955 --> 00:07:30,020
يعينه MongoDB تلقائيًا في حالة عدم اختيار استخدام حقل المعرف الخاص بك

105
00:07:30,020 --> 00:07:35,350
هو معرف الكائن الذي يتم إنشاؤه افتراضيًا بواسطة MongoDB.

106
00:07:35,350 --> 00:07:37,550
لذا فإن معرف الكائن نفسه هو

107
00:07:37,550 --> 00:07:43,660
جزء منظم من المعلومات ولكن يتم تخزينه كمعرف للمستند.

108
00:07:43,660 --> 00:07:52,390
على سبيل المثال،

109
00:07:52,390 --> 00:07:55,960
يحتوي حقل المعرف الذي يتم تعيينه تلقائيًا بواسطة Mongo في حالة عدم تحديد حقل معرف، على معرف الكائن في شكل سلسلة طويلة.

110
00:07:55,960 --> 00:08:00,605
الآن تحتوي هذه السلسلة على تنسيق محدد

111
00:08:00,605 --> 00:08:06,530
يمكّنها من تخزين عدد من أجزاء المعلومات داخل معرف الكائن.

112
00:08:06,530 --> 00:08:11,975
دعونا ننظر إلى بنية معرف الكائن نفسه في الشريحة التالية.

113
00:08:11,975 --> 00:08:16,325
كما ذكرت، حقل معرف الكائن نفسه هو

114
00:08:16,325 --> 00:08:22,635
حقل 12 بايت الذي يخزن المعلومات بتنسيق معين.

115
00:08:22,635 --> 00:08:26,445
تتضمن البايت الأربعة الأولى طابع زمني،

116
00:08:26,445 --> 00:08:31,760
الطابع الزمني Unix النموذجي في دقة ثانية واحدة.

117
00:08:31,760 --> 00:08:34,340
لذلك يقال هذا في البايت الأربعة الأولى.

118
00:08:34,340 --> 00:08:37,580
ثم وحدات البايت الثلاثة التالية نحو معرف الجهاز،

119
00:08:37,580 --> 00:08:40,490
الجهاز الذي يعمل عليه خادم Mongo

120
00:08:40,490 --> 00:08:43,910
والبايتيتان التاليتان هما معرف العملية،

121
00:08:43,910 --> 00:08:47,000
وعملية Mongo المحددة التي أنشأت

122
00:08:47,000 --> 00:08:50,674
هذا المستند ثم الحقل الأخير هو زيادة.

123
00:08:50,674 --> 00:08:52,490
الآن كما تفهم،

124
00:08:52,490 --> 00:08:56,390
حقل الطابع الزمني نفسه هو في دقة ثانية.

125
00:08:56,390 --> 00:09:00,110
لذلك إذا كان لديك مستندات متعددة يتم تخزينها في نفس الثانية،

126
00:09:00,110 --> 00:09:03,735
فسيميز حقل الزيادة بين المستندات.

127
00:09:03,735 --> 00:09:06,500
أنها زيادة الحقل هو حقل التزايد الذاتي.

128
00:09:06,500 --> 00:09:11,750
لذلك ستحصل كل مستند جديد تم إنشاؤه خلال ثانية على قيمة زيادة جديدة.

129
00:09:11,750 --> 00:09:14,150
لذلك جنبا إلى جنب مع هذين الاثنين،

130
00:09:14,150 --> 00:09:16,655
يمكنك بسهولة التمييز بين

131
00:09:16,655 --> 00:09:21,550
المستندات المختلفة التي يتم تخزينها داخل قاعدة بيانات المستند الخاص بك.

132
00:09:21,550 --> 00:09:28,500
لذلك هذا يتيح لك إعطاء معرف فريد بوضوح لكل مستند.

133
00:09:28,500 --> 00:09:30,960
ليس ذلك فقط، بالنظر إلى معرف،

134
00:09:30,960 --> 00:09:34,050
يمكنك بسهولة استرداد المعلومات من هذا المعرف.

135
00:09:34,050 --> 00:09:37,460
على سبيل المثال، يمكنك الحصول على عقد من ObjectID ثم استدعاء

136
00:09:37,460 --> 00:09:40,880
طريقة getTimestamp لمعرف الكائن

137
00:09:40,880 --> 00:09:44,655
وهذا سيعود الطابع الزمني بتنسيق تاريخ ISO.

138
00:09:44,655 --> 00:09:49,595
لذلك سوف تمكنك من تحديد متى تم إنشاء هذا المستند.

139
00:09:49,595 --> 00:09:52,750
مع هذا الفهم السريع لـ MongoDB،

140
00:09:52,750 --> 00:09:58,700
دعنا ننتقل إلى التمرين حيث سنقوم أولاً بتثبيت MongoDB على جهاز الكمبيوتر الخاص بنا

141
00:09:58,700 --> 00:10:04,970
ثم نتفاعل مع قاعدة بيانات MongoDB باستخدام تموج Mongo،

142
00:10:04,970 --> 00:10:09,365
وقراءة تقييم حلقة الطباعة التي تدعمها Mongo.

143
00:10:09,365 --> 00:10:12,695
الآن بعد ذلك، سننظر في كيفية الوصول

144
00:10:12,695 --> 00:10:19,830
إلى خادم Mongo من داخل تطبيق العقدة في الدرس التالي.