petrosagg

Joined 14 years ago

Karma

453

Submissions

Member since

Jan 24

[ my public key: https://keybase.io/petrosagg; my proof: https://keybase.io/petrosagg/sigs/u07exz-onHTZJeFG8WOpBT9NAu38uSKxt9TIjBsvycU ]

View on Hacker News

Recent submissions

Diagnosing a Double-Free Concurrency Bug in Rust's Unbounded Channels materialize.com

13 petrosagg 1 year ago 0 comments

Comment · 1 year ago

Materialize | Staff Software Engineer (Sources/Sinks) | NYC or Remote (US/Canada/EMEA) | https://job-boards.greenhouse.io/materialize/jobs/5357900004

Materialize is a cloud operational data store (ODS) enabling fast, incremental, and consistent transformations of live data using SQL.

We’re hiring Staff Software Engineers to build high-performance, distributed systems in Rust, focusing on efficient data ingestion and delivery. You’ll work on data integration pipelines, leveraging cutting-edge concepts like differential and timely dataflow to ensure correctness and efficiency.

Note: the linked position is focused on the data integration aspect of Materialize but we're also looking for wider database roles so feel free to apply if the general area of Materialize seems interesting to you!

What we’re looking for:

- 5+ years of systems-level engineering (Rust, Go, C/C++, or similar; Rust experience a plus).

- Strong CS fundamentals (B.S./M.S. equivalent).

- Bonus: distributed systems, SQL databases, CDC, or stream processing experience.

Compensation: $200K–$225K + equity.

Backed by Kleiner Perkins and Lightspeed ($100M+ raised), we’re remote-friendly and committed to building a diverse, world-class team.

Comment · 1 year ago

Materialize | Staff Software Engineer (Sources/Sinks) | NYC or Remote (US/Canada/EMEA) | https://job-boards.greenhouse.io/materialize/jobs/5357900004

Materialize is a cloud operational data store (ODS) enabling fast, incremental, and consistent transformations of live data using SQL.

What we’re looking for:

- 5+ years of systems-level engineering (Rust, Go, C/C++, or similar; Rust experience a plus).

- Strong CS fundamentals (B.S./M.S. equivalent).

- Bonus: distributed systems, SQL databases, CDC, or stream processing experience.

Compensation: $200K–$225K + equity.

Backed by Kleiner Perkins and Lightspeed ($100M+ raised), we’re remote-friendly and committed to building a diverse, world-class team.

Comment · 1 year ago

Materialize | Staff Software Engineer (Sources/Sinks) | NYC or Remote (US/Canada/EMEA) | https://job-boards.greenhouse.io/materialize/jobs/5357900004

Materialize is a cloud operational data store (ODS) enabling fast, incremental, and consistent transformations of live data using SQL.

What we’re looking for:

- 5+ years of systems-level engineering (Rust, Go, C/C++, or similar; Rust experience a plus).

- Strong CS fundamentals (B.S./M.S. equivalent).

- Bonus: distributed systems, SQL databases, CDC, or stream processing experience.

Compensation: $200K–$225K + equity.

Backed by Kleiner Perkins and Lightspeed ($100M+ raised), we’re remote-friendly and committed to building a diverse, world-class team.

Comment · 3 years ago

Thank you for the detailed response!

> However, while checksums can be used under the “Crash Consistency Model” to solve consistency through power loss, PAR showed that checksums are not sufficient to be able to distinguish between a torn write at the end of the (uncommitted) WAL caused by power loss, and a torn write in the middle of the (committed) WAL caused by bitrot.

The PAR paper states that "although Crash preserves safety, it suffers from severe unavailability". I assume that when TigerBeetle loads state from RAM into a CPU cache/register it operates under the NoDetection consistency model or the Crash consistency model if ECC RAM automatically resets the CPU on read errors. At the same time it doesn't suffer from severe unavailability so what gives?

The answer is probably that ECC RAM is just reliable enough that the NoDetection/Crash models are fine in practice.

I can believe that off-the-shelf checksum and redundancy options offered by filesystems like ext4 and ZFS or systems like RAID don't hit the required error probabilities but why does the argument stop there? Couldn't a distributed database generate error correcting data on every write in the application layer so that the probability becomes low enough such that NoDetection/Crash become a non-issue for storage, just like RAM? Is there some other fundamental difference between reading and write data from RAM versus a disk?

Comment · 3 years ago

> Sure, we’re not yet injecting storage faults, but then formal proofs for protocols like Raft and Paxos assume that disks are perfect, and depend on this for correctness? After all, you can always run your database over RAID, right? Right? > If your distributed database was designed before 2018, you probably couldn’t have done much. The research didn’t exist.

I'm trying to understand this part but something seems off. It seems to imply that those proofs do not apply to the real world because disks are not perfect, but neither is RAM. The hardware for both RAM and disks has an inherent error rate which can be brought down to arbitrary levels by using error correction codes (e.g ECC RAM).

I'm assuming that the TigerBeetle correctness proofs are predicated on perfect RAM even though in reality there is a small probability of errors. This tells me that there is an error rate which they consider negligible. If that's the case what is the difference between:

* TigerBeetle's storage approach

* Paxos or Raft with enough error correction on disk writes that the probability of errors equals that of ECC RAM which is considered negligible

I've probably made a logical error in my reasoning but I can't see it. Can someone enlighten me?

Comment · 4 years ago

The feature you're referring to is const generics which is different than generic associated types (GATs) which is the feature being stabilized.

min_const_generics have been on stable for while

Comment · 4 years ago

I must be missing something. The paper describes the algorithm of the CRDT and mentions that "timestamps ’t need to be globally unique and totally ordered".

Then it mentions multiple times that Lamport clocks/timestamp can be used as the timestamp in their system but as far as I know these only give a partial order of events. How is this reconciled in their system?

Comment · 4 years ago

Here you go https://www.youtube.com/watch?v=WJj_NMhYwf0