Regarding the second question, my problem is storing information on procedurally generated bits of world (geology, biosphere and atmosphere, for example, so it could amount to quite a large amount), that the player is not currently close to.
You can save it to disk and read it back in as needed. That's what we did in AVWW1/Valley2 with one file for each "chunk" (contiguous side-view space).
That said, I'm really
happy our more recent games don't require such a model. FWIW.
As far as tiers of storage and whatnot:
1) Registers: these are the literal sets of latches (or whatever they're called) in the CPU's arithmetic logic unit (ALU) that are directly connected to the Adder circuit and other such things that perform machine instructions. So adding two numbers already in registers is generally a single-cycle operation.
2) L1 Cache: this is a small pool of RAM-like (iirc) memory on the CPU itself, physically close to the action and very high-speed design/tech for minimal latency of retrieval.
3) Generally there's an L2 cache that's bigger and slower than the L1. Some machines have an L3 cache that's even bigger and even slower, iirc.
4) RAM: these are the sticks you actually plug into your machine when building it. They're much slower than cache (iirc) but can be much bigger. Nowadays most applications can run entirely in RAM on a decent machine (with 8+ GB of it), though this has not always been the case. So generally in an app you don't have to worry about anything "lower" than this for actual operation. But if you need more than, say, 1.4GB of actual data you need to investigate a 64-bit app (not possible with Unity right now, iirc) or some kind of disk-saving shenanigans like we did with AVWW1/Valley2.
5) Disk: the catch-all. Could be platter-based HDDs or solid state drives, or some combination. Platter-based drives (the standard until SSDs came around) are sloooooooooow. Retrieval of information involves actual physical motion of the platter. They've gotten really good at doing that quickly in the relative sense, but it just can't compare with normal electrical signals that generally move around near c (iirc). So Solid State Drives are rather nicer in this regard, though they are not without their many foibles (and they can't compete with decent RAM speed-wise, nor are they really intended to in terms of the bus architecture and so on).
I didn't list Virtual Memory separately since that's just a chunk of your disk (HDD/SSD) space carved out to serve essentially as an "overflow room" for your RAM. So if all the applications currently running on your machine need more total memory than you have RAM, your OS "pages out" parts of RAM it doesn't think you'll need soon to this virtual memory "pagefile". If your RAM is full and you don't _have_ a pagefile (disabling it is common practice with an SSD, to extend drive life), or your pagefile is also full, expect some fairly messy crashes. Generally doesn't happen nowadays though.
Edit: whoops, meant to add that as a programmer in many environments (including Unity's available languages), you have neither the ability nor the need to have any idea of or control of what happens with the Registers or Caches. That's all handled for you, for better or worse. Your choices entail how much stuff you create (that goes in RAM), and what you write to or read from disk.