Logo des Repositoriums

Auflistung nach Autor:in "Glombiewski, Nikolaus"

1 - 4 von 4
  • Zeitschriftenartikel
    Designing an Event Store for a Modern Three-layer Storage Hierarchy
    (Datenbank-Spektrum: Vol. 20, No. 3, 2020) Glombiewski, Nikolaus; Götze, Philipp; Körber, Michael; Morgen, Andreas; Seeger, Bernhard
    Event stores face the difficult challenge of continuously ingesting massive temporal data streams while satisfying demanding query and recovery requirements. Many of today’s systems deal with multiple hardware-based trade-offs. For instance, long-term storage solutions balance keeping data in cheap secondary media (SSDs, HDDs) and performance-oriented main-memory caches. As an alternative, in-memory systems focus on performance, while sacrificing monetary costs, and, to some degree, recovery guarantees. The advent of persistent memory (PMem) led to a multitude of novel research proposals aiming to alleviate those trade-offs in various fields. So far, however, there is no proposal for a PMem-powered specialized event store. Based on ChronicleDB, we will present several complementary approaches for a three-layer architecture featuring main memory, PMem, and secondary storage. We enhance some of ChronicleDB’s components with PMem for better insertion and query performance as well as better recovery guarantees. At the same time, the three-layer architecture aims to keep the overall dollar cost of a system low. The limitations and opportunities of a PMem-enhanced event store serve as important groundwork for comprehensive system design exploiting a modern storage hierarchy.
  • Konferenzbeitrag
    Event processing on your own database
    (Datenbanksysteme für Business, Technologie und Web (BTW) 2013 - Workshopband, 2013) Glombiewski, Nikolaus; Hoßbach, Bastian; Morgen, Andreas; Ritter, Franz; Seeger, Bernhard
    Event processing (EP) is widely used for reacting on events in the very moment when they occur. Events that require immediate reactions can be found in various applications, e.g. algorithmic trading, business process monitoring and sensorbased human-computer interaction. For the support of EP in an application, a specialpurpose EP system with its own API and query language has to be used. Typically, EP systems as well as their integration in applications are expensive. In this paper, we show how every standard database system can be used as an EP system via JDBC. An experimental evaluation proofs that databases behind JDBC are able to support small and medium-sized EP workloads.
  • Zeitschriftenartikel
    JEPC: The Java Event Processing Connectivity
    (Datenbank-Spektrum: Vol. 13, No. 3, 2013) Hoßbach, Bastian; Glombiewski, Nikolaus; Morgen, Andreas; Ritter, Franz; Seeger, Bernhard
    Today, event processing (EP) is the first choice technology for analyzing massive event streams in a timely manner. EP allows to detect user-defined situations of interest, like in streaming position events for example, in near real-time such that actions can be taken immediately. Unfortunately, each specific EP system has its very own API and query language because there are no standards. The exchange of EP systems as well as their use within a federation is challenging, error-prone, and expensive. To overcome these problems, we introduce the Java Event Processing Connectivity (JEPC) that is a middleware for uniform EP functionality in Java. JEPC provides always the same API and query language for EP completely independent of the EP system beneath. Furthermore, we show in detail how JEPC can integrate database systems besides EP systems and evaluate the performance of EP powered by databases systems.
  • Textdokument
    Waves of Misery After Index Creation
    (BTW 2019, 2019) Glombiewski, Nikolaus; Seeger, Bernhard; Graefe, Goetz
    After creation of a new b-tree, the ordinary course of database updates and index maintenance causes waves of node splits. Thus, a new index may at first speed up database query processing but then the first “wave of misery” requires effort for frequent node splits and imposes spikes of buffer pool contention and of I/O. Waves of misery continue over multiple instances although eventually the waves widen, flatten, and spread further apart. Free space in each node left during index creation fails to prevent the problem; it merely delays the onset of the first wave. We have found a theoretically sound way to avoiding these waves of misery as well as some simple and practical means to reduce their amplitude to negligible levels. Experiments demonstrate that these techniques are also effective. Waves of misery occur in databases and in key-value stores, in primary and in secondary b-tree indexes, after load operations, and after b-tree reorganization or rebuild. The same remedies apply with equal effect.