Re:Why Google stores billions of lines of code in a single r...
by Groxx on Sunday December 10, 2017 @01:17PM
(#15892649)
> This can be impractical if G is a database table that is very large.
If this is true, you have no choice, and must run things side by side while you convert to G2. Or shut everything down to make the migration atomic, which is increasingly not an option.
Re:Why Google stores billions of lines of code in a single r...
by geocar on Sunday December 10, 2017 @01:53PM
(#15892845)
> you have no choice
It depends on your database.
If you imagine a simple postgres or mysql server and an "alter table G..." then you're right.
If (however) G1⊂G2 then a document store or a column-based database can usually partition the table somehow.
Re:Why Google stores billions of lines of code in a single r...
by gwenzek on Monday December 11, 2017 @03:38AM
(#15895847)
> This can be impractical if G is a database table that is very large.
Unless if the new format G2 is a super set of the old format G1. Read protobuffers best practice to know more about this.
This can be impractical if G is a database table that is very large.
> it’s best imho to make the projects truly independent, as if they were developed by different companies.
One of our systems might cost £300k, so completely desynchronising them so that code paths can build both G1 and G2 simultaneously (allowing B to develop separately) means "simply" doubling the costs. That might put our team at a disadvantage against someone who figures out another way.