"ADHD creates impulse control issues and, consequently, advertising takes advantage of a disability. Ergo, ad blockers are assistive devices and interfering with their operation for commercial gain constitutes a willful violation of the ADA."
Many ads on the street today (depending on the city) are displayed on monitors, & we can manufacture glasses with filters which blacks out TV screens from your vision!
Yesterday I described hardware for a map/filter/reduce database reading from flash storage, so how'd we write to that flash storage?
The trick hardware designers use for writing to flash memory is that if you manufacturing the insulating walls to the exact right ultra-thinness (and we have a large enough positive charge to attract it) electron probability can "tunnel" from the data wires to an isolated circuit. And stay there for decades!
The catch is that flash memory can be a bit too good at storing electrons, which in practice means they wear out over time. So operating systems or firmware need to minimize & spread out writes increasing its longevity.
To minimize writes we add some "RAM" chips which stores the data in transient memory cells made from capacitors (with a counter circuit & latch to periodically recharge them). Once we've filled a "block" with data (or we're losing power) we can write it to flash memory.
If these "blocks" are spread across all the different wafers that'll speed up the concurrent processing over these tables!
To spread the writes out I'd wait for the flash chips to fill up before running queries to read out all still-live rows via RAM so we can throw out the stale data & overwrite it with the compacted live data. A compacting GC!
Prior to this I'd only overwrite the rows to flag them as stale, once a certain transaction's committed. Thus speeding up transactions!
An UPDATE query wouldn't actually overwrite the selected rows, it'd DELETE the old rows whilst generating new rows (buffered in RAM) to INSERT.
I'd include internal tables listing the address of all blocks a table is stored in, a table of defective blocsk (judging by a Hamming Code attached to every table row), & the first free block for each wafer.
As simple techniques to increase device longevity whilst speeding up atomic transactions!
Regarding the Google leak I'll concur with @Seirdy : I don't trust any conclusions from these leaks as to how Google uses these metrics they gather.
Apparently it included docs, but we all know quickly those get out of date!
Yesterday I established that compiling SQL queries & many of the more tangential features of a relational database can be framed as queries themselves, just on internal tables which we already know the schema of. So today: How do we read the desired data?
The common approach today is to store extra electrons between a transistor & its enable wire, I'll get into how we write those electrons tomorrow! Now that we've mastered the technique, it can store enough data for most non-archivists!
For each of those flash wafers I'd include a CPU core with very little memory, separating data (read from Flash) vs code (uploaded by CPU). Thus letting it evaluating any filters, column-extraction, & synopsizing it wants!
I'd want it to be able to handle strings, ints, & floats including non-trivial maths like multiply, divide, & remainder. Then again minimal & segregated code storage can allow for a simpler instruction-decoding pipeline without branch prediction!
Unlike my hypothetical "Arithmetic Core" this would be non-trivial requiring multiple specialized ALUs for the different maths operations the caller might want. I've written plenty about this before, & I will again. So I won't now.
With small enough pipelines & RAM the control unit should still be very simple!
I'd include a memory-offset register to aid retrieving from the read database row, as more is read into it as a ringbuffer. Spread tables across wafers for optimal concurrency!