Topics for this podcast:

*Matt Asay moves from Alfresco to Canonical
*GPL fade fuels heated discussion
*Apple’s iPad and its enterprise and open source impact
*Open source in data warehousing and storage
*Our perspective on Oracle’s plans for Sun open source

iTunes or direct download (32:50, 9.2 MB)

Disclaimer: This post is based on HEAP/MyISAM’s sourcecode in Drizzle.

Here are my brief notes on investigating how index keys are generated in HEAP and MyISAM. I lurked through these because I’ve started preparing for decent index support in BlitzDB. I also wrote this to assist my biological memory for later grepping (I have terrible memory for names). I’m only going to cover key generation on write in this post. Otherwise this post is going to be massive.

HEAP Engine

The index structure of HEAP can be either BTREE or HASH (in MySQL doc terms). Like other engines HEAP has a structure for keeping Key definition (parts, type, logic and etc). This structure is called HP_KEYDEF and it contains function pointers for write, delete, and getting the length of the key. These function pointers are assigned to at table creation or when the table is opened. The assigned function depends on the data structure …

On first glance, it looks like TEXT and VARCHAR can store the same information. However, there are fundamental differences between the way TEXT fields and VARCHAR fields work, which are important to take into consideration.

Standard
VARCHAR is actually part of the ISO SQL:2003 standard; The TEXT data types, including TINYTEXT, are non-standard.

Storage
TEXT data types are stored as separate objects from the tables and result sets that contain them. This storage is transparent — there is no difference in how a query involving a TEXT field is written versus one involving a VARCHAR field. Since TEXT is not stored as part of a row, retrieval of TEXT fields requires extra [edited 1/22] memory overhead.

Maximum VARCHAR length
The maximum row length of a VARCHAR is restricted by the maximum row length of a table. This is 65,535 bytes …

This Thursday (November 26th, 14:00 UTC), Giuseppe Maxia will present the Spider Storage Engine. This session was originally scheduled for October 15th but had to be postponed for technical reasons.

Here's from the abstract: Everybody needs sharding. Which is not easy to maintain. Being tied to the application layer, sharding is hard to export and to interact with. The Spider storage engine, a plugin for MySQL 5.1 and later, solves the problem in a transparent way. It is an extension of partitioning. Using this engine, the user can deal transparently with multiple backends in the server layer. This means that the data is accessible from any application without code changes. This lecture …

This Thursday (November 26th, 14:00 UTC), Giuseppe Maxia will present the Spider Storage Engine. This session was originally scheduled for October 15th but had to be postponed for technical reasons.

Here's from the abstract: Everybody needs sharding. Which is not easy to maintain. Being tied to the application layer, sharding is hard to export and to interact with. The Spider storage engine, a plugin for MySQL 5.1 and later, solves the problem in a transparent way. It is an extension of partitioning. Using this engine, the user can deal transparently with multiple backends in the server layer. This means that the data is accessible from any application without code changes. This lecture …

This Thursday (November 26th, 14:00 UTC), Giuseppe Maxia will present the Spider Storage Engine. This session was originally scheduled for October 15th but had to be postponed for technical reasons.

Here's from the abstract: Everybody needs sharding. Which is not easy to maintain. Being tied to the application layer, sharding is hard to export and to interact with. The Spider storage engine, a plugin for MySQL 5.1 and later, solves the problem in a transparent way. It is an extension of partitioning. Using this engine, the user can deal transparently with multiple backends in the server layer. This means that the data is accessible from any application without code changes. This …

This Thursday (November 5th, 10:00 UTC - note the different time for this session!), Arjen Lentz of Open Query will present the brand new GRAPH computation engine for MySQL.

From the abstract: Most of us have had to deal with hierarchies (trees) and graphs (such as friend-of-a-friend style problems), and have thus learn that this is -at best- a bit of a monster to do in an SQL/RDBMS. Until now. The GRAPH engine (GPLv2 licensed) is a MySQL storage engine allowing hierarchies and more complex graph structures to be handled in a relational fashion. In a nutshell, tree structures and friend-of-a-friend style searches can now be done using standard SQL syntax, and results joined onto other tables. http://openquery.com/graph

For MySQL University sessions, point your …

This Thursday (November 5th, 10:00 UTC - note the different time for this session!), Arjen Lentz of Open Query will present the brand new GRAPH computation engine for MySQL.

From the abstract: Most of us have had to deal with hierarchies (trees) and graphs (such as friend-of-a-friend style problems), and have thus learn that this is -at best- a bit of a monster to do in an SQL/RDBMS. Until now. The GRAPH engine (GPLv2 licensed) is a MySQL storage engine allowing hierarchies and more complex graph structures to be handled in a relational fashion. In a nutshell, tree structures and friend-of-a-friend style searches can now be done using standard SQL syntax, and results joined onto other tables. http://openquery.com/graph

For MySQL University sessions, point your …

This Thursday (November 5th, 10:00 UTC - note the different time for this session!), Arjen Lentz of Open Query will present the brand new GRAPH computation engine for MySQL.

From the abstract: Most of us have had to deal with hierarchies (trees) and graphs (such as friend-of-a-friend style problems), and have thus learn that this is -at best- a bit of a monster to do in an SQL/RDBMS. Until now. The GRAPH engine (GPLv2 licensed) is a MySQL storage engine allowing hierarchies and more complex graph structures to be handled in a relational fashion. In a nutshell, tree structures and friend-of-a-friend style searches can now be done using standard SQL syntax, and results joined onto other tables. http://openquery.com/graph

For MySQL University sessions, point your …

Ok, they aren’t like the 2012 nonsense or anything but they are interesting articles that will be important topics in the near future for expanding our knowledge and usefulness in the job market. Being a DBA does not limit you to relational database systems. I expect to see more requests for non-relational or No-SQL type of data stores as they can have many advantages over an RDBMS. Stability, scalability, simplification of administration, higher performance on lesser hardware for larger datasets, and many other items make no-sql engines very interesting. Here are some useful links:

http://en.wikipedia.org/wiki/NoSQL

http://www.linux-mag.com/cache/7579/1.html

http://www.computerworld.com/s/article/9135086/No_to_SQL_Anti_database_movement_gains_steam_

http://www.viget.com/extend/nosql-misconceptions/

How can I pass up talking about the various Cloud offerings again. Here are some interesting news stories …