https://en.wikipedia.org/wiki/ISAM
https://en.wikipedia.org/wiki/Record_Management_Services
They were more like BerkeleyDB and lacked Query Planner.
I think Oracle internally using something similar, i.e. a native filesystem optimized for an RDBMS.
21–28 of 28 posts
https://en.wikipedia.org/wiki/ISAM
https://en.wikipedia.org/wiki/Record_Management_Services
They were more like BerkeleyDB and lacked Query Planner.
I think Oracle internally using something similar, i.e. a native filesystem optimized for an RDBMS.
It is an object store called Didgets (i.e. Data Widgets). Each Didget has a specific type. One type is used to hold unstructured data like a file does. These Didgets are unsurprisingly called File Didgets. Other types of Didgets can hold lists (used to create hierarchical folders, music play lists, photo albums, etc.).
Others hold sets of Key/Value pairs which are used to create a tagging system for other Didgets or columns in a relational table.
Using a variety of Didgets, I have been able to create hierarchical file systems where a simple query can find one or thousands of files instantly out of 200 million+ based on the values of any tags attached.
In the same container (called a pod), it can store tens of thousands of relational tables; each one capable of having 100,000+ columns and billions of rows.
The system is 'multi-model' so it could manage hierarchical data, relational data, graph data, or anything managed by a NoSQL system.
It is not only versatile, but is incredibly fast.
The API revolution might be another thing - you were able to swap out a database with any other. Risky decisions are fine when they're reversible. Databases were a more reversible way to deal with scaling and architecture.
But, filesystem-databases idea is still exists. SQLite is essentially this. and I wrote an adapter for this. from experience, It look like capable of doing everything that other adapters do. but really slowly :D
For example; datrix.update('comment',/where/{ author(another file): { group(another file): { tag: 'abc'} } },/data*/ { name: 'new name', anotherRelation(another file): { connect:[123] } })
to find correct entry, this query has to check 3 file. that It replace all the results name with 'new name' and also connects another file's entry for them. what happens if another user wants to write authors same time. or names updated but while connecting another relation exception happened. I have to get back all updates. how I solved this. I lock filesystem while this query (all other requests blocked) I updated all data in memory and if anything happens on the way I revert. this is how slow this solution. what should I do to fix this. I must create another application. It has to manage all request. without blocking. and this is also we called database engine.
Store the file on the filesystem with a unique name. Store the original name, the unique name, the owner, tags, a description, locking, auth, enforce uniqueness, and track access with the database.
Then try and keep things performant and handle concurrency!
Try doing all of the above just using a filesystem and you'll either:
1. Waste years making a rubbish database. 2. Do a bad job trying to do everything with flat files.
PostgreSQL/MySQL or SQLite are easy wins.