We focus on versioning for NoSQL data on MongoDB. Versioning is essential for security audits, legal compliance and business strategy development. For each type of business object, we maintain two collections and split the data into currently valid objects and the archive. We previously presented a versioning algorithm and a preliminary evaluation on a local database, with version write times of 4 to 13ms, and versioning queries in 2 to 4ms. Here, we introduce bulk operations and present a performance study measuring all versioning operations on MongoDB Atlas. Cloud experiments show that version writes take 14 to 60ms. Queries need between 14 and 25ms. Using bulk versioning is faster, as writes need between 3 and 10ms. Cloud times are slower than those seen in local tests but the performance penalty due to network latency, imposed by the use of Atlas, is mitigated by the newly added bulk operations. Overall, the experiments show that the performance is satisfactory for an enterprise resource planning (ERP) system for small and medium enterprises (SMEs).
or not at all. As our business partner selected MongoDB We are working on an ERP system for an SME which as the platform, we decided to add versioning directly has to comply with the legal requirement of keeping old instead of using another tool as an archive, which would data for ten years. This requirement has led us to ex- make business intelligence hard to orchestrate. Although plore versioning. Adding versioning to a business system some DBMSs ofer built-in data versioning, in most cases, enables queries that typically belong to the data ware- the versioning support is not suficient for compliance [ 3] housing scenario and support business in reporting and and data warehousing solutions are used [4, 5]. Mainstrategy development. When a legal requirement has to stream NoSQL DBMSs, including MongoDB [6], only be fulfilled, the data can be queried flexibly. provide limited support for data versioning [7].
Data versioning and archival are important aspects of Here, we extend our previous work [8] where we predatabase (DB) operations. Bernstein and Goodman [1] sented a versioning algorithm which ensures that the define a multi-version DB as one where each write on a query time on the currently valid document versions is data item produces a new copy (or version) of and for kept constant, by storing historical data in a separate each read on , the DB management system (DBMS) se- collection. lects one of the versions of to be read. Stonebraker and Earlier steps in this development were presented in [9] Rowe [2] outlined three types of versioning: no archive where we showed that the ERP fits the business use case. where no historical access to a relation is needed, light Our contributions here are: (1) performance tests on Monarchive where archival is needed but this data will rarely goDB Atlas cluster executing single document versioning be accessed, and heavy archive when the system needs to and comparison to local performance we presented in [8], look up and update timestamps of previous transactions. (2) a bulk versioning algorithm which extends the range In an ERP, we expect to see no archive for business ob- of DB operations for MongoDB and uses transactions to jects that do not change and light archive for compliance, support bulk requests, and (3) performance measurement security and strategy queries. We do not see a need for a of bulk INSERT, UPDATE, and DELETE on MongoDB heavy archive. Atlas and comparison with single document versioning.
Our ERP has versioning as a primary business requirement. Part of the data, such as customer or product details, will change, which is why versioning is required. 2. Related work Archival storage systems usually do not support flexible querying while software versioning systems ofer queries based on taxonomies or text, but support no query language. Version control in most collaborative tools does not ofer support for business data analysis or legal comrelations have been researched extensively [1, 2, 10, 11] Our solution relies on Mongoose [19]. Once the docuand produced several interesting systems like ODM ment model has been defined using Mongoose, the verInsights [12]. Most NoSQL work focuses on schema sioning plugin is added. It generates the two collections changes [13, 14] and not on the data itself. and adds the versioning related fields. Our implementa
Here, we study data versioning and not schema ver- tion is available at [20, 21]. The plugin ofers two query sioning. Despite advances in data versioning, none of methods: findVersion (id, version) and findValidVersion the prior systems fits our use scenario. The only publicly (id, date) based on validity date. known document versioning library for MongoDB is Ver- Transactions are used in updates and deletes to guarmongo [15, 16]. The core idea we adopt from Vermongo antee operation atomicity, as they afect both the main is to store the current and past document versions sep- and shadow collections. In contrast to Vermongo, which arately as only the current data are of business interest does not ofer ACID guarantees, our implementation uses on a daily basis. However, Vermongo has the following MongoDB transactions. Transactions are not needed for deficiencies which make it unsuitable for ERP: no ACID inserts which only afect the main collection. Transacguarantees, no support for DBRefs which correspond to tions are handled by the user and passed to the versioning foreign keys in a relational DB and no support for mul- library for each enveloped operation. tiple CRUD operations defined by Mongoose, such as updateOne and updateMany.
1. On create, a new document is written to the main collection. 2. On update, a new version is written to the main collection and the previous version is moved to the shadow collection, within a transaction. 3. On delete, the invalid version is moved to the shadow collection, within a transaction. 4. On read, both main and shadow collections can be queried.
and executed those in groups of 10K, with 10K valid documents at any time. The experiment took approximately The evaluation scenario mimics a use case of a human 72 hours. resources (HR) ERP system and is carried out on two We carried out a second cloud experiment to test bulk types of infrastructure: a local machine, as in our previ- operations. Here, insert, update, and delete were reous paper [8] and in the cloud (MongoDB Atlas cluster). placed with their bulk versions called InsertMany, UpWe compare the performance of three approaches: no dateMany, and DeleteMany. Each operation was perversioning, plain versioning without using a shadow col- formed on a group of documents sent as a single data lection (all data, current and old in one collection), and chunk to the cloud, using two chunk sizes of 50 and 200 our versioning which uses two collections, as outlined operations. previously. HR data have an average size of 2.3K per document holding complex nested documents and document 5.1. Local Single Operations versus Cloud arrays storing personal data, skills, projects and similar.
The local infrastructure is described in our previous Performance on a local DB is detailed in [8]. The cloud paper [8]. The cloud tests were submitted from a Linux experiment repeats the local experiment on the Monserver cluster (8GB RAM, 2 virtual CPUs and 20GB Disk goDB Atlas cluster. The experiment size was reduced with Ubuntu Jammy 22.04) which invoked DB operations from 1M to 100K operations of each type (Insert, Upon an M10 Atlas cluster with MongoDB version 4.2.17 date, Delete, FVaNow, FVaPast, FVe1 and FVe2) and Enterprise, a replica set composed of three nodes with the group size from 100K to 10K. Figure 1 compares local the default DB configuration. Some system background versioning performance to cloud performance. tasks may afect results but should be similar for all tests.
PMeornfogromoasencAePwIcaasllm,ienacsluurdeidngatatthraenaspapcltiicoantiwonhelerevenle,evdiaeda, 60 60.13 CLOUD ssionlucetitohnedseosfitgwnatrheaitnntreoedduscteosbaenroepveorrhteeda,daisnrheeproernttintog tthhee 50 44.35 LOCAL times from MongoDB directly does not correspond to our )sm40 use case scenario. The experiments can be reproduced it(em30 25.11 24.84 22.38 usiWnge tthesetceoddteheavfoailllaobwleinagt o[p2e2r]a. tions: 20 16.23 12.34 13.78 13.77 • INSERT a new document • UPDATE an existing document • DELETE an existing document • FVaNOW: find the current version by object id • FVaPAST: find a past version by id and date • FVe2: find current version by id and version no. • FVe1: find past version by id and version no. • FIND: find by non-indexed field on currently valid
documents.
The operations were executed in groups of 100K in the local experiment as in [8] and 10K for the cloud. The order in the list represents the execution order inside each group of 100K (or 10K) and the group size corresponds to the maximum number of valid documents at any time point, corresponding to an HR system for a company with a constant employee count.
In the local experiment reported in [8], one million operations of each type were executed in groups of 100K lasting approximately 60 hours. There were 100K valid documents at any time.
As the cloud evaluation which aimed to replicate the local experiment took much longer per operation, we reduced the number of operations of each type to 100K 10 0 3.26
T R E S N I
E T A D P U
deletes are the slowest, as they involve writes in both the main and the shadow collection wrapped in a transaction spanning both collections. The times are adequate for an SME ERP and even the slowest operation, the Update, needs 12-13 ms on average locally and 60 ms in the cloud, which is acceptable [23].
Figure 2 shows the details of the cloud measurements. Updates and deletes are the slowest, and the relative performance of all the operations is similar to the local performance presented in [8], except that all the single cloud operations are significantly slower in the Atlas cluster, which we interpret as network latency efect. The performance is nevertheless adequate for our use case, troduces an acceptable overhead and our versioning has a better and more stable performance than using a single collection to store both current and past document versions.
102 ) s (m101 g o l 0
SINGLE BULK_50
BULK_200
Versioning
Plain Vers. and even the slowest operation, the Update, needs about 60ms. The three approaches (Versioning, Plain Versioning and No Versioning) show a similar pattern to that seen when using a local DB (Figure 2). The Update 5.2. Cloud Bulk Operations is faster than an update using plain versioning with just one main collection. The overhead of versioning in com- Figure 3 compares the cloud use of our versioning soparison to no versioning during an update is around 33.4 lution with single operations (as in previous section) to ms. Plain versioning using a single collection gives a the use of the new bulk writes using chunks of 50 and faster Delete than our versioning, by about 28 ms. 200 operations. The total number of equivalent individ
As in the local experiment, other operations perform ual operations is the same, 100K for each operation type similarly to plain versioning, with the exception of Find executed in groups of 10K. which searches for an unindexed field and causes a collec- As shown in Figure 3, the bulk writes (insert, update tion scan. Find in our versioning needs as long as a Find and delete) are significantly faster than single writes. The with no versioning, i.e. versioning produces no overhead. improvement is more pronounced for the 200 documents However, in plain versioning a Find is extremely slow, chunk size than when using groups of only 50 documents. 594 ms, as all versions are kept together and the collection The read methods do not have a bulk mode and are not is very large. This confirms our expectation that our so- shown. Bulk Insert is more than 5 times faster than a lution using a cloud DB has similar performance in most single insert while the bulk Update gets close to being operations and performs better for current documents. 8 times faster for 200 documents as compared to single.
The cloud queries on valid documents show similar Bulk Delete takes four times less time than the single execution times with and without versioning. Regarding document, even for the 50 document size. Bulk operation comparison with plain versioning, Figure 2 shows that times for 200 documents are 8 percent shorter on average our solution takes slightly longer to retrieve past versions than the ones on 50 documents. (FVe1 and FVaPast, but performs better when querying currently valid documents which are the most commonly performed operations, resulting in a better versioning 6. Conclusions performance on the expected use scenario. We presented a new solution for data versioning, tested
The performance of all cloud operations mirrors the it locally [8] and in the cloud on MongoDB Atlas and exlocal experiment, see [8], so Plain Versioning perfor- tended it with bulk operations. Versioning performance mance over time of the Find operation looks like a stair- was satisfactory for our business scenario in both the case, with each step corresponding to a new group of 10K local and the cloud settings. This good performance can operations (not shown due to space constraints) whereas support a flexible and adaptable ERP system and is being in our versioning solution the Find operation perfor- used in the system prototype. mance stays stable (not shown). We designed and implemented a NodeJS library to
Overall, the measurements confirm that the cloud in- manage many document versions by splitting the documents into two collections: live data (main collection) [7] P. Felber, M. Pasin, E. Rivière, V. Schiavoni, P. Sutra, and archival data (shadow collection). Data consistency F. Coelho, M. Matos, R. Oliveira, R. Vilaça, On is maintained by the use of transactions when required, the support of versioning in distributed key-value that is for update and delete. Inserts and queries require stores, in: IEEE SRDS, 2014, pp. 95–104. no transactions. Splitting the data into two collections [8] L. de Espona Pernas, E. Pustulka, Document Verguarantees good performance on live data, and our tests sioning for MongoDB, in: ADBIS’22, MegaData, show clearly that this is superior to keeping old data Springer, 2022, pp. 512–524. together with the current data. [9] E. Pustulka, S. von Arx, L. de Espona, Building
We compared the performance of our solution to two a NoSQL ERP, in: ICICT’22, Springer, 2023, pp. alternatives, plain versioning (all data in one collection) 671–680. and no versioning. We showed clearly that our version- [10] E. Sciore, Versioning and configuration manageing performs well enough to be used in production, using ment in an object-oriented data model, The VLDB a local or a cloud DB. Despite a small performance over- Journal 3 (1994) 77–106. head of keeping historical data, we show performance [11] J. F. Roddick, Schema Versioning, in: Encyclopedia gains on querying current document versions even in of Database Systems, 2nd Ed., Springer, 2018. non indexed fields, as compared to a solution that does [12] F. Chirigati, J. Siméon, M. Hirzel, J. Freire, Virtual not separate the data into two collections. lightweight snapshots for consistent analytics in
The bulk writes we added reduce the number of calls nosql stores, in: ICDE’2016, 2016, pp. 1310–1321. to the DB when inserting, updating and deleting. The [13] U. Störl, M. Klettke, S. Scherzinger, NoSQL Schema performance of bulk operations using groups of 200 doc- Evolution and Data Migration: State-of-the-Art and uments reduces the network latency overhead signifi- Opportunities, in: EDBT’20, 2020, pp. 655–658. cantly, so that the average performance in the cloud is [14] D. Sevilla Ruiz, S. F. Morales, J. García Molina, Inclose to the local DB execution using single operations. ferring Versioned Schemas from NoSQL Databases
Further work is required to investigate the impact of and Its Applications, in: Conceptual Modeling, versioning using real business data and processes. Our Springer, 2015, pp. 467–480. ongoing work focuses on automated indexing and ma- [15] T. Planz, Vermongo: Simple Document Versionchine learning for index selection. ing with MongoDB, 2012. URL: https://github.com/ thiloplanz/v7files/wiki/Vermongo. [16] M. Sutunc, Vermongo Mongoose Plugin, Acknowledgments 2016. URL: https://www.npmjs.com/package/ mongoose-vermongo.
Thanks to Florian Lang, Christian Dolfus and Martin [17] D. Coupal, K. W. Alger, Building with PatSterchi for their contributions. We acknowledge funding terns: The Document Versioning Pattern, 2019. from www.innosuisse.ch, Grant No. 44824.1 IP-ICT. We https://www.mongodb.com/blog/post/buildinghave no conflicts of interest to disclose. with-patterns-the-document-versioning- pattern. [18] X. Jin, D. Agun, T. Yang, Q. Wu, Y. Shen, S. Zhao, References Hybrid Indexing for Versioned Document Search with Cluster-Based Retrieval, in: CIKM’16, ACM, [1] P. A. Bernstein, N. Goodman, Multiversion Con- 2016, p. 377–386.
currency Control—Theory and Algorithms, ACM [19] LearnBoost, Mongoose, 2010. URL: https://www.
Trans. Database Syst. 8 (1983) 465–483. npmjs.com/package/mongoose. [2] M. Stonebraker, L. A. Rowe, The Design of POST- [20] L. De Espona, Versioning MongoDB Reposi
GRES, in: SIGMOD’86, ACM, 1986, p. 340–355. tory, 2021. URL: https://github.com/pier4all/ [3] C. Cioranu, M. Cioca, C. Novac, Database Ver- mongoose-versioned.
sioning 2.0, a Transparent SQL Approach Used in [21] L. De Espona, Versioning Module MongoDB, Quantitative Management and Decision Making, 2021. URL: https://www.npmjs.com/package/ Procedia Computer Science 55 (2015) 523–528. mongoose-versioned. [4] H.-G. Kang, C.-W. Chung, Exploiting Versions for [22] L. De Espona, Data Versioning Experiment On-Line Data Warehouse Maintenance in MOLAP Repository, 2021. URL: https://github.com/pier4all/ Servers, in: VLDB ’02, 2002, p. 742–753. data-versioning. [5] B. Bebel, J. Eder, C. Koncilia, T. Morzy, R. Wrembel, [23] J. Nielsen, Usability engineering, Morgan KaufCreation and management of versions in multiver- mann, 1994.
sion data warehouse, in: SAC ’04, 2004, p. 717–723. [6] MongoDB, www.mongodb.com, 2021.