Slides Geo-Distributed Databases: Engineering Around the Physics Of

Total Page:16

File Type:pdf, Size:1020Kb

Slides Geo-Distributed Databases: Engineering Around the Physics Of Geo-Distributed Databases: Engineering Around the Physics of Latency 1 © 2021 All Rights Reserved Who we are Taylor Mull Suda Srinivasan ● Senior Data Engineer ● VP of Solutions ● DataStax, Charter Comms ● ~15 years in tech - many hats ● Nutanix, Deloitte, Microsoft, bunch of startups © 2021 All Rights Reserved Cloud native relational database for cloud native applications SQL PostgreSQL Resilience and Compatibility High Availability Transactional distributed SQL database Horizontal Geographic built for resilience and scale. Scalability Distribution 100% open source. Runs in any cloud. ACID Security Transactions © 2021 All Rights Reserved 3 What is a geo-distributed database? Data centers Availability zones A single database that is spread across Regions two or more geographically distinct locations, and runs without experiencing performance delays in executing transactions But Physics! © 2021 All Rights Reserved The physics of wire latency Speed of light ~60 ms + 1-2 ms Transmission media Packet size ~150 ms Packet loss Signal strength Propagation delays ... © 2021 All Rights Reserved Latency in the I/O path Keep your data close to usage and compute close to data © 2021 All Rights Reserved Why deploy geo-distributed databases? Resilience Performance Compliance ● Datacenters, cloud AZs, even ● Customers and users are located ● Data residency laws require data regions can fail around the world about a nation's citizens or ● Applications and databases ● Moving data close to usage and residents to be collected, should be resilient and available compute close to data lowers processed, and/or stored inside through failures latency the country © 2021 All Rights Reserved Core concepts 0. YugabyteDB architecture 1. Synchronous replication within a YugabyteDB cluster 2. Follower reads 3. xCluster asynchronous replication - unidirectional and bidirectional 4. Read replicas 5. Geo-partitioning © 2021 All Rights Reserved Core concept 0: YugabyteDB architecture App Node Node Node ● Nodes across DCs, zones, and regions ● User tables sharded into tablets (group of rows) ● Tablets (per-table, across tables) evenly distributed across nodes ● Sharding and distribution are transparent to the user © 2021 All Rights Reserved Designing the perfect distributed SQL DB Aurora much more popular than Spanner Yugabyte Query Layer YCQL YSQL Amazon Aurora Google Spanner DocDB Distributed Document Store A highly available MySQL The first horizontally scalable, Distributed Sharding & Load Raft Consensus and PostgreSQL-compatible strongly consistent, relational Transaction Manager Balancing Replication & MVCC relational database service database service Document Storage Layer Not scalable but HA Scalable and HA Custom RocksDB Storage Engine All RDBMS features Missing RDBMS features PostgreSQL & MySQL New SQL syntax bit.ly/distributed-sql-deconstructed © 2021 All Rights Reserved Core concept 1: Synchronous replication by default ● Each tablet is replicated App ● YugabyteDB uses Raft consensus protocol for leader election and replication ● Writes are replicated to all the tablets peers; they need to be acknowledged by a majority of the peers before the write succeeds ● Reads and writes are served by the tablet Node Node Node leader (by default) ● Sync replication offers: ○ Consistency ○ Resilience ● Sync replication costs: ○ Latency RF-3 tablet 1’ © 2021 All Rights Reserved Geo-distribution with sync replication © 2021 All Rights Reserved Enabling business outcomes: Top 5 global retailer An American multinational retail corporation that operates a chain of hypermarkets, department stores, and grocery stores in countries around the world WHY YUGABYTE SOLUTION AND BENEFITS ● Linear scale with product growth ● SOR for product catalog of +100 million items with ● Open source billions of mappings, serving over 100K qps ● Cloud-agnostic, geo-distributed ● Enhanced product agility ● Multi-row ACID transactions ● Handled Black Friday and Cyber Monday peaks ● Alternate key lookups ● Service remained resilient and available through TX ● Better performance and resiliency than Azure cloud outage CosmosDB, Azure Cloud SQL, and other databases ● $10M in lost revenue recovered © 2021 All Rights Reserved Multi-region deployment for resilience: Top 5 retailer Deployment: 27 Azure nodes across 3 regions - US-East, US-West Seattle, and US-South Texas US-East Cores: 16 Memory: 128 GB Disk: 2 x 1024 GB premium P40 disks per node US-West- US-South-Texas OS: CentOS 7.8 Seattle Preferred leaders in US-South Central region Service remained resilient and available through the Texas cloud power outage © 2021 All Rights Reserved Core concept 2: Follower reads trade off freshness for latency Leader Follower 1 Follower 2 15 15 15 ● Follower reads can return stale data ● Followers located near the client can Write req serve data with low latency 20 15 15 received ● Follower read configuration is at the app level Write ● Follower reads offer: completed 20 20 15 ○ Low latency ● Follower reads cost: Read req Data accuracy (freshness) received 20 20 15 ○ Tablet fully replicated 20 20 15 tablet 1’ © 2021 All Rights Reserved Core concept 3: xCluster asynchronous replication Master Cluster 1 in Region 1 Master Cluster 2 in Region 2 Availability Zone 1 Availability Zone 1 Unidirectional or Bidirectional Async Replication Availability Zone 2 Availability Zone 3 Availability Zone 2 Availability Zone 3 Consistent Across Zones Consistent Across Zones No Cross-Region Latency for Both Writes & Reads No Cross-Region Latency for Both Writes & Reads © 2021 All Rights Reserved 16 Enabling business outcomes: Kroger Largest supermarket chain in the US with over 2,750 supermarkets and multi-departments stores. Rapidly growing digital channel, especially during the COVID-19 crisis. WHY YUGABYTE SOLUTION AND BENEFITS ● Distributed ACID transactions, scalability ● YugabyteDB is the SOR for the shopping list service ● Geo-distributed deployment for resilience ● 42 states, 9m shoppers ● Multi-API support - YSQL, YCQL ● Multi-region deployment with sync replication for ● Automatic data sharding resilience with single digit latency ● Open source ● xCluster bidirectional replication ● Designed to be multi-cloud on GCP and Azure ”We have been leveraging YugabyteDB as the distributed SQL database running natively inside Kubernetes to power the business-critical apps that require scale and high availability.” - Mahesh Thyagarajan, VP Engineering © 2021 All Rights Reserved Core concept 4: Read replicas AZ 1 ● Read replicas offer low latency reads AZ 2 AZ 3 ● Read replicas can’t be used for resilience/ failover AZ 1 Read Replica AZ 2 © 2021 All Rights Reserved 18 © 2021 All Rights Reserved 19 Admiral architecture Deployed across 5 countries, 3 continents ● Synchronous cluster across US West, US Central, and US East ● Each region has a master process for HA ● Read replica clusters in Asia and Europe © 2021 All Rights Reserved Core concept 5: Row-level geo-partitioning id geo id geo 4 UK 1 US ● Pin rows of a table or indexes to specific geos ● Strong consistency id geo ● Low read and write 2 IND 3 IND latency © 2021 All Rights Reserved Flexible deployment options in a single database Consistency Read Latency Write Latency Used For Multi-zone cluster Strong Low within region 1-10 ms Low within region 1-10 ms Zone-level resilience Multi-region stretched Tunable (with High with strong consistency 40-100 ms, always Region-level resilience cluster follower reads) or Low with eventual strongly consistent consistency xCluster Async Eventual (timeline) Low within region 1-10 ms Low within region 1-10 ms Backup and DR single-direction xCluster Async Eventual (timeline) Low within region 1-10 ms Low within region 1-10 ms Backup and DR bidirectional Read replicas Strong in primary Low within primary cluster Low within region 1-10 ms Low latency reads; not a cluster; eventual in region 1-10 ms DR solution (not an read replica clusters independent failure domain) Geo-partitioning Strong Low within region 1-10 ms; Low within region 1-10 ms Compliance high across regions 40-100ms © 2021 All Rights Reserved Summary of core concepts 1. Data is synchronously replicated within a Yugabyte cluster by default. 2. Nodes can be placed in different zones, different regions (stretched), or different cloud. 3. Reads and writes are handled by the tablet leader. 4. Follower reads trade off data freshness for lower latency. 5. xCluster replication asynchronously replicates data across clusters for backup/DR. 6. Read replicas enable low latency reads from local clusters. 7. Geo-partitioning allows table rows and indexes to be pinned to specific geographies. These options allow you to prioritize different objectives - resilience, data freshness, latency, and compliance. Achieve desired resilience, latency, and compliance for your apps. © 2021 All Rights Reserved Thank You Join us on Slack: yugabyte.com/slack Star us on GitHub: github.com/yugabyte/yugabyte-db © 2021 All Rights Reserved 24.
Recommended publications
  • Latency and Throughput Optimization in Modern Networks: a Comprehensive Survey Amir Mirzaeinnia, Mehdi Mirzaeinia, and Abdelmounaam Rezgui
    READY TO SUBMIT TO IEEE COMMUNICATIONS SURVEYS & TUTORIALS JOURNAL 1 Latency and Throughput Optimization in Modern Networks: A Comprehensive Survey Amir Mirzaeinnia, Mehdi Mirzaeinia, and Abdelmounaam Rezgui Abstract—Modern applications are highly sensitive to com- On one hand every user likes to send and receive their munication delays and throughput. This paper surveys major data as quickly as possible. On the other hand the network attempts on reducing latency and increasing the throughput. infrastructure that connects users has limited capacities and These methods are surveyed on different networks and surrond- ings such as wired networks, wireless networks, application layer these are usually shared among users. There are some tech- transport control, Remote Direct Memory Access, and machine nologies that dedicate their resources to some users but they learning based transport control, are not very much commonly used. The reason is that although Index Terms—Rate and Congestion Control , Internet, Data dedicated resources are more secure they are more expensive Center, 5G, Cellular Networks, Remote Direct Memory Access, to implement. Sharing a physical channel among multiple Named Data Network, Machine Learning transmitters needs a technique to control their rate in proper time. The very first congestion network collapse was observed and reported by Van Jacobson in 1986. This caused about a I. INTRODUCTION thousand time rate reduction from 32kbps to 40bps [3] which Recent applications such as Virtual Reality (VR), au- is about a thousand times rate reduction. Since then very tonomous cars or aerial vehicles, and telehealth need high different variations of the Transport Control Protocol (TCP) throughput and low latency communication.
    [Show full text]
  • Measuring Latency Variation in the Internet
    Measuring Latency Variation in the Internet Toke Høiland-Jørgensen Bengt Ahlgren Per Hurtig Dept of Computer Science SICS Dept of Computer Science Karlstad University, Sweden Box 1263, 164 29 Kista Karlstad University, Sweden toke.hoiland- Sweden [email protected] [email protected] [email protected] Anna Brunstrom Dept of Computer Science Karlstad University, Sweden [email protected] ABSTRACT 1. INTRODUCTION We analyse two complementary datasets to quantify the la- As applications turn ever more interactive, network la- tency variation experienced by internet end-users: (i) a large- tency plays an increasingly important role for their perfor- scale active measurement dataset (from the Measurement mance. The end-goal is to get as close as possible to the Lab Network Diagnostic Tool) which shed light on long- physical limitations of the speed of light [25]. However, to- term trends and regional differences; and (ii) passive mea- day the latency of internet connections is often larger than it surement data from an access aggregation link which is used needs to be. In this work we set out to quantify how much. to analyse the edge links closest to the user. Having this information available is important to guide work The analysis shows that variation in latency is both com- that sets out to improve the latency behaviour of the inter- mon and of significant magnitude, with two thirds of sam- net; and for authors of latency-sensitive applications (such ples exceeding 100 ms of variation. The variation is seen as Voice over IP, or even many web applications) that seek within single connections as well as between connections to to predict the performance they can expect from the network.
    [Show full text]
  • Nosql Databases: Yearning for Disambiguation
    NOSQL DATABASES: YEARNING FOR DISAMBIGUATION Chaimae Asaad Alqualsadi, Rabat IT Center, ENSIAS, University Mohammed V in Rabat and TicLab, International University of Rabat, Morocco [email protected] Karim Baïna Alqualsadi, Rabat IT Center, ENSIAS, University Mohammed V in Rabat, Morocco [email protected] Mounir Ghogho TicLab, International University of Rabat Morocco [email protected] March 17, 2020 ABSTRACT The demanding requirements of the new Big Data intensive era raised the need for flexible storage systems capable of handling huge volumes of unstructured data and of tackling the challenges that arXiv:2003.04074v2 [cs.DB] 16 Mar 2020 traditional databases were facing. NoSQL Databases, in their heterogeneity, are a powerful and diverse set of databases tailored to specific industrial and business needs. However, the lack of the- oretical background creates a lack of consensus even among experts about many NoSQL concepts, leading to ambiguity and confusion. In this paper, we present a survey of NoSQL databases and their classification by data model type. We also conduct a benchmark in order to compare different NoSQL databases and distinguish their characteristics. Additionally, we present the major areas of ambiguity and confusion around NoSQL databases and their related concepts, and attempt to disambiguate them. Keywords NoSQL Databases · NoSQL data models · NoSQL characteristics · NoSQL Classification A PREPRINT -MARCH 17, 2020 1 Introduction The proliferation of data sources ranging from social media and Internet of Things (IoT) to industrially generated data (e.g. transactions) has led to a growing demand for data intensive cloud based applications and has created new challenges for big-data-era databases.
    [Show full text]
  • The Effects of Latency on Player Performance and Experience in A
    The Effects of Latency on Player Performance and Experience in a Cloud Gaming System Robert Dabrowski, Christian Manuel, Robert Smieja May 7, 2014 An Interactive Qualifying Project Report: submitted to the Faculty of the WORCESTER POLYTECHNIC INSTITUTE in partial fulfillment of the requirements for the Degree of Bachelor of Science Approved by: Professor Mark Claypool, Advisor Professor David Finkel, Advisor This report represents the work of three WPI undergraduate students submitted to the faculty as evidence of completion of a degree requirement. WPI routinely publishes these reports on its web site without editorial or peer review. Abstract Due to the increasing popularity of thin client systems for gaming, it is important to un- derstand the effects of different network conditions on users. This paper describes our experiments to determine the effects of latency on player performance and quality of expe- rience (QoE). For our experiments, we collected player scores and subjective ratings from users as they played short game sessions with different amounts of additional latency. We found that QoE ratings and player scores decrease linearly as latency is added. For ev- ery 100 ms of added latency, players reduced their QoE ratings by 14% on average. This information may provide insight to game designers and network engineers on how latency affects the users, allowing them to optimize their systems while understanding the effects on their clients. This experiment design should also prove useful to thin client researchers looking to conduct user studies while controlling not only latency, but also other network conditions like packet loss. Contents 1 Introduction 1 2 Background Research 4 2.1 Thin Client Technology .
    [Show full text]
  • Object Migration in a Distributed, Heterogeneous SQL Database Network
    Linköping University | Department of Computer and Information Science Master’s thesis, 30 ECTS | Computer Engineering (Datateknik) 2018 | LIU-IDA/LITH-EX-A--18/008--SE Object Migration in a Distributed, Heterogeneous SQL Database Network Datamigrering i ett heterogent nätverk av SQL-databaser Joakim Ericsson Supervisor : Tomas Szabo Examiner : Olaf Hartig Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se Upphovsrätt Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/. Copyright The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose.
    [Show full text]
  • Database Software Market: Billy Fitzsimmons +1 312 364 5112
    Equity Research Technology, Media, & Communications | Enterprise and Cloud Infrastructure March 22, 2019 Industry Report Jason Ader +1 617 235 7519 [email protected] Database Software Market: Billy Fitzsimmons +1 312 364 5112 The Long-Awaited Shake-up [email protected] Naji +1 212 245 6508 [email protected] Please refer to important disclosures on pages 70 and 71. Analyst certification is on page 70. William Blair or an affiliate does and seeks to do business with companies covered in its research reports. As a result, investors should be aware that the firm may have a conflict of interest that could affect the objectivity of this report. This report is not intended to provide personal investment advice. The opinions and recommendations here- in do not take into account individual client circumstances, objectives, or needs and are not intended as recommen- dations of particular securities, financial instruments, or strategies to particular clients. The recipient of this report must make its own independent decisions regarding any securities or financial instruments mentioned herein. William Blair Contents Key Findings ......................................................................................................................3 Introduction .......................................................................................................................5 Database Market History ...................................................................................................7 Market Definitions
    [Show full text]
  • Evaluating the Latency Impact of Ipv6 on a High Frequency Trading System
    Evaluating the Latency Impact of IPv6 on a High Frequency Trading System Nereus Lobo, Vaibhav Malik, Chris Donnally, Seth Jahne, Harshil Jhaveri [email protected] , [email protected] , [email protected] , [email protected] , [email protected] A capstone paper submitted as partial fulfillment of the requirements for the degree of Masters in Interdisciplinary Telecommunications at the University of Colorado, Boulder, 4 May 2012. Project directed by Dr. Pieter Poll and Professor Andrew Crain. 1 Introduction Employing latency-dependent strategies, financial trading firms rely on trade execution speed to obtain a price advantage on an asset in order to earn a profit of a fraction of a cent per asset share [1]. Through successful execution of these strategies, trading firms are able to realize profits on the order of billions of dollars per year [2]. The key to success for these trading strategies are ultra-low latency processing and networking systems, henceforth called High Frequency Trading (HFT) systems, which enable trading firms to execute orders with the necessary speed to realize a profit [1]. However, competition from other trading firms magnifies the need to achieve the lowest latency possible. A 1 µs latency disadvantage can result in unrealized profits on the order of $1 million per day [3]. For this reason, trading firms spend billions of dollars on their data center infrastructure to ensure the lowest propagation delay possible [4]. Further, trading firms have expanded their focus on latency optimization to other aspects of their trading infrastructure including application performance, inter-application messaging performance, and network infrastructure modernization [5].
    [Show full text]
  • Low-Latency Networking: Where Latency Lurks and How to Tame It Xiaolin Jiang, Hossein S
    1 Low-latency Networking: Where Latency Lurks and How to Tame It Xiaolin Jiang, Hossein S. Ghadikolaei, Student Member, IEEE, Gabor Fodor, Senior Member, IEEE, Eytan Modiano, Fellow, IEEE, Zhibo Pang, Senior Member, IEEE, Michele Zorzi, Fellow, IEEE, and Carlo Fischione Member, IEEE Abstract—While the current generation of mobile and fixed The second step in the communication networks revolutions communication networks has been standardized for mobile has made PSTN indistinguishable from our everyday life. Such broadband services, the next generation is driven by the vision step is the Global System for Mobile (GSM) communication of the Internet of Things and mission critical communication services requiring latency in the order of milliseconds or sub- standards suite. In the beginning of the 2000, GSM has become milliseconds. However, these new stringent requirements have a the most widely spread mobile communications system, thanks large technical impact on the design of all layers of the commu- to the support for users mobility, subscriber identity confiden- nication protocol stack. The cross layer interactions are complex tiality, subscriber authentication as well as confidentiality of due to the multiple design principles and technologies that user traffic and signaling [4]. The PSTN and its extension via contribute to the layers’ design and fundamental performance limitations. We will be able to develop low-latency networks only the GSM wireless access networks have been a tremendous if we address the problem of these complex interactions from the success in terms of Weiser’s vision, and also paved the way new point of view of sub-milliseconds latency. In this article, we for new business models built around mobility, high reliability, propose a holistic analysis and classification of the main design and latency as required from the perspective of voice services.
    [Show full text]
  • Architecting Cloud-Native NET Apps for Azure (2020).Pdf
    EDITION v.1.0 PUBLISHED BY Microsoft Developer Division, .NET, and Visual Studio product teams A division of Microsoft Corporation One Microsoft Way Redmond, Washington 98052-6399 Copyright © 2020 by Microsoft Corporation All rights reserved. No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher. This book is provided “as-is” and expresses the author’s views and opinions. The views, opinions, and information expressed in this book, including URL and other Internet website references, may change without notice. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. Microsoft and the trademarks listed at https://www.microsoft.com on the “Trademarks” webpage are trademarks of the Microsoft group of companies. Mac and macOS are trademarks of Apple Inc. The Docker whale logo is a registered trademark of Docker, Inc. Used by permission. All other marks and logos are property of their respective owners. Authors: Rob Vettor, Principal Cloud System Architect/IP Architect - thinkingincloudnative.com, Microsoft Steve “ardalis” Smith, Software Architect and Trainer - Ardalis.com Participants and Reviewers: Cesar De la Torre, Principal Program Manager, .NET team, Microsoft Nish Anil, Senior Program Manager, .NET team, Microsoft Jeremy Likness, Senior Program Manager, .NET team, Microsoft Cecil Phillip, Senior Cloud Advocate, Microsoft Editors: Maira Wenzel, Program Manager, .NET team, Microsoft Version This guide has been written to cover .NET Core 3.1 version along with many additional updates related to the same “wave” of technologies (that is, Azure and additional third-party technologies) coinciding in time with the .NET Core 3.1 release.
    [Show full text]
  • Simulation and Comparison of Various Scheduling Algorithm for Improving the Interrupt Latency of Real –Time Kernal
    Journal of Computer Science and Applications. ISSN 2231-1270 Volume 6, Number 2 (2014), pp. 115-123 © International Research Publication House http://www.irphouse.com Simulation And Comparison of Various Scheduling Algorithm For Improving The Interrupt Latency of Real –Time Kernal 1.Lavanya Dhanesh 2.Dr.P.Murugesan 1.Research Scholar, Sathyabama University, Chennai, India. 2.Professor, S.A. Engineering College, Chennai, India. Email:1. [email protected] Abstract The main objective of the research is to improve the performance of the Real- time Interrupt Latency using Pre-emptive task Scheduling Algorithm. Interrupt Latency provides an important metric in increasing the performance of the Real Time Kernal So far the research has been investigated with respect to real-time latency reduction to improve the task switching as well the performance of the CPU. Based on the literature survey, the pre-emptive task scheduling plays an vital role in increasing the performance of the interrupt latency. A general disadvantage of the non-preemptive discipline is that it introduces additional blocking time in higher priority tasks, so reducing schedulability . If the interrupt latency is increased the task switching delay shall be increasing with respect to each task. Hence most of the research work has been focussed to reduce interrupt latency by many methods. The key area identified is, we cannot control the hardware interrupt delay but we can improve the Interrupt service as quick as possible by reducing the no of preemptions. Based on this idea, so many researches has been involved to optimize the pre-emptive scheduling scheme to reduce the real-time interrupt latency.
    [Show full text]
  • Telematic Performance and the Challenge of Latency
    This is a repository copy of Telematic performance and the challenge of latency. White Rose Research Online URL for this paper: https://eprints.whiterose.ac.uk/126501/ Version: Accepted Version Article: Rofe, Michael and Reuben, Federico orcid.org/0000-0003-1330-7346 (2017) Telematic performance and the challenge of latency. The Journal of Music, Technology and Education. 167–183. ISSN 1752-7074 https://doi.org/10.1386/jmte.10.2-3.167_1 Reuse Items deposited in White Rose Research Online are protected by copyright, with all rights reserved unless indicated otherwise. They may be downloaded and/or printed for private study, or other acts as permitted by national copyright laws. The publisher or other rights holders may allow further reproduction and re-use of the full text version. This is indicated by the licence information on the White Rose Research Online record for the item. Takedown If you consider content in White Rose Research Online to be in breach of UK law, please notify us by emailing [email protected] including the URL of the record and the reason for the withdrawal request. [email protected] https://eprints.whiterose.ac.uk/ Telematic performance and the challenge of latency Michael Rofe | Federico Reuben Abstract Any attempt to perform music over a network requires engagement with the issue of latency. Either latency needs to be reduced to the point where it is no longer noticeable or creative alternatives to working with latency need to be developed. Given that Online Orchestra aimed to enable performance in community contexts, where significant bandwidth and specialist equipment were not available, it would not be possible to reduce latency below the 20–30ms cut-off at which it becomes noticeable.
    [Show full text]
  • Top Newsql Databases and Features Classification
    International Journal of Database Management Systems ( IJDMS ) Vol.10, No.2, April 2018 TOP NEW SQL DATABASES AND FEATURES CLASSIFICATION Ahmed Almassabi 1, Omar Bawazeer and Salahadin Adam 2 1Department of Computer Science, Najran University, Najran, Saudi Arabia 2Department of Information and Computer Science, King Fahad University of Petroleum and Mineral, Dhahran, Saudi Arabia ABSTRACT Versatility of NewSQL databases is to achieve low latency constrains as well as to reduce cost commodity nodes. Out work emphasize on how big data is addressed through top NewSQL databases considering their features. This NewSQL databases paper conveys some of the top NewSQL databases [54] features collection considering high demand and usage. First part, around 11 NewSQL databases have been investigated for eliciting, comparing and examining their features so that they might assist to observe high hierarchy of NewSQL databases and to reveal their similarities and their differences. Our taxonomy involves four types categories in terms of how NewSQL databases handle, and process big data considering technologies are offered or supported. Advantages and disadvantages are conveyed in this survey for each of NewSQL databases. At second part, we register our findings based on several categories and aspects: first, by our first taxonomy which sees features characteristics are either functional or non-functional. A second taxonomy moved into another aspect regarding data integrity and data manipulation; we found data features classified based on supervised, semi-supervised, or unsupervised. Third taxonomy was about how diverse each single NewSQL database can deal with different types of databases. Surprisingly, Not only do NewSQL databases process regular (raw) data, but also they are stringent enough to afford diverse type of data such as historical and vertical distributed system, real-time, streaming, and timestamp databases.
    [Show full text]