Untitled

Hupfeld, Felix; Cortés, Toni; Kolbeck, Björn; Stender, Jan; Focht, Erich; Hess, Matthias; Malo, Jesús; Marti, Jonathan; Cesario, Eugenio

doi:10.1002/cpe.v20:17

Cited by 27 publications

(7 citation statements)

References 106 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In [30], authors present ParGRES, which is a middleware that implements the AVP technique. Kotowski et al [19] present the GParGRES middleware, which is a wrapper to enable the use of ParGRES in grids. GParGRES replicates the entire database into participating nodes.…”

Section: Query Scheduling and Dynamic Replication In Distributed Datamentioning

confidence: 99%

Quality of experience in distributed databases

Costa

Furtado

2011

Distrib Parallel Databases

View full text Add to dashboard Cite

This paper proposes an approach to improve the level of Quality of Experience (QoE) that distributed database systems provide.Quality of Experience is a measure of users' satisfaction when using a certain service or application. Therefore, the main objective of this paper is to provide mechanisms to increase users' satisfaction when accessing distributed database systems.In traditional database systems, users cannot specify execution-related constraints. Then, the database system cannot evaluate if user expectations are satisfied and neither the system can take corrective actions when necessary.In this work, we present the QoE-oriented distributed database system (QoE-DDB). It allow users to specify Data Access Requirements (DARs) and aims to please users by satisfying the DARs they define. We define a set of types of Data Access Requirements and propose some SQL extensions that enable users to specify execution-related requirements. Proposed types of DARs include execution deadline and priority, execution start and finish times, data availability and freshness degrees, and disconnected execution mode.In our QoE-DDB, each user's command is transformed into one or more tasks that are executed by data services. Community modules and local data services negotiate Service Level Objectives (SLOs) for each task, which improves the system's dependability. We propose both QoE-oriented scheduling and dynamic data placement strategies. Proposed architecture and scheduling strategies enable the system to be used in a wide range of distributed environments, from tightly-coupled homogeneous environments (e.g. composed by off-the-shelf computers connected by a LAN) Communicated by Amit Sheth. R.L.d.C. Costa ( ) · P. Furtado 362 Distrib Parallel Databases (2011) 29:361-396 to highly heterogeneous and geographically distributed systems, where data services have some degree of autonomy.Traditional performance indicators (e.g. throughput and response time) are not adequate to measure the QoE a system provides. We also propose some specialized Key Performance Indicators (KPIs) to estimate the QoE level a database system provides.Finally, we present experimental results obtained through the use of benchmark data and queries together with a prototype that implements proposed strategies. In our experiments, we consider realistic scenarios and compare proposed scheduling strategies with their best-effort oriented counterparts. Obtained results prove the importance of our QoE-oriented approach.

show abstract

Section: Query Scheduling and Dynamic Replication In Distributed Datamentioning

confidence: 99%

Quality of experience in distributed databases

Costa

Furtado

2011

Distrib Parallel Databases

View full text Add to dashboard Cite

show abstract

“…Widely used distributed file systems such as Lustre [108], GlusterFS [79], OrangeFS [31], BeeGFS [98], XtreemFS [44], and (until recently) Ceph [103] rely on general local file systems, such as ext4 and XFS, to implement their storage backends. While different systems require different features from a storage backend, two of these features, (1) efficient transactions and (2) fast metadata operations appear to be common; another emerging requirement is (3) support for novel, backward-incompatible storage hardware.…”

Section: Essentials Of Distributed Storage Backendsmentioning

confidence: 99%

“…Transaction support in the storage backend simplifies implementing strong consistency that many distributed file systems provide [44,79,103,108]. A storage backend can seamlessly provide transactions if the backing file system already supports them [58,82].…”

Section: Essentials Of Distributed Storage Backendsmentioning

confidence: 99%

See 1 more Smart Citation

The Case for Custom Storage Backends in Distributed Storage Systems

et al. 2020

View full text Add to dashboard Cite

For a decade, the Ceph distributed file system followed the conventional wisdom of building its storage backend on top of local file systems. This is a preferred choice for most distributed file systems today, because it allows them to benefit from the convenience and maturity of battle-tested code. Ceph's experience, however, shows that this comes at a high price. First, developing a zero-overhead transaction mechanism is challenging. Second, metadata performance at the local level can significantly affect performance at the distributed level. Third, supporting emerging storage hardware is painstakingly slow. Ceph addressed these issues with BlueStore, a new backend designed to run directly on raw storage devices. In only two years since its inception, BlueStore outperformed previous established backends and is adopted by 70% of users in production. By running in user space and fully controlling the I/O stack, it has enabled spaceefficient metadata and data checksums, fast overwrites of erasure-coded data, inline compression, decreased performance variability, and avoided a series of performance pitfalls of local file systems. Finally, it makes the adoption of backward-incompatible storage hardware possible, an important trait in a changing storage landscape that is learning to embrace hardware diversity.

show abstract

“…Traditionally distributed file systems have used local file systems, such as ext4 or XFS, directly or through middleware, as the storage backend [29,34,37,41,74,84,93,98,101,102]. This approach has delivered reasonable performance, precluding questions on the suitability of file systems as a distributed storage backend.…”

Section: Introductionmentioning

confidence: 99%

File systems unfit as distributed storage backends

Aghayev

Weil

Kuchnik

et al. 2019

Proceedings of the 27th ACM Symposium on Operating Systems Principles

View full text Add to dashboard Cite

For a decade, the Ceph distributed file system followed the conventional wisdom of building its storage backend on top of local file systems. This is a preferred choice for most distributed file systems today because it allows them to benefit from the convenience and maturity of battle-tested code. Ceph's experience, however, shows that this comes at a high price. First, developing a zero-overhead transaction mechanism is challenging. Second, metadata performance at the local level can significantly affect performance at the distributed level. Third, supporting emerging storage hardware is painstakingly slow. Ceph addressed these issues with BlueStore, a new backend designed to run directly on raw storage devices. In only two years since its inception, BlueStore outperformed previous established backends and is adopted by 70% of users in production. By running in user space and fully controlling the I/O stack, it has enabled space-efficient metadata and data checksums, fast overwrites of erasure-coded data, inline compression, decreased performance variability, and avoided a series of performance pitfalls of local file systems. Finally, it makes the adoption of backwards-incompatible storage hardware possible, an important trait in a changing storage landscape that is learning to embrace hardware diversity. CCS Concepts • Information systems → Distributed storage; • Software and its engineering → File systems management; Software performance.

show abstract

Untitled

Cited by 27 publications

References 106 publications

Quality of experience in distributed databases

Quality of experience in distributed databases

The Case for Custom Storage Backends in Distributed Storage Systems

File systems unfit as distributed storage backends

Contact Info

Product

Resources

About