FWIW, the smaller the payload, the bigger SNARL's speed advantage over HTTP. This may or may not matter; and it's certainly easier to implement an HTTP client for Stardog's HTTP API than to dive into ProtocolBuffers.
The database per user model is what I'm using as well. So far, I haven't run into any issues or differences with utilizing Stardog in this manner. That said, I haven't scaled it beyond a 100 or so accounts. We are currently working on an application that will need about 3,000+ accounts in the first few months. I'm using the "snarl" protocol to do database admin with my own Java logic sitting in front of it to control the automated creation process.
I'm curious, how many user databases are you going to create?
On Jul 5, 2012, at 8:12 AM, Ron Michael Zettlemoyer wrote:
I wouldn't mind knowing how to do it in 1.0.1 too. :) It's not for a tool that I'm going to share or anything like that, it's strictly for a prototype of an app that will need to create new databases on the fly. So if I use the 1.0.1 version of the API and then have to change it a little when 1.0.2 it's not a big deal.
Speaking of which, is there anything I should keep in mind as far as performance if I'm going to be setting up a lot of small (50k-100k triples) databases? It's for a web service where each database will store the data for a separate customer.