Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1
RSS
Сервер БД для больших объёмов данных
 
Здравствуйте!

Вот столкнулся с проблемой, при написании приложения,
дело в том что некоторые данные постоянно сохраняются на сервере БД.
Объем данных составляет ~30 байт на запись, интенсивность пополнения - от 1 до ~ записей в секунду,
, предположим это 3-4, т.е. уже где-то через сутки у моего MSSQL бд раздулась до 53 мегабайт, при этом начали возникать задержки при выборках, не маленькие.
Работать всё это будет 24/7/356 ;)
Вот собственно встал вопрос - какой сервер БД может более менее справляется с такими обьемами данных, т.к. MSSQL показал себя, как мне кажется в данном случае не очень хорошо.
 
ну postgres тогда попробуй
а платные СУБД с такими объёмами легко справляются)
 
хм,.. 53мб за 3-4 суток это совсем не большие объемы баз.
многие платные субд предоставляют и бесплатно девелоперские версии, у которых ограничемния конечно есть по perfomance, размерам баз.
если бы объемы были в милионы-десятки милионов записей - ткнул бы носом в тот же MSSQL, Oracle, SybaseASE, DB2,
сотни милионов - не знаю кто бы кроме sybase IQ справился бы.
меньше - и mssql это пока из пулеметом по вороб.ям - если машина позволяет тормозов не должно ыть, а т.к. есть скорее всего не настраивался сервер, почитайте как кэш увеличить, как в ночи не загруженые работой перестраивать индексы по полям из которых выборки подтормаживают.
 
Цитата
Bliznezz пишет:
хм,.. 53мб за 3-4 суток это совсем не большие объемы баз.

Подели эту цифру на 30 байт (размер одной записи) и получи число записей в базе. =) Как ты думаешь КАКИЕ там должны быть индексы, чтоб потом адекватно искать информацию? :)

ЗЫ и не за 3-4 суток, а за сутки!!! Это вообще пипец!
 
Цитата
Подели эту цифру на 30 байт (размер одной записи) и получи число записей в базе. =) Как ты думаешь КАКИЕ там должны быть индексы, чтоб потом адекватно искать информацию?
со времен разработки sybase ase и ms-sql организовывали хранение записей в logical pages, в те же базы ложились не только сами данные, но и системные таблички для того чтобы вообще организовать структуру данных, журнал транзакций.
потому теже 53мб - это не чистые данные по 30 байт на запись.  должно быть около 30мб в день
хотелось бы на select count(*) from той_таблички глянуть

а по поводу индексов - уверен что скорость выборок повысится если будут отстроены индексы по тем полям, которые используются в запросах
кеш данных будет держать индексы а не сами данные в памяти.
потому что когда делаются выборки - при отсутвии индексов - поиск идет по всей табличке, и если табличка не вмещается в памяти - sql-сервер будет её перечитывать каждый раз при выборке.

потому на увеличении кеша и отстраивании индексов настаиваю :D

Цитата
ЗЫ и не за 3-4 суток, а за сутки!!! Это вообще пипец!
не доглядел :oops:
 
Bliznezz правильно пишет про индексы. Проблема именно в неверной структуре базы.
Объем данных влияет только на размер передаваемый в select-е. Т.е. если выполнить Select * From .... действительно это будет долго.

Что касается:
Цитата
ak_ пишет:
ЗЫ и не за 3-4 суток, а за сутки!!! Это вообще пипец!
Либо у меня с математкой плохо, либо это не проблема. Примерно 2 000 000 записей за 3-4 дня ... это примерно 300 записей в минуту. Это конечно нагрузка, но далеко не смертельная. По крайней мере для MS SQL. За других не скажу. Работаю только с ним.
Что касается индексов: там 4-х байтный логн. Т.е. до 4 миллиардов можешь писать уверенно. Примерно 6000 дней. Т.е. по самой скромной оценки, индексов тебе хватит на 16 лет. Я думаю, что винты переполнятся раньше.

Если я где обсчитался, прошу меня поправить. Дело в том, что я регулярно решаю аналогичные задачи и эта проблема меня тоже беспокоит. Себя я уговорил, что все не так плохо. Но прав ли я?
 
2 Анатолий:

Цитата
Анатолий пишет:
Примерно 2 000 000 записей за 3-4 дня

За сутки! Получается, что 2 миллиона записей (эта цифра близка к верной если не сидеть с калькулятором и точно все высчитывать) в сутки, или 1200-1300 записей в минуту. Хотя автор топика пишет про:

Цитата
Андрей Титов пишет:
интенсивность пополнения - от 1 до ~ записей в секунду,, предположим это 3-4, т.е. уже где-то через сутки у моего MSSQL бд раздулась до 53 мегабайт

То есть получаетс, что там еще какие-то хранимые процедуры работают, которые генерят дополнительный поток записей в базу. (хз - может вычисления сложные какие-то)
 
дуется не столько база сколько её логи...проще по моему настроит реиндексирование базы..затем обрезку разбухшего лога..ну и собсна последняя процедура это сжатие базы ..хатяб один раз в неделю..
 
собссна обрезку логов можно сделать следующим скриптом...кому надо поправит
set transaction isolation level read uncommitted
use DATABASE

declare @dt1 datetime -- initial date
declare @dt2 datetime -- final date

select @dt1 = min(log_date) from log_data

select @dt2 = max(dt) -- initial date < final date < initial date + 3 days
-- AND final date < Current date - 3 month
from (
select dateadd(day, 3, @dt1) as dt
union
select dateadd(day, 2, @dt1) as dt
union
select dateadd(day, 1, @dt1) as dt
) t
where dt < dateadd(month, -3, getdate())

IF(@dt2 < dateadd(month, -3, getdate()))
Begin

print 'Deletion period:'
print cast(@dt1  as varchar(40)) + N' to ' +  cast (@dt2 as varchar(40))

delete
from log_data
where log_date between @dt1 and @dt2

End
 
в mssql должно быть что то штатное для обрезки журнала транзакций, аля dump tran dbname with truncate_only
я этого слона 2000й версии не щупал, но любой начинающий дба 2000го mssql скажет точно
 
На самом деле я рекомендую, во-первых, поставить БД на рэйд, если она работает под нагрузкой, которая со временем возрастает, во-вторых, если не хотите, чтобы разрастался лог, ставьте recovery model для БД в simple, тогда лог не будет сильно расти, но в этом случае обязательно нужен бэкап. В -третьих, если начинает тормозить, запускаете профайлер и смотрите тормозящие запросы. Индексы обязательно надо на поля с внешними ключами, по которым соединяются таблицы. Перестройка индексов для индексов короче 200 КБ - раз в неделю, для тех, что длиннее - раз в 2-3 дня. Проверено на БД в 1,5 млрд записей на MS SQL. Если много индексов и таблиц, разделите БД на 2 файла, в один положите таблицы, в другой - индексы, а сами файлы - на разные физические диски (если не на рэйду, конечно) ,это оптимизирует выборку, так как сканирование по индексам и по таблицам тогда разделится и ускорится.
Страницы: 1
Читают тему