تیم SQLite، در حال توسعه‌ی ابزاری برای رپلیکیشن SQLite است. اگر با مفهوم رپلیکیشن دیتابیس‌ها آشنا هستید از روی بخش زیر عبور کنید.
رپلیکیشن در پایگاه‌داده، به معنی انتقال بخشی یا همه‌ی داده‌ها (و یا ساختار) از یک دیتابیس به دیتابیس دیگه است. دیتابیس مقصد که عموما بهش Replica یا Subscriber یا… گفته می‌شه می‌تونه دور یا نزدیک باشه (نزدیک: روی همون ماشینی که دیتابیس مبدأ روش قرار داره. دور: دیتابی مقصد روی ماشین دیگه‌ای باشه، حالا داخل همون دیتاسنتر یا دیتاسنتر دیگه).
انواع مختلفی از Replication وجود داره که هر کدوم برای سناریوها و نیازهای خاصی طراحی شده:۱: رپلیکیشن مبتنی بر اسنپ‌شات (Snapshot Replication):
یک نسخه از پایگاه داده در یک زمان مشخص (Snapshot) روی پایگاه داده مقصد اعمال می‌شه. این نوع رپلیکیشن برای شرایطی مناسبه که به داده‌های کاملاً به‌روز نیازی نیست و می‌شه به صورت دوره‌ای داده‌ها رو به‌روزرسانی کرد و البته سایز دیتابیس هم متناسب با زیرساخت باشه.۲: رپلیکیشن تراکنشی (Transactional Replication):
این نوع رپلیکیشن، تغییرات و تراکنش‌ها رو به‌صورت بلادرنگ یا با تاخیر از پایگاه داده اصلی به نسخه‌های رپلیکیت‌شده منتقل می‌کنه. این روش مناسب برای سیستم‌هایی است که به داده‌های به‌روز و هماهنگ نیاز دارن، مثلاً وقتی تغییر داده‌ها روی یک سرور است، و یک یا چند سرور برای گزارش‌گیری نیاز داریم.رپلیکیشن همگام (Synchronous Replication):
در این روش، هر تغییر در پایگاه داده اصلی به طور همزمان در نسخه‌های رپلیکیت‌شده اعمال می‌شه. این روش به دلیل انتظار برای اعمال تغییر در مقصد، کُند‌تر است اما تضمین می‌کنه که نسخه‌ها، همواره به‌روز و یکسان هستن، که برای نرم‌افزارهای مهم و حیاتی کاربردیه.رپلیکیشن ناهمگام (Asynchronous Replication):
تغییرات پس از وقوع در پایگاه داده اصلی به نسخه‌های رپلیکیت‌شده ارسال می‌شن، اما این فرآیند با تاخیر زمانی انجام می‌شه. این روش انعطاف‌پذیرتره و بار کمتری به سیستم وارد می‌کنه اما ممکنه نسخه‌ها همیشه به‌روز نباشن.رپلیکیشن مبتنی بر لاگ (Log-Based Replication): این روش از لاگ‌های تراکنش برای تکرار تغییرات در نسخه‌های رپلیکیت‌شده استفاده می‌کنه. معمولاً در روش‌های جدیدتر و پیچیده‌تر مورد استفاده قرار می‌گیره و امکان تکرار دقیق تغییرات رو فراهم می‌کنه.
رپلیکیشن Peer-to-Peer (P2P):
توی این روش هر سرور دیتابیس هر تغییری رو دریافت کنه برای بقیه سرورها هم ارسال می‌کنه تا امکان خوندن و نوشتن و همگام بودن اطلاعات همه جا فراهم بشه.⚠️ البته دقت کنید که توضیحات بالا رو به صورت عمومی نوشتم و همه دیتابیس‌انجین‌ها همه‌ی این روش‌ها رو پشتیبانی نمی‌کنن.
هر کدوم از این روش‌ها با توجه به نیاز ما به میزان همگام بودن داده‌ها و شرایط و امکانات دیتابیس‌انجین و زیرساخت‌ها انتخاب می‌شن.
حالا تیم SQLite در حال تدارک ابزاری برای ایجاد رپلیکیشن مدل snapshot است، حتی در شرایطی که عملیات خواندن و نوشتن در حال انجام باشه.
ابزار sqlite3-rsync می‌تونه پایگاه داده مبدا رو به یک مکان محلی (همون ماشین) یا راه دور (ماشین دیگه و از طریق شبکه) کپی کنه (برای گزارش‌گیری یا بکاپ). در ضمن، در صورت کپی از راه دور، از پروتکل SSH برای رمزگذاری داده‌ها استفاده می‌کنه. مقصد، که در مستندات اولیه با نام REPLICA (نسخه‌ی تکراری) معرفی شده، می‌تونه از قبل وجود داشته باشه و اتصالاتش در حین فرآیند رپلیکیشن برقرار و فعال بمونه، اگرچه این اتصالات فقط خواندنی هستن. همچنین نسخه‌ی رپلیکیت‌شده در نهایت به‌صورت یک عکس لحظه‌ای از پایگاه داده مبدا در زمان اجرای ابزار عمل می‌کنه؛ بنابراین، اگر تغییراتی در مقصد اعمال شده باشد که در مبدا نیست، این تغییرات از بین خواهند رفت؛ و اگر در مبدا تغییرات جدیدی در حین فرآیند رپلیکیشن انجام شده باشه، این تغییرات شامل نخواهد شد.
در حال حاضر یک API پشتیبان‌گیری برای SQLite وجود داره که پایگاه داده رو قفل می‌کنه تا بتونه بکاپ بگیره، اگرچه می‌تونه به‌صورت مرحله‌ای اجرا بشه تا از ایجاد وقفه و تاخیر زیاد برای کاربرها جلوگیری کنه. همچنین دستور VACUUM INTO وجود داره که امکان خروجی گرفتن یک پایگاه داده به یک فایل رو فراهم می‌کنه.
ولی ابزار جدید (sqlite3_rsync) دارای ویژگی‌های منحصربه‌فردیه؛ از جمله اینکه از ابتدا برای پشتیبانی از نسخه‌های رپلیکیت‌شده راه دور طراحی شده و نه فقط فایل‌های محلی. همچنین این ابزار بسیار کارآمده از نظر سرعت و مصرف منابع، چون داده‌هایی که نیازی به ارسال ندارن رو شناسایی می‌کنه؛ مثل داده‌هایی که توی مقصد از قبل با مبدا سینک شده باشن. چجوری؟ این‌جور که نسخه‌ی تکراری یک hash از هر واحد که page یا صفحات ذخیره‌سازی هستش می‌سازه و ارسال می‌کنه تا در صورتی که این هش در مقصد، با مبدا یکی باشه، هیچ داده‌ای برای اون صفحه منتقل نمی‌شه. مستنداتش می‌گه که «برای پایگاه‌های داده‌ای که اندازه pageهاش ۴۰۹۶ بایت باشه، حداقل پهنای باند مورد نیاز برای اجرای این ابزار حدود ۰.۵٪ از اندازه‌ی پایگاه داده است.»
محدودیت‌های این ابزار جدید شامل موارد زیره:
- هر دو پایگاه داده باید از لاگ پیش‌نویس (write-ahead logging) و اندازه page یکسانی استفاده کنن.
- ابزار تنها می‌تونه یک پایگاه داده رو در آن واحد همگام‌سازی کنه.
این ابزار جدید علاوه بر امکان پشتیبان‌گیری، برای سناریوهایی که تعداد کاربرهای فقط‌خواندنی زیاد باشن یا نیاز به گزارش‌گیری باشه و همچنین نسخه‌های رپلیکیت‌شده که کمی به‌روز نباشند قابل قبول باشه هم جذاب می‌شه.
SQLite یک دیتابیس کوچک، قابل حمل و مناسب برای کاربردهای embedded است، اما می‌تونه با حجم زیادی از داده‌ها هم کار کنه. حداکثر اندازه‌ی نظری یک پایگاه داده SQLite حدود ۲۸۱ ترابایت است! اگرچه مستندات می‌گن که «این ماکسیموم سایز، به‌طور کامل آزمایش نشده چون توسعه‌دهنده‌ها به سخت‌افزاری با ظرفیت بالا برای رسیدن به این حد دسترسی ندارند.»
هنوز زمانی برای عرضه‌ی نسخه‌ی تولیدی sqlite3-rsync منتشر نشده، اما کد آن موجوده و گزارش‌های باگ به سرعت برطرف می‌شن، بنابراین در توسعه‌ی فعال آن شکی وجود نداره.