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

Откуда: Харьков
Сообщений: 140
автор
"количественный" вывод:
время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.


что то Вы темните
почем Вы там говорите индексы создавали
сдается что имели место некоторые предрасчеты при добавлении записей

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

Откуда: Магадан
Сообщений: 584
pgres
автор
"количественный" вывод:
время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.


что то Вы темните
почем Вы там говорите индексы создавали
сдается что имели место некоторые предрасчеты при добавлении записей

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

С уважением. Сергей
22 май 06, 17:47    [2692761]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
заинтриговал сам вывод, противоречащий законам физики
> время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

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

Откуда: Магадан
Сообщений: 584
pgres
заинтриговал сам вывод, противоречащий законам физики
> время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

прокомментируйте плз

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

а вот "размер данного" - это да, система дольше читает.

С уважением. Сергей
22 май 06, 17:57    [2692818]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
Sergei Obrastsov
pgres
так что давайте кашисты не изворачивайтесь а делайте придложенный тест

хорошо, привожу результаты тестирования.
в связи с тем, что заказчик теста не указал размер записи, тестировались 2
структуры:
a)
^table(date,idx)=$random(1000)

b)
^table(date,idx)=$random(1000)*$random(86400)
где date - "дата звонка" в 5-значном "внутреннем" формате, idx - 1-1300000,
$random(1000) - "продолжительность звонка" в секундах и $random(86400) -"время звонка" во внутреннем 5-значном формате.
с учетом пожеланий заказчика было выбрано такое кол-во записей на сутки,
чтобы за 31 день получить выборку в 40 млн. записей.

размер БД - 261.3 млн. записей/узлов (3.7Gb), больше не позволяет FAT32.
спешу заверить и заказчика, и оппонентов, что тестирование доказало
независимость скорости выборки и обработки данных от количества записей
в БД.

оборудование и софт: AMD 2500+ (1.8Ghz)/1Gb, IDE HDD 120Gb 7200,
Windows 2k Professional SP3, Cache 5.0.11

приоритеты задач и "разгрузка" компьютера: нет.
тестирование проходило при обычной загрузке: IE, winamp и прочая
лабуда вроде AVP, Far и ICQ.

методика тестирования: выбирались данные за 31 день (40.3 млн. записей),
начальная дата выбиралась случайным образом, выборка проводилась 100 раз.
вычислялись следующие значения:
1. число выбранных записей
2. сумма "продолжительности звонков" в часах за сутки
3. средняя "продолжительность звонка" за сутки
4. время, затраченное на обработку суточной выборки
5. время, затраченное на весь тест

результаты тестирования по структурам:
a) 87-90 секунд, независимо от даты начала выборки.
b) 126-129 секунд, независимо от даты начала выборки.

"количественный" вывод:
время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

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

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


Вот хоть что-то конкретное. Тест конечно не совсем корректный т.к. структура данных совсем упрощена вследствии чего объем данных совсем маленький. 3.7 Gb это не серьезно (Кстати очеь большой объем для 2 то полей)
Вот примерная структура таблицы на которой я тестировал
CREATE TABLE "TTALKS"
( "PHONE_NUMBER" VARCHAR2(15),
"PHONE_CALL" VARCHAR2(15),
"DATE_CONNECT" DATE,
"MNEMONIC_IN" VARCHAR2(3),
"MNEMONIC_OUT" VARCHAR2(3),
"OVERTIME" CHAR(1),
"LENTALK" NUMBER(6),
"FILIAL_ID" NUMBER(3),
"SCHEMA" VARCHAR2(9),
"ID" NUMBER(10),
"ID_CALL" NUMBER(10),
"TYPE_CONNECT" CHAR(1),
"LENTALK_MINUTES" NUMBER(4),
"LENTALK_ACCRUAL" NUMBER(4),
"TARIFF" NUMBER(10, 2),
"TARIFF_ID" NUMBER(4),
"SUMTALK" NUMBER(20, 5),
"NDS_SUMTALK" NUMBER(20, 5),
"DATE_OF_COUNT" DATE,
"REASON_OTSEV" NUMBER(2),
"SERVICE" VARCHAR2(4),
"AOP_ID" NUMBER(3),
"AOP_ID_CALL" NUMBER(3),
"ID_PAY" NUMBER(10),
"PHONE_FULL_A" VARCHAR2(15)
)
Если считать что все записи строки то примерно 217 байт на запись (поля типа дата\время я посчитал по 20 байт) что составляет в вашем случае 217*261300000 = 56702100000 байт = 53 Гб.
Это без индексов. А индексы нужны практически по всем полям (кроме тех что хранят количественные показатели). Даже на таком сильно урезаном тесте в однопользовательском варианте (у меня на сервере еще более сотни человек работало выполняло запросы и вставку данных) производительность у вас всего примерно в 2 раза выше. Где декларируемая в Каше производительность в 5 раз выше чем у реляционных БД? Если добавить в тест условие что необходимо обеспечить выборки данных с условиями по многим полям то результат я думаю будет еще хуже.
Мне для выборки всех данных потребовалось написать 1 запрос (привожу ниже). Если не секрет поделитесь своим кодом.

select to_char(t.date_connect, 'mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from ttalks t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by to_char(t.date_connect, 'mm.yyyy')

Результат выполнения запроса 1 строка с данными за 1 месяц (что-то типа такого):

03.2005 41714548 1636542.161 2.353915705

Время выполнения - 94,7 с. Вы видимо сделали группировку за месяц.
В первый раз я имел ввиду запрос с группировками по дням

select to_char(t.date_connect, 'dd.mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from ttalks t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by to_char(t.date_connect, 'dd.mm.yyyy')

В результате возвращается выборка из 31 записа с результатами на каждый день. Что-то типа этого:
01.03.0005 1460834 57702.9437222222 2.37550710512518
02.03.0005 1662122 65709.9997222222 2.37272681051328
......
22.03.0005 1373366 51959.0136666666 2.27656501779704
........

Я тут немного поэксперементировал и получил время работы запроса 105 с.
Чтоб не говорили что увидев ваш результат я быстро подделал свой привожу пример того запроса который работает примерно 200 - 230 с.

select to_date(t.date_connect, 'dd.mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from ttalks t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by to_date(t.date_connect, 'dd.mm.yyyy')

Так что при условии оптимизации запросов я получил результат не хуже вашего на гораздо больших объемах и большей нагрузке на систему. Отсюда можно сделать вывод что никакого существенного выигрыша (в 5 раз как заявляют представители interSystems например) М системы по сравнению с РСУБД не дают (по крайней мере в данном тесте).
23 май 06, 03:48    [2693681]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
Joker_Ya
Вот хоть что-то конкретное. Тест конечно не совсем корректный т.к. структура данных совсем упрощена вследствии чего объем данных совсем маленький. 3.7 Gb это не серьезно

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


(Кстати очеь большой объем для 2 то полей)

не стоит забывать, что это таблица + индекс по дате


Где декларируемая в Каше производительность в 5 раз выше чем у реляционных БД? Если добавить в тест условие что необходимо обеспечить выборки данных с условиями по многим полям то результат я думаю будет еще хуже.

я бы сказал, что измерение производительности СУБД на последовательном
переборе данных не есть правильное тестирование.


Мне для выборки всех данных потребовалось написать 1 запрос (привожу ниже). Если не секрет поделитесь своим кодом.

пожалуйста, если Вам это что-нибудь даст. как видите, общего - 0.
 s t=$p($h,",",2)
 s d1=$zdh("11/04/2005",4)
 s d=d1-1 f  s d=$o(^table(d)) q:d=""!(d>(d1+30))  d  ;
 . s cnt=0,len=0,t2=$p($h,",",2)
 . i $d(^(d,0))
 . s idx="" f  s idx=$o(^(idx)) q:idx=""  s a=^(idx),len=len+a,cnt=cnt+1
 . w !,$tr($zd(d,4),"/",".")," ",cnt," ",len/3600," ",len/cnt/60," = ",$p($h,",",2)-t2
 w !,$p($h,",",2)-t


select to_char(t.date_connect, 'mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
^^^^^^^^^^^^^

а вот такие вещи надо уточнять. я, как умная Маша, высчитываю
продолжительность в часах по КАЖДОЙ записи.
так что я, конечно, пересчитаю по-Вашему, а Вам советую сделать
по-моему и сравнить, ага. :)


Время выполнения - 94,7 с. Вы видимо сделали группировку за месяц.
В первый раз я имел ввиду запрос с группировками по дням

нет, я делал по дням.


В результате возвращается выборка из 31 записа с результатами на каждый день. Что-то типа этого:
01.03.0005 1460834 57702.9437222222 2.37550710512518
02.03.0005 1662122 65709.9997222222 2.37272681051328
......
22.03.0005 1373366 51959.0136666666 2.27656501779704
........

пожалуйста
11.04.2005 1300000 180413.7811111111111 8.326789897435897437 = 2
12.04.2005 1300000 180278.2861111111111 8.320536282051282052 = 2
13.04.2005 1300000 180449.9947222222222 8.328461294871794872 = 2
14.04.2005 1300000 180339.4480555555556 8.323359141025641025 = 2
...
08.05.2005 1300000 180375.9941666666667 8.325045884615384615 = 1
09.05.2005 1300000 180382.6883333333333 8.325354846153846153 = 2
10.05.2005 1300000 180405.1225 8.32639026923076923 = 2
11.05.2005 1300000 180471.1494444444444 8.329437666666666667 = 2
61


Я тут немного поэксперементировал и получил время работы запроса 105 с.

убрав вычисление часов по КАЖДОЙ записи, я тоже оптимизировал выборку - 60-62 с.


Так что при условии оптимизации запросов я получил результат не хуже вашего на гораздо больших объемах и большей нагрузке на систему. Отсюда можно сделать вывод что никакого существенного выигрыша (в 5 раз как заявляют представители interSystems например) М системы по сравнению с РСУБД не дают (по крайней мере в данном тесте).

отсюда можно сделать только один правильный вывод: сравнивать можно
только в одинаковых производственных условиях и на одинаковом оборудовании. и не только на последовательном переборе.
23 май 06, 08:26    [2693832]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Iura
Member

Откуда:
Сообщений: 138
Joker_Ya
Sergei Obrastsov
pgres
так что давайте кашисты не изворачивайтесь а делайте придложенный тест

хорошо, привожу результаты тестирования.
в связи с тем, что заказчик теста не указал размер записи, тестировались 2
структуры:
a)
^table(date,idx)=$random(1000)

b)
^table(date,idx)=$random(1000)*$random(86400)
где date - "дата звонка" в 5-значном "внутреннем" формате, idx - 1-1300000,
$random(1000) - "продолжительность звонка" в секундах и $random(86400) -"время звонка" во внутреннем 5-значном формате.
с учетом пожеланий заказчика было выбрано такое кол-во записей на сутки,
чтобы за 31 день получить выборку в 40 млн. записей.

размер БД - 261.3 млн. записей/узлов (3.7Gb), больше не позволяет FAT32.
спешу заверить и заказчика, и оппонентов, что тестирование доказало
независимость скорости выборки и обработки данных от количества записей
в БД.

оборудование и софт: AMD 2500+ (1.8Ghz)/1Gb, IDE HDD 120Gb 7200,
Windows 2k Professional SP3, Cache 5.0.11

приоритеты задач и "разгрузка" компьютера: нет.
тестирование проходило при обычной загрузке: IE, winamp и прочая
лабуда вроде AVP, Far и ICQ.

методика тестирования: выбирались данные за 31 день (40.3 млн. записей),
начальная дата выбиралась случайным образом, выборка проводилась 100 раз.
вычислялись следующие значения:
1. число выбранных записей
2. сумма "продолжительности звонков" в часах за сутки
3. средняя "продолжительность звонка" за сутки
4. время, затраченное на обработку суточной выборки
5. время, затраченное на весь тест

результаты тестирования по структурам:
a) 87-90 секунд, независимо от даты начала выборки.
b) 126-129 секунд, независимо от даты начала выборки.

"количественный" вывод:
время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

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

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


Вот хоть что-то конкретное. Тест конечно не совсем корректный т.к. структура данных совсем упрощена вследствии чего объем данных совсем маленький. 3.7 Gb это не серьезно (Кстати очеь большой объем для 2 то полей)
Вот примерная структура таблицы на которой я тестировал
CREATE TABLE "TTALKS"
( "PHONE_NUMBER" VARCHAR2(15),
"PHONE_CALL" VARCHAR2(15),
"DATE_CONNECT" DATE,
"MNEMONIC_IN" VARCHAR2(3),
"MNEMONIC_OUT" VARCHAR2(3),
"OVERTIME" CHAR(1),
"LENTALK" NUMBER(6),
"FILIAL_ID" NUMBER(3),
"SCHEMA" VARCHAR2(9),
"ID" NUMBER(10),
"ID_CALL" NUMBER(10),
"TYPE_CONNECT" CHAR(1),
"LENTALK_MINUTES" NUMBER(4),
"LENTALK_ACCRUAL" NUMBER(4),
"TARIFF" NUMBER(10, 2),
"TARIFF_ID" NUMBER(4),
"SUMTALK" NUMBER(20, 5),
"NDS_SUMTALK" NUMBER(20, 5),
"DATE_OF_COUNT" DATE,
"REASON_OTSEV" NUMBER(2),
"SERVICE" VARCHAR2(4),
"AOP_ID" NUMBER(3),
"AOP_ID_CALL" NUMBER(3),
"ID_PAY" NUMBER(10),
"PHONE_FULL_A" VARCHAR2(15)
)
Если считать что все записи строки то примерно 217 байт на запись (поля типа дата\время я посчитал по 20 байт) что составляет в вашем случае 217*261300000 = 56702100000 байт = 53 Гб.
Это без индексов. А индексы нужны практически по всем полям (кроме тех что хранят количественные показатели). Даже на таком сильно урезаном тесте в однопользовательском варианте (у меня на сервере еще более сотни человек работало выполняло запросы и вставку данных) производительность у вас всего примерно в 2 раза выше. Где декларируемая в Каше производительность в 5 раз выше чем у реляционных БД? Если добавить в тест условие что необходимо обеспечить выборки данных с условиями по многим полям то результат я думаю будет еще хуже.
Мне для выборки всех данных потребовалось написать 1 запрос (привожу ниже). Если не секрет поделитесь своим кодом.

select to_char(t.date_connect, 'mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from ttalks t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by to_char(t.date_connect, 'mm.yyyy')

Результат выполнения запроса 1 строка с данными за 1 месяц (что-то типа такого):

03.2005 41714548 1636542.161 2.353915705

Время выполнения - 94,7 с. Вы видимо сделали группировку за месяц.
В первый раз я имел ввиду запрос с группировками по дням

select to_char(t.date_connect, 'dd.mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from ttalks t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by to_char(t.date_connect, 'dd.mm.yyyy')

В результате возвращается выборка из 31 записа с результатами на каждый день. Что-то типа этого:
01.03.0005 1460834 57702.9437222222 2.37550710512518
02.03.0005 1662122 65709.9997222222 2.37272681051328
......
22.03.0005 1373366 51959.0136666666 2.27656501779704
........

Я тут немного поэксперементировал и получил время работы запроса 105 с.
Чтоб не говорили что увидев ваш результат я быстро подделал свой привожу пример того запроса который работает примерно 200 - 230 с.

select to_date(t.date_connect, 'dd.mm.yyyy') as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from ttalks t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by to_date(t.date_connect, 'dd.mm.yyyy')

Так что при условии оптимизации запросов я получил результат не хуже вашего на гораздо больших объемах и большей нагрузке на систему. Отсюда можно сделать вывод что никакого существенного выигрыша (в 5 раз как заявляют представители interSystems например) М системы по сравнению с РСУБД не дают (по крайней мере в данном тесте).


Переведи поля даты к типу datetime bповтори запрос. Я уверен что у тебя и база будет меньше занимать места и выигрыш в скорости запроса будет больше
23 май 06, 08:34    [2693847]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
Iura

Переведи поля даты к типу datetime bповтори запрос. Я уверен что у тебя и база будет меньше занимать места и выигрыш в скорости запроса будет больше


select trunc(t.date_connect) as "Дата",
count(1) as "Кол-во записей",
sum(t.lentalk) / 3600 as "Продолжительность разговора",
avg(t.lentalk) / 60 as "Ср. время разговора в минутах"
from talks.ttalks_local_2005 t
where t.date_connect between to_date('01.3.2005', 'dd.mm.yyyy') and
to_date('31.03.2005 23:59:59', 'dd.mm.yyyy hh24:mi:ss')
group by trunc(t.date_connect)

при таком запросе стало 85 с.
Я думаю если еще подумать то можно и до 60 с довести. Просто лень если честно. Если создать таблицу аналогичную той что использовал Sergei Obrastsov с 2 полями то время будет значительно менише 60 с. т.к. её объем будет меньше раз в 10 как минимум. Причет я использую запросы которые выполняет ядро базы. А он использует интерпритатор который гоняет цикл, что не сильно быстро как мы увидили. И все зяаявления Кашистов о беспрецедентной скорости работы рассыпались в прах. Я уж молчу о том как не удобно работать с их системой. Надо постояно продумывать структуру под запросы иначе только полный просмотр. А продумать все запросы которые понадобятся пользователям невозможно. Мне же достаточно добавить индекс и впринципе все работает. Пусть даже чуть чуть медленнее (превосходства в 5 раз никто не заметил).
23 май 06, 09:14    [2693911]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
LittleCat
Member

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

хорошо, привожу результаты тестирования.
.....

оборудование и софт: AMD 2500+ (1.8Ghz)/1Gb, IDE HDD 120Gb 7200,
Windows 2k Professional SP3, Cache 5.0.11

приоритеты задач и "разгрузка" компьютера: нет.
тестирование проходило при обычной загрузке: IE, winamp и прочая
лабуда вроде AVP, Far и ICQ.
.....


Вот хоть что-то конкретное. Даже на таком сильно урезаном тесте в однопользовательском варианте (у меня на сервере еще более сотни человек работало выполняло запросы и вставку данных) производительность у вас всего примерно в 2 раза выше. Где декларируемая в Каше производительность в 5 раз выше чем у реляционных БД?
....
Отсюда можно сделать вывод что никакого существенного выигрыша (в 5 раз как заявляют представители interSystems например) М системы по сравнению с РСУБД не дают (по крайней мере в данном тесте).

Не могли бы Вы привести конфигурацию оборудования, на котором производилось тестирование ? В примере, который привел Сергей, она присутствует. Мне кажется, выводы можно начать делать, когда мы ее сравним с Вашей. А пока они преждевременны :-)
23 май 06, 10:07    [2694087]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Sergei Obrastsov
pgres
заинтриговал сам вывод, противоречащий законам физики
> время, затраченное на выборку данных не зависит от количества
записей в БД, а зависит от размера данного/записи.

прокомментируйте плз

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

а вот "размер данного" - это да, система дольше читает.

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


я не совсем правильно понял
думал что время вычисления за день не зависит от количества записей за день
23 май 06, 10:17    [2694137]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
LittleCat

Не могли бы Вы привести конфигурацию оборудования, на котором производилось тестирование ? В примере, который привел Сергей, она присутствует. Мне кажется, выводы можно начать делать, когда мы ее сравним с Вашей. А пока они преждевременны :-)


Пожалуйста.

4 Xeon MP 1.9 Ггц дисковая стойка HP EVA 4000 на 4 Tb доступно 2,5 так как остальное забирается под их хитрый райд массив и горячую подмену (Объемы очень большие так ак надо хранить все данные минимум за 3 года). Память 4 Гб. На этом железе работает примерно 100 чел. В пики до 160. Выполняется куча аналитической отчетности.
23 май 06, 10:22    [2694156]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

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

Не могли бы Вы привести конфигурацию оборудования, на котором производилось тестирование ? В примере, который привел Сергей, она присутствует. Мне кажется, выводы можно начать делать, когда мы ее сравним с Вашей. А пока они преждевременны :-)


Пожалуйста.

4 Xeon MP 1.9 Ггц дисковая стойка HP EVA 4000 на 4 Tb доступно 2,5 так как остальное забирается под их хитрый райд массив и горячую подмену (Объемы очень большие так ак надо хранить все данные минимум за 3 года). Память 4 Гб. На этом железе работает примерно 100 чел. В пики до 160. Выполняется куча аналитической отчетности.


Забыл БД Oracle 10.1.0.5 работает в режите Archivelog,
так же включена опция flashback что не очень помогает быстродействию так как пишется куча журналов. Объем журналов за 1 день составляет 19-28 Гб.
23 май 06, 10:36    [2694225]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
AMD 2500+ (1.8Ghz)/1Gb, IDE HDD 120Gb 7200
=
4 Xeon MP 1.9 Ггц дисковая стойка HP EVA 4000 на 4 Tb 
Память 4 Гб. 

Что сравнивается в таких разных условиях, не понял. Хотя интересно было-бы узнать.
23 май 06, 10:39    [2694246]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
iscrafm
AMD 2500+ (1.8Ghz)/1Gb, IDE HDD 120Gb 7200
=
4 Xeon MP 1.9 Ггц дисковая стойка HP EVA 4000 на 4 Tb 
Память 4 Гб. 

Что сравнивается в таких разных условиях, не понял. Хотя интересно было-бы узнать.


Ну так и нагрузка разная слегка не заметили. Там 1 чел. сидит а у меня 100. У него при более выгодных условиях (с базой работает 1 чел. Практически больша никаких задач не выполняется, объем значительно меньше и т д.) скорость работы не сильно выше. Это говорит о многом в том числе о том что при многопользовательской работе и на реальных данных все работать будет гораздо медленнее. Конечно усиление железа немного спасет ситуацию но вы никогда не получите 3-5 кратного превосходства над тем же Ораклом. В общем то я хотел показать имено это. Так что не поддавайтесь на рекламу о чудо постреляционных СУБД придуманных в 60-70 гг. прошлого века.
И еще сравните код на SQL и на М. Интересно в каком коде быстрее разберется человек. Если на SQL надо написать 1 команду то на М надо целую программу. Достаточно приличного объема. Я конечно понимаю что поклонники М хитрят и не пишут операторы полностью чтоб хоть как то визуально приблизить свое творение к размерам SQL запроса. Пусть это будет на их совести. Кстати SQL можно вообще не писать есть куча графических построителей запросов. Ну это к слову. Не хочу обидеть стороников М систем. Просто мне надоело что постояно говорят о том что М может сделать любую РСУБД в несколько раз. А как доходит до реальных примеров ничего доказать не могут. Причем этим страдают не только программисты но и сама Intersystems.
23 май 06, 10:54    [2694346]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Нагрузку как определили? Следили за загрузкой процессора что-ли. На минутных загрузках как поняли, что не Вы один, а 100 чел в эту минуту делили железо. Конечно никак. Хотя действительно в адекватных условиях тест был бы интересен.
23 май 06, 11:31    [2694561]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Joker_Ya
И еще сравните код на SQL и на М. Интересно в каком коде быстрее разберется человек.

Насчет кода конечно Вы правы.
23 май 06, 11:33    [2694585]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
iscrafm
Нагрузку как определили? Следили за загрузкой процессора что-ли. На минутных загрузках как поняли, что не Вы один, а 100 чел в эту минуту делили железо. Конечно никак. Хотя действительно в адекватных условиях тест был бы интересен.

не был бы. обратите внимание, что идет последовательный перебор.

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

Откуда:
Сообщений: 61
Sergei Obrastsov
обратите внимание, что идет последовательный перебор.


А не могли бы Вы попробовать выполнить во эту программку?

автор


; Формирование теcтового массива
k ^Table
k ^SPhoneIndex
k ^DateTimeIndex
s StartDate=+$h ; массив будет формироваться начиная с сегодняшнего дня


w !,"формируем массив"
w !,"Начало формирования - ",$ZDT($h)," "
f i=1:1:10000000 d ; количество (нужно менять при испытании)
.s DeltaDate=$r(365) ; случайный день
.s date=StartDate+DeltaDate ; дата разговора для тестирования
.s time=$r(86400) ; случайное время для даты разговора
.s DateTime=+(date_"."_time) ; в таком формате будем хранить дату и время
.s SPhone=+$r(9999999) ; случайный номер телефона-источнка
.s RPhone=+$r(9999999) ; случайный номер телефона-приёмника
.s Length=$r(3600) ; случайная продолжительность разговора
.s Сortege=$LB(DateTime,Phone,Length,RPhone) ; кортеж данных
.s ^Table(i)=Сortege ; массив данных
.s ^SPhoneIndex(SPhone,DateTime)=i ; Индекс по номеру телефона-источника
.s ^DateTimeIndex(DateTime,SPhone)=i ; Индекс по дате
.i i#100000=0 w !,i," ",$ZT($p($h,",",2))
w !,"Конец формирования - ",$ZDT($h)," ",!!

; Выборки
;----------
w !,"проход по всему массиву и подсчет количества записей"
s i="" s count=0
w !,"Начало - ",$ZDT($h)," "
f s i=$O(^Table(i)) q:i="" s count=count+1
w "Конец - ",$ZDT($h)," ",!
w " количество = ",count,!!


Мне интересно время выплнения на вашем компьютере.
23 май 06, 12:14    [2694929]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
yww@escape.ru
Member

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



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

автор

.s Сortege=$LB(DateTime,SPhone,Length,RPhone) ; кортеж данных


Если не возьмётесь - я не обижусь
23 май 06, 12:17    [2694963]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
Sergei Obrastsov
iscrafm
Нагрузку как определили? Следили за загрузкой процессора что-ли. На минутных загрузках как поняли, что не Вы один, а 100 чел в эту минуту делили железо. Конечно никак. Хотя действительно в адекватных условиях тест был бы интересен.

не был бы. обратите внимание, что идет последовательный перебор.

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


а что Вы предлагаете
23 май 06, 12:40    [2695171]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
vadiminfo
Member

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

а что Вы предлагаете

Выслать тест на TPC и попросить их прокомментировать или хотя бы посмотреть на их реакцию. Что же еще?
23 май 06, 13:12    [2695508]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
pgres
Member

Откуда: Харьков
Сообщений: 140
пожалуйста вполне адекватные условия
Win XP SP2
P4 3GHz
512 Mb RAM
80 Gb HDD SATA

Microsoft SQL Server 2000 - 8.00.194 (Intel X86) Aug 6 2000 00:57:48 Copyright (c) 1988-2000 Microsoft Corporation Personal Edition on Windows NT 5.1 (Build 2600: Service Pack 2)


create table ttalks(
  starttime datetime not null,
  duration int not null
)
go

create clustered index ttalks_idx1 on ttalks(starttime)
go


количество записей за месяц ~43млн
по дням распределены неравномерно
в таблице немного больше но при существовании индекса это неважно
размер базы 1.7Гб

не самый лучший запрос

select day(starttime), count(*), sum(cast(duration as numeric(18,0)))/3600, avg(cast(duration as numeric(18,0)))/3600
from ttalks 
where starttime between '1-Jan-1900' and '31-Jan-1900' 
group by day(starttime)
order by day(starttime)

120 сек

не вижу обещаного превосходства каше в 5 раз
(ну или хотя бы в 2)

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

Откуда: Магадан
Сообщений: 584
pgres
пожалуйста вполне адекватные условия
Win XP SP2
P4 3GHz
512 Mb RAM
80 Gb HDD SATA

действительно, просто одно и то же, подумаешь на 1Ghz больше


select day(starttime), count(*), sum(cast(duration as numeric(18,0)))/3600, avg(cast(duration as numeric(18,0)))/3600
from ttalks 
where starttime between '1-Jan-1900' and '31-Jan-1900' 
group by day(starttime)
order by day(starttime)
120 сек

может кто-нибудь все-таки проверит сколько времени займет
sum(cast(duration as numeric(18,0))/3600)


не вижу обещаного превосходства каше в 5 раз
(ну или хотя бы в 2)

в 2 и есть. :)
24 май 06, 01:06    [2698586]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
Joker_Ya
Member

Откуда:
Сообщений: 186
iscrafm
Нагрузку как определили? Следили за загрузкой процессора что-ли. На минутных загрузках как поняли, что не Вы один, а 100 чел в эту минуту делили железо. Конечно никак. Хотя действительно в адекватных условиях тест был бы интересен.


За процессорами не следил в этот раз но до этого специально мониторил систему. Загрузка в рабочее время в среднем составляет 30-40%. К сведению для вас 100 подключений даже неактивных требуют довольно боольших ресурсов системы сами по себе. Это прежде всего память (около 1 М если ничего не делали на процесс, у меня в среднем 2-5). Это время процессора так как постояно проверяется активно ли соеденение. Вообще внутри системы происходит значительное кол-во телодвижений для поддержания пула соеденений, для обеспечения целостности транзакций как читающих так и пишущих. Кстати у меня запрос был в рамках 1 транзакции, т. е. все данные были полученвы на момент начала транзакции. В приведенном тесте на М о транзакциях не слова и если данные необходимые для выборки были изменены после начала обработки то уже измененные данные попадут у них в выборку. Я же получу те данные которые были на момент начала транзакции даже если после начала выполнения запроса кто либо изменил данные. Поддержка транзакция весьма ресурсоемкая вещ. Так что тест в принципе показал что никакого особого приемущества М системы не дают. Железо у них было послабее. Так и работала в однопользовательском режиме без поддержки транзакций на сильно урезанных данных (у меня кол-во записей в таблице порядка 500 млн. у них всего 261 кроме того у меня длина записи почти в 15 раз больше). И при всех этих условиях скорость выполнения у них всего в 1.5 - 2 раза выше. Если добавить в их тест еще пару работающих человек, уравнять структуры хранения добавить транзакции то результат будет не сильно лучше.
Тут Сергей постояно говорит:
обратите внимание, что идет последовательный перебор

И что это проблемы Каше и других М систем. Сделайте аналогичный SQL запрос если вам перебор не нравиться. Я думаю там вообще результат будет хуже раза в 2. В одном из топиков кто-то делал сравнение SQL в Оракле и Каше. Результат был не в пользу Каше раза в 1.5.

Еще раз повторюсь я не против Каше. Просто при практически одинаковой стоимости лицензий на Каше и Оракл вы получите конструктор сделай сам все на языке похожем на курсовую работу студента филолагического факультета (так как с математикой очень плохо у них было приоретета операций нет) с криво пределаным SQL производительность которого не блещет а синтаксис застыл на уровне 90 годов, с жесткими ограничениями на кол-во подключений (у оракла нет никаких ограничений. Только совесть клиента и если например в какой то момент ононеожидано превысит кол-во лицензий купленных то ничего страшного все будет работать дальше. А вы можете спокойно докупить лицензии), с практически полным отсутствием литературы на русском, с отсутствием нормальной бесплатной версии (практически у всех РСУБД они есть с определенными ограничениями, по объему и количеству процессоров которые позволяют спокойно работать). Есть еще много минусов. Плюсов я например от приверженцев Каше так и не дождался. Одни обещают беспрецидентной производительности раз в 5 больше чем у РСУБД но этого нет как мы видим на реальных тестах. Другие говорят об удобстве хранения данных в деревьях, но его тоже нет так как под очередной запрос надо структуру данных подгонять. В общем сплошной гемморой за нехилые бабки.
24 май 06, 02:47    [2698621]     Ответить | Цитировать Сообщить модератору
 Re: Слабые стороны Cache & SQL  [new]
c127
Guest
yww@escape.ru
c127
А для выборки по неделям они будут лежать в узлах по этим самым неделям (а в месяце не целое число недель)


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

А я ничего никуда не помещаю, это Вы их туда помещаете:
"в Каше не нужно выбирать данные за месяц.. они уже будут лежать в узле, относящемся к этому самому месяцу."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=293038&pg=6#2684408

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

Ну да, как же, только что нам втюхивали что индексы могут не потребоваться:
"если вы уже на этапе постановки задачи знаете что вам портебуются выборки по датам, то и данные можно хранить в узлах, организованных на $h... а здесь уже всё равно - по месяцу, по неделе, по году - принцип то один и тот же.. становитесь на начало периода и двигаетесь до конца.. дополнительные индексы здесь могут и не понадобиться. ИМХО, конечно.."
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=293038&pg=8#2687245

Я же об этом и говорю, что стоит немного поменять постановку задачи, а это по-моему происходит всегда, все достоинства КЕШ-а пропадают, остаются давно всем хорошо известные недостатки иерархических БД.

yww@escape.ru

И не думайте, пожалуйста, что лично вас кто то пытается обмануть

Расслабтесь, я так не думаю. Но даже если и пытаются, это меня не беспокоит, не должно беспокоить и Вас. Хотя имете право беспокоиться разумеется.
24 май 06, 03:31    [2698631]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 8 9 [10] 11   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить