fomichev3000

The teams are approaches are different, but I need to say that internal clients are the same. Yandex is doing great things and it needs great tools.

They are totally different systems. Just they have a first letter 'Y'.

Foreign keys come at a cost, especially in distributed database. It's just a fact. If you can avoid them, it's great.

The table is a bit outdated, we are going to fix it. To be honest, YQL is a very popular language in our company, it is successfully used for more than 7 years, but I agree that outside people want to see more standard SQL dialect.

We have benchmarks in our roadmap, we understand there are required.

The core tx ordering mechanism is inspired by Calvin deterministic transactions mechanism. We have some differences, like we have a distributed tx coordinator that allow us to scale number of transactions in flight.

We have consensus protocol over shared log. Some details you can find in a power point presentation at this page https://2019.hydraconf.com/2019/talks/muxomfgqembsb3st7i3ci/

Thanks for pointing this out. I think it's possible, most of the code is cross platform, we used to build YDB on Windows, so it should not be a problem. I suppose we need to improve a layer that works with storage devices to make it effective, for now it should be very naive implementation.

Yes, you can think this way. But I need to add, that YDB is also a platform for developing distributed systems that store data. YDB provides a scalable and replicated storage with low latency, a conception of a tablet (that is also used in many systems) that implements distributed consensus. These building blocks are used for persistent queue implementation, block store, KV-tablets. These blocks are hard to develop and they are very good when you need to build something new or optimal for a specific problem. OLTP is an example of such a problem. But yes, we were building YDB to support OLTP workload initially.

While you have a good point, I need to say that traditional databases and distributed databases differ in some points. For instance in YDB you can connect to any node of a database, it means that you need some kind of balancing (server side or client side). I'm not talking about SQL dialect right now, but rather how you connect to database and how you handle connection losses or node overloads. YDB SDKs have client side balancing feature to distribute load evenly across database nodes.

Postgres support is in progress actually.

YDB doesn't use Zookeeper. The system is built of tablets, every tablet implements distributed consensus algorithm. There are different types of tablets in the system, say SchemeShard is tablet that stores metadata, table schema for instance. DataShard stores table partition data.

Each tablet gather a quorum of answers from members of so called BlobStorage group. BlobStorage group is a number of so called VDisks (virtual disk), all VDisks run on different nodes (even on different fail domain like racks, AZs). VDisk stores its data on physical device, i.e. PDisk.

YDB is developed from ground up. We think about postgres compatibility layer, that's why you see 'postgres' in source code.

That's right, wire protocol is grpc. SQL dialect is called YQL. YDB doesn't have MySQL or Postgres compatibility, but we think about it.

Yes, YDB plays in this category.

YDB can work in a single AZ and such setups exist. Most of our users want to handle AZ downtime, so it's a major case.