|
|
|
|
|
|
by _tkzm
2374 days ago
|
|
|
all those points sound more like quickfixes for bad architecture design. I've been there, done that.. and i've learnt from it. instead of fixing the initial problem, you are just throwing more code and complexity over it. which costs you money and time. i think you made a BIG mistake byt going polyglot and not sticking to single a language which now prevents you from merging the code into a single binary in cost-efficient way. if you decide to go with the single binary approach, i am curious to see if you decide to go with Go or Rust :) just fyi: cdb went with Go but their storage layer ended up being rewritten with C, so they too are not much different from you, with the exception of being able to run a single binary via Cgo which you cannot do with Rust. |
|
|
As an on looker the architecture of TiDB is anything but bad. It doesn't fit into the "run one thing for everything" bucket of software because it's designed to be horizontally scalable. Every part of the design is scoped well enough to only do the bare minimum for it's goal. I have no doubt that internally at Google things like BigTable look very architecturally similar.
> Big mistake going polyglot.
Why? Because you can't make a single binary? That's not really a use case that makes sense for a cloud native DB. Everything is going to be a container anyway, so it doesn't matter what artifacts are included. Also the individual implementation layers of TiDB are individually useful (TiKV).
Making a single binary has no benifits unless you're running your hardware in a pet mentality which manually curated software. In this case a horizontally scalable db will not help you.
Also, providing an operator is a far cry from a "quick fix". I applaud them for doing this because it essentially removes the operation burden of running their DB.