3 ms·

> how does it handle ever-changing business-requirements that can retroactively apply to existing objects and associations If the change is backwards-compatibl

> 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.

DaiPlusPlus 5y ago
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.
- bcherny 5y ago
  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.
  - DaiPlusPlus 5y ago
    > The process is more complicated under the hood. Right, but that's exactly what I'm asking about :)
    - bcherny 5y ago
      Sorry, I must have misunderstood the question! :)
    - RandomBK 5y ago
      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.

DaiPlusPlus 5y ago

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.

bcherny 5y ago
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.
- DaiPlusPlus 5y ago
  > The process is more complicated under the hood. Right, but that's exactly what I'm asking about :)
  - bcherny 5y ago
    Sorry, I must have misunderstood the question! :)
  - RandomBK 5y ago
    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.