> porting RocksDB Is zOS support upstreamed too, by any chance?
- KB ------- Original Message ------- On Monday, June 5th, 2023 at 4:35 PM, David Crayford <dcrayf...@gmail.com> wrote: > One compelling reason to embrace zFS is its potential for modernization > and facilitating the development of contemporary tools. While > acknowledging the significance of QSAM, VSAM KSDS, and other older > technologies, it is crucial to recognize the advancements made in data > structure formats for disk files since the days of VSAM. In the present > era, LSM-trees have gained popularity for their application in NoSQL > key-value stores, blazing-fast TSDBs, and highly optimized logging systems. > > Attempting to implement an LSM-tree using VSAM would be an arduous > endeavor, bordering on a nightmare. Even with the assistance of Media > Manager, it remains a Herculean task to reconcile these two disparate > technologies. > > I dedicated a couple of hours to porting RocksDB, and the results have > been nothing short of exceptional. It operates seamlessly on z/OS, > demonstrating its prowess and resilience. Another noteworthy aspect of > LSM-trees is their inherent ability to merge and compact while in > operation, eliminating the need for reorgs. > https://github.com/facebook/rocksdb > > https://www.youtube.com/watch?v=I6jB0nM9SKU > > On 5/6/2023 5:55 pm, David Crayford wrote: > > > On 2/6/2023 11:31 pm, René Jansen wrote: > > > > > What I remember of it is that he was convinced it was a lot slower. > > > > He was mistaken! I've tested it out, and QSAM is no match for zFS. You > > can find the details in this gist: > > https://gist.github.com/daveyc/14b45d6d70d8dd9af1848e539d78881f. > > Adding an fsync() call after writing each record barely incurs any > > overhead. zFS, operating with highly optimized Media Manager APIs, > > handles it efficiently. Additionally, zFS functions as a caching file > > system. > > > > I have observed a certain degree of snobbery among many > > traditionalists when it comes to USS. I can recall an incident from > > approximately 15 years ago when I advocated for the use of sqlite in > > one of our products. My boss dismissed the idea, expressing concerns > > that customers might be deterred by using the UNIX file system. > > Consequently, we opted for a VSAM KSDS, despite its inherent > > limitations. Interestingly, it is worth noting that there are now > > numerous IBM z/OS products that embrace sqlite, with some even > > integrating it with HLASM. > > > > > So I told him that nobody forced him not to use QSAM for datasets just > > > because it ran in USS. And it think that is a great asset of it. Just > > > because Unix forces you to have a hierarchical directory system does not > > > mean, in USS, that you need to use it for all I/O. > > > > > > René. > > > > > > > On 2 Jun 2023, at 17:03, Seymour J metzsme...@gmu.edu wrote: > > > > > > > > Dubbing is part of the setup overhead for a task, and only occurs once, > > > > so except for very short tasks it is just noise in measuring > > > > performance. > > > > > > > > As for the general overhead of Unix System Services, the Devil is in > > > > the details. For a comparison to be reasonable, the two programs have > > > > to be using the services in a comparable fashion. Was your COBOL > > > > programmer really comparing the overhead of conventional access methods > > > > to Unix file I/O, or were the numbers drowned out by, e.g., differences > > > > in application logic? > > > > > > > > -- > > > > Shmuel (Seymour J.) Metz > > > > http://mason.gmu.edu/~smetz3 > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
