Some information on performance when using the DataStore back end in Database abstraction with google apps script
The library reference is
Mj61W-201_t_zC9fJg1IzYiz3TLx7pV4j
Comparing scriptDB, parse and datastore
In Migrate data from scriptDb to Datastore I showed how to copy over data easily from scriptdb to datastore. The good thing about abstracting the database is that code is the same regardless of which database use you are using (once you’ve got the handle).
In this example I’m copying 1000 records from scriptDB to each of parse.com, datastore and parse.com. Note that each of these drivers using batching, so it’s a fair enough comparison. For the purposes of the test, I’ve switched caching off in all cases. There are 3 operations performed – deleting 1000 records, adding 1000 records and querying them.
Note: since doing this test, I’ve improved batching on parse.com deletion – see Comparing all back ends performance for the improved parse.com performance numbers.
Here’s the code
function scriptDBCopyToDataStore (accessToken) {
//get some data from - no Siloid in original data
var handler = new cDataHandler.DataHandler (
'',
cDataHandler.dhConstants.DB.SCRIPTDB,
undefined,
'myddb',
ScriptDb.getMyDb(),
undefined,
false,
'bruce',
undefined,
true);
assert(handler.isHappy(), 'unable to get scriptdb handler','handler');
// get a datastore handler
var dsHandler = new cDataHandler.DataHandler (
'customers', // Kind
cDataHandler.dhConstants.DB.DATASTORE, // Datastore
undefined,
'xliberationdatastoredev', // project id
undefined,
undefined,
false, // analytics opt out
'bruce', // analytics debugging tracking
accessToken, // the access token
true); // disable caching for testing
assert(dsHandler.isHappy(), 'unable to get scriptdb handler','handler');
var userStore = PropertiesService.getScriptProperties();
// get a parse handler
var parseHandler = new cDataHandler.DataHandler (
'customers', // Kind
cDataHandler.dhConstants.DB.PARSE,
undefined,
'parsecustomers',
JSON.parse(userStore.getProperty("parseKeys")),
undefined,
false, // analytics opt out
'bruce', // analytics debugging tracking
accessToken, // the access token
true); // disable caching for testing
// get the source data
var data = handler.query();
assert (data.handleCode >=0, data, 'getting data from script');
// copy it to datastore
deleteAndCopy (dsHandler, data.data);
// copy it to parse.com
deleteAndCopy (parseHandler, data.data);
// copy it to scriptDB
deleteAndCopy (handler, data.data);
// delete whats there, insert and query - can be shared across handlers
function deleteAndCopy (theHandler,theData) {
// delete everything in current db
var result = theHandler.remove();
assert (result.handleCode >=0, result, 'deleting data from ' + theHandler.getDBName() );
// copy it to db
var result = theHandler.save(theData);
assert (result.handleCode >=0, result, 'writing data to ' + theHandler.getDBName());
// read it back and make sure it all made it
var result = theHandler.query();
assert (result.handleCode >=0, result, 'querying data from ' + theHandler.getDBName() );
Logger.log(result.data.length +' objects in ' + theHandler.getDBName());
}
}
Summary
Although DataStore is quicker at deletion, using its JSON API makes it slower than Parse for both querying and writing. Unless you are planning to use DataStore for its extensive capabilities and scalability outside the simple scope of being a replacement for ScriptDB, it’s hard to see why you wouldn’t choose parse.com and avoid all those quota problems
See more like this in Database abstraction with google apps script and Datastore driver and for all back end performance see Comparing all back ends performance