sidch

4 ms·

1.
by sidch 6y ago
Yugabyte PM here. Yugabyte SQL query layer is a fork of PostgreSQL 11.2's query layer. This query layer runs on DocDB, a distributed document store whose sharding, replication and ACID transactions architecture is inspired by Google Sp
2.
by sidch 7y ago
Yugabyte PM here. The goal is to demonstrate that even SQL databases can now be scaled to 1M inserts per second, a feat that was previously reserved for NoSQL databases.
3.
by sidch 7y ago
Postgres was first written in Lisp and had to be re-written in C because of slow performance [1]. YugaByte DB reuses the same C-based Postgres query layer but runs it on a Google Spanner-inspired distributed document store written in C++. T
4.
by sidch 7y ago
YugaByte product manager here -- have documented the answer to your question [1] As you can see, there are many similarities but there are also a few important differences such as depth of PostgreSQL compatibility (YB reuses PostgreSQL quer
5.
by sidch 7y ago
Thanks for sharing these. Hadn’t heard of the first 2, so look fwd to reading them. We did review the Amazon Dynamo architecture (which is used in Dynomite) in depth but found it to be lacking for supporting even single-row linearizability.
6.
by sidch 7y ago
Only if things were that simple :) Calvin avoids the need to track clock accuracy by making every transaction go through a single consensus leader which inherently becomes a single point of bottleneck for performance and availability. Spann
7.
by sidch 7y ago
assume you are referring to https://en.wikipedia.org/wiki/NonStop_SQL -- was not aware of it so thanks for bringing it to attention. first impression is that it was a technology way ahead of its times. in late 80s (and
8.
by sidch 7y ago
happy that you liked the post. as you could infer, this simplicity is by no means a magic bullet. there are always trade-offs depending on the database type you use as baseline for comparison. we highlight them here: https://docs
9.
by sidch 7y ago
YugaByte DB product manager here. we have compared the Spanner and Calvin architectures in depth previously ( https://blog.yugabyte.com/google-spanner-vs-calvin-global-co... ). one key difference comes from the fact that Calv
10.
by sidch 7y ago
YugaByte DB product manager here. Yes, CosmosDB and its underlying architecture were indeed not yet publicly available when we started the YugaByte DB project early 2016. However, classifying CosmosDB as a distributed SQL database is a bit
11.
by sidch 8y ago
YugaByte product manager here. The YCQL API which passes Jepsen has its roots in Cassandra Query Language but does not use Cassandra as its backend store. It’s backend store is DocDB, which is a Google Spanner-inspired distributed document