Highly Consistent Database

  • -1

    _aman about 1 year ago

    fault tolerant
    distrinuted

    reply
  • -1

    shyam_ 12 months ago

    what if one of the node in a shard goes down and comes online after sometime. Will the master invalidates the entries belong to the that particular node?

    reply
  • 3

    raviteja_yakkaladevi 11 months ago

    What are the cons if we use last modified time(solution given in highly available database with W+R>P) for knowing where the block is instead of maintaining a master?

    reply
    • 0

      KMeshU 9 months ago

      What if the last modified node itself goes down

      reply
      • 1

        raviteja_yakkaladevi 9 months ago

        W+R>P. This ensures the consistency even in the case that you were saying. You can read it here https://www.interviewbit.com/problems/highly-available-database/

        reply
    • 1

      piscado 3 months ago

      i think this "master" (or i'd say logger) simply acts like a write lock. for the previous high-A architecture, a read can be done in the process of a writing and gives stale data. in this case, on the other hand, we always know if the writing is finished since every read is going through the "master"

      reply
  • 2

    sarang 11 months ago

    how at paxos or raft?

    reply
  • 0

    steven_chow 6 months ago

    What are the advantages for this solution comparing with the high availability solution with Casandra when R == W == Replication Factor?

    reply
    • 2

      resurrectedVaibhav 5 months ago

      Cassandra/Dynamo solution is actually a complex solution and is focussed on business scenarios where writes are very frequent.
      That solution is not consistent in case of failures if you notice. I think the only way to make it consistent is to have a higher value of W + R thus decreasing the performance. Also, not to forget that to resolve vector-clock conflicts we need a complex algo in the client.


      Though here the load is not truly distributed.

      reply
  • 0

    shiyi_chen 6 months ago

    distributed transaction

    reply
  • 2

    samira_allahverdiyeva 5 months ago

    first, you said QPS is "Let's assume around 100k"m in the Assumptions part you say "Total estimated QPS : Around 10M ". I didn't get this part

    reply
    • 0

      sunnyk 4 months ago

      I agree, there is inconsistency in this requirement I think. would be safe to assume one and go ahead with that.

      reply
  • 0

    howard_liu 13 days ago

    another reason peer-to-peer system's consistency might break even with W + R > N: https://stackoverflow.com/q/42706811/3024143 In general, it seems to me these systems are designed for availability, not strong consistency.


    the proposed every-read-go-through-this-master-machine solution looks unlikely to me, as it could easily overload the master (as opposed to in GFS every client query chunk location once and cache it.), not to mention master's responsibility to sync each shard.


    Pinterest's sharding method (https://medium.com/@Pinterest_Engineering/sharding-pinterest-how-we-scaled-our-mysql-fleet-3f341e96ca6f) looks highly consistent to me, as it maintain single master per shard. When master dies the slave is promoted, which is still consistent despite some data between the lag will be unavailable. https://stackoverflow.com/a/25691863/3024143

    reply
Click here to start solving coding interview questions