We migrated from MySQL to PostgreSQL in the fall of 2010. We were also starting to see deadlock issues with MySQL, which were on operations we felt shouldn't deadlock. We explored various options with MySQL (such as oak-online-alter-table), but decided that we would rather move to a database that supported it directly. We couldn't keep affording to take downtime while we upgraded or even added a new index to a large table. We were iterating quickly, and our schema was evolving. As our dataset grew, our deploys started taking longer and longer. The biggest problem we faced was that schema migrations on large tables took a long time with MySQL. DRBD uses block level replication to mirror partitions between servers.This setup was fine at first, but as our traffic started growing, we began to see problems. We ran a couple of app servers and two database servers replicated using DRBD. Like most Ruby on Rails apps in 2008, our gateway started out on MySQL. We've had a lot of help along the way from the very knowledgeable people at Command Prompt. In this post, I'm going to walk you through the evolution of how we host and use PostgreSQL. Our PostgreSQL setup has changed a lot over the last few years. For example, if our traffic looks fishy, we can answer questions like "What is the percentage of Visa declines coming from Europe?" without having to pre-compute views or write complex map/reduce queries. We also love the ad-hoc querying that we get from a relational database. It's not as sexy as the new NoSQL databases, but PostgreSQL is consistent and incredibly reliable, two properties we value when storing payment information. Although we use many different data stores (such as Riak, MongoDB, Redis, and Memcached), most of our core data is stored in PostgreSQL.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |