انتخاب پایگاه داده: رابطهای، سندی یا هر دو
بحث انتخاب پایگاه داده معمولاً از سمت اشتباه شروع میشود: کدام سریعتر است، کدام جدیدتر است، تیم با کدام راحتتر است. سؤال درست این است که شکل داده و شکل پرسشهای شما چیست.
پاسخ پیشفرض
برای اکثریت قاطع سامانههای سازمانی، پایگاه دادهٔ رابطهای انتخاب درست است. این را صریح میگوییم چون بحث معمولاً طوری پیش میرود که انگار انتخاب باز است.
دلیلش هم مد نیست:
دادهٔ سازمانی ذاتاً رابطهای است. سفارش به مشتری وصل است، مشتری به قرارداد، قرارداد به لیست قیمت. اینها را میشود در سند تودرتو هم ریخت، ولی بعد هر تغییر مشتری یعنی بهروزرسانی هزار سند.
تراکنش. «موجودی کم شد و سفارش ثبت شد» باید هر دو اتفاق بیفتد یا هیچکدام. این تضمین در پایگاه دادهٔ رابطهای رایگان است و در بقیه باید ساخته شود.
گزارش. سؤالهایی که امروز نمیدانید فردا میپرسید. با SQL میشود پرسیدشان بدون اینکه ساختار داده را از قبل برایشان چیده باشید.
و یکپارچگی. کلید خارجی جلوی سفارشی که به مشتری ناموجود اشاره میکند را میگیرد، در سطح پایگاه داده و نه در سطح کدی که ممکن است یک مسیرش فراموش شود.
کجا این فرض عوض میشود
دادهٔ بیساختار یا با ساختار متغیر. لاگ رویداد، پاسخ سرویسهای بیرونی، مشخصات محصولی که در هر دسته کاملاً فرق دارد.
هرچند اینجا هم یک نکته هست: پایگاههای رابطهای مدرن ستون JSON دارند و کوئری روی آن را هم پشتیبانی میکنند. یعنی میشود بخش ساختاریافته را رابطهای نگه داشت و بخش متغیر را JSON — بدون افزودن یک پایگاه دادهٔ دوم.
جستجوی متنی در مقیاس. موتور جستجو کار متفاوتی میکند و جای خودش را دارد؛ تفصیلش در جستجوی محصول.
کش و شمارنده. جایش Redis است، نه پایگاه دادهٔ اصلی.
سری زمانی. دادههای حسگر و سنجه، با حجم بالا و نوشتن پیوسته.
دادهای که ذاتاً گراف است. شبکهٔ ارتباطات، تشخیص تقلب. نادر، و وقتی هست کاملاً موجه.
اشتباه رایج
انتخاب پایگاه دادهٔ سندی برای دادهٔ رابطهای، چون «سریعتر است» یا «شِما نمیخواهد».
آن «شِما نمیخواهد» درست است و همان جایی است که به دردسر میخورد. شِما از بین نمیرود؛ فقط از پایگاه داده به کد منتقل میشود. یعنی بهجای اینکه پایگاه داده جلوی رکورد ناقص را بگیرد، هر مسیری در کد باید خودش بررسی کند. یکی از آنها فراموش میشود، و شش ماه بعد دادهای دارید که با هیچ فرضی نمیخواند.
داشتن بیش از یکی
خیلی از سامانههای واقعی چند پایگاه داده دارند و این کاملاً درست است: رابطهای برای دادهٔ اصلی، Redis برای کش، موتور جستجو برای جستجو.
قاعدهای که این را سالم نگه میدارد: یکی منبع حقیقت است و بقیه نسخهٔ مشتق. موتور جستجو و کش را باید بشود هر لحظه از منبع اصلی بازسازی کرد. اگر دادهای فقط در کش هست، آن دیگر کش نیست.
قبل از تصمیم، اینها را بنویسید
شکل داده: چه موجودیتهایی و چه رابطههایی.
ده پرسشی که سامانه باید جواب دهد. نه ده کوئری فنی — ده سؤال کسبوکاری، مثل «فروش این مشتری در سه ماه گذشته به تفکیک دسته». اگر با ساختار پیشنهادی جواب دادن به اینها سخت است، ساختار اشتباه است.
جاهایی که تراکنش لازم است.
و حجم واقعی: تعداد رکورد امروز و تخمین دو سال بعد. اکثر سامانههایی که «مقیاس بالا» تصور میشوند، در محدودهای هستند که یک پایگاه دادهٔ رابطهای روی یک سرور معمولی راحت جواب میدهد.
و یک نکته دربارهٔ زمان
این تصمیم را میشود عوض کرد، ولی هرچه دیرتر گرانتر. مهاجرت پایگاه داده در سامانهای که در تولید است، یکی از پرریسکترین کارهاست.
پس بیش از حد رویش وقت نگذارید — اما ده سؤال بالا را قبل از خط اول کد جواب بدهید. آن یک ساعت، معمولاً تصمیم را واضح میکند، و اگر نکرد، پاسخ پیشفرض همان است که در ابتدای مقاله آمد.