SQLite.. قاعدة بيانات متواضعة تدير نصف الإنترنت

هناك ما يقرب من تريليون قاعدة بيانات SQLite قيد الاستخدام النشط حاليًا. تريليون واحد. كل هاتف iPhone وAndroid يحمل عدة قواعد. وكل تثبيت من Chrome وFirefox وmacOS وWindows يضمها. شركات مثل Adobe وAirbus وApple وGoogle والجيش الأمريكي تشحن برامجها مع SQLite بداخلها. بعدد النشر الهائل، هي محرك قاعدة البيانات الأكثر استخدامًا على الإطلاق - ومع ذلك، خلال معظم تاريخها البالغ 26 عامًا، تعامل معها المطورون كمكتبة مريحة للبيانات المحلية، وليس كقاعدة بيانات إنتاجية للخوادم.

تغير ذلك بين عامي 2022 و2026. مجموعة من الأدوات الجديدة حلت القيود التقليدية لـ SQLite على جانب الخادم، وتزايد عدد تطبيقات الإنتاج التي تخلت بهدوء عن Postgres وMySQL وRedis لصالح ملف .db واحد. إليك السبب - وما إذا كان ذلك منطقيًا لمشروعك.

ما هي SQLite فعليًا (وما ليست)

SQLite ليست خادم قاعدة بيانات. هي مكتبة C - حوالي 150,000 سطر من كود C المختبر جيدًا - تربطها مباشرة بتطبيقك. قاعدة البيانات بأكملها تعيش في ملف واحد على القرص. لا يوجد منفذ شبكة، ولا طبقة مصادقة، ولا تجمع اتصالات، ولا عملية منفصلة لتشغيلها أو مراقبتها. تطبيقك يقرأ ويكتب الملف مباشرة، داخل العملية نفسها.

أنشأ Richard Hipp SQLite في عام 2000 لاستخدامها في المدمرات الصاروخية للبحرية الأمريكية، حيث كانت أهمية تخزين البيانات المضمنة الموثوقة تفوق التنافسية متعددة المستخدمين. كان التنازل التصميمي مقصودًا: البساطة والموثوقية وعدم الحاجة إلى إدارة على حساب الكتابة المتزامنة. تنسيق الملف مستقر منذ 2004، وتوثيق SQLite لعام 2024 يلزم صراحة بالحفاظ على هذا التنسيق "إلى الأبد" - وهو ضمان قوي بشكل غير معتاد في عالم البرمجيات.

النتيجة الأهم للتصميم داخل العملية: زمن وصول شبكة صفري. استعلام يستغرق 1-2 مللي ثانية ذهابًا وإيابًا إلى مثيل Postgres عن بعد يستغرق ميكروثانية في SQLite. بالنسبة للتطبيقات كثيفة القراءة على نفس الجهاز مع قاعدة البيانات، الفرق في الأداء حقيقي.

النهضة على جانب الخادم

قصة SQLite على جانب الخادم تبدأ بحد واحد: الكتابة متسلسلة. يمكن لكاتب واحد فقط الاحتفاظ بقفل قاعدة البيانات في المرة الواحدة. في وضع دفتر اليومية الافتراضي، يقوم القراء أيضًا بحظر الكتاب. بالنسبة لتطبيق ويب متعدد المستخدمين، يبدو هذا قاتلاً.

أربع أدوات غيرت الحسابات بين 2022 و2023:

• Cloudflare D1 (2022): بنت Cloudflare منتج SQLite عديم الخادم فوق Cloudflare Workers، وزعت قواعد بيانات SQLite إلى مواقع الحافة عالميًا. يستخدم D1 وضع WAL لـ SQLite (تسجيل مسبق للكتابة) وكائنات Durable Objects للحفاظ على الاتساق. جلب SQLite إلى الحافة بواجهة SQL مألوفة وتسعير يعتمد على قراءة/كتابة لكل صف.
• Fly.io LiteFS (2022): LiteFS هو نظام ملفات قائم على FUSE يعترض كتابات SQLite ويكررها إلى العقد التابعة عبر سجل المعاملات. يتيح لك تشغيل عقدة SQLite أساسية ونسخ مكررة للقراءة فقط - نمط لم يكن ممكنًا سابقًا مع SQLite العادية. تستخدم Fly.io LiteFS داخليًا لبنيتها التحتية.
• Turso (2023): قامت Turso بتفريع SQLite إلى libSQL، وهي قاعدة بيانات مفتوحة المصدر متوافقة مع SQLite مع نسخ مكرر مدمج، ودعم واجهة API عبر HTTP، وتوزيع على الحافة. تشمل الطبقة المجانية من Turso 500 قاعدة بيانات، مما يجعل بنى متعددة المستأجرين لكل مستخدم SQLite مجانية عمليًا للنماذج الأولية.
• SQLite المدمجة في Bun (2023): أطلق Bun bun:sqlite، وهو مشغل SQLite أصلي مبني مباشرة في وقت تشغيل Bun. تظهر المقاييس أنه يعمل أسرع بحوالي 3 مرات من better-sqlite3 للأعباء النموذجية، مما يلغي الحاجة إلى حزمة npm منفصلة لمعظم حالات الاستخدام.

كل من هذه الأدوات تعالج فجوة معينة: D1 يتعامل مع توزيع الحافة، LiteFS يتعامل مع النسخ المكرر، Turso يتعامل مع كليهما بالإضافة إلى واجهة API عبر HTTP، وBun يتعامل مع سهولة استخدام المطور. معًا، حوّلوا SQLite من فضول محلي فقط إلى خيار موثوق به على جانب الخادم.

الجديد في SQLite 3.45+

بينما نضجت أدوات النظام البيئي، قدمت SQLite نفسها تحسينات مهمة في الإصدارات الأخيرة:

• SQLite 3.45 (يناير 2024): قدمت jsonb - تنسيق تخزين JSON ثنائي يحافظ على بيانات JSON في تمثيل ثنائي داخلي بدلاً من تحليل النص في كل وصول. تظهر المقاييس أن عمليات jsonb تعمل أسرع بما يصل إلى 10 مرات من عمليات JSON النصية المكافئة للهياكل المعقدة المتداخلة. نفس الإصدار أضاف دعم JSON5، مما يسمح بصياغة JSON مرنة (تعليقات، فواصل زائدة، سلاسل مفردة الاقتباس) في دوال JSON.
• SQLite 3.46 (مايو 2024): أضافت رسائل خطأ محسّنة بشكل كبير مع سياق أكثر حول ما حدث خطأ وأين. تم تحسين PRAGMA optimize ليعمل بكفاءة أكبر في التطبيقات طويلة التشغيل - الآن يقبل قناع بت للتحكم في التحسينات التي سيتم تطبيقها، مفيد للتطبيقات التي تريد تشغيله وفق جدول زمني بدلاً من عند إغلاق الاتصال.
• SQLite 3.47+ (أواخر 2024 - 2025): قدمت تحسينات على تقدير تكلفة مخطط الاستعلام للانضمامات المعقدة، مما قلل من حالات اختيار خطط استعلام دون المستوى الأمثل للجداول الكبيرة. تم توسيع عائلة دوال UNIXEPOCH() بمعدِّلات جديدة لحسابات التاريخ والوقت أكثر مرونة مباشرة في SQL.

إضافة jsonb تستحق التأكيد. أصبح JSON نوع بيانات من الدرجة الأولى في التطبيقات الحديثة، وتخزين JSON النصي السابق في SQLite كان يعني دورات متكررة من التحليل والتسلسل. التحول إلى أعمدة jsonb في مخطط بأعباء JSON ثقيلة هو ربح أداء بجهد صفري تقريبًا - غيِّر نوع العمود، أعد البناء، انتهى الأمر.

وضع WAL والتنافسية - الأرقام

الاعتراض الأكثر شيوعًا على SQLite على جانب الخادم هو التنافسية. الإجابة هي وضع WAL، الذي يتم تفعيله باستخدام توجيه واحد: PRAGMA journal_mode=WAL;

في وضع WAL، تحتفظ قاعدة البيانات بملف سجل مسبق للكتابة منفصل بجانب ملف قاعدة البيانات الرئيسي. الكتاب يضيفون إلى WAL؛ القراء يقرؤون من ملف قاعدة البيانات الرئيسي بالإضافة إلى أي إدخالات WAL ملتزمة. النتيجة: القراء لا يحجبون الكتاب أبدًا، والكتاب لا يحجبون القراء أبدًا. يعمل عدة قراء متزامنين بالتوازي دون أي نزاع على الأقفال. فقط عمليات الكتابة يتم تسلسلها ضد بعضها البعض - وبالنسبة لمعظم تطبيقات الويب، تشكل عمليات الكتابة جزءًا صغيرًا من إجمالي الاستعلامات.

مقاييس تم قياسها على M2 MacBook مع تخزين NVMe:

• وضع WAL لـ SQLite، قراءات متزامنة: ~130,000 قراءة/ثانية
• وضع WAL لـ SQLite، كتابات متسلسلة: ~35,000 كتابة/ثانية
• Postgres على نفس الجهاز (مع تكاليف الاتصال): ~40,000 قراءة/ثانية

معدل قراءة SQLite في وضع WAL أعلى بحوالي 3 مرات من Postgres على جهاز مماثل - لأنه لا يوجد اتصال بين العمليات. قاعدة البيانات في نفس العملية مع التطبيق؛ كل استعلام هو استدعاء دالة، وليس رحلة ذهاب وإياب عبر الشبكة.

عمليات الكتابة تروي قصة أكثر دقة. SQLite تسلسل الكتابات، لذا تطبيق كثيف الكتابة يصل إلى 35,000 كتابة/ثانية سيشبع الكاتب الواحد. Postgres، بهندسته المعمارية متعددة الكتاب، يوسع نطاق الكتابات أفقيًا. إذا كان تطبيقك يقوم بـ 10,000+ كتابة متزامنة في الثانية من مثيلات تطبيق منفصلة، فإن SQLite هي الخيار الخاطئ. إذا كنت تقوم بـ 500 كتابة/ثانية مع 50,000 قراءة/ثانية، فإن SQLite تفوز بفارق كبير.

متى تكون SQLite الخيار الصحيح

القرار هو سؤال يتعلق بحجم العمل، وليس سؤال هيبة:

• أعباء عمل عالية القراءة، منخفضة الكتابة ✓ — أداء قراءة SQLite استثنائي؛ الكتابات المتسلسلة نادرًا ما تكون عنق الزجاجة
• نشر في منطقة واحدة ✓ — كاتب أساسي واحد، زمن وصول منخفض، عمليات بسيطة
• نشر على الحافة ونشر مضمن ✓ — بنية تحتية صفرية، يعمل في أي مكان تعمل فيه عملية
• مجموعات بيانات صغيرة إلى متوسطة ✓ — تدعم SQLite قواعد بيانات حتى 281 تيرابايت نظريًا؛ عمليًا، أقل من 100 جيجابايت هي النقطة المثالية حيث تبقى العمليات على مستوى الملف سريعة
• تطبيقات لا تحتاج إلى بنية تحتية ✓ — لا حاجة لخادم قاعدة بيانات لتزويده، أو تحديثه، أو مراقبته
• كتابات عالية التنافسية من عمليات متعددة ✗ — الكتابات المتسلسلة تصبح عنق الزجاجة؛ استخدم Postgres أو MySQL
• كتابات أساسية متعددة المناطق ✗ — SQLite لها كاتب واحد؛ الكتابة النشطة-النشطة متعددة المناطق تتطلب قاعدة بيانات موزعة
• بحث نص كامل على نطاق واسع ✓/✗ — إضافة FTS5 قادرة لأعباء العمل المعتدلة؛ للملايين من المستندات مع ترتيب صلة معقد، البحث المخصص أفضل

الأدوات التي تجعل SQLite عملية على جانب الخادم

بعيدًا عن قاعدة البيانات نفسها، قام النظام البيئي بملء الفجوات التشغيلية:

• Turso: SQLite موزعة مع تفريع libSQL، واجهة API عبر HTTP وWebSocket، نسخ مكرر إلى مواقع حافة متعددة، نسخ مكررة مضمنة (SQLite محلية تتزامن من قاعدة بيانات Turso عن بعد). طبقة مجانية: 500 قاعدة بيانات، مليار قراءة صف/شهر.
• LiteFS: نسخ مكرر لـ SQLite قائم على FUSE من Fly.io. يعترض عمليات النظام لتسجيل سجل SQLite المسبق للكتابة وبثه إلى النسخ المكررة. جاهز للإنتاج، تستخدمه Fly.io داخليًا. يتطلب بيئة Linux مع دعم FUSE.
• Litestream: نسخ مكرر بتدفق ثنائي واحد لـ SQLite إلى S3 وR2 وGCS أو Azure Blob Storage. يعمل كعملية جانبية بجانب تطبيقك، يكرر كل إطار WAL في الوقت الفعلي تقريبًا. وقت الاستعادة من S3: أقل من 30 ثانية لقاعدة بيانات بحجم 10 جيجابايت. تكلفة شبه صفرية - تدفع فقط مقابل تخزين S3 والنقل الصادر.
• Cloudflare D1: SQLite عديمة الخادم على الحافة ضمن منصة Cloudflare Workers. نسخ مكرر شفاف للقراءة إلى ~300 موقع حافة. التسعير: $0.001 لكل مليون قراءة صف، $1.00 لكل مليون كتابة صف، 5 جيجابايت تخزين مجاني.
• bun:sqlite من Bun: مبنية مباشرة في وقت تشغيل Bun، لا حاجة لتثبيت npm. تستخدم SQLite النظام أو تشحن خاصتها. تظهر المقاييس باستمرار أنها أسرع بحوالي 3 مرات من better-sqlite3 لأعباء الاستعلام المتزامن، بسبب تكامل V8/JSC الأكثر إحكامًا وتقليل تكاليف FFI.

حالة تطبيق SaaS بـ 100 ألف مستخدم على SQLite

أكثر نمط معماري إثارة للاهتمام الذي ظهر من نهضة SQLite هو قاعدة بيانات واحدة لكل مستخدم (أو لكل مستأجر). بدلاً من قاعدة بيانات مشتركة واحدة مع أعمدة user_id في كل مكان، يحصل كل مستخدم على ملف .db خاص به.

المزايا كبيرة: عزل كامل للبيانات، نسخ احتياطي واستعادة بسيط لكل مستخدم، خطر صفري لتسرب البيانات بين المستأجرين عبر أخطاء SQL، والقدرة على نقل قواعد بيانات المستخدمين الفردية بين الخوادم دون تنسيق. حذف بيانات المستخدم هو استدعاء unlink() واحد.

هذا النمط تم استخدامه بهدوء في الإنتاج لسنوات. تشمل الحالات الموثقة تطبيقات SaaS مع أكثر من 50,000 مستخدم نشط تعمل بالكامل على SQLite مع Litestream للنسخ الاحتياطي - بدون Postgres، وبدون Redis، وبدون فريق بنية تحتية مخصص لقواعد البيانات. طبقة قاعدة البيانات بأكملها تتسع في دليل واحد من ملفات .db، مدعومة باستمرار إلى S3 بتكلفة بنسات قليلة شهريًا.

النمط يتوسع جيدًا حتى تحتاج إلى استعلامات عبر المستخدمين - تحليلات تجمع عبر جميع المستخدمين، على سبيل المثال. عند تلك النقطة، إما أن تحتفظ بقاعدة بيانات تحليلات منفصلة أو تقبل أن SQLite لكل مستخدم ليس النموذج المناسب لذلك الاستعلام.

الخلاصة

لم تكن SQLite أبدًا لعبة. كانت دائمًا تنازلًا مختلفًا: البساطة والموثوقية والأداء لأعباء العمل ذات الكاتب الواحد، على حساب الكتابات المتزامنة والوصول متعدد العمليات. النظام البيئي 2022-2026 - Turso وLitestream وLiteFS وCloudflare D1 وBun - لم يغير تنازلات SQLite. لقد بنوا الأدوات التشغيلية التي تجعل هذه التنازلات مقبولة لتطبيقات الخادم الإنتاجية.

لتطبيق ويب كثيف القراءة يعمل في منطقة واحدة، SQLite في وضع WAL سيتفوق على Postgres على نفس الجهاز، ويكلف أقل للتشغيل، ولا يتطلب أي إدارة لقاعدة البيانات. لتطبيق كثيف الكتابة مع عدة كتاب متزامنين عبر المناطق، يبقى Postgres الأداة الصحيحة. الخطأ هو التعامل معها كسؤال هيبة بدلاً من سؤال يتعلق بحجم العمل - SQLite شغّلت برامج أكثر، على أجهزة أكثر، بشكل أكثر موثوقية، من أي قاعدة بيانات أخرى في التاريخ. إنها فقط لا تحتاج إلى خادم للقيام بذلك.