VLDB 2026 Research / reviewers in the wild / expert
Maria Colgan
dblp:163/3920
· DBLP profile ↗
4ranked-venue papers
0as first author
0since 2021 · last 2016
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Databases, data management, data science and information retrieval · 4
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Databases, data mining, and information retrieval
4 papers |
Database system architecture and tuning · 37% Distributed and cloud data management · 28% Query processing and optimization · 18% |
Topics — the 10 heaviest of 11, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Database system architecture and tuning
main-memory database |
0.7 | 3 | 2016 | Fault-tolerant real-time analytics with distributed Oracle Database In-memory · ICDE 2016 Distributed Architecture of Oracle Database In-memory · Proc. VLDB Endow. 2015 Oracle Database In-Memory: A dual format in-memory database · ICDE 2015 |
Distributed and cloud data management
distributed query processing |
0.5 | 2 | 2016 | Fault-tolerant real-time analytics with distributed Oracle Database In-memory · ICDE 2016 Distributed Architecture of Oracle Database In-memory · Proc. VLDB Endow. 2015 |
Distributed and cloud data management › distributed query processing
fault-tolerant query execution |
0.2 | 1 | 2016 | Fault-tolerant real-time analytics with distributed Oracle Database In-memory · ICDE 2016 |
Query processing and optimization › query execution
in-memory query processing |
0.2 | 1 | 2016 | Accelerating Analytics with Dynamic In-Memory Expressions · Proc. VLDB Endow. 2016 |
Indexing and storage engines › column store
main-memory column store |
0.2 | 1 | 2016 | Accelerating Analytics with Dynamic In-Memory Expressions · Proc. VLDB Endow. 2016 |
Database system architecture and tuning › main-memory database
distributed in-memory database |
0.2 | 1 | 2015 | Distributed Architecture of Oracle Database In-memory · Proc. VLDB Endow. 2015 |
Query processing and optimization
parallel query processing |
0.2 | 1 | 2015 | Distributed Architecture of Oracle Database In-memory · Proc. VLDB Endow. 2015 |
Indexing and storage engines
columnar storage |
0.1 | 1 | 2015 | Oracle Database In-Memory: A dual format in-memory database · ICDE 2015 |
Database system architecture and tuning
hybrid transactional and analytical processing |
0.1 | 1 | 2015 | Distributed Architecture of Oracle Database In-memory · Proc. VLDB Endow. 2015 |
Transaction processing and concurrency control › consistency
transactional consistency |
0.1 | 1 | 2015 | Oracle Database In-Memory: A dual format in-memory database · ICDE 2015 |
Methods — techniques the papers use, named apart from their topics
in-memory storage indexes · 0.2distribution-aware architecture · 0.2column format duplication · 0.2SIMD vector processing · 0.2row-column dual format · 0.2columnar storage · 0.2NUMA-aware execution · 0.2
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2016 | Fault-tolerant real-time analytics with distributed Oracle Database In-memoryabstractModern data management systems are required to address new breeds of OLTAP applications. These applications demand real time analytical insights over massive data volumes not only on dedicated data warehouses but also on live mainstream production environments where data gets continuously ingested and modified. Oracle introduced the Database In-memory Option (DBIM) in 2014 as a unique dual row and column format architecture aimed to address the emerging space of mixed OLTAP applications along with traditional OLAP workloads. The architecture allows both the row format and the column format to be maintained simultaneously with strict transactional consistency. While the row format is persisted in underlying storage, the column format is maintained purely in-memory without incurring additional logging overheads in OLTP. Maintenance of columnar data purely in memory creates the need for distributed data management architectures. Performance of analytics incurs severe regressions in single server architectures during server failures as it takes non-trivial time to recover and rebuild terabytes of in-memory columnar format. A distributed and distribution aware architecture therefore becomes necessary to provide real time high availability of the columnar format for glitch-free in-memory analytic query execution across server failures and additions, besides providing scale out of capacity and compute to address real time throughput requirements over large volumes of in-memory data. In this paper, we will present the high availability aspects of the distributed architecture of Oracle DBIM that includes extremely scaled out application transparent column format duplication mechanism, distributed query execution on duplicated in-memory columnar format, and several scenarios of fault tolerant analytic query execution across the in-memory column format at various stages of redistribution of columnar data during cluster topology changes. Niloy Mukherjee, Shasank Chavan, Maria Colgan, Mike Gleeson, Allison Holloway, Jesse Kamp, Kartik Kulkarni, Tirthankar Lahiri, Juan Loaiza, Neil MacNaughton, Atrayee Mullick, Sujatha Muthulingam, Vivekanandhan Raja, Raunak Rungta |
ICDE | 3 |
| 2016 | Accelerating Analytics with Dynamic In-Memory ExpressionsabstractOracle Database In-Memory (DBIM) accelerates analytic workload performance by orders of magnitude through an in-memory columnar format utilizing techniques such as SIMD vector processing, in-memory storage indexes, and optimized predicate evaluation and aggregation. With Oracle Database 12.2, Database In-Memory is further enhanced to accelerate analytic processing through a novel lightweight mechanism known as Dynamic In-Memory Expressions (DIMEs). The DIME mechanism automatically detects frequently occurring expressions in a query workload, and then creates highly optimized, transactionally consistent, in-memory columnar representations of these expression results. At runtime, queries can directly access these DIMEs, thus avoiding costly expression evaluations. Furthermore, all the optimizations introduced in DBIM can apply directly to DIMEs. Since DIMEs are purely in-memory structures, no changes are required to the underlying tables. We show that DIMEs can reduce query elapsed times by several orders of magnitude without the need for costly pre-computed structures such as computed columns or materialized views or cubes. Aurosish Mishra, Shasank Chavan, Allison Holloway, Tirthankar Lahiri, Zhen Hua Liu, Sunil Chakkappen, Dennis Lui, Vinita Subramanian, Maria Colgan, Jesse Kamp, Niloy Mukherjee, Vineet Marwah |
Proc. VLDB Endow. | 10 |
| 2015 | Oracle Database In-Memory: A dual format in-memory databaseabstractThe Oracle Database In-Memory Option allows Oracle to function as the industry-first dual-format in-memory database. Row formats are ideal for OLTP workloads which typically use indexes to limit their data access to a small set of rows, while column formats are better suited for Analytic operations which typically examine a small number of columns from a large number of rows. Since no single data format is ideal for all types of workloads, our approach was to allow data to be simultaneously maintained in both formats with strict transactional consistency between them. Tirthankar Lahiri, Shasank Chavan, Maria Colgan, Dinesh Das, Amit Ganesh, Mike Gleeson, Sanket Hase, Allison Holloway, Jesse Kamp, Teck-Hua Lee, Juan Loaiza, Neil MacNaughton, Vineet Marwah, Niloy Mukherjee, Atrayee Mullick, Sujatha Muthulingam, Vivekanandhan Raja, Marty Roth, Ekrem Soylemez, Mohamed Zaït |
ICDE | 3 |
| 2015 | Distributed Architecture of Oracle Database In-memoryabstractOver the last few years, the information technology industry has witnessed revolutions in multiple dimensions. Increasing ubiquitous sources of data have posed two connected challenges to data management solutions -- processing unprecedented volumes of data, and providing ad-hoc real-time analysis in mainstream production data stores without compromising regular transactional workload performance. In parallel, computer hardware systems are scaling out elastically, scaling up in the number of processors and cores, and increasing main memory capacity extensively. The data processing challenges combined with the rapid advancement of hardware systems has necessitated the evolution of a new breed of main-memory databases optimized for mixed OLTAP environments and designed to scale. The Oracle RDBMS In-memory Option (DBIM) is an industry-first distributed dual format architecture that allows a database object to be stored in columnar format in main memory highly optimized to break performance barriers in analytic query workloads, simultaneously maintaining transactional consistency with the corresponding OLTP optimized row-major format persisted in storage and accessed through database buffer cache. In this paper, we present the distributed, highly-available, and fault-tolerant architecture of the Oracle DBIM that enables the RDBMS to transparently scale out in a database cluster, both in terms of memory capacity and query processing throughput. We believe that the architecture is unique among all mainstream in-memory databases. It allows complete application-transparent, extremely scalable and automated distribution of Oracle RDBMS objects in-memory across a cluster, as well as across multiple NUMA nodes within a single server. It seamlessly provides distribution awareness to the Oracle SQL execution framework through affinitized fault-tolerant parallel execution within and across servers without explicit optimizer plan changes or query rewrites. Niloy Mukherjee, Shasank Chavan, Maria Colgan, Dinesh Das, Mike Gleeson, Sanket Hase, Allison Holloway, Hui Jin 0001, Jesse Kamp, Kartik Kulkarni, Tirthankar Lahiri, Juan Loaiza, Neil MacNaughton, Vineet Marwah, Atrayee Mullick, Andy Witkowski, Mohamed Zaït |
Proc. VLDB Endow. | 3 |