On Thu, Dec 1, 2011 at 3:37 PM, S. Dale Morrey <[email protected]> wrote: > For a larger install you might decide to split the DB server off onto > a separate physical box so that the webserver could be dedicated > solely to serving up web pages. Doing that though increases latency > since you need to use a remote DB connection. You have also > introduced 2 distinct points of failure, your webserver could go down, > or your DB server could go down. If either goes down your customer > will see it as a broken website. > > To address this issue we decided to not use a DB server at all and > instead structure the ecommerce application to use AWS SimpleDB which > is a NOSQL schemaless DB that is essentially a large hashmap. However > it does present itself as a traditional DB and calls are executed on > the backend via HTTP GET/POST instead of a more traditional ODBC/JDBC > setup. (Our app is in Java and runs on Tomcat).
It seems strange that moving the DB to another host (presumable on the same private subnet behind a firewall that you control) and introducing the additional latency of a TCP/IP connection is worth mentioning. Yet, fetching data over a much more involved network that's not under your control with the additional overhead of wrapping it in HTTP doesn't merit a mention. Obviously, after all of that, the HTTP stuff still requires the same TCP setup and teardown. I'm not saying you've chosen the wrong solution, I just don't know about a small part of the justification as given here. Just my 2 cents, Gabe /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
