by samlambert on 9/9/24, 3:57 PM with 79 comments
by hinkley on 9/9/24, 7:45 PM
When the landing page gets too full/too many outgoing links, I start pushing links and paragraphs down into the child pages, to leave space for a fair share of timely links and on-boarding docs.
Similar and older links get pushed down into the sibling that best represents the topic. Then if the destination page is now too big, similar and older links get pushed down to their children. Eventually all of the outdated docs are three levels down from the landing page, where only historians and experts will see them. And sometimes as we finally decide how part of the system really should work, siblings get combined into one page, minus the speculative work that gets pushed down deeper in the tree. It works remarkably well. At the end of the day documentation is a search problem.
I highly recommend it for a Friday afternoon exercise when you want to be productive but you know starting a new task is a complete waste of time.
by yosri-xp on 9/10/24, 12:09 AM
The challenging part was evicting the expired keys from the BTree+ where the inserted keys would have TTL therefore we decided to fuse only one level branch and within the first sibling leaf nodes as it would be expensive if we perform clean up all the way up which would cause high lock contention and slow things down substantially specially when keys get inserted/deleted/updated.
Also we had to do sharding on top of the BTree+ to speed things up and reduce the high lock contention, that way we know what shard the the keys belong to and we lock the branch before performing any CUD, That way we can perform high concurrent operations on multiple shards/branches.
The clean up process might have some caveat and the Btree+ ends up unbalanced. We had to provide rebuild indexing feature so that would fix all the gaps if necessary to avoid extra clean up operations.
Again Thanks for the visuals.
by benwilber0 on 9/10/24, 12:15 AM
For one, it's enormous. Now you have to copy that 128bit int to every side of the relation.
Two, in most cases it's completely random. Unless you had the forethought to use something other than UUIDv4 (gen_random_uuid). So now you just have a bunch of humongous random numbers clogging up your indexes and duplicated everywhere for no good reason.
Use regular bigserial (64bit) PKs for internal table relations and UUIDs (128bit) for application-level identifiers and natural keys. Your database will be very happy!
by is_true on 9/10/24, 1:59 AM
Why don't let the user set that up on their browser
by VeejayRampay on 9/9/24, 6:45 PM
by seanman on 9/10/24, 2:04 PM
by sroussey on 9/10/24, 1:26 AM
I only wished that the reference to InnoDB storing data in the B tree itself is otherwise referred to as a clustered index.
MyISAM before it was non-clustered.
Oracle and others let you choose.
by tnvmadhav on 9/10/24, 8:46 AM
by dorbodwolf on 9/10/24, 5:33 AM
by misonic on 9/10/24, 8:03 AM