<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://andyatkinson.com/avoid-uuid-version-4-primary-keys"/>
	<rdf:li rdf:resource="https://github.com/wesql/wesql"/>
	<rdf:li rdf:resource="https://engineering.fb.com/2023/05/16/data-infrastructure/mysql-raft-meta/"/>
	<rdf:li rdf:resource="https://plaid.com/blog/exploring-performance-differences-between-amazon-aurora-and-vanilla-mysql/"/>
	<rdf:li rdf:resource="https://github.blog/2021-09-27-partitioning-githubs-relational-databases-scale/"/>
	<rdf:li rdf:resource="https://github.com/nocodb/nocodb"/>
	<rdf:li rdf:resource="https://www.flamingspork.com/projects/libeatmydata/"/>
	<rdf:li rdf:resource="https://github.com/ankane/strong_migrations"/>
	<rdf:li rdf:resource="https://www.dropbox.com/s/47xbjrkni9bx0g3/aurora2.pdf?dl=0"/>
	<rdf:li rdf:resource="https://aws.amazon.com/about-aws/whats-new/2018/02/amazon-aurora-parallel-query-is-available-for-preview/"/>
	<rdf:li rdf:resource="https://erikbern.com/2017/03/15/the-eigenvector-of-why-we-moved-from-language-x-to-language-y.html"/>
	<rdf:li rdf:resource="https://medium.com/making-instapaper/instapaper-outage-cause-recovery-3c32a7e9cc5f#.39bn4xjas"/>
	<rdf:li rdf:resource="https://github.com/square/shift"/>
	<rdf:li rdf:resource="https://engineering.pinterest.com/blog/evolving-mysql-compression-part-2"/>
	<rdf:li rdf:resource="https://www.percona.com/live/europe-amsterdam-2015/sites/default/files/slides/PL_AMS_Unicode_Booking169_v3.pdf"/>
	<rdf:li rdf:resource="https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/"/>
	<rdf:li rdf:resource="https://eng.uber.com/mysql-migration/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/aws/new-cross-region-read-replicas-for-amazon-aurora/"/>
	<rdf:li rdf:resource="http://stackoverflow.com/questions/303994/log-all-queries-in-mysql/20485975#20485975"/>
	<rdf:li rdf:resource="http://www.codeproject.com/Articles/33052/Visual-Representation-of-SQL-Joins"/>
	<rdf:li rdf:resource="http://prometheus.io/blog/2016/03/23/interview-with-life360/"/>
	<rdf:li rdf:resource="https://blog.engineyard.com/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you"/>
	<rdf:li rdf:resource="http://eev.ee/blog/2015/09/12/dark-corners-of-unicode/"/>
	<rdf:li rdf:resource="http://blog.mihasya.com/2015/07/19/thoughts-evoked-by-circleci-outage.html"/>
	<rdf:li rdf:resource="http://engineering.pinterest.com/post/116038532184/learn-to-stop-using-shiny-new-things-and-love"/>
	<rdf:li rdf:resource="http://highscalability.com/blog/2015/3/30/how-we-scale-vividcortexs-backend-systems.html"/>
	<rdf:li rdf:resource="https://github.com/barsoom/devbook/blob/master/deploy_without_downtime/README.md"/>
	<rdf:li rdf:resource="http://developer.olery.com/blog/goodbye-mongodb-hello-postgresql/"/>
	<rdf:li rdf:resource="https://github.com/soundcloud/lhm"/>
	<rdf:li rdf:resource="http://www.xaprb.com/blog/2014/12/08/eventual-consistency-simpler-than-mvcc/"/>
	<rdf:li rdf:resource="http://smalldatum.blogspot.ie/2014/11/aurora-for-mysql-is-coming.html?showComment=1416563079921"/>
	<rdf:li rdf:resource="http://smalldatum.blogspot.ie/2014/11/aurora-for-mysql-is-coming.html?showComment=1416603086179"/>
	<rdf:li rdf:resource="https://code.facebook.com/posts/1499322996995183/solving-the-mystery-of-link-imbalance-a-metastable-failure-state-at-scale/"/>
	<rdf:li rdf:resource="http://www.brunton-spall.co.uk/post/2014/05/06/database-migrations-done-right/"/>
	<rdf:li rdf:resource="http://aws.amazon.com/solutions/case-studies/hailo/"/>
	<rdf:li rdf:resource="https://tech.dropbox.com/2014/01/outage-post-mortem/"/>
	<rdf:li rdf:resource="https://www.facebook.com/notes/facebook-engineering/linkbench-a-database-benchmark-for-the-social-graph/10151391496443920"/>
	<rdf:li rdf:resource="http://www.theregister.co.uk/2013/09/12/google_mariadb_mysql_migration/"/>
	<rdf:li rdf:resource="http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html"/>
	<rdf:li rdf:resource="https://engineering.groupon.com/2013/mysql/mysql-buffer-pool-warming/"/>
	<rdf:li rdf:resource="http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html"/>
	<rdf:li rdf:resource="http://www.percona.com/doc/percona-playback/plugins/tcpdump/index.html"/>
	<rdf:li rdf:resource="http://codeascraft.etsy.com/2013/03/19/the-perils-of-sql_mode/"/>
	<rdf:li rdf:resource="http://www.solowizard.com/"/>
	<rdf:li rdf:resource="https://www.facebook.com/notes/mysql-at-facebook/online-schema-change-for-mysql/430801045932"/>
	<rdf:li rdf:resource="http://codeascraft.etsy.com/2012/04/20/two-sides-for-salvation/"/>
	<rdf:li rdf:resource="http://saucelabs.com/blog/index.php/2012/05/goodbye-couchdb/"/>
	<rdf:li rdf:resource="http://www.gamasutra.com/view/news/168799/Scale_Something_How_Draw_Something_rode_its_rocket_ship_of_growth.php"/>
	<rdf:li rdf:resource="http://highscalability.com/blog/2011/12/19/how-twitter-stores-250-million-tweets-a-day-using-mysql.html"/>
	<rdf:li rdf:resource="http://highscalability.com/bunch-great-strategies-using-memcached-and-mysql-better-together"/>
	<rdf:li rdf:resource="http://www.philwhln.com/quoras-technology-examined?ref=reddit"/>
	<rdf:li rdf:resource="http://www.maatkit.org/doc/synopsis"/>
	<rdf:li rdf:resource="http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/"/>
	<rdf:li rdf:resource="http://www.blue74.com/?p=25"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://andyatkinson.com/avoid-uuid-version-4-primary-keys">
    <title>Avoid UUID Version 4 Primary Keys | Software Engineer, Author, High Performance PostgreSQL for Rails</title>
    <dc:date>2025-12-15T11:59:46+00:00</dc:date>
    <link>https://andyatkinson.com/avoid-uuid-version-4-primary-keys</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A well-researched article suggesting that random UUIDs do not make a good primary key for database tables; I would tend to agree (for cases where performance is important).

<blockquote>
- UUID v4s increase latency for lookups, as they can’t take advantage of fast ordered lookups in B-Tree indexes
- For new databases, don’t use gen_random_uuid() for primary key types, which generates random UUID v4 values
- UUIDs consume twice the space of bigint
- UUID v4 values are not meant to be secure per the UUID RFC
- UUID v4s are random. For good performance, the whole index must be in buffer cache for index scans, which is increasingly unlikely for bigger data.
- UUID v4s cause more page splits, which increase IO for writes with increased fragmentation, and increased size of WAL logs
- For non-guessable, obfuscated pseudo-random codes, we can generate those from integers, which could be an alternative to using UUIDs
- If you must use UUIDs, use time-orderable UUIDs like UUID v7</blockquote>

]]></description>
<dc:subject>postgres rails databases sql mysql uuids indexing primary-keys keys lookup storage random</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c1aa91942c42/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postgres"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uuids"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:indexing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:primary-keys"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:keys"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lookup"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:random"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/wesql/wesql">
    <title>WeSQL</title>
    <dc:date>2024-11-26T12:22:48+00:00</dc:date>
    <link>https://github.com/wesql/wesql</link>
    <dc:creator>jm</dc:creator><description><![CDATA["an innovative MySQL distribution that adopts a compute-storage separation architecture, with storage backed by S3 (and S3-compatible systems).

WeSQL has completely replaced MySQL’s traditional disk storage with S3. All MySQL data—binlogs, schemas, storage engine metadata, WAL, and data files—are entirely (not partially!) stored as objects in S3. The 11 nines of durability provided by S3 significantly enhances data reliability. Additionally, WeSQL can start from a clean, empty instance, connect to S3, load the data, and begin serving immediately with no additional setup required.

It is ideal for users who need an easy-to-manage, cost-effective, and developer-friendly MySQL database solution, especially for those needing support for both Serverless and BYOC (Bring Your Own Cloud)."

(via Ian on ITC)]]></description>
<dc:subject>mysql s3 object-storage storage databases sql</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b01e04d0ad70/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:s3"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:object-storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://engineering.fb.com/2023/05/16/data-infrastructure/mysql-raft-meta/">
    <title>MySQL Raft at Meta</title>
    <dc:date>2023-05-17T09:04:10+00:00</dc:date>
    <link>https://engineering.fb.com/2023/05/16/data-infrastructure/mysql-raft-meta/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Sounds like a massive improvement in operational management of MySQL fleets.  Here's hoping AWS might steal a few ideas for RDS]]></description>
<dc:subject>mysql ops replicas replication raft distributed-systems meta</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bc755bcb61b1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replicas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:raft"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed-systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:meta"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://plaid.com/blog/exploring-performance-differences-between-amazon-aurora-and-vanilla-mysql/">
    <title>Exploring performance differences between Amazon Aurora and vanilla MySQL | Plaid</title>
    <dc:date>2023-04-12T08:28:02+00:00</dc:date>
    <link>https://plaid.com/blog/exploring-performance-differences-between-amazon-aurora-and-vanilla-mysql/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a major difference between vanilla MySQL and Amazon Aurora (and a potentially major risk!):

<blockquote>because Aurora MySQL primary and replica instances share a storage layer, they share a set of undo logs. This means that, for a REPEATABLE READ isolation level, the storage instance must maintain undo logs at least as far back as could be required to satisfy transactional guarantees for the primary or any read replica instance. Long-running replica transactions can negatively impact writer performance in Aurora MySQL—finally, an explanation for the incident that spawned this investigation.

The same scenario plays out differently in vanilla MySQL because of its different model for undo logs.

Vanilla MYSQL: there are two undo logs – one on the writer, and one on the reader. The performance impact of an operation that prevents the garbage collection of undo log records will be isolated to either the writer or the reader.

Aurora MySQL: there is a single undo log that is shared between the writer and reader. The performance impact of an operation that prevents the garbage collection of undo log records will affect the entire cluster.
</blockquote>

]]></description>
<dc:subject>aurora aws mysql performance databases isolation-levels</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:06b1342ee8c4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aurora"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:isolation-levels"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.blog/2021-09-27-partitioning-githubs-relational-databases-scale/">
    <title>Partitioning GitHub’s relational databases to handle scale</title>
    <dc:date>2021-09-29T09:09:08+00:00</dc:date>
    <link>https://github.blog/2021-09-27-partitioning-githubs-relational-databases-scale/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[wow this is complex. Vitess playing a key part]]></description>
<dc:subject>github mysql architecture database</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8c92e3000937/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:github"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/nocodb/nocodb">
    <title>nocodb</title>
    <dc:date>2021-05-28T08:57:02+00:00</dc:date>
    <link>https://github.com/nocodb/nocodb</link>
    <dc:creator>jm</dc:creator><description><![CDATA['The Open Source Airtable alternative' -- looks nifty as a quick and easy way to hook up an SQL database to a web-based spreadsheet view]]></description>
<dc:subject>airtable database sql mysql nocodb spreadsheets ui web</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:61352fd4e436/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:airtable"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nocodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spreadsheets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ui"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:web"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.flamingspork.com/projects/libeatmydata/">
    <title>libeatmydata</title>
    <dc:date>2019-10-10T15:55:49+00:00</dc:date>
    <link>https://www.flamingspork.com/projects/libeatmydata/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['a small LD_PRELOAD library designed to (transparently) disable fsync (and friends, like open(O_SYNC)). This has two side-effects: making software that writes data safely to disk a lot quicker and making this software no longer crash safe.'

Good for tests....]]></description>
<dc:subject>fsync linux performance mysql testing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a876035ccbb5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fsync"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/ankane/strong_migrations">
    <title>ankane/strong_migrations: Catch unsafe Rails migrations at dev time</title>
    <dc:date>2019-04-08T09:39:48+00:00</dc:date>
    <link>https://github.com/ankane/strong_migrations</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
Strong Migrations detects potentially dangerous operations in [Rails database] migrations, prevents them from running by default, and provides instructions on safer ways to do what you want.</blockquote>

]]></description>
<dc:subject>database migrations rails releases ops databases mysql ruby gems</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:11703c588753/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:migrations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:releases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gems"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.dropbox.com/s/47xbjrkni9bx0g3/aurora2.pdf?dl=0">
    <title>_Amazon Aurora: On Avoiding Distributed Consensus for I/Os, Commits, and Membership Changes_, SIGMOD '18</title>
    <dc:date>2019-01-16T10:08:18+00:00</dc:date>
    <link>https://www.dropbox.com/s/47xbjrkni9bx0g3/aurora2.pdf?dl=0</link>
    <dc:creator>jm</dc:creator><description><![CDATA[

<blockquote>One of the more novel differences between Aurora and other relational databases is how it pushes redo processing to a multi-tenant scale-out storage service, purpose-built for Aurora. Doing so reduces networking traffic, avoids checkpoints and crash recovery, enables failovers to replicas without loss of data, and enables fault-tolerant storage that heals without database involvement. Traditional implementations that leverage distributed storage would use distributed consensus algorithms for commits, reads, replication, and membership changes and amplify cost of underlying storage. In this paper, we describe how Aurora avoids distributed consensus under most circumstances by establishing invariants and leveraging local transient state. Doing so improves performance, reduces variability, and lowers costs.</blockquote>

]]></description>
<dc:subject>papers toread aurora amazon aws pdf scalability distcomp state sql mysql postgresql distributed-consensus</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:db64811fffaf/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:papers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:toread"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aurora"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pdf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:state"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postgresql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distributed-consensus"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/about-aws/whats-new/2018/02/amazon-aurora-parallel-query-is-available-for-preview/">
    <title>Amazon Aurora Parallel Query is Available for Preview</title>
    <dc:date>2018-02-02T10:39:00+00:00</dc:date>
    <link>https://aws.amazon.com/about-aws/whats-new/2018/02/amazon-aurora-parallel-query-is-available-for-preview/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Looks very nifty (at least once it's GA)

<blockquote>Parallel Query improves the performance of large analytic queries by pushing processing down to the Aurora storage layer, spreading processing across hundreds of nodes.
With Parallel Query, you can run sophisticated analytic queries on Aurora tables with an order of magnitude performance improvement over serial query processing, in many cases. Parallel Query currently pushes down predicates used to filter tables and hash joins. </blockquote>

]]></description>
<dc:subject>parallel aurora amazon mysql sql performance joins architecture data-model</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:035caa846548/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:parallel"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aurora"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amazon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:joins"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-model"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://erikbern.com/2017/03/15/the-eigenvector-of-why-we-moved-from-language-x-to-language-y.html">
    <title>The eigenvector of &quot;Why we moved from language X to language Y&quot;</title>
    <dc:date>2017-03-16T23:18:20+00:00</dc:date>
    <link>https://erikbern.com/2017/03/15/the-eigenvector-of-why-we-moved-from-language-x-to-language-y.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[this is actually quite interesting data]]></description>
<dc:subject>statistics programming languages golang go mysql coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bc481ec8d1b8/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:programming"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:languages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:golang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://medium.com/making-instapaper/instapaper-outage-cause-recovery-3c32a7e9cc5f#.39bn4xjas">
    <title>Instapaper Outage Cause &amp; Recovery</title>
    <dc:date>2017-02-14T10:42:03+00:00</dc:date>
    <link>https://medium.com/making-instapaper/instapaper-outage-cause-recovery-3c32a7e9cc5f#.39bn4xjas</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Hard to see this as anything other than a pretty awful documentation fail by the AWS RDS service:

<blockquote>Without knowledge of the pre-April 2014 file size limit, it was difficult to foresee and prevent this issue. As far as we can tell, there’s no information in the RDS console in the form of monitoring, alerts or logging that would have let us know we were approaching the 2TB file size limit, or that we were subject to it in the first place. Even now, there’s nothing to indicate that our hosted database has a critical issue.</blockquote>

]]></description>
<dc:subject>limits aws rds databases mysql filesystems ops instapaper risks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:70ad5bf26582/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:limits"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:filesystems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:instapaper"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:risks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/square/shift">
    <title>square/shift</title>
    <dc:date>2017-02-03T11:00:23+00:00</dc:date>
    <link>https://github.com/square/shift</link>
    <dc:creator>jm</dc:creator><description><![CDATA['shift is a [web] application that helps you run schema migrations on MySQL databases']]></description>
<dc:subject>databases mysql sql migrations ops square ddl percona</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fe923a6ce9c1/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:migrations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:square"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ddl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percona"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://engineering.pinterest.com/blog/evolving-mysql-compression-part-2">
    <title>Evolving MySQL Compression - Part 2 | Pinterest Engineering</title>
    <dc:date>2017-01-30T17:59:25+00:00</dc:date>
    <link>https://engineering.pinterest.com/blog/evolving-mysql-compression-part-2</link>
    <dc:creator>jm</dc:creator><description><![CDATA[generating a near-optimal external dictionary for Zlib deflate compression]]></description>
<dc:subject>compression deflate zlib pinterest hacks mysql</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8d4780ed5c89/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compression"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deflate"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:zlib"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pinterest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.percona.com/live/europe-amsterdam-2015/sites/default/files/slides/PL_AMS_Unicode_Booking169_v3.pdf">
    <title>Booking.com, MySQL and UTF-8</title>
    <dc:date>2016-12-12T11:21:30+00:00</dc:date>
    <link>https://www.percona.com/live/europe-amsterdam-2015/sites/default/files/slides/PL_AMS_Unicode_Booking169_v3.pdf</link>
    <dc:creator>jm</dc:creator><description><![CDATA[good preso from Percona Live 2015 on the messiness of MySQL vs UTF-8 and utf8mb4]]></description>
<dc:subject>utf-8 utf8mb4 mysql storage databases slides booking.com character-sets</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:12c8fe17e0d5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:utf-8"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:utf8mb4"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:slides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:booking.com"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:character-sets"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/">
    <title>Measuring Docker IO overhead - Percona Database Performance Blog</title>
    <dc:date>2016-11-01T11:59:27+00:00</dc:date>
    <link>https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[See also https://www.percona.com/blog/2016/02/05/measuring-docker-cpu-network-overhead/ for the CPU/Network equivalent.  The good news is that nowadays it's virtually 0 when the correct settings are used]]></description>
<dc:subject>docker percona overhead mysql deployment performance ops containers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c324d2498cee/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percona"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:overhead"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://eng.uber.com/mysql-migration/">
    <title>Why Uber Engineering Switched from Postgres to MySQL</title>
    <dc:date>2016-07-27T09:47:20+00:00</dc:date>
    <link>https://eng.uber.com/mysql-migration/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Uber bringing the smackdown for the HN postgres fanclub, with some juicy technical details of issues that caused them pain.  FWIW, I was bitten by crappy postgres behaviour in the past (specifically around vacuuming and pgbouncer), so I've long been a MySQL fan ;)]]></description>
<dc:subject>database mysql postgres postgresql uber architecture storage sql</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bb13fe501b54/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postgres"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postgresql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uber"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/aws/new-cross-region-read-replicas-for-amazon-aurora/">
    <title>Cross-Region Read Replicas for Amazon Aurora</title>
    <dc:date>2016-06-14T09:19:08+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/aws/new-cross-region-read-replicas-for-amazon-aurora/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Creating a read replica in another region also creates an Aurora cluster in the region. This cluster can contain up to 15 more read replicas, with very low replication lag (typically less than 20 ms) within the region (between regions, latency will vary based on the distance between the source and target). You can use this model to duplicate your cluster and read replica setup across regions for disaster recovery. In the event of a regional disruption, you can promote the cross-region replica to be the master. This will allow you to minimize downtime for your cross-region application. This feature applies to unencrypted Aurora clusters.</blockquote>

]]></description>
<dc:subject>aws mysql databases storage replication cross-region failover reliability aurora</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4bc9688d386b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cross-region"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:failover"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aurora"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://stackoverflow.com/questions/303994/log-all-queries-in-mysql/20485975#20485975">
    <title>Easy way to log all queries in mysql without restart</title>
    <dc:date>2016-04-13T10:49:47+00:00</dc:date>
    <link>http://stackoverflow.com/questions/303994/log-all-queries-in-mysql/20485975#20485975</link>
    <dc:creator>jm</dc:creator><description><![CDATA[thanks StackOverflow!]]></description>
<dc:subject>stackoverflow mysql rds logging ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a80b2ac6db7f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stackoverflow"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.codeproject.com/Articles/33052/Visual-Representation-of-SQL-Joins">
    <title>Visual Representation of SQL Joins</title>
    <dc:date>2016-03-25T15:48:55+00:00</dc:date>
    <link>http://www.codeproject.com/Articles/33052/Visual-Representation-of-SQL-Joins</link>
    <dc:creator>jm</dc:creator><description><![CDATA[useful bookmark to have (via Nelson)
]]></description>
<dc:subject>sql joins mysql reference database</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:da83d142d2e3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:joins"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reference"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://prometheus.io/blog/2016/03/23/interview-with-life360/">
    <title>Life360 testimonial for Prometheus</title>
    <dc:date>2016-03-24T13:21:13+00:00</dc:date>
    <link>http://prometheus.io/blog/2016/03/23/interview-with-life360/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Now this is a BIG thumbs up: <blockquote>'Prometheus has been known to us for a while, and we have been tracking it and reading about the active development, and at a point (a few months back) we decided to start evaluating it for production use.  The PoC results were incredible. The monitoring coverage of MySQL was amazing, and we also loved the JMX monitoring for Cassandra, which had been sorely lacking in the past.'</blockquote>

]]></description>
<dc:subject>metrics monitoring time-series prometheus testimonials life360 cassandra jmx mysql</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c4405c9925a7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:monitoring"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-series"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:prometheus"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testimonials"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:life360"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jmx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.engineyard.com/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you">
    <title>5 subtle ways you're using MySQL as a queue, and why it'll bite you</title>
    <dc:date>2016-01-06T12:42:41+00:00</dc:date>
    <link>https://blog.engineyard.com/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent post from Percona. I particularly like that they don't just say "don't use MySQL" -- they give good advice on how it can be made work: 1) avoid polling; 2) avoid locking; and 3) avoid storing your queue in the same table as other data.]]></description>
<dc:subject>database mysql queueing queue messaging percona rds locking sql architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5081114f1b88/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queue"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:messaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percona"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:locking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://eev.ee/blog/2015/09/12/dark-corners-of-unicode/">
    <title>Dark corners of Unicode</title>
    <dc:date>2015-09-14T06:02:17+00:00</dc:date>
    <link>http://eev.ee/blog/2015/09/12/dark-corners-of-unicode/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>I’m assuming, if you are on the Internet and reading kind of a nerdy blog, that you know what Unicode is. At the very least, you have a very general understanding of it — maybe “it’s what gives us emoji”.

That’s about as far as most people’s understanding extends, in my experience, even among programmers. And that’s a tragedy, because Unicode has a lot of… ah, depth to it. Not to say that Unicode is a terrible disaster — more that human language is a terrible disaster, and anything with the lofty goals of representing all of it is going to have some wrinkles.

So here is a collection of curiosities I’ve encountered in dealing with Unicode that you generally only find out about through experience. Enjoy.</blockquote>

]]></description>
<dc:subject>unicode characters encoding emoji utf-8 utf-16 utf mysql text</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f032051210c0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unicode"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:characters"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:encoding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emoji"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:utf-8"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:utf-16"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:utf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:text"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.mihasya.com/2015/07/19/thoughts-evoked-by-circleci-outage.html">
    <title>Mikhail Panchenko's thoughts on the July 2015 CircleCI outage</title>
    <dc:date>2015-07-21T10:20:42+00:00</dc:date>
    <link>http://blog.mihasya.com/2015/07/19/thoughts-evoked-by-circleci-outage.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[an excellent followup operational post on CircleCI's "database is not a queue" outage]]></description>
<dc:subject>database-is-not-a-queue mysql sql databases ops outages postmortems</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:689da69282e3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database-is-not-a-queue"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outages"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postmortems"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://engineering.pinterest.com/post/116038532184/learn-to-stop-using-shiny-new-things-and-love">
    <title>Making Pinterest — Learn to stop using shiny new things and love MySQL</title>
    <dc:date>2015-04-16T15:19:35+00:00</dc:date>
    <link>http://engineering.pinterest.com/post/116038532184/learn-to-stop-using-shiny-new-things-and-love</link>
    <dc:creator>jm</dc:creator><description><![CDATA['The third reason people go for shiny is because older tech isn’t advertised as aggressively as newer tech. The younger companies needs to differentiate from the old guard and be bolder, more passionate and promise to fulfill your wildest dreams. But most new tech sales pitches aren’t generally forthright about their many failure modes. In our early days, we fell into this third trap. We had a lot of growing pains as we scaled the architecture. The most vocal and excited database companies kept coming to us saying they’d solve all of our scalability problems. But nobody told us of the virtues of MySQL, probably because MySQL just works, and people know about it.'

It's true! -- I'm still a happy MySQL user for some use cases, particularly read-mostly relational configuration data...]]></description>
<dc:subject>mysql storage databases reliability pinterest architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ee79bcd2c695/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pinterest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://highscalability.com/blog/2015/3/30/how-we-scale-vividcortexs-backend-systems.html">
    <title>How We Scale VividCortex's Backend Systems - High Scalability</title>
    <dc:date>2015-03-30T16:55:14+00:00</dc:date>
    <link>http://highscalability.com/blog/2015/3/30/how-we-scale-vividcortexs-backend-systems.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent post from Baron Schwartz about their large-scale, 1-second-granularity time series database storage system]]></description>
<dc:subject>time-series tsd storage mysql sql baron-schwartz ops performance scalability scaling go</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fe014fc1ee1b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:time-series"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tsd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:baron-schwartz"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/barsoom/devbook/blob/master/deploy_without_downtime/README.md">
    <title>devbook/README.md at master · barsoom/devbook</title>
    <dc:date>2015-03-25T15:17:01+00:00</dc:date>
    <link>https://github.com/barsoom/devbook/blob/master/deploy_without_downtime/README.md</link>
    <dc:creator>jm</dc:creator><description><![CDATA[How to avoid the shitty behaviour of ActiveRecord wrt migration safety, particularly around removing/renaming columns.  ugh, ActiveRecord]]></description>
<dc:subject>activerecord fail rails mysql sql migrations databases schemas releasing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:be719470c073/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:activerecord"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:migrations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:schemas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:releasing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://developer.olery.com/blog/goodbye-mongodb-hello-postgresql/">
    <title>Goodbye MongoDB, Hello PostgreSQL</title>
    <dc:date>2015-03-11T10:15:28+00:00</dc:date>
    <link>http://developer.olery.com/blog/goodbye-mongodb-hello-postgresql/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Another core problem we’ve faced is one of the fundamental features of MongoDB (or any other schemaless storage engine): the lack of a schema. The lack of a schema may sound interesting, and in some cases it can certainly have its benefits. However, for many the usage of a schemaless storage engine leads to the problem of implicit schemas. These schemas aren’t defined by your storage engine but instead are defined based on application behaviour and expectations.</blockquote>

Well, don't say we didn't warn you ;)]]></description>
<dc:subject>mongodb mysql postgresql databases storage schemas war-stories</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:da312f02b590/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mongodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postgresql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:schemas"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:war-stories"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/soundcloud/lhm">
    <title>soundcloud/lhm</title>
    <dc:date>2015-03-09T23:08:39+00:00</dc:date>
    <link>https://github.com/soundcloud/lhm</link>
    <dc:creator>jm</dc:creator><description><![CDATA[The Large Hadron Migrator is a tool to perform live database migrations in a Rails app without locking.

<blockquote>
The basic idea is to perform the migration online while the system is live, without locking the table. In contrast to OAK and the facebook tool, we only use a copy table and triggers.  The Large Hadron is a test driven Ruby solution which can easily be dropped into an ActiveRecord or DataMapper migration. It presumes a single auto incremented numerical primary key called id as per the Rails convention. Unlike the twitter solution, it does not require the presence of an indexed updated_at column.</blockquote>

]]></description>
<dc:subject>migrations database sql ops mysql rails ruby lhm soundcloud activerecord</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7319dc67d62e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:migrations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rails"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lhm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:soundcloud"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:activerecord"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.xaprb.com/blog/2014/12/08/eventual-consistency-simpler-than-mvcc/">
    <title>If Eventual Consistency Seems Hard, Wait Till You Try MVCC</title>
    <dc:date>2014-12-09T16:42:44+00:00</dc:date>
    <link>http://www.xaprb.com/blog/2014/12/08/eventual-consistency-simpler-than-mvcc/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[ex-Percona MySQL wizard Baron Schwartz, noting that MVCC as implemented in common SQL databases is not all that simple or reliable compared to big bad NoSQL Eventual Consistency:
 
<blockquote>Since I am not ready to assert that there’s a distributed system I know to be better and simpler than eventually consistent datastores, and since I certainly know that InnoDB’s MVCC implementation is full of complexities, for right now I am probably in the same position most of my readers are: the two viable choices seem to be single-node MVCC and multi-node eventual consistency. And I don’t think MVCC is the simpler paradigm of the two.</blockquote>

]]></description>
<dc:subject>nosql concurrency databases mysql riak voldemort eventual-consistency reliability storage baron-schwartz mvcc innodb postgresql</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0dddeb567400/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:riak"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:voldemort"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eventual-consistency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:baron-schwartz"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mvcc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:innodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postgresql"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://smalldatum.blogspot.ie/2014/11/aurora-for-mysql-is-coming.html?showComment=1416563079921">
    <title>Aurora for MySQL is coming</title>
    <dc:date>2014-12-09T16:40:38+00:00</dc:date>
    <link>http://smalldatum.blogspot.ie/2014/11/aurora-for-mysql-is-coming.html?showComment=1416563079921</link>
    <dc:creator>jm</dc:creator><description><![CDATA[some good details of Aurora innards]]></description>
<dc:subject>mysql databases aurora aws ec2 sql storage transactions replication</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b6f304df35af/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aurora"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:transactions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://smalldatum.blogspot.ie/2014/11/aurora-for-mysql-is-coming.html?showComment=1416603086179">
    <title>Aurora for MySQL is coming</title>
    <dc:date>2014-12-05T22:53:40+00:00</dc:date>
    <link>http://smalldatum.blogspot.ie/2014/11/aurora-for-mysql-is-coming.html?showComment=1416603086179</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Anurag@AWS posts a quite interesting comment on Aurora failover: We asynchronously write to 6 copies and ack the write when we see four completions. So, traditional 4/6 quorums with synchrony as you surmised. Now, each log record can end up with a independent quorum from any other log record, which helps with jitter, but introduces some sophistication in recovery protocols. We peer to peer to fill in holes. We also will repair bad segments in the background, and downgrade to a 3/4 quorum if unable to place in an AZ for any extended period. You need a pretty bad failure to get a write outage.' (via High Scalability)]]></description>
<dc:subject>via:highscalability mysql aurora failover fault-tolerance aws replication quorum</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ae310d17fac7/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:highscalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aurora"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:failover"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-tolerance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quorum"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://code.facebook.com/posts/1499322996995183/solving-the-mystery-of-link-imbalance-a-metastable-failure-state-at-scale/">
    <title>Solving the Mystery of Link Imbalance: A Metastable Failure State at Scale | Engineering Blog | Facebook Code</title>
    <dc:date>2014-11-28T16:47:33+00:00</dc:date>
    <link>https://code.facebook.com/posts/1499322996995183/solving-the-mystery-of-link-imbalance-a-metastable-failure-state-at-scale/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent real-world war story from Facebook -- a long-running mystery bug was eventually revealed to be a combination of edge-case behaviours across all the layers of the networking stack, from L2 link aggregation at the agg-router level, up to the L7 behaviour of the MySQL client connection pool.

<blockquote>Facebook collocates many of a user’s nodes and edges in the social graph. That means that when somebody logs in after a while and their data isn’t in the cache, we might suddenly perform 50 or 100 database queries to a single database to load their data. This starts a race among those queries. The queries that go over a congested link will lose the race reliably, even if only by a few milliseconds. That loss makes them the most recently used when they are put back in the pool. The effect is that during a query burst we stack the deck against ourselves, putting all of the congested connections at the top of the deck.</blockquote>

]]></description>
<dc:subject>architecture debugging devops facebook layer-7 mysql connection-pooling aggregation networking tcp-stack</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c71d54137cff/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:devops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:layer-7"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:connection-pooling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aggregation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcp-stack"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.brunton-spall.co.uk/post/2014/05/06/database-migrations-done-right/">
    <title>Database Migrations Done Right</title>
    <dc:date>2014-05-08T16:53:32+00:00</dc:date>
    <link>http://www.brunton-spall.co.uk/post/2014/05/06/database-migrations-done-right/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The rule is simple. You should never tie database migrations to application deploys or vice versa. By minimising dependencies you enable faster, easier and cleaner deployments.</blockquote>

A solid description of why this is a good idea, from an ex-Guardian dev.]]></description>
<dc:subject>migrations database sql mysql postgres deployment ops dependencies loose-coupling</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2e8db5bfa149/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:migrations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postgres"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dependencies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:loose-coupling"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://aws.amazon.com/solutions/case-studies/hailo/">
    <title>AWS Case Study: Hailo</title>
    <dc:date>2014-04-28T11:35:23+00:00</dc:date>
    <link>http://aws.amazon.com/solutions/case-studies/hailo/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Ubuntu, C*, HAProxy, MySQL, RDS, multiple AWS regions.]]></description>
<dc:subject>hailo cassandra ubuntu mysql rds aws ec2 haproxy architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:210362e2cd0c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hailo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cassandra"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ubuntu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ec2"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:haproxy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://tech.dropbox.com/2014/01/outage-post-mortem/">
    <title>DropBox outage post-mortem</title>
    <dc:date>2014-01-13T15:52:02+00:00</dc:date>
    <link>https://tech.dropbox.com/2014/01/outage-post-mortem/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A bug in a scheduled OS upgrade script caused live production DB servers to be upgraded while live.  Fixes include fixing that script by verifying non-liveness on the host itself, and a faster parallel MySQL binary-log recovery command.]]></description>
<dc:subject>dropbox outage postmortems upgrades mysql</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:33ceb4b91aab/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dropbox"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:outage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:postmortems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:upgrades"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.facebook.com/notes/facebook-engineering/linkbench-a-database-benchmark-for-the-social-graph/10151391496443920">
    <title>LinkBench: A database benchmark for the social graph</title>
    <dc:date>2013-10-10T14:22:13+00:00</dc:date>
    <link>https://www.facebook.com/notes/facebook-engineering/linkbench-a-database-benchmark-for-the-social-graph/10151391496443920</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>However, the gold standard for database benchmarking is to test the performance of a system on the real production workload, since synthetic benchmarks often don't exercise systems in the same way. When making decisions about a significant component of Facebook's infrastructure, we need to understand how a database system will really perform in Facebook's production workload.  [....] LinkBench addresses these needs by replicating the data model, graph structure, and request mix of our MySQL social graph workload.
</blockquote>

Mentioned in a presentation from Peter Bailis, http://www.hpts.ws/papers/2013/bailis-hpts-2013.pdf]]></description>
<dc:subject>graph databases mysql facebook performance testing benchmarks workloads</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2f062c07a82a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:graph"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:workloads"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.theregister.co.uk/2013/09/12/google_mariadb_mysql_migration/">
    <title>Google swaps out MySQL, moves to MariaDB</title>
    <dc:date>2013-09-14T21:31:31+00:00</dc:date>
    <link>http://www.theregister.co.uk/2013/09/12/google_mariadb_mysql_migration/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>When we asked Sallner to quantify the scale of the migration he said, "They're moving it all. Everything they have. All of the MySQL servers are moving to MariaDB, as far as I understand."

By moving to MariaDB, Google can free itself of any dependence on technology dictated by Oracle – a company whose motivations are unclear, and whose track record for working with the wider technology community is dicey, to say the least. Oracle has controlled MySQL since its acquisition of Sun in 2010, and the key InnoDB storage engine since it got ahold of Innobase in 2005.

[...] We asked Cole why Google would shift from MySQL to MariaDB, and what the key technical differences between the systems were. "From my perspective, they're more or less equivalent other than if you look at specific features and how they implement them," Cole said, speaking in a personal capacity and not on behalf of Google. "Ideologically there are lots of differences."</blockquote>

So -- AWS, when will RDS offer MariaDB as an option?]]></description>
<dc:subject>google mysql mariadb sql open-source licensing databases storage innodb oracle</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d069159fa948/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mariadb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:licensing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:innodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oracle"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html">
    <title>The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS, a 22 MB/S Firehose, and Send Tweets in Under 5 Seconds</title>
    <dc:date>2013-07-09T09:01:05+00:00</dc:date>
    <link>http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good read.

<blockquote>Twitter is primarily a consumption mechanism, not a production mechanism. 300K QPS are spent reading timelines and only 6000 requests per second are spent on writes.</blockquote>

* their approach of precomputing the timeline for the non-search case is a good example of optimizing for the more frequently-exercised path.

* MySQL and Redis are the underlying stores.  Redis is acting as a front-line in-RAM cache.  they're pretty happy with it: https://news.ycombinator.com/item?id=6011254

* these further talks go into more detail, apparently (haven't watched them yet):

http://www.infoq.com/presentations/Real-Time-Delivery-Twitter
http://www.infoq.com/presentations/Twitter-Timeline-Scalability
http://www.infoq.com/presentations/Timelines-Twitter

* funny thread of comments on HN, from a big-iron fan: https://news.ycombinator.com/item?id=6008228]]></description>
<dc:subject>scale architecture scalability twitter high-scalability redis mysql</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5bddc42e545c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scale"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:high-scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://engineering.groupon.com/2013/mysql/mysql-buffer-pool-warming/">
    <title>Is Your MySQL Buffer Pool Warm? Make It Sweat!</title>
    <dc:date>2013-04-16T21:28:43+00:00</dc:date>
    <link>https://engineering.groupon.com/2013/mysql/mysql-buffer-pool-warming/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[How GroupOn are warming up a failover warm MySQL spare, using Percona stuff and a "tee" of the live in-flight queries. (via Dave Doran)]]></description>
<dc:subject>via:dave-doran mysql databases warm-spares spares failover groupon percona replication</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6c770a73f651/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:dave-doran"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:warm-spares"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spares"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:failover"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:groupon"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percona"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html">
    <title>High Scalability - Scaling Pinterest - From 0 to 10s of Billions of Page Views a Month in Two Years</title>
    <dc:date>2013-04-15T21:17:02+00:00</dc:date>
    <link>http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[wow, Pinterest have a pretty hardcore architecture.  Sharding to the max.  This is scary stuff for me:

<blockquote>a [Cassandra-style] Cluster Management Algorithm is a SPOF. If there’s a bug it impacts every node. This took them down 4 times.</blockquote>

yeah, so, eek ;)]]></description>
<dc:subject>clustering sharding architecture aws scalability scaling pinterest via:matt-sergeant redis mysql memcached</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:94eb7274d2de/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clustering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sharding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pinterest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:matt-sergeant"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:redis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memcached"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.percona.com/doc/percona-playback/plugins/tcpdump/index.html">
    <title>Percona Playback's tcpdump plugin</title>
    <dc:date>2013-03-20T13:23:38+00:00</dc:date>
    <link>http://www.percona.com/doc/percona-playback/plugins/tcpdump/index.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Capture MySQL traffic via tcpdump, tee it over the network to replay against a second database.  Even supports query execution times and pauses between queries to playback the same load level]]></description>
<dc:subject>tcpdump production load-testing testing staging tee networking netcat percona replay mysql</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cf3d15109c17/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcpdump"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:production"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:load-testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:staging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tee"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:networking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netcat"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percona"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replay"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://codeascraft.etsy.com/2013/03/19/the-perils-of-sql_mode/">
    <title>Data Corruption To Go: The Perils Of sql_mode = NULL « Code as Craft</title>
    <dc:date>2013-03-19T23:04:16+00:00</dc:date>
    <link>http://codeascraft.etsy.com/2013/03/19/the-perils-of-sql_mode/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[bloody hell. A load of cases where MySQL will happily accommodate all sorts of malformed and invalid input -- thankfully with fixes.

Also includes a very nifty example of Etsy tee'ing their production db traffic (30k pps in and out) via tcpdump and pt-query-digest to a test database host.  Fantastic hackery]]></description>
<dc:subject>mysql input corrupt invalid validation coding databases sql testing tcpdump percona pt-query-digest tee</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4e37ee84990a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:input"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:corrupt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:invalid"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:validation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tcpdump"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percona"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pt-query-digest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tee"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.solowizard.com/">
    <title>SoloWizard</title>
    <dc:date>2013-03-14T14:20:51+00:00</dc:date>
    <link>http://www.solowizard.com/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['bootstrap an OSX development machine with a one-liner'.

<blockquote>Many teams use chef to manage their production machines, but developers often build their development boxes by hand. SoloWizard makes it painless to create a configurable chef solo script to get your development machine humming: mysql, sublime text, .bash_profile tweaks to OS-X settings - it's all there!</blockquote>]]></description>
<dc:subject>osx chef mac build-out ops macosx deployment developers desktops laptops mysql rabbitmq activemq nginx</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c9a860892e4c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:osx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:chef"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mac"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:build-out"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:macosx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:deployment"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:developers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:desktops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:laptops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rabbitmq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:activemq"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nginx"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.facebook.com/notes/mysql-at-facebook/online-schema-change-for-mysql/430801045932">
    <title>Online Schema Change for MySQL</title>
    <dc:date>2013-03-06T09:44:53+00:00</dc:date>
    <link>https://www.facebook.com/notes/mysql-at-facebook/online-schema-change-for-mysql/430801045932</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A tool written by Facebook to ease the pain of online MySQL schema-change migrations.

<blockquote>Some ALTER TABLE statements take too long form the perspective of some MySQL users. The fast index create feature for the InnoDB plugin in MySQL 5.1 makes this less of an issue but this can still take minutes to hours for a large table and for some MySQL deployments that is too long.
 
A workaround is to perform the change on a slave first and then promote the slave to be the new master. But this requires a slave located near the master. MySQL 5.0 added support for triggers and some replication systems have been built using triggers to capture row changes. Why not use triggers for this? The openarkkit toolkit did just that with oak-online-alter-table. We have published our version of an online schema change utility (OnlineSchemaChange.php aka OSC).</blockquote>

]]></description>
<dc:subject>facebook mysql sql schema database migrations ops alter-table</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f2bd9f37b00f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:schema"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:migrations"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alter-table"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://codeascraft.etsy.com/2012/04/20/two-sides-for-salvation/">
    <title>Two Sides For Salvation « Code as Craft</title>
    <dc:date>2012-12-12T13:28:36+00:00</dc:date>
    <link>http://codeascraft.etsy.com/2012/04/20/two-sides-for-salvation/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Etsy's MySQL master-master pair configuration, and how it allows no-downtime schema changes]]></description>
<dc:subject>database etsy mysql replication schema availability downtime</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3662d0721dbe/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:etsy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:schema"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:availability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:downtime"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://saucelabs.com/blog/index.php/2012/05/goodbye-couchdb/">
    <title>Goodbye, CouchDB</title>
    <dc:date>2012-05-10T21:16:34+00:00</dc:date>
    <link>http://saucelabs.com/blog/index.php/2012/05/goodbye-couchdb/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['From most model-using code, using [Percona] MySQL looks exactly the same as using CouchDB did. Except it’s faster, and the DB basically never fails.'
]]></description>
<dc:subject>couchdb mysql nosql databases storage percona via:peakscale</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9c3fd9393941/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:couchdb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:databases"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percona"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:peakscale"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.gamasutra.com/view/news/168799/Scale_Something_How_Draw_Something_rode_its_rocket_ship_of_growth.php">
    <title>Scale Something: How Draw Something rode its rocket ship of growth</title>
    <dc:date>2012-04-19T20:19:22+00:00</dc:date>
    <link>http://www.gamasutra.com/view/news/168799/Scale_Something_How_Draw_Something_rode_its_rocket_ship_of_growth.php</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Membase, surprise answer.  In general it sounds like they had a pretty crazy time -- rebuilding the plane in flight even more than usual. "This had us on our toes and working 24 hours a day. I think at one point we were up for around 60-plus hours straight, never leaving the computer. We had to scale out web servers using DNS load balancing, we had to get multiple HAProxies, break tables off MySQL to their own databases, transparently shard tables, and more. This was all being done on demand, live, and usually in the middle of the night.  We were very lucky that most of our layers were scalable with little or no major modifications needed. Helping us along the way was our very detailed custom server monitoring tools which allowed us to keep a very close eye on load, memory, and even provided real time usage stats on the game which helped with capacity planning. We eventually ended up with easy to launch "clusters" of our app that included NGINX, HAProxy, and Goliath servers all of which independent of everything else and when launched, increased our capacity by a constant. At this point our drawings per second were in the thousands, and traffic that looked huge a week ago was just a small bump on the current graphs."]]></description>
<dc:subject>scale scalability draw-something games haproxy mysql membase couchbase</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:227a490d3262/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scale"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:draw-something"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:games"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:haproxy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:membase"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:couchbase"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://highscalability.com/blog/2011/12/19/how-twitter-stores-250-million-tweets-a-day-using-mysql.html">
    <title>High Scalability - How Twitter Stores 250 Million Tweets a Day Using MySQL</title>
    <dc:date>2011-12-19T21:49:50+00:00</dc:date>
    <link>http://highscalability.com/blog/2011/12/19/how-twitter-stores-250-million-tweets-a-day-using-mysql.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[MySQL as a storage backend -- basically an InnoDB store]]></description>
<dc:subject>mysql twitter scalability gizzard innodb performance database</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:bf5a9b9e5b85/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:twitter"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gizzard"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:innodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:database"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://highscalability.com/bunch-great-strategies-using-memcached-and-mysql-better-together">
    <title>good taxonomy of memcached use cases</title>
    <dc:date>2011-08-23T11:00:54+00:00</dc:date>
    <link>http://highscalability.com/bunch-great-strategies-using-memcached-and-mysql-better-together</link>
    <dc:creator>jm</dc:creator><description><![CDATA[via Jeff Barr's announcement of the Elasticache launch.  from 2008, but a better taxonomy than I've seen elsewhere]]></description>
<dc:subject>memcached caching mysql performance scalability via:jeffbarr</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:010b32939fd2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memcached"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:jeffbarr"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.philwhln.com/quoras-technology-examined?ref=reddit">
    <title>Quora’s Technology Examined</title>
    <dc:date>2011-02-05T21:50:36+00:00</dc:date>
    <link>http://www.philwhln.com/quoras-technology-examined?ref=reddit</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Python, Nginx, Tornado for COMET stuff, MySQL as a data store, memcached, Thrift, haproxy, AWS, Pylons.  fantastic, very detailed post (via Nelson)]]></description>
<dc:subject>quora python nginx tornado comet mysql memcached thrift haproxy aws pylons via:nelson</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:0e6e81529af5/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quora"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:python"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nginx"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tornado"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:comet"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memcached"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:thrift"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:haproxy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pylons"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:nelson"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.maatkit.org/doc/synopsis">
    <title>Maatkit</title>
    <dc:date>2010-10-28T13:48:16+00:00</dc:date>
    <link>http://www.maatkit.org/doc/synopsis</link>
    <dc:creator>jm</dc:creator><description><![CDATA[MySQL/PostgreSQL admin helper tools -- check replication status, archive, analyse logs, find deadlocks]]></description>
<dc:subject>sysadmin db mysql replication maatkit dba</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:19a8d702c591/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sysadmin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:db"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:replication"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:maatkit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dba"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/">
    <title>The MySQL “swap insanity” problem and the effects of the NUMA architecture</title>
    <dc:date>2010-09-29T15:48:24+00:00</dc:date>
    <link>http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[very interesting; modern multicore x86 architectures use a NUMA memory architecture, which can cause a dip into swap, even when there appears to be plenty of free RAM available]]></description>
<dc:subject>linux memory mysql optimization performance swap tuning vm numa swap-insanity swapping</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:6aad45b4a7bc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:numa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swap-insanity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swapping"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.blue74.com/?p=25">
    <title>We’re Back… so long MongoDB! · Blue74</title>
    <dc:date>2010-06-23T20:03:19+00:00</dc:date>
    <link>http://www.blue74.com/?p=25</link>
    <dc:creator>jm</dc:creator><description><![CDATA[MongoDB war story -- records going missing, eek]]></description>
<dc:subject>mongodb mysql nosql rant stability beta</dc:subject>
<dc:identifier>https://pinboard.in/u:jm/b:bc58a76d21be/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mongodb"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mysql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nosql"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rant"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:stability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:beta"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>