• More-of-the-same in line with MarkLogic’s core positioning.
• A new bi-directional Hadoop connector.
• A free MarkLogic Express edition, limited in license terms more than in actual features, as per Slide 27 of the deck MarkLogic graciously supplied for me to post.

Also, MarkLogic is early with a feature that most serious DBMS vendors will soon have – support for tiered storage, with writes going first to solid-state storage, then being flushed to disk via a caching-style algorithm.* And as befits a sometime search-engine-substitute, MarkLogic has finally licensed a large set of document filters, from an Australian company called Isys. Apparently, the special virtue of the Isys filters is that they’re good at extracting not only text, but metadata as well.

*If there’s a caching algorithm that doesn’t contain a major element of LRU (Least Recently Used), I don’t recall ever hearing about it.

MarkLogic seems to have settled on a positioning that, although distressingly buzzword-heavy, is at least partly based upon reality. The real part includes:

• MarkLogic is a serious, enterprise-class DBMS (see for example Slide 12 of the MarkLogic deck) …
• … which has been optimized from the getgo for poly-structured data.
• MarkLogic can and does scale out to handle large amounts of data.
• MarkLogic is a general-purpose DBMS, suitable for both short-request and analytic tasks.
• MarkLogic is particularly well suited for analyses with long chains of “progressive enhancement” (MarkLogic’s favorite term when talking about derived data).
• MarkLogic often plays the role of a content assembler and/or search engine, and the people who use MarkLogic in those ways are commonly doing things that can be described as research and analysis.

Based on that reality, MarkLogic talks a lot about Volume, Velocity, Variety, Big Data, unstructured data, semi-structured data, and big data analytics.

My November, 2010 overview of MarkLogic technology remains pretty relevant. One correction, however: Node heterogeneity configurations, in which “data” and “evaluation” nodes reside on separate servers, are the exception rather than the rule.

Like Vertica, MarkLogic has laudably said that true academic researchers can get MarkLogic for free without the severe license restrictions. Free MarkLogic should be of particular interest to researchers who:

• Are studying natural networks or graphs, such as social networks or biological pathways. (This might be a fit in the social or biological sciences.)
• Are managing metadata for, say, a variety of disparate kinds of experimental files. (This might be a fit anywhere in the natural sciences.)
• Are managing actual documents, images, videos, etc., or data about such things. (This might be a fit in the humanities or social sciences.)

MarkLogic provided some disclosable financial substance by email, which I shall quote verbatim:

• MarkLogic has 45% revenue growth and 55-60% license growth year over year.
• We expect to finish this year with over $85 million in revenue, up from $55 million last year.

Arithmetical purists might note that 85/55 is more than 145%, but I’m just going to settle for the information I got and move on.

Edit: I posted separately about the MarkLogic Hadoop connector. As for that Hadoop connector – stay tuned for a short follow-up post, as writing about it now would not be convenient. (My backup discipline isn’t what it should be, and the only copy of my notes about that product is on a heavy tower computer in a house that doesn’t have working power.)

• HP needs to make outstanding enterprise systems again.
• They fell away from that target under Mark Hurd, but they surely can hit it again, based on the remnants of DEC (Digital Equipment Corporation), Tandem, the higher-end part of Compaq, and of course the original HP systems group.
• In particular:
  • Rumors say that Oracle Exadata 1 boxes, made by HP, were much lower quality than Exadata 2 boxes made by Sun.
  • HP Neoview was a waste of good engineering talent.
  • I’d like to see a few excellent Vertica appliances.
  • I hope the SAP HANA appliances go well, whenever HANA finally becomes a serious product.
  • The general move from disk to solid-state memory should offer some opportunities.

• 100s of gigabytes of data at first, growing to >1 terabyte over time.
• High peak loads.
• Public cloud portability (but they have private data centers they can use today).
• Simple database design — not a lot of tables, not a lot of columns, not a lot of joins, and everything can be distributed on the same customer_ID key.
• Stream the data to a data warehouse, that will grow to a few terabytes. (Keeping only one year of OLTP data online actually makes sense in this application, but of course everything should go into the DW.)

So I’m leaning to saying:  

• They should go with a scalable, MySQL-based solution.
  • Lots of third-party software works with MySQL, in case that’s helpful.
  • Yes, any one vendor is small and not yet firmly established, but there are numerous vendors around with interesting MySQL scaling stories.
  • In a vendor emergency, just going with Oracle’s MySQL stuff would probably work …
  • … especially because there are these lovely things in the world called solid-state drives.
  • There’s also good escapability if one wants to move away from MySQL, because everybody knows how to handle MySQL data.
• The first product to look at is dbShards, because it meets all the topology needs:
  • Local scale-out (transparent sharding).
  • Local high availability.
  • Remote disaster recovery (details of that are underway).
• The first analytic DBMS to look at is Infobright.
  • Yes, I know Infobright is focused more on machine-generated data these days, but this client’s analytic needs are so straightforward Infobright should pass with flying colors.
  • The MySQL-to-MySQL aspect should make ETL dead simple.
  • Again, there’s escapability.

Mainly, this is all fine. But I’m getting pushback on the solid-state aspect, for fear that it will compromise public cloud portability.

Am I missing something here? As far as I’m concerned, if you’re planning an OLTP system with a many-year lifespan today, of course you should assume solid-state storage. Maybe you scale out just as far as you would with disk, striping indexes or entire databases across the RAM of multiple servers. It that case, having solid-state backing reduces the risk of bottlenecks. Maybe you don’t scale out as far as you would with disk. In that case, solid-state backing saves you money.

As for public-cloud support for solid-state storage, that’s coming fast, right? (Actually, I have data points in support of that theory, but they’re a bit tenuous.) A large fraction of web businesses with private data centers seem to be using solid-state storage — from Facebook on down — or so the NoSQL/NewSQL/short-request DBMS guys tell me. Surely a number of public cloud vendors are close behind.

• A Kaminario K2 DRAM-only appliance costs $100K.
• A Kaminario K2 flash-only appliance costs $30K (but nobody buys that configuration).
• A typical Kaminario K2 hybrid DRAM/flash appliance might cost $35K (which tells us that there’s a lot more flash than DRAM).

Kaminario positions DRAM as where you focus your most write-intensive/ bottlenecking loads, such as logging or temp space, with the primary benefit being performance and a secondary benefit being slowing the wear on your flash.

If you want even your mirrors to be on flash — which Kaminario says greatly reduces the temporary performance hit in case of a failure — there will be an additional charge. Perhaps Kaminario will dig up a price number and post it in the comment thread.

The flash comes in via Fusion-io cards. Kaminario stresses that it sells a SAN (Storage Area Network) kind of offering, as opposed to the shared-nothing way one might otherwise use Fusion-io cards in servers’ PCIe slots. Kamanario further asserts its built-in high availability is both smoother and less costly than Texas Memory Systems or Violin Memory alternatives; Kaminario is generally proud of its high availability features, down to redundant uninterruptible power supplies. Apparently the sweet spot of Kaminario’s market is single-chassis 5-6 TB systems, but Kaminario asserts seamless elasticity even if you grow into a second chassis.

Price resistance seems to have gotten strongly in the way of Kaminario’s growth, although the company was evasive about customer counts and the like. But it does now have 60+ employees and an aggressive hiring plan, vs. <50 when I wrote about Kaminario a year ago. I do believe that many enterprises would benefit from throwing solid-state storage at certain performance problems, at least as a band-aid, while they contemplate software changes.* But evidently Kaminario has had difficulties — especially at the DRAM-only price point — getting customers to agree, or at least to agree that Kaminario K2 was a sufficiently cost-effective way to address the issue.

*If you like, you can regard this as deferring repayment of your technical debt.

Kaminario’s comments about how its technology is or will be applied are all over the place (again, I think part of this is due to having a small number of customers overall, and wanting to conceal how small that number is). But in general Kaminario has seen more OLTP (OnLine Transaction Processing) than analytic uptake, which contributes to them thinking that low latency is a bigger deal than raw IOPS (Input/Output Per Second). Certainly Kaminario is focused on database applications of some kind or other, generally running on big-name DBMS such as Oracle or Microsoft SQL Server

memcached is a way to cache data in RAM across a cluster of servers and have it all look logically like a single memory pool, extremely popular among large internet companies. The Membase product — which is what Couchbase has been selling this year — adds persistence to memcached, an obvious improvement on requiring application developers to write both to memcached and to non-transparently-sharded MySQL. The main technical points in adding persistence seem to have been:

• A persistent backing store (duh), namely SQLite.
• A change to the hashing algorithm, to avoid losing data when the cluster configuration is changed.

Couchbase is essentially Membase improved by integrating CouchDB into it, with the main changes being:

• Changing the backing store to CouchDB (duh). This will be in the first Couchbase release.
• Adding cross data center replication on CouchDB’s consistency model. This will not, I believe, be in the first Couchbase release.
• Offering CouchDB’s programming and query interfaces as an option. So far as I can tell, this will be implemented straightforwardly in the first Couchbase release, with elegance planned for later down the road.

Let’s drill down a bit into Membase/Couchbase clustering and consistency.

• When data is written to RAM in memcached, it immediately gets copied to another server. The same is of course true in Membase/Couchbase. The terminology on all this is confusing, but I think:
  • The portion of data that is stored as a primary copy on any given server is called a “shard”.
  • That would seem to make sense, as that data could correspond to what goes — non-transparently — into an instance of MySQL in a classical memcached/MySQL set-up.
• Updates are of course also banged to disk ASAP — but at times of heavy load, that can take a while. A few seconds to a couple of minutes is normal operation; if it takes an hour, you really should buy more hardware. (Or solid-state storage.)
• Similarly, the replication of data to a second machine’s RAM may not happen at times of heavy load — and that’s another sign you don’t have enough machines.
• Each Membase/Couchbase “shard” has lots of logical sub-shards.* (1024 for now, at least as default, although Dustin finds that number excessive and is looking to lower it.)  So if you add a node, some of the sub-shards get sent over to the new node. Unlike the case for straight memcached, no data is lost from cache (and of course not also from the persistent store). Blocking of operations from such a move only happens in narrow time windows, and then only in edge cases.

*Edit: They’re called vbuckets.

So if we consider Membase technology alone, Couchbase is CA in the CAP Theorem.  CouchDB, however, is gloriously AP in the CAP Theorem, in that it was written to assume an occasionally connected topology.* Based on that, Couchbase will allow AP operation between data centers (i.e. “stay synchronized if you can, to within the limitations of physics and so on, but don’t beat yourself up on the rare occasions that you can’t.”) I don’t know that that capability will quite be in the first release of Couchbase, but it’s coming soon.

*CouchDB also has other features friendly to occasionally-connected use cases, such as a lot of flexibility as to which parts of the database are or aren’t synced when you do reconnect. These are at the heart of the Couchbase Mobile offering.

memcached and Membase have a very simple key-value interface. CouchDB adds secondary indexes and so on. I think in the first release of Couchbase this is pretty much like having two different APIs for the same product; more elegant integration is planned down the road, and more language support as well.

The highest-performing way to use Couchbase will probably always be to just pretend it is Membase, which is to say memcached+. Dustin told me of Membase users who demanded 10-40 millisecond response times, and that not even for single queries but rather for sequences of several queries in succession. He further told me of customers asking for 1-200 microsecond response, and insisting on no worse than 1 millisecond. Frankly, the first requirement could be met by lots of technologies I can think of, at least if  you don’t rely on disk; the second is thoroughly impossible if you rely on disk, and pretty demanding no matter what kind of hardware and storage you have.

Couchbase performance against disk is a work in progress. CouchDB started out 8X slower than SQLite as a backing store, apples to apples, but Couchbase is fixing that before they roll the product out. (After all, they wouldn’t want to slow the product down in the course of an upgrade.) Beyond that, when you do exploit the indexing capability of CouchDB, performance of course slows down. Work is underway to lower the performance hit; I imagine much improvement can indeed be made, given how few resources CouchDB has been able to devote to date to Bottleneck Whack-A-Mole.

10gen recommends solid-state storage in many cases. In some cases solid-state lets you get away with fewer total nodes. 10gen also likes Flashcache (Facebook-developed technology to put a flash cache in front of hard disks). But the 100-node example mentioned above uses spinning disk.

Use cases 10gen is proud of include:

• Lots of user profile maintenance, including at online ad companies. This includes full user ad impression data. (I’ve argued for a while that user profile information belongs in something like a NoSQL database.)
• A big-name web company that wants to inspect every packet that enters their network, and replaced Splunk with MongoDB for performance reasons.
• A big-name photo/video site whose metadata is all in MongoDB. (That’s the kind of thing that often makes for good MarkLogic use cases.)

But actually, the reason we had the call was to review cases where MongoDB’s schemaless nature was significant. Examples of those included:

• A couple of top examples were of the kind “A bunch of apps, similar but not the same.” For MTV, it’s a single content management system for a bunch of websites. For Disney Playdom, it’s different schemas for every game.
• For a wireless telco, the issue was a product catalog in which devices and service plans called for very different schemas, and which the telco felt had thus become unmanageable in Oracle.
• For Craigslist, the issue wasn’t programming so much as performance — ALTER TABLE operations took months in MySQL, and that’s not a typo, although I’ll confess to not understanding why this was the case.

The 10gen guys went on to claim that schemalessness is helpful for incremental development in general, the point being that you don’t have a database-modification step. To some extent, changes can even be rolled back more easily than if you actually changed your schemas.

Fusion-io is growing very, very fast, doubling or better in revenue every 6 months.

Fusion-io’s marketing message revolves around “data centralization”. Fusion-io is competing against storage-area networks and storage arrays.

Fusion-io’s list of application types includes

… systems dedicated to decision support, high performance financial analysis, web search, content delivery and enterprise resource planning.

Fusion-io says it has shipped over 20 petabytes of storage.

Fusion-io has a shifting array of big customers, including OEMs: 

Historically, large purchases by a relatively limited number of customers have accounted for a substantial majority of our revenue, and the composition of the group of our largest customers changes from period to period. Many of our customers make concentrated purchases to complete or upgrade specific large-scale data storage installations. These concentrated purchases are short-term in nature and are typically made on a purchase order basis rather than pursuant to long-term contracts. During fiscal 2010 and the six months ended December 31, 2010, sales to the 10 largest customers in each period, including the applicable OEMs, accounted for approximately 75% and 92% of revenue, respectively. Facebook, Inc. is currently our largest customer and accounted for a substantial portion of revenue during the six months ended December 31, 2010. We expect revenue from sales to Facebook and one other end-user to account for a substantial portion of revenue for the three months ending March 31, 2011, but that revenue from sales to Facebook and the other end-user will decline significantly for the three months ending June 30, 2011 as they complete their planned deployments.

But Fusion-io invests enough in sales and marketing, including direct sales, that I’m guessing they’re out there persuading end-users to ask for product from Dell, HP, and IBM.

Fusion-io’s inventory growth of $23.3 million for the second half of 2010 is close to revenue of $26.0 million. Accounts receivable is a much smaller figure. I’m not sure what all that signifies, but I do find it ironic that Fusion-io’s marketing statements draw an analogy to “just-in-time” manufacturing.

As for what I think about Fusion-io, it starts:

• Fusion-io’s ideas are smart.
• My skepticism about specialized storage hardware for database applications applies in part but not in whole to Fusion-io.
• Right now, Fusion-io has won the market. Even if you don’t need Fusion-io hardware to optimize your use of solid-state memory, you’re apt to go with/partner with Fusion-io anyway.

I don’t have strong opinions as to how long the last point will remain true.

• Given Oracle’s market penetration and share, it makes sense that Oracle is focused on selling add-on products to its installed base. Oracle’s three top such go-to-market emphases at the moment are:
  • Database consolidation, especially on Exadata.
  • Data warehousing, presumably on Exadata.
  • Database security, especially encryption. This is not Exadata-specific, but does exploit Intel Westmere on-chip encryption, which Oracle says allows encryption with minimal overhead. This seems to be via something called Oracle Advanced Security.
• Deleted*

*Oracle asked me to delete a point on pricing they went out of their way to make, because they are in quiet period — even though nobody said it was confidential at the time, we weren’t under NDA, and it looks like public information to me anyway. Frankly, I’m not sure I was right to comply.

Oracle also told me quite a bit about Exadata onsite POCs (Proofs of Concept) and Exadata references, but I’ll save those subjects for future posts. The same goes for workload management.

Oracle’s version names and numbers can get confusing, but it turns out that:

• Oracle 11.203 11.2.0.3 will come out this fall. Oracle 11.204 11.2.0.4 will come out a little more than a year later. After that I imagine it will be time for Oracle 12.
• The current versions of Oracle Exadata are Exadata X2-2 and Exadata X2-8.
  • Oracle Exadata 2-2 is evolutionary from prior Exadata versions, and has 8 moderately big servers per rack. It can be sliced into half- or quarter-racks.
  • Oracle Exadata 2-8, in lieu of those 8 servers, has 2 bigger SMP (Symmetric MultiProcessing) systems, each with a terabyte of RAM. You can’t slice Exadata 2-8 below full-rack size, as you’d lose redundancy among the servers.

I didn’t really understand the discussion as to why certain workloads and/or workload consolidations go better on the SMP boxes of Exadata X2-8 than the blades of Exadata X2-2, but Oracle assures me that some do. I also suspect that some Oracle customers prefer large SMP boxes for no good reason other than familiarity.

As for recent-release adoption:

• Oracle estimates that 40-50% of customers have Oracle 11g running somewhere in their shops, mainly Oracle 11g Release 2.
• All major ISVs (Independent Software Vendors) are certified on Oracle 11g, typically Oracle 11g Release 2.
• But Exadata certification is something different from Oracle 11g certification; for example, SAP certification on Exadata is still underway, targeted for some time this year.

Exadata obviously enjoys huge performance gains over existing Oracle installations for certain analytic queries, and therefore for some whole analytic workloads. Oracle has happily trumpeted these. But it turns out that Exadata’s OLTP (OnLine Transaction Processing) performance gains are less dramatic. This makes all kinds of sense, given that Oracle’s analytic query performance was in pretty bad shape pre-Exadata, while OLTP has been just fine. The range Oracle used was 2-3X OLTP performance gains vs. existing Oracle installations on several-year-old hardware. Oracle says somewhere over 50% of Exadata physical I/O* goes against flash cache in uses cases such as running Oracle’s application suite.

*Note that physical I/O may be only a small fraction of logical; e.g., SAP long ago said that >99% of SAP transactions never hit disk.

Finally, we talked about a variety of options or other related products. Highlights included:

• One piece of the Oracle security story is a new product called Oracle Database Firewall, released in January, based on an acquisition of a small startup last year. Targeted primarily at internal hackers, Oracle Database Firewall sniffs your SQL traffic for a week or so, observes what kinds of SQL statements can be expected, builds a white list accordingly, and casts a jaundiced eye on any other kind of SQL statements that come through.
• Edit: I have no idea why I was told the following, in view of a subsequent email. Oracle Active Data Guard, first introduced in the Oracle 11g code line, is the preferred way to do active-active Oracle replication. That said:
  • Not a lot of customers use Oracle Active Data Guard yet …
  • … but a considerable fraction of Exadata users are at least interested in it.
  • Some number of Oracle customers have other kinds of active-active implementation. One option is via GoldenGate.
• Oracle Cloud File Management System is an Oracle 11g feature/option that lets you managed non-Oracle data. It is related to ASM (Automatic Storage Management), which seems to have been the most popular Oracle 10g feature, and which is essential to Exadata. Oracle Cloud File Management Systems seems to be popular for consolidation uses. But it is not technically well suited to, for example, play the role of HDFS in a MapReduce implementation.
• For DBAs who care, Exadata now supports Solaris on the database server tier as well as Linux. (That would be Solaris on Intel, of course; Exadata doesn’t use Sparc.) The storage tier still runs only on a kind of embedded Linux.
• Oracle 11g Express Edition (free crippleware) just went into beta test.
• And finally, Oracle SQL Developer 3.0 features, among other things, a GUI for Oracle Data Mining, and migration tools. Sybase migration is in there now, and was enhanced for SQL Developer 3.0. Teradata migration is slated for the next release.

… start-ups that are building technologies to enable MySQL and other SQL databases to get over some of the problems they have in scaling past a certain size. … I’d like to get a sense as to whether or not the problems are as severe and wide spread as these companies are telling me? If so, why wouldn’t a customer just move to a new database?

While that sounds as if he was asking about scale-out relational DBMS in general, MySQL or otherwise, short-request or analytic, it turned out that he was asking just about short-request scale-out MySQL. My thoughts and comments on that narrower subject include(d) but are not limited to: 

• The biggest web companies had to go to non-transparently sharded MySQL years ago. The NoSQL movement is, in no small part, an attempt to improve upon that. Ditto for scale-out short-request MySQL.
• Some overlapping categories of companies or projects who need scale-out short-request database processing are:
  • The aforementioned big companies who have other applications they haven’t hand-sharded yet.
  • Other web companies whose applications are getting that big.
  • Conventional enterprises whose web efforts happen to be very big.
  • Sensor networks and other massive sources of machine-generated data.
  • Certain specialized areas (e.g., financial trading).

• Relatively few of these applications are totally impossible to do in Oracle. But the Oracle approach might be very expensive.
• In particular, there’s a break point when companies — often SaaS vendors — outgrow Oracle Standard Edition.
• Yes, the alternatives usually are one of MySQL or Oracle.
• InnoDB isn’t an alternative to these newer technologies; it’s just a piece of the puzzle and indeed of default MySQL now. Several of them — e.g. dbShards — are meant to be used in conjunction with InnoDB.
• Merging his list and mine, the high-performance/scale-out MySQL alternatives look like dbShards, Schooner, ScaleBase, ScaleDB, Tokutek, Akiban, Xeround, and Clustrix. The first two are to my knowledge more proven than the rest.
• Proprietary hardware and the associated hardware/appliance pricing aren’t very appealing for these applications. That speaks against Oracle Exadata and Clustrix, and is the reason Schooner switched to a software-only strategy despite some initial appliance sales.
• However, hardware band-aids such as solid-state drives or even RAM-based solid-state storage could make more sense:
  • If, for performance, you’ve scaling out your database so that it fits in RAM on each box, you don’t really have a disk-based architecture anyway, now do you?
  • Even if you’re not doing that yet — if your problem is throughput rather than storage capacity, silicon-based storage could be a big help.
  • In principle, devices of that kind can be moved from one application to another, after the first one is rearchitected not to need them. (In practice, however, I don’t know of anybody who is doing that. I also don’t believe that Kaminario et al. are marketing that kind of idea, more’s the pity.)
• My notes on all this from April, 2010 are already badly outdated, but may be interesting anyway.

• Teradata is rolling out a new appliance,* the 6680, which combines hard-disk and solid-state drives, relying on Teradata Virtual Storage.
• Teradata is also rolling out a hard-disk-based appliance,* the 6650, in a more routine annual refresh.

Teradata graciously permitted me to post a 6650/6680 announcement slide deck. (Contrary to what it says, it’s not actually “NDA Confidential.”)

* Teradata doesn’t use the term “appliance” for its high-end “active EDW” products, but never mind that; to me, they’re appliances.

The Teradata 6680 has a fixed 3:1 ratio of hard-disk and solid-state drives (SSDs). SSDs are always 300 gigabytes; hard drive capacity can be 300, 450, or 600 GB. Thus, the SSD part is somewhere between 1/4 and 1/7 of total data capacity.

The Teradata 6650 will let you include solid-state drives in the mix in a future release, late this year. But for the intervening months, it’s a hard-disk-only product.

Teradata’s adoption of solid-state storage is somewhat different from other vendors’ in at least two ways:

• Teradata’s disk access has always been much more “random” than some newer vendors’. Thus, Teradata potentially can enjoy a much greater speed-up from solid-state storage than they can, as per Slide 17. (However, Teradata doesn’t seem to be claiming that level of speed-up in practice.)
• Teradata doesn’t buy heavily into the idea that solid-state storage is an ideal place to put temp space. In fact, only 20% of Teradata’s SSD capacity is allocated for temp space or write-ahead logs.

Pricing of the new Teradata systems is a bit vague. According to Teradata,

The Teradata Active Enterprise Data Warehouse 6650 is offered at a price reduction from the current Teradata Enterprise Data Warehouse 5650.

But the details are no clearer than:

The Teradata Active Enterprise Data Warehouse (EADW) 6680 starting price per Terabyte of data is basically the same as the Teradata Active Enterprise Data Warehouse 6650 for the same performance level, and it can go up to 4x the performance levels of the 6650. The Teradata AEDW 6680 is designed to be more cost effective for high performance data warehouses.  In these scenarios, the price per unit of performance is lower than the Teradata AEDW 6650, and is lower than last year’s Teradata EDW 5650.

Confusion is heightened by Teradata’s balancing-taken-to-an-extreme choice to cripple some of the CPU capacity on 6650s with hard disks, then unlock it if solid-state drives are put in instead.

Naturally, the Teradata 6680 has different ratios among performance, data capacity, price, and operating cost than hard-disk-only alternatives. For example, as per Slide 30, a 6680 implementation can have >2X the performance of the 6650 on the same amount of data, yet enjoy “27% lower data center costs.”

Speaking of data center — i.e. power and  floor space — costs, Slide 28 tells us that they’re 20% better with a Teradata 6650 than a 5650. One reason is that Teradata has decided that it really trusts its write-ahead logs, so UPS (Uninterruptible Power Supplies) are no longer needed. Slide 28 also tells us that the 6650 and 5650 are pretty equivalent in performance and data capacity.

Teradata has long made a big deal about its “investment protection,” which ensures that different year’s models of Teradata systems can work together at their respective full performance capacities. However, investment protection has been suspended for Teradata’s products with solid-state drives (the 6680, or the 6650 with the optional SSDs that will eventually become available). Teradata does say that future releases will start having investment protection again, at least back to these new systems.

Relevant background to all this includes:

• Vertica’s take on combining hard and solid-state disks (August, 2010)
• IBM’s take on combining hard-disk and solid-state storage (August, 2010)
• Some storage vendors’ thoughts on the relationship between DBMS and solid-state storage (September, 2008)
• A discussion I had in October, 2009 discussion with Teradata’s Carson Schmidt. (The SSD supplier he was so high on turns out to be Pliant Technology.)