PlanetMysql.ru — информация о СУБД MySQL

The MySQL Enterprise Backup (MEB) Team is pleased to announce the release of MEB 3.7.0, with several exciting and advanced features to benefit a wide audience. Included in this release are,

• Redo Log only Incremental Backup
• Incremental Backup without specifying LSN
• Validation of Backup Image using checksums
• Hot Backup of InnoDB .frm files
• Performance Improvements and
• Enhancements for Third-Party Media Managers 

 The gist and usefulness of all these new features are described in short below,

Redo Log Only Incremental Backup:
This is a new type of incremental backup that copies only the InnoDB redo log accumulated since the previous full or incremental backup. The original incremental backup technique copies from the InnoDB data files only those pages that were modified since the previous backup. This incremental backup technique based on the redo log is much faster in most cases than incremental backups that read the data files, if incremental backups are taken frequently. You can choose this new method by specifying the --incremental-with-redo-log-only option on the mysqlbackup command line.

Performance Improvements:
Performance of backup-related I/O operations is improved, particularly on Windows, by reusing I/O library code and best practices from the MySQL Server product. To avoid memory fragmentation and overhead from frequent malloc() / free() sequences, the mysqlbackup command now does all read, compress, uncompress, and comparison operations within a fixed-size buffer that remains allocated while the command runs.

Validation of Backup Image using Checksums:
The new validate option of the mysqlbackup command tests the individual files within a single-file backup using a checksum mechanism. Validation helps to verify the integrity of the single-file backup image as the image file is moved between servers and thereby ensure that backups are reliable and consistent.

Hot Backup of InnoDB .frm files:
With this new feature, you do not have to manually copy the .frm files to perform restore. The new option --only-innodb-with-frm performs an InnoDB-only backup and backs up even the .frm files of InnoDB tables in non locking mode. Formerly, the InnoDB-only backup required putting the database briefly into a read-only state and copying the .frm files within your own backup script.

Enhancements to Third-Party Media Managers:
 To customize the interactions between MySQL Enterprise Backup and media management software (MMS), the --sbt-environment option lets you pass application-specific environment settings to the MMS (for example, Oracle Secure Backup). Each vendor that uses the SBT programming interface could implement its own set of environment variables. The --sbt-environment variable lets you pass environment variable values from any invocation method (for example, a Makefile) rather than setting and unsetting the variables within a wrapper shell script.

For more information about MEB features and examples, please see the MEB documentation located <http://dev.mysql.com/doc/mysql-enterprise-backup/3.7/en/index.html>. My sincere thanks to Lars Thalmann, Sanjay Manwani and all the MEB team members, who have provided valuable features and improvements for every release.

Download the MEB 3.7.0 package from the Oracle Software Delivery Cloud web site <https://edelivery.oracle.com/>. MySQL Enterprise customers can begin deploying MEB 3.7.0 immediately. Users without a MySQL Enterprise license can evaluate MEB 3.7.0 for free for 30 days; please try it out and send your feedback to mysql-backup_ww@oracle.com.

Someone will probably tell me that this is an elementary-level topic, but I got some good questions regarding joins from my most recent ZCE class students, so I thought I'd put down the examples that I used to explain this to them. Being able to join with confidence is a key skill, because it means that you can refactor and normalise your data, without worrying about how hard something will be to retrieve.

The database structure I'm using here looks like this (the same example that I used when I wrote the Databases chapter for PHP Master):

If you want to grab the actual data I'm using for my examples, then here's the zipped mysqldump file: recipes-db.sql.

The database includes a "many-to-many" relationship; each recipe is linked to the ingredients needed for this particular dish, while each ingredient can of course appear in many dishes. To represent this, there is a recipes table, an ingredients table, and a recipe_ingredients table to show the combinations which apply. To join twice and understand whether you're getting all the rows or just the ones with matches in all the tables can be confusing, so this post is all about showing you some examples.

Fetching Matching Records From All the Tables

Let's say we want to see which ingredients are in which recipe. We'll do this in a number of steps, which I will show below, along with the query and result that goes with that step.

Get all the recipes

mysql> SELECT id, name FROM recipes;
+----+-------------------+
| id | name              |
+----+-------------------+
|  1 | Apple Crumble     |
|  4 | Beans Chili       |
|  5 | Chicken Casserole |
|  2 | Fruit Salad       |
|  3 | Weekday Risotto   |
+----+-------------------+
5 ROWS IN SET (0.00 sec)

OK, so we have some recipes, looking at the relationship diagram, we can see we need to link across to recipe_ingredients using the ID of each recipe.

All recipes, linked with recipe_ingredients

mysql> SELECT r.id AS recipe_id, r.name, ri.ingredient_id 
FROM recipes r 
JOIN recipe_ingredients ri ON (r.id = ri.recipe_id);
+-----------+---------------+---------------+
| recipe_id | name          | ingredient_id |
+-----------+---------------+---------------+
|         1 | Apple Crumble |             1 |
|         1 | Apple Crumble |             5 |
|         1 | Apple Crumble |             7 |
|         1 | Apple Crumble |             8 |
|         2 | Fruit Salad   |             6 |
|         2 | Fruit Salad   |             2 |
|         2 | Fruit Salad   |             1 |
|         2 | Fruit Salad   |             3 |
|         2 | Fruit Salad   |             4 |
+-----------+---------------+---------------+
9 ROWS IN SET (0.00 sec)

There are a couple of different things going on here. Firstly, I have aliased the table names to r and ri respectively. This is so that they are less in the way of us reading the important bits! Since there are multiple tables in the query now, it is important to "qualify" the table names - to say which table this column belongs to so that if there is more than one id column, it's obvious which one you meant.

Secondly, there is now a join between two tables. The query doesn't specify what kind of join it is, but the default join type is INNER JOIN. You might notice that not all of the recipes appear in this result set - only the ones where there are matching records in the recipes_ingredients table will match this query. To get all of the records, we would use an outer join - more on that later.

All the recipes, their ingredients, and the actual display information for those ingredients

To get more than the ingredient_id, we need to join on the ingredients table to get the details. This is a very common type of join, we'll use it when we're linking to pretty much any kind of detail record by its ID. Once again, it's an inner join, and it looks like this:

mysql> SELECT r.id AS recipe_id, r.name, ri.ingredient_id, i.item
FROM recipes r
JOIN recipe_ingredients ri ON (r.id = ri.recipe_id)
JOIN ingredients i ON (ri.ingredient_id = i.id);
+-----------+---------------+---------------+--------------+
| recipe_id | name          | ingredient_id | item         |
+-----------+---------------+---------------+--------------+
|         1 | Apple Crumble |             1 | apple        |
|         1 | Apple Crumble |             5 | flour        |
|         1 | Apple Crumble |             7 | butter       |
|         1 | Apple Crumble |             8 | sugar        |
|         2 | Fruit Salad   |             6 | fruit juice  |
|         2 | Fruit Salad   |             2 | banana       |
|         2 | Fruit Salad   |             1 | apple        |
|         2 | Fruit Salad   |             3 | kiwi fruit   |
|         2 | Fruit Salad   |             4 | strawberries |
+-----------+---------------+---------------+--------------+
9 ROWS IN SET (0.00 sec)

And there you have it - a many-to-many relationship join across three tables. Now you have this result, you can start adding whatever "where" clauses you need to get exactly the information you're after. This dataset includes chef and category, so you could search by all pudding recipes for example (my favourite!)

All the Records, Even Those Without Matches (Outer Join)

How about those "lost" recipes, the ones without details of their ingredients? You might want to include them in your results even if the chef didn't include ingredient details yet. To do this, we'll use an outer join.

The outer join brings in all the records, plus any matching ones. So in our example, we'll see all recipes, plus any ingredients records that match. If there are no ingredients that match, then we'll still get those records, but with a NULL in the ingredients fields.

Outer joins come in two flavours: LEFT and RIGHT. The way that I think of this is that the first table is the one on the left; if you want all the records from that first table, plus any matches from the second, you'll choose LEFT. If you want all the records from the second table, plus information from the first one if there is any, you'll choose RIGHT. Take a look at the diagram at the top of this post, and you'll see that we have the recipes table on the left of the diagram, and first in our query, so we'll be using a LEFT join here. (as a complete aside, I almost always have left joins, because I build up my queries that way around: getting the records I want, then the additional information to go with them, and so on. Maybe that's just the way my brain works?). Here's our recipes and ingredients again, but including the recipes without ingredients:

mysql> SELECT r.id AS recipe_id, r.name, ri.ingredient_id, i.item 
FROM recipes r 
LEFT JOIN recipe_ingredients ri ON (r.id = ri.recipe_id)
LEFT JOIN ingredients i ON (ri.ingredient_id = i.id);
+-----------+-------------------+---------------+--------------+
| recipe_id | name              | ingredient_id | item         |
+-----------+-------------------+---------------+--------------+
|         1 | Apple Crumble     |             1 | apple        |
|         1 | Apple Crumble     |             5 | flour        |
|         1 | Apple Crumble     |             7 | butter       |
|         1 | Apple Crumble     |             8 | sugar        |
|         4 | Beans Chili       |          NULL | NULL         |
|         5 | Chicken Casserole |          NULL | NULL         |
|         2 | Fruit Salad       |             6 | fruit juice  |
|         2 | Fruit Salad       |             2 | banana       |
|         2 | Fruit Salad       |             1 | apple        |
|         2 | Fruit Salad       |             3 | kiwi fruit   |
|         2 | Fruit Salad       |             4 | strawberries |
|         3 | Weekday Risotto   |          NULL | NULL         |
+-----------+-------------------+---------------+--------------+
12 ROWS IN SET (0.00 sec)

Since we're working on a many-to-many relationship here, we're joining three tables in total. This means two joins: one between the first table and the linking table, and another from the result of that query to the other end of the relationship. In this example, this means we had two left joins. Each join operates between two data sets, which are the resultset you have so far, and the new table that is being joined. Since we still want to have records from the recipe/recipe_ingredients join even if there isn't a matching record in ingredients, then the second join here also needs to be an outer join.

Joining All Tables

My initial diagram showed five tables in all, so here's the query and result for pulling all that data together:

mysql> SELECT r.name AS recipe, c.name AS category, ch.name AS chef, i.item AS ingredient
FROM recipes r 
LEFT JOIN recipe_ingredients ri ON (r.id = ri.recipe_id)
LEFT JOIN ingredients i ON (ri.ingredient_id = i.id)
INNER JOIN chefs ch ON (r.chef_id = ch.id)
INNER JOIN categories c ON (r.category_id = c.id);
+-------------------+----------+-------+--------------+
| recipe            | category | chef  | ingredient   |
+-------------------+----------+-------+--------------+
| Weekday Risotto   | Main     | Lorna | NULL         |
| Beans Chili       | Main     | Lorna | NULL         |
| Chicken Casserole | Main     | Lorna | NULL         |
| Apple Crumble     | Pudding  | Lorna | apple        |
| Apple Crumble     | Pudding  | Lorna | flour        |
| Apple Crumble     | Pudding  | Lorna | butter       |
| Apple Crumble     | Pudding  | Lorna | sugar        |
| Fruit Salad       | Pudding  | Lorna | fruit juice  |
| Fruit Salad       | Pudding  | Lorna | banana       |
| Fruit Salad       | Pudding  | Lorna | apple        |
| Fruit Salad       | Pudding  | Lorna | kiwi fruit   |
| Fruit Salad       | Pudding  | Lorna | strawberries |
+-------------------+----------+-------+--------------+
12 ROWS IN SET (0.00 sec)

Once you have this dataset, you can filter it down any way you want to. Since the chef and category elements are required fields, I used inner joins for those; left joins would have given the same results though on this dataset.

If you were looking for examples of inner and outer joins across a real (if simple!) database with multiple joins, I hope this helped. All this talking about food is making me hungry, I'm off to the kitchen :)

Lorna is an independent web development consultant, writer and trainer, open source project lead and community evangelist. This post was originally published at LornaJane

There has been a lot going on in MySQL community and I didn’t blogged about MySQL for some time. So this is a small update regarding MySQL in openSUSE Build Service and in openSUSE in general. This post is intended to let you know what, where and in which version we’ve got in Build Service And as I recently dropped server:database:UNSTABLE repo, everything is now in server:database, so the where part is quite easy

MySQL Community Server

First, let’s take a look at MySQL Community Server provided by the open source company we all love – Oracle. There are several versions around. Which one is the right one for you? That question you have to decide by yourself, but whichever it is, we’ve got in in obs

MySQL 5.5

MySQL 5.5 was in the in repositories for quite some time. Currently there is a version 5.5.18. You can get it by installing package mysql-community-server from server:database repository. As 5.5 is around a long time already and widely tested (was running my blog for several months) it is also the version shipped with openSUSE 12.1. Although version included there is just 5.5.16. But that’s good anyway, isn’t it?

MySQL 5.6

Do you think that MySQL 5.5 is old and not cool anymore? I kind of agree. Where is the fun in stable things So if you want, you can start testing the new cool branch people are speaking about – MySQL 5.6.2. You can find it in server:database repository as package mysql-community-server_56.

MariaDB

Now let’s talk a little bit about the stuff that folks from Monty Program are working on.

MariaDB 5.2

As for MariaDB, there is version 5.2.10 available in the server:database repository and version 5.2.9 made it to openSUSE 12.1. So you can choose from who do you want your MySQL even in distribution itself

MariaDB 5.3

As I said already, I don’t like stable stuff, I like living on the edge. The bleeding edge So if you like Maria but want the newest and coolest, we’ve got that too. You can get MariaDB 5.3.2 from server:database repository (package mariadb_53) right now and try it out! That is the MySQL version I’m using for this blog right now But who knows what variant I will be using next month or year?

MySQL Cluster

Do you want more options? Do you want to play with cluster? We’ve got that too

MySQL Cluster 7.1

For the conservative folks, we’ve got MySQL Cluster 7.1.17 in server:database repository and version 7.1.15 was included in openSUSE 12.1. As you may have read already, I dropped MySQL Cluster from openSUSE Factory, so there will be probably no MySQL Cluster in next openSUSE. But don’t worry, it will still be here in server:database repository

MySQL Cluster 7.2

Do you want to play some more with clusters? We’ve got also MySQL Cluster 7.2.1 in server:database repository (package mysql-cluster_72). So you can try new beta, play with new features and try to make it crash. I think Oracle will be happy if you will manage to and will tell them about it

Switching around

Thanks to the setup we’ve got in openSUSE it is quite easy to switch between all variants as you like. Is there really cool new feature you are dying to try in MySQL 5.6? No problem if you have server:database repository. Just type in:

# zypper in mysql-community-server_56

Have Oracle done something bad and are you angry at them? Do you want your symbolic virtual revenge? Just type in:

# zypper in mariadb

What will happen? Well regardless of what would you try to install, zypper will tell that it is not possible to have two different variants at the same time. And it will let you choose. Either you will continue with installation and deinstall your old variant, or you will cowardly decide to stick with what you have. Quite simple, isn’t it? There is one little catch… Your old configuration will be saved as my.cnf.rpmsave and you’ll  end up with default configuration. But you can solve this one easily
What do we still miss from widely used stuff in our repositories is Percona. But I created Google Code-In task, so maybe some student will step-up and fix this. And even if nobody will, you can always try to be that volunteer I tried to put together some HowTo contribute to MySQL in openSUSE, so it shouldn’t be hard

Overall, if you want to play with MySQL, I think we are well prepared

DrupalDownUnder 2012 will be held in Melbourne Australia 13-15 January. A great event, I’ve been to several of its predecessors. People there don’t care an awful lot for databases, but they do realise that sometimes it’s important to either learn more about it or talk to someone specialised in that field. And when discussing general infrastructure, resilience is quite relevant. Clients want a site to remain up, but keep costs low.

I will teach pre-conference training sessions on the Friday at DDU:

• MySQL Query Design ($220 half-day)
• MySQL Server Tuning ($220 half-day)

The material is made specific to Drupal developers and users. The query design skills, for instance, will help you with module development and designing Drupal Views. The two half-days can also be booked as a MySQL Training Pack for $395.

On Saturday afternoon in the main conference, I have a session Scaling out your Drupal and Database Infrastructure, Affordably covering the topics of resilience, ease of maintenance, and scaling.

I’m honoured to have been selected to do these sessions, I know there were plenty of submissions from excellent speakers. As with all Drupal conferences, attendees also vote on which submissions they would like to see.

After DDU I’m travelling on to Ballarat for LinuxConfAU 2012, where I’m not speaking in the main program this year, but will have sessions in the “High Availability and Storage” and “Business of Open Source” miniconfs. I’ll do another post on the former – the latter is not related to Open Query.

This recent session at OSDC 2011 Canberra is based on part of an Open Query training day, and (due to time constraints) without much of the usual interactivity, exercises and further MySQL specific detail. People liked it anyway, which is nice! The info as presented is not MySQL specific, it provides general insight in how databases implement concurrency and what trade-offs they make.

See http://2011.osdc.com.au/sqll for the talk abstract.

This is not really a blog post. I just would like to know you opinion on state of MySQL at openSUSE and openSUSE Build Service. But I’m interested in your feedback even if you are not using openSUSE or even if you are not using packages I provide. As my TODO is quite long and I can’t do everything, I would like to know what should I pay the most attention to. Later I will publish a post about the current state of MySQL and how you can participate

70x Higher Performance, Cross Data Center Scalability and New NoSQL Interface

Its been an exciting week for all involved with MySQL Cluster, with the announcement of the second Development Milestone Release (7.2.1) at Oracle Open World. Highlights include:

- Enabling next generation web services: 70x higher complex query performance, native memcached API and integration with the latest MySQL 5.5 server

- Enhancing cross data scalability: new multi-site clustering and enhanced active/active replication

- Simplified provisioning: consolidated user privileges.

You can download the DMR for evaluation now from: http://dev.mysql.com/downloads/cluster/ (select Development Milestone Release tab).

70x Higher Performance with Adaptive Query Localization (AQL)

Previewed as part of the first MySQL Cluster DMR, AQL is enabled by a new Index Statistics function that allows the SQL optimizer to build a better execution plan for each query.

As a result, JOIN operations are pushed down to the data nodes where the query executes in parallel on local copies of the data. A merged result set is then sent back to the MySQL Server, significantly enhancing performance by reducing network trips.

Take a look at how this is used by a web-based content management to increase performance by 70x

Adaptive Query Localization enables MySQL Cluster to better serve those use-cases that have the need to run real-time analytics across live data sets, along with high throughput OLTP operations. Examples include recommendations engines and clickstream analysis in web applications, pre-pay billing promotions in mobile telecoms networks or fraud detection in payment systems.

New NoSQL Interface and Schema-less Storage with the memcached API

The memcached interface released as an Early Access project with the first MySQL Cluster DMR is now integrated directly into the MySQL Cluster 7.2.1 trunk, enabling simpler evaluation.

The popularity of Key/Value stores has increased dramatically. With MySQL Cluster and the new memcached API, you have all the benefits of an ACID RDBMS, combined with the performance capabilities of Key/Value store.

By default, every Key / Value is written to the same table with each Key / Value pair stored in a single row – thus allowing schema-less data storage. Alternatively, the developer can define a key-prefix so that each value is linked to a pre-defined column in a specific table.

Of course if the application needs to access the same data through SQL then developers can map key prefixes to existing table columns, enabling Memcached access to schema-structured data already stored in MySQL Cluster.

You can read more about the design goals and implementation of the memcached API for MySQL Cluster here.

Integration with MySQL 5.5

MySQL Cluster 7.2.1 is integrated with MySQL Server 5.5, providing binary compatibility to existing MySQL Server deployments. Users can now fully exploit the latest capabilities of both the InnoDB and MySQL Cluster storage engines within a single application.

Users simply install the new MySQL Cluster binary including the MySQL 5.5 release, restart the server and immediate have access to both InnoDB and MySQL Cluster!

Enhancing Cross Data Center Scalability: Simplified Active / Active Replication

MySQL Cluster has long offered Geographic Replication, distributing clusters to remote data centers to reduce the affects of geographic latency by pushing data closer to the user, as well as providing a capability for disaster recovery.

Geographic replication has always been designed around an Active / Active technology, so if applications are attempting to update the same row on different clusters at the same time, the conflict can be detected and resolved. With the release of MySQL Cluster 7.2.1, implementing Active / Active replication has become a whole lot simpler. Developers no longer need to implement and manage timestamp columns within their applications. Also rollbacks can be made to whole transactions rather than just individual operations.

You can learn more here.

Enhancing Cross Data Center Scalability: Multi-Site Clustering

MySQL Cluster 7.2.1 DMR provides a new option for cross data center scalability – multi-site clustering. For the first time splitting data nodes across data centers is a supported deployment option.

Improvements to MySQL Cluster’s heartbeating mechanism with a new “ConnectivityCheckPeriod” parameter enables greater resilience to temporary latency spikes on a WAN, thereby maintaining operation of the cluster.

With this deployment model, users can synchronously replicate updates between data centers without needing conflict detection and resolution, and automatically failover between those sites in the event of a node failure.

Users need to characterize their network bandwidth and latencies, and observe best practices in configuring both their network environment and Cluster. More guidance is available here.

User Privilege Consolidation

User privilege tables are now consolidated into the data nodes and centrally accessible by all MySQL servers accessing the cluster.

Previously the privilege tables were local to each MySQL server, meaning users and their associated privileges had to be managed separately on each server. By consolidating privilege data, users need only be defined once and managed centrally, saving Systems Administrators significant effort and reducing cost of operations.

Summary

The MySQL Cluster 7.2.1 DMR enables new classes of use-cases to benefit from web-scale performance with carrier-grade availability.

You can download the DMR for evaluation now from: http://dev.mysql.com/downloads/cluster/ (select Development Milestone Release tab).

You can learn more about the MySQL Cluster architecture from our Guide to scaling web databases. 

Let us know what you think of these enhancements directly in comments of this or the associated blogs. We look forward to working with the community to perfect these new features.

Oracle's turn-about announcement of a NoSQL product wasn't really surprising. When Oracle spends time and effort putting down a technology, you can bet that its secretly impressed, and trying to re-implement it in its back room. So Oracle's paper "Debunking the NoSQL Hype" should really have been read as a backhanded product announcement. (By the way, don't click that link; the paper appears to have been taken down. Surprise.)

I have to agree with DataStax and other developers in the NoSQL movement: Oracle's announcement is a validation, more than anything else. It's certainly a validation of NoSQL, and it's worth thinking about exactly what that means. It's long been clear that NoSQL isn't about any particular architecture. When databases as fundamentally different as MongoDB, Cassandra, and Neo4J can all be legitimately characterized as "NoSQL," it's clear that NoSQL isn't a "thing." We've become accustomed to talking about the NoSQL "movement," but what does that mean?

As Justin Sheehy, CTO of Basho Technologies, said, the NoSQL movement isn't about any particular architecture, but about architectural choice. For as long as I can remember, application developers have debated software architecture choices with gusto. There were many choices for the front end; many choices for middleware; and careers rose and fell based on those choices. Somewhere along the way, "Software Architect" even became a job title. But for the backend, for the past 20 years there has really been only one choice: a relational database that looks a lot like Oracle (or MySQL, if you'd prefer). And choosing between Oracle, MySQL, PostgreSQL, or some other relational database just isn't that big a choice.

Did we really believe that one size fits all for database problems? If we ever did, the last three years have made it clear that the model was broken. I've got nothing against SQL (well, actually, I do, but that's purely personal), and I'm willing to admit that relational databases solve many, maybe even most, of the database problems out there. But just as it's clear that the universe is a more complicated place than physicists thought it was in 1990, it's also clear that there are data problems that don't fit 20-year-old models. NoSQL doesn't use any particular model for storing data; it represents the ability to think about and choose your data architecture. It's important to see Oracle recognize this. The company's announcement isn't just a validation of key-value stores, but of the entire discussion of database architecture.

Of course, there's more to the announcement than NoSQL. Oracle is selling a big data appliance: an integrated package including Hadoop and R. The software is available standalone, though Oracle clearly hopes that the package will be running on its Exadata Database hardware (or equivalent), which is an impressive monster of a database machine (though I agree with Mike Driscoll, that machines like these are on the wrong side of history). There are other bits and pieces to solve ETL and other integration problems. And it's fair to say that Oracle's announcement validates more than just NoSQL; it validates the "startup stack" or "data stack" that we've seen in many of most exciting new businesses that we watch. Hadoop plus a non-relational database (often MongoDB, HBase, or Cassandra), with R as an analytics platform, is a powerful combination. If nothing else, Oracle has given more conservative (and well-funded) enterprises permission to make the architectural decisions that the startups have been making all along, and to work with data that goes beyond what traditional data warehouses and BI technologies allow. That's a good move, and it grows the pie for everyone.

I don't think many young companies will be tempted to invest millions in Oracle products. Some larger enterprises should, and will, question whether investing in Oracle products is wise when there are much less expensive solutions. And I am sure that Oracle will take its share of the well-funded enterprise business. It's a win all around.

Web 2.0 Summit, being held October 17-19 in San Francisco, will examine "The Data Frame" — focusing on the impact of data in today's networked economy.

Save $300 on registration with the code RADAR

Related:

• Oracle's Big Data Appliance: what it means


• Oracle's big data week


• Hadoop: What it is, how it works, and what it can do


• Building data startups: Fast, big, and focused