1. 2
  1.  

  2. 2

    Too bad they didn’t discuss whe they didn’t move to something like Riak or Cassandra, which give you the same guarantees as you can get with sharding (or better) without the operational pain.

    1. 4

      They probably kept using MySQL instead of moving to something like Riak or Cassandra because they need joins, transactions, and other features typically found in a RDBMS.

      1. 1

        If you’re sharding, you’re already giving up all of those things unless you have a very special (read brittle) sharding.

        1. 1

          It’s sometimes possible to choose a sharding strategy where most queries hit a single shard, which makes joins and transactions still useful.

          That’s exactly what Asana do: they shard “by workspace”, according to the linked article.

          There is a similar concept in Google Cloud Datastore where there is a distinction between non-distributed transactions which hit a single “entity group” and distributed transactions which hit at most 25 entity groups:

          https://cloud.google.com/appengine/docs/python/datastore/transactions

          1. 1

            Yeah, we can go back and forth on the technical benfits of one solution vs another, my point is that I would have liked to have seen that discussion in the post.