Storage - A meeting of minds

  • David.Poole

    SSC Guru

    Points: 75393

    RobertYoung (7/16/2012)


    Missing, not for the first time in such essays, is discussion of normal forms,

    Would I be correct in thinking this translates as "design your OLTP database properly and you will get better performance from your hardware"?

    I think it would be beneficial to the community as a whole if the more storage savvy amongst you wrote some articles going beyond the very basics. I've only just touched a snowflake on the tip of a very large iceberg.

  • ryan.offord

    Mr or Mrs. 500

    Points: 569

    I was working on some calculations yesterday around latency and different types of storage. Using some 'typical' figures you would see SATA being around 40 milliseconds of latency, SAS would be in the region of 20 milliseconds and PCIe around 50 microseconds. You can tweak the speed that data comes back but you still have that basic latency. This is something you have to add to every single request to get data back from the disks.

    Every touch point in the setup has the potential for latency and also the potential for failure. Network card, cable, switch and so on until you finally get to a disk that has to revolve (and you wait your turn with other requests). The beauty of systems like FusionIO is that it removes these failure / latency points, gives you a massive performance lift and allows you to have a less complex system overall while reducing costs.

    If you had the same schema design, data and queries and did a direct comparison between the three you will see a clear performance winner. The complexity gets reduced significantly as does the failure points and latency.

    Having the right design makes the world of difference but no matter what we do if there is an underlying latency you will not remove it by schema design.

  • RobertYoung

    Ten Centuries

    Points: 1130

    ryan.offord (7/17/2012)


    Having the right design makes the world of difference but no matter what we do if there is an underlying latency you will not remove it by schema design.

    If an organic NF schema reduces data footprint by an order of magnitude, not unlikely, then not only are there fewer bytes on the wire, there's less complication in the client code. Client code could be reduced to simple display. Doing what your grandfather did, using a better hardware to just do what the old software wanted, is the suboptimal choice this time.

  • Bill Kline-270970

    SSC Eights!

    Points: 915

    The article is good. The discussion has been even better.

  • mkromer

    SSC Journeyman

    Points: 79

    Wonderful article, David! I think of AlwaysOn with read-only secondaries as an implementation on CQRS and was happy to see that pattern mentioned in your story.

    BTW, did you mean that solutions like FastTrack work in "symphony" with hardware, not "sympathy" ??

    Br, Mark Kromer

  • David.Poole

    SSC Guru

    Points: 75393

    BTW, did you mean that solutions like FastTrack work in "symphony" with hardware, not "sympathy" ??

    Br, Mark Kromer

    Sorry, a Freudian slip. Though having seen FastTrack perform its worth a fanfare.

  • paul s-306273

    SSChampion

    Points: 10615

    Jo Pattyn (7/16/2012)


    Great article, will reread it twice

    I've read this article more than once.

    My experience is also of a lack of dialogue between SAN, DB and application guys.

  • quackhandle1975

    SSChampion

    Points: 11055

    One of those I added to the Briefcase for reading later on.

    So, two years later on, great article. 😀

    qh

    [font="Tahoma"]Who looks outside, dreams; who looks inside, awakes. – Carl Jung.[/font]

Viewing 8 posts - 16 through 23 (of 23 total)

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