Get my Fundamentals of Database Engineering course database.husseinnasser.com

I think this is one of the MOST UNDERRATED tech channels. Stay blessed, man. Very, very high quality content. Amazing!

@victorray9369

Жыл бұрын

True

@bdidue6998

Жыл бұрын

It's only underrated because he REALLY likes to hear this voice, and talks incredibly slow.

@curious-steps

Жыл бұрын

+1

@dindips

10 ай бұрын

@@bdidue6998 you increase the youtube play speed

@ivan.jeremic

4 ай бұрын

@@bdidue6998learn to code

Waiting for this since long time. Thank you for providing this information.

Yoooo have to do Postgres internals all the way from storage to query planning please!

@igor6133

Жыл бұрын

This!

@pearwatch1358

Жыл бұрын

yoooooooooooooooooooooooooooooo fucvk yes

@svetlanamaykhova4119

Жыл бұрын

+1

@ankitgautam1248

Жыл бұрын

+1

@zelvaman

Жыл бұрын

Yes please

Thanks for creating these videos. Definitely worth the time 🚀

Pretty neat, Thanks a lot Hussein. Looking forward your video about NewSQL DBs like TiDB

I am addicted to your videos, thank you sir

Quality videos Sir! thanks a lot :)

Waking up to a long form Hussein video on a bright Saturday morning 🌞 is one of the best ways to get going

The main difference in RDBMS and “NoSQL” is denormalization and querying efficiently instead of joins. It can be done in PG of course.

Thanks a ton for these videos. Please try making an architecture video for cassandra database as well.

Just next level stuff

Designing Data-Intensive Applications by Martin Klepmann is the go to reference for anyone who wants to understand the differences between different needs and pros and cons of each.

@shiplu.mokaddim

Жыл бұрын

I agree, but that that book doesn't contain details.

Column level or field level locking can cause problems if value of other column/field is being set based on the value of another column/field which suddenly someone has changed. Though if the read operation was performed in the same transaction in which update is being performed, we can prevent this issue.

Thanks!

Hussein is the gift that keeps on giving. 🙏

around @37:00 when discussing the clustured index; I'm assuming the clustured index is stored in RAM but it has the actual document in the clustured index so how is it saved on disk.

Wow, this was interesting! Moving from 2 io logn searches in So the max size of a doc that can be stored in mongo is 16MB, after compression from json to bson lets say the size of the doc is 1MB and the leaf_page_max is 32KB, that means, if we had a document of size 1MB and we search by _id, and we want the entire document, there would be around 32 io calls (1mb/32kb); since we can only fetch one page in 1 io? :o

❤

I had a question.. What happens if I update/replace an existing document with a much bigger document? How does the re-adjustment of the concerned data and the adjacent data happen in the disk? Does compression somehow solve this problem?

can we have next video on solving the double booking problem with timeout by using optimistic locking in mongoDB ?

I love the your channel and the content you post , but I am trying to find more channels like yours with in depth explanation on topics to fill my yt feed with such videos but couldn't find many. Feel free to reply to this commend with recommendations .

Awesome

In the 60’s and 70’s storage was incredibly expensive. So it was clever to use tables. You could store more for less. You pay in write/read performance. Now storage is dirt cheap. So you pay a small amount in storage but you get horizontal scaling and more performant write/read. There are other differences like ACID compliance but I think it’s good to know the history and motivations.

Hi @hussein Want to understand 1 concept. Since file system allows complete page to be read and flushed Then how is sequential io fast? The one we use for WAL. Wouldn’t that sequential io have to write the entire page back to disk? Please help me clarify this doubt. Thanks.

@egasimov

Жыл бұрын

Good point, Let me clarify the misconception. WAL files are append only on-disk data structure in which changes for transactions are appended to end of file via utilizing sequential access pattern, not random access. There is common misconception that disks are slow, but this is really only the case for random access. On disk data structure(i.e WAL files, append only for storing *changes not data itself )to take advantage of the sequential access pattern, the modern disk drives in a RAID configuration( i.e., with disks striped together for higher performance) could comfortably achieve several hundreds MB/sec of read and write speed.

is there a way to like many times in you tube ? excellent explanation. Thanks @hussein

Question around 14:00 ---> How is writing to WAL different from writing to data file? Same risks apply to both... Flushing pages of data file must be same as flushing pages of WAL. So, what does DBMS really achieve by offloading writes to WAL files from data files?

@nitishbhatia25

Жыл бұрын

Same doubt I also had. If you find out the answer to this, please post it here by tagging me. Thanks

@egasimov

Жыл бұрын

I will share my opinions to clear doubts. Writing to data file - uses random access Writing to wal file - uses sequential access. Sequential access is faster than random access. For Durability, apart from writing to log file, also checkpoint approach used to synch in-memory dirty pages with on disk data pages. If DB crashes, before synch happened, no worries. We have wal file, based on that data pages can be constructed again. No data loss will happen, if transaction committed successfully.

@darpanmalhotra2

Жыл бұрын

@@egasimov that's the whole confusion I have... WAL records are also going into a file on disk... So what if there's a crash before that sync operation? Or, are we saying WAL file writes are synchronous ( i.e. call fsync() immediately) and data file writes are asynchronous ( background writers).

@egasimov

Жыл бұрын

Q: So what if there is crash before that synch operation? A: After crash, dbms first check checkpoint where it left off and starting from that point trying to update on disk data pages - which already maybe stale, with help of changes already existed in WAL file Q: WAL file writes are synchronous? A:After changes are appended to WAL file, transaction will be committed successfully and sent message: “Transaction successfully committed” to client. Probably, dbms buffers the changes and then trying to append them to WAL file to reduce IO rather than calling each time fwrite() when transaction was asked to commit. Q: Data file writer are asynchronous? A:Background writers works as job that constantly are trying synching in memory pages with on disk pages in certain time interval.

A full-sized, long form Hussein video... that's an easy click!

How could people dont like sql? Its so cool!

So we can drop MySQL for Mongo finally ?

I'm confused. In WAL, If writing to the disk is expensive so instead we write in memory and to the log file. Isn't writing to the log file as expensive as writing to the data file directly ? Where is the performance gain ? Unless writing to the log file is faster than writing to different place in data files. Is that it ?

@egasimov

Жыл бұрын

Good point, Let me clarify the misconception. WAL files are append only on-disk data structure in which changes for transactions are appended to end of file via utilizing sequential access pattern, not random access. There is common misconception that disks are slow, but this is really only the case for random access. On disk data structure(i.e WAL files, append only for storing *changes not data itself )to take advantage of the sequential access pattern, the modern disk drives in a RAID configuration( i.e., with disks striped together for higher performance) could comfortably achieve several hundreds MB/sec of read and write speed.

33:26 That’s not what a clustered index is, what you described is an Alternative 1 type index, which is clustered by nature. Commonly, indexes are Alternative 2, where the leafs nodes only store the key and a pointer to the page (for a B+ tree index), but they can be clustered as well

The so called 'NoSQL' movement purpose was to create a new breed of storage engines that could leverage distributed computing and separate storage from compute. That required a huge investment from companies and community in terms of time so the frontent part for those new breed database engines wasn't a priority at the beginning. So many people mistakenly saw this as a war against the old standard interaction protocols (SQL etc) missing the bigger picture. Now after a decade or so we see all those new breed databases embrace all the concepts of the past (sql, tables, columns etc). Just a clarification for those they think structure was the motive behind 'NoSQL'

@pearwatch1358

Жыл бұрын

the mongodb docs have a very "us vsd. them" tone, doesnt rly coincide with what youre saying

Couchdb next 👍👍👍👍

🎉

Could you please make video on JunoDB

Hussein, Why don't you create a course for mongodb in depth? That will be very helpful to us.

@alvn2730

Жыл бұрын

Mongo offers the training for free

Can you please also make a video on Postgres internals?

MySql architecture please

RAM doesn't have single byte write either. Most RAM chips have a 64-bit bus, which is 8 bytes.

The evolution has nothing to do with JSON, etc. Relational DBs emerged out of a need to use disk efficiently. As disk storage became cheap, NoSQL dbs became a feasible option.

NoSql 😂

You calling this "internal"?????Couldn't be more abstract...

SQL Creates an Abstraction between the Programming Business Logic and the Underlying Database Storage. The Database Administrator, Can Make Changes to and Performance Tune The Database. Without breaking The Programming Business Logic.

MongoDB = Hierarchical Database, Like Mainframe Database: IMS. You Don't Understand WHAT a Relational SQL Database System is and How it Improves Perfromance.

Thanks a ton for these videos. Please try making an architecture video for cassandra database as well.

❤