Alternative to scripDb for storing simple data?

Question

Recently the scriptDb service was deprecated from google apps script, and will be shut off completely in the coming months. I have a project which utilizes this service and I wish to phase out the use of scriptDb before it's too late. Currently, my project uses the scriptDb service in the following way:

My script project would take in a series of XML files and parse these to generate javascript objects who's parameters were specific entries in the XML's. For example an object could be:

{type: "proposal", pi: "John Doe", coIs: {"bob", "sue"}}

etc. Each parameter of the object was filled in based on the data in an XML file. I would then proceed to store these objects in the script databse using the db.save(object) command. This was very useful for me because I could query and have returned to me arrays of objects based on specific parameters I may be looking for -outside of the execution where the objects are actually instantiated from the XML's.

The google script migration from scriptDb guide has several suggestions however I feel it would be overly complicated (I wouldn't really know where to begin) to implement an SQL type data structure as these are simple and relatively small objects and I am dealing with a low volume of these objects (in the dozens).

Is there an effective and simple way for me to store these objects after they are generated, so that I can use them in later executions? (not using the scriptDb obviously).

Thanks for any input.

Answer 1

Since its only a few dozen objects, do not use mongo or any other external db. First see exactly how you are querying. Then, decide to store in spreadsheet (a single cell can have a million chars) or properties service. If your queries are limited to certain combinations you might be able to write separate properties and get them directly. Else just store all your db in a single object like a js map. Stringify it and store in a spreadsheet. Mirror the data on a cache so you only read the ss if the cache isnt there (cache can be set to expire in up to 6hours). Finally, filter it in-memory. This will be hundreds of times faster than any external db.

Answer 2

I don’t know about any google internal services, but if it can be anywhere on the web you could use mongoHQ or something similar and store the documents in a mongodb.

Sounds like this should do exactly what you need and it would be for free for you (up to 500MB of data). The big disadvantage is the high latency, since the free version is really slow, and you need to talk to it across the internet (don’t know in which datacenter their free-databases are stored).

Update:

There is already another post on SO, how to move from ScriptDB to MongoDB (How to replace the deprecated ScriptDb with Mongodb using URL Fetch service?)