Guidebolt

Database

2018.04.22

Website Databases

For web development, we strongly recommend MySQL. It is the most popular relational database for websites with an excellent track record and a free version (MySQL Community Edition). MySQL CE was used to bootstrap Facebook, Twitter, and LinkedIn. Uber started with PostgreSQL yet migrated to MySQL.

For unstructured data, we recommend Apache Cassandra, a high-performance NoSQL database that should work perfectly for centralized storage of your website logs. It is used at Apple, Netflix, Reddit, and eBay.

Zero Down-time Database Schema Change

Zero down-time application and database changes must be designed and sectioned into distinct, well-ordered, backwards-compatible updates that allow for the gradual re-coloration of a server cluster.

Application Example: If an application update changes the encoding format of a stored phone number, then the database will soon contain phone numbers encoded with both the old and new format. Thus that same update must also change the decoding process to support both the old and new formats. After the first application update, the database must be manually scripted to transform all remaining old-format phone numbers into the new format. Then a second application update may be rolled out to refine the decoding process to only support the new encoding format.

Database Example: Suppose a database table must be replaced by a new table. If a new table is created then populated by data from the old table, then the new table will miss all the new data generated between the time when the old table data is copied and the time when the application is switched to read from the new table. This simple approach might work for small regional applications when done at zero traffic periods, but high-frequency international applications must use a more refined strategy (the correct way). First, create the new table then make an application update that causes new data to be written to both tables (old and new). Second, manually populate the new table with data from the old table. Third, make an application update to read data from the new table and stop writing to the old table. Fourth, remove and archive the old table. This general procedure ensures continuous, error-free operation across every step of the database change.