Một dòng code. Cả một thế giới ẩn bên dưới.

Bạn viết dòng này. Trông nó thật vô hại:

db.Insert("Users", row);

Nhưng bên dưới lớp vỏ ấy, mọi thứ không hề nhàm chán. Hãy tưởng tượng một engine cơ sở dữ liệu giống như một phòng cấp cứu bệnh viện bận rộn. Hàng dữ liệu của bạn là một bệnh nhân mới. Nó phải qua khâu phân loại, được ghi vào sổ tiếp nhận chính thức trước khi bất kỳ ai chạm vào bất cứ thứ gì vĩnh viễn, và chỉ sau đó mới được xếp vào danh sách khoa nội. Nếu điện bị chớp tắt giữa chừng, sổ tiếp nhận sẽ cho chúng ta biết chính xác ai đã được làm thủ tục nhập viện chính thức.

Cái nhìn tổng quan về 5 lớp

Cơ sở dữ liệu không phải là một khối duy nhất. Đó là một chồng các lớp chuyên biệt, mỗi lớp giải quyết một vấn đề cụ thể. Hãy cùng làm quen với các nhân vật:

Làm quen với API công khai

Đây là toàn bộ cuộc hội thoại mà bạn thực hiện với cơ sở dữ liệu từ mã ứng dụng của mình. Mọi thứ khác trong khóa học này chính là những gì xảy ra đằng sau những dòng code này.

using var db = new Database("mydata.mde", cacheSize: 100, useMemoryMappedFile: false);

var columns = new List<ColumnDefinition>
{
    new ColumnDefinition("Id", DataType.Int, false),
    new ColumnDefinition("Name", DataType.String),
    new ColumnDefinition("Age", DataType.Int)
};

var table = db.CreateTable("Users", columns, primaryKeyColumn: "Id");

var row = new DataRow(table.Schema);
row["Id"] = 1;
row["Name"] = "Alice";
row["Age"] = 30;

db.Insert("Users", row);

Lưu ý rằng ở cấp độ này thực sự chỉ có bốn động từ bạn cần biết: mở cơ sở dữ liệu, định nghĩa cột, tạo hàng, chèn nó. Mọi thứ khác mà khóa học này dạy là những gì cơ sở dữ liệu thực hiện cho bạn đằng sau bốn động từ đó.

Hành trình của một hàng dữ liệu

Nhấn Bước tiếp theo để xem hàng dữ liệu của bạn đi qua các lớp. Mỗi điểm dừng có đúng một nhiệm vụ duy nhất.

Bạn thích đọc theo tốc độ của mình? Đây là bảy bước tương tự dưới dạng thẻ:

Cận cảnh: code Table.Insert thực tế

Đây là phương thức C# thực tế điều phối các bước từ 3 đến 6. Có khoảng 20 dòng C# từ tệp MiniDatabaseEngine/Table.cs. Đừng lo lắng — chúng ta sẽ dịch từng dòng.

public void Insert(DataRow row, Transaction.Transaction? transaction = null)
{
    _lock.EnterWriteLock();
    try
    {
        var key = GetPrimaryKey(row);
        ValidateRowForWrite(row);

        var keyExists = _index.Search(key) != null;
        var keyPendingInTransaction = transaction?.HasBufferedValueForKey(_schema.TableName, key, GetPrimaryKeyDataType()) ?? false;
        if (keyExists || keyPendingInTransaction)
            throw new InvalidOperationException($"Duplicate primary key value '{key}'.");

var serialized = SerializeRow(row);

        if (transaction != null)
        {
            transaction.LogInsert(_schema.TableName, key, serialized);
            _nextRowId++;
            return;
        }

        _index.Insert(key, serialized);
        _nextRowId++;
    }
    finally
    {
        _lock.ExitWriteLock();
    }
}

Lưu ý cách mà phương thức đơn lẻ này điều phối bao nhiêu lớp: trình quản lý khóa, trình xác thực schema, chỉ mục, bộ tuần tự hóa, bộ đệm giao dịch. Sự phối hợp đó chính là lý do khóa học này tồn tại.

Kiểm tra trực giác của bạn

Không cần học thuộc lòng. Mỗi câu hỏi là một tình huống thực tế bạn có thể gặp khi gỡ lỗi hoặc trò chuyện với AI về cơ sở dữ liệu. Hãy suy nghĩ kỹ, rồi chọn.

Tiếp theo: Module 2 — Trang & Vùng mở rộng, sơ đồ mặt bằng lưu trữ. Chúng ta sẽ phóng to xuống tận đáy của chồng lớp và xem cách cơ sở dữ liệu sắp xếp các byte trên đĩa một cách vật lý. Một khi bạn hiểu sơ đồ mặt bằng, phần còn lại của tòa nhà sẽ trở nên hợp lý.

Ổ đĩa không quan tâm đến các hàng

Hãy tưởng tượng một kho chứa đồ tự quản khổng lồ. Mọi đơn vị kho đều có kích thước chính xác như nhau. Đó là cách một ổ đĩa nhìn thấy cơ sở dữ liệu của bạn — không phải dưới dạng các bảng và hàng, mà là một dãy dài các đơn vị lưu trữ giống hệt nhau gọi là trang.

Toàn bộ nhiệm vụ của engine lưu trữ là phiên dịch: lấy các hàng có kích thước thay đổi, lộn xộn của bạn và nhét chúng vào các đơn vị cố định, cứng nhắc này để ổ đĩa có thể di chuyển chúng một cách hiệu quả.

Giải phẫu một trang

Một trang có cấu tạo cực kỳ đơn giản: một ID, một mảng byte thô kích thước cố định, và một lá cờ. Chỉ có vậy thôi. ID là thứ làm cho phép toán hoạt động — nó cho engine biết chính xác đơn vị này nằm ở đâu trên đĩa.

public class Page
{
#if DATA_PAGE_SIZE
    public const int PageSize = #DATA_PAGE_SIZE#; 
#else
    public const int PageSize = 4096; // Trang 4KB
#endif
    public int PageId { get; set; }
    public byte[] Data { get; set; }
    public bool IsDirty { get; set; }
    
    public Page(int pageId)
    {
        PageId = pageId;
        Data = new byte[PageSize];
        IsDirty = false;
    }

Vì mọi trang đều có cùng kích thước, việc tìm trang số N trên đĩa chỉ là một phép nhân duy nhất — không cần tìm kiếm, không cần tra cứu chỉ mục, chỉ là số học thuần túy.

Vùng mở rộng (Extents) — gom đơn cho xe tải

Việc điều động xe tải vận chuyển của kho hàng rất tốn kém. Chạy 8 chuyến riêng biệt cho 8 đơn vị kho liền kề là lãng phí — vì vậy chúng ta gửi xe đi một lần và bốc cả khối cùng lúc. Khối đó gọi là một vùng mở rộng (extent).

8 trang nằm cạnh nhau. Một chuyến xe. Đó là toàn bộ ý tưởng.

public class Extent
{
    public const int PagesPerExtent = 8;
    
    public int ExtentId { get; set; }
    public Page[] Pages { get; set; }
    public bool IsDirty => Pages.Any(p => p.IsDirty);
    
    public Extent(int extentId)
    {
        ExtentId = extentId;
        Pages = new Page[PagesPerExtent];
        
        for (int i = 0; i < PagesPerExtent; i++)
        {
            int pageId = extentId * PagesPerExtent + i;
            Pages[i] = new Page(pageId);
        }
    }

Thử sức: thuộc vùng mở rộng nào?

Hãy nhớ công thức: extentId = pageId ÷ 8. Kéo mỗi trang vào vùng mở rộng mà nó thuộc về. Mấu chốt nằm ở phép toán này.

Bảng kẹp tại quầy lễ tân — Bộ nhớ đệm LRU

Việc đi bộ đến kho hàng cho mọi lần tra cứu là rất mệt mỏi. Vì vậy, quầy lễ tân giữ một bảng kẹp ghi lại những đơn vị kho được mở gần đây nhất — đó chính là bộ nhớ đệm (cache). Khi hết chỗ, nó sẽ loại bỏ kẻ nào lâu nhất không có ai động vào. Quy tắc đó có tên là: LRU.

public void Put(int pageId, Page page)
{
    lock (_lockObject)
    {
        if (_cache.TryGetValue(pageId, out var node))
        {
            node.Page = page;
            MoveToHead(node);
            return;
        }

        var newNode = new CacheNode(page);
        _cache[pageId] = newNode;
        AddToHead(newNode);

        if (_cache.Count > _capacity)
        {
            var removed = RemoveTail();
            if (removed != null)
                _cache.TryRemove(removed.Page.PageId, out _);
        }
    }
}

Vị trí "đầu" và "cuối" của bảng kẹp được theo dõi bởi một danh sách liên kết đôi, đó là lý do tại sao việc đưa một thứ lên đầu gần như là miễn phí. Một biến thể xịn hơn — tệp ánh xạ bộ nhớ (memory-mapped file) — cho phép Hệ điều hành tự xử lý việc lưu đệm, nhưng đó là chủ đề cho một ngày khác.

Vận dụng vào thực tế

Ba câu hỏi để mở rộng các ý tưởng. Không có câu hỏi mẹo — chỉ là những tình huống bạn có thể gặp trong thực tế khi làm việc với AI hỗ trợ lập trình.

Tiếp theo: module 3, Cây B+. Giờ đây các byte đã có nơi để ở, làm sao chúng ta tìm thấy một hàng cụ thể giữa hàng triệu hàng?

Danh bạ điện thoại với các tab chỉ mục

Việc quét 10 triệu hàng để tìm người dùng #47.392.185 sẽ mất rất nhiều thời gian. Một cây B+ biến cuộc tìm kiếm đó thành khoảng 23 lần so sánh — giống như việc tìm kiếm nhị phân trong một cuốn danh bạ điện thoại giấy, lật từng phần một.

Hãy hình dung một cuốn danh bạ điện thoại với các tab chỉ mục dày được dán vào mép các trang. Các tab này không chứa số điện thoại — chúng chỉ nói "lật vào đây để tìm vần S" hoặc "lật vào đây để tìm vần T". Các số điện thoại thực sự nằm trên các trang được sắp xếp theo bảng chữ cái ở cuối, và những trang đó được đóng ghim theo thứ tự — một khi bạn đã đến được mục "Smith", bạn chỉ cần đọc tiếp tới "Thompson, Turner, Vance".

Đó chính là một cây B+. Các tab là các nút nội bộ. Các trang là các nút lá. Và các ghim đóng chính là thứ làm cho các truy vấn dải (range queries) trở nên nhanh chóng.

Hai loại nút, hai nhiệm vụ khác nhau

Mọi nút đều giữ các khóa (keys). Nhưng nút lá cũng giữ các giá trị (values) thực tế và có các con trỏ Next/Previous tới các nút anh em của chúng. Nút nội bộ chỉ giữ các khóa và con trỏ tới các nút con — chúng thuần túy là biển chỉ dẫn.

public abstract class BPlusTreeNode
{
    public bool IsLeaf { get; protected set; }
    public BPlusTreeNode? Parent { get; set; }
    public List<object> Keys { get; protected set; }
    
    protected BPlusTreeNode(bool isLeaf)
    {
        IsLeaf = isLeaf;
        Keys = new List<object>();
    }
    
    public abstract int KeyCount { get; }
}

public class BPlusTreeInternalNode : BPlusTreeNode
{
    public List<BPlusTreeNode> Children { get; private set; }
    
    public BPlusTreeInternalNode() : base(false)
    {
        Children = new List<BPlusTreeNode>();
    }
    
    public override int KeyCount => Keys.Count;
}

public class BPlusTreeLeafNode : BPlusTreeNode
{
    public List<object?> Values { get; private set; }
    public BPlusTreeLeafNode? Next { get; set; }
    public BPlusTreeLeafNode? Previous { get; set; }
    
    public BPlusTreeLeafNode() : base(    {
        Values = new List<object?>();
    }
    
    public override int KeyCount => Keys.Count;
}

Hai thao tác chứng minh giá trị của toàn bộ thiết kế

Một cây B+ chứng tỏ giá trị của mình qua hai chiêu thức: nhảy thẳng tới một khóa cụ thể (Search) hoặc thu thập mọi khóa trong một khoảng (Range). Cùng một cái cây, nhưng cơ chế rất khác nhau.

Search: leo xuống các tab chỉ mục để đến đúng trang

public object? Search(object key)
{
    lock (_lockObject)
    {
        var leaf = FindLeafNode(key);
        int index = FindKeyIndex(leaf.Keys, key);
        
        if (index < leaf.Keys.Count && _comparer.Compare(leaf.Keys[index], key) == 0)
        {
            return ((BPlusTreeLeafNode)leaf).Values[index];
        }
        
        return null;
    }
}

Range: tìm điểm bắt đầu, rồi đi ngang

public IEnumerable<KeyValuePair<object, object?>> Range(object? minKey, object? maxKey)
{
    lock (_lockObject)
    {
        var results = new List<KeyValuePair<object, object?>>();
        var leaf = minKey != null ? FindLeafNode(minKey) : GetFirstLeaf();
        
        while (leaf != null)
        {
            for (int i = 0; i < leaf.Keys.Count; i++)
            {
                var key = leaf.Keys[i];
                
                if (minKey != null && _comparer.Compare(key, minKey) < 0)
                    continue;
                    
                if (maxKey != null && _comparer.Compare(key, maxKey) > 0)
                    return results;
                    
                results.Add(new KeyValuePair<object, object?>(key, leaf.Values[i]));
            }
            
            leaf = leaf.Next;
        }
        
        return results;
    }
}

Ba thao tác, nhìn thoáng qua

Mọi truy vấn mà cơ sở dữ liệu từng chạy đối với một chỉ mục đều gói gọn trong một trong ba bước đi này.

Xây dựng cây: chèn các giá trị 10, 20, 30, 40

Hãy xem một cái cây mọc lên từ con số không, với bậc (order) = 3 (nghĩa là một lá có thể giữ tối đa 2 khóa trước khi phải tách). Bốn lượt chèn, bốn bức ảnh chụp nhanh.

Đây là code chèn dữ liệu điều phối toàn bộ quá trình đó. Nó ngắn gọn một cách đáng ngạc nhiên — phần đệ quy nằm bên trong SplitLeafNode, có thể khiến các lượt tách sủi bọt lên tận gốc.

public void Insert(object key, object? value)
{
    lock (_lockObject)
    {
        var leaf = FindLeafNode(key);
        InsertIntoLeaf(leaf, key, value);
        
        if (leaf.KeyCount > _order - 1)
        {
            SplitLeafNode(leaf);
        }
    }
}

Kiểm tra nhanh — áp dụng những gì bạn đã thấy

Bốn tình huống ngắn gọn. Không chấm điểm — mục tiêu là để mở rộng các ý tưởng chứ không phải học thuộc lòng chúng.

Sắp tới: bây giờ bạn đã biết cái cây tồn tại, Module 4 sẽ cho thấy trình lập kế hoạch truy vấn LINQ quyết định khi nào nên sử dụng nó — và khi nào thì việc đọc từng hàng sẽ rẻ hơn.

Trình lập lộ trình GPS bên trong cơ sở dữ liệu của bạn

Hỏi điện thoại chỉ đường đến sân bay. Nó không thử đi qua mọi con phố — nó liếc qua yêu cầu của bạn, nhận thấy "chỉ đi đường cao tốc" và chọn một lộ trình hiệu quả. Cơ sở dữ liệu của bạn cũng làm điều tương tự với một truy vấn (query).

Bạn viết LINQ kiểu như .Where(r => r["Id"] == 42). Trước khi một hàng dữ liệu đơn lẻ bị chạm tới, một trình lập kế hoạch sẽ kiểm tra yêu cầu của bạn và chọn một chiến lược. Chiến lược đó chính là kế hoạch truy vấn, và nó quyết định liệu truy vấn của bạn chạy trong vài mili giây hay vài phút.

Ba giai đoạn của hàm Execute

Khi bạn gọi .ToList() trên một truy vấn LINQ, engine sẽ chạy phương thức Execute. Hãy coi đó là trình GPS đang chạy qua ba bước: chọn cửa vào, lọc những gì đi qua, và sắp xếp những gì còn lại.

public TResult Execute<TResult>(Expression expression)
{
    var plan = BuildExecutionPlan(expression);
    IEnumerable<DataRow> rows = ExecuteAccessPath(plan);

    foreach (var predicate in plan.Predicates)
    {
        rows = rows.Where(predicate);
    }

    if (plan.OrderByColumn != null)
    {
        if (plan.IsOrderByDescending)
            rows = rows.OrderByDescending(r => r[plan.OrderByColumn]);
        else
            rows = rows.OrderBy(r => r[plan.OrderByColumn]);
    }

    return (TResult)(}

Lưu ý trình tự: đường truy cập trước, bộ lọc thứ hai, sắp xếp sau cùng. Việc sắp xếp luôn diễn ra trong bộ nhớ đối với bất kỳ hàng nào còn sống sót sau bộ lọc. Đó là lý do tại sao ORDER BY không bao giờ làm tăng tốc truy vấn — nó chỉ có thể làm chậm đi thôi.

Chọn cửa vào: ExecuteAccessPath

Đây là trái tim của trình lập kế hoạch. Một nấc thang kiểm tra vị ngữ (predicate) ngắn gọn sẽ quyết định xem truy vấn của bạn nhảy, đi bộ hay quét.

private IEnumerable<DataRow> ExecuteAccessPath(QueryExecutionPlan plan)
{
    if (!string.IsNullOrEmpty(_primaryKeyColumn) && plan.IndexRange != null)
    {
        if (plan.IndexRange.ExactKey != null)
        {
            var single = _table.SelectByKey(plan.IndexRange.ExactKey);
            return single != null ? new List<DataRow> { single } : new List<DataRow>();
        }

        if (plan.IndexRange.HasLowerBound || plan.IndexRange.HasUpperBound)
        {
            return _table.SelectByPrimaryKeyRange(plan.IndexRange.LowerBound, plan.IndexRange.UpperBound);
        }
    }

    return _table.SelectAll();
}

Đọc từ trên xuống dưới: khóa chính xác? nhảy một lần. khoảng dải? đi bộ qua lá. không cái nào cả? quét toàn bộ. Đó là toàn bộ trình lập kế hoạch — ba dòng quyết định thực sự ngồi trên đỉnh của một cây B+.

Nơi kế hoạch gặp cái cây

Khi kế hoạch chọn "khóa chính xác", quyền điều khiển chuyển sang SelectByKey — điểm mà lớp LINQ cuối cùng cũng gọi vào cây B+ mà bạn đã xây dựng ở Module 3.

public DataRow? SelectByKey(object key)
{
    _lock.EnterReadLock();
    try
    {
        var serialized = _index.Search(key);
        if (serialized == null)
            return null;
        
        return DeserializeRow((byte[])serialized);
    }
    finally
    {
        _lock.ExitReadLock();
    }
}

Ba góc nhìn của cùng một truy vấn

Hãy xem cách những gì bạn viết trở thành một đối tượng kế hoạch rồi trở thành một lệnh gọi phương thức trên Bảng. Nhấp vào từng tab:

// Những gì bạn, lập trình viên, đã viết:
var user = db.Query("Users")
    .Where(r => (int)r["Id"] == 42)
    .ToList();

// Những gì BuildExecutionPlan đã tạo ra:
QueryExecutionPlan {
    Predicates: [],                    // trống — không có bộ lọc dư thừa nào
    IndexRange: {
        ExactKey: 42,                 // chỉ mục có thể làm điều này chính xác
        HasLowerBound: false,
        HasUpperBound: false
    },
    OrderByColumn: null,
    IsOrderByDescending: false
}

// Những gì thực sự chạy trên Bảng:
_table.SelectByKey(42);
  ↳ _index.Search(42);         // Leo cây B+: O(log n)
  ↳ DeserializeRow(bytes);     // bytes → DataRow
  ↳ return single row.

// Không có vòng lặp vị ngữ. Không sắp xếp. Xong.

Hành trình ba bước này — ý định → kế hoạch → thao tác — chính là lý do SQL và LINQ mang lại cảm giác kỳ diệu. Visitor pattern biến lambda của bạn thành một cấu trúc dữ liệu, và cấu trúc dữ liệu đó chọn ra thao tác vật lý.

Tìm lỗi: truy vấn này sẽ không dùng chỉ mục

Đây là một truy vấn trông có vẻ như lẽ ra phải là O(log n). Nhưng lập trình viên đã mắc một sai lầm nhỏ, và bây giờ nó quét toàn bộ 10 triệu hàng mỗi lần chạy. Bạn có thấy nó không?

Trình lập kế hoạch chỉ nhận diện được các mẫu có dạng r["Id"] == hằng_số. Khoảnh khắc bạn bọc cột dữ liệu trong một lời gọi hàm — .ToString(), Math.Abs(), Substring() — mẫu khớp của visitor sẽ thất bại và truy vấn quay lại phương án quét toàn bộ. Đây cũng chính là sai lầm giống như khi viết WHERE TO_CHAR(id) = '42' trong SQL. Hãy để cột dữ liệu "trần trụi" ở một bên của phép so sánh.

Kiểm tra bản năng lập kế hoạch lộ trình của bạn

Bốn tình huống. Không cần học thuộc lòng — chỉ cần áp dụng những gì bạn đã thấy.

Tiếp theo: các lượt đọc thì dễ — chúng chỉ cần nhanh là được. Các lượt ghi thì khó hơn. Chúng phải sống sót qua sự cố sập nguồn, mất điện và các giao dịch đang dở dang. Module 5 sẽ vén màn bí mật về tính bền vững.

Quầy làm thủ tục tại sân bay

Bạn đưa cho nhân viên hai tấm vé và một chiếc vali. Trước khi bất cứ thứ gì được đóng dấu lên thẻ lên máy bay, nhân viên đó ghi mọi mục vào một cuốn sổ nhật ký chính thức dày cộp, theo thứ tự: "nhóm hai người, vali đã dán nhãn, chỗ ngồi đã được phân." Sau đó họ mới in thẻ lên máy bay. Nếu điện bị cắt giữa khâu làm thủ tục, nhân viên tiếp theo vào buổi sáng sẽ đọc sổ nhật ký và chỉ hoàn tất những lượt làm thủ tục được đánh dấu "đã xong". Bất cứ thứ gì không có dấu đã xong sẽ bị loại bỏ.

Đó là cách các hãng hàng không tránh làm mất hành lý của bạn — và đó chính xác là cách cơ sở dữ liệu tránh làm mất tiền của bạn. Trong module này chúng ta sẽ làm quen với cuốn sổ nhật ký: WAL, và các quy tắc làm cho một giao dịch (transaction) hoặc là xảy ra đầy đủ, hoặc là biến mất hoàn toàn.

Hãy tưởng tượng một lệnh chuyển khoản ngân hàng. Bạn trừ tiền ở tài khoản A, rồi cộng tiền vào tài khoản B. Điều gì xảy ra nếu điện vụt tắt giữa hai bước đó? Nếu không có cam kết giao dịch, tài khoản A nghèo đi và tài khoản B không giàu thêm. Tiền đơn giản là bốc hơi. Những quy tắc dưới đây tồn tại để điều đó không bao giờ xảy ra.

Bốn chữ cái này ghép lại thành ACID — tiêu chuẩn mà mọi cơ sở dữ liệu nghiêm túc đều phải vượt qua.

Ghi nhật ký trước, áp dụng sau

Đây là quy tắc vàng cung cấp sức mạnh cho mọi thứ trong module này. Khi một giao dịch muốn thay đổi dữ liệu, cơ sở dữ liệu không chạm vào dữ liệu thật trước. Nó ghi thay đổi dự định đó vào WAL trên đĩa, ép nhật ký đó phải nằm vững trên đĩa, và chỉ sau đó mới áp dụng thay đổi. Ghi nhật ký trước, áp dụng sau.

Nếu đảo ngược trình tự đó, bạn sẽ nhận lấy sự hư hỏng dữ liệu. Áp dụng trước và hy vọng sẽ ghi nhật ký sau? Nếu sự cố sập nguồn rơi vào giữa hai bước đó, thay đổi đã nằm trên đĩa nhưng nhật ký không biết, vì vậy quá trình khôi phục sẽ không bao giờ phát lại hoặc hoàn tác nó. Toàn bộ hệ thống được xây dựng để tránh khoảng hở đó.

Hãy xem một giao dịch thực tế len lỏi qua engine. Bốn nhân vật: Người dùng (khách hàng), Giao dịch (người giữ sổ sách), WAL (sổ nhật ký trên đĩa), và Cây B+ (nơi các hàng dữ liệu thực sự trú ngụ).

Bên trong một mục nhật ký

Mọi dòng trong sổ nhật ký là một WALEntry. Một mục cho mỗi thao tác: "giao dịch 42 đã chèn Alice," "giao dịch 42 đã commit," và cứ thế. Các trường thông tin được chọn sao cho khâu khôi phục có mọi thứ nó cần — giá trị cũ để hoàn tác (undo), giá trị mới để làm lại (redo), và một số thứ tự để chúng ta biết chính xác trình tự các sự kiện đã xảy ra.

public class WALEntry
{
    private const int MaxCheckpointActiveTransactionCount = 100_000;
    private const int MaxStringByteLength = 64 * 1024;
    private const int MaxValueLength = 1024 * 1024;

    public long TransactionId { get; set; }
    public WALOperationType OperationType { get; set; }
    public string TableName { get; set; } = string.Empty;
    public object? Key { get; set; }
    public byte[]? OldValue { get; set; }
    public byte[]? NewValue { get; set; }
    public long Timestamp { get; set; }
    public long SequenceNumber { get; set; }
    public List<long> CheckpointActiveTransactionIds { get; set; } = new();
    public long CheckpointNextTransactionId { get; set; }
}

Khoảnh khắc xác nhận (commit)

Một lệnh xác nhận (commit) không phải là một cái công tắc. Đó là một vũ điệu ba bước: ghi dấu commit, flush nhật ký WAL xuống đĩa, rồi mới áp dụng. Ranh giới giữa "có thể mất cái này" và "chắc chắn an toàn" nằm ở một lời gọi hàm duy nhất: Flush().

public void Commit()
{
    _lock.EnterWriteLock();
    try
    {
        if (_state != TransactionState.Active)
            throw new InvalidOperationException($"Không thể xác nhận giao dịch ở trạng thái: {_state}");

        // Ghi nhật ký commit
        _walManager.AppendEntry(new WALEntry
        {
            TransactionId = _transactionId,
            OperationType = WALOperationType.Commit
        });

        // Ép flush để đảm bảo tính bền vững
        _walManager.Flush();

        // Chỉ áp dụng các lượt ghi trong bộ đệm sau khi WAL commit đã bền vững trên đĩa.
        _commitApplyCallback(_entries);

        _state = TransactionState.Committed;
        _transactionManager.CompleteTransaction(_transactionId);
    }
    finally
    {
        _lock.ExitWriteLock();
    }
}

Hãy nhắc lại một lần nữa: ghi nhật ký trước, áp dụng sau.

Sáng hôm sau vụ sập nguồn

Sập nguồn xảy ra. Những giao dịch mới viết được một nửa, có thể một dấu commit đã kịp ghi xuống đĩa, có thể một cái thì không. Lần tới khi engine khởi động, nó chạy hàm RecoverFromWAL: đọc toàn bộ sổ nhật ký, gom các mục theo giao dịch, chỉ phát lại những nhóm có dấu Commit, vứt bỏ phần còn lại.

Dưới đây là code khôi phục, đã được lược bớt phần xử lý lỗi. Hãy chú ý quy tắc này đơn giản như thế nào: nếu có mục Commit thì phát lại; nếu không thì bỏ qua.

public void RecoverFromWAL(Action<WALEntry> applyEntry)
{
    _lock.EnterWriteLock();
    try
    {
        var entries = _walManager.ReadEntriesForRecovery();
        var transactions = new Dictionary<long, List<WALEntry>>();
        var committedTransactions = new HashSet<long>();

        foreach (var entry in entries)
        {
            if (entry.OperationType == WALOperationType.Checkpoint) continue;

            if (entry.OperationType == WALOperationType.Commit)
                committedTransactions.Add(entry.TransactionId);
            else if (entry.OperationType == WALOperationType.Rollback)
                continue;
            else if (entry.OperationType != WALOperationType.BeginTransaction)
            {
                if (!transactions.ContainsKey(entry.TransactionId))
                    transactions[entry.TransactionId] = new List<WALEntry>();
                transactions[entry.TransactionId].Add(entry);
            }
        }

        foreach (var txnId in committedTransactions)
        {
            if (transactions.TryGetValue(txnId, out var txnEntries))
            {
                foreach (var entry in txnEntries)
                    applyEntry(entry);
            }
        }
    }
    finally { _lock.ExitWriteLock(); }
}

Câu thần chú lần nữa: ghi nhật ký trước, áp dụng sau. Khâu khôi phục chỉ tin vào những gì đã được ghi nhật ký.

Giữ cho sổ nhật ký luôn gọn gàng

Nếu WAL cứ mọc dài mãi mãi, khâu khôi phục cũng sẽ mất mãi mãi. Vì vậy, engine định kỳ thực hiện một điểm kiểm tra (checkpoint): flush mọi trang dirty trong bộ nhớ xuống đĩa, ghi một mục WAL Checkpoint đặc biệt, và cắt bỏ phần cũ nhất của nhật ký. Sổ nhật ký sẽ bắt đầu lại từ một khoảnh khắc an toàn đã biết.

Các điểm kiểm tra, các lượt ghi trì hoãn và vũ điệu commit đều dựa trên cùng một nền tảng: ghi nhật ký trước, áp dụng sau.

Hãy suy nghĩ thấu đáo

Bốn tình huống. Hãy chọn đáp án mà một kỹ sư cơ sở dữ liệu kỳ cựu sẽ đưa ra. Các phần giải thích chính là nơi bạn thực sự học được — hãy đọc chúng ngay cả khi bạn chọn đúng.

Module tiếp theo: Tính đồng thời (Concurrency). Nhiều giao dịch cùng lúc — làm sao engine giữ cho chúng không dẫm chân lên nhau?

Cửa xoay tàu điện ngầm

Hãy tưởng tượng một cánh cửa xoay tại ga tàu điện ngầm. Nhiều người có thể cùng đi qua một lúc, miễn là tất cả họ đều đi cùng hướng. Nhưng nếu một người dừng lại ở giữa để buộc dây giày, mọi người khác phải đợi cho đến khi họ xong việc.

Đó chính xác là cách cơ sở dữ liệu xử lý tính đồng thời (concurrency). Nhiều luồng đọc có thể cùng đi qua. Một luồng ghi duy nhất sẽ chiếm trọn cánh cửa. Bí quyết là đảm bảo không ai đâm sầm vào ai.

Cánh cửa có ba trạng thái

Một khóa reader-writer theo dõi xem cánh cửa hiện đang ở trạng thái nào.

Người đọc và người ghi không bao giờ có thể cùng tồn tại. Chỉ trạng thái IDLE mới kết nối họ.

Năm cánh cửa, xếp chồng lên nhau

Một cơ sở dữ liệu thực thụ không chỉ có một cánh cửa. Nó có tận năm cái, lồng vào nhau như búp bê Nga. Mỗi cánh cửa bảo vệ một phần khác nhau của hệ thống, từ toàn bộ cơ sở dữ liệu xuống đến tận một trang cache nhỏ xíu.

Khi một thao tác cần đi qua nhiều hơn một cánh cửa, nó phải luôn lấy chúng theo cùng một trình tự. Quy tắc duy nhất đó ngăn chặn cả một lớp các lỗi gọi là tắc nghẽn (deadlock).

Quy tắc thì dễ nói nhưng cực kỳ quan trọng để tuân theo: luôn chiếm các khóa theo thứ tự từ cấp độ 1 xuống cấp độ 5. Đừng bao giờ làm ngược lại. Bản hợp đồng đó được ghi trực tiếp vào mã nguồn dưới dạng chú thích.

/// <summary>
/// An toàn Luồng (Thread Safety):
/// Lớp này sử dụng ReaderWriterLockSlim để đảm bảo các thao tác an toàn luồng.
/// Nhiều luồng có thể đọc đồng thời, nhưng các thao tác ghi là độc quyền.
/// 
/// Thứ tự Khóa (để ngăn chặn deadlock khi khóa lồng nhau):
/// Khi cần chiếm nhiều khóa, luôn chiếm chúng theo thứ tự sau:
/// 1. Database._lock (thao tác cấp độ schema)
/// 2. Table._lock (thao tác cấp độ bảng)
/// 3. BPlusTree._lockObject (thao tác cấp độ chỉ mục)
/// 4. StorageEngine._lock (lớp này - thao tác lưu trữ)
/// 5. Khóa PageCache/ExtentCache (thao tác bộ nhớ đệm)
/// </summary>
public class StorageEngine : IDisposable
{
    private readonly ReaderWriterLockSlim _lock;

Đọc và Ghi: Một từ thay đổi tất cả

Trong mã code, sự khác biệt duy nhất giữa một thao tác đọc và một thao tác ghi chỉ là một từ. Nhưng từ đó thay đổi hoàn toàn cách cánh cửa hành xử.

Hãy chú ý cách cả hai ví dụ đều bọc công việc của chúng trong khối try/finally. Khóa phải được giải phóng ngay cả khi công việc bị nổ tung giữa chừng. Quên mất dòng lệnh đó chính là cách một cơ sở dữ liệu bị đóng băng vĩnh viễn.

public void Insert(DataRow row, Transaction.Transaction? transaction = null)
{
    _lock.EnterWriteLock();
    try
    {
        var key = GetPrimaryKey(row);
        ValidateRowForWrite(row);

        var keyExists = _index.Search(key) != null;
        var keyPendingInTransaction = transaction?.HasBufferedValueForKey(_schema.TableName, key, GetPrimaryKeyDataType()) ?? false;
        if (keyExists || keyPendingInTransaction)
            throw new InvalidOperationException($"Duplicate primary key value '{key}'.");

        var serialized = SerializeRow(row);

        if (transaction != null)
        {
            transaction.LogInsert(_schema.TableName, key, serialized);
            _nextRowId++;
            return;
        }

        _index.Insert(key, serialized);
        _nextRowId++;
    }
    finally
    {
        _lock.ExitWriteLock();
    }
}

public DataRow? SelectByKey(object key)
{
    _lock.EnterReadLock();
    try
    {
        var serialized = _index.Search(key);
        if (serialized == null)
            return null;
        
        return DeserializeRow((    }
    finally
    {
        _lock.ExitReadLock();
    }
}

EnterWriteLock nghĩa là "Tôi cần cánh cửa này cho riêng mình." EnterReadLock nghĩa là "Tôi sẽ chia sẻ." Chọn sai một cái là dẫn đến lỗi về tính đúng đắn hoặc thảm họa về hiệu năng.

Khi cánh cửa bị kẹt: Một vụ Deadlock sắp xảy ra

Dưới đây là những gì xảy ra khi hai luồng quên mất quy tắc về thứ tự. Luồng A lấy Khóa A, Luồng B lấy Khóa B, sau đó mỗi bên lại muốn cái mà bên kia đang giữ. Bây giờ không ai có thể nhúc nhích. Đây chính là tình trạng tương tranh (race condition) mà mọi hệ thống đồng thời đều phải phòng vệ.

Tìm lỗi

Dưới đây là một phương thức chiếm lấy hai trong số năm chiếc khóa từ chồng lớp của chúng ta. Trông nó thật vô hại. Nó thậm chí còn có khối try/finally. Nhưng ở đâu đó trong này, quy tắc về thứ tự đã bị phá vỡ. Nếu một luồng khác đang thực hiện việc lấy khóa theo trình tự 1 → 5 thông thường, hai luồng có thể chèn ép lẫn nhau.

Nhấp vào dòng lệnh mà bạn nghĩ là sai.

Chính kiểu lỗi này là nguyên nhân khiến các hệ thống vận hành thực tế bị treo vào lúc 3 giờ sáng. Hiểu rõ thứ tự khóa của hệ thống giống như hiểu rõ các lối thoát hiểm — hiếm khi cần dùng, nhưng khi cần thì nó vô giá.

Kiểm tra hiểu biết

Bốn tình huống. Đừng học thuộc lòng — hãy sử dụng những gì bạn vừa biết về những cánh cửa, người đọc, người ghi và thứ tự lấy khóa.

Tiếp theo — Module 7: Khả năng quan sát. Giờ bạn đã biết nó hoạt động thế nào, làm sao để thấy nó đang hoạt động lúc chương trình đang chạy?

Bay mù không phải là một chiến lược

Cơ sở dữ liệu của bạn đã chạy được ba ngày. Mọi thứ có ổn không? Các lượt commit có diễn ra không? Bao nhiêu lượt? Bao nhiêu lượt bị rollback? Nếu bạn không thể trả lời những câu hỏi đó trong vòng dưới năm giây, hệ thống của bạn không có khả năng quan sát.

Một phi công không thể mở mui một chiếc 747 ở độ cao 10.000 mét. Họ dựa vào bảng khí cụ trong buồng lái — các đồng hồ đo, đèn cảnh báo và máy ghi âm buồng lái. Một cơ sở dữ liệu đang chạy cũng giống hệt như vậy. Bạn không thể đóng băng nó giữa một giao dịch để liếc nhìn vào bên trong. Bạn cần những công cụ báo cáo ra bên ngoài khi nó đang "bay".

Một câu nói. Hai thực tế.

Dưới đây là cùng một sự kiện — một hàng dữ liệu được chèn — được ghi lại theo hai cách khác nhau. Cả hai đều "chạy". Chỉ có một cách là có thể sử dụng được sau khi sự việc đã xảy ra.

Console.WriteLine("insert done");

{"timestamp":"2026-04-22T10:12:03Z",
 "level":"Information",
 "event":"row.inserted",
 "table":"Users",
 "txn":42}

Máy ghi hộp đen

Mọi dòng nhật ký trong engine là một DatabaseLogEntry — một đối tượng nhỏ, có kiểu dữ liệu mạnh, biết cách tự biến mình thành JSON. Hãy coi nó là một trang được xé ra từ máy ghi âm hành trình.

public sealed class DatabaseLogEntry
{
    public DateTimeOffset Timestamp { get; init; } = DateTimeOffset.UtcNow;
    public DatabaseLogLevel Level { get; init; }
    public string EventName { get; init; } = string.Empty;
    public string Message { get; init; } = string.Empty;
    public IReadOnlyDictionary<string, object?> Properties { get; init; } = new Dictionary<string, object?>();

    public string ToJson()
    {
        var payload = new Dictionary<string,         {
            ["timestamp"] = Timestamp.ToString("O"),
            ["level"] = Level.ToString(),
            ["event"] = EventName,
            ["message"] = Message
        };

        foreach (var pair in Properties)
        {
            payload[pair.Key] = pair.Value;
        }

        return JsonSerializer.Serialize(payload);
    }
}

Các đồng hồ đo trên bảng điều khiển

Nhật ký kể câu chuyện. Các số đo đếm câu chuyện. Mọi sự kiện lớn mà engine thực hiện đều làm tăng một bộ đếm (counter) lên một đơn vị. Dưới đây là toàn bộ cụm đồng hồ đo chỉ trong 30 dòng lệnh.

internal sealed class DatabaseMetrics
{
    private long _tablesCreated;
    private long _transactionsStarted;
    private long _inserts;
    private long _updates;
    private long _deletes;
    private long _flushes;
    private long _checkpoints;
    private long _backupsCreated;
    private long _integrityChecks;

    public void IncrementTablesCreated() => Interlocked.Increment(ref _tablesCreated);
    public void IncrementTransactionsStarted() => Interlocked.Increment(ref _transactionsStarted);
    public void IncrementInserts() => Interlocked.Increment(ref _inserts);
    public void IncrementUpdates() => Interlocked.Increment(ref _updates);
    public void IncrementDeletes() => Interlocked.Increment(ref _deletes);
    public void IncrementFlushes() => Interlocked.Increment(ref _flushes);
    public void IncrementCheckpoints() => Interlocked.Increment(ref _checkpoints);
    public void IncrementBackupsCreated() => Interlocked.Increment(ref _backupsCreated);
    public void IncrementIntegrityChecks() => Interlocked.Increment(ref _integrityChecks);

    public DatabaseMetricsSnapshot Snapshot()
    {
        return new DatabaseMetricsSnapshot
        {