NoSQL و MongoDB

مشکل: محصول‌هایی با شکل‌های مختلف

فروشگاه ما گوشی، پیراهن و کتاب می‌فروشد. هر دسته ویژگی‌های خودش را دارد:

1. گوشی: حافظه، اندازه صفحه، رنگ.
2. پیراهن: سایز، جنس پارچه.
3. کتاب: نویسنده، تعداد صفحه.

در یک دیتابیس رابطه‌ای (SQL) دو راه ساده داریم و هر دو مشکل دارند:

1. یک جدول با صدها ستون. بیشتر ستون‌ها برای هر محصول خالی می‌مانند و با هر دسته جدید، جدول عوض می‌شود.
2. جدول «ویژگی و مقدار». هر ویژگی یک ردیف است. ساختن یک صفحه محصول چند JOIN لازم دارد و کوئری‌ها پیچیده می‌شوند.

در یک دیتابیس سندی، هر محصول یک سند است با همان ویژگی‌هایی که لازم دارد. سند گوشی و سند پیراهن لازم نیست یک شکل داشته باشند.

خانواده‌های NoSQL

کلمه NoSQL یک نوع دیتابیس نیست. چند خانواده مختلف است که فقط در «جدول رابطه‌ای نبودن» مشترک‌اند:

در مصاحبه بیشتر از همه درباره دیتابیس سندی (مثل MongoDB) می‌پرسند. بقیه این درس درباره همان است.

مدل سند: جاسازی یا اشاره؟

در SQL، اول داده را نرمال می‌کنی و بعد هر کوئری را با JOIN می‌سازی. در MongoDB برعکس است. اول می‌پرسی برنامه چه چیزی را با هم می‌خواند، بعد سند را به همان شکل می‌سازی.

برای سفارش، دو انتخاب داریم:

1. جاسازی (Embed). ردیف‌های سفارش داخل خود سند سفارش هستند.
2. اشاره (Reference). سند جدا است و فقط شناسه‌اش نگه داشته می‌شود، مثل کلید خارجی.

کی جاسازی کنیم؟

1. وقتی همیشه با هم خوانده می‌شوند. ردیف‌های سفارش بدون سفارش معنی ندارند.
2. وقتی تعدادشان محدود است. یک سفارش چند ردیف دارد، نه یک میلیون.
3. وقتی با هم عوض می‌شوند. تغییر یک سند در MongoDB اتمی است. پس سفارش و ردیف‌هایش با هم و بدون تراکنش جدا ذخیره می‌شوند.

کی اشاره کنیم؟

1. وقتی بی‌انتها رشد می‌کند. همه سفارش‌های یک مشتری را داخل سند مشتری نگذار. هر سند در MongoDB حداکثر ۱۶ مگابایت است.
2. وقتی جدا خوانده یا جدا عوض می‌شود. مشتری صفحه پروفایل خودش را دارد.
3. وقتی داده مشترک است و بین چند سند تکرار می‌شود.

کد با MongoDB.Driver

کلاس محصول، با ویژگی‌های متغیر در یک Dictionary:

public sealed class Product
{
    public ObjectId Id { get; set; }
    public string Name { get; set; } = "";
    public string Category { get; set; } = "";
    [BsonRepresentation(BsonType.Decimal128)] public decimal Price { get; set; }
    public Dictionary<string, string> Specs { get; set; } = new();
}

ساختن اتصال، نوشتن و خواندن:

var client = new MongoClient(builder.Configuration.GetConnectionString("Mongo"));
var products = client.GetDatabase("shop").GetCollection<Product>("products");

await products.InsertOneAsync(new Product
{
    Name = "Phone X",
    Category = "phone",
    Price = 499m,
    Specs = new() { ["ram"] = "8GB", ["screen"] = "6.1 inch" }
}, cancellationToken: ct);

var cheapPhones = await products
    .Find(p => p.Category == "phone" && p.Price < 600m)
    .SortBy(p => p.Price)
    .ToListAsync(ct);

مثل SQL، اینجا هم بدون ایندکس، MongoDB همه سندها را می‌خواند. برای کوئری بالا یک ایندکس ترکیبی بساز:

await products.Indexes.CreateOneAsync(
    new CreateIndexModel<Product>(Builders<Product>.IndexKeys
        .Ascending(p => p.Category)
        .Ascending(p => p.Price)),
    cancellationToken: ct);

کلاس MongoClient امن برای چند Thread است و اتصال‌ها را خودش مدیریت می‌کند. پس آن را یک بار بساز و Singleton ثبت کن.

مقیاس: Sharding

یکی از دلیل‌های انتخاب NoSQL، پخش داده روی چند سرور است. در MongoDB به این Sharding می‌گویند. هر سند بر اساس یک کلید پخش (Shard Key) به یکی از سرورها می‌رود.

انتخاب کلید پخش خیلی مهم است:

1. کوئری‌های اصلی باید کلید پخش را داشته باشند. وگرنه MongoDB باید از همه سرورها بپرسد.
2. مقدارها باید خوب پخش شوند. اگر کلید پخش تاریخ ساخت باشد، همه سفارش‌های جدید به یک سرور می‌روند و آن سرور داغ می‌شود.
3. عوض کردنش بعداً سخت است. پس از اول با دقت انتخاب کن.

تراکنش و سازگاری

1. تغییر یک سند همیشه اتمی است. اگر سند را درست طراحی کنی، بیشتر کارها فقط یک سند را عوض می‌کنند.
2. تراکنش چندسندی هم وجود دارد، ولی گران‌تر است. اگر برای هر کار ساده به آن نیاز داری، شاید مدل سند تو غلط است، یا داده واقعاً رابطه‌ای است.
3. خواندن از کپی‌ها ممکن است کهنه باشد. اگر از Secondary بخوانی، ممکن است آخرین نوشتن را نبینی. مثل Read Replica در SQL.

انتخاب بین SQL و NoSQL

اشتباه‌های رایج