diff --git a/README.md b/README.md index 8b148a6..c0f0085 100644 --- a/README.md +++ b/README.md @@ -395,6 +395,21 @@ Comprehensive backend architecture module with 6+ interactive visualizations cov - **Observability**: Three pillars (Logs, Metrics, Traces) with interactive triangle diagram, tool recommendations, and incident response workflow - **Request Lifecycle**: Animated "Buy Now" journey through DNS → TCP/TLS → Load Balancer → API Gateway → Cache → Database → Message Queue → Response with latency budgets +### 🗄️ **Database & DBMS (Complete)** + +Comprehensive database internals module with 7 interactive visualizations covering relational and NoSQL database architecture: + +- **Introduction**: Data vs Database vs DBMS, learning journey overview, stats grid, and module navigation +- **Database Models**: Interactive comparison of 5 paradigms (Relational, Document, Key-Value, Graph, Vector) with Database Taxonomy visualization +- **DBMS Architecture**: Query Processor + Storage Engine pillars, Oracle vs PostgreSQL background processes comparison +- **Query Processor**: Parser → Rewriter → Cost-Based Optimizer → Execution Engine pipeline with animated SQL lifecycle visualization +- **Storage Engine**: Buffer Manager, Access Methods (B-Tree, Hash), Lock Manager, Recovery Manager with interactive buffer cache simulation +- **SQL Fundamentals**: Interactive CRUD examples with category tabs, Window Functions, SQL vs NoSQL comparison +- **Indexing & Optimization**: Interactive B-Tree insertion/search visualization, B-Tree vs Hash index comparison, query optimizer GPS analogy +- **Transactions & ACID**: Atomicity, Consistency, Isolation, Durability with concurrent transaction demo (success & crash scenarios) +- **Oracle vs PostgreSQL**: SGA vs shared_buffers, process models, MVCC Undo/Redo vs dead tuples, commit flow comparison with interactive MVCC visualization +- **Visualization Hub**: 7 interactive visualizations — Database Taxonomy, Query Lifecycle, B-Tree Index, Buffer Manager, ACID Transactions, MVCC Comparison, ER Diagram Builder + - **Multi-Language Execution**: JavaScript, TypeScript (transpiled), and Python (Pyodide WASM) — all in-browser, no server - **AST Instrumentation**: Acorn/Astring pipeline injects `__snapshot()` calls around every statement; Python uses `sys.settrace` wrapper with base64-encoded source - **Timeline Player**: Step forward/backward through execution snapshots, inspect variables and call stack at each point @@ -480,7 +495,7 @@ This project is licensed under the MIT License - see the [LICENSE](LICENSE) file - 📧 **Issues**: Report bugs or request features via GitHub Issues - 💬 **Discussions**: Join community discussions for questions and ideas - 📖 **Documentation**: Comprehensive docs available in the `/docs` directory -- 🎓 **Learning Modules**: 15 complete interactive modules with 96+ visualizations +- 🎓 **Learning Modules**: 16 complete interactive modules with 103+ visualizations - 🎯 **Playground**: LeetCode-style coding environment with debugging and gamification --- diff --git a/docs/Database and DBMS Explained for All.md b/docs/Database and DBMS Explained for All.md new file mode 100644 index 0000000..45597ff --- /dev/null +++ b/docs/Database and DBMS Explained for All.md @@ -0,0 +1,411 @@ +# **Comprehensive Analysis of Database Management Systems: Architecture, Mechanics, and Visual Pedagogy** + +The modern digital ecosystem is built upon an invisible, highly structured, and relentlessly efficient foundation of data. Every application, from global financial networks to mobile social media platforms, relies on the rapid, secure, and reliable storage and retrieval of information.1 The concept of a database long predates digital computing, originating in the physical filing cabinets used to store health records, tax documents, and demographic data.2 However, the exponential growth of information necessitated a technological evolution. The transition from rudimentary flat-file systems in the 1960s to the revolutionary relational database models of the 1970s fundamentally altered information management.2 This report provides an exhaustive, deeply technical analysis of databases and Database Management Systems (DBMS), exploring their core engines, querying mechanisms, and architectural paradigms. Furthermore, designed to integrate with advanced visualization platforms, this document incorporates specific pedagogical models—including analogies suitable for a younger demographic—and actionable storyboard scenarios for Artificial Intelligence (AI) image generators. + +## **The Genesis and Evolution of Data Management** + +To understand the problems that databases solve, one must examine the history of information storage. In the early days of computing, data was stored using punch cards, magnetic tapes, and simple flat-file systems.3 While these methods allowed for digital storage, they presented severe limitations. Flat files suffered from massive data duplication, extreme difficulty in accessing specific records without reading the entire file sequentially, and a total inability to establish relationships between different data entities.1 If a company needed to update a client's address, they might have to locate and manually update dozens of disparate text files, risking data inconsistency. + +The database was created to solve these exact problems. By centralizing data and imposing a mathematical structure upon it, databases eliminated redundancy, ensured data consistency, and allowed for complex, high-speed data retrieval.1 In 1970, Edgar F. Codd published his pioneering work on the Relational Model, which organized data into highly structured tables interconnected by logical relationships.4 Throughout the 1980s and 1990s, relational databases became the dominant paradigm.2 They delivered rich indexing to make queries efficient and introduced "Transactions"—a combination of read and write operations spread across the database with strict engineering guarantees to prevent catastrophic data loss or corruption.2 + +As the internet expanded in the 2000s, producing massive volumes of unstructured and semi-structured data, relational databases faced scaling challenges.3 Their rigid schemas struggled with the messy realities of big data, and scaling them horizontally required prohibitive computational resources.4 This limitation spurred the creation of NoSQL (Not Only SQL) databases, designed for flexible, schema-less data structures and horizontal distribution.4 Most recently, the 2010s and 2020s have seen the rise of cloud computing architectures and vector databases, engineered specifically to power Artificial Intelligence (AI) and Machine Learning (ML) workloads.3 + +## **Deciphering Data, Databases, and the DBMS** + +To master database engineering, one must establish a strict ontological distinction between data, a database, and a Database Management System. + +Data, in its purest form, constitutes raw, unprocessed facts or values. It can be a number, text, an image, or any measurable metric.1 For example, the isolated strings "Cat", "25", and "Black" are raw data points. When these distinct pieces of data are processed, correlated, and organized to provide coherent meaning, they transform into information, such as the sentence, "My cat is 25 years old and black".1 + +A database is an organized, structured collection of this data, stored electronically, designed to allow applications to store, retrieve, and update large volumes of information efficiently.1 However, a database alone is merely a passive repository—comparable to a warehouse full of goods. It lacks the innate ability to enforce security protocols, manage simultaneous user access, or recover from sudden hardware failures.10 + +This operational gap is bridged by the Database Management System (DBMS). A DBMS is the sophisticated software application that acts as the active intermediary between the end-users, the applications, and the raw database itself.10 The DBMS provides the capability to perform Create, Read, Update, and Delete (CRUD) operations, enforces security protocols, facilitates backup and recovery, and processes complex queries using languages such as the Structured Query Language (SQL).2 Without a DBMS, managing concurrent access—where thousands of users might attempt to modify the same data record simultaneously—or ensuring data survival after a system crash would be virtually impossible.10 + +### **Pedagogical Visualization: Explaining the DBMS to a Ten-Year-Old** + +To translate these abstract computer science concepts for a younger audience, visual pedagogy relies on highly relatable analogies. The standard analogy utilized for a ten-year-old equates the database to a physical storage container, and the DBMS to an intelligent, active entity managing it.12 + +**AI Image Generation Prompt (Midjourney/DALL-E):** + +*A highly detailed, isometric 3D Pixar-style illustration of a glowing, magical toy box (representing the Database). Inside the box, hundreds of diverse toys (representing Data) are floating in neatly organized, color-coded grids and shelves. Standing next to the box is a friendly, futuristic robot wearing a librarian's glasses and holding a glowing clipboard (representing the DBMS). The robot is handing a specific blue toy car to a happy child (the User/Application). Bright, volumetric lighting, vibrant colors, educational technology concept, 8k resolution, photorealistic rendering.* + +In this pedagogical analogy, the toys represent raw data.12 If a child simply throws all their toys into a standard box, finding a specific blue toy car requires emptying the entire box—a wildly inefficient process known in database terminology as a "full table scan".14 The "Magic Toy Box" operates differently. The box itself is the database, storing the toys in highly organized, indexed compartments.12 The robot represents the DBMS. Because the robot tracks exactly where every toy is stored using an internal ledger, the child only needs to ask, "Give me all the blue toy cars," and the robot instantly retrieves them without searching the entire box.12 + +For slightly older audiences, an alternative analogy equates the database to a massive corporate filing cabinet full of paper records, and the DBMS to the highly efficient secretary who controls access, organizes the files logically, and retrieves specific documents upon request, ensuring no two people alter the same document simultaneously.13 + +## **The Taxonomy of Database Models** + +As data volumes expanded and the nature of applications diversified, the rigid structure of early relational databases proved insufficient for every use case. This led to the emergence of diverse database paradigms, broadly categorized into relational (SQL) and non-relational (NoSQL) systems, along with highly specialized architectures.4 + +| Database Paradigm | Structural Data Model | Primary Use Case and Architecture | Scaling Mechanism | Example Systems | +| :---- | :---- | :---- | :---- | :---- | +| **Relational (SQL)** | Structured tables with predefined schemas (rows and columns) and strict relationships.15 | Financial systems, inventory, and transactions requiring strict ACID compliance.9 Extremely reliable for structured queries.16 | Vertical scaling (adding hardware power to a single centralized server).7 | PostgreSQL, Oracle, MySQL, SQL Server.9 | +| **Document (NoSQL)** | Semi-structured JSON or BSON (Binary JSON) objects. Flexible, schema-less design.8 | Content-heavy applications, e-commerce catalogs, and rapid prototyping where schemas change frequently.9 | Horizontal scaling (distributing data chunks across multiple cluster nodes).7 | MongoDB.1 | +| **Key-Value (NoSQL)** | Collections of unique identifiers (keys) paired with arbitrary values (data).16 | High-speed caching, user session management, and real-time processing.7 | Horizontal scaling across distributed systems. | Redis, Amazon DynamoDB.9 | +| **Graph (NoSQL)** | Nodes (data entities) and Edges (relationships between entities).15 | Social networks, recommendation engines, and fraud detection where navigating complex relationships is critical.16 | Horizontal and Vertical hybrid scaling. | Neo4j. | +| **Vector** | High-dimensional mathematical arrays (vectors) representing semantic meaning.8 | AI applications, Large Language Models (LLMs), semantic search, and Retrieval-Augmented Generation (RAG).9 | Horizontal scaling. | Pinecone, Milvus, Weaviate, pgVector.9 | + +Relational databases remain the backbone of the internet, optimizing structured data retrieval, preserving complex relationships, and minimizing redundancy through normalization.9 However, for high-velocity, unstructured data generated by IoT devices or social media platforms, NoSQL databases offer the necessary schema flexibility.7 For example, a NoSQL Document database allows developers to store a user profile with three phone numbers and another with zero, without having to alter a rigid table schema.8 + +Recently, Vector databases have surged in importance.9 In the era of AI, machines need to "understand" data based on semantic meaning rather than exact keyword matches.9 Vector databases convert text, images, and audio into high-dimensional numerical vectors, allowing the system to find data points that are mathematically "close" to one another, thereby powering modern recommendation systems and generative AI platforms.9 + +### **Deep Dive: MongoDB Architecture** + +To understand NoSQL mechanics, one must examine MongoDB, a premier document database.19 MongoDB's architecture abandons the relational table in favor of Collections containing BSON (Binary JSON) documents.20 Its core architectural strength lies in its native distribution mechanisms: + +* **Replica Sets:** A group of MongoDB servers maintaining the exact same dataset. This provides redundancy and automatic failover. A Primary node handles all writes, while Secondary nodes replicate the data and can handle read operations.20 +* **Sharding:** The method for horizontal scaling. MongoDB splits massive datasets into smaller chunks (shards) distributed across multiple servers based on a designated "Shard Key".20 +* **Mongos Router & Config Servers:** Client applications do not connect directly to the shards. They connect to a mongos query router, which consults Config Servers (holding cluster metadata) to determine which specific shard holds the requested data, seamlessly routing the query.20 + +### **Pedagogical Visualization: The Database Ecosystem** + +**AI Image Generation Prompt (Leonardo.Ai / Canva Magic Studio):** + +*A futuristic, split-screen cyber-city infographic depicting different database types. On the left side (representing SQL), show highly organized, glowing steel filing cabinets stacked in perfect structural grids with neon blue connections. In the middle (representing Document NoSQL), show fluid, floating origami-like folders of different sizes and shapes connected by dynamic, flexible neon orange web-lines. On the right side (representing Vector DBs), show a 3D mathematical scatter plot of glowing particles forming recognizable constellation shapes in a dark void. Cyberpunk aesthetic, hyper-detailed UI elements, dark mode background.* 21 + +## **Inside the DBMS: Core Architectural Components** + +Most modern database management systems operate on a client-server architecture.22 The database cluster acts as the server, responsible for storing, processing, and protecting data, while applications act as clients sending requests, usually in the form of SQL queries, over a TCP/IP network.22 + +Beneath the surface, the DBMS is a highly coordinated, modular assembly of specialized components, broadly divided into the Query Processor and the Storage Engine.22 + +The **Query Processor** is the brain of the DBMS, responsible for translating human-readable SQL into executable machine actions.24 + +1. **Parser:** Checks the SQL syntax for valid structure and validates the query against the database schema.25 +2. **Query Optimizer:** A highly sophisticated algorithmic component that analyzes multiple potential execution paths. It generates an Execution Plan by calculating the "cost" of different data access methods, deciding the most mathematically efficient route to retrieve the data.22 +3. **Execution Engine:** Takes the optimal plan generated by the optimizer and executes it step-by-step against the underlying storage structures.22 + +The **Storage Engine** is the physical workhorse where the actual manipulation of data occurs on the disk and in memory.22 Its critical sub-components include: + +* **Buffer Manager (Cache):** Disk I/O is the slowest operation in computing. The Buffer Manager caches frequently accessed data pages in the main memory (RAM). When data is requested, the system checks the fast memory buffer first, drastically reducing slow physical disk reads.22 +* **Access Methods:** Defines how data is physically organized on the disk, supporting complex structural paradigms such as sequential files, B-Trees, and Log-Structured Merge-Trees (LSM Trees) to facilitate rapid retrieval.22 +* **Transaction Manager:** Coordinates concurrent access to ensure that multiple transactions adhere to ACID properties, scheduling operations to prevent data corruption.22 +* **Lock Manager:** Works in tandem with the Transaction Manager. It applies locks to specific rows, tables, or database objects during execution, ensuring that multiple users attempting to write to the exact same piece of data do not overwrite each other destructively.22 +* **Recovery Manager:** The ultimate safety net. It manages the Write-Ahead Log (WAL), a sequential file that meticulously records every change before it is permanently written to the main data files. This ensures the database can rebuild its state and recover consistently following a sudden power failure or hardware crash.22 + +## **Comparative Anatomy: Oracle vs. PostgreSQL** + +To truly master database engineering, one must move beyond abstract concepts and understand how different enterprise systems implement these core architectures. Oracle Database and PostgreSQL represent two of the most powerful and widely utilized relational systems, yet their internal mechanics and design philosophies diverge significantly.17 + +Oracle is a highly integrated, commercially licensed system optimized for massive enterprise clusters, mission-critical financial systems, and extreme concurrency.29 It relies heavily on proprietary infrastructure like Real Application Clusters (RAC) and Exadata, which couple storage and compute to deliver unparalleled performance.30 Conversely, PostgreSQL is a profoundly extensible, open-source object-relational database management system (ORDBMS) favored for modern cloud-native backend applications, microservices, and organizations seeking freedom from prohibitive licensing costs.17 + +### **Process and Memory Architectures** + +Oracle instances operate using a complex, shared memory structure known as the System Global Area (SGA) and individual process memory known as the Program Global Area (PGA).30 + +* The **SGA** is a massive shared memory pool that contains the Database Buffer Cache (storing copies of data blocks read from disk), the Shared Pool (caching parsed SQL execution plans, PL/SQL code, and data dictionary metadata), and the Redo Log Buffer (a circular buffer capturing transaction changes before they are written to disk).33 +* The **PGA** handles private, session-specific variables, sort areas, and hash areas used during query execution.32 Oracle's multithreaded architecture allows background processes to run either as separate operating system processes or as threads within a single process.34 + +PostgreSQL, conversely, utilizes a simpler, classical process-per-connection model. When the PostgreSQL server boots, a primary daemon process known as the postmaster starts.23 The postmaster listens for incoming client connections on a TCP/IP or Unix socket. When an application connects, the postmaster forks a brand new, private backend server process specifically dedicated to that single client.23 These isolated backend processes then interact with a shared memory area that holds the shared buffer cache and WAL buffers.36 While this model provides excellent isolation, managing thousands of concurrent connections requires external connection pooling software (like PgBouncer) to prevent excessive memory consumption.39 + +### **Background Processes: The Invisible Machinery** + +To maintain database health, optimize disk I/O, and ensure durability without blocking active user queries, both systems deploy a sophisticated suite of autonomous background processes.40 + +| Core Function | Oracle Background Processes | PostgreSQL Background Processes | Mechanical Description | +| :---- | :---- | :---- | :---- | +| **Disk Writing (Data)** | DBWn (Database Writer) | Background Writer (BGWriter) | Constantly scans the shared memory cache to locate "dirty" pages (data blocks that have been modified by users). It systematically flushes these dirty blocks to the physical disk files, freeing up RAM for new queries and preventing massive I/O bottlenecks. | +| **Transaction Logging** | LGWR (Log Writer) | WAL Writer | The highest priority process. It flushes the transaction logs (Redo Buffer in Oracle, WAL Buffers in Postgres) from memory to disk. This process strictly adheres to the Write-Ahead Logging protocol, guaranteeing data durability *before* the slower DBWn or BGWriter writes the actual data files. | +| **Synchronization** | CKPT (Checkpoint Process) | Checkpointer | Acts as the system orchestrator. It forces the writing of all dirty buffers to disk at specific intervals and updates all data file headers and control files. This creates a "checkpoint" that severely limits the amount of time required to recover the database after a crash. | +| **Process/Session Cleanup** | PMON (Process Monitor) | Postmaster / Backend Termination | Oracle's PMON actively cleans up the resources and locks held by user processes that have failed or abruptly disconnected. In PostgreSQL, the postmaster monitors its forked backend children and handles sudden terminations. | +| **Instance Recovery & Maintenance** | SMON (System Monitor) | Autovacuum Launcher / Startup Process | Oracle's SMON performs critical instance recovery upon reboot and reclaims temporary segment space. PostgreSQL utilizes the Startup Process for crash recovery, while the Autovacuum Launcher handles the continuous cleanup of "dead tuples" (a byproduct of its MVCC model). | + +### **Transaction Commit Flows: Undo/Redo vs. MVCC/WAL** + +Both Oracle and PostgreSQL implement Multi-Version Concurrency Control (MVCC) to achieve high transaction isolation.46 MVCC guarantees that readers do not block writers, and writers do not block readers, allowing massive concurrency.47 However, their mechanical execution of MVCC represents the most profound architectural difference between the two systems. + +When a user executes an UPDATE transaction in **Oracle**, the system generates two streams of data: "Redo" and "Undo".29 The Redo data records the *new* value (to re-apply the change in case of a crash). The Undo data records the *old* value.49 Oracle moves the old version of the row entirely out of the main data table and places it into a dedicated UNDO tablespace.47 If the transaction fails, the Undo data is used to roll back the change. If another user runs a long query that needs to see the data as it looked ten minutes ago, Oracle reconstructs that past state by reading from the UNDO tablespace, a feature that also powers Oracle's powerful "Flashback" technology.47 + +**PostgreSQL** takes a different approach to MVCC. It stores both the old and new versions of the row inline, directly within the main data file.47 When a row is updated, PostgreSQL does not overwrite it; it writes a completely new version of the row (a new tuple) elsewhere in the table and merely marks the old tuple as expired.47 This eliminates the need for separate Undo tablespaces and simplifies transaction rollback. However, this design creates "dead tuples" throughout the database.45 If left unchecked, these dead tuples cause severe database bloat, destroying query performance. Consequently, PostgreSQL relies heavily on the Autovacuum background process, which constantly sweeps the physical disk files, identifying and removing dead tuples to reclaim space for future inserts.40 + +For durability, PostgreSQL relies exclusively on the Write-Ahead Log (WAL).29 The WAL acts identically to Oracle's Redo logs, serving as an immutable, sequential ledger of all changes, ensuring the Checkpointer can perfectly rebuild the database state following a critical hardware failure.36 + +Furthermore, transaction execution boundaries differ. Oracle inherently treats every Data Manipulation Language (DML) statement as the implicit start of a transaction; the data is locked, and the transaction remains open until the developer issues an explicit COMMIT or ROLLBACK command.47 Conversely, PostgreSQL operates in an "autocommit" mode by default. It treats every individual SQL statement as a complete, committed transaction the millisecond it finishes executing, unless the developer explicitly wraps multiple statements within a BEGIN and COMMIT block.47 + +### **Pedagogical Visualization: Comparative Engine Blueprints** + +**AI Image Generation Prompt (Krock.io / Firefly):** + +*A high-resolution technical architectural blueprint split cleanly into two halves. The left half is labeled "Oracle Architecture" showing a massive, centralized circular core engine (labeled SGA) surrounded by satellite nodes (labeled DBWn, LGWR) with complex pipeline arrows pointing to external, highly secure storage vaults (labeled Redo and Undo). The right half is labeled "PostgreSQL Architecture" showing a highly distributed network of independent robot workers (Backend processes) accessing a shared central data pool, with a dedicated robotic scribe (WAL Writer) constantly printing a continuous paper receipt (Write-Ahead Log) while a cleaning robot (Autovacuum) sweeps up metallic debris. The style is detailed technical drafting, white and neon blue lines on a dark blueprint grid background, with circuit board aesthetics.* 21 + +## **The Mechanics of Retrieval: Indexing and the Query Optimizer** + +A profound concept for any software engineer to grasp is how a database can query a table containing billions of records and return a specific result in milliseconds. This miraculous speed is achieved entirely through the mathematical structures of Indexing.14 + +To conceptualize a database index, one must look no further than the index at the back of a large textbook.14 If a developer needs to find information on "Transaction Isolation" in a 1,000-page manual, reading the book page by page, line by line, is an exhausting process. In database terms, this is known as a "Full Table Scan," and it is the primary cause of catastrophic application performance degradation.14 Instead, the reader consults the index, locates the exact page number for the term, and jumps directly to that physical location.14 + +### **B-Tree vs. Hash Indexes** + +The predominant indexing data structure utilized by nearly all modern relational databases is the B-Tree (Balanced Tree).52 A B-Tree is a hierarchical, self-balancing tree structure consisting of a root node, internal routing nodes, and leaf nodes containing the actual data pointers.52 + +The power of a B-Tree lies in its balanced nature: it mathematically guarantees that all leaf nodes exist at the exact same depth from the root.53 This ensures that search times are highly predictable, shallow, and logarithmic (![][image1]). Furthermore, a single B-Tree node is typically designed to align perfectly with the size of a disk block, maximizing the amount of routing data loaded into RAM per physical disk read.54 Because B-Trees inherently maintain data in sorted order, they are exceptionally efficient for range queries (e.g., WHERE age BETWEEN 25 AND 40\) and prefix string searches (e.g., WHERE name LIKE 'Pat%').53 + +Below is an abstracted Python implementation illustrating the foundational logic of a B-Tree node, demonstrating how a database engine handles internal data splits to maintain perfect balance as new records are inserted 56: + +Python + +class BTreeNode: + def \_\_init\_\_(self, leaf=False): + self.leaf \= leaf + \# Keys hold the sorted indexed values + self.keys \= + \# Child array holds pointers to deeper nodes + self.child \= + +class BTree: + def \_\_init\_\_(self, t): + self.root \= BTreeNode(True) + self.t \= t \# The 'Order' of the B-Tree dictates maximum node capacity + + def insert(self, k): + root \= self.root + \# If the root node is completely full, the tree must grow in height + if len(root.keys) \== (2 \* self.t) \- 1: + temp \= BTreeNode() + self.root \= temp + \# The old root becomes a child of the new root + temp.child.insert(0, root) + \# The engine splits the old root in half, pushing the median key up + self.split\_child(temp, 0) + self.insert\_non\_full(temp, k) + else: + \# If space exists, standard logarithmic traversal and insertion occurs + self.insert\_non\_full(root, k) + +Alternatively, databases can utilize Hash Indexes. A Hash Index applies a deterministic mathematical algorithm to the indexed column to generate a unique hash bucket location.53 Hash indexes are unparalleled in speed for exact match queries (e.g., WHERE user\_id \= 1054), executing lookups in near constant time (![][image2]).53 However, they are entirely useless for range queries or partial wildcard matches because the cryptographic hashing process irreversibly destroys the sorting order of the original data.53 + +### **The Query Optimizer and Execution Plans** + +When an application submits a SQL query, it does not instruct the database *how* to retrieve the data; it only specifies *what* data it wants. It is the responsibility of the Query Optimizer to bridge this gap.57 The Optimizer operates as a highly advanced GPS routing algorithm for data.26 + +During the parsing phase, the Optimizer analyzes the SQL syntax and consults internal Database Statistics.26 These statistics are metadata catalogs containing deep insights into the shape of the data: how many rows exist, the cardinality of columns, and data distribution histograms.26 Using this statistical data, the Optimizer generates thousands of possible Execution Plans—comparing the mathematical "cost" of performing an Index Seek (using the B-Tree) versus a Hash Join versus a Full Table Scan—and selects the absolute most efficient route.37 + +However, if a database administrator fails to regularly update these statistics, the Optimizer operates on false assumptions. It might believe a table contains 20 rows when it actually contains 250 million, leading it to disastrously ignore a perfectly good B-Tree index and execute a multi-minute full table scan instead.59 Modern developers utilize visual EXPLAIN features in tools like MySQL Workbench or SQL Server Management Studio to visually map these execution plans, reading the tree from bottom to top, left to right, to identify missing indexes or inefficient sorting operations.58 + +### **Advanced Query Implementation** + +To fully leverage the power of the query optimizer, developers must write structurally efficient SQL. Advanced query implementation frequently relies on Common Table Expressions (CTEs) to modularize complex logic, ensuring the optimizer applies filtering *before* executing computationally expensive joins.63 + +Below is a real-world example of an optimized query. It utilizes a CTE to aggregate sales data down to a small, distinct set of customer IDs before joining that aggregated data to the larger dimension table. Furthermore, it avoids using functions on the JOIN columns, a common anti-pattern that disables the optimizer's ability to use indexes 63: + +SQL + +\-- DDL: Create a B-Tree index to support rapid filtering and joining +CREATE INDEX idx\_customer\_country ON Customers(Country); + +\-- Utilize a Common Table Expression (CTE) to pre-aggregate data efficiently +WITH SalesData AS ( + SELECT CustomerID, SUM(TotalAmount) AS Total\_Sales + FROM Orders + GROUP BY CustomerID +) +\-- Execute the final join against the pre-filtered, indexed data +SELECT c.CustomerName, c.Country, sd.Total\_Sales +FROM Customers c +INNER JOIN SalesData sd ON c.CustomerID \= sd.CustomerID +\-- The optimizer utilizes idx\_customer\_country for this strict filter +WHERE c.Country IN ('USA', 'Canada') + AND sd.Total\_Sales \> 5000; + +## **Ensuring Data Integrity: Transactions, ACID, and Normalization** + +A fundamental, non-negotiable requirement of enterprise relational databases is preserving absolute data integrity during concurrent, multi-user access.6 The rules governing this integrity are encapsulated in the ACID properties.48 + +* **Atomicity:** Treats a complex transaction consisting of multiple steps as a single, indivisible logical unit. Either all operations within the transaction succeed entirely, or the entire transaction fails and the system gracefully rolls back, leaving the database completely unchanged.48 +* **Consistency:** Guarantees that any transaction brings the database from one valid state to another, strictly enforcing all defined rules, foreign keys, and constraints.48 +* **Isolation:** Ensures that the concurrent execution of multiple transactions leaves the database in the exact same state as if the transactions were executed sequentially, one after the other, preventing simultaneous queries from interfering with one another.48 +* **Durability:** Guarantees that once a transaction has been successfully committed, it will remain permanently committed even in the event of a total system crash or catastrophic power loss, a feat achieved via the Write-Ahead Log or Redo mechanisms.48 + +### **Pedagogical Visualization: The Pokémon Card Trade Analogy** + +To elucidate the highly abstract ACID properties for a younger audience, we employ the Pokémon Card Trade analogy.68 + +**AI Image Generation Prompt (Midjourney / Canva):** + +*A vibrant, 2D vector art illustration showing two kids, Ken and Bob, at a school playground executing a card trade. Above them are four glowing, futuristic shields labeled A, C, I, D. Atomicity (A) shows a magical glowing cord connecting the two kids' hands—if one lets go, the cards instantly snap back to their original owners without the trade completing. Isolation (I) shows Ken and Bob inside an impenetrable glowing forcefield bubble, preventing a third child running in the background from interrupting or interfering with their specific trade. Durability (D) shows the successfully traded cards turning into glowing, indestructible diamonds once the handshake is complete. Clean vector style, educational textbook illustration, bright and engaging.* 68 + +### **The Perils of Concurrency: Isolation Levels** + +While Atomicity and Durability are relatively straightforward to engineer, Isolation is notoriously difficult to manage at scale. Forcing thousands of global users to execute transactions strictly sequentially would grind application performance to a halt. Therefore, databases provide varying Transaction Isolation Levels, allowing developers to mathematically balance strict data accuracy against system performance and concurrency.69 + +1. **Read Uncommitted:** The fastest but most perilous level. It provides minimal isolation, allowing a "Dirty Read" anomaly. Transaction A can read uncommitted, fluctuating data currently being altered by Transaction B. If B encounters an error and rolls back, Transaction A has made critical application decisions based on phantom data that technically never existed in the database.72 +2. **Read Committed:** The default level for most databases (including Oracle and PostgreSQL). It strictly prevents dirty reads. However, it allows "Non-repeatable Reads," where Transaction A reads the same row twice during a process, but receives different data the second time because Transaction B successfully updated and committed the row in the interim.47 +3. **Repeatable Read:** Prevents non-repeatable reads by holding strict read locks or maintaining MVCC snapshot views for the duration of the transaction. However, it can still suffer from "Phantom Reads." This occurs when Transaction A queries a range (e.g., all employees in a department) and Transaction B inserts entirely *new* employee rows that match the criteria. Transaction A will suddenly see "phantom" rows appear in subsequent identical queries.72 +4. **Serializable:** The strictest, most draconian level. It guarantees absolute sequential execution and mathematically prevents all concurrency anomalies. However, it drastically reduces database speed, causing immense locking contention and forcing applications to constantly retry failed transactions.69 + +### **Database Schema Normalization** + +Before data is ever written to disk or queried, it must be logically and mathematically structured. Database Schema Normalization is the rigorous, step-by-step process of designing relational tables to eliminate data redundancy and prevent insertion, update, or deletion anomalies.74 + +* **First Normal Form (1NF):** Enforces strict atomicity. Every single cell in a table must hold a single, indivisible value. Repeating groups, arrays, or comma-separated lists (e.g., storing "Apples, Oranges, Pears" in a single purchased\_products column) are strictly prohibited. These multi-valued attributes must be split into separate rows to ensure querying integrity.74 +* **Second Normal Form (2NF):** Requires full 1NF compliance and mandates "Full Functional Dependency." If a table utilizes a composite primary key (multiple columns combining to uniquely identify the row), all non-key attributes must depend on the *entire* key, not just a partial segment of it. This eliminates partial dependencies that cause redundant data storage.74 +* **Third Normal Form (3NF):** The standard for most production databases. It requires 2NF compliance and removes all "Transitive Dependencies." A non-key attribute must not depend on another non-key attribute. For example, if an Employees table holds Department\_ID, Department\_Name, and Department\_Location, the location depends on the department, not the employee. The department data must be normalized into its own separate dimensional table.74 + +By rigorously adhering to normalization principles, engineers ensure schemas are robust, maintainable, and impervious to data corruption over decades of use. A fully normalized, real-world schema implementation for a bookstore—executed via Data Definition Language (DDL)—looks like this 79: + +SQL + +\-- Implementing a normalized 3NF schema for a bookstore application +CREATE SCHEMA bookstore; + +\-- Dimensional Table 1: Genres +CREATE TABLE bookstore.genres ( + genre\_id SERIAL PRIMARY KEY, + name VARCHAR(255) NOT NULL UNIQUE, + description TEXT NOT NULL +); + +\-- Dimensional Table 2: Authors +CREATE TABLE bookstore.authors ( + author\_id SERIAL PRIMARY KEY, + first\_name VARCHAR(100) NOT NULL, + last\_name VARCHAR(100) NOT NULL +); + +\-- Fact Table: Books (Fully dependent on its composite foreign keys) +CREATE TABLE bookstore.books ( + book\_id SERIAL PRIMARY KEY, + title VARCHAR(255) NOT NULL, + \-- Foreign keys establish strict relational integrity to the dimensional tables + genre\_id INT NOT NULL REFERENCES bookstore.genres(genre\_id), + author\_id INT NOT NULL REFERENCES bookstore.authors(author\_id), + published\_date DATE NOT NULL +); + +## **The Developer's Journey: Software Engineering Database Roadmap** + +Understanding databases is not a static academic achievement but a progressive career roadmap. A software engineer's grasp of database concepts dictates their seniority, their salary, and their overall architectural impact on a tech organization.80 + +**Junior Engineer (0–2 Years):** The primary focus of a junior engineer is implementing defined functional requirements without causing system instability.81 A junior must be highly proficient in writing basic SQL queries, understanding inner and outer joins, and executing simple Extract, Transform, Load (ETL) scripts using Python or basic tools.83 They must firmly grasp 1NF, 2NF, and 3NF normalization to avoid catastrophic structural design errors when creating new application features.74 Their goal is to prove they can write working code that interacts safely with the data layer.84 + +**Mid-Level Engineer (2–5 Years):** The focus shifts dramatically from simply writing code to systemic optimization and managing complex pipelines.83 Mid-level engineers must deeply understand the Query Optimizer, actively read execution plans, and strategically apply B-Tree and Hash indexes to resolve production performance bottlenecks.14 They expand their toolkit beyond relational systems, working fluidly with NoSQL databases (like MongoDB and Redis), handling real-time streaming data (Apache Kafka), containerizing database nodes (Docker), and orchestrating automated data workflows (Apache Airflow).83 + +**Senior Engineer / Principal Architect (5–8+ Years):** At the highest levels, engineers rarely write routine daily queries; instead, they define the overarching architectural guardrails for the entire organization.83 They select between PostgreSQL, Oracle, Snowflake, or DynamoDB based on highly specific business requirements, cost analyses, and the CAP theorem.83 They possess deep, academic knowledge of database internals—such as Postgres garbage collection algorithms, connection pooling limits, massive horizontal sharding strategies, transaction isolation anomalies, and the mechanics of distributed consensus.39 Ultimately, the principal architect mentors junior developers, establishes CI/CD protocols for database schema migrations, and ensures the data infrastructure can survive unprecedented global scale.86 + +## **Final Synthesis: Complete Database Query Lifecycle Visualization Flow** + +To fulfill the specific requirements of the interactive learning module for the codexecutives.com platform, the following is a comprehensive storyboard prompt sequence designed to be fed directly into an AI system architecture diagram generator (such as Eraser.io, Leonardo.Ai, Canva Magic Studio, or Amazon Q CLI).90 This sequential flow creates an end-to-end visual description of the complex database query lifecycle, translating deep mechanics into an accessible format for everyday developers and users. + +**Storyboard Sequence for AI Generation:** + +**Scene 1: The Client Origin (The Input)** + +* **AI Prompt:** *"An isometric, highly detailed technology illustration showing a modern software engineer sitting at a multi-monitor setup. On the central screen, a block of code fires off a glowing, energetic blue data packet prominently labeled 'SQL SELECT Query'. The packet travels down a luminous fiber-optic wire, exiting the office building and speeding toward a massive, distant, futuristic cloud data center on the horizon. Style: Clean corporate tech illustration, isometric perspective, cool blue and cyber-purple color palette."* 90 + +**Scene 2: The DBMS Gatekeeper (The Query Processor)** + +* **AI Prompt:** *"Inside the bustling data center, the glowing blue query packet arrives at a high-tech security checkpoint labeled 'Query Processor'. A sleek robotic guard (representing The Parser) scans the packet with a laser to check for syntax errors. Standing next to the guard, a sophisticated robotic engineer holding multiple digital maps (representing The Query Optimizer) examines the packet and points definitively to the fastest, glowing neon path on a complex holographic map labeled 'Optimal Execution Plan'. Style: Sci-fi control room, holographic UI interfaces, highly detailed 3D render."* 22 + +**Scene 3: The Subterranean Factory (The Storage Engine & Indexing)** + +* **AI Prompt:** *"The approved query packet moves onto a massive, automated factory floor labeled 'Storage Engine'. In the immediate foreground, a commanding robot holding a clipboard (The Transaction Manager) stamps a document with a glowing 'ACID Approved' seal. In the expansive background, highly agile mechanical arms (representing Access Methods) are swiftly navigating through giant, perfectly balanced, tree-like shelving structures (representing B-Tree Indexes) to effortlessly extract specific glowing data cubes (Data Rows) without having to search the entire warehouse. Style: Futuristic automated logistics warehouse, dramatic neon lighting highlighting the mechanical precision and scale."* 22 + +**Scene 4: The Ultimate Safety Net (WAL and Buffer Manager)** + +* **AI Prompt:** *"A side view of the factory focusing on security. A rapid-printing industrial machine (representing the WAL Writer) is continuously printing a long, indestructible metal tape (the Write-Ahead Log), meticulously recording every single action taking place in the room. Nearby, the freshly retrieved glowing data cubes are temporarily resting on a brightly lit, high-speed workbench (the RAM Buffer Cache). Behind the bench, a sturdy, heavily armored worker robot (the Checkpointer) is permanently locking older data cubes into heavy steel vaults (Disk Storage). Style: Industrial cyberpunk aesthetics, emphasizing the stark contrast between bright glowing fast memory and dark, heavy permanent storage."* 22 + +**Scene 5: The Delivery and Visualization (The Output)** + +* **AI Prompt:** *"The specific glowing data cubes requested in Scene 1 are securely packed into a sleek, digital, glowing briefcase. The briefcase shoots back up the fiber-optic wire at lightspeed. It emerges from the software engineer's screen not as raw code, but instantly unfolding into beautifully formatted, easy-to-read 3D charts, graphs, and business dashboards. Style: Tying directly back to the visual language of Scene 1, isometric perspective, bright and triumphant tone, representing raw data successfully transformed into actionable human information."* 1 + +This narrative structural flow visually dissects the intimidating journey of a single database query. By translating abstract computer science mechanics—such as Cost-Based Optimization, Transaction Management, Logarithmic Index Traversal, and Write-Ahead Logging—into highly intuitive, pedagogical visual models, developers of any skill level can bridge the gap between writing code and truly understanding the subterranean engines that power the modern world. + +#### **Works cited** + +1. Understanding Data, Databases, and the Evolution of Database Systems | by Raihan Sikder | Mar, 2026 | Medium, accessed April 9, 2026, [https://medium.com/@sikderraihan693/understanding-data-databases-and-the-evolution-of-database-systems-f6129be94e14](https://medium.com/@sikderraihan693/understanding-data-databases-and-the-evolution-of-database-systems-f6129be94e14) +2. A brief history of databases: From relational, to NoSQL, to distributed SQL \- CockroachDB, accessed April 9, 2026, [https://www.cockroachlabs.com/blog/history-of-databases-distributed-sql/](https://www.cockroachlabs.com/blog/history-of-databases-distributed-sql/) +3. The Evolution of Databases: Filing Cabinets to Cloud Computing \- NAM Info Inc, accessed April 9, 2026, [https://nam-it.com/evolution-of-databases/](https://nam-it.com/evolution-of-databases/) +4. The Evolution of Database Technology: From Flat Files to Blockchain \- Inery, accessed April 9, 2026, [https://inery.io/blog/article/the-evolution-of-database-technology/](https://inery.io/blog/article/the-evolution-of-database-technology/) +5. The fascinating history of Databases \- YouTube, accessed April 9, 2026, [https://www.youtube.com/watch?v=6szdySvorzA](https://www.youtube.com/watch?v=6szdySvorzA) +6. Introduction to Oracle Database, accessed April 9, 2026, [https://docs.oracle.com/en/database/oracle/oracle-database/21/cncpt/introduction-to-oracle-database.html](https://docs.oracle.com/en/database/oracle/oracle-database/21/cncpt/introduction-to-oracle-database.html) +7. What Are The Different Types of Databases? \- Boomi, accessed April 9, 2026, [https://boomi.com/blog/database-types-guide/](https://boomi.com/blog/database-types-guide/) +8. Types of Databases: Relational, NoSQL, Cloud, Vector | DataCamp, accessed April 9, 2026, [https://www.datacamp.com/blog/types-of-databases-overview](https://www.datacamp.com/blog/types-of-databases-overview) +9. The Future of Databases (SQL, NoSQL, Vector, Graph) and How to Choose | by Tanuj Garg, accessed April 9, 2026, [https://medium.com/@thisistanujgarg/the-future-of-databases-sql-nosql-vector-graph-and-how-to-choose-260451cfad20](https://medium.com/@thisistanujgarg/the-future-of-databases-sql-nosql-vector-graph-and-how-to-choose-260451cfad20) +10. Difference Between Database and DBMS \- GeeksforGeeks, accessed April 9, 2026, [https://www.geeksforgeeks.org/dbms/difference-between-database-and-dbms/](https://www.geeksforgeeks.org/dbms/difference-between-database-and-dbms/) +11. What Is Database And Database Management System \- SQL School, accessed April 9, 2026, [https://sqlschool.com/blog/what-is-a-database-and-what-is-a-database-management-system/](https://sqlschool.com/blog/what-is-a-database-and-what-is-a-database-management-system/) +12. How Do You Explain a Database to a Child? \- FunTech, accessed April 9, 2026, [https://funtech.co.uk/latest/how-do-you-explain-a-database-to-a-child](https://funtech.co.uk/latest/how-do-you-explain-a-database-to-a-child) +13. What is a good analogy to introduce databases and SQL? \- Computer Science Educators, accessed April 9, 2026, [https://cseducators.stackexchange.com/questions/1419/what-is-a-good-analogy-to-introduce-databases-and-sql](https://cseducators.stackexchange.com/questions/1419/what-is-a-good-analogy-to-introduce-databases-and-sql) +14. Database Indexing Strategies: B-Tree, Hash, and Specialized Indexes Explained \- Medium, accessed April 9, 2026, [https://medium.com/@artemkhrenov/database-indexing-strategies-b-tree-hash-and-specialized-indexes-explained-95a3e5e3b632](https://medium.com/@artemkhrenov/database-indexing-strategies-b-tree-hash-and-specialized-indexes-explained-95a3e5e3b632) +15. accessed April 9, 2026, [https://boomi.com/blog/database-types-guide/\#:\~:text=Types%20of%20databases%20include%20relational,relationships%20using%20nodes%20and%20edges.](https://boomi.com/blog/database-types-guide/#:~:text=Types%20of%20databases%20include%20relational,relationships%20using%20nodes%20and%20edges.) +16. What's the Difference Between Relational and Non-relational Databases? \- AWS, accessed April 9, 2026, [https://aws.amazon.com/compare/the-difference-between-relational-and-non-relational-databases/](https://aws.amazon.com/compare/the-difference-between-relational-and-non-relational-databases/) +17. Oracle vs. PostgreSQL: Key Differences and Best Use Cases \- EDB, accessed April 9, 2026, [https://www.enterprisedb.com/blog/oracle-vs-postgresql-comparison](https://www.enterprisedb.com/blog/oracle-vs-postgresql-comparison) +18. Need help Explaining a database to complete beginners. Analogies, parallels \- What made it 'click' for you? \- Reddit, accessed April 9, 2026, [https://www.reddit.com/r/Database/comments/buszxh/need\_help\_explaining\_a\_database\_to\_complete/](https://www.reddit.com/r/Database/comments/buszxh/need_help_explaining_a_database_to_complete/) +19. NoSQL Visualization Tools | Visualizing Big Data \- MongoDB, accessed April 9, 2026, [https://www.mongodb.com/resources/basics/databases/nosql-explained/visualizing-nosql](https://www.mongodb.com/resources/basics/databases/nosql-explained/visualizing-nosql) +20. MongoDB Architecture \- GeeksforGeeks, accessed April 9, 2026, [https://www.geeksforgeeks.org/mongodb/mongodb-architecture/](https://www.geeksforgeeks.org/mongodb/mongodb-architecture/) +21. AI Architecture Diagram: Free Neon Effect Prompt (AI Sample 01\) \- ArchiDiagram, accessed April 9, 2026, [https://archidiagram.com/ai-architecture-diagram/](https://archidiagram.com/ai-architecture-diagram/) +22. Database Management System (DBMS) Architecture Explained ..., accessed April 9, 2026, [https://dev.to/quame\_jnr1/database-management-system-dbms-architecture-explained-1ija](https://dev.to/quame_jnr1/database-management-system-dbms-architecture-explained-1ija) +23. Documentation: 18: 1.2. Architectural Fundamentals \- PostgreSQL, accessed April 9, 2026, [https://www.postgresql.org/docs/current/tutorial-arch.html](https://www.postgresql.org/docs/current/tutorial-arch.html) +24. DBMS Architecture: Components and Types of Database Models Explained \- Sprinkle Data, accessed April 9, 2026, [https://www.sprinkledata.com/blogs/dbms-architecture-its-5-key-components-and-types-of-database-models](https://www.sprinkledata.com/blogs/dbms-architecture-its-5-key-components-and-types-of-database-models) +25. The DBMS Architecture In a Nutshell | by Znafryassir \- Medium, accessed April 9, 2026, [https://medium.com/@znafryassir/the-dbms-architecture-in-a-nutshell-0eace923a036](https://medium.com/@znafryassir/the-dbms-architecture-in-a-nutshell-0eace923a036) +26. SQL Server for Beginners \- How Does the Query Optimizer Work?\!? \- YouTube, accessed April 9, 2026, [https://www.youtube.com/watch?v=AqsjuhbCWrU](https://www.youtube.com/watch?v=AqsjuhbCWrU) +27. Structure of Database Management System \- GeeksforGeeks, accessed April 9, 2026, [https://www.geeksforgeeks.org/dbms/structure-of-database-management-system/](https://www.geeksforgeeks.org/dbms/structure-of-database-management-system/) +28. Lesson 3: Components of Database Management Systems (DBMS) | BTU, accessed April 9, 2026, [https://btu.edu.ge/wp-content/uploads/2024/05/Lesson-3\_-Components-of-Database-Management-Systems-DBMS.pdf](https://btu.edu.ge/wp-content/uploads/2024/05/Lesson-3_-Components-of-Database-Management-Systems-DBMS.pdf) +29. PostgreSQL vs Oracle Architecture Comparison | Important Key Differences Explained, accessed April 9, 2026, [https://learnomate.org/postgresql-vs-oracle-architecture-comparison/](https://learnomate.org/postgresql-vs-oracle-architecture-comparison/) +30. Snowflake vs. Oracle vs. PostgreSQL: A Deep Dive into ... \- Medium, accessed April 9, 2026, [https://medium.com/@jramcloud1/snowflake-vs-oracle-vs-postgresql-a-deep-dive-into-architectures-7dd7218f1777](https://medium.com/@jramcloud1/snowflake-vs-oracle-vs-postgresql-a-deep-dive-into-architectures-7dd7218f1777) +31. Oracle vs PostgreSQL: A Definitive Enterprise Database Comparison \- Wonderment Apps, accessed April 9, 2026, [https://www.wondermentapps.com/blog/oracle-vs-postgresql/](https://www.wondermentapps.com/blog/oracle-vs-postgresql/) +32. Oracle Database 19c Technical Architecture, accessed April 9, 2026, [https://www.oracle.com/webfolder/technetwork/tutorials/architecture-diagrams/19/pdf/db-19c-architecture.pdf](https://www.oracle.com/webfolder/technetwork/tutorials/architecture-diagrams/19/pdf/db-19c-architecture.pdf) +33. Oracle Database 21c Technical Architecture, accessed April 9, 2026, [https://www.oracle.com/webfolder/technetwork/tutorials/architecture-diagrams/21/database-technical-architecture.html](https://www.oracle.com/webfolder/technetwork/tutorials/architecture-diagrams/21/database-technical-architecture.html) +34. 17 Process Architecture \- Database \- Oracle Help Center, accessed April 9, 2026, [https://docs.oracle.com/en/database/oracle/oracle-database/21/cncpt/process-architecture.html](https://docs.oracle.com/en/database/oracle/oracle-database/21/cncpt/process-architecture.html) +35. PostgreSQL architecture \- NetApp Docs, accessed April 9, 2026, [https://docs.netapp.com/us-en/ontap-apps-dbs/postgres/postgres-architecture.html](https://docs.netapp.com/us-en/ontap-apps-dbs/postgres/postgres-architecture.html) +36. PostgreSQL Background Processes Explained | Postmaster, Background Writer, WAL Writer, accessed April 9, 2026, [https://learnomate.org/postgresql-background-processes-explained/](https://learnomate.org/postgresql-background-processes-explained/) +37. PostgreSQL Architecture Explained | Yugabyte, accessed April 9, 2026, [https://www.yugabyte.com/postgresql/postgresql-architecture/](https://www.yugabyte.com/postgresql/postgresql-architecture/) +38. PostgreSQL Background Processes: A Simple Guide \- DEV Community, accessed April 9, 2026, [https://dev.to/humzakt/postgresql-background-processes-a-simple-guide-12d5](https://dev.to/humzakt/postgresql-background-processes-a-simple-guide-12d5) +39. What are the levels of "database knowledge" that you achieve throughout your career? : r/cscareerquestions \- Reddit, accessed April 9, 2026, [https://www.reddit.com/r/cscareerquestions/comments/1incuky/what\_are\_the\_levels\_of\_database\_knowledge\_that/](https://www.reddit.com/r/cscareerquestions/comments/1incuky/what_are_the_levels_of_database_knowledge_that/) +40. How to Monitor & Understand PostgreSQL Background Processes \- Cybrosys Technologies, accessed April 9, 2026, [https://www.cybrosys.com/research-and-development/postgres/how-to-monitor-understand-postgresql-background-processes](https://www.cybrosys.com/research-and-development/postgres/how-to-monitor-understand-postgresql-background-processes) +41. Oracle System Architecture Processes \- The Quest Blog, accessed April 9, 2026, [https://blog.quest.com/product-post/oracle-system-architecture-processes/](https://blog.quest.com/product-post/oracle-system-architecture-processes/) +42. Oracle Database Architecture: Mastering Background Processes (DBWn, LGWR, PMON & More) \- YouTube, accessed April 9, 2026, [https://www.youtube.com/watch?v=wzJMkioOo3Y](https://www.youtube.com/watch?v=wzJMkioOo3Y) +43. Oracle Background Processes – A Detailed Guide for DBAs \- Learnomate Technologies, accessed April 9, 2026, [https://learnomate.org/oracle-background-processes/](https://learnomate.org/oracle-background-processes/) +44. F Background Processes \- Database \- Oracle Help Center, accessed April 9, 2026, [https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/background-processes.html](https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/background-processes.html) +45. In-Depth Exploration of PostgreSQL's Process Architecture | by ANKUSH THAVALI | Medium, accessed April 9, 2026, [https://medium.com/@ankush.thavali/in-depth-exploration-of-postgresqls-process-architecture-b9f554cd5313](https://medium.com/@ankush.thavali/in-depth-exploration-of-postgresqls-process-architecture-b9f554cd5313) +46. Oracle transaction model and PostgreSQL transactions \- Oracle to Aurora PostgreSQL Migration Playbook \- AWS Documentation, accessed April 9, 2026, [https://docs.aws.amazon.com/dms/latest/oracle-to-aurora-postgresql-migration-playbook/chap-oracle-aurora-pg.sql.transactions.html](https://docs.aws.amazon.com/dms/latest/oracle-to-aurora-postgresql-migration-playbook/chap-oracle-aurora-pg.sql.transactions.html) +47. Comparing Oracle and PostgreSQL Transaction Systems · Vonng \- Pigsty, accessed April 9, 2026, [https://vonng.com/en/db/oracle-pg-xact/](https://vonng.com/en/db/oracle-pg-xact/) +48. Comparison of the transaction systems of Oracle and PostgreSQL, accessed April 9, 2026, [https://www.cybertec-postgresql.com/en/comparison-of-the-transaction-systems-of-oracle-and-postgresql/](https://www.cybertec-postgresql.com/en/comparison-of-the-transaction-systems-of-oracle-and-postgresql/) +49. PostgreSQL vs. Oracle: Difference in Costs, Ease of Use & Functionality \- Reddit, accessed April 9, 2026, [https://www.reddit.com/r/PostgreSQL/comments/hqnafk/postgresql\_vs\_oracle\_difference\_in\_costs\_ease\_of/](https://www.reddit.com/r/PostgreSQL/comments/hqnafk/postgresql_vs_oracle_difference_in_costs_ease_of/) +50. COMPARING THE ORACLE AND POSTGRESQL TRANSACTION SYSTEMS, accessed April 9, 2026, [https://www.postgresql.eu/events/pgconfde2025/sessions/session/6546/slides/659/xact\_ora\_pg\_m.pdf](https://www.postgresql.eu/events/pgconfde2025/sessions/session/6546/slides/659/xact_ora_pg_m.pdf) +51. Transaction management in PostgreSQL and what is different from Oracle \- Franck Pachot, accessed April 9, 2026, [https://franckpachot.medium.com/transaction-management-in-postgresql-and-what-is-different-from-oracle-eeae34675a77](https://franckpachot.medium.com/transaction-management-in-postgresql-and-what-is-different-from-oracle-eeae34675a77) +52. B-trees and database indexes \- PlanetScale, accessed April 9, 2026, [https://planetscale.com/blog/btrees-and-database-indexes](https://planetscale.com/blog/btrees-and-database-indexes) +53. Understanding B-Tree and Hash Indexing in Databases \- TiDB, accessed April 9, 2026, [https://www.pingcap.com/article/understanding-b-tree-and-hash-indexing-in-databases/](https://www.pingcap.com/article/understanding-b-tree-and-hash-indexing-in-databases/) +54. 12.6. B-Trees — BCS2 Python Data Structures & Algorithms (Python) \- OpenDSA, accessed April 9, 2026, [https://opendsa.cs.vt.edu/ODSA/Books/bghs-stem-code-bcs/bcs2/spring-2020/1/html/BTree.html](https://opendsa.cs.vt.edu/ODSA/Books/bghs-stem-code-bcs/bcs2/spring-2020/1/html/BTree.html) +55. MySQL 9.6 Reference Manual :: 10.3.9 Comparison of B-Tree and Hash Indexes, accessed April 9, 2026, [https://dev.mysql.com/doc/refman/9.6/en/index-btree-hash.html](https://dev.mysql.com/doc/refman/9.6/en/index-btree-hash.html) +56. B Tree in Python \- GeeksforGeeks, accessed April 9, 2026, [https://www.geeksforgeeks.org/dsa/b-tree-in-python/](https://www.geeksforgeeks.org/dsa/b-tree-in-python/) +57. 10 Years Using SQL… and I Finally Learned How Databases Actually Work \- Medium, accessed April 9, 2026, [https://medium.com/@qctran1991/10-years-using-sql-and-i-finally-learned-how-databases-actually-work-c8eb4172535c](https://medium.com/@qctran1991/10-years-using-sql-and-i-finally-learned-how-databases-actually-work-c8eb4172535c) +58. SQL Server query execution plans – Examples with the SELECT statement, accessed April 9, 2026, [https://www.sqlshack.com/sql-server-query-execution-plans-examples-select-statement/](https://www.sqlshack.com/sql-server-query-execution-plans-examples-select-statement/) +59. SQL Query Optimization: Understanding Key Principle : r/programming \- Reddit, accessed April 9, 2026, [https://www.reddit.com/r/programming/comments/nm9ehx/sql\_query\_optimization\_understanding\_key\_principle/](https://www.reddit.com/r/programming/comments/nm9ehx/sql_query_optimization_understanding_key_principle/) +60. Understanding SQL Query Execution Plans: Unveiling the Path to Database Performance, accessed April 9, 2026, [https://divyanshbhatia.medium.com/understanding-sql-query-execution-plans-unveiling-the-path-to-database-performance-ad9aee04b9f7](https://divyanshbhatia.medium.com/understanding-sql-query-execution-plans-unveiling-the-path-to-database-performance-ad9aee04b9f7) +61. MySQL Workbench Manual :: 7.4 Visual Explain Plan, accessed April 9, 2026, [https://dev.mysql.com/doc/workbench/en/wb-performance-explain.html](https://dev.mysql.com/doc/workbench/en/wb-performance-explain.html) +62. Analyze an actual execution plan \- SQL Server \- Microsoft Learn, accessed April 9, 2026, [https://learn.microsoft.com/en-us/sql/relational-databases/performance/analyze-an-actual-execution-plan?view=sql-server-ver17](https://learn.microsoft.com/en-us/sql/relational-databases/performance/analyze-an-actual-execution-plan?view=sql-server-ver17) +63. How to Write Complex SQL Queries: Best Practices & Optimization Tips \- RunSQL, accessed April 9, 2026, [https://runsql.com/blog/posts/2025-03-17-complex-sql-queries-best-practices/](https://runsql.com/blog/posts/2025-03-17-complex-sql-queries-best-practices/) +64. Try These Advanced SQL Join Techniques \- Sigma Computing, accessed April 9, 2026, [https://www.sigmacomputing.com/blog/advanced-sql-joins](https://www.sigmacomputing.com/blog/advanced-sql-joins) +65. Efficient Complex SQL Joins: Best Practices \- DEV Community, accessed April 9, 2026, [https://dev.to/arvind\_toorpu/efficient-complex-sql-joins-best-practices-1phn](https://dev.to/arvind_toorpu/efficient-complex-sql-joins-best-practices-1phn) +66. ACID \- Wikipedia, accessed April 9, 2026, [https://en.wikipedia.org/wiki/ACID](https://en.wikipedia.org/wiki/ACID) +67. What are ACID Transactions? \- Databricks, accessed April 9, 2026, [https://www.databricks.com/blog/what-are-acid-transactions](https://www.databricks.com/blog/what-are-acid-transactions) +68. Demystifying ACID Properties of a Database Transaction to a 10-year-old, accessed April 9, 2026, [https://khelechy.medium.com/demystifying-acid-properties-of-a-database-transaction-to-a-10-year-old-3352d1624f1a](https://khelechy.medium.com/demystifying-acid-properties-of-a-database-transaction-to-a-10-year-old-3352d1624f1a) +69. A Practical Guide to Database Transaction Isolation Levels \- Navicat, accessed April 9, 2026, [https://www.navicat.com/company/aboutus/blog/3558-a-practical-guide-to-database-transaction-isolation-levels](https://www.navicat.com/company/aboutus/blog/3558-a-practical-guide-to-database-transaction-isolation-levels) +70. No Dirty Reads: Everything you always wanted to know about SQL isolation levels (but were too afraid to ask) \- CockroachDB, accessed April 9, 2026, [https://www.cockroachlabs.com/blog/sql-isolation-levels-explained/](https://www.cockroachlabs.com/blog/sql-isolation-levels-explained/) +71. Transaction Isolation \- Demystified\! \- YouTube, accessed April 9, 2026, [https://www.youtube.com/watch?v=7uet6HhNtic](https://www.youtube.com/watch?v=7uet6HhNtic) +72. Transaction Isolation Levels (ODBC) \- ODBC API Reference \- Microsoft Learn, accessed April 9, 2026, [https://learn.microsoft.com/en-us/sql/odbc/reference/develop-app/transaction-isolation-levels?view=sql-server-ver17](https://learn.microsoft.com/en-us/sql/odbc/reference/develop-app/transaction-isolation-levels?view=sql-server-ver17) +73. Understanding Database Isolation Levels from My Perspective | by Hossein Nejati Javaremi, accessed April 9, 2026, [https://hosseinnejati.medium.com/understanding-database-isolation-levels-from-my-perspective-27f261eeb976](https://hosseinnejati.medium.com/understanding-database-isolation-levels-from-my-perspective-27f261eeb976) +74. Database Normalization: 1NF, 2NF, 3NF & BCNF Examples \- DigitalOcean, accessed April 9, 2026, [https://www.digitalocean.com/community/tutorials/database-normalization](https://www.digitalocean.com/community/tutorials/database-normalization) +75. Normalization in Relational Databases: First Normal Form (1NF), Second Normal Form (2NF), and Third Normal Form (3NF) \- Redgate Software, accessed April 9, 2026, [https://www.red-gate.com/blog/normalization-1nf-2nf-3nf/](https://www.red-gate.com/blog/normalization-1nf-2nf-3nf/) +76. Learn Database Normalization \- 1NF, 2NF, 3NF, 4NF, 5NF \- YouTube, accessed April 9, 2026, [https://www.youtube.com/watch?v=GFQaEYEc8\_8](https://www.youtube.com/watch?v=GFQaEYEc8_8) +77. Database Normalization – Normal Forms 1nf 2nf 3nf Table Examples \- freeCodeCamp, accessed April 9, 2026, [https://www.freecodecamp.org/news/database-normalization-1nf-2nf-3nf-table-examples/](https://www.freecodecamp.org/news/database-normalization-1nf-2nf-3nf-table-examples/) +78. A Brief Guide to Database Normalization | by Leah Nguyen \- Medium, accessed April 9, 2026, [https://medium.com/@ndleah/a-brief-guide-to-database-normalization-5ac59f093161](https://medium.com/@ndleah/a-brief-guide-to-database-normalization-5ac59f093161) +79. Database Schema Design Examples, Principles & Best Practices \- Panoply Blog, accessed April 9, 2026, [https://blog.panoply.io/database-schema-design-examples](https://blog.panoply.io/database-schema-design-examples) +80. A comprehensive guide to database skills (plus examples) | Indeed.com UK, accessed April 9, 2026, [https://uk.indeed.com/career-advice/finding-a-job/database-skills](https://uk.indeed.com/career-advice/finding-a-job/database-skills) +81. The Roadmap to Become a Software Architect: OOP → Mastering Abstraction → Design Principles → Design Patterns → Fundamentals of Software Architecture → Quality Attributes (Scalability, Availability, Modifiability, etc.) → Architectural Styles → Architectural Patterns → Distributed Architectures \- Reddit, accessed April 9, 2026, [https://www.reddit.com/r/softwarearchitecture/comments/1k0pj1i/the\_roadmap\_to\_become\_a\_software\_architect\_oop/](https://www.reddit.com/r/softwarearchitecture/comments/1k0pj1i/the_roadmap_to_become_a_software_architect_oop/) +82. From Junior to Senior: A Guide to Software Engineering Levels \- MentorCruise, accessed April 9, 2026, [https://mentorcruise.com/blog/from-junior-to-senior-a-guide-to-software-engineering-levels-b942b/](https://mentorcruise.com/blog/from-junior-to-senior-a-guide-to-software-engineering-levels-b942b/) +83. A Complete Guide to the Data Engineer Career Path (2026) A Complete Guide to the Data Engineer Career Path (2026) \- CCS Learning Academy, accessed April 9, 2026, [https://bootcamp.ccslearningacademy.com/data-engineer-career-path/](https://bootcamp.ccslearningacademy.com/data-engineer-career-path/) +84. Don't be a Junior Developer: The Roadmap From Junior to Senior | Zero To Mastery, accessed April 9, 2026, [https://zerotomastery.io/blog/dont-be-a-junior-developer-the-roadmap/](https://zerotomastery.io/blog/dont-be-a-junior-developer-the-roadmap/) +85. What are the necessary skills and proficiency level required for a data engineer with 4+ years exp : r/dataengineering \- Reddit, accessed April 9, 2026, [https://www.reddit.com/r/dataengineering/comments/1p5ccrg/what\_are\_the\_necessary\_skills\_and\_proficiency/](https://www.reddit.com/r/dataengineering/comments/1p5ccrg/what_are_the_necessary_skills_and_proficiency/) +86. Junior vs. Mid vs. Senior Software Engineers \- DEPT®, accessed April 9, 2026, [https://www.deptagency.com/insight/junior-vs-mid-vs-senior-software-engineers-experience-skills-expectations/](https://www.deptagency.com/insight/junior-vs-mid-vs-senior-software-engineers-experience-skills-expectations/) +87. 11 Steps to Go From Junior to Senior Developer \- ByteByteGo, accessed April 9, 2026, [https://bytebytego.com/guides/11-steps-to-go-from-junior-to-senior-developer/](https://bytebytego.com/guides/11-steps-to-go-from-junior-to-senior-developer/) +88. 5 Important Database Concepts for the Software Engineer, accessed April 9, 2026, [https://www.red-gate.com/blog/database-concepts-for-software-engineer/](https://www.red-gate.com/blog/database-concepts-for-software-engineer/) +89. The 3 Different Levels of Data Engineers | by Dom N \- Medium, accessed April 9, 2026, [https://medium.com/@dom.n/the-3-different-levels-of-data-engineers-1ba6f9bf6ba7](https://medium.com/@dom.n/the-3-different-levels-of-data-engineers-1ba6f9bf6ba7) +90. How to Create a Storyboard Using AI | Leonardo.Ai, accessed April 9, 2026, [https://leonardo.ai/news/storyboard-ai/](https://leonardo.ai/news/storyboard-ai/) +91. System Architecture Diagram Generator \- AI \- Eraser.io, accessed April 9, 2026, [https://www.eraser.io/ai/system-architecture-diagram-generator](https://www.eraser.io/ai/system-architecture-diagram-generator) +92. Build AWS architecture diagrams using Kiro CLI and MCP | Artificial Intelligence, accessed April 9, 2026, [https://aws.amazon.com/blogs/machine-learning/build-aws-architecture-diagrams-using-amazon-q-cli-and-mcp/](https://aws.amazon.com/blogs/machine-learning/build-aws-architecture-diagrams-using-amazon-q-cli-and-mcp/) +93. AI Storyboard Generator Online \- Adobe Firefly, accessed April 9, 2026, [https://www.adobe.com/products/firefly/features/storyboard.html](https://www.adobe.com/products/firefly/features/storyboard.html) +94. Atlas Charts \- MongoDB Docs, accessed April 9, 2026, [https://www.mongodb.com/docs/charts/](https://www.mongodb.com/docs/charts/) + +[image1]: + +[image2]: \ No newline at end of file diff --git a/src/App.tsx b/src/App.tsx index 3d33970..4041346 100644 --- a/src/App.tsx +++ b/src/App.tsx @@ -32,6 +32,7 @@ const NodeJSPage = lazy(() => import('./features/nodejs')); const AuthPage = lazy(() => import('./features/auth')); const DevOpsPage = lazy(() => import('./features/devops')); const BackendPage = lazy(() => import('./features/backend')); +const DatabasePage = lazy(() => import('./features/database')); // Standalone pages (rendered without main app layout) const PlaygroundEntry = lazy(() => import('./features/playground/PlaygroundEntry')); @@ -220,6 +221,14 @@ const App: React.FC = () => { } /> + + + + } + /> diff --git a/src/components/Header.tsx b/src/components/Header.tsx index fcf8fc3..88e16b5 100644 --- a/src/components/Header.tsx +++ b/src/components/Header.tsx @@ -19,6 +19,7 @@ import { Cloud, Shield, Rocket, + HardDrive, } from 'lucide-react'; import { useUI } from '../shared/contexts'; @@ -144,6 +145,12 @@ const Header: React.FC = () => { icon: , description: 'Backend patterns & API design', }, + { + label: 'Database & DBMS', + path: '/database', + icon: , + description: 'Database internals & optimization', + }, ], }, ]; diff --git a/src/components/Sidebar.tsx b/src/components/Sidebar.tsx index 1cb6531..e670b68 100644 --- a/src/components/Sidebar.tsx +++ b/src/components/Sidebar.tsx @@ -91,6 +91,13 @@ const getThemeColorClass = ( buttonHover: 'hover:text-slate-600', border: 'border-slate-100', }, + teal: { + active: 'bg-teal-100 text-teal-800 border-teal-500', + hover: 'hover:bg-teal-50 hover:text-teal-700', + buttonActive: 'text-teal-600 hover:text-teal-700', + buttonHover: 'hover:text-teal-600', + border: 'border-teal-100', + }, }; const colors = colorMap[theme.primary] || colorMap.blue; @@ -401,6 +408,30 @@ const sidebarSections: Record> = { { label: 'Request Lifecycle', path: '/backend?section=Request%20Lifecycle' }, { label: 'Visualization', path: '/backend?section=Visualization' }, ], + '/database': [ + { label: 'Introduction', path: '/database?section=Introduction' }, + { label: 'Database Models', path: '/database?section=Database%20Models' }, + { + label: 'DBMS Architecture', + path: '/database?section=DBMS%20Architecture', + subItems: [ + { label: 'Query Processor', path: '/database?section=Query%20Processor' }, + { label: 'Storage Engine', path: '/database?section=Storage%20Engine' }, + ], + }, + { label: 'SQL Fundamentals', path: '/database?section=SQL%20Fundamentals' }, + { + label: 'Indexing & Optimization', + path: '/database?section=Indexing%20%26%20Optimization', + }, + { label: 'Transactions & ACID', path: '/database?section=Transactions%20%26%20ACID' }, + { label: 'Oracle vs PostgreSQL', path: '/database?section=Oracle%20vs%20PostgreSQL' }, + { + label: 'SQL vs NoSQL vs Vector', + path: '/database?section=SQL%20vs%20NoSQL%20vs%20Vector', + }, + { label: 'Visualization', path: '/database?section=Visualization' }, + ], '/': [], '/about': [], }; diff --git a/src/features/database/DatabasePage.tsx b/src/features/database/DatabasePage.tsx new file mode 100644 index 0000000..9697833 --- /dev/null +++ b/src/features/database/DatabasePage.tsx @@ -0,0 +1,78 @@ +import React, { Suspense } from 'react'; +import { useLocation } from 'react-router-dom'; +import { ErrorBoundary } from '../../shared/components/feedback/ErrorBoundary'; +import { LoadingFallback } from '../../shared/components/feedback/LoadingFallback'; +import { SEO } from '../../shared/components/SEO/SEO'; +import ModuleQuizSection from '../../shared/components/quiz/ModuleQuizSection'; + +// Lazy load section components for better performance +import Introduction from './components/sections/Introduction'; +const DatabaseModels = React.lazy(() => import('./components/sections/DatabaseModels')); +const DBMSArchitecture = React.lazy(() => import('./components/sections/DBMSArchitecture')); +const QueryProcessor = React.lazy(() => import('./components/sections/QueryProcessor')); +const StorageEngine = React.lazy(() => import('./components/sections/StorageEngine')); +const SQLFundamentals = React.lazy(() => import('./components/sections/SQLFundamentals')); +const IndexingOptimization = React.lazy(() => import('./components/sections/IndexingOptimization')); +const TransactionsACID = React.lazy(() => import('./components/sections/TransactionsACID')); +const OracleVsPostgreSQL = React.lazy(() => import('./components/sections/OracleVsPostgreSQL')); +const SQLvsNoSQLvsVector = React.lazy(() => import('./components/sections/SQLvsNoSQLvsVector')); +const Visualization = React.lazy(() => import('./components/sections/Visualization')); +const Quiz = () => ; + +const sectionComponents: Record = { + Introduction, + 'Database Models': DatabaseModels, + 'DBMS Architecture': DBMSArchitecture, + 'Query Processor': QueryProcessor, + 'Storage Engine': StorageEngine, + 'SQL Fundamentals': SQLFundamentals, + 'Indexing & Optimization': IndexingOptimization, + 'Transactions & ACID': TransactionsACID, + 'Oracle vs PostgreSQL': OracleVsPostgreSQL, + 'SQL vs NoSQL vs Vector': SQLvsNoSQLvsVector, + Visualization, + Quiz, +}; + +function useQuery(): URLSearchParams { + return new URLSearchParams(useLocation().search); +} + +const DatabasePage: React.FC = () => { + const query = useQuery(); + const section = query.get('section') || 'Introduction'; + const Component = sectionComponents[section] || Introduction; + + return ( + <> + +
+ + }> + + + +
+ + ); +}; + +export default DatabasePage; diff --git a/src/features/database/components/sections/DBMSArchitecture.tsx b/src/features/database/components/sections/DBMSArchitecture.tsx new file mode 100644 index 0000000..aa4ac98 --- /dev/null +++ b/src/features/database/components/sections/DBMSArchitecture.tsx @@ -0,0 +1,262 @@ +import React from 'react'; +import SectionLayout from '../../../../components/shared/SectionLayout'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import NavigationCard from '../../../../components/shared/NavigationCard'; +import CTASection from '../../../../components/shared/CTASection'; +import { Cpu, Database, HardDrive, Lock, RefreshCw, Shield } from 'lucide-react'; +import QueryProcessor2D from '../visualizations/2d/QueryProcessor2D'; + +const DBMSArchitecture: React.FC = () => { + const navigateToSection = (sectionName: string): void => { + window.location.href = `/database?section=${encodeURIComponent(sectionName)}`; + }; + + const heroContent = ( +
+
+
+ +
+
+

Inside the DBMS: Core Architecture

+

+ Most modern DBMS operate on a client-server architecture. The database cluster stores, + processes, and protects data, while applications send SQL queries over a network. Beneath + the surface, the DBMS is a highly coordinated assembly of specialized components. +

+
+ ); + + const mainContent = ( + <> + {/* Interactive Query Flow Visualization */} + +

SQL Query Lifecycle

+

+ Watch how a SQL query travels through the DBMS — from parsing to optimization to + execution. Click Play to animate the flow. +

+ + + + {/* Two Main Components */} + +

The Two Pillars of a DBMS

+ +
+ {/* Query Processor */} +
+
+
+ +
+

Query Processor

+
+

+ The "brain" of the DBMS — translates human-readable SQL into executable + machine actions. +

+
+
+

1. Parser

+

+ Checks SQL syntax validity and validates against the database schema +

+
+
+

2. Query Optimizer

+

+ Analyzes multiple execution paths and calculates the most efficient route +

+
+
+

3. Execution Engine

+

+ Takes the optimal plan and executes it step-by-step against storage +

+
+
+ +
+ + {/* Storage Engine */} +
+
+
+ +
+

Storage Engine

+
+

+ The physical workhorse where actual data manipulation occurs on disk and in memory. +

+
+
+
+ +

Buffer Manager

+
+

+ Caches frequently accessed data pages in RAM, reducing slow disk reads +

+
+
+
+ +

Lock Manager

+
+

+ Applies locks to prevent concurrent writes from corrupting data +

+
+
+
+ +

Recovery Manager

+
+

+ Uses Write-Ahead Log (WAL) to rebuild state after crashes +

+
+
+ +
+
+ + + {/* Background Processes Table */} + +

+ Background Processes: The Invisible Machinery +

+

+ To maintain database health and ensure durability without blocking active queries, both + Oracle and PostgreSQL deploy autonomous background processes: +

+
+ + + + + + + + + + + {[ + { + fn: 'Disk Writing', + oracle: 'DBWn', + pg: 'BGWriter', + desc: 'Flushes dirty memory pages to physical disk', + }, + { + fn: 'Transaction Log', + oracle: 'LGWR', + pg: 'WAL Writer', + desc: 'Writes transaction logs before data, ensuring durability', + }, + { + fn: 'Checkpoint', + oracle: 'CKPT', + pg: 'Checkpointer', + desc: 'Forces all dirty buffers to disk, limiting crash recovery time', + }, + { + fn: 'Process Cleanup', + oracle: 'PMON', + pg: 'Postmaster', + desc: 'Cleans up failed user processes and their held resources', + }, + { + fn: 'Maintenance', + oracle: 'SMON', + pg: 'Autovacuum', + desc: 'Instance recovery (Oracle) / dead tuple cleanup (PostgreSQL)', + }, + ].map((row, i) => ( + + + + + + + ))} + +
+ Function + + Oracle + + PostgreSQL + + Description +
+ {row.fn} + + {row.oracle} + + {row.pg} + {row.desc}
+
+ + + ); + + const sidebarContent = ( + +

Architecture Components

+
+ navigateToSection('Query Processor')} + /> + navigateToSection('Storage Engine')} + /> + navigateToSection('Oracle vs PostgreSQL')} + /> +
+ + ); + + return ( + <> + + navigateToSection('Indexing & Optimization')} + /> + + ); +}; + +export default DBMSArchitecture; diff --git a/src/features/database/components/sections/DatabaseModels.tsx b/src/features/database/components/sections/DatabaseModels.tsx new file mode 100644 index 0000000..a2006eb --- /dev/null +++ b/src/features/database/components/sections/DatabaseModels.tsx @@ -0,0 +1,288 @@ +import React, { useState } from 'react'; +import SectionLayout from '../../../../components/shared/SectionLayout'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import NavigationCard from '../../../../components/shared/NavigationCard'; +import CTASection from '../../../../components/shared/CTASection'; +import { Database, Server, Cpu, Brain, Search, Layers } from 'lucide-react'; +import DatabaseTaxonomy2D from '../visualizations/2d/DatabaseTaxonomy2D'; + +interface DatabaseModel { + name: string; + type: string; + structure: string; + useCase: string; + scaling: string; + examples: string; + color: string; + icon: React.ReactNode; +} + +const models: DatabaseModel[] = [ + { + name: 'Relational (SQL)', + type: 'Structured', + structure: + 'Tables with predefined schemas, rows and columns, strict relationships via foreign keys', + useCase: 'Financial systems, inventory, transactions requiring strict ACID compliance', + scaling: 'Vertical scaling (adding power to a single server)', + examples: 'PostgreSQL, Oracle, MySQL, SQL Server', + color: 'blue', + icon: , + }, + { + name: 'Document (NoSQL)', + type: 'Semi-structured', + structure: 'JSON/BSON objects with flexible, schema-less design', + useCase: 'Content-heavy apps, e-commerce catalogs, rapid prototyping', + scaling: 'Horizontal scaling (distributing across cluster nodes)', + examples: 'MongoDB, CouchDB, Firestore', + color: 'orange', + icon: , + }, + { + name: 'Key-Value (NoSQL)', + type: 'Simple pairs', + structure: 'Unique identifiers (keys) paired with arbitrary values', + useCase: 'High-speed caching, session management, real-time processing', + scaling: 'Horizontal scaling across distributed systems', + examples: 'Redis, Amazon DynamoDB, Memcached', + color: 'green', + icon: , + }, + { + name: 'Graph (NoSQL)', + type: 'Nodes & Edges', + structure: 'Nodes (entities) connected by edges (relationships)', + useCase: 'Social networks, recommendation engines, fraud detection', + scaling: 'Horizontal + Vertical hybrid', + examples: 'Neo4j, Amazon Neptune, ArangoDB', + color: 'purple', + icon: , + }, + { + name: 'Vector', + type: 'High-dimensional arrays', + structure: 'Mathematical vectors representing semantic meaning', + useCase: 'AI/ML, semantic search, RAG pipelines, recommendation', + scaling: 'Horizontal scaling', + examples: 'Pinecone, Milvus, Weaviate, pgVector', + color: 'rose', + icon: , + }, +]; + +const DatabaseModels: React.FC = () => { + const [selectedModel, setSelectedModel] = useState(0); + + const navigateToSection = (sectionName: string): void => { + window.location.href = `/database?section=${encodeURIComponent(sectionName)}`; + }; + + const heroContent = ( +
+
+
+ +
+
+

The Taxonomy of Database Models

+

+ As data volumes expanded and applications diversified, the rigid structure of early + relational databases proved insufficient for every use case. Explore the five major + paradigms and understand when to choose each one. +

+
+ ); + + const mainContent = ( + <> + {/* Interactive Taxonomy Visualization */} + +

Database Paradigm Comparison

+

+ Click on each database type to explore its architecture and ideal use cases. +

+ + + + {/* Detailed Model Cards */} + +

Database Models Deep Dive

+
+ {models.map((model, index) => ( +
setSelectedModel(index)} + > +
+
+ {model.icon} +
+
+

{model.name}

+
+
+

+ Structure +

+

{model.structure}

+
+
+

+ Best For +

+

{model.useCase}

+
+
+

+ Scaling +

+

{model.scaling}

+
+
+

+ Examples +

+

{model.examples}

+
+
+
+
+
+ ))} +
+ + + {/* MongoDB Architecture Deep Dive */} + +

Deep Dive: MongoDB Architecture

+

+ MongoDB abandons the relational table in favor of Collections containing + BSON (Binary JSON) documents. Its core strength lies in native distribution mechanisms: +

+
+
+

Replica Sets

+

+ A group of MongoDB servers maintaining the exact same dataset. A Primary node handles + all writes; Secondary nodes replicate data and handle reads. Automatic failover + ensures high availability. +

+
+
+

Sharding

+

+ Horizontal scaling by splitting massive datasets into smaller chunks (shards) + distributed across multiple servers based on a "Shard Key". +

+
+
+

Mongos Router

+

+ Client apps connect to a mongos query router, which consults Config Servers to + determine which shard holds the requested data, seamlessly routing the query. +

+
+
+ + + {/* Vector Database Section */} + +

The Rise of Vector Databases

+

+ In the era of AI, machines need to "understand" data based on{' '} + semantic meaning rather than exact keyword matches. Vector databases + convert text, images, and audio into high-dimensional numerical vectors, allowing the + system to find data points that are mathematically "close" to one another. +

+
+
+
+

How It Works

+
    +
  1. Data (text, images) is converted to vectors via embedding models
    2. +
  2. Vectors are stored in high-dimensional index structures (HNSW, IVF)
    3. +
  3. Queries are embedded the same way and compared via cosine similarity
    4. +
  4. The nearest neighbors are returned as semantically similar results
    5. +
+
+
+

Key Use Cases

+
    +
  • + + Retrieval-Augmented Generation (RAG) for LLMs +
    • +
  • + + Semantic search across documents and images +
    • +
  • + + Recommendation engines and personalization +
    • +
  • + + Anomaly detection and fraud prevention +
    • +
+
+
+
+ + + ); + + const sidebarContent = ( + +

Quick Navigation

+
+ navigateToSection('DBMS Architecture')} + /> + navigateToSection('Indexing & Optimization')} + /> + navigateToSection('Transactions & ACID')} + /> +
+ + ); + + return ( + <> + + navigateToSection('DBMS Architecture')} + /> + + ); +}; + +export default DatabaseModels; diff --git a/src/features/database/components/sections/IndexingOptimization.tsx b/src/features/database/components/sections/IndexingOptimization.tsx new file mode 100644 index 0000000..64fa9a2 --- /dev/null +++ b/src/features/database/components/sections/IndexingOptimization.tsx @@ -0,0 +1,213 @@ +import React from 'react'; +import SectionLayout from '../../../../components/shared/SectionLayout'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import NavigationCard from '../../../../components/shared/NavigationCard'; +import CTASection from '../../../../components/shared/CTASection'; +import { Search, Zap, GitBranch } from 'lucide-react'; +import BTreeIndex2D from '../visualizations/2d/BTreeIndex2D'; + +const IndexingOptimization: React.FC = () => { + const navigateToSection = (sectionName: string): void => { + window.location.href = `/database?section=${encodeURIComponent(sectionName)}`; + }; + + const heroContent = ( +
+
+
+ +
+
+

Indexing & Query Optimization

+

+ How can a database query a table with billions of records and return a + result in milliseconds? The answer is indexing — mathematical structures + that transform brute-force searches into logarithmic lookups. +

+
+ ); + + const mainContent = ( + <> + {/* Textbook Index Analogy */} + +

The Textbook Index Analogy

+
+
+
+

❌ Without an Index (Full Table Scan)

+

+ Finding "Transaction Isolation" in a 1,000-page textbook by reading every + page line-by-line. This is catastrophically slow — the #1 cause of poor database + performance. +

+
+
+

✅ With an Index

+

+ Consulting the alphabetical index at the back, finding the exact page number, and + jumping directly to it. Instantaneous. This is how B-Tree indexes work. +

+
+
+
+ + + {/* Interactive B-Tree Visualization */} + +

Interactive B-Tree Index

+

+ Insert values and watch the B-Tree self-balance. Search for values to see the logarithmic + lookup path highlighted. +

+ + + + {/* B-Tree vs Hash */} + +

B-Tree vs Hash Index

+
+
+
+ +

B-Tree Index

+
+

+ A self-balancing hierarchical tree. All leaf nodes exist at the same depth, ensuring + predictable $O(\log n)$ search times. +

+
+
+ ✓ + Range queries (BETWEEN, >, <) +
+
+ ✓ + + Prefix string searches (LIKE 'Pat%') + +
+
+ ✓ + ORDER BY without sorting +
+
+ ✓ + Equality lookups +
+
+
+ Search: $O(\log n)$ — e.g., 1 billion rows → ~30 comparisons +
+
+ +
+
+ +

Hash Index

+
+

+ A deterministic hash function maps keys to bucket locations. Unparalleled for exact + match queries with near-constant time. +

+
+
+ ✓ + Exact match (WHERE id = 1054) +
+
+ ✗ + Range queries (destroys sort order) +
+
+ ✗ + Prefix/wildcard searches +
+
+ ✗ + ORDER BY optimization +
+
+
+ Search: $O(1)$ average — near-instant for exact lookups +
+
+
+ + + {/* Query Optimizer */} + +

The Query Optimizer as GPS

+

+ When you write SQL, you tell the database what data you want — not how + to get it. The Query Optimizer bridges this gap by acting as a GPS routing algorithm: +

+
+
+
🗺️
+

Generate Plans

+

+ Consider all possible routes: full scan, index scan, nested loop join, hash join, + merge join +

+
+
+
📊
+

Estimate Costs

+

+ Calculate I/O cost, CPU cost, memory cost, and network transfer for each plan using + table statistics +

+
+
+
🏆
+

Choose Fastest

+

+ Select the execution plan with the lowest total estimated cost and execute it +

+
+
+ + + ); + + const sidebarContent = ( + +

Related Sections

+
+ navigateToSection('DBMS Architecture')} + /> + navigateToSection('Transactions & ACID')} + /> +
+ + ); + + return ( + <> + + navigateToSection('Transactions & ACID')} + /> + + ); +}; + +export default IndexingOptimization; diff --git a/src/features/database/components/sections/Introduction.tsx b/src/features/database/components/sections/Introduction.tsx new file mode 100644 index 0000000..cffa2fb --- /dev/null +++ b/src/features/database/components/sections/Introduction.tsx @@ -0,0 +1,365 @@ +import React from 'react'; +import SectionLayout from '../../../../components/shared/SectionLayout'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import NavigationCard from '../../../../components/shared/NavigationCard'; +import CTASection from '../../../../components/shared/CTASection'; +import StatsGrid from '../../../../components/shared/StatsGrid'; +import { + HardDrive, + Database, + Search, + Shield, + Zap, + Layers, + GitBranch, + CheckCircle, +} from 'lucide-react'; + +const Introduction: React.FC = () => { + const navigateToSection = (sectionName: string): void => { + const baseUrl = '/database?section='; + const encodedSection = encodeURIComponent(sectionName); + window.location.href = baseUrl + encodedSection; + }; + + const stats = [ + { + value: '7+', + label: 'Interactive Visualizations', + icon: , + }, + { + value: '5', + label: 'Database Paradigms', + icon: , + }, + { + value: '2', + label: 'DBMS Engines Compared', + icon: , + }, + ]; + + const heroContent = ( +
+
+
+ +
+
+

+ Database & DBMS: The Engine Behind Every Application +

+

+ Every application — from global financial networks to mobile social platforms — relies on + the rapid, secure, and reliable storage and retrieval of data. Understand how databases + organize information, how DBMS engines process queries, and why choosing the right data + model is one of the most critical architectural decisions you will ever make. +

+ +
+ + 🗄️ SQL & NoSQL Models + + + ⚙️ DBMS Architecture + + + 🌳 B-Tree Indexing + + + 🔒 ACID Transactions + +
+
+ ); + + const mainContent = ( + <> + +

+ What Are Databases & Why Do They Matter? +

+ +
+
+

+ From Filing Cabinets to Distributed Systems +

+

+ The concept of a database predates digital computing — originating in + physical filing cabinets for health records, tax documents, and demographic data. But + the exponential growth of information demanded a technological evolution. +

+

+ In the 1960s, data was stored on punch cards and flat files — suffering from massive + duplication, sequential-only access, and zero ability to establish relationships. In + 1970, Edgar F. Codd published his revolutionary Relational Model, + organizing data into structured tables with mathematical relationships. This became + the backbone of the internet. +

+

+ As the internet expanded in the 2000s, relational databases faced scaling challenges + with massive unstructured data. This spurred NoSQL databases — and + most recently, Vector databases powering AI and machine learning. +

+
+ +
+

Data vs. Database vs. DBMS

+
+
+
+
+ +
+

Data

+
+

+ Raw, unprocessed facts or values — a number, text, or image. "Cat", + "25", "Black" are data. When correlated: "My cat is 25 + years old and black" becomes information. +

+
+
+
+
+ +
+

Database

+
+

+ An organized, structured collection of data stored electronically. A passive + repository — like a warehouse full of goods — with no innate ability to enforce + security, manage concurrency, or recover from failures. +

+
+
+
+
+ +
+

DBMS

+
+

+ The sophisticated software layer that bridges users and the raw + database. It performs CRUD operations, enforces security, handles backup/recovery, + and processes complex SQL queries — making concurrent access safe and reliable. +

+
+
+
+
+ + {/* Why this matters */} +
+

+ Why Every Developer Needs to Understand Databases +

+
+
+
+ +
+

Query Performance

+

+ Understanding indexing and query plans turns a 30-second query into a 3ms one +

+
+
+
+ +
+

Data Integrity

+

+ ACID transactions prevent data corruption and inconsistency in production systems +

+
+
+
+ +
+

Architecture Decisions

+

+ Choosing SQL vs NoSQL vs Vector determines your system's scalability ceiling +

+
+
+
+ + + {/* Learning Journey */} + +

Your Database Learning Journey

+

+ This module takes you from understanding fundamental database models to mastering DBMS + engine internals, query optimization, and transactional architecture. Each section builds + upon the previous, with interactive visualizations to solidify every concept. +

+ +
+ {[ + { + name: 'Database Models', + description: 'Relational, Document, Key-Value, Graph, and Vector databases compared', + completed: false, + current: true, + }, + { + name: 'DBMS Architecture', + description: 'Query Processor, Storage Engine, Buffer Manager, Lock Manager', + completed: false, + current: false, + }, + { + name: 'SQL Fundamentals', + description: 'CRUD operations, JOINs, subqueries, and set operations', + completed: false, + current: false, + }, + { + name: 'Indexing & Optimization', + description: 'B-Trees, Hash indexes, execution plans, and query tuning', + completed: false, + current: false, + }, + { + name: 'Transactions & ACID', + description: 'Atomicity, Consistency, Isolation, Durability, and MVCC', + completed: false, + current: false, + }, + { + name: 'Oracle vs PostgreSQL', + description: 'Comparative architecture: SGA vs shared buffers, Undo/Redo vs WAL/MVCC', + completed: false, + current: false, + }, + { + name: 'Visualization', + description: 'All interactive database visualizations in one place', + completed: false, + current: false, + }, + ].map((step, index) => ( +
navigateToSection(step.name)} + > +
+ {step.completed ? ( + + ) : ( + {index + 1} + )} +
+
+

+ {step.name} + {step.current && (Start Here)} +

+

{step.description}

+
+
+ ))} +
+ + + ); + + const sidebarContent = ( + <> + +

Module Sections

+
+ } + onClick={() => navigateToSection('Database Models')} + /> + } + onClick={() => navigateToSection('DBMS Architecture')} + /> + } + onClick={() => navigateToSection('SQL Fundamentals')} + /> + } + onClick={() => navigateToSection('Indexing & Optimization')} + /> + } + onClick={() => navigateToSection('Transactions & ACID')} + /> + } + onClick={() => navigateToSection('Oracle vs PostgreSQL')} + /> + } + onClick={() => navigateToSection('Visualization')} + /> +
+ + + ); + + return ( + <> + + navigateToSection('Database Models')} + /> + + ); +}; + +export default Introduction; diff --git a/src/features/database/components/sections/OracleVsPostgreSQL.tsx b/src/features/database/components/sections/OracleVsPostgreSQL.tsx new file mode 100644 index 0000000..afb12a3 --- /dev/null +++ b/src/features/database/components/sections/OracleVsPostgreSQL.tsx @@ -0,0 +1,869 @@ +import React from 'react'; +import SectionLayout from '../../../../components/shared/SectionLayout'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import NavigationCard from '../../../../components/shared/NavigationCard'; +import CTASection from '../../../../components/shared/CTASection'; +import { + GitCompare, + Database, + Cpu, + HardDrive, + RefreshCw, + Server, + Search, + Shield, + TrendingUp, + BarChart3, + Layers, + Zap, +} from 'lucide-react'; +import MVCCComparison2D from '../visualizations/2d/MVCCComparison2D'; + +const OracleVsPostgreSQL: React.FC = () => { + const navigateToSection = (sectionName: string): void => { + window.location.href = `/database?section=${encodeURIComponent(sectionName)}`; + }; + + const heroContent = ( +
+
+
+ +
+
+

Oracle vs PostgreSQL

+

+ Oracle Database and PostgreSQL are two of the most powerful relational engines in the world. + Oracle dominates enterprise with its SGA, UNDO tablespace, and RAC clustering; PostgreSQL + offers a radically different open-source approach with shared buffers, inline MVCC, and + Autovacuum. Understanding both makes you stronger at either. +

+
+
+

1979

+

Oracle first release

+
+
+

1986

+

PostgreSQL (POSTGRES) began

+
+
+

#1

+

DB-Engines RDBMS ranking

+
+
+

#1

+

Most loved DB (Stack Overflow)

+
+
+
+ ); + + const mainContent = ( + <> + {/* Memory Architecture */} + +

+ + Memory Architecture +

+ +
+ {/* Oracle SGA */} +
+

+ + Oracle — System Global Area (SGA) +

+

+ Typically sized at 40–70% of total RAM via SGA_TARGET / MEMORY_TARGET automatic + management +

+
+
+

Database Buffer Cache

+

+ Caches data blocks (default 8 KB) from disk. Uses touch-count based LRU with + separate hot/cold lists. Oracle manages all I/O through SGA — + bypassing the OS page cache via Direct I/O. +

+
+
+

Shared Pool

+

+ Library Cache stores parsed SQL plans (cursor sharing across + sessions reduces hard parses). Data Dictionary Cache stores + metadata. Result Cache (11g+) can cache query results directly. +

+
+
+

Redo Log Buffer

+

+ Circular buffer (default 1–16 MB) for redo entries before LGWR flushes to disk. + Write-ahead logging ensures durability before commit returns. +

+
+
+

PGA (per-process)

+

+ Private memory per server process: SQL Work Areas (sort, hash + join), Session Memory, and Private SQL Area. + Sized via PGA_AGGREGATE_TARGET. +

+
+
+
+ + {/* PostgreSQL */} +
+

+ + PostgreSQL — Shared Memory +

+

+ Typically 25% of RAM for shared_buffers; relies on OS page cache for remainder +

+
+
+

Shared Buffers

+

+ Single shared memory pool caching 8 KB pages. Uses clock-sweep{' '} + eviction (a variant of second-chance LRU). Unlike Oracle, PostgreSQL intentionally{' '} + double-buffers — pages exist in both shared_buffers and the OS page + cache. +

+
+
+

WAL Buffers

+

+ Buffer for Write-Ahead Log entries (default ~64 KB, auto-tuned to 1/32 of + shared_buffers). WAL writer flushes periodically; forced flush at commit. +

+
+
+

+ work_mem & maintenance_work_mem +

+

+ work_mem: per-operation memory for sorts and hash joins (default + 4 MB). A single query with multiple sort/hash nodes uses multiple{' '} + work_mem allocations. maintenance_work_mem: for VACUUM, CREATE + INDEX (default 64 MB). +

+
+
+

+ OS Page Cache (Double Buffering) +

+

+ PostgreSQL relies heavily on the OS page cache as a second-level buffer. On Linux, + effective cache = shared_buffers + free RAM. This is why setting shared_buffers{' '} + {'>'} 40% of RAM often hurts performance. +

+
+
+
+
+ + + {/* Process Model */} + +

+ + Process Model +

+ +
+
+

+ Oracle — Thread-Based (since 12c on Linux) +

+
+

+ Oracle uses a multi-threaded architecture where server processes + share the SGA. On Linux from 12c, Oracle can use threads within a single OS process + (threaded execution mode): +

+
    +
  • + DBWn — Writes dirty blocks from buffer cache to disk +
    • +
  • + LGWR — Writes redo log buffer to redo log files at commit +
    • +
  • + CKPT — Triggers checkpoints; updates datafile headers +
    • +
  • + SMON — System Monitor: crash recovery, space reclamation +
    • +
  • + PMON — Process Monitor: cleans up failed connections +
    • +
  • + ARCn — Archiver: copies filled redo logs (archive mode) +
    • +
  • + MMON — Manageability Monitor: AWR snapshots, alerts +
    • +
  • + CJQ0 — Job Scheduler coordinator +
    • +
+
+

+ Connection capacity: Oracle handles 10,000+ concurrent sessions + natively via Shared Server mode or dedicated server processes. +

+
+
+
+ +
+

PostgreSQL — Process-per-Connection

+
+

+ PostgreSQL forks a dedicated backend process per client connection. + Each backend has its own memory space (~5–10 MB per idle connection): +

+
    +
  • + Postmaster — Main daemon; accepts connections & forks backends +
    • +
  • + Backend — One per connection; handles all SQL for that session +
    • +
  • + WAL Writer — Flushes WAL buffers to disk periodically +
    • +
  • + Background Writer — Writes dirty pages to disk ahead of need +
    • +
  • + Autovacuum Launcher — Spawns workers to vacuum dead tuples +
    • +
  • + Checkpointer — Periodic checkpoint to ensure durability +
    • +
  • + Stats Collector — Gathers table/index usage statistics +
    • +
  • + WAL Sender/Receiver — Handles streaming replication +
    • +
+
+

+ Connection capacity: Default max_connections=100. Production + setups use PgBouncer (transaction pooling) to fan 10,000+ app + connections into ~100 backend processes. +

+
+
+
+
+ + + {/* Query Optimizer Comparison */} + +

+ + Query Optimizer & Execution +

+ +
+
+

Oracle — Cost-Based Optimizer (CBO)

+
+
    +
  • + Optimizer Hints — allows DBA to override plan choices (e.g.,{' '} + /*+ INDEX(t idx1) */) +
    • +
  • + Adaptive Plans (12c+) — starts execution with one plan, can + switch join method mid-query if cardinality estimates are wrong +
    • +
  • + SQL Plan Management — captures and evolves plan baselines over + time to prevent plan regression +
    • +
  • + Parallel Execution — automatically parallelizes large scans, + joins, and DML across multiple server processes +
    • +
  • + Materialized View Rewriting — transparently rewrites queries to + use pre-aggregated materialized views +
    • +
  • + In-Memory Column Store (12c+) — dual-format: row store on disk, + columnar in memory for analytics +
    • +
+
+
+ +
+

+ PostgreSQL — Advanced Open-Source CBO +

+
+
    +
  • + No Hints — by design. PostgreSQL trusts its statistics and cost + model; workarounds via{' '} + SET enable_* GUCs +
    • +
  • + Genetic Query Optimizer (GEQO) — for queries joining 12+ tables, + uses genetic algorithm instead of exhaustive search +
    • +
  • + JIT Compilation (v11+) — LLVM-based just-in-time compilation of + expressions, tuple deforming, and aggregates for CPU-bound queries +
    • +
  • + Parallel Query (v9.6+) — parallel seq scan, hash join, merge + join, and aggregates. Controlled by max_parallel_workers_per_gather +
    • +
  • + Incremental Sort (v13+) — exploits partially sorted input to + avoid full re-sort for ORDER BY with multiple columns +
    • +
  • + Multicolumn Statistics (v10+) — CREATE STATISTICS for correlated + columns to improve cardinality estimates +
    • +
+
+
+
+ +
+

+ + Key Optimizer Difference +

+

+ Oracle's optimizer is more interventionist — DBAs can pin plans, + use hints, and create SQL profiles. PostgreSQL's philosophy is{' '} + "fix the statistics, not the query" — if the plan is wrong, + you update statistics (ANALYZE), add indexes, or adjust cost parameters + (random_page_cost, effective_cache_size) rather than forcing a specific plan. +

+
+ + + {/* Indexing Strategies */} + +

+ + Indexing Strategies +

+ +
+ + + + + + + + + + + {[ + ['B-Tree', '✅', '✅', 'Default; equality & range queries'], + ['Bitmap', '✅', '✅ (runtime only)', 'Low cardinality; AND/OR filters'], + ['Hash', '❌ (deprecated)', '✅', 'Equality-only lookups (no range)'], + ['GiST', '❌', '✅', 'Geometric data, full-text, range types'], + ['GIN', '❌', '✅', 'JSONB, full-text search, arrays'], + ['BRIN', '❌', '✅', 'Very large tables with natural ordering'], + ['SP-GiST', '❌', '✅', 'Partitioned search spaces (quad-trees)'], + ['Function-based', '✅', '✅', 'Index on expression (e.g., LOWER(name))'], + ['Partial Index', '❌', '✅', 'Index only rows matching a WHERE clause'], + ['Covering Index', '✅ (IOT)', '✅ (INCLUDE)', 'Index-only scans; no heap access'], + ['Spatial (R-Tree)', '✅ (Spatial option)', '✅ (PostGIS)', 'Geospatial queries'], + ['Reverse Key', '✅', '❌', 'Avoids right-side B-tree contention for sequences'], + ].map(([type, oracle, pg, use], idx) => ( + + + + + + + ))} + +
+ Index Type + + Oracle + + PostgreSQL + + Use Case +
{type}{oracle}{pg}{use}
+
+

+ PostgreSQL's extensible index API (GiST, GIN, BRIN, SP-GiST) is one of its strongest + technical advantages. Oracle compensates with domain indexes and bitmap star + transformations for data warehousing. +

+ + + {/* MVCC Interactive Comparison */} + +

+ + MVCC: Undo/Redo vs Dead Tuples +

+

+ The most fundamental architectural difference between Oracle and PostgreSQL lies in how + they implement Multi-Version Concurrency Control. Explore both approaches below. +

+ + + {/* MVCC Performance Implications */} +
+
+

Oracle MVCC Trade-offs

+
    +
  • ✅ No table bloat — old versions live in UNDO tablespace
    • +
  • ✅ No vacuum needed — UNDO is automatically reclaimed
    • +
  • ✅ Reads never block writes (and vice versa)
    • +
  • + ⚠️ ORA-01555 "Snapshot too old" if UNDO is reclaimed before long query + finishes +
    • +
  • ⚠️ UNDO tablespace sizing critical for write-heavy workloads
    • +
+
+
+

PostgreSQL MVCC Trade-offs

+
    +
  • ✅ No separate UNDO management — simpler architecture
    • +
  • + ✅ No "snapshot too old" errors (dead tuples persist until vacuumed) +
    • +
  • ✅ Reads never block writes (and vice versa)
    • +
  • ⚠️ Table bloat from dead tuples requires regular Autovacuum
    • +
  • + ⚠️ Transaction ID wraparound requires aggressive freezing (every ~2 billion txns) +
    • +
+
+
+ + + {/* Commit Flow */} + +

+ + Commit Flow Comparison +

+ +
+
+

Oracle Commit

+
    +
  1. + User issues COMMIT +
    2. +
  2. LGWR flushes redo log buffer to redo log files on disk
    3. +
  3. + Commit completes — data blocks may still be dirty in cache +
    4. +
  4. DBWn lazily writes dirty blocks to datafiles later
    5. +
  5. UNDO marks old versions as available for reuse
    6. +
+

+ “Commit is fast because only the redo log needs to hit disk.” +

+
+ +
+

PostgreSQL Commit

+
    +
  1. + User issues COMMIT +
    2. +
  2. WAL Writer flushes WAL buffer to WAL segment files on disk
    3. +
  3. + Commit completes — new tuple version has{' '} + xmax = 0 +
    4. +
  4. Background Writer lazily writes dirty pages to data directory
    5. +
  5. Autovacuum later removes dead tuples and freezes old xids
    6. +
+

+ “Commit is fast because only the WAL needs to hit disk.” +

+
+
+ + + {/* Security Comparison */} + +

+ + Security & Compliance +

+ +
+
+

Oracle Security Model

+
    +
  • + TDE — Transparent Data Encryption (tablespace & column level) +
    • +
  • + Database Vault — prevents DBA from viewing app data +
    • +
  • + Label Security — row-level classification labels (UNCLASSIFIED → + TOP SECRET) +
    • +
  • + Real Application Security — fine-grained access within the DB + engine +
    • +
  • + Audit Vault — centralized audit trail with tamper-proof storage +
    • +
  • + Data Masking — built-in static & dynamic data masking +
    • +
  • EAL4+ Common Criteria certification
    • +
+
+ +
+

PostgreSQL Security Model

+
    +
  • + Row-Level Security (RLS) — CREATE POLICY for row-level access + control +
    • +
  • + Column-level privileges — GRANT SELECT(col) on specific columns +
    • +
  • + pgcrypto — extension for column-level encryption functions +
    • +
  • + SSL/TLS — encrypted client connections (SCRAM-SHA-256 auth) +
    • +
  • + pgAudit — extension for detailed audit logging +
    • +
  • + SELinux integration — sepgsql for mandatory access control +
    • +
  • EAL2+ Common Criteria certification (with external hardening)
    • +
+
+
+ +
+

+ Key difference: Oracle bundles enterprise security features in paid + options (Advanced Security, Database Vault). PostgreSQL achieves comparable security via + extensions and OS integration, but requires more DBA assembly and expertise. +

+
+ + + {/* Scalability & HA */} + +

+ + Scalability & High Availability +

+ +
+
+
+

+ Oracle RAC (Real Application Clusters) +

+

+ Shared-disk architecture: Multiple Oracle instances on different + servers access the same storage (ASM/SAN). All nodes read/write the same + datafiles — coordination via Cache Fusion protocol (interconnect). +

+
    +
  • Active-active clustering (all nodes serve queries)
    • +
  • Automatic failover in seconds
    • +
  • Linear read scalability; write scalability limited by interconnect
    • +
  • Data Guard for disaster recovery (async/sync standby)
    • +
  • GoldenGate for heterogeneous replication
    • +
+
+
+

+ Oracle Sharding (12.2+): Native sharding for horizontal scale. + Supports hash, range, and list sharding with automatic data placement. Distributed + transactions across shards via 2PC. +

+
+
+ +
+
+

PostgreSQL HA Ecosystem

+

+ Shared-nothing architecture: Each node has its own data copy. + Relies on streaming replication and external tooling: +

+
    +
  • + Patroni — HA orchestrator with automatic leader election via + etcd/ZooKeeper +
    • +
  • + Citus — distributed PostgreSQL for horizontal read/write scaling +
    • +
  • + pg_basebackup — built-in streaming replication setup +
    • +
  • + Logical Replication (v10+) — table-level pub/sub replication +
    • +
  • + Synchronous Replication — zero data loss with synchronous_commit +
    • +
+
+
+

+ Read Replicas: PostgreSQL excels at read scaling via streaming + replicas. Hot standby serves read-only queries. Typical setups: 1 primary + N + replicas with PgBouncer load balancing reads. +

+
+
+
+ + + {/* Workload Recommendations */} + +

+ + When to Choose Which? +

+ +
+
+

Choose Oracle When:

+
    +
  • + ● + Multi-petabyte data warehouses with complex analytics +
    • +
  • + ● + Mission-critical systems requiring RAC active-active clustering +
    • +
  • + ● + + Regulatory environments requiring Oracle Database Vault & Label Security + +
    • +
  • + ● + Legacy ERP/CRM systems (SAP, PeopleSoft, E-Business Suite) +
    • +
  • + ● + Need for in-memory columnar + Exadata hardware optimization +
    • +
+
+ +
+

Choose PostgreSQL When:

+
    +
  • + ● + Startups & SaaS with rapid iteration and cost sensitivity +
    • +
  • + ● + + Applications requiring JSONB, full-text search, and geospatial (PostGIS) + +
    • +
  • + ● + Cloud-native environments (AWS RDS/Aurora, Google Cloud SQL, Azure) +
    • +
  • + ● + + Extensibility needs: custom types, operators, index methods, foreign data wrappers + +
    • +
  • + ● + Open-source mandate or vendor lock-in avoidance +
    • +
+
+
+ + + {/* Comprehensive Comparison Table */} + +

Architecture Comparison Matrix

+
+ + + + + + + + + + {[ + [ + 'MVCC Strategy', + 'Undo tablespace (separate storage)', + 'Inline versioning (dead tuples)', + ], + [ + 'Buffer Cache', + 'SGA (direct I/O, bypasses OS cache)', + 'shared_buffers + OS page cache (double buffering)', + ], + [ + 'Write-Ahead Log', + 'Redo Logs (circular, archivable via ARCn)', + 'WAL segments (16 MB files, pg_wal directory)', + ], + [ + 'Process Model', + 'Multi-threaded (threaded execution since 12c)', + 'Process-per-connection (fork + PgBouncer)', + ], + [ + 'Connection Pooling', + 'Built-in Shared Servers / DRCP', + 'External (PgBouncer / Pgpool-II)', + ], + [ + 'Dead Space Cleanup', + 'UNDO auto-managed (no table bloat)', + 'Autovacuum daemon (must tune thresholds)', + ], + [ + 'Clustering', + 'RAC (shared-disk, active-active)', + 'Patroni + Citus (shared-nothing)', + ], + ['Optimizer Hints', '100+ hint types supported', 'Not supported (by design)'], + [ + 'Partitioning', + 'Range, List, Hash, Composite, Interval', + 'Range, List, Hash (declarative since v10)', + ], + [ + 'JSON Support', + 'JSON/BSON with SODA API', + 'JSONB with GIN indexes (binary, indexable)', + ], + [ + 'Full-Text Search', + 'Oracle Text (domain index)', + 'Built-in tsvector/tsquery + GIN/GiST', + ], + [ + 'Max DB Size', + '8 EB (with BIGFILE tablespace)', + 'Unlimited (file system dependent, 32 TB/table)', + ], + [ + 'SQL Standard', + 'Proprietary extensions + SQL:2016', + '170/177 SQL:2023 mandatory features', + ], + [ + 'Replication', + 'Data Guard + GoldenGate', + 'Streaming + Logical + Bidirectional (v16)', + ], + [ + 'License', + 'Commercial ($47,500/processor core)', + 'PostgreSQL License (free, permissive)', + ], + ].map(([aspect, oracle, pg], idx) => ( + + + + + + ))} + +
AspectOracle + PostgreSQL +
{aspect}{oracle}{pg}
+
+ + + ); + + const sidebarContent = ( + +

Related Sections

+
+ navigateToSection('Transactions & ACID')} + /> + navigateToSection('Storage Engine')} + /> + navigateToSection('Query Processor')} + /> + navigateToSection('SQL vs NoSQL vs Vector')} + /> +
+ + ); + + return ( + <> + + navigateToSection('Visualization')} + /> + + ); +}; + +export default OracleVsPostgreSQL; diff --git a/src/features/database/components/sections/QueryProcessor.tsx b/src/features/database/components/sections/QueryProcessor.tsx new file mode 100644 index 0000000..8c1bab4 --- /dev/null +++ b/src/features/database/components/sections/QueryProcessor.tsx @@ -0,0 +1,495 @@ +import React from 'react'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import QueryProcessor2D from '../visualizations/2d/QueryProcessor2D'; +import { Database, Search, Zap, GitMerge, BarChart3, RefreshCw, ArrowDownUp } from 'lucide-react'; + +const QueryProcessor: React.FC = () => { + return ( +
+ +
+
+ +
+

The Query Processor

+
+

+ The Query Processor is the "brain" of the DBMS, responsible for translating + human-readable SQL into executable machine actions. It operates in three critical stages: + parsing, optimization, and execution. The optimizer alone is often the largest and most + complex component in the entire database engine. +

+ + {/* Interactive Pipeline Visualization */} + + +
+ {/* Stage 1: Parser */} +
+
+
+ 1 +
+

Parser & Rewriter

+
+

+ The parser performs lexical analysis (tokenization),{' '} + syntax validation (Is the SQL grammar correct?), and{' '} + semantic analysis (Do the referenced tables and columns exist?). + After parsing, the query rewriter transforms the query: +

+
+
+

Rewrite Rules

+
    +
  • + • View expansion — inline view definitions +
    • +
  • + • Subquery flattening — convert correlated subqueries to joins +
    • +
  • + • Predicate pushdown — push WHERE filters closer to base tables +
    • +
  • + • Constant folding — evaluate constant expressions at parse + time +
    • +
+
+
+

Security Checks

+
    +
  • • Row-level security policy injection (PostgreSQL RLS)
    • +
  • • Virtual Private Database predicate addition (Oracle VPD)
    • +
  • • Column-level privilege verification
    • +
  • • Audit policy trigger insertion
    • +
+
+
+
+
-- Input SQL:
+
+ SELECT name, salary FROM employees WHERE department = 'Engineering'; +
+
-- Parser output: Abstract Syntax Tree
+
+ ✓ Tokenize → ✓ Grammar check → ✓ 'employees' exists → ✓ Columns valid → ✓ + RLS/VPD injected → AST ready +
+
+
+ + {/* Stage 2: Optimizer */} +
+
+
+ 2 +
+

Query Optimizer

+
+

+ The most sophisticated component. For a query joining N tables, there are{' '} + N! possible join orderings — the optimizer must prune this search space + intelligently. It uses dynamic programming for small joins (≤ 12 + tables in PostgreSQL) or genetic algorithms (GEQO) for larger ones. +

+
+
+
+ +

Cost Model Components

+
+
    +
  • + • seq_page_cost = 1.0 (baseline: sequential disk read) +
    • +
  • + • random_page_cost = 4.0 (random I/O ~4× slower) +
    • +
  • + • cpu_tuple_cost = 0.01 (per-row CPU work) +
    • +
  • + • cpu_index_tuple_cost = 0.005 +
    • +
  • + • effective_cache_size (how much data is cached) +
    • +
+
+
+
+ +

Optimization Phases

+
+
    +
  • + 1. Scan path selection — seq scan vs index scan vs bitmap +
    • +
  • + 2. Join ordering — which tables to join first +
    • +
  • + 3. Join method — nested loop, hash, merge +
    • +
  • + 4. Aggregation strategy — sort vs hash vs mixed +
    • +
  • + 5. Parallel plan — workers_planned for parallelism +
    • +
+
+
+
+ + {/* Stage 3: Execution Engine */} +
+
+
+ 3 +
+

Execution Engine

+
+

+ Uses the Volcano / Iterator model: each plan node implements{' '} + Open(),{' '} + Next(),{' '} + Close(). Rows are pulled from + bottom to top of the plan tree. This enables pipelining — most nodes never + materialize full result sets. +

+
+
Execution Plan Tree:
+
+
Project (name, salary)
+
  └─ Filter (dept = 'Engineering')
+
     └─ Index Scan (idx_dept) → 42 rows, 0.8ms
+
+
+
+
+ + + {/* Join Algorithms Deep Dive */} + +

+ + Join Algorithms Explained +

+

+ Joins are the most expensive operations in SQL. Understanding when and why the optimizer + picks each algorithm is critical for performance tuning. +

+ +
+ {/* Nested Loop Join */} +
+

1. Nested Loop Join

+
+
+

+ For each row in the outer table, scan the{' '} + inner table to find matching rows. With an index on the inner + table's join column, each inner lookup is O(log n) instead of O(n). +

+
+
-- Pseudocode:
+
for each row r in outer_table:
+
for each row s in inner_table:
+
if r.key == s.key:
+
emit (r, s)
+
+
+
+

Performance

+
    +
  • + • No index: O(N × M) +
    • +
  • + • With index: O(N × log M) +
    • +
  • + • Best for: Small outer + indexed inner +
    • +
  • + • Memory: Minimal (one row buffer) +
    • +
+
+
+
+ + {/* Hash Join */} +
+

2. Hash Join

+
+
+

+ Build phase: Hash the smaller table's join key into an + in-memory hash table. Probe phase: Scan the larger table and + probe the hash table for matches. Falls back to Grace Hash Join{' '} + (partitioned to disk) if the hash table exceeds work_mem. +

+
+
+ -- Phase 1: Build hash table from smaller table +
+
hash_table = build_hash(smaller_table, key)
+
-- Phase 2: Probe with larger table
+
for each row r in larger_table:
+
matches = hash_table.lookup(r.key)
+
for each match: emit (r, match)
+
+
+
+

Performance

+
    +
  • + • In-memory: O(N + M) +
    • +
  • + • Spill to disk: O(N + M) with extra I/O +
    • +
  • + • Best for: Large equi-joins, no useful index +
    • +
  • + • Memory: work_mem per hash table +
    • +
+
+
+
+ + {/* Merge Join */} +
+

3. Sort-Merge Join

+
+
+

+ Both inputs are sorted on the join key, then merged like a zipper. If inputs are + already sorted (from an index or previous sort), the sort step is free. Excellent + for range join conditions and merge-joinable operators. +

+
+
-- Both sorted on join key:
+
advance(left), advance(right)
+
while left and right not exhausted:
+
if left.key == right.key: emit match
+
+ elif left.key {'<'} right.key: advance(left) +
+
else: advance(right)
+
+
+
+

Performance

+
    +
  • + • Pre-sorted: O(N + M) +
    • +
  • + • Needs sort: O(N log N + M log M) +
    • +
  • + • Best for: Large sorted datasets, range joins +
    • +
  • + • Memory: Minimal (streaming) +
    • +
+
+
+
+
+ + + {/* Cardinality Estimation */} + +

+ + Cardinality Estimation & Statistics +

+

+ The optimizer's effectiveness depends on{' '} + accurate row count estimates. Wrong estimates → wrong join order → + catastrophic performance. PostgreSQL's{' '} + pg_statistic and Oracle's{' '} + USER_TAB_COL_STATISTICS store + these histograms: +

+ +
+
+

Statistics Collected

+
    +
  • + n_distinct — number of unique values in a column +
    • +
  • + most_common_vals — top-N values and their frequencies +
    • +
  • + histogram_bounds — equal-height histogram for range selectivity +
    • +
  • + correlation — physical ordering vs logical ordering (drives index + scan cost) +
    • +
  • + null_frac — fraction of NULL values +
    • +
+
+
+

When Estimates Go Wrong

+
    +
  • + Correlated columns — optimizer assumes independence between + predicates (city='SF' AND state='CA') +
    • +
  • + Stale statistics — table grew 10× since last ANALYZE +
    • +
  • + Skewed data — a few values have millions of rows; others have 1 +
    • +
  • + Complex expressions — optimizer uses flat 0.1% default selectivity +
    • +
  • + Fix: Run ANALYZE, create extended statistics (PG 10+), or SQL + Profiles (Oracle) +
    • +
+
+
+ +
+

+ Pro tip: Compare estimated vs actual rows in{' '} + EXPLAIN (ANALYZE, BUFFERS). If{' '} + rows=1000 but actual rows=1,000,000 — you have a cardinality + estimation problem. Run{' '} + ANALYZE tablename and consider + CREATE STATISTICS for correlated + columns. +

+
+ + + {/* Plan Caching */} + +

+ + Plan Caching & Prepared Statements +

+ +
+
+

Oracle — Library Cache (SGA)

+

+ Oracle aggressively caches parsed SQL in the Library Cache (part of + the Shared Pool in SGA). Identical SQL text → cache hit → skip parsing + optimization. +

+
    +
  • + • Cursor Sharing: EXACT (default), SIMILAR, FORCE +
    • +
  • + • Bind Variable Peeking: optimizer peeks at first bind value to + choose plan +
    • +
  • + • Adaptive Cursor Sharing (11g+): multiple plans for different bind + values +
    • +
  • + • SQL Plan Management: capture plan baselines to prevent regression +
    • +
+
+ +
+

PostgreSQL — Per-Session Cache

+

+ PostgreSQL caches plans per connection in the backend process memory. + No cross-session plan sharing (no global library cache). +

+
    +
  • + • PREPARE / EXECUTE: manual prepared statements +
    • +
  • + • Generic vs Custom Plans: after 5 executions, PG decides whether a + generic plan (parameterized) is close enough to custom plans +
    • +
  • + • plan_cache_mode: force_generic_plan or force_custom_plan GUC +
    • +
  • + • pg_prepared_statements: view active cached plans per session +
    • +
+
+
+ + + {/* EXPLAIN query example */} + +

+ + Reading Execution Plans +

+

+ Use{' '} + + EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) + {' '} + in PostgreSQL or{' '} + EXPLAIN PLAN / DBMS_XPLAN{' '} + in Oracle to see exactly how the optimizer processes your query: +

+
+
EXPLAIN (ANALYZE, BUFFERS)
+
SELECT e.name, d.dept_name
+
+ FROM employees e JOIN departments d ON e.dept_id = d.id +
+
WHERE d.dept_name = 'Engineering';
+
-- Output:
+
+ Hash Join (cost=1.07..24.63 rows=42 width=36) (actual time=0.031..0.158 rows=42) +
+
Hash Cond: (e.dept_id = d.id)
+
Buffers: shared hit=8
+
+ → Seq Scan on employees e (rows=1000) (actual rows=1000) +
+
→ Hash (rows=1 width=4)
+
+ → Index Scan on departments d (rows=1) (actual rows=1) +
+
Filter: (dept_name = 'Engineering')
+
+ Planning Time: 0.12 ms   Execution Time: 0.19 ms +
+
+
+

+ Key metrics to watch: (1) estimated rows vs{' '} + actual rows — large divergence = bad statistics. (2){' '} + Buffers: shared hit vs shared read — reads mean cache misses. (3){' '} + loops — nested loop iterations (multiply actual rows × loops for true row + count). +

+
+ +
+ ); +}; + +export default QueryProcessor; diff --git a/src/features/database/components/sections/SQLFundamentals.tsx b/src/features/database/components/sections/SQLFundamentals.tsx new file mode 100644 index 0000000..87e973f --- /dev/null +++ b/src/features/database/components/sections/SQLFundamentals.tsx @@ -0,0 +1,236 @@ +import React, { useState } from 'react'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import { Code, Database, Plus, Search, Trash2, Edit3 } from 'lucide-react'; + +interface SQLExample { + category: string; + title: string; + description: string; + sql: string; + explanation: string; + icon: React.ReactNode; +} + +const examples: SQLExample[] = [ + { + category: 'CREATE', + title: 'Create Table', + description: 'Define a new table with constraints', + sql: `CREATE TABLE employees ( + id SERIAL PRIMARY KEY, + name VARCHAR(100) NOT NULL, + email VARCHAR(255) UNIQUE, + salary DECIMAL(10,2) CHECK (salary > 0), + dept_id INTEGER REFERENCES departments(id), + hired_at TIMESTAMP DEFAULT NOW() +);`, + explanation: + 'Creates a table with primary key, uniqueness, check constraints, and a foreign key relationship. SERIAL auto-generates IDs.', + icon: , + }, + { + category: 'READ', + title: 'JOIN Query', + description: 'Combine data from multiple tables', + sql: `SELECT e.name, d.name AS department, e.salary +FROM employees e +INNER JOIN departments d ON e.dept_id = d.id +WHERE e.salary > 75000 +ORDER BY e.salary DESC +LIMIT 10;`, + explanation: + 'INNER JOIN combines rows only when matches exist. WHERE filters after the join. ORDER BY sorts descending. LIMIT caps output.', + icon: , + }, + { + category: 'READ', + title: 'Aggregation & Grouping', + description: 'Summarize data with GROUP BY', + sql: `SELECT d.name AS department, + COUNT(*) AS headcount, + AVG(e.salary) AS avg_salary, + MAX(e.salary) AS top_salary +FROM employees e +JOIN departments d ON e.dept_id = d.id +GROUP BY d.name +HAVING COUNT(*) >= 5 +ORDER BY avg_salary DESC;`, + explanation: + 'GROUP BY collapses rows by department. Aggregate functions compute per-group. HAVING filters groups (unlike WHERE which filters rows).', + icon: , + }, + { + category: 'UPDATE', + title: 'Update with Subquery', + description: 'Modify rows using a correlated subquery', + sql: `UPDATE employees +SET salary = salary * 1.10 +WHERE dept_id IN ( + SELECT id FROM departments + WHERE name = 'Engineering' +) +AND hired_at < '2023-01-01';`, + explanation: + 'Gives a 10% raise to Engineering employees hired before 2023. The subquery finds the department ID dynamically.', + icon: , + }, + { + category: 'DELETE', + title: 'Safe Delete with CTE', + description: 'Delete rows using a Common Table Expression', + sql: `WITH inactive AS ( + SELECT id FROM employees + WHERE last_login < NOW() - INTERVAL '2 years' + AND status = 'inactive' +) +DELETE FROM employees +WHERE id IN (SELECT id FROM inactive);`, + explanation: + 'CTEs (WITH) make complex deletes readable and auditable. The query first identifies targets, then deletes. Safer than a direct DELETE with complex WHERE.', + icon: , + }, + { + category: 'READ', + title: 'Window Functions', + description: 'Analytical queries without collapsing rows', + sql: `SELECT name, department, salary, + RANK() OVER ( + PARTITION BY department + ORDER BY salary DESC + ) AS salary_rank, + salary - AVG(salary) OVER ( + PARTITION BY department + ) AS diff_from_avg +FROM employees;`, + explanation: + 'Window functions compute per-row analytics without GROUP BY. PARTITION BY creates windows per department. Each row keeps its identity.', + icon: , + }, +]; + +const SQLFundamentals: React.FC = () => { + const [activeExample, setActiveExample] = useState(0); + const categories = ['All', 'CREATE', 'READ', 'UPDATE', 'DELETE']; + const [activeCategory, setActiveCategory] = useState('All'); + + const filteredExamples = + activeCategory === 'All' ? examples : examples.filter((e) => e.category === activeCategory); + + return ( +
+ +
+
+ +
+
+

SQL Fundamentals

+

The language every database speaks

+
+
+ +

+ SQL (Structured Query Language) is the universal language for interacting with relational + databases. Unlike imperative programming languages, SQL is declarative — + you specify what data you want, not how to get it. The DBMS query + optimizer decides the most efficient execution strategy. +

+ + {/* CRUD Category Tabs */} +
+ {categories.map((cat) => ( + + ))} +
+ + {/* Example Cards */} +
+ {filteredExamples.map((example, idx) => ( +
setActiveExample(idx)} + > +
+
+ {example.icon} +
+
+
+ + {example.category} + +

{example.title}

+
+

{example.description}

+
+
+ + {activeExample === idx && ( +
+
+ 
{example.sql}
+
+
+

+ How it works: {example.explanation} +

+
+
+ )} +
+ ))} +
+ + + {/* SQL vs NoSQL Query Comparison */} + +

SQL vs NoSQL Query Styles

+
+
+

SQL (PostgreSQL)

+
+ 
{`SELECT name, email
+FROM users
+WHERE age > 25
+  AND city = 'NYC'
+ORDER BY name;`}
+
+
+
+

NoSQL (MongoDB)

+
+ 
{`db.users.find(
+  { age: { $gt: 25 }, city: "NYC" },
+  { name: 1, email: 1 }
+).sort({ name: 1 });`}
+
+
+
+

+ SQL uses a standardized, declarative syntax across all relational databases. NoSQL + databases each have their own query APIs — MongoDB uses JSON-like query documents. +

+ +
+ ); +}; + +export default SQLFundamentals; diff --git a/src/features/database/components/sections/SQLvsNoSQLvsVector.tsx b/src/features/database/components/sections/SQLvsNoSQLvsVector.tsx new file mode 100644 index 0000000..0703e57 --- /dev/null +++ b/src/features/database/components/sections/SQLvsNoSQLvsVector.tsx @@ -0,0 +1,743 @@ +import React from 'react'; +import SectionLayout from '../../../../components/shared/SectionLayout'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import NavigationCard from '../../../../components/shared/NavigationCard'; +import CTASection from '../../../../components/shared/CTASection'; +import { + GitCompare, + Database, + FileJson, + Network, + Key, + Columns, + Compass, + Scale, + Zap, + Search, + Brain, + BarChart3, +} from 'lucide-react'; +import SQLvsNoSQL2D from '../visualizations/2d/SQLvsNoSQL2D'; +import VectorDatabase2D from '../visualizations/2d/VectorDatabase2D'; + +const SQLvsNoSQLvsVector: React.FC = () => { + const navigateToSection = (sectionName: string): void => { + window.location.href = `/database?section=${encodeURIComponent(sectionName)}`; + }; + + const heroContent = ( +
+
+
+ +
+
+

SQL vs NoSQL vs Vector Databases

+

+ The database landscape has exploded beyond relational tables. Document stores, graph + databases, key-value caches, wide-column stores, and vector databases each solve + fundamentally different problems. Understanding when to choose which paradigm is + now a core engineering skill. +

+
+
+ +

SQL / Relational

+

Structured data + ACID

+
+
+ +

NoSQL

+

Flexible schemas + scale

+
+
+ +

Vector

+

Similarity search + AI

+
+
+
+ ); + + const mainContent = ( + <> + {/* Interactive Database Type Explorer */} + + + + + {/* SQL / Relational Deep Dive */} + +

+ + SQL / Relational Databases +

+

+ Born from E.F. Codd's 1970 relational model, SQL databases organize data into{' '} + tables with predefined schemas, enforced constraints, and powerful + declarative query capabilities. They remain the foundation of most business-critical + systems. +

+ +
+
+

Core Strengths

+
    +
  • ✅ ACID transactions (atomicity, consistency, isolation, durability)
    • +
  • ✅ Complex JOIN operations across normalized tables
    • +
  • ✅ Declarative SQL — optimizer finds the best execution plan
    • +
  • ✅ Schema enforcement prevents data corruption
    • +
  • ✅ Mature ecosystem: 50+ years of optimization, tooling, expertise
    • +
+
+
+

Trade-offs

+
    +
  • ⚠️ Rigid schema — ALTER TABLE can be expensive on large tables
    • +
  • ⚠️ Vertical scaling limit — single-node write bottleneck
    • +
  • ⚠️ Object-relational impedance mismatch (ORM complexity)
    • +
  • ⚠️ Horizontal sharding requires application-level logic
    • +
+
+
+

Major Players

+
    +
  • + PostgreSQL — extensible, JSONB, GIS, 170/177 SQL:2023 features +
    • +
  • + Oracle — enterprise RAC, In-Memory, Exadata +
    • +
  • + MySQL — web scale, InnoDB, ubiquitous hosting +
    • +
  • + SQL Server — .NET ecosystem, columnstore indexes +
    • +
  • + SQLite — embedded, serverless, 1 trillion+ deployments +
    • +
+
+
+ + + {/* NoSQL Categories */} + +

+ + NoSQL Database Categories +

+

+ “NoSQL” (Not Only SQL) emerged from the need to handle massive write volumes, + flexible schemas, and horizontal scaling that traditional RDBMS struggled with. The term + covers four distinct families, each with different data models: +

+ +
+ {/* Document */} +
+
+ +

Document Stores

+
+
+
+

+ Store data as JSON/BSON documents — self-describing, schema-free + objects that can be nested arbitrarily deep. Each document can have different + fields. +

+

+ Examples: MongoDB (~35% market share of NoSQL), CouchDB, Amazon + DocumentDB, Firestore, Couchbase +

+
+
+
// MongoDB document
+
{'{'}
+
+ "_id": ObjectId("..."), +
+
"name": "Alice",
+
+ "skills": ["React", "TS"], +
+
+ "address": {'{'} "city": "SF" {'}'} +
+
{'}'}
+
+
+
+ + {/* Key-Value */} +
+
+ +

Key-Value Stores

+
+
+
+

+ The simplest NoSQL model: a hash map at scale. Every entry is a + key-value pair. The database treats the value as an opaque blob — no schema, no + querying inside values. +

+

+ Examples: Redis (6M+ instances), Amazon DynamoDB, Memcached, + etcd, Riak +

+
+
+

Performance characteristics:

+
    +
  • + • Redis: ~100K ops/sec single-thread; sub-millisecond latency +
    • +
  • + • DynamoDB: single-digit ms consistency with auto-scaling +
    • +
  • • Ideal for caching (TTL expiry), session stores, rate limiting
    • +
  • • No joins, no aggregations — pure key-based access
    • +
+
+
+
+ + {/* Graph */} +
+
+ +

Graph Databases

+
+
+
+

+ Model data as nodes, edges, and properties. Use{' '} + index-free adjacency — each node directly references its + neighbors, making traversals O(1) per hop regardless of total graph size. +

+

+ Examples: Neo4j (#1 graph DB), Amazon Neptune, JanusGraph, + ArangoDB, TigerGraph +

+
+
+

Power of graph queries:

+
+
// Cypher: Find friends-of-friends
+
MATCH (a:Person)-[:FRIENDS]->
+
(b:Person)-[:FRIENDS]->(c:Person)
+
WHERE a.name = 'Alice'
+
RETURN c.name
+
+

+ This 2-hop traversal in SQL would require 2 self-joins — exponentially slower as + depth increases. +

+
+
+
+ + {/* Wide-Column */} +
+
+ +

Wide-Column Stores

+
+
+
+

+ Inspired by Google's Bigtable paper (2006). Data organized into{' '} + row keys → column families → columns. Each row can have different + columns (sparse). Designed for petabyte-scale write throughput. +

+

+ Examples: Apache Cassandra, HBase, ScyllaDB, Google Cloud + Bigtable +

+
+
+

Scale numbers (Cassandra):

+
    +
  • • Apple: 75,000 Cassandra nodes, 10 PB+ data
    • +
  • • Netflix: thousands of nodes for personalization
    • +
  • • Linear write scaling: add nodes = add throughput
    • +
  • • Tunable consistency: ONE → QUORUM → ALL per query
    • +
+
+
+
+
+ + + {/* CAP Theorem */} + +

+ + CAP Theorem & Consistency Models +

+

+ In a distributed system, you can only guarantee two out of three: + Consistency, Availability, and Partition tolerance. Since network partitions are + inevitable, the real choice is between CP (consistency over availability) + and AP (availability over consistency). +

+ +
+
+

CP Systems

+

+ Sacrifice availability during partitions to maintain consistency. +

+
+ {['PostgreSQL', 'MongoDB', 'HBase', 'Redis Cluster', 'etcd'].map((db) => ( + + {db} + + ))} +
+
+
+

AP Systems

+

+ Sacrifice consistency during partitions to remain available. +

+
+ {['Cassandra', 'DynamoDB', 'CouchDB', 'Riak', 'Voldemort'].map((db) => ( + + {db} + + ))} +
+
+
+

Tunable

+

+ Let you choose consistency level per operation. +

+
+ {['Cassandra (CL)', 'DynamoDB', 'Cosmos DB', 'YugabyteDB'].map((db) => ( + + {db} + + ))} +
+
+
+ + + {/* Vector Databases */} + +

+ + Vector Databases — The AI Era +

+

+ Vector databases store and efficiently search{' '} + high-dimensional embedding vectors (typically 256–2048 dimensions) + produced by AI models. Instead of exact matching (WHERE name = 'Alice'), they + find the most similar items using distance metrics like cosine + similarity, Euclidean distance, or dot product. +

+ + {/* Interactive Vector Visualization */} + + + + {/* Vector DB Architecture */} + +

+ + Vector Database Architecture +

+ +
+
+

ANN Search Algorithms

+
+
+

+ HNSW (Hierarchical Navigable Small World) +

+

+ Multi-layer graph structure. Top layers have few nodes with long-range links (for + fast navigation); bottom layers have all nodes with short-range links (for + precision). O(log N) query time. Memory-intensive but highest + recall/speed trade-off. Used by: Pinecone, pgvector, Qdrant, Weaviate. +

+
+
+

IVF (Inverted File Index)

+

+ K-means clustering of vectors into partitions (Voronoi cells). At query time, + search only the nearest nprobe partitions instead of all vectors. + O(N/k) per query. Used by: FAISS, Milvus. +

+
+
+

Product Quantization (PQ)

+

+ Compresses vectors by splitting them into sub-vectors and quantizing each to a + codebook entry. Reduces memory 10–100× with ~5% recall loss. Often combined with + IVF as IVF-PQ — the workhorse of billion-scale systems. +

+
+
+

+ LSH (Locality-Sensitive Hashing) +

+

+ Random projections that hash similar vectors into the same bucket with high + probability. Sub-linear query time. Loss of accuracy for high-dimensional data. + Used for deduplication and near-duplicate detection. +

+
+
+
+ +
+

Similarity Measures

+
+
+

Cosine Similarity

+

+ Measures the angle between vectors (direction, not magnitude). Range: [-1, 1]. + Most popular for text embeddings.{' '} + cos(A, B) = A·B / (|A|×|B|) +

+
+
+

Euclidean Distance (L2)

+

+ Straight-line distance in vector space. Sensitive to magnitude. Best for image + embeddings where scale matters. +

+
+
+

Dot Product (Inner Product)

+

+ Measures both direction and magnitude. Efficient to compute. Used when vectors are + normalized (equivalent to cosine similarity on unit vectors). +

+
+
+ +

Major Vector Databases

+
+ {[ + { + name: 'Pinecone', + desc: 'Fully managed serverless; auto-scales; metadata filtering', + }, + { name: 'pgvector', desc: 'PostgreSQL extension — vector search + SQL in one DB' }, + { name: 'Weaviate', desc: 'Open-source; built-in ML models for auto-embedding' }, + { name: 'Qdrant', desc: 'Rust-based; high performance; rich filtering' }, + { name: 'Milvus', desc: 'Open-source; FAISS/HNSW; billion-scale; GPU support' }, + { name: 'Chroma', desc: 'Lightweight; designed for LLM app prototyping' }, + ].map((db) => ( +
+

+ {db.name} + — {db.desc} +

+
+ ))} +
+
+
+ + + {/* RAG Architecture */} + +

+ + RAG: Vector DBs + LLMs +

+

+ Retrieval-Augmented Generation (RAG) is the primary use case driving + vector database adoption. Instead of fine-tuning an LLM on your data, you store your + documents as embeddings and retrieve relevant context at query time: +

+ +
+
+ {[ + { step: '1', label: 'User Query', desc: '"How does MVCC work?"', color: 'violet' }, + { step: '2', label: 'Embed Query', desc: 'text → 1536-dim vector', color: 'blue' }, + { step: '3', label: 'Vector Search', desc: 'k-NN in vector DB', color: 'teal' }, + { + step: '4', + label: 'Retrieve Docs', + desc: 'Top-K relevant chunks', + color: 'emerald', + }, + { + step: '5', + label: 'LLM + Context', + desc: 'Generate grounded answer', + color: 'amber', + }, + ].map((s, i) => ( + + {i > 0 && →} +
+
Step {s.step}
+
{s.label}
+
{s.desc}
+
+ + ))} +
+
+ + + {/* Comprehensive Comparison Table */} + +

+ + Head-to-Head Comparison +

+ +
+ + + + + + + + + + + + + + {[ + [ + 'Data Model', + 'Tables (rows/cols)', + 'JSON documents', + 'Key→Value', + 'Nodes + Edges', + 'Sparse columns', + 'High-dim vectors', + ], + [ + 'Schema', + 'Strict (enforced)', + 'Flexible', + 'Schema-free', + 'Flexible', + 'Column families', + 'Fixed dimensions', + ], + [ + 'Query Language', + 'SQL', + 'MQL / N1QL', + 'GET/SET API', + 'Cypher/Gremlin', + 'CQL', + 'ANN + filters', + ], + [ + 'Primary Op', + 'Complex JOIN', + 'Doc CRUD', + 'Key lookup', + 'Traversal', + 'Range scan', + 'Similarity search', + ], + [ + 'Consistency', + 'Strong (ACID)', + 'Tunable', + 'Eventual', + 'Strong', + 'Tunable', + 'Eventual', + ], + [ + 'Scaling', + 'Vertical + replicas', + 'Horizontal', + 'Horizontal', + 'Vertical++', + 'Massive horizontal', + 'Horizontal', + ], + ['Latency', '1–100ms', '1–10ms', '<1ms', '1–50ms', '1–10ms', '5–100ms'], + [ + 'Best Workload', + 'OLTP / OLAP', + 'Content mgmt', + 'Caching', + 'Relationships', + 'Time-series/IoT', + 'AI/ML search', + ], + ].map(([feature, ...values], idx) => ( + + + {values.map((val, vi) => ( + + ))} + + ))} + +
+ Feature + + SQL (RDBMS) + + Document + + Key-Value + + Graph + + Wide-Column + + Vector +
{feature} + {val} +
+
+ + + {/* Decision Framework */} + +

+ + Decision Framework +

+

+ Most production systems use polyglot persistence — multiple databases for + different needs. Here's how to choose: +

+ +
+ {[ + { + question: 'Need ACID transactions with complex joins?', + answer: 'SQL (PostgreSQL, Oracle, MySQL)', + color: 'blue', + }, + { + question: 'Flexible schemas with nested objects & rapid iteration?', + answer: 'Document Store (MongoDB, Firestore)', + color: 'emerald', + }, + { + question: 'Sub-millisecond key lookups at massive scale?', + answer: 'Key-Value (Redis, DynamoDB)', + color: 'purple', + }, + { + question: 'Relationship traversals (friends-of-friends, recommendations)?', + answer: 'Graph DB (Neo4j, Neptune)', + color: 'orange', + }, + { + question: 'Massive write throughput for time-series or events?', + answer: 'Wide-Column (Cassandra, ScyllaDB)', + color: 'teal', + }, + { + question: 'Semantic search, RAG, or AI-powered recommendations?', + answer: 'Vector DB (Pinecone, pgvector, Weaviate)', + color: 'violet', + }, + { + question: 'Need SQL + vector search in one database?', + answer: 'PostgreSQL + pgvector (converged approach)', + color: 'indigo', + }, + ].map((item, idx) => ( +
+ ? +
+

{item.question}

+

+ → {item.answer} +

+
+
+ ))} +
+ + + ); + + const sidebarContent = ( + +

Related Sections

+
+ navigateToSection('Database Models')} + /> + navigateToSection('Oracle vs PostgreSQL')} + /> + navigateToSection('Indexing & Optimization')} + /> + navigateToSection('Transactions & ACID')} + /> +
+ + ); + + return ( + <> + + navigateToSection('Visualization')} + /> + + ); +}; + +export default SQLvsNoSQLvsVector; diff --git a/src/features/database/components/sections/StorageEngine.tsx b/src/features/database/components/sections/StorageEngine.tsx new file mode 100644 index 0000000..4c2631c --- /dev/null +++ b/src/features/database/components/sections/StorageEngine.tsx @@ -0,0 +1,478 @@ +import React from 'react'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import { + HardDrive, + RefreshCw, + Lock, + Shield, + Database, + AlertTriangle, + Layers, + FileText, +} from 'lucide-react'; +import BufferManager2D from '../visualizations/2d/BufferManager2D'; + +const StorageEngine: React.FC = () => { + return ( +
+ +
+
+ +
+

The Storage Engine

+
+

+ The Storage Engine is the physical workhorse of the DBMS. It manages how data is organized + on disk, cached in memory, locked for concurrent access, and recovered after failures. + Understanding these mechanics is critical for performance tuning. +

+ + + {/* Page Format */} + +

+ + Data Page Format +

+

+ Databases read and write data in fixed-size pages (typically 8 KB). + Understanding the page layout explains why some operations are fast and others cause + expensive page splits. +

+ +
+ {/* Page diagram */} +
+
+ Page Header (24 bytes) — LSN, checksum, free space pointers, flags +
+
+ Item Pointers (Line Pointers) — array of (offset, length) pairs + pointing to tuples +
+
+ ↕ Free Space ↕ +
+
+ Tuple Data — actual row data, grows backwards from end of page +
+
+ Special Space (B-tree: sibling pointers; Heap: unused) +
+
+

+ Item pointers grow forward; tuples grow backward. When they meet → page is full. + PostgreSQL uses HOT (Heap-Only Tuples) for updates that don't change indexed + columns — avoiding index chain updates. +

+
+ + + {/* Buffer Manager Visualization */} + +

+ + Buffer Manager (Cache) +

+

+ Disk I/O is the slowest operation in computing (~10ms for HDD, ~0.1ms for SSD). The Buffer + Manager caches frequently accessed data pages in RAM. A cache hit serves + data in ~100ns — that's 1,000× faster than SSD and 100,000× faster than HDD. +

+ + +
+
+

Eviction Policies

+
    +
  • + LRU (Oracle): Touch-count based. Frequently accessed blocks stay in + the hot end; cold blocks evicted first. +
    • +
  • + Clock-Sweep (PostgreSQL): Circular scan with usage counters. On + sweep, decrement counter; evict pages with counter=0. Efficient O(1) amortized. +
    • +
  • + Ring Buffer (PG): Large sequential scans use a small ring buffer to + avoid polluting shared buffers with one-time data. +
    • +
+
+
+

Write Strategies

+
    +
  • + Write-Back: Dirty pages stay in cache; written to disk lazily by + background writer. Maximizes cache utilization. +
    • +
  • + Checkpoint: Periodic flush of all dirty pages to disk. Creates a + recovery point. PostgreSQL: checkpoint_timeout (default 5 min). +
    • +
  • + Direct I/O (Oracle): Oracle bypasses the OS page cache entirely, + managing all caching in SGA for full control. +
    • +
+
+
+ + + {/* Storage Components */} + +

Access Methods

+
+
+

+ + Heap Files +

+

+ Rows stored in insertion order across 8 KB pages. No inherent ordering. +

+
    +
  • + • Sequential Scan: Read every page. O(N). Best for large fractions + of a table. +
    • +
  • + • Bitmap Scan: Build a bitmap of qualifying pages from an index, + then fetch pages in physical order — minimizes random I/O. +
    • +
+
+ +
+

+ + B-Tree Indexes +

+

+ Balanced tree with sorted keys. O(log N) lookup. Each leaf page links to next for + efficient range scans. +

+
    +
  • + • Fill Factor: Leave space (default 90%) for future inserts to + avoid page splits. +
    • +
  • + • Deduplication (PG 13+): Store duplicate keys once with a posting + list of TIDs. +
    • +
+
+ +
+

+ + LSM Trees +

+

+ Log-Structured Merge Trees. Optimized for write-heavy workloads. Used by RocksDB, + Cassandra, LevelDB. +

+
    +
  • + • Memtable: In-memory sorted buffer. When full, flushed to disk as + an SSTable. +
    • +
  • + • Compaction: Background merge of SSTables to reclaim space and + maintain read performance. +
    • +
+
+
+ + + {/* Concurrency Control Deep Dive */} + +

+ + Concurrency Control Mechanisms +

+ +
+ {/* 2PL */} +
+

Two-Phase Locking (2PL)

+

+ The classic approach guaranteeing serializability. Has two strict phases: +

+
+
+

Growing Phase

+

+ Transaction acquires all locks it needs. Can acquire new locks but + cannot release any. +

+
+
+

Shrinking Phase

+

+ Transaction releases locks. Can release but{' '} + cannot acquire new ones. In Strict 2PL (used by + most DBMS), all locks held until commit. +

+
+
+

+ Strict 2PL prevents cascading aborts but reduces concurrency. That's why modern + DBMS prefer MVCC for reads and 2PL only for writes. +

+
+ + {/* MVCC */} +
+

+ MVCC (Multi-Version Concurrency Control) +

+

+ Readers never block writers; writers never block readers. Each + transaction sees a consistent snapshot of the database as of its start time. +

+
+
+

Oracle Approach

+

+ Old row versions stored in UNDO tablespace. Current version + in-place in the data block. Reads reconstruct old versions from UNDO chain if + needed. +

+
+
+

PostgreSQL Approach

+

+ Old and new versions both live in the heap page. Each tuple has + xmin (creating txn) and xmax (deleting txn). Visibility check: xmin committed + && xmax not committed. +

+
+
+
+ + {/* Optimistic */} +
+

Optimistic Concurrency Control (OCC)

+

+ No locks during operation — validate at commit. Three phases: Read{' '} + (work on private copies), Validate (check for conflicts),{' '} + Write (if valid, apply changes). +

+

+ Best for low-contention workloads (mostly reads). Used by Hekaton (SQL Server + In-Memory), and application-level patterns (HTTP ETags, compare-and-swap). +

+
+
+ + + {/* Lock Manager */} + +

+ + Lock Manager & Deadlock Detection +

+ +
+
+

Lock Hierarchy

+
+ {[ + { level: 'Database', desc: 'Prevents DROP DATABASE during use', color: 'red' }, + { + level: 'Table', + desc: 'ACCESS SHARE, ROW EXCLUSIVE, etc. (8 levels in PG)', + color: 'orange', + }, + { + level: 'Page', + desc: 'SQL Server uses page locks; PG/Oracle skip this level', + color: 'amber', + }, + { + level: 'Row', + desc: 'Most common — xmax marker in PG, TX lock entry in Oracle', + color: 'yellow', + }, + ].map((lock, idx) => ( +
+

{lock.level} Lock

+

{lock.desc}

+
+ ))} +
+
+ +
+

Lock Compatibility Matrix

+
+ + + + + + + + + + + + + + + + + + + + +
Request ↓ / Hold →S (Shared)X (Exclusive)
S (Shared) + ✅ Compatible + ❌ Blocked
X (Exclusive)❌ Blocked❌ Blocked
+
+ +
+

+ + Deadlock Detection +

+

+ A deadlock occurs when two transactions each hold a lock the other needs: +

+
+
T1: holds lock on row A, waits for row B
+
T2: holds lock on row B, waits for row A
+
→ Circular wait = DEADLOCK
+
+

+ PostgreSQL: Builds a wait-for graph; aborts the youngest + transaction (deadlock_timeout = 1s default). +
+ Oracle: Detects immediately; rolls back the statement (not the + transaction) and raises ORA-00060. +

+
+
+
+ + + {/* Recovery Manager + ARIES */} + +

+ + Recovery Manager & ARIES Protocol +

+

+ The Write-Ahead Log (WAL) is the foundation of crash recovery. Every + change is logged before being applied to data pages. The ARIES{' '} + (Algorithm for Recovery and Isolation Exploiting Semantics) protocol, invented at IBM + Research, defines how modern databases recover: +

+ +
+ {/* WAL Basics */} +
+

WAL (Write-Ahead Logging)

+
+
+

+ Three Rules: +

+
    +
  1. + Log record written before data page change +
    2. +
  2. + All log records for a transaction flushed to disk{' '} + before commit returns +
    3. +
  3. Data pages can be written lazily (no-force policy)
    4. +
+
+
+

+ Log Record Contents: +

+
    +
  • + • LSN — Log Sequence Number (monotonically increasing) +
    • +
  • + • Transaction ID — which transaction made this change +
    • +
  • + • Page ID — which page was modified +
    • +
  • + • Before-image — old data (for UNDO) +
    • +
  • + • After-image — new data (for REDO) +
    • +
+
+
+
+ + {/* ARIES Three Phases */} +
+
+

Phase 1: Analysis

+

+ Scan the log forward from the last checkpoint. Rebuild the{' '} + Dirty Page Table (which pages had uncommitted changes) and the{' '} + Active Transaction Table (which transactions were in-flight). +

+
+
+

Phase 2: REDO

+

+ Replay all logged changes (committed and uncommitted) from the + oldest dirty page's recLSN forward. Restores the exact state at the time of the + crash. “Repeating history.” +

+
+
+

Phase 3: UNDO

+

+ Roll back all changes from uncommitted transactions by applying + before-images in reverse order. Writes CLR (Compensation Log + Records) to make UNDO idempotent — safe to crash during recovery. +

+
+
+
+ +
+

PostgreSQL WAL Specifics

+
    +
  • + • WAL segments are 16 MB files in{' '} + pg_wal/ directory +
    • +
  • + • wal_level: minimal, replica + (default), logical +
    • +
  • + • Archived WAL + base backup = Point-in-Time Recovery (PITR) to any LSN or timestamp +
    • +
  • + • pg_waldump utility to inspect WAL + contents +
    • +
+
+ +
+ ); +}; + +export default StorageEngine; diff --git a/src/features/database/components/sections/TransactionsACID.tsx b/src/features/database/components/sections/TransactionsACID.tsx new file mode 100644 index 0000000..e5fa6bc --- /dev/null +++ b/src/features/database/components/sections/TransactionsACID.tsx @@ -0,0 +1,237 @@ +import React from 'react'; +import SectionLayout from '../../../../components/shared/SectionLayout'; +import ThemeCard from '../../../../components/shared/ThemeCard'; +import NavigationCard from '../../../../components/shared/NavigationCard'; +import CTASection from '../../../../components/shared/CTASection'; +import { Shield, Lock, RefreshCw, CheckCircle } from 'lucide-react'; +import TransactionACID2D from '../visualizations/2d/TransactionACID2D'; + +const TransactionsACID: React.FC = () => { + const navigateToSection = (sectionName: string): void => { + window.location.href = `/database?section=${encodeURIComponent(sectionName)}`; + }; + + const heroContent = ( +
+
+
+ +
+
+

Transactions & ACID Properties

+

+ A transaction is a combination of read/write operations that the DBMS treats as a single + atomic unit. ACID properties provide strict engineering guarantees to prevent data loss, + corruption, and inconsistency — even when thousands of users modify data simultaneously. +

+
+ ); + + const mainContent = ( + <> + {/* ACID Properties */} + +

The Four ACID Guarantees

+
+
+
+
+ A +
+

Atomicity

+
+

+ All or Nothing. Either every operation in the transaction completes + successfully, or none of them take effect. If a bank transfer debits $100 from Account + A but crashes before crediting Account B, the entire transaction rolls back. +

+
+ BEGIN → Debit A (-$100) → Credit B (+$100) → COMMIT ✓ +
+ BEGIN → Debit A (-$100) → ⚡ CRASH → ROLLBACK (A restored) +
+
+ +
+
+
+ C +
+

Consistency

+
+

+ Rules Always Hold. The database moves from one valid state to + another. All constraints (primary keys, foreign keys, check constraints) are satisfied + before and after every transaction. +

+
+ Before: Total balance = $1000 +
+ Transfer $100: A=$400, B=$600 +
+ After: Total balance = $1000 ✓ +
+
+ +
+
+
+ I +
+

Isolation

+
+

+ Transactions Don't Interfere. Concurrent transactions execute as + if they were the only one running. The isolation level (Read Committed, Repeatable + Read, Serializable) determines how strictly this is enforced. +

+
+ Tx1: reads balance=$500 +
+ Tx2: updates balance=$400 (hidden from Tx1) +
+ Tx1: still sees $500 until it commits +
+
+ +
+
+
+ D +
+

Durability

+
+

+ Committed = Permanent. Once a transaction commits, the changes + survive any subsequent failure — power outage, disk crash, or kernel panic. The + Write-Ahead Log (WAL) guarantees this. +

+
+ COMMIT → WAL persisted to disk +
+ ⚡ Power failure +
+ Restart → Replay WAL → Data intact ✓ +
+
+
+ + + {/* Interactive Transaction Demo */} + +

+ Interactive: Concurrent Transactions +

+

+ Watch two transactions run concurrently. See how isolation prevents dirty reads and how + atomicity handles crashes. Click the buttons to step through the scenario. +

+ + + + {/* MVCC */} + +

+ Multi-Version Concurrency Control (MVCC) +

+

+ MVCC is the key technology that allows readers to never block writers and + vice versa. Instead of locking rows, the database keeps multiple versions of each row, + allowing different transactions to see different snapshots. +

+ +
+
+

+ + Oracle: Undo/Redo Model +

+
+
+ + Old row version moved to separate UNDO tablespace +
+
+ + New version written in-place in the data table +
+
+ + Long queries reconstruct past state from UNDO +
+
+ + Powers Oracle "Flashback" time-travel queries +
+
+
+ +
+

+ + PostgreSQL: Inline Versioning +

+
+
+ + Old and new versions stored inline in the same table +
+
+ + Old tuple marked as "expired" (dead tuple) +
+
+ + No separate UNDO storage needed +
+
+ + Autovacuum continuously cleans dead tuples to reclaim space +
+
+
+
+ + + ); + + const sidebarContent = ( + +

Related Sections

+
+ navigateToSection('Oracle vs PostgreSQL')} + /> + navigateToSection('Storage Engine')} + /> +
+ + ); + + return ( + <> + + navigateToSection('Oracle vs PostgreSQL')} + /> + + ); +}; + +export default TransactionsACID; diff --git a/src/features/database/components/sections/Visualization.tsx b/src/features/database/components/sections/Visualization.tsx new file mode 100644 index 0000000..6c867c5 --- /dev/null +++ b/src/features/database/components/sections/Visualization.tsx @@ -0,0 +1,112 @@ +import React, { Suspense, useState } from 'react'; +import CTASection from '../../../../components/shared/CTASection'; +import { + Eye, + Network, + Search, + HardDrive, + RefreshCw, + GitCompare, + Layers, + PenTool, + FileJson, + Brain, +} from 'lucide-react'; + +const DatabaseTaxonomy2D = React.lazy(() => import('../visualizations/2d/DatabaseTaxonomy2D')); +const QueryProcessor2D = React.lazy(() => import('../visualizations/2d/QueryProcessor2D')); +const BTreeIndex2D = React.lazy(() => import('../visualizations/2d/BTreeIndex2D')); +const BufferManager2D = React.lazy(() => import('../visualizations/2d/BufferManager2D')); +const TransactionACID2D = React.lazy(() => import('../visualizations/2d/TransactionACID2D')); +const MVCCComparison2D = React.lazy(() => import('../visualizations/2d/MVCCComparison2D')); +const ERDiagramBuilder2D = React.lazy(() => import('../visualizations/2d/ERDiagramBuilder2D')); +const SQLvsNoSQL2D = React.lazy(() => import('../visualizations/2d/SQLvsNoSQL2D')); +const VectorDatabase2D = React.lazy(() => import('../visualizations/2d/VectorDatabase2D')); + +const vizTabs = [ + { key: 'taxonomy', label: 'Database Taxonomy', icon: Network }, + { key: 'query', label: 'Query Lifecycle', icon: Search }, + { key: 'btree', label: 'B-Tree Index', icon: Layers }, + { key: 'buffer', label: 'Buffer Manager', icon: HardDrive }, + { key: 'acid', label: 'ACID Transactions', icon: RefreshCw }, + { key: 'mvcc', label: 'MVCC Comparison', icon: GitCompare }, + { key: 'erd', label: 'ER Diagram Builder', icon: PenTool }, + { key: 'sqlnosql', label: 'SQL vs NoSQL', icon: FileJson }, + { key: 'vector', label: 'Vector Search', icon: Brain }, +] as const; + +type VizTab = (typeof vizTabs)[number]['key']; + +const fallback = ( +
+
+
+); + +const Visualization: React.FC = () => { + const [active, setActive] = useState('taxonomy'); + + return ( +
+ {/* Hero */} +
+
+ +

Interactive Visualizations

+
+

+ Database internals are notoriously abstract — invisible data pages, lock queues, and query + plans. These 9 interactive visualizations make the invisible visible. Choose a topic below + and explore at your own pace. +

+
+ + {/* Tab Selector */} +
+ {vizTabs.map((tab) => { + const TabIcon = tab.icon; + return ( + + ); + })} +
+ + {/* Active Visualization */} + + {active === 'taxonomy' && } + {active === 'query' && } + {active === 'btree' && } + {active === 'buffer' && } + {active === 'acid' && } + {active === 'mvcc' && } + {active === 'erd' && } + {active === 'sqlnosql' && } + {active === 'vector' && } + + + {/* CTA */} + { + window.location.href = '/database?section=Introduction'; + }} + colorScheme="teal" + /> +
+ ); +}; + +export default Visualization; diff --git a/src/features/database/components/visualizations/2d/BTreeIndex2D.tsx b/src/features/database/components/visualizations/2d/BTreeIndex2D.tsx new file mode 100644 index 0000000..19062a9 --- /dev/null +++ b/src/features/database/components/visualizations/2d/BTreeIndex2D.tsx @@ -0,0 +1,376 @@ +import React, { useState, useCallback, useMemo } from 'react'; +import { Search, Plus, RotateCcw, ChevronRight } from 'lucide-react'; + +interface BTreeIndex2DProps { + className?: string; +} + +const BTreeIndex2D: React.FC = React.memo(({ className = '' }) => { + const [searchKey, setSearchKey] = useState(null); + const [insertValue, setInsertValue] = useState(''); + const [searchPath, setSearchPath] = useState([]); + const [message, setMessage] = useState( + 'Click a key in the tree to search, or insert a new value.' + ); + + // Static B-Tree structure (order 3) for visualization + const [tree, setTree] = useState<{ + root: number[]; + children: number[][]; + }>({ + root: [30, 60], + children: [ + [10, 20], + [40, 50], + [70, 80, 90], + ], + }); + + const handleSearch = useCallback( + (key: number) => { + setSearchKey(key); + const path: string[] = []; + + // Check root + path.push('root'); + const rootIdx = tree.root.findIndex((k) => k === key); + if (rootIdx >= 0) { + setSearchPath(path); + setMessage(`Found ${key} in the root node! Search complete in ${path.length} step(s).`); + return; + } + + // Determine which child to descend into + let childIdx = 0; + for (let i = 0; i < tree.root.length; i++) { + if (key > tree.root[i]) childIdx = i + 1; + } + path.push(`child-${childIdx}`); + + const leaf = tree.children[childIdx]; + if (leaf && leaf.includes(key)) { + setSearchPath(path); + setMessage( + `Found ${key} in leaf node ${childIdx}! Path: Root → Leaf ${childIdx}. Total: ${path.length} step(s).` + ); + } else { + setSearchPath(path); + setMessage( + `Key ${key} not found. Searched Root → Leaf ${childIdx}. In a real B-Tree, each step eliminates half the keys.` + ); + } + }, + [tree] + ); + + const handleInsert = useCallback(() => { + const val = parseInt(insertValue, 10); + if (isNaN(val) || val < 1 || val > 99) { + setMessage('Enter a number between 1 and 99.'); + return; + } + + // Check if already exists + if (tree.root.includes(val) || tree.children.some((c) => c.includes(val))) { + setMessage(`${val} already exists in the tree.`); + return; + } + + // Find correct leaf + let childIdx = 0; + for (let i = 0; i < tree.root.length; i++) { + if (val > tree.root[i]) childIdx = i + 1; + } + + const newChildren = tree.children.map((child, i) => { + if (i === childIdx) { + return [...child, val].sort((a, b) => a - b); + } + return child; + }); + + // If child index doesn't exist yet, create it + if (childIdx >= tree.children.length) { + while (newChildren.length <= childIdx) { + newChildren.push([]); + } + newChildren[childIdx] = [val]; + } + + setTree({ ...tree, children: newChildren }); + setSearchKey(val); + setSearchPath([`child-${childIdx}`]); + setInsertValue(''); + setMessage( + `Inserted ${val} into leaf node ${childIdx}. In a real B-Tree, node splits occur when a leaf exceeds its capacity.` + ); + }, [insertValue, tree]); + + const handleReset = useCallback(() => { + setTree({ + root: [30, 60], + children: [ + [10, 20], + [40, 50], + [70, 80, 90], + ], + }); + setSearchKey(null); + setSearchPath([]); + setMessage('Tree reset. Click a key to search, or insert a new value.'); + }, []); + + const allKeys = useMemo( + () => [...tree.root, ...tree.children.flat()].sort((a, b) => a - b), + [tree] + ); + + return ( +
+ {/* B-Tree SVG */} +
+ + + + + + + + {/* Root Node */} + + + + ROOT + + {tree.root.map((key, i) => { + const kx = 290 + i * 120; + const isHighlighted = searchKey === key; + return ( + handleSearch(key)} + onKeyDown={(e) => { + if (e.key === 'Enter' || e.key === ' ') { + e.preventDefault(); + handleSearch(key); + } + }} + style={{ cursor: 'pointer' }} + > + + + {key} + + + ); + })} + + + {/* Leaf Nodes */} + {tree.children.map((child, ci) => { + const lx = 60 + ci * 250; + const ly = 160; + const nodeW = Math.max(160, child.length * 52 + 20); + const isInPath = searchPath.includes(`child-${ci}`); + + return ( + + {/* Connector from root to leaf */} + + + {/* Leaf box */} + + + Leaf {ci} + + + {/* Keys in leaf */} + {child.map((key, ki) => { + const kx = lx + 25 + ki * 48; + const isHighlighted = searchKey === key; + return ( + handleSearch(key)} + onKeyDown={(e) => { + if (e.key === 'Enter' || e.key === ' ') { + e.preventDefault(); + handleSearch(key); + } + }} + style={{ cursor: 'pointer' }} + > + + + {key} + + + ); + })} + + {/* Next-leaf pointer (doubly linked) */} + {ci < tree.children.length - 1 && ( + + )} + + ); + })} + + {/* Legend */} + + ← Leaf pointers enable range scans without revisiting the root → + + +
+ + {/* Controls */} +
+
+ setInsertValue(e.target.value)} + onKeyDown={(e) => { + if (e.key === 'Enter') handleInsert(); + }} + placeholder="1-99" + className="w-16 px-2 py-1 rounded border border-gray-300 text-sm" + aria-label="Value to insert into B-Tree" + /> + +
+ + + +
+ + Click any key to search +
+
+ + {/* Message */} +
+ + {message} +
+ + {/* Stats */} +
+
+

{allKeys.length}

+

Total Keys

+
+
+

2

+

Tree Depth

+
+
+

O(log n)

+

Search Time

+
+
+
+ ); +}); + +BTreeIndex2D.displayName = 'BTreeIndex2D'; + +export default BTreeIndex2D; diff --git a/src/features/database/components/visualizations/2d/BufferManager2D.tsx b/src/features/database/components/visualizations/2d/BufferManager2D.tsx new file mode 100644 index 0000000..7ccb571 --- /dev/null +++ b/src/features/database/components/visualizations/2d/BufferManager2D.tsx @@ -0,0 +1,391 @@ +import React, { useState, useEffect, useCallback, useMemo } from 'react'; +import { Play, Pause, RotateCcw } from 'lucide-react'; + +interface PageSlot { + id: number; + pageId: string | null; + dirty: boolean; + pinned: boolean; + accessTime: number; +} + +interface BufferManager2DProps { + className?: string; +} + +const BufferManager2D: React.FC = React.memo(({ className = '' }) => { + const POOL_SIZE = 8; + const [pool, setPool] = useState(() => + Array.from({ length: POOL_SIZE }, (_, i) => ({ + id: i, + pageId: null, + dirty: false, + pinned: false, + accessTime: 0, + })) + ); + const [tick, setTick] = useState(0); + const [isPlaying, setIsPlaying] = useState(false); + const [stats, setStats] = useState({ hits: 0, misses: 0 }); + const [log, setLog] = useState(['Buffer pool initialized (8 slots)']); + const [lastRequest, setLastRequest] = useState(null); + + const diskPages = useMemo( + () => ['P1', 'P2', 'P3', 'P4', 'P5', 'P6', 'P7', 'P8', 'P9', 'P10'], + [] + ); + + const requestPage = useCallback( + (pageId: string) => { + setLastRequest(pageId); + setTick((t) => t + 1); + + setPool((prev) => { + const newPool = prev.map((s) => ({ ...s })); + + // Check if already in pool (HIT) + const cached = newPool.find((s) => s.pageId === pageId); + if (cached) { + cached.accessTime = tick + 1; + cached.pinned = true; + setTimeout(() => { + setPool((p) => p.map((s) => (s.id === cached.id ? { ...s, pinned: false } : s))); + }, 600); + setStats((s) => ({ ...s, hits: s.hits + 1 })); + setLog((l) => [`✓ HIT — Page ${pageId} found in slot ${cached.id}`, ...l.slice(0, 9)]); + return newPool; + } + + // MISS — need to load from disk + setStats((s) => ({ ...s, misses: s.misses + 1 })); + + // Find empty slot first + let target = newPool.find((s) => s.pageId === null); + + if (!target) { + // LRU eviction — find unpinned slot with oldest access time + const unpinned = newPool.filter((s) => !s.pinned); + if (unpinned.length === 0) { + setLog((l) => ['✗ All pages pinned — cannot evict!', ...l.slice(0, 9)]); + return newPool; + } + target = unpinned.reduce((a, b) => (a.accessTime < b.accessTime ? a : b)); + + const evictedId = target.pageId; + if (target.dirty) { + setLog((l) => [ + `✗ MISS — Evicting dirty page ${evictedId} from slot ${target!.id} (written to disk)`, + ...l.slice(0, 9), + ]); + } else { + setLog((l) => [ + `✗ MISS — Evicting clean page ${evictedId} from slot ${target!.id}`, + ...l.slice(0, 9), + ]); + } + } else { + setLog((l) => [ + `✗ MISS — Loading page ${pageId} into empty slot ${target!.id}`, + ...l.slice(0, 9), + ]); + } + + target.pageId = pageId; + target.dirty = false; + target.pinned = true; + target.accessTime = tick + 1; + + setTimeout(() => { + setPool((p) => p.map((s) => (s.id === target!.id ? { ...s, pinned: false } : s))); + }, 600); + + return newPool; + }); + }, + [tick] + ); + + const markDirty = useCallback((slotId: number) => { + setPool((prev) => prev.map((s) => (s.id === slotId && s.pageId ? { ...s, dirty: true } : s))); + setLog((l) => [`⬡ Slot ${slotId} marked dirty (modified)`, ...l.slice(0, 9)]); + }, []); + + // Auto-play random requests + useEffect(() => { + if (!isPlaying) return; + const timer = setInterval(() => { + const page = diskPages[Math.floor(Math.random() * diskPages.length)]; + requestPage(page); + }, 1200); + return () => clearInterval(timer); + }, [isPlaying, diskPages, requestPage]); + + const handleReset = useCallback(() => { + setPool( + Array.from({ length: POOL_SIZE }, (_, i) => ({ + id: i, + pageId: null, + dirty: false, + pinned: false, + accessTime: 0, + })) + ); + setStats({ hits: 0, misses: 0 }); + setLog(['Buffer pool reset']); + setLastRequest(null); + setIsPlaying(false); + }, []); + + const hitRate = + stats.hits + stats.misses > 0 + ? ((stats.hits / (stats.hits + stats.misses)) * 100).toFixed(0) + : '—'; + + return ( +
+ {/* Buffer Pool SVG */} +
+ + {/* Disk icon */} + + + + DISK + + + {diskPages.length} pages + + + + {/* Arrow from disk to pool */} + + + I/O + + + {/* Buffer Pool */} + + + Buffer Pool ({POOL_SIZE} slots) + + + {/* Slots */} + {pool.map((slot, i) => { + const col = i % 4; + const row = Math.floor(i / 4); + const sx = 185 + col * 148; + const sy = 44 + row * 100; + const isRequested = lastRequest === slot.pageId && slot.pageId !== null; + + return ( + + + {/* Slot label */} + + Slot {slot.id} + + + {slot.pageId ? ( + <> + {/* Page ID */} + + {slot.pageId} + + {/* Status badges */} + + {slot.dirty ? '● dirty' : '○ clean'} + {slot.pinned ? ' 📌 pinned' : ''} + + {/* Click to mark dirty */} + markDirty(slot.id)} + onKeyDown={(e) => { + if (e.key === 'Enter' || e.key === ' ') { + e.preventDefault(); + markDirty(slot.id); + } + }} + /> + + ) : ( + + — empty — + + )} + + {/* Pulse on access */} + {slot.pinned && ( + + + + )} + + ); + })} + +
+ + {/* Controls */} +
+
+ {diskPages.map((page) => ( + + ))} +
+ +
+ + +
+
+ + {/* Stats */} +
+
+

{stats.hits}

+

Cache Hits

+
+
+

{stats.misses}

+

Cache Misses

+
+
+

{hitRate}%

+

Hit Rate

+
+
+

LRU

+

Eviction Policy

+
+
+ + {/* Event Log */} +
+ {log.map((entry, i) => ( +

+ {entry} +

+ ))} +
+ +

+ Click page buttons to request from disk. Click occupied slots to mark dirty. LRU eviction + replaces the least recently used clean page. +

+
+ ); +}); + +BufferManager2D.displayName = 'BufferManager2D'; + +export default BufferManager2D; diff --git a/src/features/database/components/visualizations/2d/DatabaseTaxonomy2D.tsx b/src/features/database/components/visualizations/2d/DatabaseTaxonomy2D.tsx new file mode 100644 index 0000000..279c4cc --- /dev/null +++ b/src/features/database/components/visualizations/2d/DatabaseTaxonomy2D.tsx @@ -0,0 +1,324 @@ +import React, { useState, useCallback, useMemo } from 'react'; +import { Database, FileText, Key, Share2, Cpu, ChevronRight } from 'lucide-react'; + +interface DatabaseType { + id: string; + label: string; + icon: React.ReactNode; + color: string; + bgColor: string; + borderColor: string; + description: string; + strengths: string[]; + examples: string[]; + dataModel: string; +} + +interface DatabaseTaxonomy2DProps { + selectedModel?: string; + onModelSelect?: (model: string) => void; + className?: string; +} + +const DatabaseTaxonomy2D: React.FC = React.memo( + ({ selectedModel: controlledModel, onModelSelect, className = '' }) => { + const [internalSelected, setInternalSelected] = useState('relational'); + const selected = controlledModel ?? internalSelected; + + const handleSelect = useCallback( + (id: string) => { + if (onModelSelect) { + onModelSelect(id); + } else { + setInternalSelected(id); + } + }, + [onModelSelect] + ); + + const types: DatabaseType[] = useMemo( + () => [ + { + id: 'relational', + label: 'Relational', + icon: , + color: 'text-blue-700', + bgColor: 'bg-blue-50', + borderColor: 'border-blue-300', + description: + 'Stores data in tables with fixed schemas. Rows have the same columns. Relationships via foreign keys. ACID-compliant by default.', + strengths: [ + 'Strong consistency & ACID transactions', + 'Complex JOINs and aggregations', + 'Mature tooling and SQL standard', + 'Best for structured, relational data', + ], + examples: ['PostgreSQL', 'Oracle', 'MySQL', 'SQL Server'], + dataModel: 'Tables → Rows → Columns', + }, + { + id: 'document', + label: 'Document', + icon: , + color: 'text-emerald-700', + bgColor: 'bg-emerald-50', + borderColor: 'border-emerald-300', + description: + 'Stores data as flexible JSON/BSON documents. Each document can have a different structure. Great for rapidly evolving schemas.', + strengths: [ + 'Flexible, schema-less design', + 'Nested objects stored inline', + 'Horizontal scaling via sharding', + 'Natural fit for APIs and web apps', + ], + examples: ['MongoDB', 'CouchDB', 'Firestore', 'DynamoDB'], + dataModel: 'Collections → Documents → Fields', + }, + { + id: 'keyvalue', + label: 'Key-Value', + icon: , + color: 'text-amber-700', + bgColor: 'bg-amber-50', + borderColor: 'border-amber-300', + description: + "Simplest model: every item is a key-value pair. Blazing fast lookups by key. No complex queries — you get the value or you don't.", + strengths: [ + 'Sub-millisecond O(1) lookups', + 'Perfect for caching and sessions', + 'Extremely scalable horizontally', + 'Simple mental model', + ], + examples: ['Redis', 'Memcached', 'Riak', 'DynamoDB'], + dataModel: 'Key → Value (blob)', + }, + { + id: 'graph', + label: 'Graph', + icon: , + color: 'text-purple-700', + bgColor: 'bg-purple-50', + borderColor: 'border-purple-300', + description: + 'Data modeled as nodes and edges (relationships). Traversing relationships is a first-class operation — no expensive JOINs.', + strengths: [ + 'Relationship-first queries', + 'Social networks and recommendations', + 'Pattern matching and pathfinding', + 'Dynamic, evolving schemas', + ], + examples: ['Neo4j', 'Amazon Neptune', 'ArangoDB', 'TigerGraph'], + dataModel: 'Nodes → Edges → Properties', + }, + { + id: 'vector', + label: 'Vector', + icon: , + color: 'text-rose-700', + bgColor: 'bg-rose-50', + borderColor: 'border-rose-300', + description: + 'Stores high-dimensional vectors (embeddings). Enables similarity search — "find the 10 most similar items". Powers AI/ML applications.', + strengths: [ + 'Semantic similarity search', + 'AI embedding storage', + 'Image/text/audio retrieval', + 'RAG (Retrieval-Augmented Generation)', + ], + examples: ['Pinecone', 'Weaviate', 'Milvus', 'pgvector'], + dataModel: 'Vectors → Indexes (HNSW/IVF)', + }, + ], + [] + ); + + const activeType = useMemo( + () => types.find((t) => t.id === selected) ?? types[0], + [types, selected] + ); + + return ( +
+ {/* SVG Taxonomy Tree */} +
+ + {/* Central Node */} + + + Database Paradigms + + + {/* Branch Lines */} + {types.map((t, i) => { + const cx = 80 + i * 165; + const cy = 180; + const isActive = t.id === selected; + return ( + + {/* Connecting line */} + + + {/* Node */} + handleSelect(t.id)} + onKeyDown={(e) => { + if (e.key === 'Enter' || e.key === ' ') { + e.preventDefault(); + handleSelect(t.id); + } + }} + style={{ cursor: 'pointer' }} + > + + {/* Icon circle */} + + {/* Small icon placeholder */} + + {t.id === 'relational' + ? '⊞' + : t.id === 'document' + ? '{ }' + : t.id === 'keyvalue' + ? 'K:V' + : t.id === 'graph' + ? '◉─◉' + : '↗'} + + {/* Label */} + + {t.label} + + {/* Examples */} + + {t.examples.slice(0, 2).join(', ')} + + + + {/* Pulsing indicator for selected */} + {isActive && ( + + + + + )} + + ); + })} + +
+ + {/* Detail Card */} +
+
+
+ {activeType.icon} +
+
+

+ {activeType.label} Database +

+

{activeType.dataModel}

+
+
+ +

{activeType.description}

+ +
+
+

+ Strengths +

+
    + {activeType.strengths.map((s, i) => ( +
  • + + {s} +
    • + ))} +
+
+
+

+ Popular Examples +

+
+ {activeType.examples.map((ex) => ( + + {ex} + + ))} +
+
+
+
+
+ ); + } +); + +DatabaseTaxonomy2D.displayName = 'DatabaseTaxonomy2D'; + +export default DatabaseTaxonomy2D; diff --git a/src/features/database/components/visualizations/2d/ERDiagramBuilder2D.tsx b/src/features/database/components/visualizations/2d/ERDiagramBuilder2D.tsx new file mode 100644 index 0000000..805fb0d --- /dev/null +++ b/src/features/database/components/visualizations/2d/ERDiagramBuilder2D.tsx @@ -0,0 +1,500 @@ +import React, { useState, useCallback, useMemo } from 'react'; +import { Plus, Trash2, RotateCcw, Link } from 'lucide-react'; + +interface Entity { + id: string; + name: string; + x: number; + y: number; + attributes: string[]; + color: string; +} + +interface Relationship { + from: string; + to: string; + label: string; + cardinality: string; +} + +interface ERDiagramBuilder2DProps { + className?: string; +} + +const ENTITY_TEMPLATES: Omit[] = [ + { name: 'User', attributes: ['user_id (PK)', 'name', 'email', 'created_at'], color: '#3b82f6' }, + { + name: 'Order', + attributes: ['order_id (PK)', 'user_id (FK)', 'total', 'status'], + color: '#8b5cf6', + }, + { name: 'Product', attributes: ['product_id (PK)', 'name', 'price', 'stock'], color: '#059669' }, + { name: 'Category', attributes: ['category_id (PK)', 'name', 'description'], color: '#f59e0b' }, + { + name: 'Payment', + attributes: ['payment_id (PK)', 'order_id (FK)', 'amount', 'method'], + color: '#ef4444', + }, + { + name: 'Review', + attributes: ['review_id (PK)', 'user_id (FK)', 'product_id (FK)', 'rating'], + color: '#ec4899', + }, +]; + +let nextId = 1; + +const ERDiagramBuilder2D: React.FC = React.memo(({ className = '' }) => { + const [entities, setEntities] = useState(() => [ + { + id: 'e1', + name: 'User', + x: 80, + y: 60, + attributes: ['user_id (PK)', 'name', 'email', 'created_at'], + color: '#3b82f6', + }, + { + id: 'e2', + name: 'Order', + x: 360, + y: 60, + attributes: ['order_id (PK)', 'user_id (FK)', 'total', 'status'], + color: '#8b5cf6', + }, + { + id: 'e3', + name: 'Product', + x: 360, + y: 220, + attributes: ['product_id (PK)', 'name', 'price', 'stock'], + color: '#059669', + }, + ]); + + const [relationships, setRelationships] = useState([ + { from: 'e1', to: 'e2', label: 'places', cardinality: '1:N' }, + { from: 'e2', to: 'e3', label: 'contains', cardinality: 'N:M' }, + ]); + + const [dragging, setDragging] = useState(null); + const [dragOffset, setDragOffset] = useState({ x: 0, y: 0 }); + const [connecting, setConnecting] = useState(null); + const [selectedEntity, setSelectedEntity] = useState(null); + + const ENTITY_W = 180; + const ENTITY_H = 120; + + const handleMouseDown = useCallback( + (entityId: string, e: React.MouseEvent) => { + if (connecting) return; + const svg = (e.target as SVGElement).closest('svg'); + if (!svg) return; + const pt = svg.createSVGPoint(); + pt.x = e.clientX; + pt.y = e.clientY; + const svgP = pt.matrixTransform(svg.getScreenCTM()?.inverse()); + const entity = entities.find((en) => en.id === entityId); + if (entity) { + setDragOffset({ x: svgP.x - entity.x, y: svgP.y - entity.y }); + setDragging(entityId); + } + }, + [entities, connecting] + ); + + const handleMouseMove = useCallback( + (e: React.MouseEvent) => { + if (!dragging) return; + const svg = e.currentTarget; + const pt = svg.createSVGPoint(); + pt.x = e.clientX; + pt.y = e.clientY; + const svgP = pt.matrixTransform(svg.getScreenCTM()?.inverse()); + setEntities((prev) => + prev.map((en) => + en.id === dragging + ? { + ...en, + x: Math.max(0, Math.min(600, svgP.x - dragOffset.x)), + y: Math.max(0, Math.min(340, svgP.y - dragOffset.y)), + } + : en + ) + ); + }, + [dragging, dragOffset] + ); + + const handleMouseUp = useCallback(() => { + setDragging(null); + }, []); + + const handleEntityClick = useCallback( + (entityId: string) => { + if (connecting) { + if (connecting !== entityId) { + const label = prompt('Relationship label (e.g., "has", "belongs to"):') || 'relates'; + const card = prompt('Cardinality (1:1, 1:N, N:M):') || '1:N'; + setRelationships((prev) => [ + ...prev, + { from: connecting, to: entityId, label, cardinality: card }, + ]); + } + setConnecting(null); + } else { + setSelectedEntity(entityId === selectedEntity ? null : entityId); + } + }, + [connecting, selectedEntity] + ); + + const addEntity = useCallback((template: Omit) => { + const id = `e${++nextId + 10}`; + setEntities((prev) => [ + ...prev, + { + id, + ...template, + x: 80 + Math.random() * 400, + y: 60 + Math.random() * 260, + }, + ]); + }, []); + + const removeEntity = useCallback( + (entityId: string) => { + setEntities((prev) => prev.filter((e) => e.id !== entityId)); + setRelationships((prev) => prev.filter((r) => r.from !== entityId && r.to !== entityId)); + if (selectedEntity === entityId) setSelectedEntity(null); + }, + [selectedEntity] + ); + + const handleReset = useCallback(() => { + nextId = 3; + setEntities([ + { + id: 'e1', + name: 'User', + x: 80, + y: 60, + attributes: ['user_id (PK)', 'name', 'email', 'created_at'], + color: '#3b82f6', + }, + { + id: 'e2', + name: 'Order', + x: 360, + y: 60, + attributes: ['order_id (PK)', 'user_id (FK)', 'total', 'status'], + color: '#8b5cf6', + }, + { + id: 'e3', + name: 'Product', + x: 360, + y: 220, + attributes: ['product_id (PK)', 'name', 'price', 'stock'], + color: '#059669', + }, + ]); + setRelationships([ + { from: 'e1', to: 'e2', label: 'places', cardinality: '1:N' }, + { from: 'e2', to: 'e3', label: 'contains', cardinality: 'N:M' }, + ]); + setSelectedEntity(null); + setConnecting(null); + }, []); + + const entityMap = useMemo(() => new Map(entities.map((e) => [e.id, e])), [entities]); + + return ( +
+ {/* Canvas */} +
+ + + + + + + + {/* Grid */} + {Array.from({ length: 15 }).map((_, i) => ( + + ))} + {Array.from({ length: 9 }).map((_, i) => ( + + ))} + + {/* Relationships (lines first, under entities) */} + {relationships.map((rel, i) => { + const fromE = entityMap.get(rel.from); + const toE = entityMap.get(rel.to); + if (!fromE || !toE) return null; + + const x1 = fromE.x + ENTITY_W / 2; + const y1 = fromE.y + ENTITY_H / 2; + const x2 = toE.x + ENTITY_W / 2; + const y2 = toE.y + ENTITY_H / 2; + const mx = (x1 + x2) / 2; + const my = (y1 + y2) / 2; + + return ( + + + {/* Diamond for relationship */} + + + {rel.label} + + {/* Cardinality labels */} + + {rel.cardinality.split(':')[0]} + + + {rel.cardinality.split(':')[1]} + + + ); + })} + + {/* Entities */} + {entities.map((entity) => { + const isSelected = selectedEntity === entity.id; + const isConnecting = connecting === entity.id; + + return ( + handleMouseDown(entity.id, e)} + onClick={() => handleEntityClick(entity.id)} + style={{ cursor: connecting ? 'crosshair' : 'grab' }} + > + {/* Entity rectangle */} + + {/* Header */} + + + + {entity.name} + + + {/* Attributes */} + {entity.attributes.slice(0, 4).map((attr, ai) => ( + + {attr} + + ))} + + {/* Selection indicator */} + {isSelected && ( + + + + )} + + ); + })} + + {connecting && ( + + Click another entity to create a relationship... + + )} + +
+ + {/* Controls */} +
+ {/* Add entities */} +
+ {ENTITY_TEMPLATES.filter((t) => !entities.some((e) => e.name === t.name)).map( + (template) => ( + + ) + )} +
+ +
+ + + {selectedEntity && ( + + )} + + +
+
+ +

+ Drag entities to reposition. Click to select. Use "Connect" to draw relationships. + PK = Primary Key, FK = Foreign Key. +

+
+ ); +}); + +ERDiagramBuilder2D.displayName = 'ERDiagramBuilder2D'; + +export default ERDiagramBuilder2D; diff --git a/src/features/database/components/visualizations/2d/MVCCComparison2D.tsx b/src/features/database/components/visualizations/2d/MVCCComparison2D.tsx new file mode 100644 index 0000000..016a5be --- /dev/null +++ b/src/features/database/components/visualizations/2d/MVCCComparison2D.tsx @@ -0,0 +1,361 @@ +import React, { useState, useCallback, useMemo } from 'react'; +import { RefreshCw, Database } from 'lucide-react'; + +interface RowVersion { + xmin: number; + xmax: number | null; + data: string; + location: string; +} + +interface MVCCComparison2DProps { + className?: string; +} + +const MVCCComparison2D: React.FC = React.memo(({ className = '' }) => { + const [step, setStep] = useState(0); + const [engine, setEngine] = useState<'oracle' | 'postgres'>('oracle'); + + const oracleSteps = useMemo( + () => [ + { + title: 'Initial State', + description: 'Row exists in data table with value "Alice, $1000".', + table: [ + { xmin: 100, xmax: null, data: 'Alice, $1000', location: 'Data Block #42' }, + ] as RowVersion[], + undo: [] as RowVersion[], + note: 'Data block holds the current version. UNDO tablespace is empty for this row.', + }, + { + title: 'T200: UPDATE balance = $800', + description: 'T200 writes new value in-place. Old version moved to UNDO tablespace.', + table: [ + { xmin: 200, xmax: null, data: 'Alice, $800', location: 'Data Block #42' }, + ] as RowVersion[], + undo: [ + { xmin: 100, xmax: 200, data: 'Alice, $1000', location: 'UNDO Segment' }, + ] as RowVersion[], + note: 'New row written IN-PLACE. Old version copied to separate UNDO storage.', + }, + { + title: 'T150 reads (started before T200)', + description: 'T150 needs the pre-T200 version. Oracle reconstructs it from UNDO.', + table: [ + { xmin: 200, xmax: null, data: 'Alice, $800', location: 'Data Block #42' }, + ] as RowVersion[], + undo: [ + { + xmin: 100, + xmax: 200, + data: 'Alice, $1000 ← T150 reads this', + location: 'UNDO Segment', + }, + ] as RowVersion[], + note: 'T150 follows the UNDO chain to find a version visible at its SCN. This is "consistent read".', + }, + { + title: 'UNDO purged (after all readers done)', + description: 'Once no transaction needs the old version, UNDO space is reclaimed.', + table: [ + { xmin: 200, xmax: null, data: 'Alice, $800', location: 'Data Block #42' }, + ] as RowVersion[], + undo: [] as RowVersion[], + note: 'UNDO automatically managed. If purged too early → ORA-01555 "snapshot too old" error.', + }, + ], + [] + ); + + const postgresSteps = useMemo( + () => [ + { + title: 'Initial State', + description: 'Row lives in the heap page with xmin=100, xmax=0 (not expired).', + table: [ + { xmin: 100, xmax: null, data: 'Alice, $1000', location: 'Heap Page #42' }, + ] as RowVersion[], + deadTuples: 0, + note: 'All versions stored inline in the same heap page. No separate UNDO storage.', + }, + { + title: 'T200: UPDATE balance = $800', + description: 'PostgreSQL creates a NEW tuple. Old tuple marked xmax=200 (dead).', + table: [ + { xmin: 100, xmax: 200, data: 'Alice, $1000 (dead)', location: 'Heap Page #42' }, + { xmin: 200, xmax: null, data: 'Alice, $800', location: 'Heap Page #42' }, + ] as RowVersion[], + deadTuples: 1, + note: 'BOTH versions coexist in the same page. Old tuple is "dead" but not removed yet.', + }, + { + title: 'T150 reads (started before T200)', + description: "T150's snapshot sees xmin=100 as visible. The dead tuple serves the read.", + table: [ + { + xmin: 100, + xmax: 200, + data: 'Alice, $1000 ← T150 reads this', + location: 'Heap Page #42', + }, + { xmin: 200, xmax: null, data: 'Alice, $800', location: 'Heap Page #42' }, + ] as RowVersion[], + deadTuples: 1, + note: 'Dead tuple is still needed by T150. Visibility check: xmin ≤ snapshot < xmax.', + }, + { + title: 'Autovacuum cleans dead tuples', + description: 'After all readers finish, Autovacuum marks space as reusable.', + table: [ + { xmin: 200, xmax: null, data: 'Alice, $800', location: 'Heap Page #42' }, + ] as RowVersion[], + deadTuples: 0, + note: 'VACUUM reclaims dead tuple space. Without it → table bloat. Autovacuum runs automatically.', + }, + ], + [] + ); + + const steps = engine === 'oracle' ? oracleSteps : postgresSteps; + const current = steps[step]; + + const handleNext = useCallback(() => { + setStep((s) => Math.min(s + 1, steps.length - 1)); + }, [steps.length]); + + const handlePrev = useCallback(() => { + setStep((s) => Math.max(s - 1, 0)); + }, []); + + const handleEngineSwitch = useCallback((e: 'oracle' | 'postgres') => { + setEngine(e); + setStep(0); + }, []); + + return ( +
+ {/* Engine Selector */} +
+ + +
+ + {/* SVG Visualization */} +
+ + {/* Data Table Area */} + + + {engine === 'oracle' ? 'Data Block' : 'Heap Page'} + + + {current.table.map((row, i) => { + const ry = 42 + i * 60; + const isDead = row.xmax !== null; + return ( + + + {/* xmin */} + + xmin={row.xmin} + + {/* xmax */} + + xmax={row.xmax ?? '∅'} + + {/* Data */} + + {row.data} + + {/* Location */} + + {row.location} + + + ); + })} + + {/* UNDO / Dead Tuples Area (right side) */} + + + {engine === 'oracle' ? 'UNDO Tablespace' : 'Autovacuum Status'} + + + {engine === 'oracle' ? ( + // Oracle UNDO entries + (current as (typeof oracleSteps)[number]).undo.length > 0 ? ( + (current as (typeof oracleSteps)[number]).undo.map((row, i) => { + const ry = 42 + i * 60; + return ( + + + + xmin={row.xmin} xmax={row.xmax ?? '∅'} + + + {row.data} + + + ); + }) + ) : ( + + (empty) + + ) + ) : ( + // PostgreSQL dead tuple meter + + + Dead Tuples + + + 0 ? 115 : 0} + height="20" + rx="4" + fill="#f59e0b" + style={{ transition: 'width 0.3s ease' }} + /> + + {(current as (typeof postgresSteps)[number]).deadTuples} dead tuple(s) + + + {(current as (typeof postgresSteps)[number]).deadTuples > 0 + ? 'Autovacuum will clean these up' + : 'No cleanup needed'} + + + )} + + {/* Progress dots */} + {steps.map((_, i) => ( + + ))} + +
+ + {/* Step Controls */} +
+ + + Step {step + 1} / {steps.length} + + +
+ + {/* Description */} +
+

+ {current.title} +

+

{current.description}

+

{current.note}

+
+
+ ); +}); + +MVCCComparison2D.displayName = 'MVCCComparison2D'; + +export default MVCCComparison2D; diff --git a/src/features/database/components/visualizations/2d/QueryProcessor2D.tsx b/src/features/database/components/visualizations/2d/QueryProcessor2D.tsx new file mode 100644 index 0000000..e325589 --- /dev/null +++ b/src/features/database/components/visualizations/2d/QueryProcessor2D.tsx @@ -0,0 +1,315 @@ +import React, { useState, useEffect, useCallback, useMemo } from 'react'; +import { Play, Pause, RotateCcw, ArrowRight } from 'lucide-react'; + +interface Stage { + id: string; + label: string; + shortLabel: string; + color: string; + fill: string; + description: string; + detail: string; +} + +interface QueryProcessor2DProps { + className?: string; +} + +const QueryProcessor2D: React.FC = React.memo(({ className = '' }) => { + const [activeStage, setActiveStage] = useState(0); + const [isPlaying, setIsPlaying] = useState(false); + + const stages: Stage[] = useMemo( + () => [ + { + id: 'sql', + label: 'SQL Query', + shortLabel: 'SQL', + color: '#6366f1', + fill: '#eef2ff', + description: 'Raw SQL text arrives from the client application.', + detail: 'SELECT name, balance FROM accounts WHERE balance > 1000 ORDER BY balance DESC;', + }, + { + id: 'parser', + label: 'Parser', + shortLabel: 'Parse', + color: '#0891b2', + fill: '#ecfeff', + description: 'Lexer tokenizes SQL → Parser builds an Abstract Syntax Tree (AST).', + detail: + 'Validates syntax, resolves table/column names against the data dictionary, checks permissions.', + }, + { + id: 'rewriter', + label: 'Query Rewriter', + shortLabel: 'Rewrite', + color: '#7c3aed', + fill: '#f5f3ff', + description: 'Transforms the AST: expands views, applies rules, simplifies predicates.', + detail: + 'View expansion, subquery de-correlation, constant folding, predicate pushdown (logical rewrites).', + }, + { + id: 'optimizer', + label: 'Cost-Based Optimizer', + shortLabel: 'Optimize', + color: '#059669', + fill: '#ecfdf5', + description: + 'Generates candidate plans, estimates cost using statistics, picks the cheapest plan.', + detail: + 'Join ordering, index selection, nested loop vs hash join vs merge join. Uses table stats + histograms.', + }, + { + id: 'executor', + label: 'Execution Engine', + shortLabel: 'Execute', + color: '#dc2626', + fill: '#fef2f2', + description: 'Executes the chosen physical plan using an iterator (Volcano) model.', + detail: + 'Each operator (Seq Scan, Index Scan, Hash Join, Sort) is a node that pulls rows from child nodes.', + }, + { + id: 'result', + label: 'Result Set', + shortLabel: 'Result', + color: '#0d9488', + fill: '#f0fdfa', + description: 'Rows are returned to the client, one batch at a time.', + detail: 'Streamed via the wire protocol (e.g., PostgreSQL protocol or Oracle Net).', + }, + ], + [] + ); + + useEffect(() => { + if (!isPlaying) return; + const timer = setInterval(() => { + setActiveStage((prev) => { + if (prev >= stages.length - 1) { + setIsPlaying(false); + return prev; + } + return prev + 1; + }); + }, 1500); + return () => clearInterval(timer); + }, [isPlaying, stages.length]); + + const handleReset = useCallback(() => { + setActiveStage(0); + setIsPlaying(false); + }, []); + + const handleTogglePlay = useCallback(() => { + if (activeStage >= stages.length - 1) { + setActiveStage(0); + } + setIsPlaying((p) => !p); + }, [activeStage, stages.length]); + + const currentStage = stages[activeStage]; + + return ( +
+ {/* Pipeline SVG */} +
+ + + + + + + + {stages.map((stage, i) => { + const x = 20 + i * 138; + const y = 15; + const w = 118; + const h = 70; + const isActive = i === activeStage; + const isPast = i < activeStage; + + return ( + + {/* Arrow between nodes */} + {i > 0 && ( + + )} + + {/* Stage box */} + { + setActiveStage(i); + setIsPlaying(false); + }} + onKeyDown={(e) => { + if (e.key === 'Enter' || e.key === ' ') { + e.preventDefault(); + setActiveStage(i); + setIsPlaying(false); + } + }} + style={{ cursor: 'pointer' }} + > + + {/* Stage number */} + + + {i + 1} + + {/* Label */} + + {stage.shortLabel} + + + + {/* Active pulse */} + {isActive && ( + + + + )} + + {/* Data flow dot (animated) */} + {isActive && isPlaying && i < stages.length - 1 && ( + + + + )} + + ); + })} + + {/* Progress bar */} + + + +
+ + {/* Controls */} +
+ + +
+ Stage {activeStage + 1} / {stages.length} +
+
+ + {/* Detail Panel */} +
+
+ +

+ {currentStage.label} +

+
+

{currentStage.description}

+
+ {currentStage.detail} +
+
+
+ ); +}); + +QueryProcessor2D.displayName = 'QueryProcessor2D'; + +export default QueryProcessor2D; diff --git a/src/features/database/components/visualizations/2d/SQLvsNoSQL2D.tsx b/src/features/database/components/visualizations/2d/SQLvsNoSQL2D.tsx new file mode 100644 index 0000000..b4aaed9 --- /dev/null +++ b/src/features/database/components/visualizations/2d/SQLvsNoSQL2D.tsx @@ -0,0 +1,572 @@ +import React, { useState } from 'react'; + +type DbCategory = 'sql' | 'document' | 'keyvalue' | 'graph' | 'widecolumn'; + +interface DbTypeInfo { + label: string; + color: string; + bgColor: string; + borderColor: string; + examples: string[]; + dataModel: string; + queryLang: string; + scaling: string; + consistency: string; + bestFor: string; +} + +const DB_TYPES: Record = { + sql: { + label: 'Relational (SQL)', + color: 'text-blue-700', + bgColor: 'bg-blue-50', + borderColor: 'border-blue-200', + examples: ['PostgreSQL', 'Oracle', 'MySQL', 'SQL Server'], + dataModel: 'Tables with rows & columns, strict schema, foreign keys', + queryLang: 'SQL (declarative)', + scaling: 'Vertical (scale-up); read replicas for horizontal reads', + consistency: 'Strong (ACID transactions)', + bestFor: 'Structured data, complex joins, financial systems, ERP', + }, + document: { + label: 'Document Store', + color: 'text-emerald-700', + bgColor: 'bg-emerald-50', + borderColor: 'border-emerald-200', + examples: ['MongoDB', 'CouchDB', 'Amazon DocumentDB', 'Firestore'], + dataModel: 'JSON/BSON documents, flexible schema, nested objects', + queryLang: 'MongoDB Query Language, N1QL (Couchbase)', + scaling: 'Horizontal (auto-sharding across nodes)', + consistency: 'Tunable (eventual → strong per operation)', + bestFor: 'Content management, user profiles, catalogs, real-time apps', + }, + keyvalue: { + label: 'Key-Value Store', + color: 'text-purple-700', + bgColor: 'bg-purple-50', + borderColor: 'border-purple-200', + examples: ['Redis', 'Amazon DynamoDB', 'Memcached', 'etcd'], + dataModel: 'Simple key → value pairs (value is opaque blob)', + queryLang: 'GET/SET/DELETE API (no query language)', + scaling: 'Horizontal (hash-based partitioning)', + consistency: 'Eventual (DynamoDB: tunable)', + bestFor: 'Caching, sessions, shopping carts, leaderboards', + }, + graph: { + label: 'Graph Database', + color: 'text-orange-700', + bgColor: 'bg-orange-50', + borderColor: 'border-orange-200', + examples: ['Neo4j', 'Amazon Neptune', 'JanusGraph', 'ArangoDB'], + dataModel: 'Nodes + Edges + Properties (index-free adjacency)', + queryLang: 'Cypher (Neo4j), Gremlin, SPARQL', + scaling: 'Challenging for writes; good for read-heavy traversals', + consistency: 'Strong (ACID in Neo4j)', + bestFor: 'Social networks, fraud detection, knowledge graphs, recommendations', + }, + widecolumn: { + label: 'Wide-Column Store', + color: 'text-teal-700', + bgColor: 'bg-teal-50', + borderColor: 'border-teal-200', + examples: ['Cassandra', 'HBase', 'ScyllaDB', 'Google Bigtable'], + dataModel: 'Row key → column families → columns (sparse, wide rows)', + queryLang: 'CQL (Cassandra), HBase API', + scaling: 'Massive horizontal (petabyte-scale)', + consistency: 'Tunable (Cassandra: ANY → ALL)', + bestFor: 'Time-series, IoT, event logging, messaging at massive scale', + }, +}; + +const categories: DbCategory[] = ['sql', 'document', 'keyvalue', 'graph', 'widecolumn']; + +const SQLvsNoSQL2D: React.FC = () => { + const [selected, setSelected] = useState('sql'); + const info = DB_TYPES[selected]; + + return ( +
+

+ Interactive Database Type Explorer +

+ + {/* Category selector */} +
+ {categories.map((cat) => { + const t = DB_TYPES[cat]; + const isActive = cat === selected; + return ( + + ); + })} +
+ + {/* Detail card */} +
+

{info.label}

+ +
+
+
+

Data Model

+

{info.dataModel}

+
+
+

Query Language

+

{info.queryLang}

+
+
+

Scaling

+

{info.scaling}

+
+
+
+
+

Consistency Model

+

{info.consistency}

+
+
+

Best For

+

{info.bestFor}

+
+
+

Examples

+
+ {info.examples.map((ex) => ( + + {ex} + + ))} +
+
+
+
+
+ + {/* Data Model Visualizations */} +
+

+ Data Model Visualization — {info.label} +

+ + {selected === 'sql' && ( + + {/* Table visualization */} + + + employees + + + {/* Header row */} + {['id', 'name', 'department', 'salary'].map((col, i) => ( + + {col} + + ))} + + {/* Data rows */} + {[ + ['1', 'Alice', 'Engineering', '$120k'], + ['2', 'Bob', 'Marketing', '$95k'], + ['3', 'Carol', 'Engineering', '$115k'], + ['4', 'Dave', 'Sales', '$88k'], + ].map((row, ri) => + row.map((val, ci) => ( + + {val} + + )) + )} + + )} + {selected === 'document' && ( + + + + Document 1 + + + {'{'} + + + "name": "Alice", + + + "dept": "Engineering", + + + "skills": ["React", + + + "TypeScript"], + + + "address": {'{'} ... {'}'} + + + {'}'} + + + + + Document 2 + + + {'{'} + + + "name": "Bob", + + + "dept": "Marketing", + + + "phone": "555-1234" + + + {'}'} + + + ← Different fields OK! + + + )} + {selected === 'keyvalue' && ( + + {[ + { key: 'user:1001', val: '{"name":"Alice","cart":[...]}', y: 20 }, + { key: 'session:abc', val: '{"token":"jwt...","exp":1720000}', y: 65 }, + { key: 'cache:home', val: '...rendered page...', y: 110 }, + { key: 'counter:views', val: '1847293', y: 155 }, + ].map((item, i) => ( + + + + {item.key} + + + → + + + + {item.val} + + + ))} + + )} + {selected === 'graph' && ( + + {/* Nodes */} + + + Alice + + + :Person + + + + + Bob + + + :Person + + + + + React + + + :Skill + + + {/* Edges */} + + + FRIENDS_WITH + + + + + KNOWS + + + + + KNOWS + + + + + + + + + )} + {selected === 'widecolumn' && ( + + + Column Family: user_activity + + {/* Row 1 */} + + + Row Key + + + user:1001 + + + user:1002 + + + {['login_ts', 'page_view', 'click_target', 'duration_ms', 'device'].map((col, i) => ( + + + + {col} + + + {i < 3 ? '✓' : i === 3 ? '✓' : ''} + + + {i < 2 ? '✓' : ''} + + + ))} + + + Each row can have different columns → sparse storage + + + Columns grouped into Column Families stored together on disk + + + Rows sorted by Row Key for efficient range scans (time-series) + + + )} + +
+
+ ); +}; + +export default SQLvsNoSQL2D; diff --git a/src/features/database/components/visualizations/2d/TransactionACID2D.tsx b/src/features/database/components/visualizations/2d/TransactionACID2D.tsx new file mode 100644 index 0000000..aa12728 --- /dev/null +++ b/src/features/database/components/visualizations/2d/TransactionACID2D.tsx @@ -0,0 +1,483 @@ +import React, { useState, useEffect, useCallback, useMemo } from 'react'; +import { Play, Pause, RotateCcw, Shield, AlertTriangle, CheckCircle } from 'lucide-react'; + +interface Transaction { + id: string; + color: string; + label: string; +} + +interface Step { + tx: string; + action: string; + description: string; + accountA: number; + accountB: number; + walEntry?: string; + status: 'pending' | 'committed' | 'rolled-back'; + violation?: string; +} + +interface TransactionACID2DProps { + className?: string; +} + +const TransactionACID2D: React.FC = React.memo(({ className = '' }) => { + const [currentStep, setCurrentStep] = useState(0); + const [isPlaying, setIsPlaying] = useState(false); + const [scenario, setScenario] = useState<'success' | 'crash'>('success'); + + const transactions: Transaction[] = useMemo( + () => [ + { id: 'T1', color: '#3b82f6', label: 'Transfer $200' }, + { id: 'T2', color: '#8b5cf6', label: 'Read Balance' }, + ], + [] + ); + + const successSteps: Step[] = useMemo( + () => [ + { + tx: 'T1', + action: 'BEGIN', + description: 'T1 starts: Transfer $200 from A → B', + accountA: 1000, + accountB: 500, + status: 'pending', + }, + { + tx: 'T1', + action: 'READ A', + description: 'T1 reads Account A balance: $1000', + accountA: 1000, + accountB: 500, + walEntry: 'T1: READ accounts WHERE id=A → $1000', + status: 'pending', + }, + { + tx: 'T2', + action: 'BEGIN + READ A', + description: 'T2 starts and reads A. Isolation: T2 sees $1000 (T1 uncommitted)', + accountA: 1000, + accountB: 500, + walEntry: 'T2: READ accounts WHERE id=A → $1000', + status: 'pending', + }, + { + tx: 'T1', + action: 'WRITE A = $800', + description: 'T1 debits $200 from A. Change is NOT visible to T2 (isolation).', + accountA: 800, + accountB: 500, + walEntry: 'T1: UPDATE accounts SET balance=800 WHERE id=A', + status: 'pending', + }, + { + tx: 'T1', + action: 'WRITE B = $700', + description: 'T1 credits $200 to B. Both writes are part of the same atomic unit.', + accountA: 800, + accountB: 700, + walEntry: 'T1: UPDATE accounts SET balance=700 WHERE id=B', + status: 'pending', + }, + { + tx: 'T1', + action: 'COMMIT', + description: + 'T1 commits. WAL flushed to disk. Changes are now durable. A+B still = $1500 ✓', + accountA: 800, + accountB: 700, + walEntry: 'T1: COMMIT ✓ (WAL persisted)', + status: 'committed', + }, + { + tx: 'T2', + action: 'READ A (again)', + description: + 'T2 reads A again. In Read Committed: sees $800. In Repeatable Read: still sees $1000.', + accountA: 800, + accountB: 700, + walEntry: 'T2: READ accounts WHERE id=A → depends on isolation level', + status: 'pending', + }, + { + tx: 'T2', + action: 'COMMIT', + description: 'T2 read-only transaction commits. All ACID properties maintained.', + accountA: 800, + accountB: 700, + walEntry: 'T2: COMMIT ✓', + status: 'committed', + }, + ], + [] + ); + + const crashSteps: Step[] = useMemo( + () => [ + { + tx: 'T1', + action: 'BEGIN', + description: 'T1 starts: Transfer $200 from A → B', + accountA: 1000, + accountB: 500, + status: 'pending', + }, + { + tx: 'T1', + action: 'READ A', + description: 'T1 reads Account A balance: $1000', + accountA: 1000, + accountB: 500, + walEntry: 'T1: READ accounts WHERE id=A → $1000', + status: 'pending', + }, + { + tx: 'T1', + action: 'WRITE A = $800', + description: 'T1 debits $200 from A.', + accountA: 800, + accountB: 500, + walEntry: 'T1: UPDATE accounts SET balance=800 WHERE id=A', + status: 'pending', + }, + { + tx: 'T1', + action: '⚡ CRASH', + description: + 'SYSTEM CRASH! T1 debited A but never credited B. Without atomicity, $200 would vanish.', + accountA: 800, + accountB: 500, + walEntry: '⚡ CRASH — T1 never committed', + status: 'pending', + violation: 'Crash before commit', + }, + { + tx: 'SYS', + action: 'RECOVERY', + description: 'System restarts. WAL replay: T1 never committed → ROLLBACK all T1 changes.', + accountA: 1000, + accountB: 500, + walEntry: 'RECOVERY: T1 not committed → UNDO all T1 writes', + status: 'rolled-back', + }, + { + tx: 'SYS', + action: 'RESTORED', + description: + 'Database restored to consistent state. A=$1000, B=$500. Total=$1500 ✓ Atomicity preserved!', + accountA: 1000, + accountB: 500, + walEntry: 'RECOVERY COMPLETE — Database consistent', + status: 'rolled-back', + }, + ], + [] + ); + + const steps = scenario === 'success' ? successSteps : crashSteps; + const step = steps[currentStep]; + + useEffect(() => { + if (!isPlaying) return; + const timer = setInterval(() => { + setCurrentStep((prev) => { + if (prev >= steps.length - 1) { + setIsPlaying(false); + return prev; + } + return prev + 1; + }); + }, 2000); + return () => clearInterval(timer); + }, [isPlaying, steps.length]); + + const handleReset = useCallback(() => { + setCurrentStep(0); + setIsPlaying(false); + }, []); + + const handleToggle = useCallback(() => { + if (currentStep >= steps.length - 1) setCurrentStep(0); + setIsPlaying((p) => !p); + }, [currentStep, steps.length]); + + return ( +
+ {/* Scenario Selector */} +
+ {(['success', 'crash'] as const).map((s) => ( + + ))} +
+ + {/* Visualization */} +
+ + {/* Account boxes */} + + + + Account A + + + ${step.accountA} + + + + + + Account B + + + ${step.accountB} + + + + {/* Total */} + + + + Total + + + ${step.accountA + step.accountB} + + + + {/* Consistency check */} + + {step.accountA + step.accountB === 1500 ? '✓ Consistent' : '✗ Inconsistent!'} + + + {/* WAL (Write-Ahead Log) */} + + + Write-Ahead Log (WAL) + + {step.walEntry && ( + + {step.walEntry.length > 46 ? step.walEntry.slice(0, 46) + '...' : step.walEntry} + + )} + + Step {currentStep + 1}/{steps.length} — {step.action} + + + {step.status === 'committed' && '💾 Persisted to disk'} + {step.status === 'rolled-back' && '↩ Rolled back'} + {step.status === 'pending' && '⏳ In progress...'} + + + {/* Timeline */} + + {steps.map((s, i) => { + const tx = transactions.find((t) => t.id === s.tx); + const cx = 20 + (i / (steps.length - 1)) * 660; + const isActive = i === currentStep; + const isPast = i < currentStep; + const fillColor = s.violation + ? '#ef4444' + : s.status === 'rolled-back' + ? '#f59e0b' + : (tx?.color ?? '#6b7280'); + + return ( + { + setCurrentStep(i); + setIsPlaying(false); + }} + onKeyDown={(e) => { + if (e.key === 'Enter' || e.key === ' ') { + e.preventDefault(); + setCurrentStep(i); + setIsPlaying(false); + } + }} + style={{ cursor: 'pointer' }} + > + + + {i + 1} + + + {s.tx} + + + {s.action.length > 12 ? s.action.slice(0, 12) : s.action} + + + ); + })} + + {/* Active step pulse */} + {(() => { + const cx = 20 + (currentStep / (steps.length - 1)) * 660; + return ( + + + + + ); + })()} + +
+ + {/* Controls */} +
+ + +
+ + {/* Description */} +
+
+ + + Step {currentStep + 1}: {step.action} + +
+

{step.description}

+
+
+ ); +}); + +TransactionACID2D.displayName = 'TransactionACID2D'; + +export default TransactionACID2D; diff --git a/src/features/database/components/visualizations/2d/VectorDatabase2D.tsx b/src/features/database/components/visualizations/2d/VectorDatabase2D.tsx new file mode 100644 index 0000000..818b446 --- /dev/null +++ b/src/features/database/components/visualizations/2d/VectorDatabase2D.tsx @@ -0,0 +1,322 @@ +import React, { useState, useCallback } from 'react'; + +interface Point { + x: number; + y: number; + label: string; + color: string; + cluster: string; +} + +type AlgorithmType = 'brute' | 'hnsw' | 'ivf'; + +const POINTS: Point[] = [ + // Cluster: Animals + { x: 120, y: 80, label: 'cat', color: '#3B82F6', cluster: 'Animals' }, + { x: 150, y: 100, label: 'dog', color: '#3B82F6', cluster: 'Animals' }, + { x: 100, y: 120, label: 'fish', color: '#3B82F6', cluster: 'Animals' }, + { x: 140, y: 60, label: 'bird', color: '#3B82F6', cluster: 'Animals' }, + { x: 170, y: 90, label: 'horse', color: '#3B82F6', cluster: 'Animals' }, + // Cluster: Vehicles + { x: 380, y: 280, label: 'car', color: '#10B981', cluster: 'Vehicles' }, + { x: 410, y: 300, label: 'truck', color: '#10B981', cluster: 'Vehicles' }, + { x: 350, y: 260, label: 'bus', color: '#10B981', cluster: 'Vehicles' }, + { x: 420, y: 250, label: 'bike', color: '#10B981', cluster: 'Vehicles' }, + { x: 390, y: 310, label: 'plane', color: '#10B981', cluster: 'Vehicles' }, + // Cluster: Food + { x: 440, y: 80, label: 'apple', color: '#F59E0B', cluster: 'Food' }, + { x: 470, y: 100, label: 'pizza', color: '#F59E0B', cluster: 'Food' }, + { x: 420, y: 60, label: 'bread', color: '#F59E0B', cluster: 'Food' }, + { x: 460, y: 120, label: 'cake', color: '#F59E0B', cluster: 'Food' }, + // Cluster: Tech + { x: 150, y: 280, label: 'laptop', color: '#8B5CF6', cluster: 'Tech' }, + { x: 120, y: 300, label: 'phone', color: '#8B5CF6', cluster: 'Tech' }, + { x: 180, y: 260, label: 'tablet', color: '#8B5CF6', cluster: 'Tech' }, + { x: 140, y: 310, label: 'mouse', color: '#8B5CF6', cluster: 'Tech' }, +]; + +const QUERY_POINT = { x: 160, y: 270, label: 'keyboard' }; + +function distance(a: { x: number; y: number }, b: { x: number; y: number }): number { + return Math.sqrt((a.x - b.x) ** 2 + (a.y - b.y) ** 2); +} + +const VectorDatabase2D: React.FC = () => { + const [algorithm, setAlgorithm] = useState('brute'); + const [showSearch, setShowSearch] = useState(false); + const [hoveredPoint, setHoveredPoint] = useState(null); + + const handleSearch = useCallback((): void => { + setShowSearch(true); + }, []); + + const handleReset = useCallback((): void => { + setShowSearch(false); + }, []); + + // Sort points by distance to query + const sortedByDistance = [...POINTS] + .map((p) => ({ ...p, dist: distance(p, QUERY_POINT) })) + .sort((a, b) => a.dist - b.dist); + + const topK = sortedByDistance.slice(0, 4); + const topKLabels = new Set(topK.map((p) => p.label)); + + // IVF clusters centroids + const clusters = [ + { name: 'Animals', cx: 136, cy: 90, r: 60, color: '#DBEAFE' }, + { name: 'Vehicles', cx: 390, cy: 280, r: 55, color: '#D1FAE5' }, + { name: 'Food', cx: 448, cy: 90, r: 50, color: '#FEF3C7' }, + { name: 'Tech', cx: 148, cy: 288, r: 55, color: '#EDE9FE' }, + ]; + + return ( +
+

+ Vector Similarity Search Visualization +

+

+ Words are embedded as vectors in 2D space. Similar concepts cluster together. Search finds + the nearest neighbors to a query vector. +

+ + {/* Algorithm selector */} +
+ {( + [ + { key: 'brute', label: 'Brute Force', desc: 'O(N) — compare all vectors' }, + { key: 'hnsw', label: 'HNSW', desc: 'O(log N) — navigable small world graph' }, + { key: 'ivf', label: 'IVF', desc: 'O(N/k) — inverted file index with clusters' }, + ] as const + ).map((algo) => ( + + ))} + + +
+ + {/* SVG visualization */} +
+ + {/* IVF cluster regions */} + {algorithm === 'ivf' && + clusters.map((c) => ( + + + + {c.name} + + + ))} + + {/* HNSW graph edges */} + {algorithm === 'hnsw' && ( + + {POINTS.map((p, i) => + POINTS.slice(i + 1) + .filter((q) => distance(p, q) < 120) + .map((q, j) => ( + + )) + )} + + )} + + {/* Brute force: show distance lines to query when searching */} + {showSearch && algorithm === 'brute' && ( + + {POINTS.map((p, i) => ( + + ))} + + )} + + {/* Search result highlights */} + {showSearch && + topK.map((p, i) => ( + + + + + ))} + + {/* Data points */} + {POINTS.map((p, i) => { + const isResult = showSearch && topKLabels.has(p.label); + const isHovered = hoveredPoint === p.label; + return ( + setHoveredPoint(p.label)} + onMouseLeave={() => setHoveredPoint(null)} + className="cursor-pointer" + > + + + {p.label} + + + ); + })} + + {/* Query point */} + + + + ? {QUERY_POINT.label} + + {showSearch && ( + + )} + + + {/* Legend */} + + + + + Query vector + + + + Data vectors (k-NN results circled) + + + +
+ + {/* Algorithm explanation */} +
+ {algorithm === 'brute' && ( +

+ Brute Force (Flat Index): Compares the query vector against every + single vector in the database. 100% accurate but O(N) — impractical for + millions of vectors. Used as a baseline for measuring recall of approximate methods. +

+ )} + {algorithm === 'hnsw' && ( +

+ HNSW (Hierarchical Navigable Small World): Builds a multi-layer graph + where each node connects to nearby neighbors. Search starts at the top layer (few nodes, + long-range links) and narrows down to the bottom layer (all nodes, short-range links).{' '} + O(log N) search time. Used by Pinecone, pgvector, Qdrant, Weaviate. +

+ )} + {algorithm === 'ivf' && ( +

+ IVF (Inverted File Index): K-means clusters the vectors into + partitions. At query time, only the nprobe nearest cluster centroids + are searched — reducing comparisons by orders of magnitude. O(N/k) per + query. Used by FAISS (Facebook AI Similarity Search). +

+ )} +
+
+ ); +}; + +export default VectorDatabase2D; diff --git a/src/features/database/index.ts b/src/features/database/index.ts new file mode 100644 index 0000000..ec7b0bc --- /dev/null +++ b/src/features/database/index.ts @@ -0,0 +1,15 @@ +/** + * Database & DBMS Feature Module + * Entry point for the Database learning module + * + * Covers database fundamentals including: + * - Database models (Relational, Document, Key-Value, Graph, Vector) + * - DBMS architecture (Query Processor, Storage Engine, Buffer Manager) + * - SQL fundamentals and query optimization + * - Indexing with B-Trees and Hash indexes + * - Transactions, ACID properties, and MVCC + * - Oracle vs PostgreSQL comparative architecture + */ + +export { default } from './DatabasePage'; +export { default as DatabasePage } from './DatabasePage'; diff --git a/src/pages/Home.tsx b/src/pages/Home.tsx index 13f575d..92675eb 100644 --- a/src/pages/Home.tsx +++ b/src/pages/Home.tsx @@ -227,11 +227,24 @@ const Home: React.FC = () => { level: 'Intermediate', duration: '4-5 hours', }, + { + icon: , + title: 'Database & DBMS', + description: + 'Master database internals, DBMS architecture, SQL optimization, B-Tree indexing, ACID transactions, and Oracle vs PostgreSQL', + path: '/database', + color: 'teal', + gradient: 'from-teal-600 to-cyan-600', + bgGradient: 'from-teal-50 to-cyan-50', + topics: ['DBMS Architecture', 'B-Tree Indexing', 'ACID & MVCC', 'Oracle vs PostgreSQL'], + level: 'Deep Dive', + duration: '4-5 hours', + }, ]; const stats = [ - { value: '15+', label: 'Interactive Modules', icon: }, - { value: '96+', label: 'Visualizations', icon: }, + { value: '16+', label: 'Interactive Modules', icon: }, + { value: '103+', label: 'Visualizations', icon: }, { value: '1000+', label: 'Code Examples', icon: }, { value: '24/7', label: 'Available Learning', icon: }, ]; @@ -269,7 +282,8 @@ const Home: React.FC = () => { allModules[12], allModules[13], allModules[14], - ], // Python, System Design, TypeScript, AI, Node.js, DevOps, Auth, Backend + allModules[15], + ], // Python, System Design, TypeScript, AI, Node.js, DevOps, Auth, Backend, Database icon: , color: 'emerald', description: @@ -302,7 +316,7 @@ const Home: React.FC = () => { const features = [ { icon: , - title: '89+ Interactive Visualizations', + title: '96+ Interactive Visualizations', description: 'See how engines, compilers, and frameworks work internally', }, { @@ -326,7 +340,7 @@ const Home: React.FC = () => { <> { actually work under the hood. For developers who want to understand JavaScript engines, Git internals, data structure performance, and framework architectures through{' '} - 89+ interactive visualizations. + 96+ interactive visualizations.

{/* CTA Buttons */} @@ -474,7 +488,7 @@ const Home: React.FC = () => { }} className="inline-flex items-center space-x-2 text-indigo-600 font-semibold hover:text-indigo-700 transition-colors" > - View All 14 Modules + View All 16 Modules
diff --git a/src/shared/constants/moduleNavigation.ts b/src/shared/constants/moduleNavigation.ts index 7433d1e..a591314 100644 --- a/src/shared/constants/moduleNavigation.ts +++ b/src/shared/constants/moduleNavigation.ts @@ -19,7 +19,8 @@ export type LearningModuleId = | 'nodejs' | 'devops' | 'auth' - | 'backend'; + | 'backend' + | 'database'; export interface LearningModuleConfig { id: LearningModuleId; @@ -135,6 +136,13 @@ export const learningModuleConfigs: Record = { @@ -436,6 +444,30 @@ const baseModuleNavigationSections: Record = { { label: 'Request Lifecycle', path: '/backend?section=Request%20Lifecycle' }, { label: 'Visualization', path: '/backend?section=Visualization' }, ], + '/database': [ + { label: 'Introduction', path: '/database?section=Introduction' }, + { label: 'Database Models', path: '/database?section=Database%20Models' }, + { + label: 'DBMS Architecture', + path: '/database?section=DBMS%20Architecture', + subItems: [ + { label: 'Query Processor', path: '/database?section=Query%20Processor' }, + { label: 'Storage Engine', path: '/database?section=Storage%20Engine' }, + ], + }, + { label: 'SQL Fundamentals', path: '/database?section=SQL%20Fundamentals' }, + { + label: 'Indexing & Optimization', + path: '/database?section=Indexing%20%26%20Optimization', + }, + { label: 'Transactions & ACID', path: '/database?section=Transactions%20%26%20ACID' }, + { label: 'Oracle vs PostgreSQL', path: '/database?section=Oracle%20vs%20PostgreSQL' }, + { + label: 'SQL vs NoSQL vs Vector', + path: '/database?section=SQL%20vs%20NoSQL%20vs%20Vector', + }, + { label: 'Visualization', path: '/database?section=Visualization' }, + ], '/': [], '/about': [], }; diff --git a/src/utils/theme.ts b/src/utils/theme.ts index 2941e4b..2d5a13f 100644 --- a/src/utils/theme.ts +++ b/src/utils/theme.ts @@ -132,6 +132,14 @@ export const theme = { border: 'blue-200', shadow: 'blue-200', }, + database: { + primary: 'teal', + secondary: 'cyan', + accent: 'emerald', + gradient: 'from-teal-50 via-white to-cyan-50', + border: 'teal-100', + shadow: 'teal-200', + }, }, layout: { // Standard section layout with hero + content grid