tags:

views:

87

answers:

8

I'm storing unique user-agents in a MySQL MyISAM table so when I have to look if it exists in the table, I check the md5 hash that is stored next to the TEXT field.

User-Agents 
{
    id         - INT
    user-agent - TEXT
    hash       - VARCHAR(32) // md5
}

There is any way to do the same but using a 32-bit integer and not a text hash? Maybe the md5 in raw format will be faster? That will requiere a binary search.

[EDIT]

MySQL don't handle hash searches for complete case-sensitive strings?

A: 

Are you REALLY sure the hashes are only 32-bit? MD5 is 128-bit. Cropping the hash to first 4 or 8 bytes would greatly increase risk of collisions.

CommanderZ
I'm pretty sure OP meant 32 characters long?
Andrei Serdeliuc
in PHP, md5 are always 32 chars long, yes
Yanick Rochon
I'm using Md5 for performance and for collisions safe, what I need is a method to search a big string in a db in a faster way than a String compare. In this case using hashes.
Wiliam
+2  A: 

Let MySQL do the hard work for you. Use a CHAR column and create an index on that column. You could convert and store the hash as an integer, but there's absolutely no benefit, and it may actually cause problems.

banzaimonkey
Why varchar, not char for fixed-width string?
Māris Kiseļovs
@Māris Kiseļovs Updated--Thanks for the tip.
banzaimonkey
Fixed CHAR better than VARCHAR. But, 32 bytes CHAR is bigger than 16 bytes BINARY, so will have bigger indexes values and table will be bigger, so performance will be in some cases 200% slower for that index right? I'm working with hypothetic 50M rows tables.
Wiliam
+1  A: 

You can't store an MD5 hash in a 32-bit int: it simply won't fit. (It's 32 characters when written in hex, but it's 128-bits of data)

You could look at MySQL's BINARY and VARBINARY types. See http://dev.mysql.com/doc/refman/5.1/en/binary-varbinary.html. These types store binary data. In your case, BINARY(16) or VARBINARY(16), but since MD5 hashes are always 16 bytes, the latter seems a bit pointless.

Thanatos
BINARY(16) better and I know I can't store a md5 in a 32-bit integer, what I was asking is for another solution that fits in a 32-bit integer or in 2 fields. Thanks
Wiliam
+1  A: 

You can store MD5 hash in char(32) which is a bit faster than varchar(32). It's also possible to make two BIGINT fields and keep first half of md5 hash in first field and second part in second field.

Māris Kiseļovs
That will be an abstraction fail for any app and will require 2 indexes.
Wiliam
Thinking it better... if the table is going to have millions of rows, that's the faster solution.
Wiliam
A: 

If your field hash is always an MD5 value generated by PHP, then you can safely set it to CHAR(32). This should not impact the response time to your queries, unless you plan to have millions+ of rows, or even worst! JOIN other tables with this field. The bottom line is that fixed width column is better than variable ones, so if you can optimize do it.

Regarding changing MD5 into int values, see this question; the conclusion to this is that if you really want to change your MD5 into a 128-bit int value, you might as well use a random number instead of an MD5!

Yanick Rochon
I'm working with hypothetic tables of 50M records. Thinking small is an error.
Wiliam
then use a random generated number instead of an MD5. With 32-bit integers, you have plenty of range to play with, even with 500M rows.
Yanick Rochon
It can't be random, it must be the hash of the string field. So If I need to find the text in the string field I have only to search the hash.
Wiliam
you should put that field as UNIQUE then to avoid any possible collision (even for slim chances) and since this field will apparently only be used for searching purposes, then CHAR(32) will be your best choice. You could even go for SHA-1, which generates a 40 characters long string and would still be good in response time since indexed strings are stored in binary trees...
Yanick Rochon
A: 

Have you tried creating a BINARY(16) field, and storing the result of md5($plaintext, true); in it? That might work, make sure you index that field as well.

Because trying to fit a 128-bit value in 32 bits doesn't make any sense...

wimvds
A: 

You could do this instead:

User-Agents 
{
    id         - INT
    user-agent - TEXT
    hash       - UNSIGNED INT (CRC32, indexed)
}


$crc32 = sprintf("%u", crc32($user_agent));

SELECT * FROM user_agents WHERE hash=$crc32 AND user_agent='$user_agent';

It's unlikely that you'll get collisions with crc32 for this kind of data.

To guarantee that collisions will not cause problems, add a secondary search parameter. MySQL will be able to use the index to quickly find the record. Then it can do a simple string search to guarantee that match is correct.

PS: The sprintf() is there to work around signed 32-bit integers. Should be unnecessary on 64-bit systems.

konforce
I like this solution, but another check column will requiere a md5 16-binary-bytes hash right? Only to use when 2 "crc32-hash" records have the same value.
Wiliam
There is no need for a second index or a md5 with this approach. MySQL can only use one index per query. It will use the crc index to find any possible records. After it has found them (usually 0 or 1 record), it will do a string search on the user agent to make sure it isn't a false positive (Collision).
konforce
+2  A: 

try MurmurHash. Its a fast hashing algo thats been translated to multiple languages. It takes your input and translates it into a 32/64 bit integer hash.

ebt
That sounds good, but a php implementation will not be as fast as the native php md5 right? And the hash hasn't been test enough yet I think.
Wiliam
I've use it in production to create unique (UUID4 unique) hashes with no collisions at 100M+ records so far. Speed depends on implementation, C version blazes, I can't speak for PHP.
ebt