Notes on some basic database terminology
In a call Monday with a prominent company, I was told:
- Teradata, Netezza, Greenplum and Vertica aren’t relational.
- Teradata, Netezza, Greenplum and Vertica are all data warehouse appliances.
That, to put it mildly, is not accurate. So I shall try, yet again, to set the record straight.
In an industry where people often call a DBMS just a “database” — so that a database is something that manages a database! — one may wonder why I bother. Anyhow …
1. The products commonly known as Oracle, Exadata, DB2, Sybase, SQL Server, Teradata, Sybase IQ, Netezza, Vertica, Greenplum, Aster, Infobright, SAND, ParAccel, Exasol, Kognitio et al. all either are or incorporate relational database management systems, aka RDBMS or relational DBMS.
2. In principle, there can be difficulties in judging whether or not a DBMS is “relational”. In practice, those difficulties don’t arise — yet. Every significant DBMS still falls into one of two categories:
- Relational:
- Was designed to do relational stuff* from the get-go, even if it now does other things too.
- Supports a lot of SQL.
- Non-relational:
- Was designed primarily to do non-relational things.*
- Doesn’t support all that much SQL.
*I expect the distinction to get more confusing soon, at which point I’ll adopt terms more precise than “relational things” and “relational stuff”.
3. There are two chief kinds of relational DBMS:
- RDBMS that are designed for, among other things, online transaction processing (OLTP). Examples include Oracle, DB2, SQL Server, Sybase ASE, PostgreSQL, and MySQL. It is reasonable to refer to these as general-purpose or OLTP RDBMS.*
- RDBMS that are designed strictly for analytic uses. Examples include Sybase IQ, Vertica, Greenplum, Aster, Infobright, SAND, ParAccel, Exasol, Kognitio and the DBMS software inside systems from Teradata and Netezza. It is most accurate to refer to these as analytic RDBMS or just analytic DBMS (sometimes abbreviated ADBMS).
* “General-purpose” is usually a better term than “OLTP”; most OLTP DBMS can handle at least basic reporting, and the leading ones go well beyond that.
4. Some analytic RDBMS were designed to be columnar. Some were designed to be row-based. Multiple systems from both groups now offer both column- and row-based storage options. But they’re all equally relational.
And once again, I remind you that columnar storage and columnar compression are not the same thing.
5. An appliance can include a DBMS, and indeed exist for no purpose other than to run a DBMS; but a DBMS is not an appliance. At a minimum, a data warehouse appliance is a computing system (hardware, storage, operating system, etc.) with an analytic RDBMS preinstalled.
Occasionally somebody suggests that a “virtual appliance” doesn’t have to have hardware included, but they usually draw little attention.
However, reasonable people can disagree about pickier questions, such as:
- Does appliance hardware have to be in any way purpose-built? I lean to a No — but I prefer those “appliance” stories that include an actual a hardware advantage.
- Does appliance hardware have to have custom silicon, or at least FPGAs (Field-Programmable Gate Arrays)? My answer is an emphatic No.
- Does an appliance have to be super-easy to install and administer? I lean to a No — but two of the top appliance benefits are ease of deployment and administration.
For example, I think:
- All hardware systems Teradata makes are appliances, even the ones it thinks aren’t.
- Similarly, Oracle Exadata systems are appliances.
- IBM Netezza is the classic line of data warehouse appliances.
- IBM’s “Smart Analytic Systems” can justifiably be called appliances if IBM wishes — but IBM would be wise to save that word for its Netezza line.
Again, reasonable people can disagree — just so long as they don’t slap the label “appliance” onto software-only analytic RDBMS.
Comments
14 Responses to “Notes on some basic database terminology”
Leave a Reply
Forgive the metonymists
And EMC’s Greenplum DCA is not an appliance, but a rack of commodity blades with a factory-installed instance of Greenplum database.
Thomas,
I’m OK with that being called an appliance.
I suspect your reasoning for saying it’s not an appliance would have more force if you instead were arguing that it’s not a GOOD (enough) appliance.
Curt,
If Greenplum DCA is an appliance, anything is an appliance.
TD
not sure what’s the semantic issue of Thomas from Netezza … But you can rest assured that Greenplum’s Data Computing Appliance (DCA) is an appliance, just check the acronym 🙂
BTW, the DCA is not a rack of blades (there are no blade servers in it). It is a rack of servers and network equipment, with all the efforts to make it the best and easiest Greenplum environment to deploy – from call home, to regular monitoring (like unified SNMP support for HW and SW), to pre-optimized setup on all layers (network, firmware, O/S, DB etc), to well tested operational procedures (from expansion to field service to advanced networking to customers network) to tested integration with other products (like EMC Data Domain) to support for mixing GPDB and GPHD (Hadoop) in one appliance, to unified admin web GUI for GPDB, GPHD and HW etc etc.
All this making it easy, fast way to deploy, run and get best end-to-end support (your box is the same as the engineering box), which is what appliances are all about.
BTW – I find it “purpose built” without any specialized HW. I like that – this way you can run your dev environments on a VM and get all the same features, or deploy a software-only version on commodity servers from any vendor, if you want (maybe want to run GP on IBM servers? we have a reference config for you)
Anyway, to each his own.
Ofir (Greenplum)
No, Thomas.
For example, something without hardware included isn’t an appliance.
the main point is not is it an appliance or not, but which kind of appliance is it. While netezza is a datawarehouse appliance, Oracle Exadata is a database appliance.
The first one runs a DWH out of the box, the second runs a DB out of the box, which can be tuned to run a DWH.
An appliance is just hardware and software bundled together to make it easier for a customer to have a successful implementation with the least amount of effort and maintenance.
It’s easy to call Netezza an appliance because they use proprietary hardware and that’s the only way to buy it and their model of an appliance is disposability, sort of like a having a 2 slice toaster, your family grows out of and you need a 4 slice toaster, you throw the 2 slice toaster out.
Teradata typically considered an appliance because it’s software on commodity hardware is bundle together but can be purchased as software only and run on customer hardware or even downloaded for free from their website. Calling Greenplum DCA not an appliance is the same as calling Teradata not an appliance.
A gray area would be software like SAP and HANA or Microsoft PDW that only works on “reference hardware”. To me it’s a cop out because while it couples the technology, it decouples the support and responsibility between two companies.
Curt, I admire your restraint, and the quality of the article.
The most interesting piece of this entire thread would be the name of the clearly misguided ‘prominent company’…which I’m sure we’ll never get to know. Shame!
[…] Opinions differ as to whether a system has to have some of these further advantages to properly be called an “appliance”. […]
If your Systems Administrator calls it an Appliance, then it is an Appliance. This has a lot to do with how much effort he invested in building it, writing detailed specifications for it and of course the depth of detail he’s determined to go into to understand the inner workings of the combination of the software and hardware at hand.
Appliance is an abstraction that is more meaningful to system administrators and DBAs than anybody else.
@adamo,
I love your first sentence! Indeed, your whole argument is good.
terms of dbms with definition
Can you please explain about basic database terminology like entity attribute field etc.in detail