If we need to store some data in a database, but without the need of advanced SQL features, can we use this scheme (written here in Javascript / node.js) :
// the DB will be in RAM !
var myDb = {};
// read DB from disk if file exists
try { myDb = JSON.parse(fs.readFileSync(DBFILENAME)); } catch(e) { }
// serialize to disk every minute or when process terminates
function serialize() { fs.writeFile('./myDb.json', JSON.stringify(myDb)); }
setInterval(serialize, 60 * 1000);
process.on('SIGTERM', serialize); process.on('SIGINT', serialize);
myDb['record1'] = 'foo';
myDb['record2'] = 'bar';
// ...
See the longer version here as a gist (8 lines of code).
1) Does this DB practice have a name? Is it really so bad? Is it possible to use such a 10-lines-of-code DB system, even in production of websites that have a < 1 GB database ?
2) Scalability: until which size would this system work without performance problems?
i.e. would it work until 2GB of data on a a normal Linux server with 4GB RAM? Or would there be real performance problems?
Note: a minute seems enough to write a 2GB data to disk… Of course I admit it is 100% non-optimized, we could add diff feature between n-1th and nth writing to disk…
3) Search: can I use ready-to-use tools to do some search in such a “simple” database? Lucene, ElasticSearch, Sphinx, etc. something else?
7
Nothing is wrong with this for development. If it has a name, I suppose it would be a mock database. It is not uncommon to create a mock database that can emulate very basic functionality. You have the added advantage that you start from a scratch database each and everytime, thus you know that your program would work also for a potential empty nosql database for the same reason.
However this is not a reasonable permanent solution by any means.
Most programmers, due to the small overhead, will simply go ahead and make it work with a nosql database. It may take slightly longer, you are also programming directly to work in production and not being forced to adapt your program and test it beforehand.
Scalability is a non-issue because you’re always working in development. If you crash your own computer, it is not that big of a deal. The limit of such a database would be only that of your RAM (or the RAM of the computer running the server), however I think you’d find that you’ll find that the program gets very slow before you even reach the point when your program will crash.
Perhaps you could adapt some searching mechanism for the mock database, but if you’re going to go through the trouble, just go ahead and use a proper nosql database. If you literally lose more than 1 hour working on this mock database, then you’ve wasted time.
3