@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{StoerlTekleabKlettkeetal., author = {St{\"o}rl, Uta and Tekleab, Alexander and Klettke, Meike and Scherzinger, Stefanie and Storl, Uta}, title = {In for a Surprise When Migrating NoSQL Data}, series = {2018 IEEE 34th International Conference on Data Engineering (ICDE), 16-19 April 2018, Paris, France}, booktitle = {2018 IEEE 34th International Conference on Data Engineering (ICDE), 16-19 April 2018, Paris, France}, publisher = {IEEE}, doi = {10.1109/ICDE.2018.00202}, pages = {1662}, abstract = {Schema-flexible NoSQL data stores lend themselves nicely for storing versioned data, a product of schema evolution. In this lightning talk, we apply pending schema changes to records that have been persisted several schema versions back. We present first experiments with MongoDB and Cassandra, where we explore the trade-off between applying chains of pending changes stepwise (one after the other), and as composite operations. Contrary to intuition, composite migration is not necessarily faster. The culprit is the computational overhead for deriving the compositions. However, caching composition formulae achieves a speed up: For Cassandra, we can cut the runtime by nearly 80\%. Surprisingly, the relative speedup seems to be system-dependent. Our take away message is that in applying pending schema changes in NoSQL data stores, we need to base our design decisions on experimental evidence rather than on intuition alone.}, language = {en} }