whirlwind
TDD infected, paranoid
Поиск по файлам: оптимизация
ГЫ. нет, всетаки без помощи аудитории не обойтись
Хочу поинтересоваться у опытных людей по поводу серченжинов. Задача собсно заключается в индексации файлов для локалки. Обращаюсь исключительно потому, что времени на разработку есть макс. два дня в неделю по выхам, протестить все варианты и найти оптимальный довольно затруднительно, а сделать хочется. Т.к. некоммерческое и все такое...
Имеецо: таблица вхождений->таблица файлов. Ищем вхождения, джойнясь на таблицу вхождений. Проблема в том, что при >4КК во вхождениях начинаются тормоза в зависимости от вводных.
Вопрос №1: Почему поиск по индексу длинной 8 байт со значением к примеру linuxsoft выполняется медленнее чем поиск по двум значениям linux и soft при том что по linuxsoft ничего нет? Если я правильно понимаю принцип работы индексов b-tree, то linuxsoft должен отработать быстрее, потому что linuxsof это 64 ветки, а linux soft это 64*2 (ну или по крайней мере переход на еще одно условие).
Вопрос №2: понятно, что длинные лексемы будут искаться быстрее коротких. И чем больше лексем, тем быстрее будет получен результат. Первое, что приходит на ум, это отсортировать лексемы по длине, и джойнить от более длинного к менее длиному. Как быть, если все лексемы короткие? На ум приходит остортировывать и собирать короткие лексемы в одну и таким же образом обрабатывать входные данные, но судя по в.№1 это не даст эффекта.
Вопрос №3: имеет ли смысл на 32 машинах разбивать на 32-разр. составляющие. Т.е. при требуемой точности в 8 символов закодировать лексемы как 2xINTEGER(32), построить по этим полям multicolumn индекс. Или положительного эффекта этим не добиться?
Пробовал на btree, сейчас строю hash, но сколько времени займет неизвестно))))
ГЫ. нет, всетаки без помощи аудитории не обойтись
Хочу поинтересоваться у опытных людей по поводу серченжинов. Задача собсно заключается в индексации файлов для локалки. Обращаюсь исключительно потому, что времени на разработку есть макс. два дня в неделю по выхам, протестить все варианты и найти оптимальный довольно затруднительно, а сделать хочется. Т.к. некоммерческое и все такое...
Имеецо: таблица вхождений->таблица файлов. Ищем вхождения, джойнясь на таблицу вхождений. Проблема в том, что при >4КК во вхождениях начинаются тормоза в зависимости от вводных.
Вопрос №1: Почему поиск по индексу длинной 8 байт со значением к примеру linuxsoft выполняется медленнее чем поиск по двум значениям linux и soft при том что по linuxsoft ничего нет? Если я правильно понимаю принцип работы индексов b-tree, то linuxsoft должен отработать быстрее, потому что linuxsof это 64 ветки, а linux soft это 64*2 (ну или по крайней мере переход на еще одно условие).
Вопрос №2: понятно, что длинные лексемы будут искаться быстрее коротких. И чем больше лексем, тем быстрее будет получен результат. Первое, что приходит на ум, это отсортировать лексемы по длине, и джойнить от более длинного к менее длиному. Как быть, если все лексемы короткие? На ум приходит остортировывать и собирать короткие лексемы в одну и таким же образом обрабатывать входные данные, но судя по в.№1 это не даст эффекта.
Вопрос №3: имеет ли смысл на 32 машинах разбивать на 32-разр. составляющие. Т.е. при требуемой точности в 8 символов закодировать лексемы как 2xINTEGER(32), построить по этим полям multicolumn индекс. Или положительного эффекта этим не добиться?
Пробовал на btree, сейчас строю hash, но сколько времени займет неизвестно
))))