Merge pull request #123 from scalableinternetservices/rdbms_no_sql

Rdbms no sql

schedule.md

@@ -151,7 +151,7 @@ The following schedule is subject to change, and many slide links are not yet ac
 <!-- - #### Wednesday November 22: Zoom Guest Lecture -->
 
 - Deep Dive: Load Testing with Tsung [slides](/slides/2024f/10_tsung/index.html)
-- Non-Relational Data Stores
+- Non-Relational Data Stores [slides](/slides/2024f/13_nosql/index.html)
 
 ### Tasks
 
@@ -174,7 +174,7 @@ The following schedule is subject to change, and many slide links are not yet ac
 
 <!-- - #### Wednesday November 29: Zoom Guest Lecture -->
 - Web Security
-- Guest Lecture (Th 11/21)
+- Guest Lecture w/ Andrew Mutz (Th 11/21)
 
 ### Tasks
 

slides/2024f/12_rdbms_scaling/index.html

@@ -504,6 +504,11 @@
 
 Like with partitioning, no joins can automatically be performed across these partitions.
 
+???
+
+* Parttion splits data sets of the same schema
+* SOA splits segments of the application based on function
+
 ---
 
 # SOA Stack
@@ -517,6 +522,13 @@
 
 .center[![Service Oriented Architecture](soa_stack.png)]
 
+???
+
+* Front end application server talks to services
+* Services may talk to other services
+* Services may talk to databases
+* Front end application server may talk to databases
+
 ---
 
 # SOA Functions
@@ -531,6 +543,12 @@
 
 .center[![Service Oriented Architecture](soa_stack.png)]
 
+???
+
+* Contrast this with sharding where the data is split by some criteria
+* Ex: SaaS application where Users, Billing and Acconts are sharded by customer
+* vs. SOA where Users, Billing and Accounts are separate services
+
 ---
 
 # SOA Communications
@@ -578,17 +596,11 @@
 
 1. Comments service can track comments and replies for each submission.
 
---
-
 2. Submissions service can be responsible for all the links that are submitted.
 
---
-
 3. Communities service can store the list of communities along with their
    creator.
 
---
-
 4. Users service can manage the users in the system.
 
 ---
@@ -639,8 +651,6 @@
 - Via Async message passing (message brokers: RabbitMQ,
 ActiveMQ, Apache Kafka, Amazon SQS, Google Pub/Sub, etc.)
 
---
-
 [Source: Designing Data-Intensive Applications: The Big Ideas Behind Reliable,
 Scalable, and Maintainable Systems
 by Martin Kleppmann](https://dataintensive.net/)
@@ -661,15 +671,15 @@
 
 ## Weaknesses
 
-* May not scale with the number of users (e.g., increased load to
-  authentication service)
-
 * Transactions across services do not exist
 
 * Consistent DB snapshots across services do not exist
 
 * Application logic required to join data
 
+* Some service may grow disproportionately to others
+  * sharding / partitioning might still be neccessary
+
 ---
 
 class: center inverse middle
@@ -685,6 +695,10 @@
 This graph shows significantly more _reads_ than _writes_. This may be the case
 for your application.
 
+???
+
+* More reads than writes
+
 ---
 
 # Database Horizontal Scaling
@@ -702,6 +716,10 @@
 ]
 .right-column[![Database Primary Replica](database_master_replica.png)]
 
+???
+
+* Horizontal scaling is easy for read-only copies
+
 ---
 
 # Database Replication
@@ -722,6 +740,11 @@
 transaction to its replicas but does not wait to see if the transaction is
 applied.]
 
+???
+
+* Wait until all replicas have applied the transaction
+* Wait until some replicas have applied the transaction
+* Don't wait for any replicas to apply the transaction
 ---
 
 # Database Replication Trade-offs
@@ -828,6 +851,16 @@
 
 https://www.postgresql.org/docs/9.1/warm-standby.html#SYNCHRONOUS-REPLICATION
 
+
+???
+
+* What is the use case for replication
+Tradeoff between consistency and performance
+* High availability with zero data loss?
+  * Synchronous replication
+* High availability with some data loss?
+  * Asynchronous replication
+
 ---
 
 # Demo App and Read Replicas