January 17, 2024 at 12:00 am
Comments posted to this topic are about the item Learning NoSQL
January 18, 2024 at 5:46 am
Heh... let's look at the first paragraph in the article...
It's a good idea to learn more about different technologies. I've been amazed throughout my career, and even now as someone working for a software vendor, how many different technologies I run into. I'm also amazed at how little bits of knowledge comes in handy, either to help me understand a problem or to help guide others with a recommendation of how to proceed.
Now, let's rewrite it to see what I've been seeing ...
It's a good idea to learn more about the different technologies that you're already using. I've been amazed throughout my career, and even now as someone working as a DBA, how many different technologies I see people run into and spend time on. I'm also amazed at how little knowledge they have especially in the tools they already have, which frequently do the job better than the tools they're looking at.
Heh... wanna learn something new and exciting??? Then actually learn what you can do in SQL.
And watch out for people that say things like "To a hammer, everything is a nail" or "Just because you can do something in SQL doesn't mean you should" or "SQL is not the center of the universe". I especially like to challenge them to find out about that last one by turning off their SQL Server to prove it. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
January 18, 2024 at 6:04 am
We use Cassandra extensively in one of our software products. Its "active-active" clustering, and being able to perform a write on any node, is the primary reason why we use it. However, just as you mentioned in your post, Steve, we also still have, and rely upon, a regular RDBMS for other data within the product.
Some interesting aspect of Cassandra include how you distribute your cluster nodes, are they all contained within one "data center", or do you have multiple "data centers" defined? What replication factor do you choose? What consistency level do you choose?
There is a concept/feature in Cassandra called "lightweight transactions", but we don't use them. Instead, the general recommendation is that the application code provides the SQL statement you want to perform, and then another statement to effectively undo the first statement, if it fails. So for example, if I want to update a user's email address from 'kevin@myemail.com' to 'kevinSql@server.com', I would essentially make two UPDATE statements. The first would be your normal UPDATE statement to update to the new value. But if that fails, we need another statement to try and set the value back. So that means we need the original value. How do you know or get the original value? Well, you have to make a call to read the database first, at some point, before trying to update it. So that's a bit odd and doesn't seem very performant. Obviously, your use cases will vary.
And then, one last thing that I'm a bit biased on, is that Cassandra is written in and runs on Java. And they are no longer making new releases that run on Microsoft Windows OS.
January 18, 2024 at 12:39 pm
Kris Kovacs has kept his original NOSQL comparison article up-to-date. I refer back to it at intervals.
All DBs represent a compromise to achieve a set of functionality. This is true for RDBMS, NOSQL or anything else. I look at NOSQL solutions as a different set of compromises in order to gain a benefit that outweighs its cost. Understanding that cost is trickier than you might suppose.
I've certainly seen DB choices that gave a distinct advantage to their immediate users, however the advantage to the organisation was lost due to what was involved in integrating data from that DB into more general use. The problem was not really the technology choice, it was the lack of thought on how that technology choice. Like all things tacked on as an afterthought, those fixes required to address fait au compli solutions inherit a load of constraints that make the operation of those fixes suboptimal.
January 18, 2024 at 4:21 pm
This was removed by the editor as SPAM
January 20, 2024 at 5:40 pm
We use Cassandra extensively in one of our software products. Its "active-active" clustering, and being able to perform a write on any node, is the primary reason why we use it. However, just as you mentioned in your post, Steve, we also still have, and rely upon, a regular RDBMS for other data within the product.
...
That's neat. It is working well for you? Would love to know more, especially how you decide to model some data in one system or the other. If you want to share/write, let me know.
January 20, 2024 at 5:41 pm
Kris Kovacs has kept his original NOSQL comparison article up-to-date. I refer back to it at intervals.
Thanks, need to read this.
January 20, 2024 at 5:42 pm
Heh... let's look at the first paragraph in the article...
...
Heh... wanna learn something new and exciting??? Then actually learn what you can do in SQL.
And watch out for people that say things like "To a hammer, everything is a nail" or "Just because you can do something in SQL doesn't mean you should" or "SQL is not the center of the universe". I especially like to challenge them to find out about that last one by turning off their SQL Server to prove it. 😀
Learning about NoSQL vs learning more about an RDBMS are two things that can go together. This also isn't about choosing one or the other, but the reality of the world. There are lots of places that end up with different technologies for a variety of reasons. Knowing more about new (or current) tech, is always a good thing.
January 22, 2024 at 4:52 am
You missed my point... and that's actually OK. I wasn't suggesting one of the other... I was pointing out that a whole lot of other people do and it's usually SQL that they decide to not learn very well.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply