pgresДа что Вы заладили каше - большие объемы данных / данные растут в геометрической прогрессии
до боли напоминает рекламные с программированием ассоциаций
наверное это на тренингах по каше как мантру повторяют

понятия не имею, я там никогда не был.

pgres
лично у меня с большими объемами данных ассоциируется оракл и дб2
да откройте наконец секрет какие у Вас например объемы и почему так остро стоит проблема дискового пространства

диск небольшой, а MSSQL много кушает.
~300 млн. записей, а ведь индексировать еще нужно. если мне сейчас скажут,
что это все ерунда и без индексов SQL выберет все, что нужно за минуту,
я не поверю.

pgres
автор
true кешистов/м-щиков давно/пока нет, все на чем-нибудь из РСУБД да
работают.

это говорит в пользу рсубд

"на безрыбье..." :)

pgres
если прочитаете 5 пункт то увидите что данные надо выбирать за месяц

я не слепой. а мат.операции делались на этой выборке или на всей базе?

pgres
с нетерпением жду результатов
ЗЫ: если результаты будут такими которые легко опротестовать то зачем эти результаты
как только Joker ответит
еще кстати не хило бы спросить: а выбранные данные куда-то складывались,
пересылались или как?

yww@escape.ru
Я думаю что предложенные тесты не дадут объективно стравнить Cache и Oracle потому что для решения реальных задач будет использоваться принципиально разный способ организации данных.

да не только поэтому. во-первых, надо проверять на одном оборудовании,
во-вторых, при одинаковой нагрузке. ну будет у меня быстрее, а мне
скажут - фигня, это у тебя 40 пользователей не работали. а будет медленнее,
я скажу - извините, господа, у меня простенький комп на 1.8Ghz/1Gb с IDE.


>>2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
вот тоже самое.. не будет программист на Каше делить на 3600. Там есть встроенные функции преобразования количества секунд во время формата ЧЧ:ММ:СС .. они входят в сам язык, поэтому реализованы на C.

ну-ну, чего это он не будет? может стандартная функция возьмет значение
часа более 23? :)


>>3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
вот это сравнение может что нибудь и даст..

а вот тут вообще забавно. средняя продолжительность получается делением
значения из пункта 2. на значение из пункта 1. причем тут групповые операции? может я что-то путаю? или его нужно каждый раз перевычислять
во время выборки? это было бы странно


5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
опять не выйдет сравнение.. в Каше не нужно выбирать данные за месяц.. они уже будут лежать в узле, относящемся к этому самому месяцу.
ну, так нельзя. прочитают люди и подумают, что так оно там всегда и пишется.
конечно же не так. я, например, буду организовывать индекс по дате, так правильнее, вдруг выборка будет за неделю.

С уважением. Сергей

pgres Sergei Obrastsov
диск небольшой, а MSSQL много кушает.
~300 млн. записей, а ведь индексировать еще нужно. если мне сейчас скажут,
что это все ерунда и без индексов SQL выберет все, что нужно за минуту,
я не поверю.

и это послужило причиной перехода с mssql на cache ? в таком случае Вы просто фанатик
300 млн. - ну пусть это 300 Гб ну пусть еще 150 Гб на индексы
да сейчас люди домой для фильмов такие диски покупают(не плохо былоб если б Вы указывали иногда и физический размер, все таки диски со строками не работают)

записи-то? 156 байт в plain-файле. а вот насчет дисков проблема, 80Gb - все,
что доступно. и это ведь не одна задача, там их несколько крутится, эта просто самая жирная. :)


я вас умоляю скоьлко там данных - за три года 1096 строк

5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)


я, видимо, совсем не умею читать?


PS так почему Вы замалчиваете ответ про TPC :)

а я-то здесь при чем? я что-ли разработчик и продавец Cache? есть сайт
InterSystems - у них и спрашивайте. насколько я слышал, Cache туда не
берут поскольку она не RDBMS. может и врут.

SiDenСергей, я же привел ссылки по подсчету размеров индексов, давайте сравним.
я прочитал. а что с чем будем сравнивать-то?

С уважением. Сергей

SiDenс вашей табличкой с индексами, где ~300млн.
дык сравнивайте. все данные для этого есть здесь

/topic/288398&pg=4#2628282
/topic/288398&pg=5#2629383

если я неправильно использовал индексирование в SQL и на самом
деле индекс по дате займет гораздо меньше места, то самое время
мне об этом сказать. а то как-то все промолчали.

С уважением. Сергей

SiDenметодику рассчета еще для Каше плз, хотя бы только для индексов, на сколько я понимаю основные вопросы по ним, а не по данным
не могу, вроде как формул не описано, тем более они жмутся по префиксам.
я привел конкретные данные, полученные до и после полной индексации по 9 полям.
не, вру, 1.15Gb - это уже с индексом по дате. 300 млн. записей это максимальный объем, сейчас только 81 с мелочью.

С уважением. Сергей

SiDen
данные занимают 237472 страницы по 8192 байта (1855.25 мб)

очень близко к реальности

SiDen
кластерный индекс: размер - 20 байт (исходя из того что 1 поле - 8 байт)
на странице умещается - 368 строк
считаем по уровням: level0 = 237472/368=646
level1=646/368=2
level2=1
итого: кол-во занимаемых страниц - 649 по 8192 байта.

подумаем. 5Mb? интересно. перепроверил, все правильно.
очень впечатляет.


ЗЫЫ: для рассчета индекса некластерного нужно знать размерность кластерного (он будет больше)
насколько больше? мне ведь их еще 8 нужно.
и что это тогда был за индекс, который так хорошо убил базу в моем
примере?

С уважением. Сергей

pgres Sergei Obrastsov SiDenметодику рассчета еще для Каше плз, хотя бы только для индексов, на сколько я понимаю основные вопросы по ним, а не по данным
не могу, вроде как формул не описано, тем более они жмутся по префиксам.
я привел конкретные данные, полученные до и после полной индексации по 9 полям.
не, вру, 1.15Gb - это уже с индексом по дате. 300 млн. записей это максимальный объем, сейчас только 81 с мелочью.
С уважением. Сергей
1.15Gb это те самые 300млн строк ?
чувак это не объем у тебя ж памяти гиг
а внимательнее читать по ссылке не получается? там ведь прямо сказано,
что тестируется база из 18 млн. записей

SiDenСергей, еще было бы не безинтересно посмотреть на размер без сжатия.
без моего "ручного" или без сжатия индексов? с индексами никак не смогу,
они жмутся системой, а вот "ручное" могу и убрать. только пересчитываться
будет долго.

С уважением. Сергей

Gluk (Kazan)Про измерение индексов в MySQL на FAT32 улыбнуло
коментировать как то более развернуто не до сук
P.S. не серьезно это
верю. я потому и ждал каких-либо серьезных замечаний.
вроде как "а у меня в DB2" или там "а мой MSDE", или уж "а вот Oracle"...
делов-то на полчаса.
нет ничего. ну и какие ко мне претензии тогда?
вот человек откликнулся, спасибо ему. надеюсь, все-таки
доведем эту тему до логического завершения.

SiDenБез ручного конечно.
Встроенное незачем трогать да и "никак" :)
можно и так прикинуть. если брать по-максимуму, то добавится 16 символов
на каждую запись. итого ~289 Mb, если еще грубее, с учетом увеличения
число блоков БД, то 300.

С уважением. Сергей

P.S. Надеюсь от меня не потребуют учитывать еще и "ненужные" разделители? :)