Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > MS SQL Server > Безнадёга

Автор: Artemon 5.2.2006, 16:33

Была у меня программа, которая довольно сносно работала с текстовыми базами (самодельными) пример: {art}ARTIST {alb}ALBUM {gen}GENRE ......... ........ ....... Была у меня текстовая БД в 5 mb, я ее полностю грузил в оперативку , а там уже работал с ней. Решил перейти на реляционные БД. За месяц переделал прогу с текстовых БД на MSSQL. ОООООООООООООО ужас поиск в MSSQL происходит медленее чем в тексте, загруженном в память. Разве так может быть?????????????????????? P.S. Произвожу поиск по тексту. (%ANY_TEXT%)

Автор: useless 5.2.2006, 20:05

Раслабься, так и должно быть!!!! Всё, что загружено в оперативку, обрабатывается быстрее, чем то что храниться в БД. Выгоду от использования любой СУБД можно получить только при работе в режиме многопользовательского доступа.

Автор: ТоляМБА 6.2.2006, 06:41

4 Artemon БД ведь у тебя лежит на винте. Посмотри скорость доступа к винту и скорость доступа к оперативке и сразу всё поймешь.

Автор: Artemon 6.2.2006, 08:29

Жестоко.

Автор: Vit 6.2.2006, 15:45

Хм... Возможно дело в неправильной оптимизации. MS SQL Server достаточно по умному кэширует данные и оставляет запрашиваемые данные в оперативке. Лучше приведи примеры запросов которые тормозят и структуру таблиц на которых они проходят. PS. Базы данных действительно не дадут выигрыша в скорости на небольших массивах данных, потому как неизбежны накладные расходы в виде ретрансляции потоков данных из одной программы в другую, многоступенчатые преобразования: программа-драйверБД-сервер-данные, компилляция запросов и т.д. Но у баз данных есть неоспоримые преимущества - они дают значительное увеличение производительности на больших масивах данных или при многопользовательском использовании, делают системы легко расширяемыми и дают существенные удобства в манипулировании данными.

Автор: Artemon 6.2.2006, 16:04

Вот у меня какой самый тормозной запрос Код SELECT ALBUM, YEAR, PATH, ARTIST, GENRE, ALBUMS.ID_ALBUM, SONG FROM ALBUMS, ARTISTS, GENRES, SONGS  WHERE SONG LIKE '" + NormalizeSQL_QUERY(Context) + "%' ESCAPE '" + ESC_TOKEN + "' " AND ALBUMS.ID_ALBUM = SONGS.ID_ALBUM AND ALBUMS.ID_ARTIST = ARTISTS.ID_ARTIST  AND ARTISTS.ID_GENRE = GENRES.ID_GENRE ORDER BY ARTIST  P.S. В каждой таблице не больше 40000 строк

Автор: Vit 6.2.2006, 19:22

Мдя... Ты делаешь декартово произведение... Реально ищется не через 40000, а через 40000*На ARTISTS * на GENRES * SONGS, т.е. реально сервер лопатит десятки миллионов записей. Чтобы сделать это по человечески наду применить Join (Inner или Outer в зависимости от задачи) Что-то вроде: Код SELECT ALBUM, YEAR, PATH, ARTIST, GENRE, ALBUMS.ID_ALBUM, SONG FROM ALBUMS with (nolock) left outer join ARTISTS with (nolock) on ALBUMS.ID_ARTIST = ARTISTS.ID_ARTIST  left outer join GENRES with (nolock) on ARTISTS.ID_GENRE = GENRES.ID_GENRE left outer join SONGS with (nolock) on ALBUMS.ID_ALBUM = SONGS.ID_ALBUM WHERE SONG LIKE '" + NormalizeSQL_QUERY(Context) + "%' ESCAPE '" + ESC_TOKEN + "' " ORDER BY ARTIST  Кроме того надо поставить индекс на поле SONG, желательно кластерный Если это не поможет, тогда надо будет ещё поработать над оптимизацией. PS. на 40000 записей сервер должен искать практически мгновенно, никак не долее 1 секунды, если дольше - то проблемы с запросом или структурой данных

Автор: boevik 7.2.2006, 09:13

Vit, ты не прав. Artemon использовал inner join по старой системе, так что у него не получилось декартово произведение.

Автор: Vit 7.2.2006, 15:59

Цитата(boevik @ 7.2.2006, 00:13 ) Vit, ты не прав. Artemon использовал inner join по старой системе, так что у него не получилось декартово произведение. Вроде как то, что он использовал - это "Cross Join" по старой системе, но я могу ошибаться, сейчас посмотрю как MS SQL Server меняет план выполнения запроса в этом стиле... Добавлено @ 16:03 Ага, ты прав... Inner Join получается... Тогда, Artemon присылай базу данных, попробую покрутить у себя и подумать как сделать её побыстрее... В любом случае на 40K записей практически любые запросы должны выполняться практически мгновенно...

Автор: Artemon 8.2.2006, 18:53

Vit, огромное спасибо, но нет возможности выслать базу.

Автор: Vit 8.2.2006, 20:10

Тогда смотри сам в Query Analyser чего твоя квери делает и какая операция жрёт время. Индексы ставить не пробовал? На вскидку нужны индексы по следующим полям ALBUMS.ID_ARTIST = ARTISTS.ID_ARTIST ARTISTS.ID_GENRE GENRES.ID_GENRE ALBUMS.ID_ALBUM SONGS.ID_ALBUM SONG Желательно кластерный индекс по полю SONG

Автор: Artemon 8.2.2006, 20:57

А что значит кластерный?

Автор: boevik 8.2.2006, 22:55

В селекте участвует 4 таблицы, если в них нет индексов то происходит довольно ощутимое сканирование таблиц. Желательно, а то и обязательно индексы по полям: ID_ALBUM в таблицах ALBUMS и SONGS ID_ARTIST в таблицах ALBUMS и ARTISTS ID_GENRE в таблицах ARTISTS и GENRES

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)