tiDB – Scalable RDBMS Inspired by Google F1 with Support for MySQL Protocol
github.com
github.com
if so, good post by John Hugg of voltdb about it: http://voltdb.com/blog/foundationdbs-lesson-fast-key-value-s...
How does tiDB compare to this?
That said, I think props still go to Google's teams on GFS, Spanner, and F1 as the best techs out there. A F1 variant, which two teams are trying, is best approach given it's proven and with much published detail.
I'm just a little sad that it's all MySQL again, now that we're betting on PostgreSQL and don't really look back.
On the performance side I'm just a litte worried however. While Go is an excellent choice for performant and concurrent app-level code, I'm not too bullish on the language on the database level. InfluxDB sucked hard when we put it under some more load, but let's see what comes out there.
Doesn't Postgres have its own multi-master solution in the works with BDR?
You can't divide the data on multiple servers (sharding)
It will come a time, when you'll exhaust the biggest machine they have available, and then you're stuck
While it's true that most companies will be fine in 256GB ram, we were talking about sharding, which it doesn't have.
I'm assuming [meme] is shorthand “overly-broad assertion”? It's nice if your database has horizontal scaling built in but it's not like we don't have an entire generation of successful companies who had application-level sharding logic either by necessity or because they found the control it offered was valuable compared to the built-in generic logic.
> While it's true that most companies will be fine in 256GB ram, we were talking about sharding, which it doesn't have.
You still haven't supported the assertion that it's common for places to have massive, heavily-queried databases like this which would not be better split following natural application-level boundaries. This is particularly relevant when discussing AWS as some of the common reasons for keeping everything in one database are sweet-spots for other services (e.g. migrating data for long-term historical reporting over to RedShift).
Again, I'm not questioning that integrated sharding would have its uses – only your sweeping assertion that this is a likely problem for most people and that it's a dead-end (“you're stuck”) rather than merely one of many growing pains which you'll deal with on a successful product. In particular, it's unlikely that everyone will have the same right answer at that scale since access patterns vary widely.
Are there any design documents detailing its implementation? I checked the wiki but it didn't look like there was anything there. What alternatives were considered, and why were they abandoned?
Also, is there a concrete use case for which this system is being built? If so, what are some (publicly releasable) details about the use case, e.g. access patterns, data volume, etc.?
We will consistently deliver new features like HBASE support, and the documentation will be improved as well.
EDIT: The architecture diagram wasn't visible to me before, now that it suddenly appeared things are way more clear.
What about MPP (Massively Parallel Processing) support? This is one of the things that make CitusDB so powerful.