{"title":"consistent:保持弱一致性下的正确性和SLA","authors":"Subhajit Sidhanta, S. Mukhopadhyay, W. Golab","doi":"10.1145/3288599.3288630","DOIUrl":null,"url":null,"abstract":"While executing a client application, comprising a sequence of one or more storage operations (read, write, etc.), replicated datastores provide the option of tuning per-operation client-centric consistency settings, Weaker consistency settings allow client applications to execute with lower observed latency due to less coordination among the replica, improving throughput. To enable a client application running on a geo-replicated datastore to meet stringent SLA (Service Level Agreement) deadlines, i.e., latency thresholds provided in the SLA, users apply weak client-centric consistency settings. Strong consistency settings may result in higher latency due to coordination among greater number of replicas. However, since a weak consistency setting requires only a partial quorum of replicas to coordinate, some of the replicas may be overwritten by conflicting updates from concurrent clients, which, in turn, may result in violation of correctness conditions specified by the developer. Such correctness conditions are provided as postconditions that impose restrictions on the values observed by the clients. Enforcing correctness conditions under weak consistency settings on geo-replicated datastores from the client application code is a tedious and challenging task. The task is even more complicated when considering application-level SLA deadlines. Deadline (latency) is one of the most important SLA parameters for optimizing client-centric performance. To this end, we present Consistify, a novel framework, that acts as an interface layer between client applications and underlying data-stores, and enables client applications to execute with weak per-operation consistency settings, while simultaneously respecting: 1) the correctness conditions, specified using logical predicates, and 2) the SLA deadline. Using benchmark workloads, we experimentally demonstrate that Consistify outperforms the state-of-the-art systems, namely QUELA. For several other systems that provide flexible consistency settings, namely Bolt-on causal system, SIEVE, and Cure, we provide a comparison of the throughput and latency observed with Consistify against the numbers reported with those systems in prior papers.","PeriodicalId":346177,"journal":{"name":"Proceedings of the 20th International Conference on Distributed Computing and Networking","volume":"30 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2019-01-04","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"1","resultStr":"{\"title\":\"Consistify: preserving correctness and SLA under weak consistency\",\"authors\":\"Subhajit Sidhanta, S. Mukhopadhyay, W. Golab\",\"doi\":\"10.1145/3288599.3288630\",\"DOIUrl\":null,\"url\":null,\"abstract\":\"While executing a client application, comprising a sequence of one or more storage operations (read, write, etc.), replicated datastores provide the option of tuning per-operation client-centric consistency settings, Weaker consistency settings allow client applications to execute with lower observed latency due to less coordination among the replica, improving throughput. To enable a client application running on a geo-replicated datastore to meet stringent SLA (Service Level Agreement) deadlines, i.e., latency thresholds provided in the SLA, users apply weak client-centric consistency settings. Strong consistency settings may result in higher latency due to coordination among greater number of replicas. However, since a weak consistency setting requires only a partial quorum of replicas to coordinate, some of the replicas may be overwritten by conflicting updates from concurrent clients, which, in turn, may result in violation of correctness conditions specified by the developer. Such correctness conditions are provided as postconditions that impose restrictions on the values observed by the clients. Enforcing correctness conditions under weak consistency settings on geo-replicated datastores from the client application code is a tedious and challenging task. The task is even more complicated when considering application-level SLA deadlines. Deadline (latency) is one of the most important SLA parameters for optimizing client-centric performance. To this end, we present Consistify, a novel framework, that acts as an interface layer between client applications and underlying data-stores, and enables client applications to execute with weak per-operation consistency settings, while simultaneously respecting: 1) the correctness conditions, specified using logical predicates, and 2) the SLA deadline. Using benchmark workloads, we experimentally demonstrate that Consistify outperforms the state-of-the-art systems, namely QUELA. For several other systems that provide flexible consistency settings, namely Bolt-on causal system, SIEVE, and Cure, we provide a comparison of the throughput and latency observed with Consistify against the numbers reported with those systems in prior papers.\",\"PeriodicalId\":346177,\"journal\":{\"name\":\"Proceedings of the 20th International Conference on Distributed Computing and Networking\",\"volume\":\"30 1\",\"pages\":\"0\"},\"PeriodicalIF\":0.0000,\"publicationDate\":\"2019-01-04\",\"publicationTypes\":\"Journal Article\",\"fieldsOfStudy\":null,\"isOpenAccess\":false,\"openAccessPdf\":\"\",\"citationCount\":\"1\",\"resultStr\":null,\"platform\":\"Semanticscholar\",\"paperid\":null,\"PeriodicalName\":\"Proceedings of the 20th International Conference on Distributed Computing and Networking\",\"FirstCategoryId\":\"1085\",\"ListUrlMain\":\"https://doi.org/10.1145/3288599.3288630\",\"RegionNum\":0,\"RegionCategory\":null,\"ArticlePicture\":[],\"TitleCN\":null,\"AbstractTextCN\":null,\"PMCID\":null,\"EPubDate\":\"\",\"PubModel\":\"\",\"JCR\":\"\",\"JCRName\":\"\",\"Score\":null,\"Total\":0}","platform":"Semanticscholar","paperid":null,"PeriodicalName":"Proceedings of the 20th International Conference on Distributed Computing and Networking","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/3288599.3288630","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
Consistify: preserving correctness and SLA under weak consistency
While executing a client application, comprising a sequence of one or more storage operations (read, write, etc.), replicated datastores provide the option of tuning per-operation client-centric consistency settings, Weaker consistency settings allow client applications to execute with lower observed latency due to less coordination among the replica, improving throughput. To enable a client application running on a geo-replicated datastore to meet stringent SLA (Service Level Agreement) deadlines, i.e., latency thresholds provided in the SLA, users apply weak client-centric consistency settings. Strong consistency settings may result in higher latency due to coordination among greater number of replicas. However, since a weak consistency setting requires only a partial quorum of replicas to coordinate, some of the replicas may be overwritten by conflicting updates from concurrent clients, which, in turn, may result in violation of correctness conditions specified by the developer. Such correctness conditions are provided as postconditions that impose restrictions on the values observed by the clients. Enforcing correctness conditions under weak consistency settings on geo-replicated datastores from the client application code is a tedious and challenging task. The task is even more complicated when considering application-level SLA deadlines. Deadline (latency) is one of the most important SLA parameters for optimizing client-centric performance. To this end, we present Consistify, a novel framework, that acts as an interface layer between client applications and underlying data-stores, and enables client applications to execute with weak per-operation consistency settings, while simultaneously respecting: 1) the correctness conditions, specified using logical predicates, and 2) the SLA deadline. Using benchmark workloads, we experimentally demonstrate that Consistify outperforms the state-of-the-art systems, namely QUELA. For several other systems that provide flexible consistency settings, namely Bolt-on causal system, SIEVE, and Cure, we provide a comparison of the throughput and latency observed with Consistify against the numbers reported with those systems in prior papers.