Facebook has always been using MySQL databases ever since its genesis. Most people are curious about the optimisation process that allows the social networking site to support data from over two billion users and yet run smoothly without any snags. In fact, when people talk about scalable databases, the mention of Facebook is almost mandatory. There have been no bigger success stories in the niche of database management and growth in the recent times for sure. Facebook may still be using MySQL database as their core engine, but with changing times, the team led by Mark Zuckerberg is now gradually gravitating towards NoSQL databases like most prominent organisations.
Inclination towards a NoSQL database
Back in 2014, Jeff Johnson, a Facebook representative announced the introduction of Apollo at the QCon New York. It is Facebook’s own version of the Paxos like NoSQL database. This new NoSQL database model is a hierarchical storage system. The stored data in the advanced database is available in fragments, just like in region servers in HBase. However, the unique feature of the new NoSQL model is its online low latency storage system. It is not a document-oriented data system. Apollo is more about data structure modification that will allow the users to modify data structures without much prologue. The individual shards of data are small – between a byte and 1MB. But the total size of the data can reach up to 10+ Petabyte. It can support almost a thousand servers starting from a meager three.
Understanding Apollo
The data stored in the Apollo database is available in the form of tiny fragments. Each of these fragments has four distinct components.
The first part of Apollo is based on Raft. It is a quorum consensus protocol that is a direct derivation of Raft — the robust leader protocol from the house of Stanford. This is unique about the Apollo database system.
The second component in the Apollo database is the storage system inside the database. RocksDB inspires the storage system. It is a Key/Value store built on Google LevelDB. Facebook can easily manipulate it to mimic other data structures including its old MySQL database structure. Notably, Apollo is not very amicable to customisations of storage. As a result, the database management teams of Facebook are working on adding fragments of MySQL database support to their new Apollo database storage system.
The third component is Facebook’s native API. Any database API is a critical component. For Apollo, it is a Client API with read() and write() components. Users need to express their pre-conditions. Apollo returns the values (reads or writes) if the preconditions are correct. You must remember that all data inside the database is in fragments. Therefore, any operation inside the Apollo database at the Shard level is atomic. You can always combine many conditions and reads together to create new operations pre-conditions.
The fourth component is the Fault Tolerant State Machines or FTSMs. These are a part of the system code in Apollo DB. Each shard owns a separate FTSM. Think of it this way, if there is a shard of three different machines, all of them will execute the same code concurrently. It has a huge advantage in the world of large databases. If one code suddenly dies, the other shards keep running the same code in the proper acceptable order, accepted by all nodes.
Although there’s a huge hullaballoo about Apollo being Facebook’s new blue-eyed boy, the news says, Facebook is not using it in production as of now. The company is instead looking forward to replacing some Memcached use cases. Facebook relies heavily on memory cached storage systems, and that is no secret. There are whispers about Apollo becoming the new queuing system for outbound messages from Facebook to iOS devices and carriers via SMS. It is going to be great for analytics. Furthermore, it will boost speed and accuracy of data extraction.
Why is Apollo coming to existence
Facebook uses the state machines mostly for load balancing, shard generation and management, coordinating data transactions across machines and data migrations. However, the process is not perfect enough. These state machines can send RPC requests to the remote servers. In addition to that, whenever users need to make changes to the persistent state of data, they need to go through Raft and get all other servers to agree.
What is Facebook using right now
Apollo is still “under construction.” It is far away from being the daily database for Facebook. Therefore, at present, the social networking giant is using MySQL databases with a lot of modifications and add-ons to facilitate the humongous amounts of data transfer and data storage every day. You cannot expect a multi-billion dollar corporation to use MySQL out-of-the-box! They have induced some changes in the IO Subsystem including new features:
innodb_read_io_threads, innodb_write_io_threads – This sets the number of background IO threads.
innodb_io_capacity – This sets the IO capacity of each server to determine the background IO limits.
innodb_max_merged_io – This one sets the highest number of adjoining IO requests. Usually, the next IO requests merge into a much larger IO request later on.
Unlike Apollo, Facebook is currently relying upon the MySQL database as a key-value store, which enables random distribution of data across an array of logical instances. You can find these across the physical nodes of the server. All the load balancing work of the current server happens at the physical node level only.
The most surprising rumor states that Facebook has about 1,800 MySQL servers and only three in-house DBAs. This seems like quite an impossible task! Well, even if Facebook had just three DBAs to manage the entire dataset, it would never be possible without a MySQL database. It is simple yet powerful, and it will take Facebook or any other similar networking site years to replace the MySQL servers with the new NoSQL servers on a full-time basis.
