The InnoDB full-text search capability is an exciting feature. The full-text search itself is generally useful to have in an RDBMS. If an application is using all InnoDB tables except for one that is used for full-text searches, now that last table can be switched to InnoDB. If putting the full-text data in a MyISAM table led to scalability problems, duplication, or a less-than-ideal schema design, now those issues can be addressed.

In this post, I’ll take you through some of the basics of setting up and querying an InnoDB FULLTEXT search index. I’ll leave the scalability and performance aspects to Jimmy’s and Vinay’s blog posts, and just use some toy-sized data for demonstration purposes.

Creating a Table with a …

Brian Aker presents "Drizzle, Virtualizing and Scaling MySQL for the Future" at OSCon Data 2011

http://drizzle.org

irc.freenode.net #drizzle

http://blog.krow.net

@brianaker

2005 MySQL 5.0 released - web developers wanted tons of features that were not in the release (making replication better for instance)

2008 Sun buys MySQL

2008 MySQL 6.0 is forked to become Drizzle

2009 Oracle buys Sun

2010 Drizzle developers leave Oracle

2011 First GA release, Drizzle7

MySQL's Architecture - monolithic kernel, not very modular, lots of interdependence.

Drizzle has a microkernel, which includes a listener, parser, optimizer, executioner, storage system, logging/error reporting.

Drizzle can accept SQL and http blog streaming, and memcached …

Congratulations and thanks to Monty Program on the release of MariaDB 5.3! This looks like a great release. (I haven’t had a chance to try it yet.) I really welcome the query optimizer improvements; the list of changes is huge. There are a lot of fixes for problems I’ve seen for years. And there’s group commit, and high-resolution date/time types, and lots more.

And congratulations and thanks to Oracle on the next series of previews of what MySQL 5.6 will look like, including full-text search inside InnoDB, performance and scalability improvements, and usability and operational improvements. I love the batch of informational blog posts from the InnoDB team and others that usually comes out around such announcements. I …

Pipe viewer is a command line tool which is used to monitor the throughput, display the estimated time of completion or to limit the transfer rate of a pipe (pipeline).

Install pipe viewer on Debian / Ubuntu with the following command.

apt-get install pv

On CentOS / Fedora / RedHat use the yum command to install pipe viewer

yum install pv

To use pipe viewer just insert the pv command between two processes to monitor the throughput of the pipe.

cat logfile.log.1 | pv | gzip -9 > logfile.log.1.gz
9,18MB 0:00:01 [ 9,1MB/s] [   <=>

Or limit the transfer rate of the pipe to a designated number of bytes.

cat logfile.log.1 | pv --rate-limit 100 | gzip -9 > logfile.log.1.gz
 300B 0:00:03 [ 101B/s ] [         <=>                                    ]

Related Posts:

• …

This is a simple and classic case that I am following on twitter and try to help a MySQL friend: @danny said – how to automatically add the timestamp value of a new register and when that same register is altered, how to automatically alter that date? @wagnerbianchijr e.g. for a forum comment, I want to track [...]

Dwight Merriman gives "MongoDB Schema Design" at OSCon Data 2011.

@dmerr

RDBMS / MongoDB

relational / document-oriented

database / database

table / collection

row / JSON (BSON) document

index / index

column / field (dynamic/not predeclared)

SQL / Mongo query language (JSON)

Join / Embedding & Linking

Primary Key / _id field

Schema design is coupled with what you want to do:

- Dynamic queries

- Secondary indexes

- Atomic updates

- Map Reduce

Considerations:

- no joins

- atomic operations are at the single document level only

- types of queries/updates to do

- sharding

- speed

This is the commandline mongo interface but all this can be done in any (modern) programming language. …

MariaDB 5.3 is now released as beta (feature freeze).

MariaDB 5.3 radically improves performance for subqueries as well as for joins and single-table queries over large data sets. MariaDB 5.3 is based on MySQL 5.1.

For a detailed description of MariaDB 5.3, see the What is MariaDB 5.3 page.

In most respects MariaDB will work exactly as MySQL: all commands, interfaces, libraries and APIs that exist in MySQL also exist in MariaDB.

A few highlights:

One of the major performance improvements in MariaDB 5.3.0 is that subqueries are finally usable in practice. It is no longer necessary to rewrite subqueries manually into joins or separate queries. The optimizer of MariaDB 5.3 will do this, and more automatically. EXPLAIN for derived tables and materialized views is instantaneous. Both derived tables and …

The MariaDB Project is at OSCON 2011. We’ve got a booth, and we plan to also have a BoF session: Wednesday 27 July 2011 at room E142 at 8pm.

There will as usual be lots of black vodka (there was some yesterday at the MySQL BoF as well), and we’re going to talk about and celebrate the release of MariaDB 5.3.0 beta.

Come drop by the booth… we clearly have an interesting booth giveaway. And feel free to say hi to Kurt von Finck, Michael “Monty” Widenius, or Colin Charles who will be present, walking around, etc. Spot them in a MariaDB t-shirt of course!

The primary objective of this release was to radically improve performance for subqueries, as well as for joins and single-table queries over large data sets. The MariaDB 5.3 release is based on MariaDB 5.2 (and therefor, MariaDB 5.1 & MySQL 5.1).

Noteworthy improvements in this release include:

read more

Just in case you missed the press release:

Oracle Provides Early Access to MySQL 5.6 New Features

At OSCON (the O’Reilly Open Source Convention) in Oregon, Oracle announced that early access to new features of MySQL 5.6 is available for the community to test, deploy and provide feedback.  Read more here