Selective Data Replication for Online Social Networks with Distributed Datacenters

Abstract

Though the new OSN model, which deploys datacenters globally, helps reduce service latency, it causes higher inter-datacenter communication load. In Facebook, each datacenter has a full copy of all data, and the master datacenter updates all other datacenters, generating tremendous load in this new model. Distributed data storage, which only stores a user's data to his/her geographically closest datacenters mitigates the problem. However, frequent interactions between distant users lead to frequent inter-datacenter communication and hence long service latencies. In this paper, we aim to reduce inter-datacenter communications while still achieving low service latency. We first verify the benefits of the new model and present OSN typical properties that underlie the basis of our design. We then propose Selective Data replication mechanism in Distributed Datacenters (SD 3 ). Since replicas need inter-datacenter data updates, datacenters in SD 3 jointly consider update rates and visit rates to select user data for replication; furthermore, SD 3 atomizes users' different types of data (e.g., status update, friend post, music) for replication, ensuring that a replica always reduces inter-datacenter communication. SD 3 also incorporates three strategies to further enhance its performance: locality-aware multicast update tree, replica deactivation, and datacenter congestion control. The results of trace-driven experiments on the real-world PlanetLab testbed demonstrate the higher efficiency and effectiveness of SD 3 in comparison to other replication methods and the effectiveness of its three schemes. and require only the capacity to serve nearby users, not all users in the OSN. Assigning the geographically closest datacenter to a user to serve the user and store his/her master replica helps reduce service latency and service network load to the users of OSNs, since the network load of a package is related to both package size and transmission distance [4]. Indeed, Facebook is now building a datacenter in Sweden to make Facebook faster for Europeans [3]. However, this new model causes higher inter-datacenter communication load (i.e., network load, the resource consumption for data transmission [4]). In this new model, Facebook's single-master replication protocol obviously would generate a tremendously high load. Though the distributed data storage that maintains a user's data in his/her geographically closest datacenter mitigates the problem, the frequent interactions between distant users lead to frequent communication between datacenters.Thus, in this paper, we study how to replicate data in OSN distributed datacenters to minimize inter-datacenter communication load while still achieving low service latency. Increasing replication of user data can enable the resolution of more data requests locally, leading to lower service latencies; however, a rarely visited replica provides little benefit in terms of service latency reduction but increases network load for updates, leading to higher inter-datacenter communication l...

Adaptive Data Placement for Improving Performance of Online Social Network Services in a Multicloud Environment

“…Additionally, traffic associated with further operations that find data stored in the other cloud is reduced. Liu et al proposed that a cloud can only replicate its frequently requested data from other clouds to reduce intercloud communication due to the update of the replications [2]. These two studies mentioned above consider applicationspecific factors, particularly the social relationship between users.…”

“…As shown in the figure, the amount of traffic is generated differently by location at the same time, as well as by time at the same location. These features also appear in other OSN services such as Facebook and Instagram [2,[13][14][15].…”

“…In our experiment, we evaluated the case of " / = 100" to reflect the fact that OSN services have much more reading operations than writing operations [22]. We set the size of each read and write operation to 1 KB, which is the average request size of OSN services [2]. As a result, the workloads were generated by time, as shown in Figure 13.…”

“…Some studies have addressed this issue by continuously monitoring the service's performance and provisioning resources additionally as needed. Other studies have addressed this issue by applying a more efficient replication technique [1][2][3][4][5][6].…”

“…First, in most Multicloud studies and projects, user data are redundantly stored in several clouds using the master-slave replications technique [3]. In particular, where there are more than 20 clouds, such as the United States [7][8][9], the users benefit in terms of latency delay by accessing the closest cloud to use the OSN service [1,2]. However, in this case, unnecessary storage waste may occur by storing user data into the cloud, which are located in a place that users rarely access.…”