SQLite: پراستفاده‌ترین پایگاه داده جهان که تقریباً کسی از آن صحبت نمی‌کند

پایگاه‌های داده‌ای که توجه را جلب می‌کنند آن‌هایی هستند که شما مدیریت می‌کنید: کلاسترهای PostgreSQL، replicaهای MySQL، shardهای MongoDB، سرویس‌های مدیریت‌شده ابری از AWS و Google. اما پایگاه داده‌ای که در مکان‌های بیشتری نسبت به مجموع همه آن‌ها قرار دارد، بی‌صدا در پس‌زمینه اجرا می‌شود، نیازی به مدیر ندارد، کمتر از ۱ مگابایت فضای دیسک برای کتابخانه خود مصرف می‌کند و یک فایل منبع C تکی است که هر توسعه‌دهنده‌ای می‌تواند در یک بعدازظهر آن را بخواند.

SQLite همه‌جا هست. این موتور ذخیره‌سازی درون هر برنامه iOS و اندرویدی است که به داده‌های ساختیافته نیاز دارد. در هر مرورگر دسکتاپ – Chrome، Firefox، Safari و Edge – برای تاریخچه، نشانک‌ها و داده‌های کش‌شده جاسازی شده است. این پایگاه داده‌ای است که نرم‌افزار مدیریت پرواز در هواپیماهای ایرباس و بوئینگ را نیرو می‌دهد. داخل تلویزیون‌ها، خودروها، مسیریاب‌ها و دستگاه‌های پزشکی قرار دارد. پروژه SQLite تخمین می‌زند بیش از یک تریلیون استقرار در حال استفاده فعال وجود دارد – عددی آنقدر بزرگ که تأیید آن دشوار است، اما با توجه به تعداد لایه‌های نرم‌افزاری که زیربنای آن است، رد کردن آن نیز دشوار است.

طراحی که آن را متفاوت می‌کند

هر پایگاه داده SQL دیگری که احتمالاً استفاده کرده‌اید یک سیستم کلاینت-سرور است: پایگاه داده به‌عنوان یک فرایند جداگانه اجرا می‌شود، شما از طریق یک socket (محلی یا شبکه) به آن متصل می‌شوید، Query ارسال می‌کنید و نتایج را دریافت می‌کنید. SQLite بدون سرور است – کل موتور پایگاه داده یک کتابخانه است که درون فرایند برنامه شما اجرا می‌شود. هیچ سروری برای راه‌اندازی وجود ندارد، هیچ فایل پیکربندی برای مدیریت وجود ندارد، هیچ سیستم مجوز کاربری وجود ندارد، هیچ پورت شبکه‌ای برای باز کردن وجود ندارد. شما به کتابخانه link می‌کنید و یک پایگاه داده کامل SQL دارید.

خود پایگاه داده یک فایل تکی در سیستم فایل است. این هم بزرگترین نقطه قوت آن است و هم محدودیت کلیدی آن. انتقال یک پایگاه داده SQLite یک کپی فایل است. پشتیبان‌گیری از آن یک کپی فایل است. بازرسی آن نیاز به ابزار خاصی ندارد – SQLite Browser یا رابط خط فرمان sqlite3 هر فایل پایگاه داده را در هر سیستم عاملی باز می‌کند. وقتی برنامه شما تمام شد، چیزی برای خاموش کردن وجود ندارد.

محدودیت هم‌روندی است: SQLite از قفل‌گذاری سطح فایل استفاده می‌کند، به این معنی که فقط یک نویسنده می‌تواند در یک زمان پایگاه داده را تغییر دهد. خواننده‌های هم‌روند متعدد اشکالی ندارد؛ نویسنده‌های هم‌روند متعدد به صورت سریال در می‌آیند. برای برنامه‌هایی با هم‌روندی نوشتاری سنگین – سرورهای وب با ترافیک بالا که درخواست‌های همزمان را مدیریت می‌کنند – این محدودیت اهمیت دارد. برای اکثر قریب‌به‌اتفاق برنامه‌ها، از جمله بیشتر برنامه‌های موبایل، ابزارهای دسکتاپ و سرویس‌های وب با ترافیک متوسط، این محدودیت اهمیتی ندارد.

چرا SQLite به‌اندازه کافی قابل اعتماد است که در هواپیما استفاده شود

کدبیس SQLite یکی از دقیق‌ترین قطعات نرم‌افزاری است که تاکنون آزمایش شده است. این پروژه تقریباً ۶۰۰ برابر کد آزمایشی نسبت به کد تولیدی حفظ می‌کند – خود کتابخانه حدود ۱۵۰,۰۰۰ خط C است؛ مجموعه آزمایشی حدود ۹۰ میلیون خط است، شامل یک SQL fuzzer کامل، TH3 (یک مهار آزمایش تجاری برای آزمایش دقیق در برابر موارد مرزی)، و آزمایش‌های جامع بازیابی خرابی.

استاندارد قابلیت اطمینان برای نرم‌افزار منبع‌باز غیرمعمول است. D. Richard Hipp، خالق SQLite، آن را به‌طور صریح برای سیستم‌های ایمنی-بحرانی هوانوردی مناسب طراحی کرده است و ایرباس و دیگران آن را مطابق با این استاندارد تأیید کرده‌اند. پایگاه داده تضمین‌های ACID – اتمیسیته، سازگاری، ایزولاسیون، دوام – را از طریق یک سیستم WAL (write-ahead log) فراهم می‌کند. خرابی در وسط یک تراکنش پایگاه داده را در یک وضعیت مشخصاً خوب باقی می‌گذارد؛ WAL تضمین می‌کند یا کل تراکنش commit می‌شود یا هیچ‌کدام، حتی در صورت قطع ناگهانی برق.

کف عملکرد شگفت‌انگیز

معماری بدون سرور SQLite به این معنی است که از سربار پایگاه‌های داده کلاینت-سرور جلوگیری می‌کند: بدون serialization داده برای ارسال روی socket، بدون زمینه‌گردانی بین فرایندهای کلاینت و سرور، بدون برنامه‌ریزی پرس‌وجو در مرز شبکه. برای workloadهایی که پرس‌وجوها ساده و پایگاه داده کوچک تا متوسط است، عملکرد SQLite اغلب با PostgreSQL قابل مقایسه و گاهی سریع‌تر است.

تیم SQLite در سال ۲۰۲۲ بنچمارک‌هایی اجرا کرد که نشان داد برای یک workload با خواندن بالا (۳۵ خواندن به ازای هر نوشتن)، SQLite روی یک SSD NVMe معمولی ۴۸,۰۰۰ تراکنش در ثانیه پردازش کرد در مقایسه با ۷,۰۰۰ تراکنش PostgreSQL – عمدتاً به این دلیل که معماری درون‌فرایندی SQLite سربار ارتباط بین‌فرایندی را حذف می‌کند. برای workloadهای با نوشتن بالا، تصویر پیچیده‌تر است؛ مدیریت هم‌روند نوشتاری PostgreSQL به آن مزیت‌هایی در سناریوهای با رقابت بالا می‌دهد.

پیامد عملی: بسیاری از برنامه‌هایی که به‌طور پیش‌فرض از PostgreSQL استفاده می‌کنند چون «درجه تولید» تلقی می‌شود، با SQLite عملکرد خوبی خواهند داشت و از نظر عملیاتی ساده‌تر خواهند بود. سرویس D1 توزیع‌شده SQLite کلادفلر و libSQL تورسو (یک fork از SQLite با پشتیبانی replication) در حال ساختن زیرساخت حول این شرط هستند که سادگی SQLite در برنامه‌های سمت سرور کم‌ارزش‌گذاری شده است.

SQLite مدرن: نسخه ۲۰۰۵ نیست

SQLite به‌طور قابل توجهی تکامل یافته است. پشتیبانی JSON که در سال ۲۰۱۵ اضافه شد و تا ۲۰۲۲ گسترش یافت، امکان پرس‌وجو و ایندکس‌گذاری داده‌های JSON تودرتو با معناشناسی کامل SQL را فراهم می‌کند – برای بسیاری از موارد استفاده با پایگاه‌های داده سند رقابت می‌کند. افزونه Full-Text Search 5 (FTS5) جستجوی تمام‌متن با رتبه‌بندی BM25 را با پرس‌وجوهای پیشوندی فراهم می‌کند، بدون نیاز به یک ایندکس جستجوی جداگانه. افزونه R*Tree پرس‌وجوهای محدوده جغرافیایی را مدیریت می‌کند. جداول مجازی به SQLite امکان پرس‌وجو از منابع داده خارجی (فایل‌های CSV، APIهای راه دور) با syntax SQL را می‌دهد.

جدیدترین افزوده، افزونه جستجوی شباهت برداری است – sqlite-vss، که بر روی کتابخانه FAISS فیسبوک ساخته شده است – که جستجوی نزدیک‌ترین همسایه تقریبی را به SQLite اضافه می‌کند. این به این معنی است که یک فایل SQLite می‌تواند اسناد، embeddingهای برداری آن‌ها را ذخیره کند و جستجوی شباهت معنایی انجام دهد، و آن را به یک پایگاه داده RAG (تولید افزایش‌یافته بازیابی) جاسازی‌شده قابل دوام برای برنامه‌های محلی هوش مصنوعی تبدیل می‌کند. ترکیب پرس‌وجوهای ساختیافته، جستجوی تمام‌متن و جستجوی برداری در یک پایگاه داده بدون پیکربندی، برای برنامه‌هایی که قبلاً به سه سیستم جداگانه نیاز داشتند، جذاب است.

زمانی که نباید از SQLite استفاده کنید

پاسخ صادقانه به «آیا باید از SQLite استفاده کنم؟» نیازمند اذعان به محدودیت‌های واقعی آن است. workloadهای نوشتاری با هم‌روندی بالا – مثلاً یک برنامه وب که هزاران تراکنش همزمان را مدیریت می‌کند – به هم‌روندی چندنویسنده‌ای که PostgreSQL ارائه می‌دهد نیاز دارند. مجموعه داده‌هایی که به طور قابل توجهی از RAM موجود بزرگ‌تر هستند از مدیریت buffer pool و برنامه‌ریز پرس‌وجوی PostgreSQL که برای سناریوهای داده بزرگ بهینه شده است، بهره می‌برند. برنامه‌هایی که نیاز به کنترل دسترسی دقیق (امنیت سطح ردیف، مجوزهای سطح ستون) دارند به یک پایگاه داده مبتنی بر سرور نیاز دارند.

اما اینها محدودیت‌هایی هستند که بر اقلیتی از استقرارها تأثیر می‌گذارند. برنامه وب معمولی CRUD، برنامه موبایل، ابزار دسکتاپ، سیستم جاسازی‌شده و اسکریپت pipeline داده همگی با سادگی SQLite به خوبی کار می‌کنند. توصیه‌ای که می‌گوید SQLite «مقیاس‌پذیر نیست» یا «آماده تولید نیست» برای یک دهه منسوخ شده است – این سیستم به صورت عمودی تا اندازه‌های بسیار بزرگ مقیاس می‌شود و از اوایل دهه ۲۰۰۰ به طور قابل اعتماد برنامه‌های تولیدی را نیرو می‌دهد. شکاف بین قابلیت‌های واقعی SQLite و شهرت آن در میان توسعه‌دهندگانی که اخیراً از آن استفاده نکرده‌اند، قابل توجه است و ارزش اصلاح دارد.