Database of Databases

Post by agambrahma » Wed, Sep 16, 2020, 7:24 PM UTC

fizixer wrote: post #17

Any good learning resources for implementing your own DBMS, and DB internals? (not DB theory, not SQL, not intro).

Post by kreetx » Wed, Sep 16, 2020, 7:46 PM UTC

samsquire wrote: post #9

They're using SQLite which is single threaded and single user by design. So this website will not be able to service that much traffic.

Post by abnry » Wed, Sep 16, 2020, 8:14 PM UTC

rsecora wrote: post #48

chickenpotpie wrote: post #3

Reminds me of my favorite Wikipedia article: https://en.wikipedia.org/wiki/List_of_lists_of_lists

This article itself is a list of lists, so it contains itself.

Post by the_duke » Wed, Sep 16, 2020, 8:38 PM UTC

simonw wrote: post #34

samsquire wrote: post #9

They're using SQLite which is single threaded and single user by design. So this website will not be able to service that much traffic.

SQLite isn't single threaded - and it can support multiple readers very well. The limitation with SQLite is that it doesn't support concurrent writes well - it needs to take a lock on the entire database to perform a write. Writes are crazy fast (a few ms) so this often isn't a problem - but it does mean you wouldn't want to use it to build a site that has many people writing at once, like Hacker News for example. Fo…

Post by tbran » Wed, Sep 16, 2020, 9:17 PM UTC

pfraze wrote: post #12

tyingq wrote: post #10

Earlier quoted context omitted.

Should be fine for reads. Sqlite.org is dynamic, pulling from sqlite data for ~20% of the pages, and it does fine with HN piling on. The single threaded would be an issue for writes, but I don't see why they would be doing writes for a page view. See https://www.sqlite.org/whentouse.html

Also, caching layers. Presumably a service uses SQLite to simplify their ops. So long as the caching layer is equally simple to maintain, then SQLite continues to make sense to me