Image switch to webp, crush remaining png. Drop > 50% of image bytes.

2011-08-08-database-best-practices-for-future-scalability.html

@@ -9,7 +9,7 @@
 <li><p>Use InnoDB. You’re eventually likely to want transactions, foreign keys, row-level locking or relative crash safety. You can Google and find lots of InnoDB vs. MyISAM comparisons, but if you don’t want to dig too deeply, “just use InnoDB” is a safe place to start.</p></li>
 <li><p>Don’t store data that you don’t intend to use relationally. Using MySQL as a key/value store or to store encoded data (XML, <a href="http://code.google.com/p/protobuf/">protocol buffers</a>, etc.) in BLOB/TEXT may work, but dedicated key/value stores are likely to be more efficient.</p></li>
 <li><p>Try to design your schema with as few hierarchies as possible. For example, take the following table layout, with arrows representing many-to-one relationships:Perhaps A=”Users”, B=”DVDs Owned”, C=”Logins”, D=”Times Watched”, while E=”Administrators” and F=”Changes”. These are two hierarchies, since A and E have no links to each other. Minimizing the number of hierarchies (keeping it to just one is awesome!) makes it easier to shard later. Schemas with cross-links (say F also links to A, or a table records transfers between two different users, linking to A twice) are very difficult to shard.<br>
-<img src="data:image/png;base64,<!--# include file="images/db-hierarchy.png.base64" -->" alt="" style="background: white;"></p></li>
+<img src="data:image/webp;base64,<!--# include file="images/db-hierarchy.webp.base64" -->" alt="" style="background: white;"></p></li>
 <li><p>Use BIGINT UNSIGNED NOT NULL (64-bit required numeric) primary keys on every table. AUTO_INCREMENT is fine, at least to start. You can skip this for many-to-many link tables; just put both link columns in the primary key. Having single-column, numeric primary keys makes it easier to do things like drift checking and traversing between tables.</p></li>
 <li><p>Use BIGINT instead of INT for all keys. The cost in space (4 vs. 8 bytes) and compute time is so small that you’ll never notice it, but the cost of a schema change later to increase the field size, or an accidental wraparound, can be enormous. As you expand shards, your key space becomes sparse and grows rapidly, so wide keys are critical.</p></li>
 <li><p>Split off your data access code into an <a href="http://en.wikipedia.org/wiki/Object-relational_mapping">ORM layer</a>, even if it’s very simple to begin with. This will be where your read/write split, shard lookups and change tracking will live later.</p></li>