Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

bondsbw bondsbw
  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , Bass wrote

    The slowness entirely comes from the fact that ACID-compliant DBs typically have to wait for a process involving a physically moving part to complete before they can return a success code. This process is measured in milliseconds. Milliseconds. There is no voodoo you can do that make that fast. 

    Other than well-tuned indexes, probably the best thing you could do for SQL performance would be to trade the HDDs for SSDs and improve the IO ops/second by a factor of 50.

    But then that is just a factor of 50.  Will your database need to grow to handle a factor of 50 increase in usage over the next year or two?  If it's already big enough to warrant this discussion, chances are the answer to that question is "yes".  And, of course, SSD will also improve NoSQL performance.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , figuerres wrote

    what about json ?   that is also a pile of strings with some braces tossed in for fun but folks love that ....  

    The primary use of JSON is for holding data, not as an API.  And when it is used as an API such as for POST data, it is rare that JSON is handwritten.  It is often converted from a native API.  The same could be said about XML/SOAP.

    SQL on the other hand is even today often handwritten and sent directly to the server, which is prone to injection.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    @swheaties:  Amen.  This is really what I was talking about.  SQL is one of the only, and definitely the most popular, services where the most common API is strings.  

     

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , Bass wrote

    a desire to avoid SQL

    This by itself is a virtue. :)

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    And besides, I'm just describing one aspect of one form of NoSQL database.  There are many other aspects that need to be weighed, and several types of data stores that fall under the NoSQL moniker.  We could have debates on KV-store vs. document, object vs. graph... it's not just about NoSQL vs. Relational.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , figuerres wrote

    *snip*

    You seem to be assuming worst case, if the server and database are setup halfway right then the tables and indexes will be in memory; a more normal run will have no disk Io. and just some CPU time to make the result set. 

    If you have several gigabytes or terabytes of data, then I doubt all of your tables and indexes will be in memory.

    If we're talking about some tiny database, then what's to debate?  Most anything you throw at it will be fast enough.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , RealBboy360 wrote

    Writing the joins is no big deal, that's a one time thing. Performance-wise no comparison?  Even if MS SQL Server is 30x faster now?  (This I don't know)?

    Relational tables are written to disk in pages.  If I have to join 100 tables to get one or a few records from each, that means I have to read from many pages on disk, and this can be slow to very slow depending on how fragmented your pages are across the disk (and of course how well you set up indexes relative to the particular query plan you are running).

    In a document database, all the data for a document is stored together.  So if there are N documents, in theory a document database would be around N times faster retrieving all the data for a single document.

    And "30x" sounds like a magic number.  I'm not disputing it since I don't know where it comes from, but it's probably either for an average query plan or the average across all common query plans or something else that isn't specific enough to have any idea how it would fare for a particular type of query.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , Jim Young wrote

    This must be a joke.

    I fail to see the humor.  Not everything is a hammer and not everything is a nail.

  • Vortex based mathematics.

    If your math breaks down when you change base, it's not math.

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    @spivonious:  I've never used MongoDB (my NoSQL experience is with db4o and I conceptually understand document databases such as RavenDB).  But if the primary purpose of your system is to figure out how many hammers you have, then querying an object graph rooted at Customer isn't going to be as efficient as the RDBMS solution.  The situation you stated is an example where RDBMS solutions excel.

    OTOH, if you have a document that has dozens or hundreds of objects nested, and you just want to gather all the information about a single document... well, I'll have it out of a document database before you even get the second line of SQL join written.  Performance-wise, there would be no comparison, even a fairly trivial document DB would beat any RDBMS, any day.

    My approach, if you need super-fast statistical queries on the data stored in your document DB, replicate that DB to an RDBMS and do your queries there.