So if I shard my graph into 3 parts, my main class can store them as class variables and they'll persist across requests? That would be great. But will I run into quota problems holding 3M data in memory? (Assuming low overhead otherwise, and only 100ish requests per day)
Also, if I did it that way, is there a good way to export the sharded graph data to BigTable for backup/inspection purposes? I guess I could schedule a cron job that hits webapp periodically to trigger export of x items, where x is however many you're allowed to write at a time. Seems inelegant though. thanks Amar On Dec 27, 5:56 pm, Robin B <robi...@gmail.com> wrote: > Using Djikstra's shortest path algorithm, you can compute the shortest > paths between all nodes in the same runtime as computing the path > between any 2 nodes, so storing then querying the precomputed paths > would be a good approach as mentioned above. > > > Since there are no files in AppEngine, my first thought was to create > > a model for thegraphand then write a batch importer that puts all > > the nodes/edges into BigTable. > > AppEngine actually does have read-only access to the filesystem, so > you could break a 3MB file into 3x1MB files, upload them along with > your application files via 'appcfg', then read the files from disk at > launch, cache the data in memcache or, for even faster access, in a > dict global stored in local RAM which is preserved between requests. > > Robin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
