Меню
Что нового?

Не поможите оптимизировать ?

Mocus

Guest
Не поможите оптимизировать ?

У меня работает поисковый FTP-сервер нашей локалки... Файлов много и база весит уже 73 метра. Ума не приложу, как её можно оптимизировать. Попробую объяснить, что есть.

1-я таблица содержит записи об адресах, логинах, паролях и владельцах FTP-серверов. Каждому FTP-шнику присвоен уникальный номер.

2-я таблица содержит 3 поля:
- уникальный номер - INT
- "каталог" - VARCHAR(255)
- "файл" - VARCHAR(255)

В этой таблице просто масса повторяющихся данных. Например:
1 | ftp://10.10.1.1/Audio/Наше | Кино
1 | ftp://10.10.1.1/Audio/Наше | Наутилус
1 | ftp://10.10.1.1/Audio/Наше | Дельфин
1 | ftp://10.10.1.1/Video/Фильмы | Кино
1 | ftp://10.10.1.1/Video/Фильмы | Anime
1 | ftp://10.10.1.1/Video/Фильмы | xxx
...
и так далее...
Поиск происходит только по полю "файл" типа LIKE "%$string%";

Вот я и думаю... Как бы сделать так, чтобы все "файлы" с одинаковым "каталогом" ссылались на 1 каталог ?

Спасибо за внимание :)

-~{}~ 10.03.04 22:18:

Забыл написать... Уникальный номер во второй таблице соответствует номеру из 1-й таблицы. По нему выводится информация о владельце и доступности сервера в данный момент (On/Off Line).
 

Winnie Pooh

-_-
Re: Не поможите оптимизировать ?

Автор оригинала: Mocus

2-я таблица содержит 3 поля:
- уникальный номер - INT
- "каталог" - VARCHAR(255)
- "файл" - VARCHAR(255)

В этой таблице просто масса повторяющихся данных. Например:
1 | ftp://10.10.1.1/Audio/Наше | Кино
1 | ftp://10.10.1.1/Audio/Наше | Наутилус
и так далее...
Нажмите для раскрытия...
имхо.. вместо этой таблицы сделать две..
первая с названиями каталогов и их отношению к владельцам FTP-серверов
вторая отношение файлов и каталогов...
итого:
первая
cat_id | ftp_id | "каталог"
--------------------------------------------------------
1 | 1 | ftp://10.10.1.1/Audio/Наше

вторая

id |cat_id | "файл"
-------------------------
1 | 1 | Наутилус
 
Falc

Falc

Новичок
А еще лучше каталог организовать в виде дерева.
Или как минимум вынести адреса серверов ( ftp://10.10.1.1/)
В отдельный справочник ( естествено после выноса путей, как предложил Winnie Pooh )
 

Mocus

Guest
==>Winnie Pooh
Это конечно хорошо... Но как вы себе это представляете ?
Делает товарищ запрос:
select * from файл where файл like "%xxx%";
, и находится, допустим, 100 ответов. Теперь надо сделать 2-й запрос в таблиц "каталог". Допустим, что все 100 "файлов" лежат в разных дирректориях. Как вы представляете себе такой запрос ?? :)

==>Falc
А еще лучше каталог организовать в виде дерева.
Эээ... А это как ? И как повлияет на скорость ?

Или как минимум вынести адреса серверов ( ftp://10.10.1.1/)
В отдельный справочник ( естествено после выноса путей, как предложил Winnie Pooh )
Хорошо. Я выношу адреса серверов. Но размерность базы от этого не меняется. Ведь размер поля всё равно остаётся VARCHAR(255). Реальный выигрыш от этого, по моим подсчётам, меньше 5%.
 

lucas

Guest
А еще лучше каталог организовать в виде дерева.
Эээ... А это как ? И как повлияет на скорость ?
Нажмите для раскрытия...
http://phpclub.ru/talk/showthread.php?s=&threadid=30904&rand=1

Хорошо. Я выношу адреса серверов. Но размерность базы от этого не меняется. Ведь размер поля всё равно остаётся VARCHAR(255).
Нажмите для раскрытия...
Поле это нужно будет поменять, например, на mediumint.
 

ecto

Новичок
таблица хостов host - id|host
таблица путей path - id|id_host|path
таблица файлов file - id|id_path|file

поля h.host,p.path,f.file тип char для увелечения скорости работы

select h.host,p.path,f.file,MATCH (f.file,p.path) AGAINST ('search text' in boolean mode) as reval
from host h,path p,file f
where f.id_path=p.id and p.id_host=h.id
order by reval desc

оптимизация -
по полям id ставится pimary key
тогда связывание будет наиболее эффективным
по полям p.path,f.file строить индексы
бесполезно - использоваться они не будут

как дерево организовывать нельзя -
слишком большая нагрузка на сервер при развертывании путей
 
Falc

Falc

Новичок
ecto
Во-первых автору нужно искать только по file.
Во-вторых ты ничего не сказал что надо сделать полнонтекстовый индекс.
В-третьих при полноконтекстовом индексе типы h.host,p.path,f.file мало повлияют на скорость работы и в целях экономии места их можно сделать varchar.
В-четвертых при организации в виде дерева не так много путей придется развертывать, так что никакой нагрузки там не будет.
 

ecto

Новичок
Falc

>нужно искать только по file
да пропустил я тот момент что ищет он по имени файла
>не сказал что надо сделать полнонтекстовый индекс
я сказал -
по полям p.path,f.file строить индексы
бесполезно - использоваться они не будут

а вот если искать по одному имени файла то есть два варианта
1 ищется по конструкции f.file like '%text%'
индекс строть бесполезно
2 по match(f.file) against('text')
тогда можно строить fulltext индекс на varchar
только это всеравно что из пушки по воробьям
всетаки fulltext создан для объёмов текстов
и постоянная корректность поиска под вопросом
(например поиcк 'mp3' работать не будет точно)

поэтому 1 вариант наиболее приемлемый

остальные поля char так как индекса в них нет

про дерево остаюсь при своем мнении и навязывать его никому не буду )
 
Falc

Falc

Новичок
Mocus
Если названия файлов у тебя переодически повтаряются, то и их можно вынести в отдельный справочник.

ecto
>>про дерево остаюсь при своем мнении и навязывать его никому не буду )
Твое мнение провалилось нагрузки от развертывания там будет мизер. Так что придумай что-нибудь другое. Основное время будет уходить на: like '%text%'. Просто в виде дерева скорее все каталог будет занимать меньше места, но на самом деле надо смотреть по данным.
 

Mocus

Guest
Поскольку про деревья я вообще ничего не знаю. Буду читать :) И пробовать ваши советы :)
 
Войдите или зарегистрируйтесь для ответа.
Сверху