1:58 - Write Operation occurs in Master DB, Read op occurs from Slave DB 2:58 - Inconsistent situation 3:58 - Sharding [All are having same power unlike Master/Slave] 5:17 - N times efficient 6:42 - Joins between them 7:36 - CAP Example 9:43 - Availability 10:11 - Partition Tolerance - Even if the link b/w 2 serves A and B goes down, they will still be able to communicate[Via C] We can ONLY have any 2 of CAP - Most of the Data Stores provide AP Eventual consistency - You will be getting old Un-updated data readily VS Strong Consistency offers up-to-date data but lately after updation of all nodes. 20:10 - BASE
@PrashantGadagiUSC4 жыл бұрын
A comment about CAP theorem. In general, distributed systems don't have control over network failures. So, partition has to be tolerated. It's actually a choice between Consistency and Availability. In case there are no network failures (ideal scenario), all 3 can be satisfied. here's the excerpt from Wikipedia - "No distributed system is safe from network failures, thus network partitioning generally has to be tolerated. In the presence of a partition, one is then left with two options: consistency or availability. When choosing consistency over availability, the system will return an error or a time out if particular information cannot be guaranteed to be up to date due to network partitioning. When choosing availability over consistency, the system will always process the query and try to return the most recent available version of the information, even if it cannot guarantee it is up to date due to network partitioning. In the absence of network failure - that is, when the distributed system is running normally - both availability and consistency can be satisfied. CAP is frequently misunderstood as if one has to choose to abandon one of the three guarantees at all times. In fact, the choice is really between consistency and availability only when a network partition or failure happens; at all other times, no trade-off has to be made. Database systems designed with traditional ACID guarantees in mind such as RDBMS choose consistency over availability, whereas systems designed around the BASE philosophy, common in the NoSQL movement for example, choose availability over consistency. The PACELC theorem builds on CAP by stating that even in the absence of partitioning, another trade-off between latency and consistency occurs." Source: en.wikipedia.org/wiki/CAP_theorem
@devanshmalhotra6308 Жыл бұрын
Best channel for understanding System Design and other software development aspects. Cracked multiple interviews by going through your videos. Thanks a lot man. Great stuff.
@shahidsarwar2563 жыл бұрын
Thank you for serving humanity. Levi and you are one of humanity's greatest soldier.
@jesus-love5 жыл бұрын
You are doing a very good work. You deserve a lot more subscribers and views. Thank you so much.
@akn43365 жыл бұрын
A in ACID stands for Atomicity not Availability
@akn43365 жыл бұрын
@@kittgs Thanks for the comment. Just fixed it.
@TeluguAbbi4 жыл бұрын
A more relevant term for A in ACID is abortability. Source: Klepman
@mitsiddharth6 жыл бұрын
Nice explanation. Your observation about current systems choosing AP over C applies for majority of cases. There is one special class of apps which need consistency though: e-wallets, banking etc. Discussing some approaches to mitigate inconsistencies on those systems might be interesting.
@jesus-love5 жыл бұрын
You could get all 3 of them with Cassandra. It's all about configuring it properly.
@renning225 жыл бұрын
blockchain please.
@ibknl19862 жыл бұрын
Thank you. Very nice explanation. May God ALLAH guide and bless you
@haoyuanhuang50983 жыл бұрын
It's interesting that Base and Acid are terms that sits at the two ends of a pH scale in chemistry, a fair analogy of the different characteristics between an eventual consistency and a strong consistency RDBMS.
@VinodMoorkoth3 жыл бұрын
Good observation :)
@iambhanu75 жыл бұрын
P in CAP: The definition listed here "Even in case of internal network failure, the system should be up and running" is very misleading. I think it should be "Even in case of internal network failure, the guarantees (either C or A) promised by system will continue to hold"
@agraman263 жыл бұрын
can you explain how to solve the problem at 5:45?
@senthilk3962 жыл бұрын
Bhanu is correct. Partition happens by default. We should choose either C or A
@auroshisray91403 жыл бұрын
Great work sir!
@wastabirrajvee88676 жыл бұрын
Excellent video really liked it. Thank you so much for your efforts.
@m13m6 жыл бұрын
A video on consistency model would be great
@nwcutee4 жыл бұрын
17:20 Its not ok to forgo consistency.. It depends on the application you are working/designing. Agree with systems like FB, insta etc but not with traditional enterprise applications in domains like health, banking, insurance etc.. Also, reading from slaves and writing to master is not a bad strategy always.. Some major companies still use it.. again it depends on the use case.. bitbucket.org/blog/scaling-bitbuckets-database
@mgundawar4 жыл бұрын
CAP is frequently misunderstood as if one has to choose to abandon one of the three guarantees at all times. In fact, the choice is really between consistency and availability only when a network partition or failure happens; at all other times, no trade-off has to be made
@zishanshaikh30685 жыл бұрын
Great job
@w.maximilliandejohnsonbour7255 жыл бұрын
Very informative video...!!!!!.
@shayelmualem32185 жыл бұрын
Thanks so much for this great explanation!
@AshutoshKumar-xz9hs3 жыл бұрын
If we are partitioning in master and slave form then how we can write to slave, directly as you said ? In that case we need to make all db as master right? Correct me if I am wrong
@ajaywadhwa33983 жыл бұрын
Is your playlist is in sequential order ?
@dikan74213 жыл бұрын
thank you, you rock the concepts
@9fxhrlif9er4 жыл бұрын
Some NoSQL databases like MongoDB are not only fully ACID compliant, but it's also fully consistent. Even DynamoDB has consistent read mode.
@anuragreddygv3236 жыл бұрын
Nice 👍
@jayaprakashtr5625 жыл бұрын
Good video. But I think consistency in ACID and CAP are different. In ACID it talks about database invariants/rules such as cascades, constraints etc. Also keeping 'P' optional in CAP may not be possible in distributed systems as we can't avoid network failures.
@vikas200135 жыл бұрын
Why P is always included when we cannot handle network failures?
@adityagupta3752 жыл бұрын
I thought the same...its not in our hand to choose partition (P) or not....Design should be made with a mindset that if partition occurs .... what are you going to prefer ? consistency or Availability (i.e essentially choosing your partition tolerance strategy). Partition not happening is the best case possible cos then you have both consistency and availability.
@m13m6 жыл бұрын
In reality you can really choose either AP or CP you can't build system which is CA (network is reliable fallacy)
@sharthakghosh9706 жыл бұрын
Awesome explanation !!
@sweetyb32875 жыл бұрын
Great explanation again! Have tried reading about CAP theorem but your video clarifies it very nicely. Can you please post the link of the video that you mentioned at the end where you'll use cassandra DB to explain the distributed DBs concept?
@sijung64943 жыл бұрын
if sharding is used , is consistency solved? if so when we need to worry about consistency? Mongodb uses both master slave and sharding?
@ashrafulalamfoysal86724 жыл бұрын
Hey!can you solve this problem : An owner designed a security system with two sensors, motion and heat, and an alarm for his home. If the system is disabled, there is no alarm even if the two sensors detect a stimulus. When the system is enabled, it triggers an alarm if either of the two sensors detect a stimulus. The triggering of the alarm is done by passing a signal to the system output. The system can be considered to have two blocks, A and B. Block A sends the signal to block B whether to pass the alarm sound or not. Design the circuits of the two blocks.
@hariniswaralahari88535 жыл бұрын
Thank You so much for your explanation. Could you please do a session on system design of the GrubHub or Seamless system.
@algorithmimplementer4155 жыл бұрын
Geez .. so much time on CAP theorem!! Did you explain how to merge/join the results from two nodes which triggered the discussion of CAP?
@HimanshuSingh_924 жыл бұрын
Even I wanted to learn about that. Can you please share here if you find anything related to it? Thanks.
@msha48874 жыл бұрын
For financial application we can't do a AP model. Good and information.thanks
@IC-kf4mz4 жыл бұрын
Here only one type of master and slave is discussed. Does anyone know where I can find some examples of distributed databases?
@nishantsehgal4555 жыл бұрын
Can you explain how RDBMS is COnsistent and Highly available as per CAP therorem? system can either be CP or AP according to me.
@manjunathdavanam39015 жыл бұрын
Can you please make video on columnar storage
@santoshdl4 жыл бұрын
key is how to write the application that can check the index of records on a pre-existing database and shards it automatically when in need. scalar function
@imMavenGuy2 жыл бұрын
It is never a choice to pick any 2 in CAP theorem - partitioning is actually partition-tolerance which is a static problem with distributed data stores connected via networks, thus the trade-off is between Availability and Consistency. [AP or CP]. Also, the CAP theorem is fading out and the PACELC theorem is the more detailed extension of it.
@imMavenGuy2 жыл бұрын
CA type databases are generally the monolithic databases that work on a single node and provide no distribution. Hence, they require no partition tolerance.
@Inception13383 жыл бұрын
Does somebody know about models for distributed database that sync only on demand to keep traffic low? I see mongoDB is a choice but I cannot find material on how it handles inconsistency and sync on demand.
@vinays85466 жыл бұрын
Small correction I think A in ACID stands for Atomicity not Availability..
@TechDummiesNarendraL6 жыл бұрын
Your absolutely rite, slip of tongue:|
@bhavyabansal11432 жыл бұрын
When we already shared, why write on one shared will go to other? I thought each shards will have replicas which makes sense but why shard s1 will replicate to shard s2? Does not make sense
@arisrahmanudin90945 жыл бұрын
thank you, that is clear my doubt
@gokukanishka3 жыл бұрын
under which CAP scenario Conistancy AND Availability will exist together ?
@termoyad2 жыл бұрын
Under none. It can be available and eventually consistent though
@MrSushil4305 жыл бұрын
Nice videos :)
@AbhishekSharma-si8ui4 жыл бұрын
AWESOME
@subee1285 ай бұрын
Thanks
@soumya74303 жыл бұрын
how is consistency + partition tolerance possible , if you bring in partition tolerance arent you compromising consistency almost always
@SunilPatil-hs8wd4 жыл бұрын
In ACID principle A stands for Atomicity
@vikas200135 жыл бұрын
Why P is always included when we cannot 100% handle network failures?
If I choose A & P meaning, my system will always be available, and the partition will always be working (Always Connected). So If I have chosen A & P, how come the problem of 'Inconsistency' can occur?
@pratikshasingh54642 жыл бұрын
In fact, the choice is really between consistency and availability only when a network partition or failure happens; at all other times, no trade-off has to be made. (Taken from Wikipedia & comments below). Got my answer. Added this, just in case anyone has the same dilemma.
@arifmalikoracledba97573 жыл бұрын
Mate, ACID is A for Atomicity ^& I for Isolation (NOT availability & Integrity !!)
@WylliamJudd4 жыл бұрын
I think you could have explained CAP Theorem better by showing an AP setup, and then showing how you can sacrifice one of them to gain consistency.
@Knigh7z4 жыл бұрын
You don't sacrifice a or p, you sacrifice c or a in the event of p - choose consistency or availability in the event of a network partition.
@at_tap6 жыл бұрын
ACIP - Atomicity,Consistency,Isolation,Durability :: Its Atomicity not Availability
@TechDummiesNarendraL6 жыл бұрын
Oh yess!! My bad. I will update the video. Thanks
@Atpugtihsrah6 жыл бұрын
It's ACID not ACIP.
@blasttrash5 жыл бұрын
@@Atpugtihsrah lol
@reddykiran93206 жыл бұрын
Can you give an example of CP
@subvind5 жыл бұрын
PostgresQL
@rohitkumarsharma46476 жыл бұрын
Suggestion : You should not look back and forth between the board and the camera so often, it is completely distracting when you turn your head twice every second. Try finishing a concept once, and then turning to the camera to discuss. Thanks.
@TechDummiesNarendraL6 жыл бұрын
Never thought about it, Thanks for the suggestion
@arun57416 жыл бұрын
Rohit Kumar Sharma U r my hero. Can u pls share ur number
@ayushjindal49812 жыл бұрын
can anybody pls tell me how t achieve CA and CP?
@vaibhavgoel92545 жыл бұрын
Sorry but... where was RDMBS scaling ???
@krishsingh1113 жыл бұрын
What a terrible explanation of CAP . He kept repeating same thing over and over again