@article{KlettkeStoerlScherzinger, author = {Klettke, Meike and St{\"o}rl, Uta and Scherzinger, Stefanie}, title = {Herausforderungen bei der Anwendungsentwicklung mit schema-flexiblen NoSQL-Datenbanken}, series = {HMD Praxis der Wirtschaftsinformatik}, volume = {53}, journal = {HMD Praxis der Wirtschaftsinformatik}, number = {4}, publisher = {Springer}, doi = {10.1365/s40702-016-0234-9}, pages = {428 -- 442}, abstract = {NoSQL-Datenbanksysteme sind in den letzten Jahren sehr popul{\"a}r geworden, gute Gr{\"u}nde sprechen f{\"u}r ihren Einsatz: Eine attraktive Eigenschaft vieler Systeme ist ihre Schema-Flexibilit{\"a}t, die insbesondere in der agilen Anwendungsentwicklung Vorteile bietet. Durch horizontale Skalierbarkeit erm{\"o}glichen NoSQL-Datenbanksysteme eine effiziente Verarbeitung großer Datenmengen. Einige Systeme, die f{\"u}r die Datenhaltung interaktiver Anwendungen konzipiert sind, k{\"o}nnen zudem hochfrequente Nutzeranfragen bedienen. Diesen Vorteilen stehen eine Reihe von Nachteilen gegen{\"u}ber, aus denen sich neue Herausforderungen f{\"u}r die Anwendungsentwicklung ergeben: Fehlende Standards bei den Anfragesprachen erschweren die Entwicklung datenbanksystemunabh{\"a}ngiger Anwendungen. Schema-Flexibilit{\"a}t im Datenbankmanagementsystem f{\"u}hrt dazu, dass die Verantwortung f{\"u}r das Schema-Management in die Anwendung verlagert wird. Im vorliegenden Beitrag werden wesentliche Herausforderungen identifiziert und L{\"o}sungsans{\"a}tze aus Forschung und Praxis vorgestellt. Dabei liegt der Fokus auf schema-flexiblen NoSQL-Datenbanksystemen, mit einem aggregat-orientierten Datenmodell, d. h. Key-Value Datenbanksysteme, dokumentenorientierten Datenbanksystemen und Column-Family Datenbanksystemen. NoSQL data stores have become very popular over the last years, as good reasons are justifying their application: One attractive feature of many systems is their schema flexibility, which may be preferable in agile software development projects. Due to their horizontal scalability, NoSQL data stores make it possible to efficiently process large amounts of data. Some systems, designed as data backends for interactive applications, can also manage highly frequent user requests. Apart from these advantages, there are also downsides to NoSQL data stores that create new challenges for software development: Missing standards in query languages make it difficult to build data store independent applications. Schema flexibility in the data store shifts the responsibility for schema management into the application. This article identifies substantial challenges as well as solution statements from research and practice. The focus of our survey is on schema-flexible NoSQL data management systems with an aggregate-oriented data model, i. e., key-value data management systems, as well as document and column family data management systems.}, language = {de} } @inproceedings{KlettkeStoerlShenavaietal., author = {Klettke, Meike and St{\"o}rl, Uta and Shenavai, Manuel and Scherzinger, Stefanie and Storl, Uta}, title = {NoSQL schema evolution and big data migration at scale}, series = {2016 IEEE International Conference on Big Data (Big Data), 5-8 Dec. 2016, Washington, DC}, booktitle = {2016 IEEE International Conference on Big Data (Big Data), 5-8 Dec. 2016, Washington, DC}, publisher = {IEEE}, doi = {10.1109/BigData.2016.7840924}, pages = {2764 -- 2774}, abstract = {This paper explores scalable implementation strategies for carrying out lazy schema evolution in NoSQL data stores. For decades, schema evolution has been an evergreen in database research. Yet new challenges arise in the context of cloud-hosted data backends: With all database reads and writes charged by the provider, migrating the entire data instance eagerly into a new schema can be prohibitively expensive. Thus, lazy migration may be more cost-efficient, as legacy entities are only migrated in case they are actually accessed by the application. Related work has shown that the overhead of migrating data lazily is affordable when a single evolutionary change is carried out, such as adding a new property. In this paper, we focus on long-term schema evolution, where chains of pending schema evolution operations may have to be applied. Chains occur when legacy entities written several application releases back are finally accessed by the application. We discuss strategies for dealing with chains of evolution operations, in particular, the composition into a single, equivalent composite migration that performs the required version jump. Our experiments with MongoDB focus on scalable implementation strategies. Our lineup further compares the number of write operations, and thus, the operational costs of different data migration strategies.}, language = {en} } @inproceedings{ScherzingerSombachWiechetal., author = {Scherzinger, Stefanie and Sombach, Stephanie and Wiech, Katharina and Klettke, Meike and St{\"o}rl, Uta}, title = {Datalution: a tool for continuous schema evolution in NoSQL-backed web applications}, series = {QUDOS 2016: Proceedings of the 2nd International Workshop on Quality-Aware DevOps}, booktitle = {QUDOS 2016: Proceedings of the 2nd International Workshop on Quality-Aware DevOps}, publisher = {ACM}, doi = {10.1145/2945408.2945416}, pages = {38 -- 39}, abstract = {When an incremental release of a web application is deployed, the structure of data already persisted in the production database may no longer match what the application code expects. Traditionally, eager schema migration is called for, where all legacy data is migrated in one go. With the growing popularity of schema-flexible NoSQL data stores, lazy forms of data migration have emerged: Legacy entities are migrated on-the-fly, one at-a-time, when they are loaded by the application. In this demo, we present Datalution, a tool demonstrating the merits of lazy data migration. Datalution can apply chains of pending schema changes, due to its Datalog-based internal representation. The Datalution approach thus ensures that schema evolution, as part of continous deployment, is carried out correctly.}, language = {en} } @article{StoerlKlettkeScherzinger, author = {St{\"o}rl, Uta and Klettke, Meike and Scherzinger, Stefanie}, title = {Kurz erkl{\"a}rt: Objekt-NoSQL-Mapping}, series = {Datenbank-Spektrum}, volume = {16}, journal = {Datenbank-Spektrum}, number = {1}, publisher = {Springer}, doi = {10.1007/s13222-016-0212-y}, pages = {83 -- 87}, language = {de} } @inproceedings{RinglstetterScherzingerBissyande, author = {Ringlstetter, Andreas and Scherzinger, Stefanie and Bissyand{\´e}, Tegawend{\´e} F.}, title = {Data Model Evolution Using Object-NoSQL Mappers: Folklore or State-of-the-Art?}, series = {2016 IEEE/ACM 2nd International Workshop on Big Data Software Engineering (BIGDSE), 16 May 2016, Austin, TX, USA}, booktitle = {2016 IEEE/ACM 2nd International Workshop on Big Data Software Engineering (BIGDSE), 16 May 2016, Austin, TX, USA}, publisher = {ACM}, doi = {10.1145/2896825.2896827}, pages = {33 -- 36}, abstract = {In big data software engineering, the schema flexibility of NoSQL document stores is a major selling point: When the document store itself does not actively manage a schema, the data model is maintained within the application. Just like object-relational mappers for relational databases, object-NoSQL mappers are part of professional software development with NoSQL document stores. Some mappers go beyond merely loading and storing Java objects: Using dedicated evolution annotations, developers may conveniently add, remove, or rename attributes from stored objects, and also conduct more complex transformations. In this paper, we analyze the dissemination of this technology in Java open source projects. While we find evidence on GitHub that evolution annotations are indeed being used, developers do not employ them so much for evolving the data model, but to solve different tasks instead. Our observations trigger interesting questions for further research.}, language = {en} }