Forum Moderators: open

Message Too Old, No Replies

Split Full text search to separate table

Is what I'm doing making any sense?

         

whoisgregg

1:49 pm on Oct 4, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Hello,

I have a table of just over 250,000 rows (in six months it will be 300K+, two years it will be a million+). Each row has a longtext field of search terms (description, keywords, etc.) and a full text index. For some reason, I thought it would make sense to slice the longtext field to a separate table so that reads from that table will not lock the main table.

Searching is done with an AJAX widget so that table will get accessed a lot -- more than one would typically expect it to be accessed. For that reason should it be split? Or am I just adding unnecessary complexity?

coopster

6:51 pm on Oct 15, 2007 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



Split from what?

whoisgregg

12:14 pm on Oct 16, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



What it boils down to is, should I have my full-text index in the same table as the rest of the object data. Or should I have a table that exists just for full-text searches? I'm doing an AJAX-y search of the objects, so I am concerned there will be many reads from the full text index and I don't want that to interrupt the necessary reads/writes to the object data.

 CREATE TABLE `object` (
`object_id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`object_name` VARCHAR( 128 ) NOT NULL ,
`object_w` INT NOT NULL ,
`object_h` INT NOT NULL ,
`object_added` TIMESTAMP NOT NULL ,
...
)

Should I create a second table that has a foreign key to the `object` table and solely holds the full text search data? Or should the `object_keywords` and it's corresponding full text index just be part of the main table?

 CREATE TABLE `object_search` (
`object_id` BIGINT UNSIGNED NOT NULL ,
`object_keywords` LONGTEXT NOT NULL ,
PRIMARY KEY ( `object_id` ) ,
FULLTEXT (
`object_keywords`
)
)

I realize this probably makes no sense from a normalization point of view, but I'm thinking more from an optimization point of view. I also realize this is premature optimization. ;)

coopster

7:01 pm on Oct 17, 2007 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



Well, your thought process certainly makes sense, but I have no insight as to the underlying logic and reason, and whether there is need for concern. Is it file-locking on the reads that concerns you?

whoisgregg

7:45 pm on Oct 17, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



It is file locking on the reads that concerns me. This project is rather large compared to anything I've worked on before and will be accompanied by a significant marketing effort. The table in question is the most used -- particularly for searching.

coopster

8:32 pm on Oct 17, 2007 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



This webinar may prove helpful, you'll have to let me know ;)
[mysql.com...]

whoisgregg

9:31 pm on Oct 17, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Watching it now and so far it is quite helpful. Although "tags" aren't quite what I'm doing, all the scaling strategies are looking good. Thanks coopster! :D

coopster

3:52 pm on Oct 18, 2007 (gmt 0)

WebmasterWorld Administrator 10+ Year Member



Personally, and perhaps my approach will draw criticism, but I would normalize, optimize and launch. If the site becomes that successful, use the revenue to consult and take next steps. I say jump in ;)

whoisgregg

3:18 pm on Oct 22, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Looks like a sound strategy to me. Thanks coopster. :)