How We Partitioned Airbnb’s Main Database in Two Weeks
nerds.airbnb.com
How We Partitioned Airbnb’s Main Database in Two Weeks
1–10 of 20 posts
Re: How We Partitioned Airbnb’s Main Database in Two Weeks
#2RDS wouldn't be my first choice to run in a production environment like AirBNB...
Re: How We Partitioned Airbnb’s Main Database in Two Weeks
#3RDS wouldn't be my first choice to run in a production environment like AirBNB...
How come? Isn't that exactly what RDS is designed for?
Re: How We Partitioned Airbnb’s Main Database in Two Weeks
#4[deleted]
Re: How We Partitioned Airbnb’s Main Database in Two Weeks
#5RDS wouldn't be my first choice to run in a production environment like AirBNB...
RDS is just fine for production environments. Any tuning you need done can be done with parameters; your only limit might be that imposed on RDS for connections (based on instance size).
Re: How We Partitioned Airbnb’s Main Database in Two Weeks
#6RDS wouldn't be my first choice to run in a production environment like AirBNB...
RDS is just fine for production environments. Any tuning you need done can be done with parameters; your only limit might be that imposed on RDS for connections (based on instance size).
Failing between AZs is a multi minute process and sometimes doesn't work at which point you have to get someone on the phone.
Re: How We Partitioned Airbnb’s Main Database in Two Weeks
#7This really shows the value of a few good engineers. I can easily see this taking a team of engineers much longer, but in this case a few engineers figured out the least painful solution and implemented it with minimal down time.
Re: How We Partitioned Airbnb’s Main Database in Two Weeks
#8Those who forget Oracle are doomed to reinvent it.
Re: How We Partitioned Airbnb’s Main Database in Two Weeks
#9[deleted]
Re: How We Partitioned Airbnb’s Main Database in Two Weeks
#10RDS wouldn't be my first choice to run in a production environment like AirBNB...
RDS is just fine for production environments. Any tuning you need done can be done with parameters; your only limit might be that imposed on RDS for connections (based on instance size).
In my experience (a few years ago though, to be honest), RDS was absolutely terrible for high performance and/or latency sensitive write workloads. Due to how (again, at the time) replication was handled -- amazon apparently did (at the time? still does?) synchronous writes to each AZ, and only completes the transaction when both return. When one AZ/RDS-instance was slow or dropping packets (seemed oddly frequent at the time for cross-AZ traffic -- again about 3 years ago though), our production stack would catch fire and come to a crashing halt. Never again!