Inside SQLite: The 300KB File That Beat Oracle and Postgres

Watch on YouTube

Now Playing

Transcript

388 segments

0:00

الأقوال لا تكلف شيئاً

0:01

. أرني الكود البرمجي.

0:02

قال لينوس تورفالدز

0:03

ذلك في أغسطس عام 2000.

0:05

كان أحدهم يطلق

0:05

ادعاءات كبيرة حول

0:07

برمجته، فقال لينوس

0:08

باختصار: "أثبت ذلك".

0:09

اليوم، أريد أن أعرض

0:11

لكم برنامجاً أثبت ذلك

0:12

تماماً. ليس بالأقوال

0:14

ولا بالتسويق، بل بكود

0:15

جيد لدرجة أنه أصبح

0:16

بصمت المكون البرمجي

0:18

الأكثر انتشاراً في

0:19

تاريخ البشرية. أنا

0:20

أتحدث عن SQLite. الآن،

0:22

قبل أن تقول: "أجل، لقد

0:24

سمعت عنه". دعني أريك

0:26

شيئاً. تثبيتات MySQL حول

0:27

العالم، حوالي 5

0:29

ملايين. PostgreSQL، حوالي

0:31

مليون واحد. SQLite، أكثر

0:33

من تريليون. هذا ليس

0:35

خطأ مطبعياً. تريليون

0:37

عملية تثبيت نشطة. لقد

0:39

استخدمت SQLite اليوم

0:40

بالفعل، ربما عشرات

0:41

المرات. عندما فتحت

0:43

هاتفك هذا الصباح، كان

0:44

SQLite. أرسلت رسالة عبر

0:46

واتساب، SQLite. فتحت

0:48

متصفح كروم أو سفاري،

0:50

SQLite. التقطت صورة، فتم

0:51

حفظ البيانات الوصفية

0:53

في SQLite. كل آيفون، كل

0:54

أندرويد، كل متصفح، كل

0:56

جهاز ماك أو ويندوز،

0:58

يعمل في الخلفية بصمت

1:00

عبر SQLite. والمحرك

1:01

بالكامل، يتم تجميعه

1:03

في حوالي 300 كيلوبايت.

1:04

بدون خادم، بدون

1:06

إعدادات، بدون معالج

1:07

تثبيت، مجرد ملف واحد.

1:09

فكيف انتهى المطاف

1:10

بمحرك قاعدة بيانات

1:11

صغير كتبه شخص واحد

1:12

ليُشغل العالم؟ دعونا

1:14

نكتشف ذلك. إنه عام 2000.

1:22

مقاول برمجيات يُدعى

1:23

ريتشارد هيب يعمل على

1:24

المدمرة البحرية "يو

1:25

إس إس أوسكار أوستن"،

1:27

المصممة لتحمل أضرار

1:28

المعارك. ما هي وظيفته

1:30

؟ بناء برنامج يساعد

1:31

البحارة على إعادة

1:32

توجيه الأنابيب عندما

1:33

تتعرض أجزاء من

1:33

السفينة للتلف. فكر في

1:35

الأمر كنظام تحكم في

1:36

التمديدات. لكن

1:37

المخاطر هنا حياة أو

1:38

موت. المشكلة؟ قاعدة

1:40

البيانات التي كانوا

1:41

يستخدمونها هي Informix.

1:43

وكان Informix يحتاج إلى

1:44

خادم. عندما كان ذلك

1:46

الخادم يتعطل، وهو ما

1:47

كان يحدث، كان التطبيق

1:48

بالكامل ينهار. كان

1:49

البحارة ينقرون على

1:50

التطبيق مرتين فيظهر

1:51

لهم مربع حوار جميل. لا

1:53

يمكن الاتصال بخادم

1:54

قاعدة البيانات. فكر

1:55

ريتشارد: نحن على متن

1:57

سفينة حربية في معركة،

1:58

وخادم قاعدة البيانات

1:59

يمثل نقطة فشل واحدة.

2:01

لذا سأل من حوله: هل

2:02

توجد قاعدة بيانات لا

2:04

تحتاج إلى خادم؟ شيء

2:05

يقرأ ويكتب مباشرة على

2:07

القرص. لم يكن هناك شيء

2:09

موجود. قال له زميل: "يا

2:10

ريتشارد، لماذا لا

2:11

تكتب واحدة بنفسك؟"

2:13

وخلال فترة توقف

2:14

التمويل الحكومي،

2:15

عندما تجمدت العقود

2:16

لبضعة أشهر، فكر

2:17

ريتشارد: "حسناً،

2:18

سأكتب واحدة". فتح

2:19

محرراً للنصوص وبدأ في

2:20

بناء محرك قاعدة

2:21

بيانات من الصفر. بدون

2:23

تمويل استثماري،

2:24

وبدون فريق. مهندس

2:25

واحد فقط يحل مشكلته

2:27

الخاصة. بعد بضعة أشهر

2:28

، قام بنشرها عبر

2:29

الإنترنت. أسماها SQLite،

2:31

النسخة الخفيفة من SQL.

2:33

ظنّ أنه ربما سيجد

2:34

البعض فائدة فيه. لم

2:36

تكن لديه أدنى فكرة.

2:37

قبل أن نتعمق أكثر،

2:39

لنفهم ما الذي يجعل

2:40

SQLite مختلفاً. لأنك إن

2:42

عملت مع MySQL أو PostgreSQL،

2:43

فقد يكون تصورك الذهني

2:45

خاطئاً. في قاعدة

2:46

البيانات التقليدية،

2:48

كـ PostgreSQL، يتصل تطبيقك

2:49

عبر الشبكة بعملية

2:50

خادم منفصلة. يدير هذا

2:52

الخادم الاتصالات،

2:53

والذاكرة، والتخزين

2:54

المؤقت، ويتواصل مع

2:55

الملفات الفعلية على

2:56

القرص. إنه قوي، وقابل

2:58

للتوسع، لكنه معقد

2:59

أيضاً. عليك تهيئته،

3:01

وتأمينه، وضبطه،

3:02

والحفاظ على

3:02

استمرارية عمله. تقلب

3:04

SQLite هذا النموذج

3:05

بالكامل. لا يوجد خادم.

3:07

لا يوجد اتصال شبكي. لا

3:09

توجد عملية منفصلة.

3:11

SQLite عبارة عن مكتبة.

3:12

تقوم بربطها مباشرة

3:14

داخل تطبيقك. لذا،

3:15

عندما يستدعي كودك

3:16

دالة SQLite، فإنه يقرأ

3:17

ويكتب في ملف واحد على

3:19

القرص. هذا كل ما في

3:20

الأمر. ذلك الملف هو

3:21

قاعدة البيانات. فكر

3:22

في الأمر بهذه الطريقة

3:24

. قاعدة البيانات

3:25

التقليدية تشبه

3:25

الذهاب إلى مطعم. أنت

3:27

تطلب طلبك من النادل.

3:28

يتحدث النادل إلى

3:29

المطبخ. يصل الطعام

3:31

إليك. أما SQLite فهي كأن

3:32

تملك المطبخ بأكمله في

3:34

شقتك. أنت تذهب مباشرة.

3:36

ولهذا السبب يستخدمه

3:37

كل تطبيق جوال. لا

3:38

خوادم لإدارتها، لا

3:40

منافذ لفتحها، لا

3:41

ملفات تهيئة. قاعدة

3:43

بياناتك هي مجرد ملف

3:44

يمكنك نسخه، أو إرساله

3:45

بالبريد، أو رفعه على

3:46

Git. ورغم خفته، فإنه لا

3:48

يزال متوافقاً تماماً

3:49

مع معايير ACID.

3:50

المعاملات تعمل،

3:51

استعادة البيانات عند

3:53

التعطل تعمل، إنها

3:54

ليست لعبة. قاعدة

3:55

بيانات SQLite هي ملف

3:57

واحد، ينتهي عادةً بـ

3:59

.db أو .sqlite. ولكن ما

4:00

الذي يوجد داخل ذلك

4:02

الملف؟ الملف مقسم إلى

4:03

أجزاء ثابتة الحجم

4:05

تسمى صفحات. افتراضياً

4:07

، حجم كل صفحة هو 4096

4:08

بايت. وهو نفس حجم كتلة

4:10

القرص النموذجية. هذا

4:12

ليس من قبيل المصادفة.

4:13

صُمم SQLite ليعمل بكفاءة

4:15

مع طريقة عمل الأقراص

4:16

الفعلية. الصفحة

4:17

الأولى خاصة ومميزة.

4:19

تحتوي على ترويسة من 100

4:20

بايت بها بيانات وصفية

4:22

عن قاعدة البيانات،

4:23

وحجم الصفحة، وعدد

4:25

الصفحات الموجودة،

4:26

ورقم الإصدار، وسلسلة

4:27

نصية توضح أنها بتنسيق

4:29

SQLite 3 في البداية. هكذا

4:30

يمكن لأي أداة التعرف

4:32

على ملف SQLite فوراً. كل

4:34

صفحة أخرى هي جزء من

4:36

هيكل B-tree. وهذا هو جوهر

4:38

SQLite. إذا لم تكن على

4:39

دراية بهياكل B-trees،

4:40

فكر فيها كشجرة عائلة

4:42

لبياناتك. في الأعلى،

4:43

لديك عقدة جذرية. تلك

4:45

الجذر تشير إلى عقد

4:46

فرعية. تلك الفروع

4:47

تشير إلى المزيد من

4:48

الفروع. في القاع

4:49

تماماً، لديك عقد

4:50

ورقية تحتوي على

4:51

الصفوف الفعلية. لذا،

4:52

عند تشغيل استعلام مثل

4:54

"select star from users where ID equal

4:56

to 42"، فإن SQLite لا تفحص

4:58

كل صف. تبدأ من الجذر،

5:00

وتقارن المفاتيح،

5:01

وتختار الابن المناسب

5:02

للمتابعة، وتستمر حتى

5:04

تعثر على الصفحة التي

5:05

تحتوي على الصف 42. وهذا

5:06

يمثل تعقيداً زمنياً

5:08

لوغاريتمياً. إذا كان

5:09

لديك ملايين الصفوف،

5:10

فقد تقرأ SQLite ثلاث أو

5:11

أربع صفحات فقط للعثور

5:12

على ما تحتاجه. في

5:14

الواقع، تحتفظ SQLite

5:15

بنوعين من أشجار B-tree.

5:16

أحدهما هو شجرة B-tree

5:18

الخاصة بالجدول. هذه

5:19

تخزن بيانات الصفوف

5:20

الفعلية مفهرسة بمعرف

5:21

الصف (row ID). والآخر هو

5:23

شجرة B-tree الخاصة

5:24

بالفهرس. إذا قمت

5:25

بإنشاء فهرس على عمود

5:26

البريد الإلكتروني

5:27

مثلاً، تبني SQLite شجرة

5:28

منفصلة تكون فيها

5:29

المفاتيح هي عناوين

5:30

البريد والقيم هي

5:31

معرفات الصفوف. بهذه

5:32

الطريقة، يصبح البحث

5:33

عن طريق البريد

5:34

الإلكتروني سريعاً.

5:35

ابحث عن البريد في

5:36

شجرة الفهرس، واحصل

5:37

على معرف الصف، ثم

5:38

انتقل إلى شجرة الجدول

5:39

. وهذا هو نفس الهيكل

5:40

الأساسي الذي تستخدمه

5:42

PostgreSQL و MySQL و Oracle. لكن

5:43

SQLite تطبق ذلك في حوالي

5:45

150 ألف سطر من لغة C

5:47

بدلاً من الملايين.

5:48

حسناً، لدينا ملف

5:50

بصفحات منظمة كأشجار

5:51

B-trees. لكن إليك سؤالاً

5:53

مخيفاً. ماذا يحدث إذا

5:55

تعطل تطبيقك في منتصف

5:56

كتابة البيانات؟ إذا

5:57

كانت SQLite في منتصف

5:59

تحديث صفحة وانقطعت

6:00

الطاقة، تصبح تلك

6:01

الصفحة تالفة. تصبح

6:02

قاعدة بياناتك تالفة

6:04

تماماً. وهنا تصبح SQLite

6:06

ذكية. في الأصل،

6:07

استخدمت SQLite شيئاً

6:08

يسمى سجل التراجع (

6:09

rollback journal). لذا قبل

6:10

تعديل أي صفحة، كانت

6:12

تنسخ الصفحة الأصلية

6:13

إلى ملف سجل منفصل. إذا

6:14

حدث خطأ ما، يمكن لـ

6:15

SQLite الاستعادة من

6:16

السجل عند بدء التشغيل

6:18

التالي. لكن SQLite

6:19

الحديثة تستخدم شيئاً

6:20

أفضل. وهو سجل الكتابة

6:22

المسبقة، أو WAL. وإليك

6:23

كيف يعمل. بدلاً من

6:25

تعديل ملف قاعدة

6:26

البيانات الرئيسي

6:27

مباشرة، تضيف SQLite

6:28

التغييرات إلى ملف WAL

6:29

منفصل. يبقى ملف قاعدة

6:31

البيانات الرئيسي دون

6:32

مساس. لذا، عند تنفيذ

6:33

معاملة (transaction)، تكتب

6:35

SQLite علامة إتمام في

6:36

ملف WAL فقط. لا يتم لمس

6:37

ملف قاعدة البيانات

6:39

الفعلي بعد. لاحقاً،

6:40

أثناء نقطة التحقق (

6:41

checkpoint)، تدمج SQLite تلك

6:42

التغييرات في الملف

6:43

الرئيسي. لماذا هذا

6:45

أفضل؟ أولاً، لا يحجب

6:46

القراء والكتاب بعضهم

6:48

البعض. ينظر القراء

6:49

إلى الملف الرئيسي

6:50

بالإضافة إلى أي

6:51

إدخالات مكتملة في ملف

6:52

WAL. يقوم الكتاب

6:53

بالإلحاق في ملف WAL فقط

6:54

. لا حاجة لأقفال.

6:56

ثانياً، عمليات

6:57

الكتابة متسلسلة.

6:58

الإلحاق بملف أسرع

6:59

بكثير من التحديثات

7:00

العشوائية، خاصة على

7:01

أقراص SSD. ثالثاً،

7:02

استعادة النظام بعد

7:03

الانهيار بسيطة. إذا

7:05

كان ملف WAL يحتوي على

7:06

إدخالات غير مكتملة،

7:07

يتم تجاهلها ببساطة.

7:08

يظل الملف الرئيسي

7:09

دائماً في حالة متسقة.

7:11

وهكذا تمنحك SQLite

7:12

ضمانات ACID كاملة:

7:13

الذرية، والاتساق،

7:14

والعزل، والمتانة في

7:16

ملف واحد دون الحاجة

7:17

إلى خادم. لذا، يتم شحن

7:19

SQLite على مليارات

7:21

الأجهزة. ماذا يحدث

7:22

عندما تتسرب الأخطاء

7:23

البرمجية؟ اكتشف

7:24

ريتشارد هيب ذلك

7:25

بالطريقة الصعبة.

7:26

عندما بدأت أندرويد

7:27

بشحن SQLite على ملايين

7:28

الهواتف، ظهرت فجأة في

7:30

كل مكان أخطاء لم تظهر

7:31

أبداً أثناء الاختبار.

7:32

ماذا كانت استجابته؟

7:34

قضى عاماً كاملاً، بـ

7:35

60 ساعة عمل أسبوعياً،

7:37

في كتابة اختبارات حتى

7:39

حقق ما يسمى بتغطية 100%

7:41

MCDC. يرمز MCDC إلى تغطية

7:43

قرار الشرط المعدل.

7:44

إنه معيار اختبار

7:46

يُستخدم لبرمجيات

7:47

الطيران، وهي الأكواد

7:48

التي تعمل على

7:49

الطائرات. هذا يعني أن

7:51

كل فرع في كود الآلة

7:52

المترجم قد تم اختباره

7:53

في كلا الاتجاهين.

7:55

إليكم كيف تبدو مجموعة

7:56

اختبارات SQLite اليوم.

7:57

يتكون جوهر SQLite من

7:59

حوالي 160 ألف سطر من

8:00

لغة C. ماذا عن كود

8:01

الاختبار؟ حوالي 90

8:03

مليون سطر. هذه نسبة

8:04

تقريبية تبلغ 600 سطر من

8:06

الاختبار لكل سطر من

8:07

كود المنتج. تحاكي تلك

8:09

الاختبارات أخطاء

8:10

نفاد الذاكرة، وفشل

8:11

القرص، وانقطاع

8:12

الطاقة أثناء

8:12

المعاملات، وكل كارثة

8:13

يمكن أن تتخيلها. ما

8:15

النتيجة؟ تم اعتماد

8:16

SQLite للاستخدام في

8:17

الطائرات التجارية

8:19

بموجب معيار DO-178B، وهو

8:20

أحد أكثر معايير سلامة

8:22

البرمجيات صرامة. وكم

8:23

عدد الأشخاص الذين

8:24

يتابعون صيانة كل هذا؟

8:26

اثنان فقط. مهندسان

8:27

متفرغان يقومان

8:28

بصيانة قاعدة

8:28

البيانات الأكثر

8:29

انتشاراً في التاريخ.

8:30

بعد 24 عاماً، هناك

8:31

قواعد بيانات SQLite على

8:33

الأرض أكثر من عدد

8:34

البشر. في بعض الأحيان

8:35

، ليست الهندسة الأفضل

8:37

هي الأكثر تعقيداً. بل

8:38

هي التي يتم شحنها

8:39

بالفعل، وتعمل بالفعل

8:41

، ولا تعيق طريقك.

8:42

الكلام سهل، أرني

8:44

الكود. لقد أظهرت لنا

8:46

SQLite الكود، وهو يعمل

8:47

على هاتفك الآن.

Interactive Summary

Ask follow-up questions or revisit key timestamps.

يتناول الفيديو قصة نشأة وتطور SQLite، قاعدة البيانات الأكثر انتشاراً في العالم، والتي صممها ريتشارد هيب في عام 2000 لحل مشكلة الاعتماد على الخوادم في الأنظمة الحرجة. يشرح الفيديو كيف تتميز SQLite ببساطتها كملف واحد دون الحاجة لخادم، وكيف تستخدم هياكل B-trees وسجل الكتابة المسبقة (WAL) لضمان الكفاءة والموثوقية ومعايير ACID، وصولاً إلى استراتيجيات الاختبار الصارمة التي جعلتها تستخدم حتى في الطيران.