سختترین مسئله دیتابیس توزیعشده: تراکنش قوی روی دادهای که در چند قاره کپی شده است. دههها گفته میشد «یا سازگاری یا سرعت جهانی» — تا اینکه Google با Spanner ترفند عجیبی زد: بهجای حدس زدن زمان، عدمقطعیتِ زمان را اندازه گرفت و صبر کرد.
مسئله: ساعت، دشمنِ ترتیب
در فصل ۹ دیدیم که ساعت ماشینها دقیق نیست (skew چند میلیثانیه تا ثانیه). حالا تصور کن تراکنش T1 در اروپا commit میشود و یک میلیثانیه بعد T2 در آمریکا — با ساعتهای معمولی هیچکس نمیتواند بگوید کدام اول بود؛ ولی برای external consistency (همان linearizability در مقیاس سراسری) باید ترتیب واقعی حفظ شود.
TrueTime: نه «زمان دقیق»، بلکه «بازه دقیقِ عدمدقت»
قیمت: commit-wait چند میلیثانیه تأخیر به هر تراکنش اضافه میکند و به زیرساخت زمانِ ویژه نیاز دارد. CockroachDB همین ایده را با HLC (فصل ۹) و بدون ساعت اتمی پیاده میکند و برای اطمینان، «عدمقطعیت بیشتر» را با مکانیزمهای دیگر جبران میکند. درس بزرگتر: جادوی Spanner نه در الگوریتم که در صادقانهمدلکردنِ زمان است — عدمقطعیت را پنهان نکرد، اندازهاش گرفت و کنارش حساب کرد.
کی دیتابیس سراسری میخواهی؟
- وقتی چند region فعال میخواهی ولی از درد conflict resolution و multi-leader فرار میکنی: Spanner/Cockroach تراکنش سازگار سراسری میدهند به قیمت تأخیر نوشتن (RTT بین region ها + commit-wait).
- برای اغلب سیستمها همان الگوی فصل ۹ کافی است: home region برای نوشتن + replica برای خواندن جهانی.
- قبل از انتخاب، SLO بخوان: اگر کاربرانت در یک قارهاند، دیتابیس سراسری پیچیدگی اضافه است؛ اگر RTO/RPO≈0 بینقارهای با سازگاری قوی میخواهی، این خانواده ساخته شده برای دقیقاً همان.
به زبان ساده
Spanner با ساعتهای اتمی و اتم GPS بازه «عدم قطعیت زمان» را میسنجد و با صبرکردنِ آن بازه، به همه دنیا یک ترتیب واحدِ تراکنش میدهد.
مثال واقعی
دو نفر در دو سرِ زمین همزمان آخرین بلیت را میخرند؛ Spanner بهجای حدس زدن ساعت، چند میلیثانیه صبر میکند تا مطمئن شود کدام تراکنش واقعاً اول بود.