rkarthik007

6 ms·

1.
by rkarthik007 5y ago
Thanks for pointing this out, was not aware of TAPIR. Will take a look, seems pretty interesting.
2.
by rkarthik007 5y ago
The difference is in how the regular path (exercised most of the time) vs an edge case when there is a conflict (typically in larger clusters with a pathological access pattern) works. With TrueTime, the latency is always 7ms and no issues
3.
by rkarthik007 5y ago
This blog post covers the various techniques to sync clocks in general (NTP, GPS clocks / TrueTime, Timestamp Oracle, HLC, etc). CockroachDB uses HLC (hybrid logical clocks), which is the same clock sync mechanism as YugabyteDB uses (a
4.
by rkarthik007 5y ago
Spanner gets both correctness and low latency from tight synchronization. They do COMMIT_WAIT, meaning wait for the max clock skew to pass. But the max clock skew without TrueTime will be around 500ms (which it impractical to wait out). So,
5.
by rkarthik007 5y ago
> but AFAIK can do that off-the-shelf today using chrony with hardware timestamping or PTP. No need to invent your own. Actually, the issue is about the max clock skew guarantees (as opposed to the average or median). Even a single viola
6.
China launches world’s fastest programmable quantum computers(scmp.com)
1 points by rkarthik007 5y ago|0 comments
7.
Discuss: Google Cloud Spanner adds a PostgreSQL interface(datanami.com)
44 points by rkarthik007 5y ago|6 comments
8.
by rkarthik007 5y ago
When building YugabyteDB, we reuse the "upper half" of PostgreSQL just like Amazon Aurora PostgreSQL and hence support most of the functionality in PG (including advanced ones like triggers, stored procedures, full suite of indexe
9.
by rkarthik007 6y ago
Hi @catblast, (I am the CTO of Yugabyte) Your points are all completely valid. Just wanted to add my 2 cents. With YugabyteDB specifically, we are more than just PostgreSQL wire-compatible, we "reuse" the upper half of PostgreSQL
10.
by rkarthik007 7y ago
Hi @hkolk, Thanks for your feedback! Not sure when you tried yugabyteDB, but our serializable isolation level and YSQL API (which is needed to exercise serializability) were in beta till a couple of days ago. That said, if you can share som
11.
by rkarthik007 7y ago
Hi @Nican, sure thing. There are two benchmark workloads, simple inserts and secondary index. The simple inserts workload 50M unique key-values into the database using prepare-bind INSERT statements with 256 writer threads running in parall
12.
by rkarthik007 7y ago
Yup, already done - we dropped it from the title of the post. Our aim was never to misrepresent. Its a difference of opinion on what "Jepsen testing" represents to us - core transactional correctness or transactional DDL (which mo
13.
by rkarthik007 7y ago
We are working on r2dbc, this is currently an active project. We have made good progress so far. If you have a use case or are in guiding the project, please join our community slack!
14.
by rkarthik007 7y ago
True for a single node. However, there will be multiple IP address/connections anyway, since YugaByte DB is a distributed DB and it runs across multiple nodes. JDBC drivers connect to only one node - so to provide true connection scali
15.
by rkarthik007 7y ago
We are working with the R2DBC folks on reactive programming for async/event based use cases as well. This work is just getting kicked off. If interesting, please join our community Slack and give us any feedback/thoughts.
16.
by rkarthik007 7y ago
Yes absolutely spot on! Peeling the onion one more layer, there are two underlying features that are required: 1) Move to a threaded model to be able to scale instantaneously. This is already the case with YCQL, we're planning on doing
17.
by rkarthik007 7y ago
Very astute observation! Two things: * We implemented a feature to share memory between these connection handling processes so that makes it a bit more efficient * Longer term we are thinking of switching to a thread based model. This is ho
18.
by rkarthik007 7y ago
Would much appreciate some constructive criticism! - CTO/co-founder
19.
by rkarthik007 7y ago
Hi @jazoom, Thanks for your comment... had a couple of clarifications. Our take on the open-source licensing of CockroachDB/MongoDB has no implication on the features of these products. So in essence, you raised two separate points (on
20.
by rkarthik007 7y ago
Yes, we support all types of joins (inner, right included) and indexes. In fact, we recently also enabled stored procedures with plpgsql :) Tuning to perform these efficiently in a distributed manner is a work in progress (this is wrt the t
21.
by rkarthik007 7y ago
Thanks for your wishes @nishantvyas! This might help answer some of your questions: https://docs.yugabyte.com/latest/introduction/#what-are-the-... Please look at the trade-offs in the above section (vs SQL, vs tr
22.
by rkarthik007 7y ago
Hi @kodeblah, True, but note that the comparison only focuses on SQL (as it related to PostgreSQL) features and not any DB-specific features. The YugaByte DB specific pieces are not included as well - for example, support for YCQL (Cassandr
23.
by rkarthik007 7y ago
I won't be making that mistake again! (I am talking about "begs the question" vs "raises the question" - no idea about the downvote).
24.
by rkarthik007 7y ago
(founder/cto of YugaByte) This is a very insightful suggestion, thanks for raising that! We had considered many of these variants until finally, we concluded that fully open is the best way. PostgreSQL (which is the database on fire ri
25.
by rkarthik007 7y ago
Hi rekoros, I am the CTO/Founder of YugaByte and author of the above post. Thanks for your comments, glad you liked the post! You make a great point about YugaByte DB using Apache Kudu to start out, but wanted to clarify a few things.
26.
by rkarthik007 8y ago
Hi @shin_lao As @aphyr had mentioned, any NTP-alike system would work. We can update the docs to mention PTP, we do work with AWS Time Sync as well (which uses Chrony).
27.
by rkarthik007 8y ago
Hi @manigandham, great question. As it stands now, YugaByte would not be a PG extension. It will be a fully distributed but standalone PG cluster called "YSQL" API layer. We have started with the 10.4 version of PG for building di
28.
by rkarthik007 8y ago
CTO of YugaByte here... this is indeed our plan. We are working with the community on pluggable storage coming out next year, and in the slightly longer term want to make YB a plugin (extension in the case of PG) model. While a reasonable a
29.
by rkarthik007 8y ago
Hi @lukeqsee, we are working on just this, please stay tuned!
30.
by rkarthik007 8y ago
HN ate my comment, hope to figure hn out someday! Had written: From the bailis.org link you posted: > Linearizability is a guarantee about single operations on single objects. The place we references "linearizability" (in the J

More ›