در مخزنِ دارای نسخه‌های متعددِ کلید، نشانِ حذف ممکن است هنوز لازم باشد تا مقدارِ قدیمی‌تر دیده نشود. Compaction فقط انتخابِ تازه‌ترینِ هر کلید نیست؛ snapshotهای زنده نیز می‌توانند به نسخهٔ قبلی نیاز داشته باشند. این تمرینِ حافظه‌ای هر دو خطای حذفِ زودهنگام را با تاریخچهٔ کوچک و کنترلِ خواندن نشان می‌دهد.
یک کلید، چند شمارهٔ نسخه
تاریخچهٔ اصیل چنین است: a در شماره۰مقدار ancient، در۱مقدار old و در۳نشانِ حذف دارد. b در۲مقدار beta و در۴مقدار new می‌گیرد؛ c در۵مقدار gamma دارد. شماره‌ها ترتیبِ نسخه‌اند، نه زمانِ واقعی یا شناسهٔ مشتری. ورودی بر کلیدِ صعودی و شمارهٔ نزولی مرتب است.
خواندن در snapshotِ s، تازه‌ترینِ نسخهٔ همان کلید با شمارهٔ حداکثر s را می‌خواهد. نشانِ حذف نتیجهٔ منطقیِ ناموجود می‌دهد؛ در این مدل None هم نبودِ نسخه و هم حذف را در خروجیِ خواندن نشان می‌دهد، نه پاک‌شدنِ فیزیکیِ بایت‌ها.
قدیمی‌ترین خواننده هنوز شماره۲را می‌خواهد
با oldest=۲، نشانِ حذفِ a در۳برای خواندنِ فعلی لازم است، اما خوانندهٔ۲باید مقدارِ old از۱را ببیند. نگه‌داشتنِ فقطِ نسخهٔ۳، آن خواننده را بی‌جواب می‌کند. نسخهٔ۰از a برای هیچ snapshotِ مجازِ ۲یا بالاتر لازم نیست و قابل کنارگذاشتن است.
خروجیِ واقعی پنج رکورد نگه می‌دارد: a۳حذف،a۱old،b۴new،b۲beta وc۵gamma. صرفِ کمترشدنِ تعدادِ رکورد، معیارِ صحت نیست؛ باید همان خواندن‌هایی که تعهد کرده‌ایم حفظ شوند. نسخهٔ b۲نیز برای snapshot۲یا۳هنوز لازم است.
چرا حذفِ همهٔ tombstoneها غلط است؟
کد عمداً تمام نشان‌های حذف را از نسخهٔ غلط کنار می‌گذارد. اکنون خواندنِ فعلیِ a مقدارِ old را بازمی‌گرداند، درحالی‌که تاریخچهٔ اصلی در شماره۵آن را حذف‌شده می‌داند. این زنده‌شدنِ منطقیِ مقدارِ قدیمی، شاهدِ مشخصِ خطاست؛ هیچ دادهٔ واقعیِ پایگاه پاک یا بازیابی نشده است.
نسخهٔ غلطِ دیگر فقط تازه‌ترین رکوردِ هر کلید را نگه می‌دارد. خواندنِ a در۲ناموجود می‌شود، اما مرجع old دارد. این دو خطا متفاوت‌اند: یکی حذفِ فعلی را می‌شکند و دیگری دیدِ تاریخیِ خواننده را. یک تستِ فقطِ زمانِ فعلی، خطای دوم را نمی‌بیند.
سطحِ قدیمیِ بیرون از compaction مهم است
آزمایشِ جدا فقط a۳حذف وa۱old را در ورودیِ ادغام دارد؛ نسخهٔ a۰ممکن است در سطحِ قدیمیِ خارج از ادغام باقی باشد. با oldest=۳و وجودِ آن سطح، نشانِ حذف نگه می‌ماند تا ancient بیرونی را بپوشاند، اما a۱پوشیده کنار می‌رود.
اگر هیچ سطحِ قدیمیِ دارایِ همان کلید نباشد، همین نشانِ حذفِ ۳هم می‌تواند با نسخه‌های پوشیدهٔ درونِ ادغام کنار برود. این شرط به اطلاعاتِ معتبرِ مخزن نیاز دارد؛ حدسِ نبودِ سطح قدیمی کافی نیست. فایل، پرچمِ صریحِ این فرض را می‌گیرد و LevelDB واقعی را باز نمی‌کند.
خواندنِ قبل و بعد را مستقل مقایسه کنیم
تمامِ سه کلید و snapshotهای۲تا۵قبل و بعد کنترل می‌شوند. در حالتِ ادغامِ جزئی نیز برای oldestهای۰تا۵و هر دو فرضِ وجودِ سطح قدیمی،۴۲خواندن با مرجعِ مستقل برابرند. مرجع، بزرگ‌ترینِ شمارهٔ مجاز را مستقیم از تاریخچه پیدا می‌کند؛ از شرطِ حذفِ compactor استفاده نمی‌کند.
شش ورودیِ نامعتبر، از نسخهٔ متناقضِ تکراری و run نامرتب تا شمارهٔ منفی یا پرچمِ کلیدِ ناشناخته، رد می‌شوند. سقفِ محلی۳۲رکورد و شماره۰تا۱۰۰است. پشتیبانِ WAL تصویرِ سازگار و حذف سند از RAG لایه‌های مشتق را بررسی می‌کنند؛ اینجا دیدِ نسخهٔ کلید موضوع است.
ادامه در مبانی هوش مصنوعی؛ فایلِ SSTable،دیسک،دوام،پاک‌سازیِ خصوصی یا معماریِ ذخیره‌سازیِ اپرا آزمایش نشده‌اند.
فایل تمرین و منبع
کد کاملِ تمرینِ مستقل و کنترل‌ها؛ Python · ورودی و تمامِ خروجیِ اجرای واقعی؛ JSON
- مرجع اصلی LevelDB؛ بخش جدول‌های مرتب وCompactions،دلیلِ نشانِ حذف و سطح‌های قدیمی خوانده شد؛ اعدادِ عملکردِ منبع استفاده نشده‌اند
- کد اصلی LevelDB،تعریفِ smallest_snapshot وشرط‌های drop درDoCompactionWork خوانده شد؛ کدِ Python حافظه‌ای مستقل است وLevelDB اجرا نشده
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.