> On Saturday, March 21, 2015, Thomas Steinmaurer <t...@iblogmanager.com
> <mailto:t...@iblogmanager.com>> wrote:
>
>      >
>
>     IMHO 99% of the Firebird customer-base isn't in the "distributed system
>     business", thus state-of-the art scale up (instead of scale out)
>     capabilities on a single server will be excellent.
>
>
>     Scale up is a very bad strategy for any number of reasons.  First,
>     the only way to increase capacity is to shut down the system and
>     replace the hardware with something faster.  Second, there is no
>     economy of scale to speed:  To get a machine that is 20% faster you
>     can expect to pay twice as much.  Third, with only one processor,
>     the entire system is down when that processor is down.
>
>
>     An elastic scale out solution lets you add capacity by adding cheap
>     commodity processors.  If designed inteligently, it can offer 100%
>     up time with complete redundancy and rolling upgrades.  It can be
>     geographically disperse.  And, utilizing commodity hardware, it can
>     be hosted in a cloud, multiple clouds, public clouds, private
>     clouds, or any combination of the above.

I know. Ideally such systems like NuoDB, Cassandra etc. will provide 
linear scalability by scaling out with commodity hardware. Lovely.

>     Scale up is just dumb.

Absolutely, if you design a new system for large scale in mind, but not 
for a legacy system like Firebird. From a Firebird perspective, taking 
the existing small/mid-sized customer base into account (do they really 
want to run a distributed database just because Firebird can't better 
(fully) utilize single server resources?), Firebird's 
lightweight/low-footprint capabilities, lack of human resources in the 
Firebird project etc., short/mid-term or even long-term the only viable 
route is to fully utilize a single server.

I can't exactly recall concrete numbers from the past, but I wonder if 
Firebird can currently go beyond > 10MB/s disk I/O utilization. And this 
is not about being limited by spinning disk and seek time (random I/O).

> The only reason to even consider it is if
>     you can't think of anything better.


Regards,
Thomas

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to