July 16, 2012 at 4:30 pm
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.
July 17, 2012 at 1:31 am
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.
July 17, 2012 at 6:21 am
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.
July 17, 2012 at 11:44 am
The article is good. The discussion has been even better.
July 22, 2012 at 6:54 pm
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
July 24, 2012 at 10:00 am
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.
December 18, 2012 at 2:16 am
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.
August 8, 2014 at 7:46 am
One of those I added to the Briefcase for reading later on.
So, two years later on, great article. 😀
qh
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply