Author
Listed:
- Baya Chalabi
(Laboratoire de la Communication dans les Systèmes Informatiques, Ecole Nationale Supérieure d’Informatique, BP 68M, Oued-Smar, Alger 16309, Algeria)
- Yahya Slimani
(Institut Supérieur des Art Multimédias de la Manouba, Uiversité de la Manouba, Manouba 2010, Tunisia)
Abstract
With the emergence of data-intensive computing, which is due to the growth of the data produced and generated each day, it became necessary to store and manage big data. Cloud data storage is actually the best choice for large distributed systems. Successful Cloud Computing cannot be achieved without a reliable data-management system to store and handle the enormous volume of data. Management of the available storage system at large scale becomes progressively more complicated, and we face many challenges, such as scalability, data availability, fault tolerance, etc. Also, data storage is faced with specific access patterns: highly concurrent reads of data from the same file, many overwrites, and very concurrent appends to the same file. Most of the existing storage systems use versioning to bring and enhance data access parallelism and this enables better performance levels under concurrency; but, generally, these systems use one component (version manager), which is responsible for generating new versions of each file stored. When we speak in the context of big data, the requests for read, write and append increase. If these requests are managed by a single component, then we have a performance bottleneck and an overloaded version manager. To avoid this drawback, we proposed and designed a new architecture of storage systems that uses versioning; the new architecture uses multi-version managers to support better the scalability and provide partial fault tolerance. To illustrate the practicability of our approach, we assessed it on the BlobSeer data-management system. The experimental results demonstrate that our architecture achieves near-linear scalability for CREATE operations (495 ops/s per additional version manager), reduces WRITE execution time by up to 66%, and maintains 67% availability under single-node failures, all while introducing minimal resource overhead (3% aggregate CPU increase). These results confirm that the proposed multi-version manager architecture offers a practical, scalable, and partially fault-tolerant solution for Cloud data-storage systems.
Suggested Citation
Baya Chalabi & Yahya Slimani, 2026.
"Multi-Version Managers for Large Scalable Data-Management Systems,"
Future Internet, MDPI, vol. 18(7), pages 1-24, July.
Handle:
RePEc:gam:jftint:v:18:y:2026:i:7:p:358-:d:1989891
Download full text from publisher
Corrections
All material on this site has been provided by the respective publishers and authors. You can help correct errors and omissions. When requesting a correction, please mention this item's handle: RePEc:gam:jftint:v:18:y:2026:i:7:p:358-:d:1989891. See general information about how to correct material in RePEc.
If you have authored this item and are not yet registered with RePEc, we encourage you to do it here. This allows to link your profile to this item. It also allows you to accept potential citations to this item that we are uncertain about.
We have no bibliographic references for this item. You can help adding them by using this form .
If you know of missing items citing this one, you can help us creating those links by adding the relevant references in the same way as above, for each refering item. If you are a registered author of this item, you may also want to check the "citations" tab in your RePEc Author Service profile, as there may be some citations waiting for confirmation.
For technical questions regarding this item, or to correct its authors, title, abstract, bibliographic or download information, contact: MDPI Indexing Manager The email address of this maintainer does not seem to be valid anymore. Please ask MDPI Indexing Manager to update the entry or send us the correct address
(email available below). General contact details of provider: https://www.mdpi.com .
Please note that corrections may take a couple of weeks to filter through
the various RePEc services.