Hacker Newsnew | past | comments | ask | show | jobs | submit | riccomini's commentslogin

DD supports lattices that allow it to compute at multiple points in time simultaneously. As I understand it, DBSP limits time to one diff at a time. Lalith can correct me if I’m off base on this. :)


I'd say the difference is in the type of transaction isolation guarantees each system provides. DBSP can process multiple diffs in parallel, and when it's done it outputs a single diff that captures the effects of all the input diffs. DD can additionally attribute each output diff to a specific input diff by assigning each input diff and matching output diff a logical timestamp. This has a cost in terms of complexity and runtime overhead, but it allows strong isolation of concurrent transactions.


But as gz09 said, both DD and DBSP are data-parallel architectures that can evaluate queries concurrently on multiple threads or multiple machines.


(lalith here) -- Whatever ryzyk and gz09 said above. :)


Great question! We started out with the design you described--WAL as L0. But we found that there's a bit of a tension between wanting to have L0 SSTs be larger (and having fewer of them) to reduce metadata size, while we wanted to keep WAL SSTs small and frequent (to reduce async/await latency).

Basically, we wanted to have WAL writes go on the order of milliseconds, but we wanted L0 SSTs to be larger since they actually service reads.

The architecture page has more detail if you haven't found it yet:

https://slatedb.io/docs/architecture


I’m Chris, and I built WANT to help you discover, share, and research premium products. Looking forward to hearing your feedback! =)

Everybody’s got a friend they go to for shopping advice; the friend that can’t stop talking about their new self-cleaning water bottle, ceramic grill, or wireless mechanical keyboard. You know the type.

For me, this “friend” is actually a group of friends. During the pandemic, I started doing more online shopping. :sweat_smile: My friends and I had a text thread going to keep us sane. The thread became a place to talk about our new purchases (among other things), and to get purchase advice. We shared the cool new home gym equipment we got, discussed standing desks, and posted the new chef’s knife that we ordered.

I built WANT as an extension of that text thread.

## No Amazon Here

My friends and I noticed that less and less of the cool stuff we found was coming through Amazon. Many of the products we purchased were coming directly from the manufacturer’s website–usually fronted by Shopify.

Recognizing this, I’ve decided to block Amazon links on WANT. My hope is that this will encourage us to buy more (and higher quality) goods outside of Amazon. I also hope blocking Amazon emphasizes that WANT is not a deal site–it’s a place for finding high quality products and supporting the brands that create them.

## This is Just...

WANT is a lot like Reddit, Pinterest, Product Hunt, Instagram, and others. The app borrows heavily from each of these sites. WANT’s product discovery is similar to Product Hunt, its commenting system is like Reddit’s, and its shelf system will be like Pinterest’s boards. Visually, WANT is somwhere between Instagram and Twitter.

I like to think that, by combining different aspects of each of these sites, I’ve ended up with something useful and unique. =)

## Tech

I built WANT entirely myself, as a side project. The site is built with Ruby on Rails and Postgres. It's hosted on Heroku. I use Mailgun for email and Zenscraper to scrape submitted product URLs.

The iOS app is built in Swift, but it's mostly a WkWebView wrapper around the website; I built the app to provide a share extension, so users could submit products as they surf on their phone.

One annoying thing I dealt with was OAuth on iOS via a WkWebView. I've written more about that at https://cnr.sh/essays/google-oauth-wkwebview.

Anyhow, looking forward to your thoughts!


I think The Missing README goes quite well with Will Larson's "Staff Engineer" and Camille Fournier's "The Manager's Path". These three book will take you from entry-level engineer, through a staff/technical lead, all the way to management at the SVP of Engineering level.


Zhamak's article is the canonical reference. It does a decent job of outlining the problem space:

https://martinfowler.com/articles/data-monolith-to-mesh.html


Thanks!


100% agree with this sentiment. My co-author and I are wrapping up a book with No Starch and the experience has been very positive. The editing, in particular, has been stellar.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: