Oracle Database In-Memory: A dual format in-memory database

Lahiri, Tirthankar; Chavan, Shasank; Colgan, Maria; Das, Dinesh; Ganesh, Amit; Gleeson, Mike; Hase, Sanket; Holloway, Allison; Kamp, Jesse; Lee, Teck-Hua; Loaiza, Juan; Macnaughton, Neil; Marwah, Vineet; Mukherjee, Nilanjana; Mullick, Atrayee; Muthulingam, Sujatha; Raja, Vivekanandhan; Roth, Marty; Soylemez, Ekrem; Zaït, Mohamed

doi:10.1109/icde.2015.7113373

Cited by 84 publications

(77 citation statements)

References 4 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Most column-stores use dictionary encoding such as Microsoft SQL Server [21], IBM DB2 BLU [30], Oracle [18], and MonetDB [26]. Our analysis can also extend to columns without a dictionary.…”

Section: Discussion and Outlookmentioning

confidence: 99%

“…All columns are split into the parts defined by the PP. PP is useful for improving the performance through pruning, i.e., skipping a part if it is excluded by the query predicate, and for moving parts in a distributed environment (see, e.g., SAP HANA [4] and Oracle [18]). In this paper, we use PP to place each part on a different socket.…”

Section: Physical Partitioning (Pp)mentioning

confidence: 99%

“…The data of an uncompressed column can be stored sequentially in a vector in main-memory [14,18,21,23]. Compression techniques are typically employed to reduce the amount of consumed memory, and potentially speed up processing.…”

Section: Main-memory Column-storesmentioning

confidence: 99%

“…PP can use a hash function on a set of columns, a range partitioning on a column, or a simple round-robin scheme [4,18]. All columns are split into the parts defined by the PP.…”

Section: Physical Partitioning (Pp)mentioning

confidence: 99%

“…The key comparative criterion for analytical relational database management systems (DBMS) is their efficiency in servicing numerous clients on big data. For this reason, many analytical DBMS, e.g., SAP HANA [14] or Oracle [18] (see Section 3 for additional examples), opt for a mainmemory column-store instead of a disk-based row-store typically employed for OLTP workloads [32]. The column-wise in-memory representation minimizes the amount of data to read, as only the necessary columns are accessed.…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Scaling up concurrent main-memory column-store scans

et al. 2015

View full text Add to dashboard Cite

Main-memory column-stores are called to efficiently use modern non-uniform memory access (NUMA) architectures to service concurrent clients on big data. The efficient usage of NUMA architectures depends on the data placement and scheduling strategy of the column-store. Most column-stores choose a static strategy that involves partitioning all data across the NUMA architecture, and employing a stealingbased task scheduler. In this paper, we implement different strategies for data placement and task scheduling for the case of concurrent scans. We compare these strategies with an extensive sensitivity analysis. Our most significant findings include that unnecessary partitioning can hurt throughput by up to 70%, and that stealing memory-intensive tasks can hurt throughput by up to 58%. Based on our analysis, we envision a design that adapts the data placement and task scheduling strategy to the workload.

show abstract

Section: Discussion and Outlookmentioning

confidence: 99%

Section: Physical Partitioning (Pp)mentioning

confidence: 99%

Section: Main-memory Column-storesmentioning

confidence: 99%

“…PP can use a hash function on a set of columns, a range partitioning on a column, or a simple round-robin scheme [4,18]. All columns are split into the parts defined by the PP.…”

Section: Physical Partitioning (Pp)mentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Scaling up concurrent main-memory column-store scans

et al. 2015

View full text Add to dashboard Cite

show abstract

Multi-model Database Management Systems - A Look Forward

Liu

Gawlick

et al. 2019

Heterogeneous Data Management, Polystores, and Analytics for Healthcare

View full text Add to dashboard Cite

The existence of the variety of data models and their associated data processing technologies make data management extremely complex. In this paper, we envision a single Multi-Model DataBase Management Systems (MMDBMS) providing declarative accesses to a variety of data models. We briefly review the history of the evolution of the DBMS technology to derive requirements of MMDBMSs and then we illustrate our ideas of building MMDBMSs satisfying those requirements. Since the relational algebra is not powerful enough to provide a mathematical foundation for MMDBMSs, we promote the category theory as a new theoretical foundation, which is a generalization of the set theory. We also suggest a set of shared data infrastructure services among data models to support "Just-In-Time" multi-model data access autonomously.

show abstract