MoSQL

Question

Post reply

MoSQL

Steve Jones - SSC Editor

SSC Guru

Points: 736078
More actions
December 5, 2018 at 9:45 pm

#382390

Comments posted to this topic are about the item MoSQL

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply

call.copse SSCoach Points: 18045 More actions · Answer 1

Hear hear. I doubt it's been a real revelation to be fair but the words are certainly rational and welcome...

jay-h SSCoach Points: 18816 More actions · Answer 2

Those that ignore history are doomed to repeat it.

...

-- FORTRAN manual for Xerox Computers --

xsevensinzx One Orange Chip Points: 25560 More actions · Answer 3

I guess it really depends on what side of the fence you are on. There is clearly a huge issue with having data locked down and not easy to shift regardless of the size. The idea you cannot freely access and conform data is a huge issue many organizations have with the RDBMS. There is also a huge issue with trying to figure out what to do with the data once it's captured. In meaning, the turnaround time to add new data sources, new models, etc can be a huge burden on everyone just as it's a huge burden to learn something new just to access data out some NoSQL system that was just implemented.

Jeff Moden SSC Guru Points: 1004290 More actions · Answer 4

Heh.... to play a bit on the quote in my signature line (which is also a play on words)...

Them (whoever they are): "Yeah Jeff? Well, to a hammer, everything is a nail".
Me: Agreed... so why are you trying to use a pipe wrench to drive nails"? 😀

I love the new term... "MoSQL".

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

x SSC-Insane Points: 23660 More actions · Answer 5

So go ahead and promote more SQL Server databases. Google thinks they're good for many applications, and that's good enough for most developers.

It doesn't look like Google used SQL Server in Spanner or Chubby. I'm probably the odd one out because I actually read the articles LOL!

Even with NoSQL, at some point you're going to be faced with consistency requirements. Either you code for consistency in the application layer, or you generalize it and it becomes part of your data access layer. In the absence of either, you are only offering statistical probabilities that the database "might be in a particular state."

The linked papers are pretty interesting! Google still does not violate CAP, but they really have incredible redundancy in their networks and produce the sort of high availability that really reduces the 'P' in CAP. I found this little snippet really awesome:

Starting in 2009, due to “excess” availability, Chubby’s Site Reliability Engineers (SREs) started forcing periodic outages to ensure we continue to understand dependencies and the impact of Chubby failures.

I still agree that for the scale that most of IT works at, SQL Server is a great solution, while there may be areas that you want to build custom data storage systems, you really need a good reason to and you'd better have some seriously skilled programmers to handle what SQL Server provides out of the box.

Lynn Pettis SSC Guru Points: 442467 More actions · Answer 6

Lynn Pettis

SSC Guru

Points: 442467

December 6, 2018 at 9:08 am

#2015682

Comes down to using the right tool for the job.

Eric M Russell SSC Guru Points: 125560 More actions · Answer 7

I see the arguments for or against schema-less and transaction-less databases as similar to debates about corporate dress codes. For example, it can be true that allowing *some* employees to wear tee-shirts and shorts into the office can improve worker productivity, moral, etc. But it also depends on self imposed constraints and the the individual's role in the organization. Warehouse workers certainly don't need a coat and tie, but there are different expectations for public facing staff or C level executives.

Likewise, some databases are inherently transactional and are relied upon to be a single version of truth, especially for mission critical things like financial applications. But, yes, if you've got a team in the back office performing sentiment analysis against petabytes of social media feeds, then the focus should be on maximizing turnaround and minimizing operational costs; referential integrity and pants are optional.

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Jeff Moden SSC Guru Points: 1004290 More actions · Answer 8

Lynn Pettis - Thursday, December 6, 2018 9:08 AM
Comes down to using the right tool for the job.

Heh... so different size hammers. 😀

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

xsevensinzx One Orange Chip Points: 25560 More actions · Answer 9

Eric M Russell - Thursday, December 6, 2018 10:49 AM
But, yes, if you've got a team in the back office performing sentiment analysis against petabytes of social media feeds, then the focus should be on maximizing turnaround and minimizing operational costs; referential integrity and pants are optional.

Well, maximizing turnaround and operational costs are also huge with out the petabytes of data too. When I mentioned about people on the other side of the fence in my previous comment, it was also about those who are doing something with the data once it's in the RDBMS. In a lot of cases, developers and DBA's can figure out what they want to do with the data when it comes to building that RDBMS. The issue crops up when you want to bring it beyond the RDBMS to analyze and turn what you have captured into something else. Then it falls on non-technical people working with technical people trying to figure out what they want, when in a lot of cases, they just don't know what they want. Thus, having that ability to turn on a dime and constantly change the model is a major drawback to the RDBMS on top of just being able to not have to worry about optimization and so forth of the final model, just throw more nodes at the problem until it's fast enough.