02 - In-Memory Databases (CMU Databases / Spring 2020)

Рет қаралды 28,796

Күн бұрын

Пікірлер: 23

@CppExpedition 9 ай бұрын

Thank you CMU database group, we are much appreciated for bringing to us this high quality content. No word exists to gratitude you properly

@alfin3644 3 жыл бұрын

Even when he is almost falling asleep he can give an engaging lecture. Kudos DB professor.

@mdkamaruzzaman5632 3 жыл бұрын

The most comprehensive lecture series on advanced database systems

@rohandvivedi 4 жыл бұрын

I really appreciate the lectures. thank you.

@joaquindragotto 2 жыл бұрын

This material is incredible ! Thanks you so much!

@why966 2 жыл бұрын

this very useful class, i want to be a professor like andy! if the subtitles of the videos can be exactly , it will be better!

@shengxu6331 4 жыл бұрын

the slides are perfect

@redixhumayun Жыл бұрын

Does anyone know where to find the course material he keeps mentioning throughout the video as things that were covered in the previous semester?

@gsh1784 3 жыл бұрын

Really nice lectures! I'm curious at 1:01:23, (if I understand the lecture correctly) why using stored procedures lead to "no overhead of restarting transactions"? What's the overhead we are talking about and why stored procedures can eliminate it?

@gsh1784 3 жыл бұрын

I found in the first paper of the reading list: "the time it takes to undo a transaction is slightly less than the time it takes to re-execute the transactions queries." This explains why restarting an aborted transaction has a low overhead in their experiments, but I'm not sure whether it is relevant to the use of stored procedures.

@andypavlo 3 жыл бұрын

If you are not using stored procedures, you have to send the abort exception back to the client. The client than has to process that exception and then re-execute the code in the application to start a new txn to retry. Lots of network round trips.

@gsh1784 3 жыл бұрын

@@andypavlo Got it, thanks!

@florianwicher 3 жыл бұрын

Same question, thanks

@furkanakyol3936 2 жыл бұрын

I think optimistic concurrency control is called optimistic because it is actually optimistic about the order of the currently running transactions. Basic TIO acts too quickly to assign timestamps for transactions without even knowing what they are going to read or write and then it might bite you if they are assigned poorly. Think of 10 transactions running in parallel and only 1 of them will write a block and other 9 is going to read that block. With basic TIO if you assign writing transaction a more future timestamp than others and it modifies the data physically before other transactions all other 9 transactions will be invalid because they will try to read future data. (or just the writing one will be invalid but still). But OCC will not assign any timestamps to all 10 of them and when validating it will know that the if writing transaction has the lowest timestamp it is all fine and all 10 transactions can commit. Am I right?

@lisztk1928 3 жыл бұрын

That would be great if someone could provide subtitles to these videos. The explanations are super clear but sometimes I get lost when I can't hear the word. Thanks

@vimalsheoran8040 4 жыл бұрын

Professor I've been writing the synopsis for the papers you've provided for additional reading in a Notion document can I submit it to the form? I'm not a CMU student.