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

171–180 of 220 posts

Re: Databases in 2024: A Year in Review

#171

Post by wslh »

Tanjreeve wrote: post #108
wslh wrote: post #38

Great heads up. I wonder about graph databases. He mentioned https://umbra-db.com/ > and https://cedardb.com/ > both include the graph use case and I wonder how they compare to https://neo4j.com/ >.

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 database system that delivers best-in-class performance for all your workloads, from transactional to analytical to graph,..."

Re: Databases in 2024: A Year in Review

#172

Post by physicles »

nojito wrote: post #49
antirez wrote: post #16

Earlier quoted context omitted.

Many non-SQL DBs had query languages that were broken Javascript-ish versions of SQL. Of course, this is wrong, and people will eventually adopt SQL instead. But if your data model isn't anything like relational DBs, non-SQL makes a ton of sense. OP seems to miss exactly this, that the Redis query language is shaped on the Redis data model, that is basically alien to the relational model. The idea behind Redis data m…

>But if your data model isn't anything like relational DBs, non-SQL makes a ton of sense. OP seems to miss exactly this, that the Redis query language is shaped on the Redis data model, that is basically alien to the relational model. Sure...but all roads lead back to SQL eventually. Another recent example also mentioned in the OP is BigTable adopting SQL.

If you write code that uses a hash map, would you insist on using SQL to query it? This makes no sense.

Re: Databases in 2024: A Year in Review

#173

Post by yla92 »

breadwinner wrote: post #126
senderista wrote: post #115

Earlier quoted context omitted.

Yes. 1. It is single-threaded, which severely limits throughput for a single instance. 2. All communication must go over a socket, which severely impacts latency for use cases where it could otherwise run in-process.

What is the better alternative?

Do checkout https://www.dragonflydb.io . It's also mentioned in the review!

Re: Databases in 2024: A Year in Review

#174

Post by brightball »

Spivak wrote: post #85
brightball wrote: post #80

Earlier quoted context omitted.

Yea, I always use Redis for very specialized purposes. Like offloading a shared data structure between threads / processes / machines so that I don’t have to deal with thread safety issues.

I understand machines but threads ?! Why introduce IPC overhead on the fastest/easiest way to share data? This is beyond a solved problem and your language probably has multiple ready-made battle tested solutions. In Python you don't even need a lib, dict is thread safe even in nogil.

Depends on the use case. Often if I’m sharing data between threads there’s a good chance I’ll want to scale it to another instance at some point so just going straight to Redis is pretty common.

Especially if there’s a chance I’d want that data to persist across restarts.

It’s one thing if I’m using a BEAM language, but otherwise I’ll usually reach for Redis.

Re: Databases in 2024: A Year in Review

#175

Post by CRConrad »

josephg wrote: post #149
antirez wrote: post #86

Earlier quoted context omitted.

The examples I made are just a subset of the protection that this provides. Similarly you can't LRANGE a set type, and so forth. So this in general makes certain errors evident ASAP (command mismatch with the key type). This does not meant that Redis would not work having generic LEN, INSERT, RANGE commands. But such commands would end also having type-specific options, that I have the feeling is not very clean. Anyw…

Eh. What people are really arguing about here is redis’s type system. Redis’s approach has some pros and some cons. I think dismissing redis’s approach out of hand for its choices is too simple a treatment. Most sql databases (like Postgres) require all types to be declared once, and then they do type checking on mutation. In that sense, sql is like a static language like C. But weirdly, the results returned from a s…

> I’d much rather if queries could return scalar values

Since when can't they?

Re: Databases in 2024: A Year in Review

#176

Post by branko_d »

rawgabbit wrote: post #55
teej wrote: post #45

Earlier quoted context omitted.

Are people choosing SQL Server independently of the Microsoft ecosystem? My understating is that you typically use it because you’re forced to choose a MS product.

SQL Server is a terrific product. And I detest most things Microsoft.

I wish Microsoft paid more attention to T-SQL though. It’s an atrociously primitive language in some ways. There is no “record” or “struct” type of any kind, table-valued functions are not composable, an error in one line may throw an exception or just continue execution to the next line depending on whether TRY..CATCH exists at some higher level… to name just a few grievances of many I accumulated over the years.

It can work well performance-wise and security-wise, but programming it can be quite a pain, and I feel that’s unnecessarily so, considering what resources Microsoft has at their disposal.

Re: Databases in 2024: A Year in Review

#177

Post by josephg »

CRConrad wrote: post #175
josephg wrote: post #149

Earlier quoted context omitted.

Eh. What people are really arguing about here is redis’s type system. Redis’s approach has some pros and some cons. I think dismissing redis’s approach out of hand for its choices is too simple a treatment. Most sql databases (like Postgres) require all types to be declared once, and then they do type checking on mutation. In that sense, sql is like a static language like C. But weirdly, the results returned from a s…

> I’d much rather if queries could return scalar values Since when can't they?

I mean, they can - but they’re always wrapped up as pseudo-tables.

Not everything is best described as a table, y’know?

Re: Databases in 2024: A Year in Review

#178

Post by datadrivenangel »

rawgabbit wrote: post #84
stackskipton wrote: post #78

Earlier quoted context omitted.

SRE who deals with some .Net stuff that uses MSSQL but is converting to MySQL. so I feel somewhat qualified to talk about MSSQL. TL;DR: Nothing interesting going on. There is nothing to talk about here. It's boring database engine that powers boring business applications. It's pretty efficient and can scale vertically pretty well. With state of modern hardware, that vertical limit is high enough most people won't enc…

I was a big proponent of MSSQL. It is still a good product but I see Microsoft constantly fumbling with new OLAP tools. It is a shame but it seems Microsoft is abandoning MSSQL.

If it's any consolation, half of the new cloud OLAP tools are basically still MSSQL

Re: Databases in 2024: A Year in Review

#179

Post by CRConrad »

epolanski wrote: post #8
badindentation wrote: post #3

The section on Larry Ellison is amusing.

I couldn't understand if it was satire or something. Do they believe the guy marries a 30 years old cause she loves him? In any case, who cares, how was that relevant..

> I couldn't understand if it was satire or something.

The quotes from last year's bit on Ellison in sibling comment https://news.ycombinator.com/item?id=42567484 might help you make up your mind.

Re: Databases in 2024: A Year in Review

#180

Post by datadrivenangel »

greggyb wrote: post #119
stackskipton wrote: post #78

Earlier quoted context omitted.

SRE who deals with some .Net stuff that uses MSSQL but is converting to MySQL. so I feel somewhat qualified to talk about MSSQL. TL;DR: Nothing interesting going on. There is nothing to talk about here. It's boring database engine that powers boring business applications. It's pretty efficient and can scale vertically pretty well. With state of modern hardware, that vertical limit is high enough most people won't enc…

I'll probably come across as a shill here, but there is a lot going on with SQL Server, all included in your license (Standard Edition has limitations on scaling). Some of these things are merely passable, some are great, but it's all included. The key takeaway is that SQL Server is a full data platform, not just an RDBMS. - RDBMS: very solid, competitive in features - In-memory OLTP: (really a marketing name for a w…

Microsoft is a decent deal if you go 100% in on Microsoft, but it's important to budget for additional support because actually using microsoft products has quite the learning curve.
Post reply on HN