Проектирование архитектуры сайта

Господа профессионалы :)

Появилась такая проблема. Я нигде не нашел адекватной и структурированной информации о проектировании архитектуры web-приложений, размер таблиц в которых будет более 4 Гб(и даже больше раз эдак в 5-8).

Я приложение уже доделал (почти-почти). Это поисковая система(очень специфичная). Потестировал, время работы поиска занимает от 0.3 до 1.5 сек. Это нормально для товарных поисковых систем? Просто хочется быстрее, а рефакторинг сократит может 30%.

Вот у меня и зародились сомнения в правильности архитектуры.
Что сделал:
1) Запросы семантически разделяются по n типам.
2) Имеется n таблиц c товарами (tov_table), которым соответствуют n таблиц со значениями релевантности этих товаров (rel_table).
3) Когда поступает запрос, то происходит выборка по каждой паре tov_table и rel_table с их объединением, все парные выборки объединяются UNOIN-ом.

Появились вопросы:
1) Что будет, если таблицы со значениями релевантности станут больше 4Гб?
2) Что если ОС на сервере не будет поддерживать такие файлы?
3) А что если не разделять на типы, а тупо все товары в одной табличке держать, а их значения релевантности в другой? Это быстрее чем делать UNION-ы (с filesort к тому же), но тогда такие таблицы быстро перерастут и 4 Гб и вскорости вообще все немыслимые пределы.
Просьба не ставить под сомнение мои оценочные размеры таблиц, я хорошо посчитал да и вконце концов представим просто такие исходные данные.

Ну, оптимизация…

по сабжу очень хотелось бы услышать что-либо. Хоть ссылок побольше каких (если сами не касались глубоко этой темы).

база - Mysql.

Отчет то я себе отдаю, просто желания вперед возможностей прут (разве у вас никогда такого не было?) Я надеялся, что задам абстрактный вопрос и обрисую его интерфейс, а кто-нибудь шаристый подскажет способ решения, задав пару вопросов-наследников:)