Joker_Ya Sergei Obrastsov pgres так что давайте кашисты не изворачивайтесь а делайте придложенный тест

хорошо, привожу результаты тестирования.
в связи с тем, что заказчик теста не указал размер записи, тестировались 2
структуры:
a)

b)
где 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повтори запрос. Я уверен что у тебя и база будет меньше занимать места и выигрыш в скорости запроса будет больше