rystsov

7 ms·

1.
by rystsov 3y ago
Yep, I still consider them to be cutting edge. Paxos was written in 1990 but the industry adopted it only in 2010s. For example I've looked through pBFT and it doesn't mention reconfiguration protocol which is essential for indust
2.
by rystsov 3y ago
We can't ignore or pretend that network partitioning doesn't happen. When people talk about choosing two out of CAP the real question is C or A because P is out of our control. When we combine network partitioning with single loca
3.
by rystsov 3y ago
Strongly consistent protocols such as a Paxos and Raft always choose consistency over availability and when consistency isn't certain they refuse to answer. Raft & Paxos: any number of nodes may be down, as soon as the majority is
4.
by rystsov 4y ago
I was following Jepsen results since Kyle's first post and it's amazing that the blog post series became a well respected company The report revealed the following unknown consistency issues which we had to fix: - duplicated w
5.
by rystsov 4y ago
Hey folks, I wrote this post and I'm happy to answer questions
6.
Redpanda’s official Jepsen What we fixed, and what we shouldn’t(redpanda.com)
6 points by rystsov 4y ago|3 comments
7.
by rystsov 4y ago
Cool! What did you test? I've played with Jepsen and Cosmos DB when I was at Microsoft but we had to ditch ssh, write custom agent and inject faults with PowerShell command lets.
8.
by rystsov 4y ago
Can you clarify what you mean? AFAIK with manual commit you have the most control over when the commit happens Look at this blog post describing a data loss caused by auto-commit: https://newrelic.com/blog/best-practice
9.
by rystsov 4y ago
Documentation is a bit confusing: the protocol was evolved over time (new KIPs) and there is mismatch between the database model and kafka model. But we see a lot of potential in the Kafka transactional protocol. At Redpanda we were able to
10.
by rystsov 4y ago
It wasn't a big surprise for us. Redpanda is a complex distributed system with multiple components even at the core level: consensus, idmepotency, transactions so we were ready that something might be off (but we were pleased to find t
11.
by rystsov 4y ago
I've created this list a while ago https://github.com/redpanda-data/awesome-distributed-transac... . Maybe it's time to update it. Usually I start with a couple of seed papers then follow the references, look
12.
by rystsov 4y ago
The mess is mostly the result of the mismatch between the classic database transactional model and kafka transactional model (G0 anomaly). If you read the documentation without the database background it seems ok, but when you notice the d
13.
by rystsov 4y ago
Different systems solve different problems and have different functional characteristics. Actually one of the thing which Kyle highlighted in his report is write cycles (G0 anomaly), it isn't a problem of the Redpanda implementation bu
14.
by rystsov 4y ago
Hey folks, I was working with Kyle Kingsbury on this report from the Redpanda side and I'm happy to help if you have questions
15.
by rystsov 6y ago
Yes and no, we do both. For ack=-1 we wait for fsync & replication confirmation but for other modes we relaxed the behavior.
16.
by rystsov 6y ago
Author is here AMA :)
17.
by rystsov 6y ago
Hi Kyle, thanks for the Elle :) I want to use Elle to check long histories of transactions over small set of keys with read dominant workload, the paper recommends to use lists over registers but when the history becomes long on the one han
18.
by rystsov 8y ago
I agree it's hard for me too to be precise about naming in academic sense. But this published paper "Writes: the dirty secret of causal consistency" says that both Cosmos DB and MongoDB have causal consistency so I don't
19.
by rystsov 8y ago
It's off-topic. But yes, Cosmos DB has rigorous tests[1] including Jepsen (a tool). [1] https://twitter.com/dharmashukla/status/869104163510034432
20.
by rystsov 8y ago
> Thus far, causal consistency has generally been limited to research projects ... MongoDB is one of the first commercial databases we know of which provides an implementation. Cosmos DB provides session consistency (looks like an anothe
21.
by rystsov 8y ago
I agree that CRDT don't help with data-scalability (eventually all data converge on a single node), just wanted to comment on the following phrase > CRDTs don't help in the case that you don't want to deliver wrong answers
22.
by rystsov 8y ago
CRDT may help: if you read from quorum, merge(+modify) and write back to quorum for read (write) then you'll always get right answers.
23.
by rystsov 8y ago
"unlike Google Percolator, FoundationDB, or similar systems, FaunaDB places no constraints on replica distance and is practical to deploy at global internet latencies" "For each batch of parallel transactions, they are insert
24.
by rystsov 9y ago
Roaring 20s were pretty liberal in USSR too - https://en.wikipedia.org/wiki/LGBT_history_in_Russia#LGBT_Hi...
25.
by rystsov 9y ago
It would be interesting to repeat the research in St.Petersburg, the siege during the WW2 lasted more than 2 year and there were 642,000 casualties among civilians. https://en.wikipedia.org/wiki/Siege_of_Leningrad
26.
by rystsov 9y ago
Some update on Gryadka - Tobias Schottdorf and Greg Rogers independently explored it with TLA+ and didn't find any issues: - https://tschottdorf.github.io/single-decree-paxos-tla-compar... - https://medium.c
27.
Testing responsiveness of dist. storages when leader is isolated from the peers(github.com)
1 points by rystsov 9y ago|0 comments
28.
by rystsov 9y ago
I responded in the comments: http://tschottdorf.github.io/if-its-not-paxos-its-probably-w... the analysis is based on a false assumption about the read operation
29.
by rystsov 9y ago
I don't know TLA+ yet but I'll assist anybody with an explanation on how Gryadka works.
30.
by rystsov 9y ago
It's good but wrong because it's based on a false assumption about how the read operation works. I explained it in the comments.

More ›