Oct 282005
 

My GordonTillman.info site, and this blog, is hosted by Dreamhost. They are nice folks and I have had good service from them.

But for the last 3 weeks or so I have been experiencing apparently random outages on my site. Each time I have contacted customer support and they have been able to get it back online pretty quickly. Last week I had broached the idea that maybe one of the other customers that are sharing the same machine may be doing something that is causing problems. They were going to setup some monitoring software.

Well, I don’t know if they did, in fact, setup some monitoring software or not. But earlier today I had another outage on my site. I contacted support and Kelly just got back to me. Kelly told me they had found an exploit active and running from another site that is hosted from the same machine as me. By the way, the name of the machine is shekel. Kelly killed the offending process and contacted the owner of the site to have them update their software to avoid future exploits.

So hopefully all will be well in the future.

Oct 202005
 

Apple has quietly released a bunch of updates to their line of hardware. For me the most exciting one is the new dual-core G5. Here is an overview of the specs for the high-end model:

  • Two dual-core 2.5GHz processors
  • 1MB L2 cache for each core
  • 1.25 GHz frontside bus
  • Up to 16GB PC2-4200 RAM (533 MHz, DDR2 SDRAM)
  • NVIDIA GeForce 6600 with 256MB GDDR SDRAM (other cards also available)
  • 250GB SATA drive
  • 16X SuperDrive with double-layer support (DVD+R, DL/DVD+-RW/CD-RW)
  • 3 PCIX slots
  • USB 1.1 and 2.0, FireWire 400 and 800
  • Analog and optical audio in and out
  • Dual 10/100/1000BASE-T ethernet, airport, bluetooth

It’s a bad-ass machine, folks!

Oct 082005
 

A very interesting and informative article that talks about the different storage engines available the MySQL may be read here.

You can use the show engines; command to see what storage engines your installation of MySQL knows about and which ones are available. For instance, here on my laptop, the following list is revealed:

mysql> show engines;
+------------+---------+------------------------------------------------------------+
| Engine     | Support | Comment                                                    |
+------------+---------+------------------------------------------------------------+
| MyISAM     | DEFAULT | Default engine as of MySQL 3.23 with great performance     |
| HEAP       | YES     | Alias for MEMORY                                           |
| MEMORY     | YES     | Hash based, stored in memory, useful for temporary tables  |
| MERGE      | YES     | Collection of identical MyISAM tables                      |
| MRG_MYISAM | YES     | Alias for MERGE                                            |
| ISAM       | NO      | Obsolete storage engine, now replaced by MyISAM            |
| MRG_ISAM   | NO      | Obsolete storage engine, now replaced by MERGE             |
| InnoDB     | YES     | Supports transactions, row-level locking, and foreign keys |
| INNOBASE   | YES     | Alias for INNODB                                           |
| BDB        | NO      | Supports transactions and page-level locking               |
| BERKELEYDB | NO      | Alias for BDB                                              |
| NDBCLUSTER | NO      | Clustered, fault-tolerant, memory-based tables             |
| NDB        | NO      | Alias for NDBCLUSTER                                       |
| EXAMPLE    | NO      | Example storage engine                                     |
| ARCHIVE    | YES     | Archive storage engine                                     |
| CSV        | NO      | CSV storage engine                                         |
| BLACKHOLE  | NO      | Storage engine designed to act as null storage             |
+------------+---------+------------------------------------------------------------+

Older versions of MySQL may require you to use the command show variables like 'have_%';.

Decisions about which engine type to use for a given table should be made based upon the following criteria:

  • supported field and data types
  • locking types (Note: Only the InnoDB supports row-level locking)
  • indexing
  • transactions

Here are excepts from this article, which I encourage you to read in its entirety.


MyISAM

This is the default engine type. Offers the best combination of performance and functionality, but lacks transaction capabilities and uses table-level locking.

MERGE

The MERGE engine type allows you to combine a number of identical tables into a single table. You can then execute queries that return the results from multiple tables as if they were just one table. Each table merged must have the same table definition.

MEMORY

The MEMORY storage engine (previously known as the HEAP storage engine) stores all data in memory; once the MySQL server has been shut down any information stored in a MEMORY database will have been lost. However, the format of the individual tables is kept and this enables you to create temporary tables that can be used to store information for quick access without having to recreate the tables each time the database server is started.

EXAMPLE

The EXAMPLE engine is actually a programming example of a storage engine that can be used as the basis for other engines within the MySQL system. It does not support data inserts and isn’t a practical engine for any form of database access. It is, however, a good guide to how to develop your own storage engine, and is therefore an effective guide for programmers.

FEDERATED

The FEDERATED storage engine (added in MySQL 5.03) enables you to access data from remote MySQL database (other databases may be supported in the future) as if it were a local database. In effect, the MySQL server acts as a proxy to the remote server, using the MySQL client access library to connect to the remote host, execute queries and then reformat the data into the localized format.

ARCHIVE

The ARCHIVE storage engine supports only the INSERT and SELECT statements, but does support most of the MySQL field types. Information stored in an ARCHIVE storage engine table is compressed and cannot be modified and so ARCHIVE tables are perfect for storing log data (which you don’t want to be able to change) or information that is no longer in active use (for example, old invoicing or sales data).

CSV

The CSV storage engine stores data not in a binary format, but in the form a CSV (Command Separated Values) file. Because of this, there are limitations to the data stored. It is not an efficient method for storing large volumes of data, or larger data types like BLOB, although such types are supported. There is also no indexing. However, because the data is stored in the CSV format it is exceedingly portable; these CSV files generated can easily be imported into many different software packages, including Excel, OpenOffice and database systems like Access or FileMaker.

In general, the CSV engine is impractical as a general database engine. It is, however, probably the most effective and easiest method for data exchange. What makes it so convenient is that we can use SELECT and INSERT statements to create the database, which in turn means that we can easily produce CSV files based on queries of other data.

With some careful work, the CSV storage engine can also be used as an effective way of getting information into MySQL. Here, you can create the tables first, shutdown the MySQL server, copy over CSV files that you have exported from Excel, Access or another database, and you can then import the data and copy it over to MyISAM or InnoDB tables.

BLACKHOLE

Strange though it may seem, the BLACKHOLE engine does not actually store any data. Although you can create tables and indexes, all SQL statements that would add or update information to the database are executed without actually writing any data. The database structure is retained, however, and you can create any indexes on the (non-existent) information that you want.

Although this seems like a futile exercise, it does allow you to test out database structures and play with table definitions without actually creating any data. Even more useful, however, is that SQL statements on BLACKHOLE databases are written to the binary log, and therefore are replicated to slave databases.

ISAM

The ISAM storage engine was the original engine type available with versions of MySQL up until MySQL 3.23, when the MyISAM storage engine was introduced. ISAM has a number of different limitations that make it impractical as a database engine.

ISAM is included for backwards compatibility, you certainly shouldn’t use ISAM for new databases, use MyISAM instead.

Berkeley DB (BDB)

The Berkeley DB (or BDB) engine is based on the technology provided by the Berkeley DB storage system developed by SleepyCat software. BDB is a hash based storage mechanism, and the keys to the hash values are stored very efficiently. This makes the recovery of information–especially when accessed directly using a unique key incredibly quick, and by far the quickest of the available database types. Recovering full records is even quicker if you the data is short enough to be stored with the unique key (i.e., under 1024 bytes long). BDB is also one of only two types of storage engine that support transactions.

InnoDB

The InnoDB Engine is provided by Innobase Oy and supports all of the database functionality (and more) of MyISAM engine and also adds full transaction capabilities (with full ACID (Atomicity, Consistency, Isolation, and Durability) compliance) and row level locking of data.

Engine Introduced Default Install Data Limitations Index Limitations Transaction Support Locking Level
MyISAM v3.23 Yes None 64 indexes per table (32 pre 4.1.2) No Table
MERGE v3.23.25 Yes Underlying tables must be MyISAM N/A No Table
MEMORY 1.0 (only known as MEMORY since 4.1) Yes BLOB and TEXT types not supported None No Table
EXAMPLE v4.1.3 No N/A N/A N/A N/A
FEDERATED v5.0 No Limited by remote database N/A No N/A
ARCHIVE v4.1.3 No Data can only be inserted (no updates) N/A No N/A
CSV v4.1.4 No None Indexing not supported No Table
BLACKHOLE v4.1.11 No No data is stored, but statements are written to the binary log (and therefore distributed to slave databases) N/A No N/A
ISAM v1.0 Yes Limited maximum database size (4GB) Maximum 16 indexes per table, 16 parts per key No Table
BDB v3.23.34a No None Max 31 indexes per table, 16 columns per index;max key size 1024 bytes Yes Page (8192 bytes)
InnoDB v3.23 (source only), v4.0 (source and binary) No None None Yes (ACID compliant) Row