• If your goal is to keep a certain class of queries from taking too many resources, Tim thinks a great way of doing that is to control how many of them are allowed to run concurrently.
• By way of contrast, Tim is cautious about the common approach of just lowering a query’s priority. His concern is that a long-running query could linger even longer, creating a long-lasting bottleneck in, for example, temp space.
• When running over (I believe) Linux and AIX, DB2 workload management is integrated with operating system workload management. I.e., the same “service class” or “workload class” (at a guess, the former is the official term and the latter is the term that makes sense) of queries and associated processes gets the same treatment in both DB2 and the OS.
• DB2’s workload management extends to buffer pools, to inhibit low-priority queries from evicting a higher-priority query’s data from cache.
• Sometimes, workload management doesn’t throttle a query, but just decides to collect stats for future analysis. (This is on the eminently reasonably theory that the best stats to collect are the ones that are live when performance problems are actually occurring.)

Finally, Tim spoke of what I regard as the weirdest workload management requirement, one I also heard about from Netezza (but didn’t explicitly mention) in June. Sometimes, it seems, you simply don’t want queries to finish too fast. Why? Because if you give great performance when the machine is lightly loaded, then business users might expect that performance too when the machine is heavily loaded and you can’t deliver it. Apparently, in some environments it’s better to never deliver great query performance than it is to do so only inconsistently.

*The comment threads are the most informative parts of those posts.

I’m a little unclear as to the Netezza Migrator details, not least because Netezza folks don’t seem to care too much about Netezza Migrator themselves. That said, the core ideas of Netezza Migrator are: 

• Netezza Migrator is an enhanced (?) version of EnterpriseDB’s Postgres Plus Advanced Server DBMS. (Recall that Postgres Plus is PostgreSQL-based and fairly Oracle-compatible.)
• Netezza Migrator does not run on Netezza appliances, but rather on conventional computers off to the side.
• Netezza Migrator generally farms out queries to Netezza appliances, but can also manage data itself. (That latter part could supposedly come in handy for small tables one might want to execute stored procedures against.)
• Netezza Migrator does a better job of farming out queries (and also inserts/updates/loads) to Netezza appliances than an Oracle DBMS would. The two biggest examples of that are:
  • Oracle will farm out SELECTs, but not JOINs.
  • Oracle won’t invoke Netezza’s parallel/bulk load capabilities.

• Netezza now intends to come out with a Flash-based appliance earlier than it originally expected.
• Indeed, Netezza has suspended — by which I mean “scrapped” — prior plans for a RAM-heavy disk-based appliance. It will use a RAM/Flash combo instead.*
• Tim Vincent of IBM told me that customers seem ready to adopt solid-state memory. One interesting comment he made is that Flash isn’t really all that much more expensive than high-end storage area networks.

Uptake of solid-state memory (i.e. Flash) for analytic database processing will probably stay pretty low in 2010, but in 2011 it should be a notable (b)leading-edge technology, and it should get mainstreamed pretty quickly after that. 

*So far as I can tell, that’s one of the two significant roadmap changes between the 2009 and 2010 editions of Enzee Universe. The other one is that the robust form of appliance-to-appliance replication technology is coming out later than Netezza had originally planned and hoped.

There also is increasing reason to think that the issues with Flash memory wearing out are overwrought.  And by the way, the entire history of enterprise solid-state memory use is basically shorter than the time in which these products supposedly will wear out, so it’s not as if there have been a lot of real-life failures out there.)

• First, clever things are being done in the area of error correction codes, although for the most part I defer that part of the discussion to Petascan’s Camuel Gilyadov. E.g., this seems to be the idea behind Anobit.
• Second, analytic DBMS are pretty much an ideal use case for Flash reliability. Suppose, as is the case for many products and implementations, you only write things in big blocks. Then you are, ipso facto, resetting the Flash bits only in big blocks. Thus, at least in theory, you automatically have pretty perfect wear leveling.

Another part of the deal was that I’d give a talk this morning at 9:30 am. And when I give talks, I like to put up posts that cover whatever material I haven’t written up before, while also offering the talk’s listeners convenient links to materials I have already covered previously at length.

So anyway:

As I’ve been doing all year, I plan to start the talk with the subject of liberty and privacy. My most recent overview post on privacy and liberty has a bunch of links to what I and other people have said before.

This year’s Enzee Universe keynote speaker was Stephen Baker, author of Numerati. His talk, the only one all week I’ve attended in its entirety (I do intend for mine to be the second one, however ) reminded me that some of my ideas had been inspired by his book, specifically the part about sensors in our elderly relatives’ homes tracking every movement, for legitimate reasons of health care and physical safety.

One thing I’m reminded of when talking with users is that they tend to be a bit focused on their projects or areas, and almost never have the opportunity to consider the full range of possibilities open to them. So I’ve put in two slides to raise consciousness on the point.

• $ per user
  • $1000s or maybe $10,000s (perhaps a small team of analysts looking at Big Data)
  • $100s or maybe $1000s (perhaps conventional BI)
  • On the order of $.10 or $1 (stakeholder-facing analytics)
• Three benefits of better price/performance
  • Do the same thing, cheaper
  • Do the same thing, better
  • Do something different

Then I put together a list of “cool technologies in analytics” people might want to think about, including:

• Solid-state memory (there’s a whole section here about that; see the sidebar)
• Data mart spin-out
• Exploratory BI (e.g., QlikView)
• Advanced analytics (platforms)
  • DBMS-centric (more on that coming soon, but meanwhile February’s posts can be a placeholder)
  • MapReduce-centric (there’s a whole section here on that too)
• Advanced analytics (UIs and algorithms)
  • SQL tasting (I just coined that to talk about the useful idea of getting fast, partial results on long queries)
  • Stats/predictive (I’ve really got to build a blog category for that)
  • Graph
  • Matrix/optimization

And finally, I listed three “aggravating analytic challenges” in areas where I’m disappointed with the progress of and/or prospects for technology, including:

• KPI management
• Text/tabular integration
• Profile of Revealed Preferences aka “Social graph”

Posts on Netezza’s announcements around the time of Enzee Universe

• A long discussion of Netezza’s technology, focusing on the database parts
• A discussion of Netezza’s and IBM’s compression strategies
• Notes on how Netezza balances its silicon and uses its FPGAs
• A quickie on data warehouse loading latency
• How Netezza Migrator works
• Netezza’s strategy for RAM and Flash

• Subsecond load latency is substantially impossible. Doing that amounts to OLTP.
• 5 seconds or so is doable with aggressive investment and tuning.
• Several minute load latency is pretty easy.
• 10-15 minute latency or longer is now very routine.

There’s generally a throughput/latency tradeoff, so if you want very low latency with good throughput, you may have to throw a lot of hardware at the problem.

I’d expect to hear similar things from any other vendor with reasonably mature analytic DBMS technology. Low-latency load is a problem for columnar systems, but both Vertica and ParAccel designed in workarounds from the getgo. Aster Data probably didn’t meet these criteria until Version 4.0, its old “frontline” positioning notwithstanding, but I think it does now.

Related link

• Just what is your need for speed anyway?

When you sell a row-based DBMS, as Netezza and IBM do, there are a couple of approaches you can take to compression. First, you can compress the blocks of rows that your DBMS naturally stores. Second, you can compress the data in a column-aware way. Both Netezza and IBM have chosen completely column-oriented compression, with no block-based techniques entering the picture to my knowledge. But that’s about as far as the similarity between Netezza and IBM compression goes. 

IBM’s basic DB2 compression strategy is remarkably simple. In every table (not column) – or in each range partition in a range-partitioned table — the 4096 most common* values are identified; these are all encoded into 12-bit strings. And that’s that. This has been happening since DB2 9.1, released 4 ½ years ago. DB2’s compression persists through logs, buffer pools (i.e., RAM cache), and so on. In DB2 9.7, the most recent release, IBM extended the use of the compression to a few areas it hadn’t stretched before, such as log-based replication, native XML, or CLOBs (Character Large OBjects) that happen not to be too big.

*Actually, I’d presume it’s not exactly the “most common”; there surely is some minimum length of a value to be encoded, or some bias toward length. Also, the determination of what to encode is probably a little imprecise. E.g., I forgot to ask whether the choice of values ever changes as data got updated.

The sophisticated part of DB2’s simple compression strategy is its breadth of applicability; DB2 compression can apply to:

• Values in columns (numeric, character, whatever)
• Substrings of values in columns
• Groups of columns (e.g., city/state/zip code)

Except for the 4096 values limit, that sounds at least as flexible as the Rainstor/Clearpace compression approach.

Netezza, unlike IBM, takes a grab-bag approach to compression – try out a bunch of techniques, see which work best, and incorporate those in the product. Netezza first introduced compression a couple of years ago, for numeric columns only, especially integer.  Techniques  used in Netezza numeric compression include but are not limited to:

• Delta compression, wherein you store the increment between a value and its predecessor rather than a whole new value.
• Ways of indicating that a value or increment was just the same as in the row before.

This was via something called Compress Engine,* now being renamed to Compress Engine 1. Netezza’s new Compress Engine 2 improves on what Netezza did in Compress Engine 1 for numeric data, most notably by trimming away excess field length. (Netezza says it got 28% better compression on a test data set with almost no character strings, primarily from that enhancement.) Further, Netezza Compress Engine 2 adds new compression techniques, allowing it to handle VARCHAR – i.e. character strings — as well.

*Fortunately, the original name or at least description of “Compiled Tables” is retreating ever more from view.

Netezza’s Compress Engine 2 has two ways to compress character fields/text strings – prefix compression and Huffman coding. By way of contrast, Netezza tested suffix compression and decided it wasn’t beneficial enough to bother messing with.

• The idea behind prefix compression is that if two strings start with the same characters, for the second one you only have to record the part that’s different. Prefix compression has a lot of the same merits as delta compression; like delta compression, it works best on sorted columns. (An example of where prefix compression makes obvious sense is URLs, which tend to all start in similar ways.)
• In Netezza’s version of Huffman coding, the alphabet is encoded symbol-by-symbol, with more common characters getting codes of shorter length. These codes are chosen on a column-by-column basis. (I presume the “/” character gets shorter code in a URL column than it would, for example, in one that stored addresses.)

While I didn’t ask explicitly, it seems pretty obvious that Compress Engine 2’s functionality is a strict superset of Compress Engine 1’s. Netezza is going to run Compress Engines 1 and 2 side by side, but expects pages to move from Compress Engine 1’s purview to Compress Engine 2’s as part of the new “table grooming” process.

Related links

• IBM kindly permitted me to post some of its slides in the area of compression
• Microsoft SQL Server seems to rely on prefix and dictionary compression

• Netezza planned to be “generous” in its original TwinFin FPGA capacity, anticipating software upgrades like the ones it’s introducing now. It is satisfied that this strategy worked. More on this below.
• The same surely applies to CPU.
• What’s more, I get the sense that the CPU turned out in practice to be even more over-provisioned than they anticipated …
• … at least when one just considers Netezza’s base NPS software.
• However, I suspect that if the advanced analytics capability takes off, Netezza will determine that more CPU is always better.
• And by the way, NEC is making versions of Netezza appliances with more advanced chips than Netezza is. So if anybody should really, really need more CPU in their Netezza boxes, there’s a very straightforward way to make that happen. (And if there were nontrivial demand for that, appropriate support plans could surely be structured.)
• Everybody needs to be careful about RAM. Netezza is surely no exception.

The major parts of Netezza’s FPGA software are:

• Compress Engine 2. This is Netezza’s new way of doing compression.
• Compress Engine 1. This is Netezza’s old way of doing compression. It is being kept around so that existing Netezza tables don’t suddenly have to be changed or reloaded.
• Project Engine. Guess what this does.
• Restrict Engine. Ditto.
• Visibility Engine. This enforces ACID and handles row-level security. It is “sort of a corner of” the Restrict Engine (Actually, Netezza seems to waver as to whether to describe “Restrict” and “Visibility” as being two engines or one.)
• Miscellaneous plumbing.

If I understood correctly, each Netezza FPGA has two each of the engines in parallel.

Related link

• An August, 2009 post on what Netezza does in its FPGA

It might be best to start with some Netezza product introduction and naming housekeeping:

• Netezza isn’t changing the hardware on any of its existing systems at this time. Rather, Netezza’s product upgrades are contained in a software-only release …
• … except that it isn’t a “release,” but rather a “wave.” There are three points to that terminological distinction:
  • The advanced analytics part doesn’t depend on the new database platform software.
  • Individual functions in the advanced analytics part don’t necessarily depend on advances in the analytics platform.
  • It plays on the surfboard-centric naming of Netezza’s appliances.
• Netezza has wisely scrapped its prior plan to make its advanced-analytics capabilities be a chargeable add-on to it core appliance products. Rather, Netezza is going to offer advanced analytics as part of its core product. Part of the reason is that the interest in these capabilities is broader than Netezza first anticipated. The name for this is is something like i-Class advanced analytics capabilities.
• There is a “release” in all this too, namely NPS 6.0 (Netezza Performance Software). That’s the core DBMS technology.
• It’s all to be shipped in Q3.

Highlights of our NPS 6.0 conversation include:

• As promised, Netezza has improved its compression significantly. Because this was anticipated, this upgrade was planned for in the design of the systems Netezza started introducing last summer. Consequently, the reduction in I/O produced by compression translates almost directly into better performance – the silicon is now more fully loaded than it was before, but few if any actual silicon bottlenecks have been introduced by the I/O improvement.
• Netezza’s other big performance enhancement is the introduction of clustered base tables, which it says can reduce I/O by an order of magnitude or better.
• Netezza says that there are individual queries in which the enhancements take query performance up 30-40X. (Presumably, those would be ones for which clustered base tables are a big win.)
• More interestingly, Netezza says that overall performance is improved by >2X. That’s queries, load, backup, and everything else all blended together.
• Underpinning all this, Netezza went from 125 MHz to a blend of 125 and 250 MHz in its FPGA clock speeds. Also, the width of the FPGA onboard data path went from 16 to 32 bits. Netezza suggests that the naive calculation which says this could increase FPGA throughput 4X isn’t entirely misleading.
• Netezza is pretty content with its workload management capabilities for queries, but nonetheless keeps adding features. Workload management has not yet been extended to cover all the non-query parts of the analytic functionality.
• Netezza continues to enhance its cost-based optimizer and query planner.
• Netezza has long used an internal networking approach that’s rather different from TCP/IP. Netezza views TCP/IP’s strength as recovering gracefully if there’s congestion. However, Netezza would rather do whatever it takes to preclude congestion in the first place, except perhaps in rare edge cases. I’m not aware of what enhancements, if any, have been made to Netezza’s internal networking specifically in NPS 6.0.

The basic idea of clustered base tables (“base tables” are ones that are not, for example, materialized views) is to range partition in multiple dimensions at once. Then you rule out (as in don’t retrieve) all those blocks that fail a match in any one of the cluster dimensions. Netezza says its customers were doing a lot of work to simulate this benefit by multiple sorts; Netezza’s implementation will now handle that much more automatically. Netezza says that talking to customers revealed that 4-5 cluster dimensions was almost always the most somebody would need; they will ship support for 4. That makes sense. In most cases, you’d want to cluster on the answers to “W” questions – Who, What, Where, When (but probably not Why), in one dimension each. However, Netezza does call out as an ideal use case geospatial, precisely because 2 (or more rarely 3) dimensions each have “equal weight.”

I don’t know how other vendors implement clustered base tables, but in Netezza’s case it’s via a space-filling curve. (Actually, they called it a “Hilbert space-filling curve,” but I oppose that phrasing, as it’s apt to lead to extremely incorrect use of the term “Hilbert space.”) I.e., data is mapped to 4-tuples (say) in line with the dimensions, which are then sorted in a linear order in line with a space-filling curve. Happily, Netezza hasn’t experienced problems clustering columns that have particularly challenging cardinality or skew.

If I understood correctly, you can only zone map (and presumably cluster) on integers and dates right now, but that will change soon. (Edit: In blog comments and email, Tim Greenwood of Netezza explained to me that the NPS 6.0 workarounds to that were much more robust than I realized.)

Netezza put a lot of work for NPS 6 into something it calls “table grooming,” which amounts to recopying tables in more beneficial form. Uses for table grooming – which is a manually initiated process – include but probably aren’t limited to:

• Clustering tables and, as needed, reclustering them.
• Getting rid of data that was deleted. (Netezza has Postgres-style multiversion concurrency control – MVCC – but no time-travel, so keeping around deleted data is a waste of space.)
• Recompressing data from Compress Engine 1 to Compress Engine 2.
• Alter Table

The core ideas of table grooming include:

• The Netezza NPS software copies rows from one place to another.
• Netezza NPS then updates the appropriate metadata.
• Metadata updates are transactional, even though the actual data movement is not.

This can be done part of a table at a time. Reads and loads are unaffected by the process, or at least not blocked. Delete commits are indeed blocked during a reorg, but Netezza guesses that the blocks hold for a few minutes during the grooming of a clustered base table, 10-15 seconds if space is being reclaimed, and something similar for an Alter Table.

And finally, here are some notes on Netezza’s query optimization and planning.

• Netezza has a traditional cost-based optimizer, in which all operations have estimated costs, measured in microseconds, irrespective of which parts of the system (CPU, I/O, network, whatever) they most stress. (I have trouble imagining how a cost-based optimizer could work differently from that without incurring huge computational costs.)
• Netezza’s bottleneck is almost always disk I/O.
• Netezza’s optimizer is not/no longer based on the PostgreSQL optimizer.
• Netezza does a lot of query transformation. Key points include:
  • Netezza joins are usually very cheap.
  • Filtered scans are cheap too.
  • More expensive in Netezza are data redistribution (duh), sorts, and unfiltered scans.
  • Most expensive of all are intermediate result sets that don’t fit into memory.
• Specific examples of Netezza query transformation include:
  • Pushing predicates out to nodes.’
  • Flattening query trees and eliminating subqueries.
  • Rewriting windowed aggregates to be joins + grouped aggregates.
  • (New in 6.0) Transforming outer joins into other kinds.
• Netezza does real-time sampling to help with query planning. (But this is only worth doing for queries that are estimated to be expensive.) Zone maps (and clustering too?) are invoked as part of deciding where to sample. Sampling was for scans only prior to NPS 6.0, and will now be done for joins as well.

Related links

• Notes on this week’s spate of Netezza-related blog posts
• How Netezza (and IBM) do database compression
• Netezza’s silicon balance

After the first one, Netezza Marketing VP Tim Young took me aside for two pieces of constructive criticism. The surprising one* was that he felt I had been INSUFFICIENTLY critical of Netezza. Since then, every other conversation we’ve had about content creation has also featured ringing reassurances that Tim truly wants independent, non-pandering work.

*The unsurprising one was that I’d rushed. Well, duh. After months of telling me I had a 1 hour slot, Netezza cut me to ½ hour a few days beforehand. And my talk had been designed to be high-speed even in the longer time slot …

As a result, I accepted a subsequent gig from Netezza that I would barely consider from most other vendors. Namely, for this year’s Enzee Universe – June 21-23, aka Monday-Wednesday of this week, at the Westin Waterfront Hotel in Boston – I would do some contemporaneous blogging. The parameters we agreed on included: 

• I would just blog here on DBMS2, with Netezza allowed to reuse posts in their entirety on its site(s).
• I also would give a talk on the conference’s last day.
• I wouldn’t say much about conference sessions, because:
  • I’m not a session-attending kind of guy. (I wasn’t particularly good at sitting still in class in 8^th grade. I haven’t gotten much better since. And I have a huge aversion to other people’s uninterruptible PowerPoints.)
  • I think Netezza’s sessions are just as hype-filled as anybody else’s. (Much as I enjoyed traveling around the world with Netezza last year, it was painful hearing Jim Baum claim in city after city that Netezza boasts a 50X performance advantage vs. the competition.)
• Rather, I’d base things much more on individual conversations and meetings.
• Because I didn’t see how turnaround time could work otherwise, we’d have some of those meetings beforehand, and others early in the conference.

That last bit didn’t exactly wholly work out; for the second consecutive year Netezza pulled a surprise schedule switch a few days beforehand. But:

• I did have extensive, fascinating meetings at Netezza’s offices on Thursday, which were the fodder for multiple posts going up today.
• I have a nice meeting schedule set up for Tuesday.
• There should be plenty of opportunity for hallway and exhibit-floor conversation as the conference progresses.
• I even have my own private conference room, with a lovely name (the “Paine Room”).

So far as I know, the rest of the plan is still operative.

Posts already written as I draft this one include:

• A long discussion of Netezza’s technology, focusing on the database parts
• A discussion of Netezza’s and IBM’s compression strategies
• Notes on how Netezza balances its silicon and uses its FPGAs
• A quickie on data warehouse loading latency

I still need to write one focusing on Netezza’s advanced analytics strategy, and plan to edit in a link to it when it’s up.

• How quickly and cost-effectively does it execute SQL?
• What analytic functionality, SQL or otherwise, does it do a good job of executing?

And so, in undertaking such a selection, you need to start by addressing three issues:

• What does “speed” mean to you?
• What does “cost” mean to you?
• What analytic functionality do you need anyway?

Key elements of cost* include:

• Software license and maintenance
• Hardware purchase cost, maintenance, electric power, and computer room burden
• Database and system administration
• (For some uses cases) Programming

*Assuming a classical in-house IT shop, where products are typically bought rather than leased/rented. With outsourced and/or monthly-fee structures, the details change but the principles remain the same.

Most of that can be evaluated pretty well via a spreadsheet, although things can get a bit tricky when you get to people costs, which are a large fraction of the whole. In particular, different analytic DBMS product suites have great, high-performance support for different (and often rapidly growing) sets of functionality – basic and advanced SQL, statistics, and more. Figuring out which ones will be best for your programmers, and how significant the differences are — well, that’s a lot like any other programming language evaluation, and those are rarely neat or clean-cut.

But when it comes to evaluating speed, there’s no substitute for a well-designed proof of concept (POC). Many analytic DBMS and appliance vendors are happy to let you do a POC, on your own premises (or remotely if you prefer), under your control, at no cost to you. And that’s great. It is crucial that a POC be run either by you, by a consultant* answerable to you, or – if you decide the vendor must run it for you – at least with you watching every step of the way and knowing exactly what is being done. Appliance vendors do find it cheaper to run POCs on their own premises, so a certain reluctance to ship you a box is understandable. But make no compromises about the transparency of a POC, or about your control of exactly what it is that gets tested.

*Since I sell consulting services for users evaluating analytic DBMS, I naturally am biased to think that consultants can be very useful in the process. But whether you should use them a little (sanity check), a medium amount (work with you through the process), or heavily (actually drive the process for you and/or execute the POCs) is very dependent upon your specific situation.

So far as I’ve been able to tell:

• Netezza loves to ship boxes to prospects for POCs, and have them set up the boxes and do POCs themselves. That’s a big reason why Netezza wants to call attention to this subject.
• Oracle has generally been pretty reluctant to ship Exadata boxes out for POCs. That’s the other reason Netezza wants to call attention to the issue.
• Open source vendors make it easy for you to download and test at least their community editions.
• Vertica makes it pretty easy for you to test its software too (download or cloud).
• ParAccel has generally insisted on running POCs itself, although it will do so on your premises if you insist.
• Teradata naturally tries to do POCs on its own premises, but doesn’t insist too hard. (Edit: Randy Lea of Teradata says that Teradata is now doing over half its POCs onsite.)
  

Most of the criticisms I’ve heard of vendors’ POC practices have been directed at Oracle or ParAccel.

For most POCs, it’s a good conceptual template to form and then test a hypothesis to the effect of:

• For a given technology product assemblage (brand of DBMS, number of nodes, etc.), and
• For a given level of human effort (e.g., administrative effort), you can
• Run a given a workload, with
• Satisfactory and satisfactorily consistent response times

Sometimes absolute throughput and price/performance are important secondary considerations; sometimes they’re less germane. But either way, it’s almost always right to focus primarily on the questions of “What do I want this system to do?” and “What do I think we’re going to have to invest in it?” By way of contrast, it’s often misleading to focus too much on questions like “What’s the one number that best describes the performance of this system?” — even if you customize that calculation for your environment – or, even worse, “How much speed-up can I get on my single worst Query from Hell?”

The fundamental rule of POC construction is: Model your entire use case as best you can. That means you need to consider, at a minimum:

• Your whole concurrent query, other analytic, and low-latency update workload (peak).
• Your whole query, analytic, load, backup, and maintenance workload (ongoing).
• Partial-failure scenarios.
• Your core SLAs (Service-Level Agreements).

Of course, that’s not as easy as it sounds. Presumably, the main reason you’re getting a new analytic DBMS is that you want to do new kinds of analysis. By the very nature of analytics, you won’t know what analytic operations are most useful until you try them out and see what their results are. On the other hand – if you haven’t done considerable thinking about how you’re going to use your new analytic database, how did you ever get funding for the project in the first place?

Seriously, I could write multiple posts, each as long as this one (but more application-oriented), about how to upgrade your analytic capabilities (and which fool’s gold to avoid). But this has gotten pretty long already, so for now I’ll just stop here.

Note: My clients at Netezza asked me to write something short about POCs they could use as a kind of foreword to some collateral, where by “short” they meant single-paragraph or something like that. They’re great clients, so I said yes, under the condition I could also use it as a blog post. Except … this post didn’t turn out to be nearly as short as they envisioned. Oops.

Related links

• My February, 2009 slide deck on how to select an analytic DBMS is in many parts still pretty current