3 ms·
I'm a little confused. Does the "layers" concept mean the data which is stored in the core can be accessed in any valid manner that the layers allow? Or stated
by mikece 8y ago
I'm a little confused. Does the "layers" concept mean the data which is stored in the core can be accessed in any valid manner that the layers allow? Or stated differently: if I've got a dumpster fire of data in a MongoDB that should have been in an RDBMS but moving to SQL would be too risky/slow would this allow me to schlep my Mongo data to FoundationDB and have the app continue to use the Mongo access methods while I start switching APIs over to querying by SQL in batches instead of One Big Volatile Move?
- sigstoat 8y agofoundationdb is just a KV store that doesn't even authenticate clients connecting to it. the idea is you put layers in front of it to take nice structured requests (of some sort) and turn them into transactional KV manipulations, while also doing things like authentication, access control, logging, whatever else you need. so you could (hypothetically, if such software existed), have this mongo layer, and then another layer off to the side which took SQL queries, and figured out how to turn them into KV queries against the data that the mongo layer has stored. more realistically, you could have your SQL clients know how to talk to foundationdb directly (making them into the layer; presumably they're a web backend or something already), and they could know how to execute the high level operation they want to perform against the KV data stored by the mongo layer. conveniently skipping all of the SQL translation that there isn't software for.