MoSQL

  • Steve Jones - SSC Editor

    SSC Guru

    Points: 714093

    Comments posted to this topic are about the item MoSQL

  • call.copse

    SSCoach

    Points: 16653

    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: 18801

    Those that ignore history are doomed to repeat it.

    ...

    -- FORTRAN manual for Xerox Computers --

  • xsevensinzx

    One Orange Chip

    Points: 25437

    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: 993652

    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.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."
    When you put the right degree of spin on it, the number 3|8 is also a glyph that describes the nature of a DBAs job. ๐Ÿ˜‰

    Helpful Links:
    How to post code problems

  • x

    SSC-Insane

    Points: 23349

    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: 442093

    Comes down to using the right tool for the job.

  • Eric M Russell

    SSC Guru

    Points: 124937

    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. Seek What They Sought." - Matsuo Basho

  • Jeff Moden

    SSC Guru

    Points: 993652

    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.
    "If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
    "Change is inevitable... change for the better is not."
    When you put the right degree of spin on it, the number 3|8 is also a glyph that describes the nature of a DBAs job. ๐Ÿ˜‰

    Helpful Links:
    How to post code problems

  • xsevensinzx

    One Orange Chip

    Points: 25437

    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.

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

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