- April 17, 2018
- Posted by: admin
- Category: Uncategorized
Many providers spend vast capital resources on state of the art data center and fiber networks to increase robustness and uptime; however, it doesn’t obviate one likely culprit of faults, namely, natural disasters. The Tsunami causing the Fukashima disaster left many data centers and their clients crippled. Hurricane Sandy took down numerous datacenter in New York, and websites like The Huffington Post and Buzzfeed along with them. In Dublin, lighting strikes took out both Amazon and Microsoft datacenters.
And there are more unpredictable sources of datacenter failures. Yahoo claims squirrels took down one of their datacenters. Google had problems with sharks. The stories of datacenter failures go on and on. The moral of the story? Distribute your data far and wide.
As a result, we have seen a new concept emerge for databases, a geographically replicated database. A well known example is Google’s Spanner. Most of these databases utilize a new design called newSQL which combines the ACID compliance of SQL with the scalability of noSQL. They scale easily because they rely upon the flexibility of underlying newSQl architecture. Servers, along with the data stored on each, are replicated across the globe. Consequently, this allows for significantly greater fault tolerance. Even if one server or even a server farm were to suffer a catastrophic failure, the other backups in geographically disparate locations would take over without a break in continuity of service.
This model lowers query time by geographically optimizing server choice. Because there are many different servers around the world all with access to a given database, queries can be automatically routed to the server with the lowest lag time which often means the closest server. This allows for faster response time. However, while these geographically replicated databases improve on many aspects of typical database design, they run into problems of their own.