3 ms·
Very cool. This is the architecture that inevitably results from when you start with boxed, native, desktop software and incrementally move towards cloud based
by jelder 3y ago
Very cool. This is the architecture that inevitably results from when you start with boxed, native, desktop software and incrementally move towards cloud based storage and collaboration. You have to be really good at doing schema changes and version migrations, because they're happening at fantastic scale without administrator intervention: not when you launch, but when each individual customer chooses to use the next version.
Quite different from a SaaS-first approach where it actually makes sense to do "customer id column"-based multi-tenancy and one-migration-at-a-time schema changes that I think most of us at less-than-Apple scales are familiar with.
- meowtimemania 3y agoIs there any writing about these types of schema changes? It's something I run into using dynamodb.
- AtlasBarfed 3y agoAt least with Cassandra, there are cell-level timestamps which are very useful for doing data migrations while active writes are still incoming. You can simply mirror the writes to both systems, and then migrate the old data underneath. As long as the data transfer preserves the cell level timestamps, the read path resolves any differences and compaction will eventually clean up any duplicates. (and sstable loads will have the timestamps) Dynamodb does NOT have cell level timestamps, I believe they have row level timestamps. How it is doing globally replicated data and mutation merges: I have no idea. It seemed like a handwave when they were announcing it about two or three years ago.