Hacker News Reader

Comment by bcherny | Hacker News Reader

> how does it handle ever-changing business-requirements that can retroactively apply to existing objects and associations

If the change is backwards-compatible:

1. Update the schema definition

2. Run codegen

3. Done

If it’s not:

1. Create a new field/assoc

2. Double-write data to the new and old fields/assoc

3. Backfill data from the old one to the new one

4. Delete the old one

5. Done

> I assume each TAO object can be treated as a keyed blob with type-name (i.e. a 3-tuple of (id, type, blob) ) - in which case using an RDMBS is overkill and introduces many overheads, so why use an RDMBS?

I believe data is stored in tuples, same as most other graph DBs. I can’t speak to why MySQL in particular.

View on HN

Facebook's database is distributed - it's not as simple as "updating the schema definition" because that process-step alone is non-trivial with many cases to consider.

The process is more complicated under the hood. I’m describing it from the POV of an engineer that wants to update a field — from that POV, it really is that simple.

> The process is more complicated under the hood.

Right, but that's exactly what I'm asking about :)

Sorry, I must have misunderstood the question! :)

The key is in making sure every step-wise change is backwards-compatible.

Creating a new field, double-writing, and backfilling are all relatively easy tasks in a distributed environment. Individual nodes can take their time catching up to the latest schema.

After a day or two, the engineer can verify that all data have been correctly migrated and double-written to the new ent/assoc. They then turn off double-writing to begin deprecating the old assoc. This can be done in an A/B test to ensure no major breakages.

Once the double-writing is fully turned off, the engineer checks one last time that all the data have been migrated. They check that the read/write rate to the old ent/assoc is 0, which then confirms that the old field is now safe to delete.

Overall, the trick is to think of the migration as a series of safe, backwards-compatible, easily-distributed steps, rather than a single atomic operation.

Reply on news.ycombinator.com