Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11   вперед  Ctrl      все
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
2 yww@escape.ru

ну хорошо, а насчет TPC тестов - тоже кашисты слишком гордые чтобы в них участвовать

--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
19 май 06, 14:38    [2684551]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

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

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

pgres

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

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

pgres

автор

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

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

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

pgres

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

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

pgres

с нетерпением жду результатов
ЗЫ: если результаты будут такими которые легко опротестовать то зачем эти результаты

как только Joker ответит
еще кстати не хило бы спросить: а выбранные данные куда-то складывались,
пересылались или как?
19 май 06, 14:41    [2684589]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
pgres
2 yww@escape.ru

ну хорошо, а насчет TPC тестов - тоже кашисты слишком гордые чтобы в них участвовать

--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)



Не понял вопрос.. возможно вы с кем то обсуждали эту тему.. но не со мной.
О какой гордости идет речь?
19 май 06, 14:50    [2684674]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Sergei Obrastsov

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

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


автор
как только Joker ответит
еще кстати не хило бы спросить: а выбранные данные куда-то складывались,
пересылались или как?

я вас умоляю скоьлко там данных - за три года 1096 строк
автор
"на безрыбье..." :)

опять не в пользу каше

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

--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
19 май 06, 15:00    [2684753]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
yww@escape.ru
pgres
2 yww@escape.ru

ну хорошо, а насчет TPC тестов - тоже кашисты слишком гордые чтобы в них участвовать




Не понял вопрос.. возможно вы с кем то обсуждали эту тему.. но не со мной.
О какой гордости идет речь?


простите, действительно tpc не с вами

но по поводу вашего поста о целесообрзности тестов скажу что в оракле тоже не все так просто работает как вы думаете однако никто не заявляет что нет смысла в тестах так как cost based optimizer & materialized views

--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
19 май 06, 15:08    [2684813]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
yww@escape.ru

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

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


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

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


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

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


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

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

С уважением. Сергей
19 май 06, 15:11    [2684832]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
>>конечно же не так. я, например, буду организовывать индекс по дате, так правильнее, вдруг выборка будет за неделю.

если вы уже на этапе постановки задачи знаете что вам портебуются выборки по датам, то и данные можно хранить в узлах, организованных на $h... а здесь уже всё равно - по месяцу, по неделе, по году - принцип то один и тот же.. становитесь на начало периода и двигаетесь до конца.. дополнительные индексы здесь могут и не понадобиться. ИМХО, конечно..
19 май 06, 15:27    [2684969]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140

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

да мудро. эти данные и так аплодятся по порядку через append это же udr
так что за оракл не волнуйтесь он возьмет только нужные блоки
--
Кто - еще до сражения - побеждает предварительным расчетом , у того шансов много (Сунь Цзы)
19 май 06, 15:28    [2684977]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
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. может и врут.
19 май 06, 15:33    [2685015]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
Сергей, я же привел ссылки по подсчету размеров индексов, давайте сравним.
19 май 06, 16:30    [2685353]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

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

я прочитал. а что с чем будем сравнивать-то?

С уважением. Сергей
19 май 06, 16:35    [2685383]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
с вашей табличкой с индексами, где ~300млн.
19 май 06, 16:40    [2685402]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen
с вашей табличкой с индексами, где ~300млн.

дык сравнивайте. все данные для этого есть здесь

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=4#2628282
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=5#2629383

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

С уважением. Сергей
19 май 06, 16:45    [2685430]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
методику рассчета еще для Каше плз, хотя бы только для индексов, на сколько я понимаю основные вопросы по ним, а не по данным
19 май 06, 16:48    [2685442]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen
методику рассчета еще для Каше плз, хотя бы только для индексов, на сколько я понимаю основные вопросы по ним, а не по данным

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

С уважением. Сергей
19 май 06, 16:54    [2685481]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
Я и не сомневаюсь что не врете:
итого, что вышло, по той таблице что Вы приводили с 19-ю столбцами, при 18047848 записях и кластерным индексом по date
при расчетах таблица у меня была 18 столбцов, date и time я считал за один (8 байт)
данные занимают 237472 страницы по 8192 байта (1855.25 мб)
кластерный индекс: размер - 20 байт (исходя из того что 1 поле - 8 байт)
на странице умещается - 368 строк
считаем по уровням: level0 = 237472/368=646
level1=646/368=2
level2=1
итого: кол-во занимаемых страниц - 649 по 8192 байта.

ЗЫ: fill factor = 100%
ЗЫЫ: меня еще смутил несколько int(3), но для теоритических рассчетов это не актуально, на порядок не влияет :)
ЗЫЫ: для рассчета индекса некластерного нужно знать размерность кластерного (он будет больше)
19 май 06, 17:29    [2685680]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Sergei Obrastsov
SiDen
методику рассчета еще для Каше плз, хотя бы только для индексов, на сколько я понимаю основные вопросы по ним, а не по данным

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

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


1.15Gb это те самые 300млн строк ?
чувак это не объем у тебя ж памяти гиг
19 май 06, 17:38    [2685726]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
Сергей, еще было бы не безинтересно посмотреть на размер без сжатия.
19 май 06, 17:48    [2685779]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov

дык сравнивайте. все данные для этого есть здесь

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=4#2628282
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=5#2629383

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


Про измерение индексов в MySQL на FAT32 улыбнуло
коментировать как то более развернуто не до сук

P.S. не серьезно это
19 май 06, 17:53    [2685814]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen

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

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

SiDen

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

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


ЗЫЫ: для рассчета индекса некластерного нужно знать размерность кластерного (он будет больше)

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

С уважением. Сергей
19 май 06, 18:07    [2685871]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
pgres
Sergei Obrastsov
SiDen
методику рассчета еще для Каше плз, хотя бы только для индексов, на сколько я понимаю основные вопросы по ним, а не по данным

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

1.15Gb это те самые 300млн строк ?
чувак это не объем у тебя ж памяти гиг

а внимательнее читать по ссылке не получается? там ведь прямо сказано,
что тестируется база из 18 млн. записей
19 май 06, 18:09    [2685884]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen
Сергей, еще было бы не безинтересно посмотреть на размер без сжатия.

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

С уважением. Сергей
19 май 06, 18:12    [2685901]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Gluk (Kazan)
Про измерение индексов в MySQL на FAT32 улыбнуло
коментировать как то более развернуто не до сук
P.S. не серьезно это

верю. я потому и ждал каких-либо серьезных замечаний.
вроде как "а у меня в DB2" или там "а мой MSDE", или уж "а вот Oracle"...
делов-то на полчаса.
нет ничего. ну и какие ко мне претензии тогда?
вот человек откликнулся, спасибо ему. надеюсь, все-таки
доведем эту тему до логического завершения.
19 май 06, 18:16    [2685920]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SiDen
Member

Откуда:
Сообщений: 518
Без ручного конечно.
Встроенное незачем трогать да и "никак" :)
19 май 06, 18:26    [2685950]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
SiDen
Без ручного конечно.
Встроенное незачем трогать да и "никак" :)

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

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

P.S. Надеюсь от меня не потребуют учитывать еще и "ненужные" разделители? :)
19 май 06, 18:38    [2685987]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8 9 10 11   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить