Большие таблицы

← →
картман © (2009-11-30 12:43) [0]

Всем привет!
Есть БД с большим кол-вом записей в таблицах - > 1 000 000. Запись ведется постоянно и стала медленной. Кол-во записей увеличивается постоянно. СУБД SQL Server 2005, но, думаю, не принципиально. Вопрос - как организовать эффективное хранение/добавление/извлечение данных, при условии, что эти операции проводятся одновременно(или почти одновременно). Как вообще решаются вопросы производительности больших БД? Подскажите литературу, плиз.

← →
Sergey13 © (2009-11-30 12:46) [1]

При таком вопросе недурственно бы еще указывать что за таблица (структура, индексы и т.п.) и как конкретно ведется запись.

← →
Игорь Шевченко © (2009-11-30 12:47) [2]

> Есть БД с большим кол-вом записей в таблицах - > 1 000
> 000

разве это большое количество

← →
clickmaker © (2009-11-30 12:53) [3]

> Есть БД с большим кол-вом записей в таблицах - > 1 000 000

и все нужны?
может, имеет смысл периодически архивировать или чистить?

← →
картман © (2009-11-30 12:54) [4]

> Sergey13 © (30.11.09 12:46) [1]

Ну, со-структурой и индексами я разберусь. Мне в более глобальном плане.

запись ведет программа, анализирующая тексты, примерно 5-20 зап/сек

> Игорь Шевченко © (30.11.09 12:47) [2]

Для меня большое - как сделать, чтоб стало маленьким?

← →
картман © (2009-11-30 12:54) [5]

> clickmaker © (30.11.09 12:53) [3]

нужны

← →
Sergey13 © (2009-11-30 12:57) [6]

> [4] картман © (30.11.09 12:54)
> Мне в более глобальном плане.

Т.е. фигни всякой? 8-)
Все глобальное складывается из очень конкретных неправильных действий. Например только сочетание нескольких ошибок привело к "глобальному" взрыву на ЧАЭС.

← →
clickmaker © (2009-11-30 12:57) [7]

> [5] картман © (30.11.09 12:54)

тогда, не зная структуру данных, мало что посоветовать можно

← →
ZeroDivide © (2009-11-30 12:57) [8]

На триггере Before Insert ничего "такого" не понаписано? Летать должна вставка, если ничего лишнего на триггерах не висит. Дальнейшая оптимизация - проблема самой СУБД.

← →
ZeroDivide © (2009-11-30 13:00) [9]

Ну и да, попробуйте повключать-поотключать некоторые индексы. Возможно тоже даст эффект.

← →
ZeroDivide © (2009-11-30 13:02) [10]

И с транзакциями тоже посмотрите, что у вас. Возможно коммитить можно пакетами, а не после каждой вставки... это зависит, конечно, от специфики задачи.

← →
Sergey Masloff (2009-11-30 13:15) [11]

По идее скорость записи от числа записей зависеть не должна.
Если на таблице кроме вставки еще и удаления относительно часты и есть индексы то замедление возможно - нужно предусмотреть эпизодическую перестройку индексов. Если идет только вставка то перестройка нужна гораздо реже. Кстати наверняка в настройках есть опция (я не спец в MSSQL) чтобы при вставке не использовать "дырки" от удаленных записей.

← →
clickmaker © (2009-11-30 13:18) [12]

> чтобы при вставке не использовать "дырки" от удаленных записей.

насколько я знаю, мс скл их и не использует
для упаковки базы в нем есть специальные команды, которые видимо и оптимизируют размещение блоков, то есть дефрагментируют

← →
картман © (2009-11-30 13:22) [13]

> ZeroDivide © (30.11.09 12:57) [8]

ничего

> Sergey Masloff (30.11.09 13:15) [11]

там перед вставкой несколько select"ов идет...

Так есть книжка СуперХранилищеДанных за 24 часа?

← →
clickmaker © (2009-11-30 13:26) [14]

> Так есть книжка СуперХранилищеДанных за 24 часа?

конечно. Это называется "знал бы прикуп - жил бы в Сочи"

← →
Anatoly Podgoretsky © (2009-11-30 13:28) [15]

> Для меня большое - как сделать, чтоб стало маленьким?

Так у тебя и так маленькое количесто, 1 000 000 это же смешно.

← →
Sergey13 © (2009-11-30 13:29) [16]

> [13] картман © (30.11.09 13:22)
> там перед вставкой несколько select"ов идет...

Постов через 20 выяснится, что ПК заполняется max+1 по неиндексированным полям. 8-)

← →
Anatoly Podgoretsky © (2009-11-30 13:30) [17]

> при вставке не использовать "дырки" от удаленных записей.

Что бы снизить быстродействие?

> для упаковки базы в нем есть специальные команды, которые
> видимо и оптимизируют размещение блоков, то есть дефрагментируют

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

Только чего говорить об квадратном коне в вакуме?

← →
Anatoly Podgoretsky © (2009-11-30 13:31) [18]

> картман © (30.11.09 12:43)

Вооспользуйся профайлером, да и вопрос этот для специализированого форума, по данной СУБД

← →
картман © (2009-11-30 13:37) [19]

> Anatoly Podgoretsky © (30.11.09 13:28) [15]

1 млн * 365 * (не знаю, сколько лет)? Ну ладно, последний множитель 1.

> Anatoly Podgoretsky © (30.11.09 13:30) [17]

>
> Только чего говорить об квадратном коне в вакуме?

Да не нужно мне, как завязывать шелковые шнурки салатового цвета - меня интересует, как завязывать шнурки вообще.

← →
Anatoly Podgoretsky © (2009-11-30 13:39) [20]

> картман (30.11.2009 13:37:19) [19]

Ты уже определил узкое место, проштудировал BOL?

← →
clickmaker © (2009-11-30 13:44) [21]

> [19] картман © (30.11.09 13:37)

вот эти скрипты позапускай. Глядишь, и обрисуется слабое место
http://msdn.microsoft.com/ru-ru/magazine/cc135978.aspx

← →
картман © (2009-11-30 13:54) [22]

> Anatoly Podgoretsky © (30.11.09 13:39) [20]

Сейчас займусь

> clickmaker © (30.11.09 13:44) [21]

Спасибо большое

← →
Anatoly Podgoretsky © (2009-11-30 13:57) [23]

> Сейчас займусь

Если ты хочешь квалифицированый ответ, то тебе надо идти на www.sql.ru

← →
картман © (2009-11-30 14:02) [24]

> Anatoly Podgoretsky © (30.11.09 13:57) [23]

мне там интерфейс форума не нравится и потом, с насморком привык сюда:)

← →
Игорь Шевченко © (2009-11-30 14:09) [25]

я не понял, у тебя на вставке миллиона записей тормоза или на вставке десятка тысяч в таблице с миллионом тормоза ?

← →
картман © (2009-11-30 14:15) [26]

> Игорь Шевченко © (30.11.09 14:09) [25]

На вставке десятка тысяч в таблицу с миллионом. Только как-то странно - когда приложение делает анализ и потом заносит в БД данные, обычно грузит процессор(ядро) на 100%, работы СУБД же почти не заметно - по загрузке проца, сейчас же наоборот - анализатор простаивает, а СУБД съедает все ресурсы. Что-то не верится, что из-за увеличения кол-ва записей, так сильно могли поменяться приоритеты...

← →
Игорь Шевченко © (2009-11-30 14:17) [27]

> На вставке десятка тысяч в таблицу с миллионом

ну это у тебя чего-то с базой спроектировано не так...или с приложением. То есть, мало информации

← →
Anatoly Podgoretsky © (2009-11-30 14:52) [28]

> картман (30.11.2009 14:15:26) [26]

Вполне нормально, при кардинальном изменение количества записей, план может измениться сильно.

> На вставке десятка тысяч в таблицу с миллионом

транзакция явно стартует?

> [30] картман © (30.11.09 15:10)

рекомендую стартовать
фишка в том, что при отсутствии явной транзакции, сиквел стартует ее для каждой операции (insert, select, update, delete). А это накладные расходы.
А если еще и триггеры на таблицу навешаны...
Вообще, вставка 10 тысяч записей одним махом наводит на мысль о bulk copy или о чем-то наподобие. Если конечно при этом какая-то логика не должна срабатывать, в т.ч. и на триггерах

> картман (30.11.2009 15:10:30) [30]

Это невозможно, все операции идут только в рамках транзакции.

> clickmaker © (30.11.09 15:16) [31]

bulk не пойдет из-за логики программы

> рекомендую стартовать

т.е. тут:

if exists(select * from table where id = 13234)
insert into...

две транзакции?

> две транзакции?

нет, потому что if - атомарная операция
вот отдельно селект и инсерт не связанные - две

> картман (30.11.2009 15:19:33) [33]

Одна, это называется пакет.

> if exists(select * from table where id = 13234) > insert into...

вот тут-то похоже собака и порылась

> if exists(select * from table where id = 13234)
> insert into...

я говорил, что приложение плохое

> clickmaker © (30.11.09 15:21) [34]

> Anatoly Podgoretsky © (30.11.09 15:22) [35]

> Petr V. Abramov © (30.11.09 15:23) [36]

ужас. Я в шоке.

> Игорь Шевченко © (30.11.09 15:26) [37]

я сейчас тремя строчками исправлю эту плохоту, новый код сам подгрузится?

> картман © (30.11.09 15:30) [39]

> ужас. Я в шоке.
>

от чего ты в шоке? от того, что скорость селекта разная на 1000 записей и на миллионе?

Большие таблицы Найти похожие ветки