سيقوم هذا الأمر بتعيين كلمة مرور جديدة للمستخدم `test`.

## الميزات

- **مصادقة المستخدم**: تسجيل دخول آمن باستخدام اسم المستخدم وكلمة المرور.
- **تحديث كلمة المرور**: تغيير كلمة المرور للمستخدمين الموثَّقين.
- **استرجاع العَلَمة**: الحصول على العَلَمة (flag) للمستخدم المسؤول.
- **ميزات الأمان**:
  - تحديد معدل المحاولات لتسجيل الدخول.
  - التحقق من صحة الإدخال لجميع الحقول.
  - إدارة الجلسات باستخدام رموز JWT.
  - تجزئة كلمة المرور باستخدام bcrypt.

## التثبيت

1. استنساخ المستودع:
   ```bash
   git clone https://github.com/example/repo.git
   cd repo

انظر [التثبيت](#installation) لـ Node، Go، Rust، الوضع المحلي فقط، واستخدام الامتداد القابل للتحميل `.so` مباشرة

## التصميم

صُممت turbolite لقيود S3 بدلاً من قيود نظام الملفات. كل قرار ينبع من هذا النموذج:

| قيد S3 | التأثير |
|--------|---------|
| **رحلة الذهاب والإياب بطيئة** | قلل عدد الطلبات. اكتب بشكل مجمع، اقرأ مسبقاً بشكل هجومي. |
| **عرض النطاق هو عنق الزجاجة** | عزز استخدام عرض النطاق الترددي إلى أقصى حد. |
| **عمليات PUT و GET تُفرض رسوم لكل عملية** | تكلفة GET بحجم 64KB نفس تكلفة GET بحجم 16MB. حسّن عدد الطلبات، وليس كفاءة البايت. |
| **الكائنات غير قابلة للتعديل** | لا تقم بالتحديث في المكان. اكتب إصدارات جديدة، بدّل المؤشر. لا تلف ناتج عن الكتابة الجزئية. |
| **التخزين رخيص** | لا تحسّن للمساحة. وفّر في التجهيز، احتفظ بالإصدارات القديمة، واترك لمجمع القمامة التنظيف لاحقاً. |

### الهندسة المعمارية

تضيف turbolite طبقات من الفحص الداخلي والإعادة التوجيه بين SQLite و S3 تقوم بتجميع الصفحات وضغطها وتتبعها وجلبها بكفاءة.

يستخدم SQLite فهرس B-tree ويطلب صفحة واحدة في كل مرة. يعلم أن الصفحة N تقع عند الإزاحة البايتية `N * page_size`. وهذه الصفحات موزعة عشوائياً على خريطة الصفحات للوصول العشوائي الفعال. لكن على S3، جلب صفحة واحدة لكل طلب يعني آلاف عمليات GET العشوائية المحتملة لكل استعلام.

لكن الصفحات ليست متساوية. يحتوي SQLite على أنواع مختلفة من الصفحات. تفصل turbolite **مجموعات الصفحات حسب النوع**: الصفحات الداخلية لـ B-tree، وصفحات أوراق الفهرس، وصفحات أوراق البيانات.

يتم الوصول إلى الصفحات الداخلية في كل استعلام لتوجيه عمليات البحث إلى صفحات الأوراق. تكتشفها turbolite، وتخزنها في حزم مضغوطة في S3، وتحمّلها بشغف عند فتح VFS. بعد ذلك، كل مسار B-tree يصبح ضربة مخبأ.

تحصل صفحات أوراق الفهرس على نفس المعاملة: حزم منفصلة، جلب مسبق كسول في الخلفية، مثبتة ضد الإخراج. الاستعلامات الباردة تحتاج فقط إلى جلب صفحات البيانات.

تستفيد turbolite من **الفحص الداخلي لـ B-tree** لفهم *أي شجرة (جدول أو فهرس) تنتمي إليها الصفحة*، وتخزين تلك الصفحات معاً بذكاء في S3 كـ **مجموعات صفحات**: العديد من الصفحات مجزأة في كائن S3 واحد. كبيرة بما يكفي لتشبع عرض النطاق عند الجلب المسبق، وصغيرة بما يكفي للاستعلامات النقطية. الافتراضي: 256 صفحة لكل مجموعة، حوالي 16MB بصفحات 64KB.

تخزين نفس الجدول/الفهرس معاً يعني أننا نقوم بأقل عدد ممكن من عمليات GET للاستعلامات الباردة.

تقوم turbolite **بتوجيه عمليات بحث الصفحات عبر ملف بيان** هو مصدر الحقيقة حول مكان كل صفحة. يستبدل علاقة SQLite الضمنية `offset = page * size` بمؤشرات صريحة. لا يتم أبداً استبدال إصدارات مجموعة الصفحات القديمة؛ وضع البيان هو نقطة الالتزام الذرية. تصبح الإصدارات القديمة قمامة، ويتم تنظيفها بواسطة `gc()`.

يستخدم SQLite افتراضياً صفحات بحجم 4KB لمطابقة حجم صفحة قرص نظام الملفات. على S3، حجم صفحة القرص غير ذي صلة. المهم هو تقليل عدد الطلبات وتعظيم انتشار B-tree. الإجابة هي **صفحات كبيرة**: تستخدم turbolite افتراضياً صفحات بحجم 64KB. صفحات أقل = رحلات ذهاب وإياب أقل في S3 للوصول إلى ورقة.

لتسريع الاستعلامات النقطية، تستخدم turbolite **ضغطاً قابلاً للبحث**: كل مجموعة صفحات مشفرة كـ **إطارات zstd** متعددة (حوالي 4 صفحات لكل إطار). يخزن ملف البيان إزاحات البايت لكل إطار، لذا تجلب ضربة مخبأ مفقودة فقط الجزء الفرعي ~256KB الذي يحتوي على الصفحة المطلوبة عبر GET نطاق S3، وليس المجموعة بأكملها.

للجلب المسبق طبقتان: **استباقي** (التنبؤ بخطة الاستعلام) و **تفاعلي** (تكيفي يعتمد على الأخطاء).

**التنبؤ بخطة الاستعلام** يعمل أولاً. قبل تنفيذ الاستعلام، تعترض turbolite خطة استعلام SQLite عبر `EXPLAIN QUERY PLAN`، وتستخرج بالضبط الجداول والفهارس التي سيلمسها الاستعلام، وتُرسل جميع مجموعات صفحاتها إلى تجمع الجلب المسبق قبل حتى قراءة الصفحة الأولى. عملية JOIN من خمسة جداول كانت ستؤدي إلى خمس سلاسل متتالية من خطأ ثم جلب، لكنها بدلاً من ذلك تشعل جميع عمليات الجلب الخمسة بشكل متوازٍ في بداية الاستعلام. بالنسبة لاستعلامات `SCAN`، يعني هذا أن الجدول بأكمله يُجلب مسبقاً من البداية.

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

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

تُتتبع عدادات الأخطاء **لكل B-tree، وليس عالمياً**. استعلام ملف تعريف يضرب `users` (خطأ 1) ثم `posts` (خطأ 1) يتتبع كل شجرة بشكل صحيح عند 1، وليس 2. هذا يمنع استعلام JOIN متعدد الجداول من تصعيد الجلب المسبق عن طريق الخطأ على كل شجرة فقط لأنه يلمس عدة أشجار.

كل خطأ متتالي يتقدم عبر **جدول جلب مسبق** يتحكم في أي جزء من مجموعات نفس الشجرة سيتم جلبه مسبقاً. تختار turbolite جدولاً تلقائياً بناءً على خطة الاستعلام:
- **جدول البحث** `[0.3, 0.3, 0.4]`: لاستعلامات `SEARCH ... USING INDEX` التي تمسح أجزاء غير معروفة من الفهارس. عدواني من أول خطأ لأننا لا نعرف كم من الفهرس سيتم مسحه.
- **جدول الاستعلام النقطي** `[0.0, 0.0, 0.0]`: للاستعلامات النقطية وعمليات بحث الفهرس التي تصيب 1-2 صفحات لكل شجرة. ثلاث فرص مجانية قبل أي جلب مسبق. الجداول ذات الأصفار الثقيلة تتفوق على الصعود المبكر في كل من S3 Express و Tigris.

يمكنك ضبط جدول الجلب المسبق عند الفتح عن طريق تعيين `prefetch.search` / `prefetch.lookup` على `TurboliteConfig` - أنت تعرف شكل الحمل المتوقع، لذا لا يحتاج VFS إلى التخمين. انظر [تكوين الجلب المسبق](#configuring-prefetch).

كلا الجدولين يستفيدان من الفحص الداخلي لـ B-tree: كل مجموعة تم جلبها مسبقاً مضمونة أن تحتوي على صفحات من الشجرة الصحيحة. مثال: إذا طلب SQLite صفحة من جدول `users`، ثم طلب أخرى من نفس الجدول، تفترض turbolite أن مسحاً قادماً وتجلب مسبقاً بقية جدول `users` في الخلفية، ولا شيء آخر. بدون الفحص الداخلي لـ B-tree، كانت ستجلب عن طريق الخطأ نصف جدول users ونصف جدول posts فقط لأن البيانات تعيش بجانب بعضها على القرص.

**النظر إلى الأمام في أوراق الفهرس** يفعل الشيء نفسه لـ `SEARCH` المفهرس. ورقة الفهرس تدرج بالفعل rowids الجدول التي سيطلبها SQLite بعد ذلك — لذا تقوم turbolite بحلها من خلال الصفحات الداخلية المخزنة وتجلب تلك الإطارات من الجدول دفعة واحدة بدلاً من واحدة تلو الأخرى، مما يقلل عدد الطلبات.

### مخبأ الصفحات في الذاكرة

لدى turbolite مخبأ صفحات خاص بها في الذاكرة يحل محل مخبأ الصفحات المدمج في SQLite. يخبئ مُجدول صفحات SQLite الصفحات داخلياً ولا يقرأ أبداً من VFS للصفحات المخبأة. هذا جيد لقواعد بيانات ذات كاتب واحد، لكن لنسخ القراءة المتماثلة (متابعي HA، قراء استقصاء البيان)، يصبح مخبأ SQLite قديماً عندما تتغير البيانات الأساسية عبر النسخ المتماثل.

مخبأ turbolite **مدرك للبيان**: عندما يتم تشغيل `set_manifest()` (بيانات جديدة من النسخ المتماثل)، فإنه يبطل الصفحات المتأثرة في كل من مخبأ القرص ومخبأ الذاكرة. الكتابات أيضاً تبطل صفحاتها في مخبأ الذاكرة. هذا يضمن قراءات جديدة بعد النسخ المتماثل أو الكتابات.

**الهندسة المعمارية:**```
SQLite (PRAGMA cache_size=0)
  -> turbolite VFS xRead
    -> in-memory page cache (64MB default, AtomicPtr, zero-lock reads)
      -> disk cache (NVMe pread)
        -> S3 (on miss)

لإعادة الضبط لكل استعلام دون إعادة فتح الاتصال، استخدم دالة SQL `turbolite_config_set` (المرحلة Cirrus c). كل دفعة تكون محصورة في مقبض الاتصال المُستدعى وتبقى سارية المفعول حتى تغيرها مرة أخرى:```sql
SELECT turbolite_config_set('prefetch_search', '0.5,0.5,0.0');
SELECT turbolite_config_set('prefetch_lookup', '0.0,0.0,0.0');
SELECT * FROM posts WHERE created_at > ?;   -- runs with the new schedule

أو قم بتعيين `lookahead` على `TurboliteConfig` / متغير البيئة `TURBOLITE_LOOKAHEAD` عند وقت الفتح.

يمكن للمتصلين بلغة Rust استدعاء نفس المسار عبر `turbolite::tiered::settings::set`.

### الإعدادات الموصى بها

| عبء العمل | الإعداد | السبب |
|----------|--------|-----|
| OLTP المختلط | الافتراضية | معالج يعتمد على خطة التعامل مع المسح الضوئي، جدول البحث يسخن الفهارس، جدول الاستعلام يبقى محافظًا. |
| ثقيل النقاط (قواعد بيانات الوكيل) | `prefetch.lookup: vec![0.0, 0.0, 0.0]` | الاستعلامات لا تحتاج تقريبًا إلى الجلب المسبق. |
| تحليلات ثقيلة المسح | `prefetch.search: vec![0.5, 0.5]`, `prefetch.query_plan: true` | تسخين بحث عدواني بالإضافة إلى جلب مسبق جماعي يعتمد على خطة. |
| محافظ (خادم متقطع) | `prefetch.search: vec![0.1, 0.2, 0.3]`, `prefetch.lookup: vec![0.0, 0.0, 0.1]` | أقل ضوضاء جلب مسبق. |

**ملاحظة**: الجلب المسبق يكون لكل اتصال. كل اتصال جديد يبدأ بعدادات فقدان لكل شجرة باردة. ذاكرة التخزين المؤقت مشتركة، لذا يستفيد الاتصال الثاني من الصفحات المخبأة من الأول.

### أهمية خلفية التخزين

تعتمد جداول الجلب المسبق المثلى على التنازل بين زمن الاستجابة وعرض النطاق الترددي لخلفية S3 الخاصة بك. اختبرنا 10 أزواج جداول عبر 6 استعلامات على كل من S3 Express (~4ms GET) و Tigris (~25ms GET):

| الخلفية | زمن استجابة GET | أفضل استعلام نقطي | أفضل ملف تعريف | كسب الضبط |
|---------|-------------|-------------------|-------------|-------------|
| **S3 Express** | ~4ms | 74ms (off/off: 96ms) | 188ms (off/off: 212ms) | 5-23% مقارنة بعدم الجلب المسبق |
| **Tigris** | ~25ms | 192ms (off/off: 231ms) | 524ms (off/off: 616ms) | 8-34% مقارنة بعدم الجلب المسبق |

على S3 Express، يكون `off/off` (بدون جلب مسبق على الإطلاق) تنافسيًا بشكل مفاجئ للاستعلامات النقطية لأن كل GET لنطاق فرعي صغير يستغرق حوالي 4 مللي ثانية فقط. الفجوة بين "بدون جلب مسبق" و"الجلب المسبق الأمثل" صغيرة (23% للاستعلامات النقطية) لأن عمليات GET الفردية رخيصة. على Tigris، يستفيد نفس الاستعلام بشكل أكبر من الجلب المسبق (حتى 39% على idx-filter) لأن كل دورة مهدورة تكلف 25 مللي ثانية.

التأثير العملي: على الخلفيات ذات زمن الاستجابة العالي، ادفع جداول البحث بقوة أكبر واحتفظ بجداول الاستعلام مع المزيد من الأصفار البادئة. على S3 Express، تعمل الإعدادات الافتراضية بشكل جيد ويوفر الضبط مكاسب أصغر. أداء المسح الكامل غير حساس للجدول على كلا الخلفيتين لأن التنفيذ المسبق لخطة الاستعلام يقوم بجلب مسبق جماعي للجدول بالكامل مقدمًا.

استخدم `tiered-tune` (انظر أدناه) للعثور على الجداول المثلى لخلفيتك واستعلاماتك المحددة.

### أداة الضبط

يتصل `tiered-tune` بقاعدة بيانات turbolite موجودة ويبحث في جداول الجلب المسبق مقابل استعلاماتك الفعلية. بدلاً من تخمين الجداول، قم بتشغيل حملك الفعلي ودع الأداة تجد أفضل زوج:```bash
# Connect to existing database, test your queries
cargo run --release --features cloud,zstd --bin tiered-tune -- \
  --prefix "databases/tenant-123" \
  --query "SELECT * FROM users WHERE id = ?1" \
  --query "SELECT p.*, u.name FROM posts p JOIN users u ON p.user_id = u.id WHERE p.id = ?1" \
  --iterations 10

# Custom schedule grid
cargo run --release --features cloud,zstd --bin tiered-tune -- \
  --prefix "databases/tenant-123" \
  --query "SELECT * FROM orders WHERE user_id = ?1 ORDER BY created_at DESC LIMIT 20" \
  --search-schedules "0.3,0.3,0.4;0.5,0.5;1.0" \
  --lookup-schedules "0;0,0,0.1;0,0,0,0.1,0.2" \
  --iterations 10

[No content provided for translation.]```rust
let config = TurboliteConfig {
    wal_replication: true,  // enable WAL shipping
    ..Default::default()
};

**Node.js**: `npm install turbolite` — see [turbolite-ffi/packages/node/](https://github.com/russellromney/turbolite/blob/HEAD/turbolite-ffi/packages/node/)

**Rust**:```toml
[dependencies]
turbolite = "0.5"                                              # local VFS
turbolite = { version = "0.5", features = ["cloud"] }          # + S3 storage
turbolite = { version = "0.5", features = ["encryption"] }     # + encryption

```go
// #cgo LDFLAGS: -L/path/to/target/release -lturbolite
// #include <stdlib.h>
// extern int turbolite_register_local_file_first(const char* name, const char* db_path, int level);
// extern void* turbolite_open(const char* path, const char* vfs_name);
// extern int turbolite_exec(void* db, const char* sql);
// extern char* turbolite_query_json(void* db, const char* sql);
// extern void turbolite_close(void* db);
import "C"

Please provide the Markdown content to translate.```c
sqlite3_enable_load_extension(db, 1);
sqlite3_load_extension(db, "path/to/turbolite", NULL, NULL);
// "turbolite" VFS (local) is always registered
// "turbolite-s3" is a single-volume convenience VFS when TURBOLITE_BUCKET is set

لتكوين نظام الملفات الافتراضي `"turbolite"` لوضع الملف أولاً عند وقت تحميل الإضافة، قم بتعيين `TURBOLITE_DATABASE_PATH=/data/app.db` في البيئة قبل تحميل الإضافة. يكون الملف الجانبي عندها `/data/app.db-turbolite/` ويتم تجاهل المتحكم الأدنى `TURBOLITE_CACHE_DIR`.
### Node.js```bash
npm install turbolite

INPUT:
``````js
const { connect } = require("turbolite");

// File-first: /data/app.db is the local page image.
// /data/app.db-turbolite/ holds hidden implementation state.
const db = connect("/data/app.db");
db.exec("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)");
db.prepare("INSERT INTO users VALUES (?, ?)").run(1, 'alice');

const rows = db.prepare("SELECT id, name FROM users").all();
// [{ id: 1, name: 'alice' }]
db.close();

النموذج ذو المستوى المنخفض يتيح لك اختيار دليل التخزين المؤقت مباشرة:```rust
let config = TurboliteConfig {
    cache_dir: "/path/to/data".into(),  // turbolite owns this dir
    ..Default::default()
};

`app.db` هي صورة الصفحة المضغوطة لـ turbolite. ليس من المضمون أن يتم فتحها مباشرة بواسطة `sqlite3` القياسي. بالنسبة لملف SQLite عادي (مثل واجهة سطر الأوامر `sqlite3`)، استخدم واجهة برمجة تطبيقات النسخ الاحتياطي عبر الإنترنت لـ SQLite أو أداة التصدير الخاصة بالربط (`conn.iterdump()` في بايثون، `db.backup()` في نود).

## CLI```bash
cargo install turbolite --features cloud,zstd

تقبل جميع أوامر S3 العلامات `--bucket` و`--prefix` و`--endpoint` و`--region`، أو تقرأ من متغيرات البيئة `TURBOLITE_BUCKET` و`TURBOLITE_PREFIX` و`AWS_ENDPOINT_URL` و`AWS_REGION`.

## المشاريع ذات الصلة والمقارنة

هناك العديد من المشاريع في مجال SQLite عبر الشبكة. يستعير turbolite أفكارًا من جميعها.

### طلبات النطاق على ملفات .db الخام (للقراءة فقط)

النهج الأكثر شيوعًا: وضع ملف `.db` غير معدل على S3 أو CDN وإصدار طلبات HTTP Range GET عندما يقرأ SQLite صفحة.

- [**sql.js-httpvfs**](https://github.com/phiresky/sql.js-httpvfs): الأصلية. WASM SQLite مع طلبات HTTP Range. يحتوي على رؤوس قراءة افتراضية مع جلب مسبق أسي للمسح الضوئي. كانت رائدة فكرة أنك لست بحاجة إلى تنزيل قاعدة البيانات بأكملها للاستعلام عنها.
- [**sqlite_web_vfs**](https://github.com/mlin/sqlite_web_vfs): إضافة VFS أصلية بلغة C++ مع دمج الطلبات التكيفي وملف فهرس `.dbi` اختياري يجمع عُقد B-tree الداخلية مسبقًا للجلب المسبق - نفس فكرة حزم الصفحات الداخلية في turbolite. مصمم للتوافق مع sqlite_zstd_vfs.
- [**sqlite3vfshttp**](https://github.com/psanford/sqlite3vfshttp): VFS نظيف وبسيط بلغة Go. مبني للاستعلام عن SQLite في S3 من Lambda دون تنزيل الملف.
- [**sqlite-s3-query**](https://github.com/michalc/sqlite-s3-query): مكتبة Python تستخدم ctypes لاعتراض إدخال/إخراج الملف وترجمة القراءات إلى طلبات S3 Range GET. تتطلب مجلدات ذات إصدار للاتساق أثناء استبدال قاعدة البيانات.
- [**sqlite-wasm-http**](https://github.com/mmomtchev/sqlite-wasm-http): الخلف الروحي لـ sql.js-httpvfs باستخدام بناء SQLite WASM الرسمي. ذاكرة تخزين مؤقت للصفحات مشتركة عبر SharedArrayBuffer. نشط الصيانة.
- [**s3sqlite](https://github.com/litements/s3sqlite): Python، يستخدم s3fs (FUSE) + APSW. يترك FUSE يتعامل مع طلبات النطاق.

هذه جميعها للقراءة فقط وتجلب الصفحات غير المضغوطة من الملف الخام. بحث نقطة واحد ينقل صفحة خام بحجم 4KB (أو 64KB) لكل طلب.

### تكرار/مزامنة على مستوى الصفحة

تعامل هذه المشاريع التخزين الكائني كمصدر للحقيقة وتكرر الصفحات الفردية أو مجموعات التغييرات، مما يتيح النسخ المتماثلة الجزئية والنشر في وضع عدم الاتصال/الحافة.

- [**Graft**](https://graft.rs/) ([`orbitinghail/graft`](https://github.com/orbitinghail/graft)): محرك تخزين معاملات للنسخ المتماثل الكسول والجزئي والمتسق بقوة عبر S3. إضافة SQLite `libgraft` تنفذ VFS يقرأ ويكتب صفحات بحجم 4KB عبر وحدات تخزين Graft. يستخدم ضغط zstd المؤطر ومجموعات تغييرات قائمة على splinter. أقرب قريب معماري لـ turbolite في مجال "تكرار الصفحات، وليس إطارات WAL"، مع التركيز على مزامنة الحافة متعددة الكُتّاب بدلاً من زمن وصول القراءة الباردة.
- [**mvsqlite**](https://github.com/losfair/mvsqlite): الصفحات مخزنة في FoundationDB كأزواج قيمة-مفتاح موجهة بالمحتوى. MVCC كامل مع السفر في الزمن إلى أي لقطة، ترميز delta XOR+zstd بين إصدارات الصفحة. أكثر محركات التخزين تطورًا في هذا المجال، ولكنه يتطلب FoundationDB، وليس S3.

### التكرار والنسخ الاحتياطي إلى S3

تكرر هذه المشاريع الكتابات المحلية إلى S3 للنسخ الاحتياطي أو الاستعادة.

- [**Litestream**](https://github.com/benbjohnson/litestream): يشحن إطارات WAL باستمرار إلى S3. المعيار الذهبي لنسخ SQLite الاحتياطي. يمكن لـ VFS الأحدث في Litestream تقديم القراءات من S3 باستخدام طلبات النطاق على ملفات LTX مع ذاكرة تخزين مؤقت LRU وفهرس صفحات — أقرب شيء معماريًا لمسار القراءة في turbolite، لكنه للقراءة فقط ومرتبط بتنسيق تكرار Litestream.
- [**LiteFS**](https://github.com/superfly/litefs): نظام أساسي/تابع قائم على FUSE من Fly.io. يلتقط مجموعات تغييرات الصفحات ويدفقها إلى النسخ المتماثلة. يحل مشكلة التوفر، وليس التخزين.
- [**Verneuil**](https://github.com/backtrace-labs/verneuil): يقسم قاعدة البيانات إلى أجزاء بحجم 64KB مع ضغط zstd وملف بيان، ويكرر بشكل غير متزامن إلى S3. نموذج الجزء+البيان يشبه مجموعات الصفحات + البيان في turbolite، ولكن Verneuil أداة تكرار - تستعلم من القرص المحلي، وليس S3.
- [**libSQL/sqld**](https://github.com/tursodatabase/libsql) (بواسطة Turso): Fork من SQLite مع واجهة WAL افتراضية. وضع "Bottomless" يشحن إطارات WAL إلى S3. الاستعلامات محلية؛ S3 للاستعادة.

### محركات تخزين مخصصة

- [**sqlite-s3vfs**](https://github.com/simonw/sqlite-s3vfs): كل صفحة SQLite مخزنة ككائن S3 منفصل. يتيح الكتابات ولكن بتكلفة PUT واحدة لكل صفحة، تكلفة 0.02 دولار لكل 4096 صفحة مقابل 0.000005 دولار من turbolite لنفس الدفعة (بحجم صفحة افتراضي 64KB). انظر جدول المقارنة أعلاه لزمن وصول الاستعلام البارد؛ turbolite أسرع بمقدار 7.5–263× على نفس مجموعة البيانات.
- [**wa-sqlite-s3vfs**](https://github.com/LoneRifle/wa-sqlite-s3vfs): منفذ TypeScript / متصفح لـ sqlite-s3vfs لـ `wa-sqlite`. نفس نموذج كائن واحد لكل صفحة، مكيف للاستخدام مع WASM / جانب العميل.

### الضغط

- [**sqlite_zstd_vfs**](https://github.com/mlin/sqlite_zstd_vfs): يخزن الصفحات المضغوطة كصفوف في قاعدة بيانات "غلاف" خارجية. ضغط zstd مع تدريب القاموس. يتوافق مع sqlite_web_vfs لقراءات مضغوطة عبر طلبات النطاق عبر HTTP. الجمع بين sqlite_web_vfs + sqlite_zstd_vfs هو على الأرجح أقرب شيء موجود لمسار القراءة في turbolite، لكنه للقراءة فقط ولا يجمع الصفحات في مجموعات.
- [**SQLCipher**](https://github.com/sqlcipher/sqlcipher): تشفير AES-256 على مستوى الصفحة لـ SQLite المحلي. لا تخزين عن بعد.

### أين يختلف turbolite

| | turbolite | Raw-file range GETs | Litestream VFS | sqlite_web_vfs + zstd_vfs | mvsqlite | Graft | sqlite-s3vfs |
|---|---|---|---|---|---|---|---|
| القراءة من S3 | طلبات range GET قابلة للبحث على مجموعات الصفحات المضغوطة | طلبات range GET على الصفحات الخام | طلبات range GET على ملفات LTX | طلبات range GET على قاعدة البيانات الخارجية المضغوطة | عمليات بحث KV على FoundationDB | جلب كسول للصفحات 4KB / مجموعات التغييرات | GetObject واحد لكل صفحة |
| الكتابة إلى S3 | نقطة تفتيش (PUT واحد لكل مجموعة) | لا | لا | لا | نعم (MVCC) | نعم (تكرار مجموعات التغييرات غير المتزامن) | PUT واحد لكل صفحة |
| الضغط | zstd متعدد الإطارات قابل للبحث | لا | لا | zstd (قاعدة بيانات متداخلة) | ترميز delta zstd | zstd مؤطر | لا |
| التشفير | AES-256-GCM لكل صفحة | لا | لا | لا | لا | غير مذكور | لا |
| الجلب المسبق | نظرة للأمام + جدول قفز | لا أو قراءة مسبقة أساسية | ذاكرة تخزين مؤقت LRU | دمج تكيفي | مخازن العميل | كسول / حسب الطلب | لا |
| تحسين الصفحات الداخلية | مكتشفة، مثبتة، مجمعة بشكل منفصل | لا | فهرس الصفحات من ذيل LTX | ملف `.dbi` اختياري | لا | غير مذكور | لا |
| بايت لكل بحث نقطة (ذاكرة تخزين مؤقت: فهرس) | ~100KB (إطار مضغوط واحد) | 4-64KB (صفحة خام واحدة) | يختلف | يختلف | يختلف | 4KB (صفحة واحدة) | 4KB (صفحة واحدة) |
| تكلفة الكتابة لكل 4096 صفحة | ~0.000005 دولار (PUT واحد) | غير متاح | غير متاح | غير متاح | عمليات FoundationDB | مجموعات تغييرات مجمعة | ~0.02 دولار (4096 PUT) |

## الاختبارات المعيارية

جميع الاختبارات المعيارية موجودة في [`benchmark/`](https://github.com/russellromney/turbolite/blob/HEAD/benchmark/). انظر [`benchmark/README.md`](https://github.com/russellromney/turbolite/blob/HEAD/benchmark/README.md) لسيناريوهات النشر (محلي، Fly.io، EC2).

يقوم الثنائي `tiered-bench` بتوليد مجموعة بيانات وسائل التواصل الاجتماعي (المستخدمون، المنشورات، الإعجابات، الصداقات) واختبار الاستعلامات على كل مستوى من مستويات التخزين المؤقت مقابل S3.

يقوم إطار منفصل [`benchmark/bench_s3vfs.py`](https://github.com/russellromney/turbolite/blob/HEAD/benchmark/bench_s3vfs.py) بتشغيل نفس الاستعلامات مقابل [sqlite-s3vfs](https://github.com/simonw/sqlite-s3vfs) للمقارنة المباشرة. يتم نشره عبر [`benchmark/fly-s3vfs.toml`](https://github.com/russellromney/turbolite/blob/HEAD/benchmark/fly-s3vfs.toml) ويستخدم نفس مولد مجموعة البيانات الحتمية مثل `tiered-bench`.```bash
# Basic benchmark: 100K posts, default settings
TIERED_TEST_BUCKET=my-bucket AWS_ENDPOINT_URL=https://t3.storage.dev \
  cargo run --features zstd,cloud --bin tiered-bench --release -- \
    --sizes 100000

# 1M posts, 8 prefetch threads, only interior-level point queries
cargo run --features zstd,cloud --bin tiered-bench --release -- \
    --sizes 1000000 --prefetch-threads 8 --queries post --modes interior

# Quick local VFS comparison (no S3 needed)
cargo run --example quick-bench --features encryption --release

## اختبار```bash
cargo test --features zstd                    # local VFS tests
cargo test --features zstd,cloud             # + S3 integration tests
cargo test --features zstd,encryption         # + encryption tests