| Firebird Documentation Index → Firebird Enterprise Whitepaper → Is Firebird “Enterprise Capable”? |
|
|
|
Putting a rope around the term “enterprise capable” is a lot harder than counting the hits it gets on Google. The on-line press uses the term as if it were a given, like “newborn” or “duty-free”. The inference is that this ephemeral thing is something everyone wants in database software, is either present or absent, and can only be obtained in commercial products.
To address the question in a meaningful way, one first needs to find a context for “enterprise” that fits the business model being addressed. The two rational questions to ask are: What needs, present and future, does Enterprise X have that must be satisfied by the capabilities of the database software? Can DBMS Y satisfy them?
Those of us who sit in the users' gallery rather than the press gallery would put the capabilities for our enterprise context under at least six general spotlights, viz., stability, scalability, availability, capacity, interoperability and autonomy.
We want a database management system that stores the data that our business needs to store and protects it from corruption from both environmental mishaps and human error. Our system must be able to deliver data to applications in flexible conformations consistently, accurately and with acceptable speed and it must be able to handle conflicting conditions. It must do all of these things at once, without interruptions, stalling, crashing or excessive waiting.
Such intrinsic stability in a DBMS is an obvious requirement, regardless of any other factors in the wish-list of the enterprise. A set of interleaved principles has evolved over the years defining four essentials that no database management system should lack if it is to be taken seriously. “ACID” is an acronym for these four principles: Atomicity, Consistency, Isolation, Durability.
Firebird's design and architecture are fully “ACID-compliant”. The ACID concepts are described below, in the section Acid Compliance and Firebird, with comments about how Firebird meets each principle.
Everything in Firebird is done within the context of an ACID transaction. A Firebird transaction may involve many complex, inter-dependent steps of an enterprise task but it will never permit violation of any ACID principle.
With the stability of our production environment in mind, we may not always want to choose a brand-new DBMS to be the heart of our enterprise systems. In general, we prefer to begin with a product that has established its capabilities and whose sweet and sour spots are known and well understood. If end-users are to be responsible for dealing with problems that might occur, we want to know whom they should call on for assistance. If an application software vendor is the one who takes the 000 call, does that vendor have adequate support on hand?
The Firebird end-user community is well-served by highly-capable tool and application developers and vendors. Typically, these developers have been close to the developing source code for six years. Much of their expertise extends much further back, to the earliest days of the Borland development tools, which have always shipped with InterBase developer versions in the enterprise packages.
The Firebird developer community is famous for its support forums, where expertise is constantly shared.
End-user support contracts, while offered by several companies, are rarely demanded. Contract support for developers is available in many countries, including Australia. However, it must be said that demand from developers for support, beyond perhaps the installation stage on an unfamiliar hardware platform, is low in most locations.
On the other hand, because business demands change and hardware capabilities increase rapidly, we may also want to know whether the DBMS is under active development or is near the end of its development life. We expect regular sub-releases and signs that the next major release is on the way. When we are ready, will it be easy to upgrade? Can our existing databases be migrated painlessly to a new release or will it be a lengthy, do-or-die logistical exercise?
Now in its sixth year, the Firebird Project team continues confidently on its track towards planned releases that will implement architectural enhancements to meet hardware advances and satisfy a demanding community of developers, users and supporters. The openness of the code and the renowned willingness of the community to share what they know ensures a continual supply of up-to-date knowledge about the code modules and the software's capabilities.
The project's independence from commercial owners frees end-users from concerns about continuity and ensures that technical discipline prevails over the drive to get releases “to market”.
Scalability refers to the ability of the DBMS not just to manage the database needs for the current range of enterprise needs but also its capacity to cope with growth (upward scalability) and minimalisation (scaling “down” to single-user, briefcase or embedded appliance models, for example).
Scalability considerations address factors such as minimum and maximum numbers of active end-users, whether database growth and rising user numbers affect performance or stability, whether migration of data is involved in ascending or descending the scale of possible requirements. For some enterprises, scalability factors may overlap with other areas of capability, such as availability and interoperability (q.v.).
Scalability in any direction is one of Firebird's strengths. Unlike many software systems competing in the same space, Firebird, since its earliest days as InterBase, was always network software by design, and the on-disk structure of databases has always been managed independently of the host's filesystem, by the database engine itself.
In contrast with some heavily marketed, supposedly “enterprise-capable” DBMS offerings that respond to demand for upscaling capability by adding weight and ever more prolific file-bound mechanisms, Firebird's upscaling is merely a question of adapting the environment. The same engine comfortably handles anything from being embedded in a stand-alone client application, through to a classical two-tier client/server LAN of around 750 potential users, to incorporation in a multi-tier solution for thousands of potential clients. Database growth is effectively limited only by the disk storage available and can be split across multiple hard disks.
Through smart replication and good connection management in the access layers, the workload of a busy system can be distributed across multiple servers. For example, a well-resourced central server can handle the interactive demands of LAN, intranet or extranet (or all together) while a replicated server takes care of long-running jobs that need to isolate a snapshot of data for lengthy periods.
Maximum availability is sometimes measured by the “five nines” criterium: can the server be relied on to keep databases available for 99.999 per cent of the required operating hours? Among its users, Firebird has a reputation for being bomb-proof.
Some high-profile data management systems require costly expertise on site for all of the hours when the databases have to be working. The typical Firebird deployment is to companies that do not have any database staff on the payroll.
As with any complex system, a Firebird deployment needs to be well planned and well designed, but an appropriately configured Firebird deployment on a reliable network infrastructure “just works”. It uses optimistic locking at record level, drastically reducing the wait-time overheads in comparison to others where read-write transactions lock entire sets, even tables, pre-emptively. No tuning is ever required to facilitate handling varying workloads through the day or week. A database does not have to be shut down for backups. It can be replicated or shadowed for almost instantaneous cutover in the event of disk failure. It is robust and recovers immediately from power failure, without loss of database integrity.
Firebird is a popular choice for enterprises needing continuity of service around the clock. Command-line tools are distributed with the software for all administrative activities, allowing regular housekeeping to be automated as scheduled or on-demand jobs. A Services API is also available to wrap admin tasks into a program or service application.
On-line backup (gbak) creates not a database but a platform-neutral file containing metadata and data saved separately in a compressed text format. Firebird 2 also has optional on-line incremental backup, which can be scheduled throughout the day to suit the loads.
The largest Firebird database we have heard of is about 11 Terabytes and growing. Tables are limited to about 2,000,000,000 rows and, up to version 1.5.x, a maximum of about 30 Gigabytes per table. The maximum table byte-size limit disappears in v.2.0, due in mid-2006.
Firebird is among the most compliant of all the RDBMS offerings in its implementation of the international (ISO) and U.S. (ANSI) standards for the the SQL query language, exceeding even its InterBase cousin. Standards evolve continually and, as they do, the Firebird developers keep the language implementations from release to release aligned to the latest published versions.
Existing implementations of language features that become subject to new standards are retained as “deprecated options” to ensure backward compatibility.
Firebird is designed for interoperability as a “back-end” in the absolute sense. It is not bound to any “integrated solution” that ties databases to a specific environment. A decision to move Firebird databases from a Windows to a Linux or Unix host, or vice versa, can literally happen overnight. All it takes is a transportable backup at the old host and a restore at the new and you are back in business.
Application vendors who are mindful of the ease of such transitions are careful to write software that is “aware” of the ways Firebird servers can be configured so that software running on any client operating system can access database servers running on any other supported operating system.
Firebird is capable of running in heterogeneous networks. Application software written for one operating system happily connects to databases running on another, without modification. An application can connect to multiple database servers on mixed hosts simultaneously and can run multi-database transactions across mixed hosts.
It is common, for example, for demanding sites to run several Firebird servers, replicating between a high-cost main server and cheaper boxes running a sparsely-configured Linux with fast disk systems for load-balancing and failover.
Firebird servers can also participate in heterogeneous transaction server environments like MTS and Citrix, in pass-through environments and in secure virtual networks.
Firebird has no requirement for suites of special modules to bind it to external applications. All data access layers converse with the server through its two published application programming interfaces (APIs), one for database-level operations and the other for server-level services such as backup and user authentication.
Driver support is available for a large number of programming and standard interface environments, including Java/JDBC, ODBC, .NET, Delphi, Python, PHP and Perl.
Autonomy refers to the degree to which data stored and managed in a database has “an internal life of its own”, i.e., its capability to exist and to remain consistent, independently of hardware and operating system environment, external application programs, specific programming environment.
“Autonomic features” include such things as
file-system independence
declarative referential integrity
the ability to implement validation and/or business rules via triggers and CHECK constraints
stored procedures, to encapsulate business procedures and processes internally, independently of any application language or user interface
database-resident user access control
the ability to query external data as “virtual” structures without needing to store that data
the ability to output programmatically constructed temporary data sets without the need to materialise temporary tables
retention of deprecated features to ensure backward compatibility
Firebird supports all of these autonomic features.
A further aspect of database autonomy that has become an issue for users of many high-profile DBMS products in recent times is the degree of transparency with which legacy databases can be managed and migrated when the server software is upgraded or databases are ported to a different host hardware or operating system platform. With these issues, the common experience is that they are high-cost in terms of time and logistics.
In contrast to any other significant RDBMS except Firebird's cousin, InterBase, migration of databases is seamless. Unlike others, which have architectually different on-disk structures for multiple platforms, or which bind database structures to a single platform, Firebird database structures are stable across platforms. This means, for example, that if choosing one operating system as a host turns out to be a sub-optimal decision, you may switch to another host in the time it takes to perform a backup and restore.
A new release of a Firebird server connects to any database that ran under a previous version and a transportable database backup made on one hardware/OS platform can be restored, ready-to-go, on any other supported host platform.
When upgrading to a new major release, it is highly recommended, although not essential, to put databases through the backup/restore cycle, in order to upgrade the on-disk structure of the database and make new features available. The question of whether to do this really depends on whether the application vendor has already updated applications to take advantage of new and enhanced capabilities.
|
| Firebird Documentation Index → Firebird Enterprise Whitepaper → Is Firebird “Enterprise Capable”? |