Live data from Hacker News

Migrating Uber's ledger data from DynamoDB to LedgerStore

uber.com

141–150 of 345 posts

Re: Migrating Uber's ledger data from DynamoDB to LedgerStore

#141
post #91

Earlier quoted context omitted.

That was where my mind went to when I saw the headline. Granted that while I’m not on the Finance side of things and am in fact a developer, “six million” didn’t seem like much at all considering engineer salaries. It’s certainly an achievement, but at what short and long term salaried cost?

$6m across 2.5 years is like $15.5m, how many engineers man-months to breakeven, I'm pretty sure it was worth the work.

$6m in perpetuity is like infinite and engineers can be fired.

Re: Migrating Uber's ledger data from DynamoDB to LedgerStore

#142

I pretty much never see engineering salaries factored into these types of savings projects. I assume because engineers are already viewed as a sunk cost or maybe it’s just because it’s way less tangible. Have seen many designs describe how X saves Y dollars but ignores the engineering effort to maintain and build it. Half the time I suspect it’s just so people have something to work on, rather than it being some crit…

If anything, it reduces Uber's exposure to AWS' proprietary technology. I don't know how to measure how much that's worth but they probably do.

Companies this size almost certainly have different terms of use. I worked for a smaller, but still ASX200 company that had a custom contract, and assigned staff that would drop by 2-3 days a month. Of specific note was that if AWS wanted to stop doing business with us they had to give at least X notice (from memory that was 12 months for us).

For our risk profile this was more than enough time to migrate off any AWS' proprietary technology.

That makes it worth less to avoid exposure.

Re: Migrating Uber's ledger data from DynamoDB to LedgerStore

#143

I pretty much never see engineering salaries factored into these types of savings projects. I assume because engineers are already viewed as a sunk cost or maybe it’s just because it’s way less tangible. Have seen many designs describe how X saves Y dollars but ignores the engineering effort to maintain and build it. Half the time I suspect it’s just so people have something to work on, rather than it being some crit…

$6M/y is something like 20 heads (depending on where they are, could be more). So probably it's a win. Hard to see that this could take more than about 5. Add cost of hay and water of course.

Re: Migrating Uber's ledger data from DynamoDB to LedgerStore

#144

Earlier quoted context omitted.

Seems to happen with all our blog posts that appear on here (I work at Uber) - I don't get why the originals don't get upvoted but these rehashes do - are our titles just not as good?

i mean it could use a few "blazing fast" sprinkled about

And you can't have blazing fast without rust, and a little kvetching about lifetimes

Re: Migrating Uber's ledger data from DynamoDB to LedgerStore

#145
post #119

More power to them. At this point even technically decent teams/companies have given up on developing large, complex systems in favor of SaaS. After carefully evaluating our strategic course of action answer always is AWS. Its only team who propose alternative they have to justify rigorously how come they differ in conclusion.

"At this point even technically decent teams/companies have given up on developing large, complex systems in favor of SaaS"

Yeah until those bill come, They would consider alternative

Re: Migrating Uber's ledger data from DynamoDB to LedgerStore

#146

Does no one ever delete data? It's hard to believe there's much business value in keeping every individual payment record dating back to 2017.

In systems that deal with money, money-related data is virtually never deleted. The reason is the fear that deletion can be exploited somehow in the future, rather than the old data being actionable. For example, if a customer registers with the name of a deleted customer, which will resurface some "unfinished" transactions or rules associated with the older version of the "same" customer that haven't been properly d…

I agree with you, but there is a plus for deleting old data.

If you are not required to keep the information for more than X years, and you still keep it, then you have to provide it when it's requested.

If you didn't keep it, then it can't be used against you.

If you delete it after it was requested, then you are in trouble.

Re: Migrating Uber's ledger data from DynamoDB to LedgerStore

#147
post #106

I would gladly pay 6 million/year to not be on call, and have to worry about things like bios and ssd firmware ever again.

Thats a great situation to be in when one can spend 6 million even when there was some chance to save.

I tried same for ready to eat meal everyday to save me from potential kitchen disasters but sadly numbers didn't work out.

Re: Migrating Uber's ledger data from DynamoDB to LedgerStore

#148
post #65

Congrats to anyone who worked on it! However, I'm guessing the cost of just running this team be quite large and not significantly different from the savings (6M), and add on top of it the overhead of maintenance. Payments would not likely be a long-term bet as well, so kind of interesting why teams take up such projects ? Is it some kind of sunk-cost with the engineering teams you already have?

Developing and maintaining a totally bespoke DB system with that kind of volume even for $5m/yr, spitball you could get yourself 25 top-notch engineers without AI PhDs and have another mil left over for metal. Sounds plenty feasible to have a nice tailored suit for a core part of your business.

Is accounting really a core part of Uber's business? They're a transportation company not a bank. I kind of question the premise really

Re: Migrating Uber's ledger data from DynamoDB to LedgerStore

#149
post #61
post #35

Earlier quoted context omitted.

You can split up into 10 SQLite DB's on this individual server.

You've now implemented sharding on top of SQLite. Eventually all programs will be able to read email.

Exactly! Why take a system not designed for this sort of scale and force it to scale, rather than use systems which are designed and tested for this scale and volume? All you will do is hackily re-invent all the other things that the other databases had to do to scale to this extent.

Plus size is only one limit, you would be limited to 1 write every few milliseconds. My napkin maths estimate is that there are at least 1-2m writes per hour going into this thing, so probably 300-600 writes / second (Average) and maybe over 1k writes/second peak. We are going to fall over here!

Not sure why some people seem to have a viwe of "There is no scaling problem that can't be solved with a sufficient enough number of SQLite databases".

Re: Migrating Uber's ledger data from DynamoDB to LedgerStore

#150

Earlier quoted context omitted.

>When I’m on the other side of the table I do that No, you don't. There are many established storage solutions out there. If you're in the market for one, you can easily fill days, weeks or months vetting those. So, why would you bother dealing with a sales rep from a random one you never heard of before, and isn't used by anyone. You don't even provide any details on what makes it different or better from anything e…

Well the reason I’m working on this in the first place is that when I was on the other side of the table I was looking for one. I filled in the contact forms of a couple of different startups that had products somewhat in line with what I was looking for, and talked to their sales reps. Admittedly they weren’t as early stage as my project, but on the other hand they weren’t 100% focused on my use-case either. I guess…

>I guess what I’m trying to say is that I was hoping that someone with a write intensive workload would want to spend some time evaluating a product built specifically for that.

Again, it's not clear to me exactly what it is you're doing that's any different from the plethora of existing off-the-shelf solutions.

You're saying that you started this project/company because you were looking for a solution to a specific use case (write-intensive workloads) and existing options didn't work - can you expand on that? Can you create a chart, for example, that lists out the specific things that Haystackdb does and alternatives don't? Presumably, if you optimize for write-intensive workloads, there are some drawbacks when it comes to reads - no? Or maybe storage? That's good to highlight.

What you need are whitepapers/blog posts/youtube videos/talks at conferences/etc. that highlight the technical details of your solution, because you're trying to get technical people interested in your product to the point where they will invest time to learn more.

Post reply on HN