Быстрый доступ к контенту

Milif · 12 сен 2005, 10:07

Есть таблица ~ 150 миллионов строк. Нужен быстрый доступ к контенту. Т.е. нужно быстро получить информацию из 100 000 строк, зная их номера (контент – простое число). В начале пробовал индексировать и нужные строки выбирать селектом:
select контент from table where IND= функция_номера_строки
Тормоза жуткие. 1000 значений строк за 5 сек. выдергивает – это очень долго.
Потом пробовал напрямую к нужной строке обращаться:
Declare kur cursor for select контент from table
Open kur
Далее в цикле - fetch absolute номер_нужной_строки from kur
Результат примерно такой же

Как-то можно это дело ускорить??
Очень нужно! Помогите плииз..

Yurich · 12 сен 2005, 14:42

Самый быстрый способ - это select. Просто тебе надо посмотреть внимательно какие индексы ты строишь и как они используются в твоем коркретном селекте. Может быть проблема так же в настройках сервера или железе.

12 сен 2005, 18:41

IND= функция_номера_строки

Э... на сколько я понимаю из-за этого и тормозит. Пробуй between, или, если никак, то складывай индексы IND во временную таблицу и получай свои строчки Join'ом. Разумеется индексы, как заметил Yurich, проверять надо. Причём в данном случае явно напрашивается использование clustered индекса.

Milif · 13 сен 2005, 11:55

Э... на сколько я понимаю из-за этого и тормозит. Пробуй between, или, если никак, то складывай индексы IND во временную таблицу и получай свои строчки Join'ом. Разумеется индексы, как заметил Yurich, проверять надо. Причём в данном случае явно напрашивается использование clustered индекса.

Индекс именно такой – clustered. Таблица весит около 4 гегов. Когда она была раз в 40 меньше выборка 1000 строк в момент делалась. Я думаю тормоза из-за поиска в индексе. Т.е. приходит номер индекса, далее по этому номеру нужно выдернуть строку. Что делает SQL? Как я полагаю, он делает поиск в таблице индекса (значение индекса ведь физическому адресу строки не соответствует). Как он ведет поиск не знаю, может методом половинного деления может ещё как, но чем больше значений индекса, тем дольше поиск. Вообщем, я себе так это объясняю..
Непонятно почему во втором случае тормозит?? Я пытаюсь сразу обратиться к нужной строке, тобишь задаю её физический номер (адрес по нему сразу находится?). И всё равно тормоза!! (( Что делать, знает кто?

складывай индексы IND во временную таблицу и получай свои строчки Join'ом.

Это разве поможет?

13 сен 2005, 14:05

Там B-tree. Join в общем случае будет быстрее, особенно если во временной таблице тоже индекс будет. Я с функциями не знаком, но подозреваю, что технология такая же- если в IND 1000 значений, то проводится грубо говоря 1000 поисков по индексу 4Гб таблицы, что не быстро. А когда все значения известны, поиск существенно оптимизируется - по крайней мере происходит экономия времени при выборки данных, расположенных в одном октете. Хотя, быть может, мой склероз меня и подводит - я уже лет 5 шашек в руках не держал. Кстати, посмотри какой у тебя fill factor. Может и тут собака порылась.

Milif · 13 сен 2005, 21:01

AiK:
fill factor - 0% прописан.

Попробовал, как ты писал:
select a.ind from table as a inner join T as b on a.ind=b.ind , T - индексирована, содержит 1000 значений. Результат аналогичный

План показывает Clustered index seek (table). Избавиться бы от него...
Чтобы 1000 числовых значений из таблицы выдрать требуется 5 секунд! Должен же какой-то способ быть ?!

13 сен 2005, 21:31

План показывает Clustered index seek (table). Избавиться бы от него...

Дык это же не table scan.

fill factor - 0% прописан.

Если таблица не изменяется - поставь 100. Для конкретного индекса, разумеется.
Если меняется, то есть DBCCЧТОТОТАМ, которая показывает, как у тебя данные фрагментированы. Она же показывает рекомендумые значения для fill factor.

select a.ind from table as a inner join T as b on a.ind=b.ind

Что-то я тебя не понял. Тебе только индексы нужны или же содержимое строк?

ssDev · 14 сен 2005, 06:22

Windows плохо работает с файлами >=4 гб, так что многое зависит от операционки и железа которое ты используеш.
При таких размерах обычным анализом запросов не обойтись надо знать OS и СУБД.
В Oracle например можно разбить такую таблицу на несколько датафайлов.

Milif · 14 сен 2005, 09:56

select a.ind from table as a inner join T as b on a.ind=b.ind

Что-то я тебя не понял. Тебе только индексы нужны или же содержимое строк?

Конечно содержимое строк. Этот запрос для примера, он хорошо показывает на что всё время тратиться - на Clustered index seek (поиск в B-tree). Содержимое за то же время выводит.

Я так понимаю, задача не решаема ... Хотя мне идейку подкинули. DBCC PAGE - выдергивает нужную страницу из базы. Если fill factor задать 100% (таблица статична), вычислить номер нужной страницы и с читать её содержимое через DBCC PAGE или похожую функцию .. Выиграю я в скорости? Во всяком случае от поиска в B-tree избавлюсь

14 сен 2005, 17:08

fill factor 100 поиск ускорит однозначно. У тебя в итоге таблица будет меньшее количество страниц и экстентов занимать.
Про DBCC PAGE впервые от тебя услышал, почитал MSDN и сразу возникло два вопроса а) у тебя MS SQL 6.5? и 2) где ты собираешься парсить содержимое страницы?

P.S: поиск по двоичному дереву очень быстрый. Вся потеря времени - на загрузки страниц в память. Думаю, что без серьёзного тюнинга тут не обойтись. Для дальнейших советов нужно знать версию SQL сервера.