NoSQL وتصميم الداتا

#ليه NoSQL موجودة؟ والعائلات المختلفةWhy NoSQL exists and its main families

بعض workloads محتاجة reads محددة على بيانات ضخمة موزعة، أو document مرنة، أو graph traversal بدل joins عامة. NoSQL عائلات مختلفة، مش product واحد ولا وعد إن كل حاجة schema-free أو أسرع من SQL.

العائلات متداخلة. pgvector extension في PostgreSQL relational، مش دليل إن كل vector search لازم NoSQL. Cassandra wide-column مش نفس columnstore analytics. ابدأ بالمطلوب من queries والـ consistency والـ operations، مش باسم الموضة.

#Model by access patterns: order و customerModel by access patterns: orders and customers

لو الشاشة دايماً بتعرض order مع lines، تحميل document واحدة مفيد. لكن embedding كل orders جوه customer يعمل document بلا حدود ونقطة contention.

{
  "id": "order-42",
  "tenantId": "store-7",
  "customerId": "customer-9",
  "customerSnapshot": { "name": "Ali", "shippingCity": "Cairo" },
  "status": "pending",
  "lines": [
    { "productId": "product-3", "nameAtSale": "Mug", "qty": 2,
      "unitPriceMinor": 12000, "currency": "EGP" }
  ],
  "schemaVersion": 1
}

1. اكتب queries: point lookup لـ order، وقائمة customer orders حسب الوقت، وتحديث status. اختار indexes والـ partition key لكل واحدة.
2. embed lines لأنها bounded ومملوكة للـ order وبتتقري وتتعدل معاه. productId و customerId references لكيانات ليها عمر مستقل.
3. snapshot للسعر والاسم والعنوان عند البيع؛ current customer data تتجاب من ملفه لو مطلوبة.
4. لو نسخت current data في أكتر من مكان، حدد update owner وآلية sync و acceptable staleness.

الفلوس هنا minor units من غير floating-point ambiguity؛ currencies ليها scales مختلفة، فحدد السياسة. schemaVersion مع validation و readers تقبل النسخ القديمة؛ schema flexibility مش غياب schema. limits لحجم document والـ arrays والـ write contention لازم تتراجع حسب المنتج.

#Partition و shard keys والـ hot partitionsPartition keys, sharding and hot partitions

جهاز واحد ليه حدود storage و throughput. sharding يقسم data بين عقد؛ partition key بيحدد مين يستقبل read و write. اختيار غلط يخلي cluster كبير شغال كأنه جهاز واحد.

Access pattern                  Candidate key           Risk
Orders for one ordinary tenant  tenantId                One huge tenant becomes hot
Order point lookups             orderId                 Customer history fans out
Customer history                tenantId + customerId   One celebrity customer can be hot
Write-heavy event archive       tenantId + time bucket  Active bucket can still be hot
Extreme write skew              key + hash bucket       Reads must query several buckets

high cardinality مهمة، لكن مش كفاية: key ممكن ليها مليون قيمة ومعظم traffic على قيمة واحدة. قيم متزايدة في range sharding ممكن تركز writes في آخر shard. hash يوزع writes بس يضر range locality. compound أو hierarchical keys حسب دعم database ممكن توازن احتياجات مختلفة.

1. قيس أكبر partition مش المتوسط، والـ RU أو CPU والـ throttling.
2. راجع reads: query من غير partition key قد تحتاج scatter-gather لكل shards.
3. راجع transaction boundary والـ uniqueness scope والـ resharding قبل القرار.
4. لو قسمت tenant على buckets، احتفظ بطريقة routing و merge للـ results وخطة migration.

#Replication و quorum reads و writesReplication and quorum reads and writes

نسخة واحدة نقطة فشل. replication تزود availability والـ read locality، لكن تحديث النسخ وترتيب الكتابات ليهم تكلفة.

N = 3 replicas: A, B, C
W = 2: a successful write is acknowledged by A and B
R = 2: a read waits for responses from B and C
R + W = 4 > N: the read and write sets intersect at B
But: concurrent writes, version choice and failed writes still need rules.

R عدد ردود القراءة المطلوبة، W عدد acknowledgements للكتابة، N replication factor. R + W > N يضمن intersection لـ quorums على نفس replica set ثابتة. مش ضمان linearizability لوحده. لازم version ordering صح، ومعالجة concurrent و partial writes و membership changes. sloppy quorum ممكن تستخدم replicas بديلة فـ intersection المقصود مايبقاش موجود. write quorum intersection نفسها تحتاج 2W > N لو مطلوبة؛ consensus له بروتوكول أوسع من مجرد المعادلة.

W=1 يقلل انتظار الكتابة لكنه قد يخسر acknowledged data مع failure قبل النسخ. زيادة R أو W ترفع التنسيق وتقلل عدد failures اللي تقدر تتحملها للـ operation دي. ماتستخدمش إعداد منتج لإثبات ضمان مش موثق فيه.

#CAP و PACELC من غير شعاراتCAP and PACELC without slogans

لو network فصلت مجموعتين من replicas، هل الاتنين يقبلوا operations ولا واحدة تستنى؟ CAP بيحدد trade-off أثناء partition، مش قائمة تختار منها اتنين طول الوقت.

During a partition:
  C: preserve one-copy linearizable behavior, possibly reject or delay requests
  A: every request to a non-failing node completes, possibly with stale results
PACELC:
  If Partition: Availability versus Consistency
  Else:        Latency versus Consistency

C هنا linearizability، مش ACID consistency اللي معناها valid constraints. A هي formal availability لكل request لعقدة غير فاشلة، مش SLA uptime عادي. في نظام موزع network partitions احتمال لازم تتعامل معاه؛ مش اختيار نلغي P. product واحد ممكن يختار بشكل مختلف لكل operation أو configuration.

PACELC بيفكرك إن حتى وقت الشبكة السليمة، انتظار replica بعيدة يزود latency. ماتحطش label ثابت AP أو CP على كل features المنتج من غير تحديد scope وإعداداته.

#Consistency levels: مثال Cosmos DBConsistency levels through Cosmos DB

العميل عدّل عنوانه وبعدها قراه قديم؛ مجرد كلمة eventual مش بتقول تجربة المستخدم هتبقى إيه. اختار guarantee واضحة وحدد نطاقها.

ده نموذج Cosmos DB for NoSQL؛ راجع mappings للـ APIs التانية و scope ضمانات partition والـ transaction. session tokens لازم تنتقل لو نفس user بيتنقل بين app instances؛ singleton client يساعد إدارة tokens لكن مش بيغطي كل distributed flow. account default يحدد أقصى قوة request consistency المعتادة؛ ماتطلبش strong من account مضبوط على eventual وتتوقع upgrade سحري.

#BASE و ACID و transactions في NoSQLBASE, ACID and NoSQL transactions

عدم استخدام جداول مش معناه ممنوع transactions. الفرق في scope والتكلفة. BASE وصف شائع: Basically Available، و Soft state، و Eventual consistency؛ مش معيار يحدد كل behavior.

// MongoDB.Driver; reuse client. Replica set or supported sharded deployment required.
using var session = await client.StartSessionAsync(cancellationToken: ct);
await session.WithTransactionAsync(async (s, token) =>    // (1)
{
    var filter = Builders<StockDocument>.Filter.And(
        Builders<StockDocument>.Filter.Eq(p => p.Id, productId),
        Builders<StockDocument>.Filter.Gte(p => p.Available, quantity));
    var update = Builders<StockDocument>.Update.Inc(p => p.Available, -quantity);
    var result = await stock.UpdateOneAsync(s, filter, update,
        cancellationToken: token);                        // (2)
    if (result.ModifiedCount != 1)
        throw new InvalidOperationException("Insufficient stock");
    await orders.InsertOneAsync(s, order, cancellationToken: token);
    return order.Id;                                      // (3)
}, cancellationToken: ct);

ACID transaction ممكن توجد داخل database بتوفر eventual replica reads. الفلوس والـ stock غالباً تحتاج conditional writes و version checks أو transaction واضحة، مش last-write-wins. ماتنقلش توقعات relational isolation لكل NoSQL transaction من غير توثيق.

#MongoDB indexing و query plansMongoDB indexing and query plans

document model مش بتمنع collection scans. index لازم يدعم filter والـ sort الفعليين، وإلا الـ flexible schema هتخبي bottleneck بس.

using MongoDB.Driver;

var keys = Builders<OrderDocument>.IndexKeys
    .Ascending(o => o.TenantId)
    .Ascending(o => o.CustomerId)
    .Descending(o => o.CreatedAt);                        // (1)
await orders.Indexes.CreateOneAsync(
    new CreateIndexModel<OrderDocument>(keys),
    cancellationToken: ct);                              // (2)

MongoDB عندها compound و unique و multikey للـ arrays و partial و TTL indexes. multikey ليها قيود على compound arrays والـ covered queries؛ ماتعتمدش على mapping ذهني لجدول SQL. TTL expiration asynchronous، فمش ضمان مسح لحظي وقت expiry؛ query أو authorization لازم يتحققوا من صلاحية record. unique indexes على sharded collections ليها shard-key restrictions. كل index تكلف storage و writes و memory.

#Redis data structures: أكتر من cacheRedis data structures beyond caching

أحياناً المطلوب membership أو ranking أو event log، مش مجرد JSON تحت key. Redis عندها operations جاهزة تقلل read-modify-write في التطبيق.

HSET cart:{customer-9} product-3 2
SADD product:3:interested customer-9
ZINCRBY products:popular 1 product-3
XADD orders:events * orderId order-42 status paid
XGROUP CREATE orders:events fulfilment 0 MKSTREAM
XREADGROUP GROUP fulfilment worker-1 COUNT 10 STREAMS orders:events >
# After durable processing: XACK orders:events fulfilment <message-id>

دي redis-cli commands توضيحية؛ XGROUP CREATE تتعمل مرة وتتعامل مع group موجودة. Streams ممكن تعيد pending message بعد crash، فـ consumer idempotent ويعمل claim للمتروك. Pub/Sub مختلف: messages مش متخزنة للمشترك الغايب. Lua أو transactions تجمع operations atomically على السيرفر ضمن قيود cluster keys؛ Redis مش بتعمل relational rollback لكل runtime error. persistence و replication و failover configuration يحددوا durability؛ in-memory مش معناها مفيش تخزين ولا معناها durable افتراضياً.

#MongoDB و Cosmos DB من .NETUsing MongoDB and Cosmos DB from .NET

اختار driver لما محتاج native operations وتحكم واضح، أو EF provider لو abstraction وحدود الترجمة مناسبين. تغيير provider مش بيحوّل document database لـ relational.

// MongoDB.Driver; register and reuse MongoClient for its connection pools.
using MongoDB.Bson.Serialization.Attributes;
using MongoDB.Driver;

var client = new MongoClient(mongoConnectionString);
var orders = client.GetDatabase("store")
    .GetCollection<OrderDocument>("orders");
var filter = Builders<OrderDocument>.Filter.And(
    Builders<OrderDocument>.Filter.Eq(o => o.TenantId, tenantId),
    Builders<OrderDocument>.Filter.Eq(o => o.Id, orderId)); // (1)
var order = await orders.Find(filter).FirstOrDefaultAsync(ct);

public sealed class OrderDocument
{
    [BsonId] public string Id { get; set; } = "";
    public string TenantId { get; set; } = "";
    public string CustomerId { get; set; } = "";
    public DateTime CreatedAt { get; set; }
}

// Microsoft.Azure.Cosmos; reuse CosmosClient. Existing /tenantId container assumed.
using Microsoft.Azure.Cosmos;

var cosmos = new CosmosClient(cosmosConnectionString);
var container = cosmos.GetContainer("store", "orders");
try
{
    var response = await container.ReadItemAsync<CosmosOrder>(
        id: orderId, partitionKey: new PartitionKey(tenantId),
        cancellationToken: ct);                          // (2)
    Console.WriteLine(response.RequestCharge);
}
catch (CosmosException ex) when (ex.StatusCode == System.Net.HttpStatusCode.NotFound)
{
    Console.WriteLine("Order not found in the authorized partition");
}
public sealed record CosmosOrder(string id, string tenantId, string status);

استخدم secret store أو managed identity حيث متاحة بدل credentials في source. المقتطفات بتفترض provisioned databases و collections و .NET 10 مع package versions متوافقة. ماتعملش client جديد لكل request.

#Polyglot persistence و SQL vs NoSQL decisionPolyglot persistence and SQL versus NoSQL decisions

أداة مختلفة لكل query ممكن تحسن الأداء، لكنها تزود backups والـ monitoring والـ skills والـ consistency work. polyglot persistence قرار cost مش هدف لوحده.

-- PostgreSQL: stable relational facts plus variable product attributes.
CREATE TABLE products (
    id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    name text NOT NULL,
    price numeric(18,2) NOT NULL CHECK (price >= 0),
    attributes jsonb NOT NULL DEFAULT '{}'::jsonb         -- (1)
);
CREATE INDEX ix_products_attributes ON products USING gin (attributes);
SELECT id, name FROM products
WHERE attributes @> '{"color":"blue"}'::jsonb;           -- (2)

JSONB مش automatic sharding، والتحديثات الكبيرة والـ indexing ليهم تكلفة. لو عندك SQL مصدر الحقيقة و search نسخة مشتقة، استخدم outbox أو CDC و idempotent consumers و reconciliation؛ ماتعملش dual write ساذجة. اعرف تعيد بناء index وتتعامل مع deleted records و schema versions. query result لازم يلتزم authorization حتى لو search index قديم.