3 ms·

Wouldn't that slow down an application to have every database call go over the internet?

jarito 16y ago
This is my question. 300 milliseconds is nice, but once you add HTTP overhead, then TLS overhead, it will be almost impossible for your site to respond to YOUR user in less than a second or two. We'll see in 2011 I guess.
- arethuza 16y ago
  There are other cloud-based database services out there - and from my (fairly limited) experience the latency involved is rather noticeable. It might be different if you do bulk uploads of data and then spend a lot of time querying it and retrieving relatively small reports - but that's probably not what most applications spend their time doing.
kondro 16y ago
I guess the trick is to make sure your servers are close to the database... like running on force.com ;-) I guess for most sites, users won't really notice a few hundred milliseconds. I mean, most websites take many seconds to load when you factor in all the individual files and images, etc. UX performance is more about perceived delay (by end-users, not us technical folk) rather than actual delay. If you want to use a product like this so you no longer have to think about your database (and are willing to pay what seem to be quite high fees), design your application to account for the fact that there will be large amounts of lag... that's what parallelisation and non-blocking IO is for.
riffraff 16y ago
possibly, they expect you tu build most logic in store procedures so that you can minimize calls. Also, once you cache them to avoid hitting a backend xSQL store you can also cache them to avoid hitting a remote SQL store, I imagine.
GrandMasterBirt 16y ago
I am sure this is the number 1 concern for them. If they don't solve this then they have just screwed themselves over. Bigger concern: How exportable is this database (my guess is very, since its a resful api to access it all) because at some point if they fail, you going to need to move to your own cluster.
- Maro 16y ago
  Whether the API is REST is irrelevant. In most big data use-cases on real systems, you have special dump/export tools to get your data out. In this case, the question is whether such a tool/API exists, how fast and practical it is. It can be simple though, eg. do they have a button on the webconsole that exports your dataset to a CSV file that you can then download per FTP.
bstrong 16y ago
This doesn't make any sense at all to me for generating dynamic html, since the whole page load will be stalled while you run your db queries. Most sites run many queries to generate a page, at least some of which need to be done serially, so you're adding (300ms + WAN latency) * (num serial queries) to the page load time. If you have a pure ajax app that's directly hitting the db, then it starts to make some sense, as this isn't too much slower than it would be to hit your own service backed by a local db (though 300ms is definitely on the slow side for queries). This seems to be the use case they're aiming for given the focus on end-user authentication.

This is my question. 300 milliseconds is nice, but once you add HTTP overhead, then TLS overhead, it will be almost impossible for your site to respond to YOUR user in less than a second or two. We'll see in 2011 I guess.

arethuza 16y ago
There are other cloud-based database services out there - and from my (fairly limited) experience the latency involved is rather noticeable. It might be different if you do bulk uploads of data and then spend a lot of time querying it and retrieving relatively small reports - but that's probably not what most applications spend their time doing.

kondro 16y ago

I guess the trick is to make sure your servers are close to the database... like running on force.com ;-) I guess for most sites, users won't really notice a few hundred milliseconds. I mean, most websites take many seconds to load when you factor in all the individual files and images, etc. UX performance is more about perceived delay (by end-users, not us technical folk) rather than actual delay. If you want to use a product like this so you no longer have to think about your database (and are willing to pay what seem to be quite high fees), design your application to account for the fact that there will be large amounts of lag... that's what parallelisation and non-blocking IO is for.

riffraff 16y ago

possibly, they expect you tu build most logic in store procedures so that you can minimize calls. Also, once you cache them to avoid hitting a backend xSQL store you can also cache them to avoid hitting a remote SQL store, I imagine.

GrandMasterBirt 16y ago

I am sure this is the number 1 concern for them. If they don't solve this then they have just screwed themselves over. Bigger concern: How exportable is this database (my guess is very, since its a resful api to access it all) because at some point if they fail, you going to need to move to your own cluster.

Maro 16y ago
Whether the API is REST is irrelevant. In most big data use-cases on real systems, you have special dump/export tools to get your data out. In this case, the question is whether such a tool/API exists, how fast and practical it is. It can be simple though, eg. do they have a button on the webconsole that exports your dataset to a CSV file that you can then download per FTP.

bstrong 16y ago

This doesn't make any sense at all to me for generating dynamic html, since the whole page load will be stalled while you run your db queries. Most sites run many queries to generate a page, at least some of which need to be done serially, so you're adding (300ms + WAN latency) * (num serial queries) to the page load time. If you have a pure ajax app that's directly hitting the db, then it starts to make some sense, as this isn't too much slower than it would be to hit your own service backed by a local db (though 300ms is definitely on the slow side for queries). This seems to be the use case they're aiming for given the focus on end-user authentication.