Entre los lastres del progreso Algunos hábitos de los queretanos criticados desde la

Another common example of the problem is selling products with limited inventories. When you get down to the last “one” item in stock,many different people could potentially purchase the same “last” item because the database servers weren’t synchronized quickly enough after the first person pressed the buy button. Many people will be falsely led to believe they purchased the last one when,in reality,a database conflict exists and the in- ventory isn’t there.

There are good,though not widely used,hybrid approaches to deal with these issues. Of course,as with all technology designs,the right design approach varies substantially, depending on the business and technical objectives.

The following questionnaire can help to determine the better approach to take: Data Distribution Questionnaire

1. Do you plan to have only a single DB server? If yes, no problem; stop here. If no, go to 1a.

1a. Are you using multiple database servers to increase availability or to increase performance, or both? (This answer might be used later.)

2. Will these database servers be connected by a high-speed network connection/ link such as ATM or fast Ethernet?

2a. Will only two database servers replicate to each other?

If the answers to 2 & 2a are yes, stop here, no problem (though extremely high transaction systems still could have problems peer-to-peer replicating fast enough—but only a small number of companies would generate this much traffic). If the answer to either 2 or 2a is no, go to 3.

3. Will all data entry/modifications take place on a single database server? If yes, no problem,use master/slave replication with all the other nonprimary servers acting as slaves. If the answer is no, go to 4.

4. Will only add functions be performed on the distributed database servers (that is, no edit or modify to existing records)? If the answer is yes, replication should work okay, but go to question 4a, just in case. If the answer is no, definitely go to 5.

4a. Will all the added database records be completely independent of any database information that changes based on those additions (that is, the client can place an order for a product, regardless of whether it’s in stock in the computer and that entry won’t decrement the inventory in real time)?

If the answer is yes, with proper programming and database development, it should work fine. If the answer is no, go to 5.

Option A For many web infrastructures,designing a peer-to-peer style architecture on top of a master/slave architecture makes sense. This is done by allowing the slave data- bases to accept updates,whicharen’tapplied directly in the slave database tables. Instead, the changes are stored in special tables for replication,which are sent back to the master and applied there first. If a conflict arises,this is known immediately and is communi- cated back to the slave,so it can communicate the information to the user. If no conflict exists at the master,the change is made to the master records,and then the master pushes the changes out to all slaves. This allows a peer-to-peer style architecture to help avoid problems in case the master fails and a new master must be elected,while controlling the conflict resolution in a central site. The drawback,of course,is extra latency involved for write transactions that require conflict validation. The bonus of this architecture is no ex- tra latency exists for read transactions (obviously) or for write transactions that don’t pose a conflict potential. Every transaction that requires conflict validation is run through a consistent process,so the outcome is repeatable and consistent. No two clients ever receive false success status.2

Option B They could consider getting high-speed links (ATM,and so forth) between the database servers,hopefully,to overcome the replication limitations. Again,high-speed doesn’t guarantee no conflicts will occur,but it makes conflicts much less likely than if they were traveling over the Internet. This option isveryexpensive,however,and can only be considered for those customers with plenty of cash to burn.

Option C If question 1a was answered as “increase performance,” the customer should consider simply buying faster hardware,building a cluster in one location,or looking at ways to optimize their database schema and programming. They should also consider factors such as reducing the number of database transactions (especially write transac- tions) done on the database per client visit. Write transactions have a much greater im- pact on performance than do read transactions.

Option D If question 1a was answered as “increase availability” or “both,” the cus- tomer needs to do a failure analysis and determine the likelihood of database failure and the impact to their business. Having a single point of failure for a DB server isn’t necessar- ily the end of the world,if many other conditions are met. For example,if they have spare systems and components,24/7 monitoring and management,and they have good static content distributed to multiple sites,they won’t have as adverse an impact if their data- base fails. For example,for many years Cisco had a single point of failure with its backend database for its online ordering. Cisco sells billions of dollars of equipment online each year,yet realized it had no realistic,cost-effective mechanism to distribute its databases completely in a peer-to-peer manner. So,Cisco distributed its web servers and application servers all over the world. And Cisco built a bulletproof NOC in San Jose to protect its database—with a huge cluster,24/7 monitoring,spare parts,great security,and so forth. If California falls into the ocean,however,Cisco online ordering will be offline. But users will still be able to access all the other features of Cisco’s web site (without real-time order information). Cisco saw this as an unfortunate, but acceptable, business risk.

SUBSCRIBER EDGE NETWORKING— NETWORKING