The immediate hook here is that I had a short conversation with Scott Gnau of Teradata yesterday, triggered by Teradata’s acquisition of Kickfire’s assets. Takeaways from that part included:

• The acquisition is all about Kickfire’s data pipelining technology.
• Scott (in my opinion rightly) thinks that isn’t particularly tied to Kickfire’s choice of particular DBMS architecture (fairly vanilla columnar).
• No decision has been made about whether the right vehicle for this technology is an FPGA (Field Programmable Gate Array), conventional Intel CPU, RAM, etc.

If you want to handicap Teradata’s future data pipelining strategy, you might note that:

• Kickfire’s own choice – and hence its existing implementation – is an FPGA.
• VectorWise’s approach to pipelining is Intel-based, apparently at the cost of being closely tied to specific generations of Intel CPUs.
• XtremeData’s approach to pipelining is FPGA-based.
• Teradata has a lot more development resources than any of those other companies, as well as important existing products, and hence has both means and motive to shoehorn new technology into older system designs.

While I had Scott on the phone, I brought up a few other subjects too. Highlights included:

• Teradata’s Flash-based appliance is doing just fine in beta test and customer POCs (Proofs of Concept).
• Other kinds of Teradata appliance are not inconceivable.
• Scott thinks Michael McIntire’s condemnation of Active-Active architectures is overstated. That said,
  • Scott does acknowledge a need for greater Active-Active scalability, and suggests that the reason Xkoto’s current products are being discontinued is their lack of scaling.
  • Scott seems quietly confident the scaling will get done.
• Scott is emphatic that Teradata is not going to go to a two-tier architecture. In particular, the point of splitting storage/lightweight database processing and heavyweight database processing on separate tiers is generally to save bandwidth, and Teradata’s BYNET is typically less than 10% loaded.
• Scott didn’t dispute my claim that this all suggests Teradata Virtual Storage is the future, at the expense of a rigid delineation among specific use-case-focused product lines.
• Unlike Netezza or Aster, Teradata doesn’t seem to plan analytic capability that works outside the UDF (User Defined Function) framework. However, Scott noted that Teradata has long had the capability that Aster and Netezza now also have of letting you run analytic code either in “protected mode” (if the process fails the whole database doesn’t crash) or in the database kernel (best performance, if you’re sufficiently confident in the code’s stability to take the risk). Scott also spoke of the release later this quarter of Teradata FastPath, which will offer yet better performance (however, there’s a gotcha to Teradata FastPath that’s still NDA).

Putting all that together with the rest of what we know about Teradata, I’m going to call out three pillars of Teradata’s long-term product strategy:

• Same fundamentals as always. Teradata’s core product strategy is:
  • Single DBMS, capable of meeting all analytic needs while running in a single instance, usually running on …
  • … proprietary hardware …
  • … built from conservatively-chosen parts.
• Selective vertical application stack. No matter how horizontally-oriented they are, many companies that have been in the analytic technology business for a while wind up with some vertical applications. It sort of just happens. Teradata is no exception. Teradata also likes to sell services to its product customers, and some of those are quite vertical-aware.
• Mutable, modular platform. This is what I highlighted above. Note that it’s philosophically attuned with the one-system-does-everything approach Teradata prefers. More subtly, please also note that it goes well with customer-by-customer price customization, which is almost a must for Teradata given the Innovator’s Dilemma kind of pricing box it finds itself in.

So far, that’s not too exciting, except in the details of how Teradata’s engineers make that all work. But there’s a fourth pillar to Teradata’s technical strategy as well, and it’s a wild card: tight partnerships. Every time I talk with Teradata hardware chief Carson Schmidt, he seems excited about some particular version of a part or other – sometimes from a reasonably established vendor (once it was LSI Logic), sometimes from a tiny one (notably the “stealth” start-up on which Teradata bet its first solid-state product.) In the future, I expect tight business intelligence partnerships as well. Cognos BI will be increasingly integrated with IBM’s DBMS and hardware; Business Objects’ BI will increasingly be integrated with SAP’s applications; and Oracle’s BI will eventually be integrated with everything. How do you compete with that if you‘re Microstrategy? Well, you try to have superior product, of course – but you also partner as closely with DBMS vendors as you can, an approach Microstrategy has already started. Predictive analytics stalwart SAS, of course, is on a partnership binge as well.

Teradata has a larger installed base than almost all its competitors, and enjoys richer third-party software and service support as a result. But I suspect that going forward, for Teradata to remain a leading competitor at price points it is willing to accept, Teradata’s “ecosystem” advantages will need to ratchet up one or several notches.

• Teradata is discontinuing Xkoto’s existing product Gridscale, which Scott characterized as being too OLTP-focused to be a good fit for Teradata. Teradata hopes and expects that existing Xkoto Gridscale customers won’t renew maintenance. (I’m not sure that they’ll even get the option to do so.)
• The point of Teradata’s technology + engineers acquisition of Xkoto is to enhance Teradata’s active-active or multi-active data warehousing capabilities, which it has had in some form for several years.
• In particular, Teradata wants to tie together different products in the Teradata product line. (Note: Those typically all run pretty much the same Teradata database management software, except insofar as they might be on different releases.)
• Scott rattled off all the plausible areas of enhancement, with multiple phrasings – performance, manageability, ease of use, tools, features, etc.
• Teradata plans to have one or two releases based on Xkoto technology in 2011.

Frankly, I’m disappointed at the struggles of clustering efforts such as Xkoto Gridscale or Continuent’s pre-Tungsten products, but if the DBMS vendors meet the same needs themselves, that’s OK too.

The logic behind active-active database implementations actually seems pretty compelling: 

• You may well be keeping a second copy of your database for high availability/hot standby.
• You might even be keeping a third copy for off-site disaster recovery.
• In some cases, you might have reasons beyond disaster recovery to distribute a database around the world.
• So why not allow queries to be run against all the copies?
• And by the way, splitting the workload up a bit by kinds (e.g., long-running vs. short query) might let you optimize the implementation of each copy of the database. (This last point becomes even more important with the rise of solid-state memory.)

Analytic DBMS vendors pretty much all need to offer this. (Possible exception: If they have a data-mart-only positioning so extreme that customers will never care about any form of failover.) That said, I must confess to not having done a good job of tracking who does or doesn’t have which features in this area to date; informative comments to this post in that regard would be much appreciated!

At this time, I have no idea who the lucky buyer is.

Edit: We now know it’s Teradata.

• 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

However, I chatted briefly Thursday with Michelle Wilkie, who is the SAS product manager overseeing all this (and also some other stuff, like SAS running on grids without being integrated into a DBMS). As best I understood, the story is:

• On Teradata, SAS is shipping in-database scoring today. SAS also is shipping a limited amount of in-database modeling on Teradata, the count recently having gone up from 4 “procs” to 10.
• On Netezza Twinfin(i), SAS is shipping in-database scoring, and this was recently announced. I can’t actually find much evidence of this announcement by searching the Web or the SAS website, but Michelle was pretty clear on the point even so.  Further confusing matters, SAS’ website seems to say in-database scoring is supported on Netezza’s old generation of products but not its latest one, even though SAS CTO Keith Collins told me exactly the opposite would be true.
• On Aster Data nCluster, SAS will ship in-database scoring by the end of 2010. If I understood correctly, this will be for “limited” rather than “general” availability, but Michelle framed that as a distinction without a difference. I.e., if you want to buy in-database SAS scoring on Aster nCluster, you’ll be able to.
• (More) in-database SAS modeling is expected on all of Teradata, Netezza Twinfin(i), and Aster Data nCluster in the vague future. (The concept of 2011/2012 came into play.)
• SAS/Teradata integration, developed first, involved more hand-coding. SAS has subsequently developed some kind of a more general parallelism/in-database capability, akin to what it has in the DBMS-less grid, that either is or isn’t a good match for DBMS vendors’ native way of supporting parallel processing. (Obviously, I’m still pretty unclear on this part.)
• SAS technology is a good fit for Aster Data’s MapReduce-centric way of doing parallelism.

I also took the opportunity to ask Michelle a question I’ve had a heck of a time getting answered: What’s the big-deal about in-database data mining scoring anyway? After all, the most common form of in-database data mining scoring is just to take a weighted sum of specific fields in a row, where the weights are the regression coefficients. You can do that in generic SQL, with performance that superficially should be at least as good as that for any alternative strategy. Michelle’s answers seemed to be twofold:

• There are other kinds of scoring too — neural networks, etc.
• Coding the scoring in SQL isn’t that easy. Michelle gave the example of a specific user (default Netezza reference account, with initials resembling mine) that spent 400 hours writing and testing something you now get for free with SAS/Netezza integration.

Edit: In response to this post, SAS wrote in with further clarification about in-database and/or MPP SAS.

• Manage data to high standards of accuracy, consistency, cleanliness, clarity, and security.
• Manage all the data in your organization.

Pick ONE.

There’s little to dislike in the enterprise data warehouse dream, as represented (for example) in this 2004 Teradata Magazine article. But in a world where ever more data comes in from ever more sources – and is needed ever faster – it simply isn’t realistic to expect that all an enterprise’s data will be vetted, organized, and managed to the highest of standards.

This is a core premise of Greenplum’s Enterprise Data Cloud (EDC)/Chorus marketing initiative, and in that respect Greenplum is correct.

If the EDW is a great idea that can never be 100% implemented, what should you do? At conventional enterprises, the answer is pretty obvious: Manage some of your data to enterprise data warehouse standards, but not all of it. Specifically, your highest-value data should be in something that looks like a classic enterprise data warehouse, and your lower-value data shouldn’t.

Of course, if you’re a data mart outsourcer or other analytic service provider, whose data is about your customers’ businesses rather than your own, and whose business is managing your customers’ data, this may not apply to you. But otherwise it’s a position with many supporting arguments, including:

• Financial reporting, compliance, and other legitimate concerns introduce rigidity into data models. This increases the cost and reduces the speed of getting data into enterprise data warehouses.
• Data governance procedures imposed for any other business purpose have the same effect. What’s deemed necessary for enterprise data warehouses can be fatal to timely analytics.
• The highest-value data typically comes from transactional systems, such as order entry or sales contact management. So it starts out with a degree of governance that, say, web log files may never enjoy.
• In some enterprises, it is affordable or even cost-effective to manage your highest-value data in your favorite big-brand DBMS, but necessary to manage most of your data in something with lower TCO (Total Cost of Ownership). Big-brand OLTP DBMS are often better (or at least less bad) at managing enterprise data warehouses than they are at running data mart workloads.
• At certain enterprise and database sizes, it may indeed make sense to run what amounts to an enterprise data warehouse out of the same database instance that does OLTP, while putting larger data sets into more cost-effective data marts. A trend to “operational BI” may actually make that option more appealing going forward than it has been in the past.
• And finally, there’s the empirical fact that not one really large enterprise on the whole planet has a true, perfectly comprehensive enterprise data warehouse. At least, I’ve never heard of one.

Related links

• Even Teradata doesn’t push an EDW-only strategy any more
• I agreed when Greenplum first started pushing the EDC idea that something like it would be the future of data marts

• Business is strong. Multiple vendors claim to be going gangbusters, with the happy sounds coming out of Vertica and Infobright being echoed by several competitors. Hearsay suggests some other companies in related businesses are doing well too. Depending on who you talk to, the business pickup dates back to Q4, give or take a quarter.
• Oracle Exadata has become a formidable competitor, on the strength of Exadata 2. Exadata 2’s positioning and perception among Oracle users seem to be pretty much in line with what Oracle portrayed to me.
• Teradata is portrayed as a weak competitor. Competitors don’t worry about Teradata nearly as much as they do about Oracle. That said, I suspect a bit of wishful thinking; Teradata is clearly still getting a lot of business the other vendors would dearly love to have.
• HP Neoview is reeling. (Almost) nobody sees Neoview competitively. The Walmart Neoview installation is said to have stayed small at best. JP Morgan Chase is said to have completely thrown Neoview out (and a bunch of HP engineers with it).
• (Almost) nobody mentions competing against DB2 either. This continues to baffle me.

*I probably have it worse than most people in that regard, because my clients run tentative feature lists and announcement schedules by me well in advance, which may get changed multiple times before the final dates roll around. I also occasionally miss some detail, if it wasn’t in a pre-briefing but gets added at the end.

Anyhow, the three big themes of this month’s announcements are probably:

• Integrating different kinds of analytic processing into databases and DBMS.
• Taking advantage of hardware advances.
• Playing catchup in areas where small vendors’ products weren’t mature yet.

For example, the three biggest data warehouse DBMS product announcements this month are probably:

• Aster Data nCluster 4.5. Much like Aster’s prior release — Aster Data nCluster 4.0 – Aster Data nCluster 4.5 has a major focus on integrating analytics and database processing. This time, the emphasis is on application development tools and pre-built analytic packages. In addition, Aster’s management tool GUIs have been upgraded, building on catch-up functionality in the Aster Data nCluster 4.0.
• Netezza’s “i” add-on to its existing TwinFin products. With Netezza TwinFin(i), Netezza becomes the second MPP RDBMS vendor with a comprehensive “Big Data Analytic Platform” kind of strategy. (Netezza would surely argue that it was the first, but that depends on how seriously one took Netezza’s prior attempt.) Many of the details are different from Aster’s, of course, but the general philosophy is similar. So far, Netezza has announced one interesting proprietary library of analytic packages (for linear/matrix algebra), plus the port of 4,000 or so functions in open source libraries.
• Vertica 4.0. Vertica has had a highly innovative columnar DBMS architecture from the getgo, but at the cost of some restrictions or awkwardness in the relationship between data layout and SQL processing. Vertica says that Vertica 4.0 fixes all that. In addition, it has some analytic processing enhancements, especially in the time series area, where Vertica doesn’t vigorously dispute that Sybase IQ previously had an advantage.

In addition,

• Teradata is announcing its Data Warehouse Appliance 2580, the successor to the Teradata 2550. This is purely a hardware refresh; Teradata’s hardware and software upgrades are not generally synced. The Teradata 2580 upgrades CPUs from Harpertown to Nehalem, includes 3X the RAM of its predecessor, and offers an option for 1 TB disks (thus lowering the bottom price/TB a lot, to $31K list).
• Aster, Vertica, and ParAccel have all called attention to the fact that, if solid-state drives have interfaces like those of disk drives, and if a DBMS supports disk drives, then a DBMS also supports solid-state drives as well. At least Aster and ParAccel have signaled that they have at least one customer or prospect each interested in Fusion I/O’s solid-state technology, especially in the retail sector. This is basically a hardware matter as well, and a big deal only for those who were somehow unaware of the impending dominance of solid-state memory technology.
• Sybase announced its Aleri acquisition earlier this month.
• Various vendors have bragged about various rankings, awards, or benchmarks, or – sometimes less tediously — about last year’s sales results.

• Netezza’s software runs on well-designed proprietary hardware. Aster runs on hardware that’s more off-the-shelf.
• Aster was first to ship, and will also be first to ship an IDE (Integrated Development Environment).
• MapReduce is central to Aster’s approach. Netezza TwinFin(i) supports MapReduce too, specifically a Hadoop implementation, but I don’t get the sense that everything Netezza does is built on MapReduce underpinnings.
• Both Aster and Netezza try to provide rich functionality for creating in-memory data structures parallel analytic programs can use. Both seem to let you escape from the pure relational-table paradigm more easily than, say, Teradata’s new persistent memory capabilities do.
• Aster and Netezza have made different choices about what kinds of prebuilt analytic packages to offer. Netezza could actually leapfrog Aster in this regard, but let’s see where each vendor is by, say, mid-year. If you care about the details of built-in analytic functions, you really should consider executing non-disclosure agreements with both those companies.
• Both Aster and Netezza stress that you can run analytic functions out-of-process, greatly reducing the chance that they crash the database. Netezza and I’m pretty sure also Aster also retain the option of running in-process, which provides maximum performance. (In Netezza’s case C++ is the only in-process language supported, and I think Aster has a similar limitation.)
• Like Aster, Netezza is integrating SQL queries and other analytic processing under the same workload management rubric.
• Much like Aster, Netezza is tap-dancing by implying much richer forthcoming SAS support than anything currently announced. (The crunch-per-paragraph ratio in either vendor’s SAS-related press releases to date is distressingly low.)

More specifically, here are some highlights of what I know, am guessing, and/or am allowed to say about Netezza TwinFin(i) at this time.

• The foundation for the analytic add-ons in Netezza TwinFin(i) is some sort of low-level “analytic executables.” Not understanding exactly what these are is my biggest area of confusion in the whole TwinFin(i) stack. Are they all C++, with everything translated into same? Is there Java all the way down as an alternative? (E.g., Hadoop is written in Java.) Anyhow, whatever it is, it’s surely a big improvement on Netezza’s prior Verilog-based generation of analytic extensibility technology.
• The announced list of languages supported in Netezza TwinFin(i) is Java, Python, Fortran, R, and C/C++. More are coming.
• Netezza has named a lot of analytic functions it is adding, and hinting about more to come. It has named CRAN/R and GNU libraries, saying those have 1900 or more functions each. Netezza has also built its own linear algebra library for TwinFin(i), called nzMatrix. And as previously noted, TwinFin(i) also boasts a Hadoop implementation.
• I haven’t heard about much in the way of TwinFin(i)-specific IDE support.
• I don’t really have details as to what kinds of in-memory data structures Netezza TwinFin(i) does or doesn’t support.

• Aster Data Analytic Foundation, a set of analytic packages prebuilt in Aster’s SQL-MapReduce
• Aster Data Developer Express, an Eclipse-based IDE (Integrated Development Environment) for developing and testing applications built on Aster nCluster, Aster SQL-MapReduce, and Aster Data Analytic Foundation

And in other Aster news:

• Along with the development GUI in Aster nCluster 4.5, there is also a new administrative GUI.
• Aster has certified that nCluster works with Fusion I/O boards, because at least one retail industry prospect cares. However, that in no way means that arm’s-length Fusion I/O certification is Aster’s ultimate solid-state memory strategy.
• I had the wrong impression about how far Aster/SAS integration has gotten. So far, it’s just at the connector level.

Aster Data Developer Express evidently does some cool stuff, like providing some sort of parallelism testing right on your desktop. It also generates lots of stub code, saving humans from the tedium of doing that. Useful, obviously.

But mainly, I want to write about the analytic packages. I’m not convinced that they’re a big deal in themselves yet, or that a whole lot of person-months have gone into their combined development. Still, I think they provide a great indication of one direction in which analytic functionality is going. And by the way, Aster promises to release a lot more of that kind of thing over the next 12 months.

Aster’s flagship analytic package is nPath, which is like a regular expression matcher, but for (time) series of data rather than for character strings. The main use for nPath is in pulling specific kinds of event sequences out of web or network event logs. However, one could imagine uses in other sectors that focus on temporal or sequential data (e.g., trading, intelligence, other sensor analysis), should existing SQL- and/or CEP-based technologies not prove sufficiently flexible. Aster 4.5 adds some new aggregation capabilities around nPath.

Other not-wholly-new packages in the Aster Data Analytic Foundation announcement are for sessionization (of clickstream data and the like) and tokenization (of text/character string data). While sessionization can be done in SQL, Aster thinks its MapReduce-based version is faster, since it doesn’t require self-joins. Makes sense. Aster’s tokenization sounds lame, however – text analytics in MapReduce tends to reinvent simplistic wheels for no clear reason, and Aster doesn’t seem to be an exception. (Aster would argue, however, that anything it does in SQL-MapReduce is more flexible than pure SQL or pure MapReduce alternatives.)

Another example of better-living-without-self-joins is Aster’s new market basket package. This lets you look at a set of point-of-sale data, pick a small integer N, and pull out all the sets of N things that were bought by the same person at the same time. I haven’t probed the claim in detail, but Aster implies there’s less combinatorial explosion in its approach than it is in the self-join alternative.

Note: Gartner highlighted self joins as a performance challenge in its recent Data Warehouse Magic Quadrant.

Aster is also releasing a few statistical and general analytic functions — specifically (and I quote a slide):

• exponential moving average
• weighted moving average
• simple moving average
• volume-weighted average price
• correlation
• linear regression
• logistic regression
• approximate_percentile
• approximate_count_distinct

The point of the last two items on the list is that if you set a non-zero tolerance for error, you can you can count things or order them into bins very efficiently – especially in terms of RAM — while being guaranteed not to exceed your error tolerance.

Note: One obvious inference from this list — which Aster gladly confirms — is that Aster has high hopes of selling to the financial services industry.

Finally, Aster is releasing its first pure graph-analytic function, for finding the shortest path between a given pair of nodes.

While I had the Aster folks on the phone anyway, I also took the opportunity to ask about the Aster nCluster 4.0 capability to create fairly persistent non-relational in-memory data structures. Specifically, I asked whether different users could access the same in-memory structure, and was told that this is a little klugey but not too horrendous. That suggests Aster’s capability may be a strict superset of UDF-based (User-Defined Function) approaches to meeting the same need, at least from a functionality standpoint. However, ease of creating those in-memory structures may still be better in the more SQL/UDF-centric approach favored by Teradata.