November 28, 2015 at 1:22 pm
Comments posted to this topic are about the item NoSQL Complaints
November 30, 2015 at 2:51 am
RDBMS is just a specific flavour of DBMS. We need persistence and we use file systems, document stores, relational data etc. Differing classes of data stores are already in use so there should not be an issue with further classes to apply when appropriate.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 30, 2015 at 6:57 am
.. One thing in the piece I did notice is that it's likely that we will see more platforms and products incorporate both RDBMS and non-RDBMS technologies together. We see that in SQL Server already with the addition of columnstore technologies in the last few versions and Polybase to SQL Server 2016. I expect we'll also start to see some of the capabilities of DocumentDB added to SQL Server, along with, perhaps, graph based technologies in the future..
In addition to the various non-traditional data storage formats and retrieval methods that SQL Server currently supports, we also have had a federated version of SQL Server, Parallel Data Warehouse, for several years. It's designed for high end MPP appliances, but if the technology could be retrofitted to scale horizontally across commodity servers and then incorporated into Enterprise and Azure editions, then that would truly turn the NoSQL vs. RDMS debate on it's head.
Adding insult to injury for many in the NoSQL community; the feature most requested by their paying customers is... SQL.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 30, 2015 at 7:32 am
Cassandra vs. Shamwow!
If you're a mechanic, if you get a new tool, you understand what it can do, how it will work and where it will not work well. You keep all your old tools - because you know how to use them.
With technology, every time a new tool comes out, countless people jump up and down shouting how this will be the tool to end all tools - and that you can just throw away all your old tools - just like in those informercials.
Frankly, these are just ruminations of people who still believe that the latest DB system will be the one to rule them all.
The more you are prepared, the less you need it.
November 30, 2015 at 7:53 am
Much of the NoSQL vs RDMS debate boils down to application developers looking for a more practical persistence layer. If that's the case, then the DBA should simply take a step back and let them do their own thing. For example, a shopping cart for an ecommerce website is not the same thing as a purchase order for accounting, and only when the customer actually enters their credit card information and clicks the submit button does it become a set of golden records worth managing permanently. The same goes for attempts to do stuff like logging page hits, mouse hover over events, and device telemetry output; it's just digital fluff that's not relevant at the operational level until it's been data mined really hard and distilled, which should be done elsewhere, using something like Hadoop.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 30, 2015 at 7:58 am
I believe it is too late for me to think beyond the traditional RDBMS.
November 30, 2015 at 8:23 am
Eric M Russell (11/30/2015)
...For example, a shopping cart for an ecommerce website is not the same thing as a purchase order for accounting, and only when the customer actually enters their credit card information and clicks the submit button does it become a set of golden records worth managing permanently...
In the example when saving an actual order it doesn't have to be to a database. This could be implemented using transaction message queues thus further decoupling the back office from the online presence to ensure that both systems can remain performant without disturbing each other.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 30, 2015 at 8:24 am
The file system never made it to a RDBMS nor did exchange server. All the major vendors have always had product that they decided not to use a RDBMS for.
412-977-3526 call/text
November 30, 2015 at 8:32 am
robert.sterbal 56890 (11/30/2015)
The file system never made it to a RDBMS nor did exchange server. All the major vendors have always had product that they decided not to use a RDBMS for.
Quite right too. The Windows Registry was originally implemented as a cut down SQL Server instance. Sometimes other implementations are a better suited data repository for a given scenario.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 30, 2015 at 8:56 am
Gary Varga (11/30/2015)
Eric M Russell (11/30/2015)
...For example, a shopping cart for an ecommerce website is not the same thing as a purchase order for accounting, and only when the customer actually enters their credit card information and clicks the submit button does it become a set of golden records worth managing permanently...In the example when saving an actual order it doesn't have to be to a database. This could be implemented using transaction message queues thus further decoupling the back office from the online presence to ensure that both systems can remain performant without disturbing each other.
Amazon appears to do this. The orders don't go into a live db, or the same db I query as an "order" in real time. There are delays at times. Usually seconds/minutes, but delays, yet AMZN seems to manage that well.
November 30, 2015 at 9:13 am
Steve Jones - SSC Editor (11/30/2015)
Gary Varga (11/30/2015)
Eric M Russell (11/30/2015)
...For example, a shopping cart for an ecommerce website is not the same thing as a purchase order for accounting, and only when the customer actually enters their credit card information and clicks the submit button does it become a set of golden records worth managing permanently...In the example when saving an actual order it doesn't have to be to a database. This could be implemented using transaction message queues thus further decoupling the back office from the online presence to ensure that both systems can remain performant without disturbing each other.
Amazon appears to do this. The orders don't go into a live db, or the same db I query as an "order" in real time. There are delays at times. Usually seconds/minutes, but delays, yet AMZN seems to manage that well.
This is true. I have read an Amazon white paper (a LONG time ago) and all I can recall was that they had a RDBMS at the back end and a different technology initially storing the orders. I think, but I may be recalling incorrectly, that they used a third technology for the basket - which I think was a NoSQL database (although it was not referred to as that).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 4, 2015 at 6:07 am
I think NoSQL has it's uses. The trend I've experienced is poor database and/or query design in relational databases can lead some developers to believing that the relational database simply cannot handle the load and that the only solution is NoSQL. Bad design = bad performance in any data architecture.
I'm a relational guy, but I love the NoSQL movement and I can honestly vouch for its versatility in certain circumstances. I've introduced MongoDB with great effect in some areas of a data platform.
December 4, 2015 at 6:25 am
Clive Strong (12/4/2015)
I think NoSQL has it's uses. The trend I've experienced is poor database and/or query design in relational databases can lead some developers to believing that the relational database simply cannot handle the load and that the only solution is NoSQL. Bad design = bad performance in any data architecture.I'm a relational guy, but I love the NoSQL movement and I can honestly vouch for its versatility in certain circumstances. I've introduced MongoDB with great effect in some areas of a data platform.
Spot on. Although I would go so far as to say:
Bad design = bad performance in any
dataarchitecture.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 4, 2015 at 8:57 am
Valid point!
December 4, 2015 at 10:15 am
I find it rather sad to see the NOSQL discussion approached so often in terms of not having any SQL and not having anything at all relational. A lot of people understand NO in NOSQL to stand for "Not Only". Judging by comments on the web (not so much here) such people must form a tiny minority of those who use the term. I guess people tend to forget things like the SQL front end developed for read-only access to IDMSX and RDS support of the relational model alongside its hierarchical network model and SQL alonside its native C and C++ API, as well as not remembering that Ingres originally supported only QUEL (no SQL support at all) and later on, for a long time, supported both QUEL and SQL and probably not even being aware is things like Cypher Query Language (a query language for a graph database that includes an SQL-like sublanguage) and RDFSharp, SPARQL and SPASQL (essentially RDF graph data living in SQL databases and/or accessible using SQL as a framework).
As far as the "throw away the relational model" version of NOSQL is concerned, an awful lot of what is going on is repeating old mistakes. I guess learning from other peoples mistakes is no longer fashionable, one has to repeat them instead? There's a good paper about this by Mohan (IBM Fellow at Almeda, formerly IBM India Chief Scientist) at History Repeats Itself: ...
Tom
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply