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

Откуда:
Сообщений: 257
На мой взгляд, Вы пока еще не начали понимать про MUMPS, pgres.
Именно в РСУБД "теория" вся в белых пятнах. Очередной пример - горячо обсуждаемые "индексы".
"Индексы" - это банальный пример денормализации для повышения производительности. В "индексах" хранятся (еще раз) самые, что ни на есть, настоящие данные. Это в бОльшей степени данные, чем так называемые метаданные (словари данных). Если метаданные "хранятся" в РСУБД в отношениях (на логическом уровне), как и "основные" данные, и это считается важным и полезным, то почему же данные ("индексы") не "хранятся" тоже в отношениях ? Они хранятся почему-то в какой-то другой (если рассуждать с точки зрения модели данных) СУБД, к которой имеет доступ "оптимизатор запросов" так называемой РСУБД. Осмысление этой ситуации возможно принесет больше пользы, чем изучение технических вопросов физической организации данных.
И по скорости, и по "теории", и по "подвижности специалистов" MUMPS превосходит РСУБД. Специалистов по MUMPS намного меньше, и распространены системы на MUMPS меньше, чем на РСУБД. Это факт. В любой области есть попса, и есть альтернативные направления для "высоколобых", "идиотов", "интеллектуалов", "маргиналов" (кому как больше нравится).
19 май 06, 21:08    [2686404]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
SergSuper
Member

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

P.S. Надеюсь от меня не потребуют учитывать еще и "ненужные" разделители? :)
А вот еще вопрос: чего Вы периодически всё про разделители упоминаете? Они как-то суются в данные? Просто странно как-то, я единственно когда про разделители думал - ну разве что при экспорте текстовых файлов
19 май 06, 23:57    [2686800]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
yww@escape.ru

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

Ага, придумали новый отмазон. Да какая разница как они там данные организованы, мы же и не собираемся сравнивать способ организации данных, мы собираемся сравнивать производительность. Производительность тоже принципиально разная? Ее что нельзя измерить в секундах на запрос, а секунды что, разные для всех серверов?

yww@escape.ru

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

Магическое слово "С". А конвертация строки, в которой хранится число и дата в КЕШ-е, в число ничего не занимает? Говорили уже - занимает, даже если это все реализовано на на страшном и ужасном С.

yww@escape.ru

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

А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель), а для выборки по району города они будут лежать в узлах по этим самым районам, аналогичкно по пользователям, типам телефонов и еще неизвестно чему. И это все в одном дереве.

Двадцать раз уже говорилось, что в дерево хорошо укладываются только очень ограниченное множество задач, а остальные не укладываются вообще никак. Причем даже в хороших случаях все нужно знать заранее, в процессе работы поменять уже ничего нельзя. Поэтому не будут у Вас в узлах лежать данные по месяцам, поскольку отчеты по месяцам всплывут в самый разгар реализации проекта. Вы вообще почти никогда не будете знать заранее чего от системы захочет начальство и какие отчеты оно потребует выдавать пользователям в биллах, оно и само этого не знает.





Sergei Obrastsov

Sergei Obrastsov

ну конечно, не разработчики M изобрели B-дерево и вообще иерархические структуры. но они оценили и взяли их на вооружение еще тогда, в 70-х. как
видим, они оказались дальновидны. а ведь все очень просто, с большими
объемами данных первыми столкнулись именно они.

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

а сами объемы не нужно привести?

Приведите.

Sergei Obrastsov

(если честно, я притомился искать в инете конкретные цифры)

В таком случае воздержитесь от утверждений типа что КЕШ первый работал с такими объемами.

Sergei Obrastsov

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

А как же оно читается? По другому железо читать не умеет.

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, MSSQL) таблица с одним индексом и Cache-структура с 9-ю.

Хорошо, смотрю.

Sergei Obrastsov

я только ЗА. ссылки приведены.

Это теперь, после напоминания они приведены.

Sergei Obrastsov


Неправда, дефрагментация далеко не всегда дает прирост скорости, тем более на нормальных ФС. Пора бы уже избавиться от этих МС-ДОС-овских предрассудков. О дефрагментации ext2 я даже не слышал, по-видимому настолько сильно ускоряет работу ФС, что ее боятся использовать, как бы диск не разлетелся.

я бы рад избавиться, но пока приходится дефрагментировать. не часто и все же. про ext2 ничего не скажу, мне приходится работать под Windows

Неправда, Вы уже сказали: "дефрагментация всегда давала выигрыш в скорости, дает и сейчас, даже при наличии "супер-файловых" систем."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=293038&pg=4#2676944
По-моему лучше остерегаться подобных обобщений до появления соответствующего опыта с супер файловыми системами, хотя бы с NTFS.

Sergei Obrastsov

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

Не останавливайтесь на этом. Если поискать, то еще можно найти диски размером в 10 и даже 5 Gb.

Нужно ведь быть немного резонным. Никто же не спорит, что можно найти задачу, где преимущества КЕШ-а будут очевидными. Например поставить условия, что данные внутри сервера должны храниться в виде строк. Зачем - неизвестно, нужно и все. Но ведь это несерьезно, мы же обсуждаем СУБД общего назначения, которые работают на человеческом железе.

Sergei Obrastsov

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

Вы по-видимому просто не представляете себе что такое геометрическая поргрессия. Ей там неоткуда взяться, скорее всего Вы перепутали с арифметической прогрессией.

Пусть запись в некоторой таблице занимает N байт, а база L байт.
Добавили одну запись, получили (примерно) L+N байт,
добавили две записи - получили L+2*N байт,
сто записей - L+100*N байт
и т.д.
Это арифметическая прогрессия. Индекс растет еще медленнее. И где тут можно увидеть геометрическую прогрессию? Ткните пальцем, а то моей фантазии не хватает.

Хотя нет, понял. Недооценил оказывается свою фантазию. Вспомнил, что говорю с КЕШ-истом, так вот по КЕШ-овым революционным правилам действительно получается нечто очень похожее на геометрическую прогрессию:
L+N
(L+2)*N
...
(L+100)*N
...

И все бы хорошо, но вот только к реальному росту БД эта прогрессия никакого отношения не имеет.
20 май 06, 00:34    [2686866]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Чернышев Андрей Леонидович

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

Особенно к денормализации индексы имеют отношение. Еще бы в нормализованной схеме индексов не может быть никогда? Если канечно это реальный ЧАЛ, а не разводка на флейм.

Чернышев Андрей Леонидович

В "индексах" хранятся (еще раз) самые, что ни на есть, настоящие данные.

Не иначе - выдержавшие проверку временем. От того и такие настоящие.

Чернышев Андрей Леонидович

Это в бОльшей степени данные, чем так называемые метаданные (словари данных).

Совсем похоже на разводку.

Чернышев Андрей Леонидович

Если метаданные "хранятся" в РСУБД в отношениях (на логическом уровне), как и "основные" данные, и это считается важным и полезным, то почему же данные ("индексы") не "хранятся" тоже в отношениях ?

Ко всему что хранится в отношениях можно писать запросы на SQL (это ни какой-нибудь там МУМПС). А к якобы данным ("индексам") писать запросы ломает. Они лучше для другого подходят.

Чернышев Андрей Леонидович

Они хранятся почему-то в какой-то другой (если рассуждать с точки зрения модели данных) СУБД, к которой имеет доступ "оптимизатор запросов" так называемой РСУБД.

Забыли ЧАЛа спросить. Вот от того все и происходит.

Чернышев Андрей Леонидович

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

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

Чернышев Андрей Леонидович

И по скорости, и по "теории", и по "подвижности специалистов" MUMPS превосходит РСУБД.

Чтобы писать циклы вместо нормального запроса "подвижность специалиста", наверное, понадобится какая-то особенная. Да и "теория" для обоснования такого подхода тоже нужно придумать особенную. Не иначе.
20 май 06, 00:42    [2686873]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

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

P.S. Надеюсь от меня не потребуют учитывать еще и "ненужные" разделители? :)
А вот еще вопрос: чего Вы периодически всё про разделители упоминаете? Они как-то суются в данные? Просто странно как-то, я единственно когда про разделители думал - ну разве что при экспорте текстовых файлов

правильно думали, поскольку здесь сходная ситуация. в M нет фиксированного
задания полей для структур, поскольку и сами структуры тоже не заданы.
поэтому есть только один тип данного - строка. и есть возможность
указать в строке символы-разделители, чтобы получить "виртуальные" поля
данных.
строка данных:
а,b*,c:,d*,e
5 полей через разделитель ","
3 поля - через "*"
2 поля через ":"
если их нет, то их надо создать:
set ^dft(v5,"idx",idx)=tr_"*"_cat_"*"_pha_"*"_phb_"*"...
в результате данные выглядят так:
1*10*51123*76543*...*700*100*650*1
2*10*612341231123*4111323176543*...*700*101**
1*10*643423*676543*...****
берутся они функцией, которая для этого и сделана:
set f1=$piece(data,"*",1)
...
set f5=$piece(data,"*",5)
и пишутся ей же, то есть нет смысла пересобирать строку данных:
1*10*51123*76543*...*700*100*650*1

set $piece(data,"*",2)=13

1*13*51123*76543*...*700*100*650*1

это, конечно, не единственный вариант хранения данных в M. я часто встречаю
такой:
^table(idx,1)=field1
^table(idx,2)=field2
...
^table(idx,N)=fieldN
тоже, конечно, вариант. imho, не оптимальный.

про "проблему концевых разделителей" можно посмотреть здесь:
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=288398&pg=17#2655401

С уважением. Сергей
20 май 06, 01:54    [2686926]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
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, MSSQL) таблица с одним индексом и Cache-структура с 9-ю.

Посмотрел. Пока увидел, что сравнивался на самом деле не MySQL-MSSQL, а только MySQL. Каким образом сделан вывод, что "впрочем, MS SQL 15 млн. записей с индексацией по дате в 3.5 Gb тоже не запишет. :))" пока непонятно. МССКЛ мелькал только как рабочая база, сравнивать ее с тестовой не совсем корректно, тем более что имели место многочисленные неточности. Никто не может поручиться, что о рабочей базе не забыли упомянуть какую-нибудь деталь. К тому же неизвестно что случится, например, с размером файла данных КЕШ-а, если он поработает несколько месяцев, как МССКЛ. Крчать что ничего не случиться не нужно, нужно поставить базы в одинаковые условия и проверить.


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

эти вещи просьба мне в вину не ставить, SQL пакует числа, так
что нечего тут,

СКЛ числа не пакует.

Идем дальше.

На данных без индексов выигрыш КЕШ-а по объему аж 30% (1.970 гиг в МуСКЛ - 1.155 гиг в КЕШ-е). Обсуждать смешно.
С индексами - не понимаю кешового синтаксиса, хорошо бы пояснить. Также хорошо бы привести скрипт для создания индекса в МУСКЛ-е и параметры сервера, например сколько fillfactor, или как он там называется в МуСКЛ-е. Пока вижу что разница аж на те же 30-40%, игнорируя количество индексов. Тоже нечего обсуждать, это не разница. Что же касается разных индексов, то зачем об этом постоянно говорить, проще уберать лишние из кеша, либо добавить необходимые в МуСКЛ, тогда можно сравнить.

Так что пока ничего существенного. Можете поставить в заслугу КЕШ-у выигрыш в 50% по размеру файлов. По-видимому это выдающееся достижение, но из-за экономии места в пол-файла я, например, на КЕШ не перейду.




Еще приведите время создания индекса кешем и МуСКЛ-ем. Хоть это и не типичная операция, но интересно.

Что касается необходимости индекса, то в РСУБД действительно не всегда нужно индексировать все подряд. Например если в запросе участвует индексированное поле, которое выдаст небольшое количество записей (порядка 20 в случае обычного индекса), скажем фамилия, то остальные поля можно не индексировать, все равно прямой перебор по этому множеству будет быстрее. Кроме того существуют составные индексы, в некоторых случаях по подмножествам полей индекс заводить уже не обязательно. Так что то что в КЕШ-е делается девятью индексами, в РСУБД может быть сделано меньшим (или большим) числом индеков. Есил выложите типичные запросы, то можно пообсуждать необходимые индексы.
20 май 06, 02:05    [2686934]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

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

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

Ага, придумали новый отмазон. Да какая разница как они там данные организованы, мы же и не собираемся сравнивать способ организации данных, мы собираемся сравнивать производительность. Производительность тоже принципиально разная? Ее что нельзя измерить в секундах на запрос, а секунды что, разные для всех серверов?

это он поторопился.


А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель), а для выборки по району города они будут лежать в узлах по этим самым районам, аналогичкно по пользователям, типам телефонов и еще неизвестно чему. И это все в одном дереве.

Двадцать раз уже говорилось, что в дерево хорошо укладываются только очень ограниченное множество задач, а остальные не укладываются вообще никак. Причем даже в хороших случаях все нужно знать заранее, в процессе работы поменять уже ничего нельзя. Поэтому не будут у Вас в узлах лежать данные по месяцам, поскольку отчеты по месяцам всплывут в самый разгар реализации проекта. Вы вообще почти никогда не будете знать заранее чего от системы захочет начальство и какие отчеты оно потребует выдавать пользователям в биллах, оно и само этого не знает.

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


Sergei Obrastsov

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

Не останавливайтесь на этом. Если поискать, то еще можно найти диски размером в 10 и даже 5 Gb.

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


Нужно ведь быть немного резонным. Никто же не спорит, что можно найти задачу, где преимущества КЕШ-а будут очевидными. Например поставить условия, что данные внутри сервера должны храниться в виде строк. Зачем - неизвестно, нужно и все. Но ведь это несерьезно, мы же обсуждаем СУБД общего назначения, которые работают на человеческом железе.

а ведь мне лучше было бы работать на связке Clarion+SQL, чем на
Clarion+Cache, меньше возни с интерфейсом.
так что я не пытался засунуть "вшивый КЕШ" в очередную дырку, вопреки
всем правилам и традициям.


Sergei Obrastsov

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

Вы по-видимому просто не представляете себе что такое геометрическая поргрессия. Ей там неоткуда взяться, скорее всего Вы перепутали с арифметической прогрессией.

кол-во зарегистрированных сотовых телефонов в городе по годам:
2003  2004  2005-2006
0      1000   150000
как там будет выглядеть рост кол-ва звонков по ним?


Хотя нет, понял. Недооценил оказывается свою фантазию. Вспомнил, что говорю с КЕШ-истом, так вот по КЕШ-овым революционным правилам действительно получается нечто очень похожее на геометрическую прогрессию:
И все бы хорошо, но вот только к реальному росту БД эта прогрессия никакого отношения не имеет.

я понимаю, что хочется "погнуть пальцы и постучать копытами". но может
лучше это делать не здесь?
20 май 06, 02:45    [2686945]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

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

Посмотрел. Пока увидел, что сравнивался на самом деле не MySQL-MSSQL, а только MySQL. Каким образом сделан вывод, что "впрочем, MS SQL 15 млн. записей с индексацией по дате в 3.5 Gb тоже не запишет. :))" пока непонятно.

первая попытка была с MSSQL. данные за 2 месяца заняли именно такой объем.
это меня и напугало.


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

а я и не спорю. если есть во что ткнуть меня носом - я буду только рад.
как я уже сказал в предыдущем письме, связка Clarion+SQL для меня
предпочтительнее связки Clarion+Cache.


К тому же неизвестно что случится, например, с размером файла данных КЕШ-а, если он поработает несколько месяцев, как МССКЛ. Крчать что ничего не случиться не нужно, нужно поставить базы в одинаковые условия и проверить.

работает, посматриваю. пока все нормально.


Sergei Obrastsov

эти вещи просьба мне в вину не ставить, SQL пакует числа, так
что нечего тут,

СКЛ числа не пакует.

пакует. в 2 байта, в 4 байта... для меня это упаковка.


На данных без индексов выигрыш КЕШ-а по объему аж 30% (1.970 гиг в МуСКЛ - 1.155 гиг в КЕШ-е). Обсуждать смешно.

это не совсем так. я надеялся, что кто-нибудь захочет вникнуть и заметит
подвох. :) в M структура не существует без индексов, поэтому 1.155Gb
это уже с индексом по v5. но вот вчера мне показали, что "кластерный
индекс" занимает очень мало места и этот выигрыш просто пропадает.
ну, что тут скажешь, сегодня посмотрю.


С индексами - не понимаю кешового синтаксиса, хорошо бы пояснить. Также хорошо бы привести скрипт для создания индекса в МУСКЛ-е и параметры сервера, например сколько fillfactor, или как он там называется в МуСКЛ-е. Пока вижу что разница аж на те же 30-40%, игнорируя количество индексов. Тоже нечего обсуждать, это не разница. Что же касается разных индексов, то зачем об этом постоянно говорить, проще уберать лишние из кеша, либо добавить необходимые в МуСКЛ, тогда можно сравнить.

индексы и есть индексы. насчет fillfactor посмотрю. 30-40% это действительно
не разница. я бы убрал лишние, если бы они не были нужны. как было сказано
ранее, время обработки данных критично. а добавить необходимые в MySQL
не могу, размер скачет. сегодня попробую кластерный по дате-время, может
это облегчит жизнь.


Так что пока ничего существенного. Можете поставить в заслугу КЕШ-у выигрыш в 50% по размеру файлов. По-видимому это выдающееся достижение, но из-за экономии места в пол-файла я, например, на КЕШ не перейду.

а никто никого и не зовет. 50% на 100Gb - существенная разница.


Еще приведите время создания индекса кешем и МуСКЛ-ем. Хоть это и не типичная операция, но интересно.

MySQL быстрее, что, впрочем, не удивительно. там ведь был только один индекс, а не 9 как в Cache. и импорт быстрее на порядок, Cache плохо
работает с последовательными файлами.


Что касается необходимости индекса, то в РСУБД действительно не всегда нужно индексировать все подряд. Например если в запросе участвует индексированное поле, которое выдаст небольшое количество записей (порядка 20 в случае обычного индекса), скажем фамилия, то остальные поля можно не индексировать, все равно прямой перебор по этому множеству будет быстрее. Кроме того существуют составные индексы, в некоторых случаях по подмножествам полей индекс заводить уже не обязательно. Так что то что в КЕШ-е делается девятью индексами, в РСУБД может быть сделано меньшим (или большим) числом индеков. Есил выложите типичные запросы, то можно пообсуждать необходимые индексы.

буду только рад. итак для таблицы:
v1 - tinyint
v2 - int(3)
v3 - varchar(16)
v4 - varchar(16)
v5 - data
v6 - time
v7 - int(6)
v8 - int(8)
v9 - int(2)
v10 - int(2)
v11 - tinyint
v12 - tinyint
v13 - int(4)
v14 - int(4)
v15 - tinyint
v16 - int(4)
v17 - int(4)
v18 - int(4)
v19 - int(4)

необходимы выборки по полям:
v1 - заданное значение
v2 - заданное значение
v3 - префиксный выбор из заданного списка
v4 - префиксный выбор из заданного списка
v5 - диапазон
v6 - диапазон
v7 - диапазон, значение
v8 - диапазон, значение
v9-v12 - значение
v13 - заданный список
v14 - заданный список
v16-v17 - заданный список
v18-v19 - заданный список
как я уже упоминал, время обработки данных - серьезный критерий.
минимальный объем данных ~80 млн. записей, максимальный - ~300.

"префиксный выбор..." это когда задан список в виде:

413
22522
4412
8787890201

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

размер запросов не лимитирован, т.е. могут быть заданы все условия одновременно.
20 май 06, 03:24    [2686954]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
Joker_Ya

Я уже говорил в одном из постов что не надо зацикливаться на М системах. Почитайте книги по базовым алгоритмам (работа с деревьями, построение компиляторов, сортировки, поиск и т.д.) и вам многое станет ясно в том как работает любая система изнутри. Тогда я думаю вы будете более скептически относиться к заявлениям маркетологов о выигрыше в скорости в десятки раз.

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


Я понимаю когда человек глазам верит (хотя иногда бывает обман зрения), Но чтоб он рукам верил это уже что-то интересное. Ну да ладно это ваши личные проблемы. Вот вам задача конкретная давайте на ней тестировать

Есть таблица с 500 млн. записей (дата_время разговора, продолжительность (сек.) и еще десяток полей. Мы будем работать только с этими) Необходимо получить следующие данные

Дата (день) Кол-во разговоров Общая продолжительность (час.) Средняя родолжительность (час.)

т е простейшая статистика по разговорам.
1. Пррверяем скорость мат операций с целыми числами (получение кол-ва разговоров простейший инкримент),
2. проверяем скорость вычислений с плавающей точкой (получение продолжительности в часах, необходимо делить на 3600 секунды),
3. проверяем способность к групповым операциям (получение средней продолжительности разговора по дню),
4. проверяем умение системы работать с большими объемами данных (у меня в рабочей базе объем таблицы порядка 65 Гб с индексами)
5. для проверки избирательности запросов выбираем данные за 1 месяц (обрабатывается порядка 35-40 млн. записей из 500 млн.)
Время выполнения на Oracle 10.1.0.5 составил вместе с выборкой данных 224 с.
Данный запрос выплнился на рабочей базе со 100 подключенными пользователями из них активно работают примерно 20-40. Примерно такие запросы только с большим кол-вом условий выполняются постояно. Причем на данных за 3 года. (каждый год таблица порядка 500 млн записей и размером 50-70 Гб.)
Вот вам реальный пример. В начале месяца нагрузка увеличивается раза в 2 так как необходимо выдать немеренное кол- отчетности в том числе и аналитической. И все работает никто особо не жалуется. Одновременно выпоолняются сложные отчеты, заливаются новые данные (в день более 1 млн. записе), расчитывается стоимость разговора и т д. В 2001 году перешли на Оракл потому что система на М просто не справлялась. Жду от вас результатов тестирования на подобном обеме. Тесты на таблице из 100 записей не состоятельны для серьезных систем. Видимо поэтому ни одна из М систем не представлена независимых тестах TCP.[/quot]


Пожалуйста, если есть возможность провести тест - искуственно увеличь рамеры файлов базы данных (раза в два) и через неделю, попробуй провести анналогичный тест. Посмотри изменится ли производительность ? А после теста уменьш файлы азы до минимально возможного значения и повтори тест.
Сообщи нам результаты!
20 май 06, 09:52    [2687019]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
c127
А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель)


Что ж вы так горячитесь? Не помещайте данные по месяцам в узлы - поместите их в узлы по дате.. все вопросы с неделями снимутся... как и, впрочем, с часами и минутами.. $h - хранит и дату и время одновременно.

Что касается других выборок - постройте для них подходящие индексы.

И не думайте, пожалуйста, что лично вас кто то пытается обмануть
20 май 06, 13:40    [2687245]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

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


Если очень хочется сравнить самостоятельно - сравнивайте...

А можете и просто посмотреть :
"Начисление всем абонентам повременка 1 286 093 109 (записей) 12 часов 25 мин
Справка по доходам 1 час 13 мин
Сортировка всех абонентов по адресам для печати квитанций 2 часа 50 мин 43 сек"

Вот здесь это находится http://www.asr.orel.ru/news/tenmillion.htm
20 май 06, 14:46    [2687306]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

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

А можете и просто посмотреть :
"Начисление всем абонентам повременка 1 286 093 109 (записей) 12 часов 25 мин
Справка по доходам 1 час 13 мин
Сортировка всех абонентов по адресам для печати квитанций 2 часа 50 мин 43 сек"

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

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

Откуда:
Сообщений: 61
Но ведь там ещё "3000 процессов с выполнением фонового задания формирования отчетных данных." .. хотя, может и не очень быстро.. судить не берусь.. для других систем тесты такого объёма ведь не проводились.. на 10 миллионов абонентов - в России это единственная сертифицированная система
20 май 06, 16:02    [2687389]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Dimonana
Guest
Отцы, да НАПЛЕВАТЬ сколько база занимает

https://www-132.ibm.com/webapp/wcs/stores/servlet/ConfiguratorDisplay?storeId=1&catalogId=-840&langId=-1&site_type=public&oiId=null¤cy=USD&base=17002RD&x=8&y=13

Следующий конфиг:

IBM Total Storage DS400 - Dual Controller

1. 146GB X 14 штук
(Gen 3) Hot-Swap 3.5" 15K RPM Ultra 320 SCSI HDD ( $649.00 )

2. IBM SMB 2-Gbps Fibre Channel HBA ( $549.00 ) X 4 штуки

3. IBM TotalStorage Storage Switch Model L10 (Loop Switch) ( $1,845.00 ) X 1 штука - на всякий случай :)

4. 1GB PC2700 ECC DDR SDRAM DRAM ( $619.00 ) X 2 штуки

5. Кабель IBM 5m LC-LC Fibre Channel Cable ( $129.00 ) X 4 штуки

6. 3000XHV Uninterruptible Power Supplies ( $1,439.20 ) X 1 штука

Итого:

Объем 2 ТБ (можно в максимуме расширить до 12 ТБ)

Цена $28,310.20

Производительность 2% присутствующих могут представить

Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО
21 май 06, 00:51    [2688220]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
yww@escape.ru
на 10 миллионов абонентов - в России это единственная сертифицированная система

Гыыыы...
"на 10 миллионов абонентов" - это что значит?
Сколько абонентов прямо или косвенно пользуется этой системой в действительности? 10000000 телефонных абонентов в Орле? Та хде вы их там нашли, в Орле людей в двадцать раз меньше, при этом половина в своей жизни телефона не видала.

Или речь идет о максимальном (предельном) размере справочника абонентов? Типа с (максимум) десятимиллионным справочником каша способна работать, и её на это сертифицировали, а с пятнадцатимиллионным справочником - уже ой, не сертифицировали?

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

Писец рекламные клоуны нах.
21 май 06, 00:54    [2688226]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Dimonana
Отцы, да НАПЛЕВАТЬ сколько база занимает

Гыыы... Очередной тупой му**к.
Больше места занимает база - больше время на чтение нужных данных - меньше скорость выполнения запросов.
В случае фуллскана, разумеется. В случае не фуллскана - надо более другие вещи смотреть, но завязанные опять таки на объем этих самых более других вещей.

Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО

Вывод - иногда лучше жевать, чем говорить. Если после "жевать" возникло желание "говорить" - предварительно почитать учебники.
21 май 06, 00:59    [2688230]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Dimonana

Отцы, да НАПЛЕВАТЬ сколько база занимает

Не скажите. Например, если одна и та же табла с одной и той же инфой занимает разный объем на диске, то на той которая меньше меньше болков считывать надо. А это имеет значение для скорости выполнения запросов в общем случае.
21 май 06, 01:02    [2688239]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Dimonana
Guest
Пьяный Лох
Dimonana
Отцы, да НАПЛЕВАТЬ сколько база занимает

Гыыы... Очередной тупой му**к.
Больше места занимает база - больше время на чтение нужных данных - меньше скорость выполнения запросов.
В случае фуллскана, разумеется. В случае не фуллскана - надо более другие вещи смотреть, но завязанные опять таки на объем этих самых более других вещей.

Вывод НЕ НАДО БОЛЬШЕ О РАЗМЕРАХ. СМЕШНО

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


Нда, ну от ника странно ожидать чего-то другого.

Специально для пьяных и тупых лохов попытаюсь разжевать:

Разница даже в 2 раза несущественно при нынешнмх производительных и дешевых системах.
21 май 06, 01:10    [2688248]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
Dimonana
Специально для пьяных и тупых лохов попытаюсь разжевать:

Разница даже в 2 раза несущественно при нынешнмх производительных и дешевых системах.

[удалено модератором]
21 май 06, 01:15    [2688250]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@mail.ru
Guest
Пьяный Лох
yww@escape.ru
на 10 миллионов абонентов - в России это единственная сертифицированная система

Гыыыы...
Писец рекламные клоуны нах.


Никакой рекламы.. Боже упаси меня от такого занятия.
Уточните, пожалуйста, про клоунов. К кому возглас то направлен?

По ссылке было показано то, что "АСР ОРЕЛ-М получила Сертификат соответствия № ОС/1-СТ-76 как универсальная тиражируемая автоматизированная система расчётов высшего уровня" и "В ноябре 2002г прошли испытания системы в рамках инспекционного контроля на базе, смоделированной на платформе Cache'и предназначенной для обслуживания сети емкостью 10 000 000 и более абонентов".

Эта ссылка предложена в качестве альтернативы самостоятельным проверкам производительности Каше.

В Орле действительно нет 10 миллионов абонентов.. их нет ни в одном городе России.. только речь то идёт о других цифрах. Был вопрос - справится ли Каше с 50 миллионами записей? Вот в Орле есть ответ (для 1 286 093 109). Если есть желание, проверьте это лично.
21 май 06, 10:51    [2688409]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 yww@mail.ru
Никакой рекламы.. Боже упаси меня от такого занятия.
Уточните, пожалуйста, про клоунов. К кому возглас то направлен?

Большей частью оно было в сторону авторов штатьи, на которую Вы ссылку привели. Может они и не совсем рекламные, но смеяццо можно над многими кусками штатьи.
К Вам по прежнему вопрос - что значит "сертифицирована на 10 миллионов абонентов"? На 500 тысяч - не сертифицирована? Или на 15 миллионов?
Что вообще означает термин "сертификация на определенное количество абонентов"?

По ссылке было ... предназначенной для обслуживания сети емкостью 10 000 000 и более абонентов"

Т.е. на 10000000 - предназначена, на более - предназначена. А на менее, чем 10 миллионов? Если да, то это фраза из серии "до 16 и старше". Что-то сказали, цифру красивую засветили, информации ноль.

Эта ссылка предложена в качестве альтернативы самостоятельным проверкам производительности Каше.

Нет уж, лучше самостоятельно, чем по такой штатье.
21 май 06, 17:48    [2688868]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Пьяный Лох
Что вообще означает термин "сертификация на определенное количество абонентов"?

Я, пожалуй, соглашусь, что рекламная составляющая в той статье есть.

Как именно проводится сертификация биллинговых систем я не знаю, но о самом термине, у меня следующее представление:
Сертификация - процесс проведения испытаний, с целью определения соответствия действительных показателей заявленным. Это относится не только к программым продуктам, но и ко всем продуктам вообще (минералка, в общем то, тоже должна соответствовать тому, что написано на этикетке).

Организация, выдавшая сертификат, должна иметь некоторый "законный авторитет" в той области, для которой проводит испытания.. Для связистов это Ленинградский институт связи. То есть, если сертификация проведена, значит есть подтверждение качеств продукта.

Смысл 10 миллионов абонентов можно (при желании) увидеть в таком примере:
- для 10 миллионов абонентов можно вычислить ожидаемое количество разговоров в сутки (у связистов есть методики)
- биллинговая система должна успевать провести расчет стоимости (или хотя бы выгрузку данных со станции) суточного массива за время менее 24 часов. Если она не успевает это сделать, то значит не пригодна для обслуживания биллинга 10 миллионов абонентов.

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

Так вот, если она сертифицирована на 10 млн, то на 1 млн - скорее всего, тоже. А на 15 млн - нет.
21 май 06, 18:44    [2688914]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
guest_20040621
Guest
> DS400

2 Тб (и 12 Тб) можно найти по гораздо более привлекательной цене при сопоставимой производительности, надежности и масштабируемости.

Dimonana, Вы напрасно в этом треде упомянули СХД. ;) Здесь кодеры (язык не поворачивается назвать их разработчиками) заняты любимым делом: сравнением длины пиписек. О популярности этого занятия Вы можете судить по длине обсуждения. ;)) О глубине - по фразе "Больше места занимает база - больше время на чтение нужных данных - меньше скорость выполнения запросов". ;))
21 май 06, 18:50    [2688919]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Пьяный Лох
Member

Откуда:
Сообщений: 3652
2 yww@escape.ru
Так вот, если она сертифицирована на 10 млн, то на 1 млн - скорее всего, тоже. А на 15 млн - нет.

Так вот, откуда Вы взяли факт сертификации на 10 млн.?
В штатье по ссылке есть следующие факты:
- система как-то кем-то сертифицирована "для обслуживания сети электросвязи ёмкостью до 500 000 номеров"
- система еще как-то кем-то сертифицирована, но без указания кол-ва абонентов
- система тестировалась для "обслуживания сети емкостью 10 000 000 и более абонентов". Как я уже указывал, сказать "10000000 и более" - это значит не сказать ничего, тока циферки красивые засветить.

Я уж не говорю о том, что тестирование само по себе не много значит, если оно стоит в одном абзаце с государственной сертификацией.
Ну тестировали чего-то там в Орле, ну получили какой-то результат. Например тот результат, что список абонентов сортировался по адресам в течение почти трех (!) часов. Это, пардон, пузырьковой сортировкой надо было сортировать.. на 286-ом компе..
21 май 06, 19:40    [2688992]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

Откуда:
Сообщений: 61
Пьяный Лох
2 yww@escape.ru
Так вот, если она сертифицирована на 10 млн, то на 1 млн - скорее всего, тоже. А на 15 млн - нет.

Так вот, откуда Вы взяли факт сертификации на 10 млн.?
В штатье по ссылке есть следующие факты:
- система как-то кем-то сертифицирована "для обслуживания сети электросвязи ёмкостью до 500 000 номеров"
- система еще как-то кем-то сертифицирована, но без указания кол-ва абонентов
- система тестировалась для "обслуживания сети емкостью 10 000 000 и более абонентов". Как я уже указывал, сказать "10000000 и более" - это значит не сказать ничего, тока циферки красивые засветить.

Я уж не говорю о том, что тестирование само по себе не много значит, если оно стоит в одном абзаце с государственной сертификацией.
Ну тестировали чего-то там в Орле, ну получили какой-то результат. Например тот результат, что список абонентов сортировался по адресам в течение почти трех (!) часов. Это, пардон, пузырьковой сортировкой надо было сортировать.. на 286-ом компе..


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