The Consistency Debate

  • Banking is a good example. However, transactional consistency is not about deposits and withdraws, but about transfers. If you transfer money from your account to another account to pay a bill, you may assume that it either succeeds or bounces. If the money has been taken from your account, but the transfer to the other account failed for whatevr reason, you really want that money returned to your account!

    Transactional consistency involves multiple operations. It might involve moving money, documents, images, or any other data around, splitting or joining data, or other operations that might destroy valuable assets if canceled halfway through. Transactions are committed or rolled back as a whole, and while the first might occur 99.9% of the times, the later is very important to maintain credibility among your customers.

    Consistency is more often than not an assumption as long as everything goes well. It is a safety net if something does go wrong. Then your customers don't want to hear that it should be save, but that it is save. You do understand how important this data is, don't you?

  • Paul Stafford (3/13/2012)


    GSquared (3/13/2012)


    I think local, up-to-the-hour, or up-to-the-day data is probably good enough for a lot of things. Like ads on websites (to name one with a lot of money attached to it).

    So, in those cases, the editorial is exactly right. Distributing a "recent enough" copy of the data in a read-only, optimized-for-Selects format, makes all kinds of sense.

    In others, it needs to be real-time. I think banking is actually a poor example of this, because most people don't need their balance to be up-to-the-second. On the other hand, there are medical data applications where it could be life or death. "Has Mr. Smith not had his dose of X yet, or is the database a few minutes out of date?" could be a question that kills someone, either through a missed dose of something critical, or a double-dose of something that turns lethal at higher blood concentrations. And so on.

    Having worked in both the financial and health care industries, I can tell you it's the financial sector that is much less tolerant of data errors and inconsistencies. In health care, bad data is just accepted with a shrug of the shoulders.

    Yep. And the reason for the huge importance granted to financial data is laregely due to the need for audits required by government regulations. I've worked in that industry, and I've seen people get their panties in a serious wad over tiny data errors, while ignoring gigantic data errors that weren't audit-related.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • vliet (3/13/2012)


    Banking is a good example. However, transactional consistency is not about deposits and withdraws, but about transfers. If you transfer money from your account to another account to pay a bill, you may assume that it either succeeds or bounces. If the money has been taken from your account, but the transfer to the other account failed for whatevr reason, you really want that money returned to your account!

    Transactional consistency involves multiple operations. It might involve moving money, documents, images, or any other data around, splitting or joining data, or other operations that might destroy valuable assets if canceled halfway through. Transactions are committed or rolled back as a whole, and while the first might occur 99.9% of the times, the later is very important to maintain credibility among your customers.

    Consistency is more often than not an assumption as long as everything goes well. It is a safety net if something does go wrong. Then your customers don't want to hear that it should be save, but that it is save. You do understand how important this data is, don't you?

    Deposits and withdrawals ARE transfers, by definition, and have to be treated with the same ACID properties.

    But Steve's point (and mine) is that when you run a debit card through a scanner and purchase a soda at a 7-11, it probably doesn't need to check your up-to-the-millisecond ballance before running the purchase. If you had a positive ballance in the account that morning, the machine probably doesn't need to check beyond that point before accepting/declining the purchase.

    Nobody here (that I've noticed) is suggesting that losing a deposit or an account transfer is acceptable.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • GSquared (3/13/2012)


    Paul Stafford (3/13/2012)


    GSquared (3/13/2012)


    I think local, up-to-the-hour, or up-to-the-day data is probably good enough for a lot of things. Like ads on websites (to name one with a lot of money attached to it).

    So, in those cases, the editorial is exactly right. Distributing a "recent enough" copy of the data in a read-only, optimized-for-Selects format, makes all kinds of sense.

    In others, it needs to be real-time. I think banking is actually a poor example of this, because most people don't need their balance to be up-to-the-second. On the other hand, there are medical data applications where it could be life or death. "Has Mr. Smith not had his dose of X yet, or is the database a few minutes out of date?" could be a question that kills someone, either through a missed dose of something critical, or a double-dose of something that turns lethal at higher blood concentrations. And so on.

    Having worked in both the financial and health care industries, I can tell you it's the financial sector that is much less tolerant of data errors and inconsistencies. In health care, bad data is just accepted with a shrug of the shoulders.

    Yep. And the reason for the huge importance granted to financial data is laregely due to the need for audits required by government regulations. I've worked in that industry, and I've seen people get their panties in a serious wad over tiny data errors, while ignoring gigantic data errors that weren't audit-related.

    Very true. Sarbanes-Oxley was the driver of much of that attention to detail.

  • I wouldn't use ATM's as an example as I think you will find that in this day and age, all ATM transactions are live (both debit and credit cards).

    You need to remember that people travel all over the planet these days and still need to use their cards, do you think this data is stored in 3rd party databases?

    That would be a logistical nightmare, not to mention the security implications 🙂

    -d

  • David in .AU (3/14/2012)


    I wouldn't use ATM's as an example as I think you will find that in this day and age, all ATM transactions are live (both debit and credit cards).

    You need to remember that people travel all over the planet these days and still need to use their cards, do you think this data is stored in 3rd party databases?

    That would be a logistical nightmare, not to mention the security implications 🙂

    -d

    ATMs and credit/debit card scanners attached to POS systems are definitely real-time. At least at most US retailers (I can't speak for other industries/countries, just don't know enough about them). Steve's point is that making them operate off of distributed databases with a latency factor to them probably wouldn't hurt anything, and would reduce the transactional load on primary data servers.

    Nobody (that I know of) is doing that. The question in the editorial is, would it hurt anything if they did? There would be definite benefits to doing so, and there would also be some potential drawbacks regarding securing multiple datacenters (true of any cloud solution), but would the costs outweigh the benefits?

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

Viewing 6 posts - 16 through 20 (of 20 total)

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