Граждане, есть вопрос. Допустим, я создаю базу TPC-C, и заливаю ее лоадером с коэффициентом
-W100 (100 варехаусов). У меня в Firebird и InterBase база получается размером 8.8 гигабайт (без создания индексов).

Если кто занимался самостоятельно запуском TPC-C, можете сказать, какой объем при -W100 у Oracle, MS SQL, и т.п.?

MasterZivНу, скажем так, а зачем тебе это ? Не проще ли принять, что
места нужно под базу "дофига" и успокоиться ?
меня интересует соотношение объемов баз. 10 гиг это фигня, меня интересуют коэффициенты.

авторВ-нулевых, может быть зависит и от конкретной реализации TPC-C.
я как то думал, что требования к наполнению данных не могут зависеть "от реализации" теста. TPC-C это тест, и если будут его "реализации", то тогда и результаты нельзя будет сравнивать.
В описании теста, кстати, даются конкретные коэффициенты для всех таблиц, и правила генерации данных.

авторВо-первых, объём потребной БД будет зависеть от настроек разных СУБД. Они могут быть разные, и у тебя в итоге размер будет разный
насколько разные, в разы, на порядки?
меня интересует без настроек, by default. максимум что можно менять - размер страницы 16к.

авторВо-вторых, я думаю человек уже и не вспомнит, сколько там
этих гигов ушло под данные, и в третьих, он вспомнит только
сколько он выделил, а не сколько реально минимально надо было
выделять. Хотя бы в MSSQL это -- разные вещи.
кто не вспомнит - пусть не вспоминает. и меня не интересует "сколько выделил", я понимаю, что на 10 гиг данных можно выделить 100 гиг, но я не об этом спрашиваю.

К чему все усложнять? Да, я хочу получить хоть какое-то сравнение по мотивам этого топика
http://www.sql.ru/forum/actualthread.aspx?tid=664884
нет, меня не интересуют никакие "неумолчательные" параметры сжатия и прочего, т.е. возможности конкретной СУБД в этом плане.
Я просто хочу понять, если я взял 10 гиг tpcc данных (100 warehouses), то сколько это будет в MS SQL, Оракле, ДБ2, и так далее.

MasterZivВот размер страницы и будет влиять.
сомневаюсь, что будет. даже если резервирование места на страницах делается, то наверняка от размера страницы процент резервирования не зависит. А в тпц-ц записи мелкие, так что хоть с размером страницы 2к, что 16к, 100 варехаусов будут иметь практически один и тот же размер.

для MS SQL уже заряжено, а вот с другими пока тишина. ну и ладно.

ApexТак что вы таким способом померяете среднюю температуру по больнице, ИМХО.
ничего подобного. допустим, есть 2 архиватора. У одного есть варианты выбора степени сжатия, у другого - нет. Причем у первого (с вариантами) есть сжатие по умолчанию.

Берем эталонный файл, жмем обеими архиваторами. Получаем разницу. Здесь с БД то же самое, абсолютно, но почему-то вызывает подозрения на холивар или "с этой СУБД вы правильно ничего не померяете". Я не пытаюсь выяснить максимальное или минимальное сжатие. Я просто хочу узнать, сколько по объему занимает один и тот же эталонный объем данных, при умолчательных параметрах, только и всего. Нет задачи выяснять, кто сильнее сожмет или пытаться "сжать" данные одним сервером так же как и другим.

Apexно при дложной настройке получается сильно лучше, чем у другого хоть занастройся, тогда что?
да ничего. я в жизнь не поверю, что у Оракла или MS SQL например нельзя просто взять и создать таблицу. Не указывая экстенты и прочее. Если нельзя - пусть будет 8к или 16, пофиг.

Apexу кого какие настройки по-умолчанию, но не возможности по сжатию как таковые. Если это и есть цель - я согласен.
ужас. да мне пофиг у кого какие настройки по умолчанию. И меня не интересуют "возможности по сжатию". Вы вообще преувеличиваете возможности конкретной и тонкой настройки, которая тут нафиг не уперлась. Если бы я спросил, насколько сильно сервер может сжать сырые данные, тогда да, можно было бы скакать вокруг настроек, задать 0% резервирования свободного места на страницах, и т.п. Но я же про это не спрашиваю. Меня даже не интересуют предполагаемые размеры логов.
Меня интересует тупое хранение некоего стандартного набора данных на страницах размером 4, 8 или 16к. При том что для 10 гиг данных разница между размером страницы не будет иметь значения (как минимум потому, что в tpc-c тесте максимальный размер записи - 700 байт).

Короче, все равно никто на вопрос ответить не может, по вполне понятным объективным причинам, а Вы не только не ответили, но и начинаете мне я--а крутить. Я понимаю, если бы речь шла о вопросе производительности этого самого tcp-c. Так ведь даже об этом я ни слова не сказал.

ApexНормально... я еще и му**к в данной ситуации.
судя по отзывам на мой вопрос - я первый :-)

скрипт структуры БД прислать не проблема. Проблема может быть с лоадером, т.к. он скомпилен для ИБ-ФБ. Пришлите мне пожалуйста письмо на kdv@ibase.ru, я перешлю скрипт и исходники, вдруг что получится.

DSИ не хотят плохо выглядеть на фоне известных серверов.
это все домыслы (не твои). В смысле, если плохо жмет, то плохой, или если хорошо жмет, то плохой?
ничего, кроме коэффициента "размера", я знать не хочу. Мне нужен очень приблизительный коэффициент разницы, чтобы можно было сказать - если в ФБ база 10 гиг, то в MS SQL она займет .... К примеру, есть информация от одного человека, что он перегоняя базу из ФБ в MS SQL получил размер в 1.8 раз больше. Это была его база, и в MS SQL он разбирается.

Причем, действительно, в сжатии особой крутизны нет, т.к. хоть ИО и меньше, но оверхед на распаковку больше грузит проц. Так что если и TPC-C у MS SQL получится больше, чем у ФБ, это даже не говорит о том, что MS SQL "хуже пакует". Просто теоретически, в среднем по больнице, вот такая разница в объеме хранимых данных. То есть, чисто оценочные данные.

to Apex : извиняюсь, запарка в конце квартала, завтра (уже сегодня) вышлю что нашел.