Thanks for the article. On the topic of redis: 3 executives from redis built FalkorDB (succeeded redisgraph) raising 3m to build a graphdb for better rag (ref:https://github.com/FalkorDB/GraphRAG-SDK)
Databases in 2024: A Year in Review
151–160 of 220 posts
Re: Databases in 2024: A Year in Review
#152Earlier quoted context omitted.
You totally miss that Redis is more like a remote interpreter with a DSL that manipulates data structures stored at global variables (keys): you (hopefully) would never complain about languages having this semantics. I don't think you understood how Redis collections work. The items are just strings, they can't be mixed like integers or strings together or whatever, nor collections can be nested. The Redis commands d…
>> stored at global variables This is an interesting (and correct) perspective. Global variables scare us in software but we are ok with it when it comes to application state stored in a db.
Global variables can definitely be overused, but in the right situations, they’re generally fine. After all, the filesystem is a big global variable too. So is any database. But people don’t complain too much about that.
The strongest argument against global variables is that they don’t show up in the parameter lists of functions. In that way, they’re sort of “spooky action at a distance”. And they encourage functions to be impure. But if this bothers you, you can always pass your database connection as an explicit parameter to any function which interacts with it.
Re: Databases in 2024: A Year in Review
#153Earlier quoted context omitted.
You totally miss that Redis is more like a remote interpreter with a DSL that manipulates data structures stored at global variables (keys): you (hopefully) would never complain about languages having this semantics. I don't think you understood how Redis collections work. The items are just strings, they can't be mixed like integers or strings together or whatever, nor collections can be nested. The Redis commands d…
>> stored at global variables This is an interesting (and correct) perspective. Global variables scare us in software but we are ok with it when it comes to application state stored in a db.
They aren’t scary. They are useful and you probably use them in many forms (lambdas capturing locals, logging, singletons).
This is yet another reason why single threaded should be the default assumption and multi-threaded require special consideration.
Re: Databases in 2024: A Year in Review
#154I highly recommend their Youtube series on databases. They have great guest speakers.
Link?
Re: Databases in 2024: A Year in Review
#155Wow, the reasons why Redis commands API suck in Andy's video (linked in the post) are the weakest ever. It is possible to make a case against the Redis API (I would not agree of course but... it's totally legitimate), but you gotta have stronger arguments than those, particularly if you are a teacher of some kind. Especially: you need to be somewhat fluent in Redis and how developers use Redis in order to understand…
> 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 different data types and have it return the right thing.)
2. The lack of a predefined schema means you can overwrite values with different types. So you can create a list named "foo" and then overwrite it with a string named "foo" and then overwrite that with a hash named "foo" and Redis will happily do it, meaning the developer needs to keep track on their end what actual type any given key is holding onto.
To me these criticisms come across as essentially saying "Redis doesn't behave like a RDBMS" to which I suppose antirez's point is "well, yeah, it's not supposed to".
Re: Databases in 2024: A Year in Review
#156Earlier quoted context omitted.
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…
Yes, it has a ton going on but most of companies I've found using it are using primarily as RDBMS and thus MySQL/Postgres could replace it. Other stuff it did could be replaced by tools more geared towards specific function and most of time, at much lower cost. Licensing isn't cheap. For anyone wondering, before discount, it's 876/yr per core for Standard and 3288/yr per core for Enterprise. Also note that Standard i…
Theres still an express version thats free to use but limits database to 10gig, for what its worth
Re: Databases in 2024: A Year in Review
#157Wow, the reasons why Redis commands API suck in Andy's video (linked in the post) are the weakest ever. It is possible to make a case against the Redis API (I would not agree of course but... it's totally legitimate), but you gotta have stronger arguments than those, particularly if you are a teacher of some kind. Especially: you need to be somewhat fluent in Redis and how developers use Redis in order to understand…
SQL is king and history has shown non-sql languages are not good which causes many non-sql DBMS's to adopt sql eventually.
For what it's worth, SQL kind of sucks. It's just the de facto choice because it's extremely widespread and good enough for 80% of the use cases out there and what's missing can be kludged on top of it, either by specific DB vendors, or by various extensions.
It's not too hard to come up with alternatives that improve upon individual aspects of SQL like https://prql-lang.org/ but the barrier of entry is about as high as trying to make a huge social media network, most attempts will remain niche.
Then again, most software kind of sucks, it's just that some of it also works. For example, the Linux FHS reads like an overcomplicated structure that is the way it is for historical reasons, but works in practice.
Re: Databases in 2024: A Year in Review
#158Earlier quoted context omitted.
> It's boring database engine that powers boring business applications. FWIW, it also powered the most popular (in terms of player base) MMORPG before WoW took over. And I wouldn't be surprised to find it in aviation, railways, powerplants, grid control, etc...
Before wow , there was either lineage, and then EverQuest. I guess it was Lineage as Korean used mainly MSFT softwares?
Looking at some subscription charts I was able to quickly find now I see I made a mistake. I was thinking of Lineage 2 using mssql, while it was Lineage (1) that was the major one. I do not know anything about its backend and it would be hard to assume considering how much older it is.
1. https://ics.uci.edu/~wscacchi/GameIndustry/MMOGChart-July200...
Re: Databases in 2024: A Year in Review
#159I think one thing Andy misses about why people were pissed about Elastic and Redis but not as many for MongoDB and some other is their license and size of Contributors Community. When original license is as restricted as AGPL it is unlikely there is much of embedded use... so less people are impacted in truly catastrophic way Also if there is no contributor community to speak of... who is going to do the fork ? I put…
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 as possible. And they pay peanuts for the skills needed to do the job.
Re: Databases in 2024: A Year in Review
#160> There was no major effort to fork off MongoDB, Neo4j, Kafka, or CockroachDB when they announced their license changes. AFAIK people didn't take MongoDB seriously from the start, especially with the "web scale database" joke circulating. The Neo4j Community version has been under GPLv3 for quite some time, while the Enterprise version has always been somewhat closed, regardless of whether the source code was availab…
There are production uses of MongoDB (Stripe comes to mind). But it is certainly not a popular choice there.
It’s sad, but there are a lot of companies using it. In all places I know (directly or friends) it’s being chosen as „easier”. Almost everyone ends up not knowing the real schema of data inside the database, but using Spring-magic they are already lost and not owning the data.
Maybe the enterprise Mongo is not so widely spread (they earn much, because they are not cheap), but free version is IMO overused and popular :(