MySQL miscellany
For a guy who doesn’t go to the MySQL conference and routinely gets flamed by the MySQL community for being insufficiently adoring of their beloved product, I sure have been putting up a lot of MySQL-related posts recently. Here’s another, zooming through a few different topics. Read more
| Categories: MySQL, Open source | 4 Comments |
I don’t see why the GPL would be a major barrier to a useful MySQL fork
I posted suggesting that substantial elements of the MySQL community should throw their weight behind MySQL forks. Mike Olson of Cloudera helpfully pointed out, on Twitter and by email, how the GPL could appear to stand in the way of such an effort. But would it really?
Currently, any version of the MySQL code that isn’t proprietary to the MySQL company — which is owned by Sun and hence expected to be owned soon by Oracle — is covered by GPL 2. That license states (emphasis mine):
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted,
Hence it is hard for me to see how the MySQL company could in any way hinder another software vendor from saying “Please buy my software, then go download a free copy of GPLed MySQL and run the two together.”*
| Categories: MySQL, Open source | 14 Comments |
This week is a REALLY good time to actively strengthen the MySQL forkers
As my first three posts on the Oracle/Sun merger suggested, I think Oracle will do a better job with MySQL product development than Sun has. But of course that’s a low hurdle. And so it leaves open the questions:
What should and/or will be the most widely adopted code lines of MySQL (or other open source DBMS),
especially for the types of users and vendors who are engaged with MySQL (as opposed to principal alternative PostgreSQL) today?
As much as I’ve bashed MySQL/MyISAM and MySQL/InnoDB for being low-quality general-purpose DBMS, I’d still hate to see MySQL-based development stall out. There are a number of MySQL engine providers with rather unique technology, that deserve a good front-end partner to build their products with. The high-volume sharding guys deserve the chance to continue down their current path as well. And so does the low-end mass market — although I’m least worried about them, as I can’t imagine any realistic scenario in which Oracle doesn’t offer a version of MySQL fully suited to support 10s of millions of WordPress and Joomla installations.
So far as I can tell, there are only four real and currently active candidates for MySQL code coordinator:
- MySQL itself, soon to be owned by Oracle.
- MariaDB, Monty Widenius’ proposed mainstream MySQL alternative
- Percona, which seems to have some fans as a superior alternative to vendor-supplied MySQL/InnoDB
- Drizzle, which is directly focused at web-centric MySQL users who never wanted a robust DBMS in the first place.
Patrick Galbraith and Steven Vaughan-Nichols did good jobs of illustrating the turmoil.
Oracle isn’t a very comfortable partner long term for the storage engine vendors, and Drizzle doesn’t seem to be what they need. So I think that Infobright, Kickfire, Tokutek, Calpont, et al. need to get aligned in a hurry with an outside MySQL provider such as Percona or MariaDB or a newcomer, preferably all with the same one. Yes, I understand that Infobright is getting a lot of marketing help from Sun these days, that Kickfire just got a nice-sounding Sun marketing announcement as well, and so on. But the time to start working toward the inevitable future is now.
And by “now” I mean “right now,” since the MySQL community is at this moment gathered together for its annual conference.
| Categories: Infobright, Kickfire, MySQL, Open source | 12 Comments |
MySQL storage engine round-up, with Oracle-related thoughts
Here’s what I know about MySQL storage engines, more or less.
- MySQL with MyISAM is fast. But it’s not transactional. Except for limited purposes, MySQL with MyISAM is a pretty crummy DBMS. Nothing can change that.
- MySQL with InnoDB is transactional. But it’s not particularly fast. MySQL with InnoDB is a pretty mediocre DBMS. Oracle could fix that, at least partially, over time.
- I don’t know much about Falcon, Maria, and so on. With Oracle winding up owning both MySQL and InnoDB, the motivation for those engines (except as Oracle-free forks) might fade.
- Infobright is the most established of the rest. At the moment I’m not recommending it for most industrial-strength uses unless the user is particularly cash-constrained. But I wouldn’t be surprised if that changed soon. A cheap, fast, simple columnar analytic DBMS has a place in the world.
- Kickfire is next in line, offering a hardware-based growth path for users who’ve maxed out on what unaided MySQL can do. It remains to be seen for how many users the desire to keep things simple and stay with MySQL outweighs the desire to avoid custom hardware. Having Oracle salespeople all over those accounts surely wouldn’t help. Kickfire also has a second market, namely OEM vendors who are mainly interested in the superfast chip. That would probably be pretty unaffected by Oracle.
- Tokutek offers a technical proposition that’s hard to match head-on without going the CEP route. Users who care are likely to be MySQL shops. Tokutek’s main challenge is to prove that it sufficiently outdoes competing technical strategies for sufficiently many users. Oracle ownership of MySQL seems pretty irrelevant to Tokutek’s success or failure.
- Calpont offers a kind of lightweight Exadata alternative. With Calpont’s packaging and positioning perennially unclear, it’s difficult to predict the effect of a particular change — i.e., Oracle buying MySQL — in Calpont’s market environment.
- I haven’t heard from transactionally-oriented ScaleDB since I wrote about them a year ago. Apparently, they’re rolling out beta product this week, and their venerable techie guru sadly passed away earlier this month.
| Categories: Calpont, Columnar database management, Data warehousing, Exadata, Infobright, Kickfire, MySQL, Open source, Oracle, Tokutek and TokuDB | 14 Comments |
Should the Oracle/MySQL combo face antitrust opposition?
Oracle is a powerhouse in database management systems, but it’s hardly a monopolist. IBM revels in contriving figures that show it to have market share comparable to Oracle’s, and Microsoft has a very solid position as well. Smaller players like Teradata, Sybase, and MySQL are also thriving. And of course there’s a whole wave of newer DBMS companies, from Netezza on, showing that the DBMS industry isn’t even the secure oligopoly it appeared to be earlier this decade.
However, it’s certainly legitimate to define a product category of “real” DBMS that includes everything from MySQL on up, but not Microsoft Access and other low-end data management products. In that universe, while MySQL is a trivial addition to Oracle’s revenue, it’s a huge increment to Oracle’s unit market share. A merged Oracle/MySQL will dwarf the competition in ways that Oracle or MySQL alone don’t. Read more
| Categories: MySQL, Open source, Oracle | 10 Comments |
First thoughts on Oracle acquiring Sun
- Wow.
- And during the week of the MySQL conference, too.
- In the must-read slide presentation, Oracle’s says all the right things about being committed to all product lines and technologies. On the whole, this is believable.
- Oracle says it’s focusing Sun hardware sales on existing Oracle/Sun customers. Makes sense.
- Oracle mentions OpenStorage prominently. Makes sense. Integrating DBMS with storage is Oracle’s high-end DBMS future. (E.g., Exadata.)
- HP can’t be happy.
- MySQL and InnoDB are reunited.
- MySQL is apt to get decent, much as it would have under IBM.
- Even so, if you really believe in open source’s freedom, it’s time to look at PostgreSQL …
- … or EnterpriseDB’s Postgres Plus, although my recent dealings with EnterpriseDB underscore the importance of being VERY careful about counting your fingers after you shake hands with that company.
- And I wouldn’t be surprised if another shoe dropped soon on the EnterpriseDB front. (Please excuse the mixed metaphor.)
- I used to laugh at how many different app servers Sun had acquired. Oracle acquired a number too. Together it’s quite a pile of them.
- Oracle says acquiring Java is a great big deal. I’m not sure I see why that would really be true.
More later. I have a radio interview in a few minutes on a very different subject.
| Categories: EnterpriseDB and Postgres Plus, HP and Neoview, MySQL, Open source, Oracle, PostgreSQL | 20 Comments |
Calpont update — you read it here first!
Calpont has gone through a lot of strategy iterations since its founding. The super-short version is that Calpont originally planned an appliance built around a SQL chip, much like Kickfire. But after various changes in management and venture backing, Calpont turned itself into a software-only analytic DBMS vendor relying on a MySQL front end. Calpont is now at the stage of announcing an Early Adopter program at the MySQL conference on Wednesday, although details of Calpont’s product release timing, pricing, feature set, etc. are all To Be Determined.
Minor highlights of the Calpont technical story include: Read more
| Categories: Calpont, Columnar database management, Data warehousing, MySQL, Open source, Parallelization, Theory and architecture | Leave a Comment |
Infobright update
For the past couple of quarters, Infobright has been MySQL’s partner of choice for larger data warehousing applications. Infobright’s stated business metrics, and I quote, include:
> 50 Customers in 7 Countries
> 25 Partners on 4 continents
A vibrant open source community
+1 million visitors
Approaching 10,000 downloads
2,000 active community participants
These may be compared with analogous metrics Infobright offered in February.
Infobright has also made or promised a variety of technological enhancements. Ones that are either shipping now or promised soon include: Read more
| Categories: Columnar database management, Data warehousing, Infobright, MySQL, Open source | 6 Comments |
Introduction to Tokutek
Tokutek has a paradoxical pitch: Tokutek writes data particularly quickly, and therefore you’re supposed to buy Tokutek for query-oriented uses. Highlights of the Tokutek story include:
- Tokutek is a MySQL storage engine.
- MySQL/Tokutek writes indexed data a lot faster than B-tree-based alternatives. (The claim is 10s of 1000s of rows per second on a single server.)
- MySQL/Tokutek reads data at B-tree speeds. (But not, I presume, at the speed of specialized analytic DBMS.)
- Tokutek is not yet ACID-compliant. They’re working on that, but we don’t know what the performance implications will be when they achieve it. ACID compliance won’t come as soon as the May release (Tokutek Version 2.0).
- Tokutek has made one sale. Others are in the pipeline.
Tokutek’s initial target market is the usual combination of clickstream/personalization/other network management. The idea is that many data warehouse technologies have trouble getting latency below, say, 15 seconds to 5 minutes, at least at very high update volumes. So if immediacy is more important than raw complex query performance, Tokutek’s performance profile could be attractive. Read more
| Categories: Data warehousing, MySQL, Tokutek and TokuDB, Web analytics | 14 Comments |
Cloudera presents the MapReduce bull case
Monday was fire-drill day regarding MapReduce vs. MPP relational DBMS. The upshot was that I was quoted in Computerworld and paraphrased in GigaOm as being a little more negative on MapReduce than I really am, in line with my comment
Frankly, my views on MapReduce are more balanced than [my] weary negativity would seem to imply.
Tuesday afternoon the dial turned a couple notches more positive yet, when I talked with Michael Olson and Jeff Hammerbacher of Cloudera. Cloudera is a new company, built around the open source MapReduce implementation Hadoop. So far Cloudera gives away its Hadoop distribution, without charging for any sort of maintenance or subscription, and just gets revenue from professional services. Presumably, Cloudera plans for this business model to change down the road.
Much of our discussion revolved around Facebook, where Jeff directed a huge and diverse Hadoop effort. Apparently, Hadoop played much of the role of an enterprise data warehouse at Facebook — at least for clickstream/network data — including:
- 2 1/2 petabytes of data managed via Hadoop
- 10 terabytes/day of data ingested via Hadoop (Edit: Some of these metrics have been updated in a subsequent post about Facebook.)
- Ad targeting queries run every 15 minutes in Hadoop
- Dashboard roll-up queries run every hour in Hadoop
- Ad-hoc research/analytic Hadoop queries run whenever
- Anti-fraud analysis done in Hadoop
- Text mining (e.g., of things written on people’s “walls”) done in Hadoop
- 100s or 1000s of simultaneous Hadoop queries
- JSON-based social network analysis in Hadoop
Some Facebook data, however, was put into an Oracle RAC cluster for business intelligence. And Jeff does concede that query execution is slower in Hadoop than in a relational DBMS. Hadoop was also used to build the index for Facebook’s custom text search engine.
Jeff’s reasons for liking Hadoop over relational DBMS at Facebook included: Read more