Web Application & Software Architecture 2 Flashcards
Working with NoSQL Databases:
Ease of Development:
Simplified Operations:
No stress of managing complex queries or relationships.
Efficiency:
Key-based object retrieval leads to faster operations.
Popular NoSQL Databases:
Industry Usage:
Examples include MongoDB, Redis, Neo4J, Cassandra, Memcache, etc.
Performance Comparison: SQL vs. NoSQL
Technology Performance:
Equality in Performance:
Relational and non-relational databases are equally performant from a technology benchmarking standpoint.
Dependence on System Design:
System design and architecture play a critical role in performance, more so than technology choice.
Performance Comparison: SQL vs. NoSQL
Tech Stack Choices:
Popular Tech Stack Preferences:
Tech stacks like MEAN (MongoDB, ExpressJS, AngularJS/ReactJS, NodeJS) often prefer NoSQL databases.
Reasons for Prevalence:
Convenience, availability of resources, and commercial factors influence tech stack choices.
Performance Comparison: SQL vs. NoSQL
Importance of Fit:
Use Case Alignment:
Focus on picking the technology that best suits the specific use case rather than following popular stacks blindly.
Performance Comparison: SQL vs. NoSQL
Performance Factors:
Application Architecture Impact:
Performance heavily reliant on architecture, database design, network latency, etc.
Complexity Impact:
Join-heavy relational databases may impact response times but can match NoSQL speed when simplified.
Real-World Examples:
Facebook and Quora:
Facebook’s MySQL Use:
Utilizes MySQL for storing user social graphs, making engine tweaks to suit its use case.
Quora’s Efficient MySQL Use:
Efficient partitioning of data in MySQL achieved at the application level.
Emphasis on Design:
Design Impact on Performance:
Well-designed SQL data stores often outperform less optimized NoSQL stores.
Polyglot Persistence:
Hybrid Database Use:
Polyglot Persistence Concept:
Leveraging multiple databases (SQL and NoSQL) in an application for varied persistence needs.
Common Practice:
Large-scale online services often use a mix of SQL and NoSQL for optimal persistence behavior.
Benefits of Polyglot Persistence:
Tailored Solutions:
Specific Data Needs:
Selecting the right database for each unique data storage and access requirement.
Enhanced Performance:
Optimized Performance:
Improved performance by leveraging specialized databases for different functionalities.
Diverse Features:
Utilizing Unique Features:
Accessing and utilizing specific database features tailored for distinct purposes.
Scalability and Flexibility:
Scalability Support:
Scalable solutions catered to varied data handling scenarios.
Drawbacks of Polyglot Persistence:
Complexity Concerns:
Increased Complexity:
Challenges in integrating, managing, and maintaining multiple databases together.
Learning Curve:
Diverse Skill Set:
Requires expertise across different database technologies.
Real-World Application:
Example Scenario:
Social Networking App Design:
Utilizing multiple databases (relational, key-value, wide-column, etc.) to serve different functionalities within the application (user relationships, session management, analytics, ads, search, etc.).
Multi-Model Databases
Integration of Different Models:
Support for Multiple Models:
Enable usage of various data models (graph, document-oriented, relational, etc.) within a single database system.
Unified Database System:
Eliminate the need for managing multiple databases or services for different data models.
Operational Simplification:
Reduced Complexity:
Minimize operational complexities associated with managing multiple persistence technologies.
Single API Integration:
Provides access to different data models through a unified API
Popular Multi-Model Databases:
Notable Examples:
ArangoDB:
Known for its multi-model capabilities supporting graph, document, and key-value data.
CosmosDB:
Microsoft’s offering providing multi-model support for various data types and APIs.
OrientDB:
Combines graph and document capabilities within a single database.
Eventual Consistency
Eventual consistency is a model where datastores prioritize high availability over immediate consistency across all nodes in a distributed system. It’s a fundamental concept in distributed systems, ensuring data eventually reaches a consistent state globally, even if momentarily inconsistent across different nodes or geographical regions.
Key Aspects of Eventual Consistency:
High Availability Focus:
Primary Objective:
Prioritize system availability and continuous write operations over immediate global consistency.
Data Propagation Delay:
Propagation Timeframe:
Data changes take time to propagate across distant nodes or geographic zones.
Momentary Inconsistencies:
Users may observe temporarily different or outdated data due to propagation delays.
Strong Consistency
Data must be consistently the same across all nodes at any given time, requiring locking nodes during updates to ensure synchronicity.
Strong Consistency
Social Application
In a microblogging site, implementing strong consistency would involve locking all nodes globally when a user in one zone updates a post, preventing concurrent updates until a consensus is reached.
Strong Consistency
Locking Nodes
Nodes are locked during updates to ensure only one user can modify data at a time until a global consensus is achieved.
Strong Consistency
Real-World Application: Stock Market System
In financial applications like stock markets, strong consistency ensures users across regions see the same stock prices, preventing chaos due to simultaneous updates.
Strong Consistency
Challenge of Strong Consistency: Scaling and Availability
Strong consistency impedes scalability and availability, limiting concurrent updates while ensuring data consistency.
Strong Consistency
Implementation Strategy: Queuing Write Requests
Managing write requests in a queue ensures strong consistency but can limit system scalability. Details on this are covered in a message queue chapter.
Strong Consistency
Impact on ACID Transactions:
Strong consistency enables ACID transactions but hinders the ability to scale globally due to concurrent update restrictions.
Strong Consistency
Tradeoff with NoSQL and Distributed Systems:
NoSQL databases prioritize scalability and availability, sacrificing global ACID transactions due to their inherent design.
Strong Consistency
Purpose of NoSQL Technology:
NoSQL was developed to scale and ensure high availability, compromising on strong consistency for these benefits.
Strong consistency ensures synchronized data but constrains system scalability and concurrent updates, contrasting with NoSQL’s emphasis on scalability and high availability.
CAP Theorem
In case of network failure, the system can prioritize either availability or consistency, not both simultaneously.
CAP
Trade-off Explanation
During node failures, prioritizing availability allows continued write operations, leading to potential inconsistency upon offline nodes’ return.