|
"Do you think SQL Anywhere is scalable enough... or should we just use Oracle so we are sure?" I have a client who has big plans -- and that's the question he asked me today. And, quite frankly, I don't have experience on databases that come close to the limits of SQL Anywhere. The only limit I've run into in the past is uptime... I want 100% application uptime. And now I have it (knock on wood). We didn't have 100% application uptime until we got replication going... and now it's trivial to toggle our apps between instances of SQLA, so that we can install patches, reboot machines, whatever needs doing. However, it would seem to me that SQL Anywhere is pretty much limitless in its transaction processing capability... I know that the size of the database has limitations based on the size of the media, but given that you can replicate the database, then divide the workload across thousands of servers installed across multiple data centers, the only real limit on SQLA is storage, right? Yeah, yeah, I know, there is much more to managing large databases than this... but theoretically anyway, would a well-architected database in SQLA be unlimited in transaction processing capability? I'm getting popcorn. (No oracle bashing please. Plenty of that elsewhere.) |
|
Regarding your use-case as mostly selects in a web environment in my opinion with the new scale-out mechanism (>=V 12) it comes close to unlimited. So for you it's more a question of having enough hardware and bandwidth between the servers. 2
Martin, I think you are absolutely right. The new Scale Out feature in SQL Anywhere version 12 was designed EXACTLY for this purpose. Client requests that are SELECT only will/may be redirected to a scale out node for the query to be handled. Folks can read more about this feature on DCX
(23 Mar '11, 10:18)
Chris Kleisath
|
no comments, no answers? ;-(
I think the phrase "unlimited" has scared everyone away. "Unlimited" is ... well ... unlimited. How would anyone answer that?
As well, I question what a "database" is in your envisioned system. Is a "database" a single .db file (ok...perhaps with several dbspace files), OR are you considering a partitioned scheme where the tables and data for some set of users is in one .db, and the tables and data for another set of users is in a different .db?
"Unlimited" is reason enough to link to Glenn's great blog article on "infinite scalability":
"Infinity gives me vertigo" - cf. http://iablog.sybase.com/paulley/2010/07/.
Chris.. of course, you are right. Good stuff Volker (and Glenn!) thanks!
In my head, i'm thinking of this from a perspective of a web based application that is mostly SELECTs against a single database -- but that database can be replicated to a boat load of remote databases, and each remote database can handle part of the load. As the user base of the application grew, we'd just add more remote database instances.
Think Facebook... it started with dozens of users, and now has 500 million? I have no idea what their architecture is, but I'll bet there is a database in replication at the heart of it. When the user base gets bigger, there has to be a way to scale up without a complete overhaul.
Maybe "infinite" is a bad choice of words, how about "massive" scalability?
There's plenty of interesting info on the High Scalability blog. See this for Facebook: http://highscalability.com/blog/2010/11/4/facebook-at-13-million-queries-per-second-recommends-minimiz.html
AFAIK, these huge websites like Wikipedia tend to give up some of the typical ACID priciples in order to get higher thoughput and to isolate different "replicas" from another. I.e. they allow inconsistent/not transactional updates where a typical classic distributed DB application would require a 2-phase commit protocol (and by that lead to some kind of serialization). That's one of the sources for the "NoSQL" architectures.