Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Databases in 2024: A Year in Review

cs.cmu.edu

Post reply on HN
Print view View original

191–200 of 220 posts

Re: Databases in 2024: A Year in Review

#191

Post by tayo42 »

nodamage wrote: post #155
tayo42 wrote: post #48

Earlier quoted context omitted.

> Andy's video (linked in the post) Is there a "to long didnt watch" summary any one knows of? I hate videos, but am curious lol

As far as I can tell the two main criticisms in the video are that: 1. The Redis API requires the developer to use different commands to retrieve/manipulate data depending on the type of data being stored. To retrieve a string you use GET, but if you want to retrieve a list it's LRANGE, for a set it's SMEMBERS, for a hash it's HGETALL. (As opposed to an API design which would allow you to call GET on all of the diffe…

thanks for saving me some time!

Re: Databases in 2024: A Year in Review

#192

Post by paulddraper »

threeseed wrote: post #72
paulddraper wrote: post #37

Earlier quoted context omitted.

There are production uses of MongoDB (Stripe comes to mind). But it is certainly not a popular choice there.

MongoDB does over $2b in revenue (and growing by 20%) each year. There are a lot of production uses.

In my experience, these are largely startups or non-production use cases.

Also, MongoDB charges an arm and a leg and does not make it particularly easy to self-host (and many newer features are limited to their hosting).

Re: Databases in 2024: A Year in Review

#193

Post by Tanjreeve »

wslh wrote: post #171
Tanjreeve wrote: post #108

Earlier quoted context omitted.

Umbra and cedar are both still relational databases. Afaik the jury is now out on if graph databases are better than modern relational databases for most graph queries especially ones with good query planners/compilers. The only time graph DBs seem to be consistently better is for very specialist many degrees traversals for small amounts of data.

My point is that both Umbra and Cedar mentioned graph support, and I don't believe this was a coincidence. Umbra highlights: "Groupjoins enable efficient computation of aggregates, worst-case optimal joins handle complex queries on graph structured data, and range joins efficiently evaluate queries with conditions on location or time intervals." while Cedar includes in the hero: "CedarDB is a relational-first databas…

I think that phrase of "relational first" explains it best. Anything that supports joins can support a graph. Whether it'll perform satisfactorily is going to depend on the compiler and use case/size.

Re: Databases in 2024: A Year in Review

#194

Post by mike_hearn »

menaerus wrote: post #159
rockwotj wrote: post #121

Earlier quoted context omitted.

RE ScyllaDB, there will absolutely be no fork and it’s very unlikely they have ever had a meaningful contribution to Scylla OSS (which is not changing, just going to bit rot and the enterprise version which was closed source was moved to source available). The reasoning being the bar is very high for contributions. It’s C++ 20/23 without virtual memory and a userland cooperative thread per core scheduler (this is the…

> It’s C++ 20/23 without virtual memory Not sure what you mean by this? Virtual memory is implied by the CPU MMU and consequently OS kernel. Perhaps you meant they use a lot of custom memory allocation schemes? Otherwise, I agree that the bar is quite high since (1) the problem at hand is already too complex (scalable LSM), and (2) pretty much anything in the code is custom made, e.g. avoiding the OS kernel as much a…

Seastar runs everything in kernel mode.

Re: Databases in 2024: A Year in Review

#195

Post by bdangubic »

breadwinner wrote: post #188
bdangubic wrote: post #137

Earlier quoted context omitted.

this of course is false… it scales fine if you know what you are doing.

It is of course true... it is well known that SQL Server scales to department level, but Oracle scales to company level. This is true inside Microsoft and Oracle as well. Inside Microsoft, they have a bug database per division but Oracle has a single database for the entire company. Ask people who work at those companies. See also scalability sections in these artcles: https://airbyte.com/data-engineering-resources/o…

if it is good for SO it should be good for most :)

https://stackoverflow.blog/2008/09/21/what-was-stack-overflo...

Re: Databases in 2024: A Year in Review

#196

Post by senderista »

kwillets wrote: post #44

I spent the past year puzzling over the DB market as well, but I don't feel like I'm much closer to understanding it. It appears that a lot of attention is now directed at the folks doing 100 MB queries, and the high end has moved past everybody's radar. My idea of an exciting product is Ocient, who have skipped over Cloud and gone for hyperscale on-prem hardware. Yellowbrick is also a contender here. I have a lot of…

I was seriously considering applying to Ocient (had an internal referral), but there's no way I could live on their salary ranges ($145K-185K quoted for senior SWE roles), given that I live in a HCOL area.

Re: Databases in 2024: A Year in Review

#197

Post by menaerus »

mike_hearn wrote: post #194
menaerus wrote: post #159

Earlier quoted context omitted.

> It’s C++ 20/23 without virtual memory Not sure what you mean by this? Virtual memory is implied by the CPU MMU and consequently OS kernel. Perhaps you meant they use a lot of custom memory allocation schemes? Otherwise, I agree that the bar is quite high since (1) the problem at hand is already too complex (scalable LSM), and (2) pretty much anything in the code is custom made, e.g. avoiding the OS kernel as much a…

Seastar runs everything in kernel mode.

Makes no sense. Source?

Re: Databases in 2024: A Year in Review

#198

Post by emmelaich »

thayne wrote: post #146
emmelaich wrote: post #123

Earlier quoted context omitted.

If it supports backup to a file, you can have it write to a named pipe and from there to wherever. I used this hack for backing up Oracle 30 years ago. Something like 'mknod p backup.dmp; oradump .... file=backup; dd if=backup.dmp | ssh othermachine receiver-process'

Not necessarily. That won't work if the backup uses apis that a pipe doesn't support, like seek or reading back from the file.

Sure; does any backup actually do that? I guess it's possible.

Backups (at least db backups) used to be made with the assumption that the backup device is tape.

Re: Databases in 2024: A Year in Review

#199

Post by breadwinner »

bdangubic wrote: post #195
breadwinner wrote: post #188

Earlier quoted context omitted.

It is of course true... it is well known that SQL Server scales to department level, but Oracle scales to company level. This is true inside Microsoft and Oracle as well. Inside Microsoft, they have a bug database per division but Oracle has a single database for the entire company. Ask people who work at those companies. See also scalability sections in these artcles: https://airbyte.com/data-engineering-resources/o…

if it is good for SO it should be good for most :) https://stackoverflow.blog/2008/09/21/what-was-stack-overflo...

You don't believe that web visitors are directly querying SQL Server, right? I can believe they are storing their employee database in SQL Server... they have hundreds of employees.
Post reply on HN