Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Сравнение производительность обработки Oracle & Java  [new]
Yo.!
Guest
DPH
Увы, а у меня именно такого типа бизнес-логика, уже который проект. И нужны данные, не поверите, именно за последние несколько секунд, а не за месяц/год. И данные легко помещаются в оперативную память одного сервера. Впрочем, если добавить всю бизнес-логику, то, думаю, все равно Java будет быстрее (когда появляются динамические фильтры, сложные зависимости между элементами, введенные пользователем формулы, пара десятков настроек и т.п.).


ну специальность у вас узкая. небойсь че нибудь типа ИИ для форекса, все таки задач которые насилуют субд гораздо больше.
6 июн 08, 12:22    [5769627]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
mq
Guest
Yo.!
у меня такое предложение. сгенерить побольше табличку, чтоб она гарантирована сильно не влезла бы в память, миллионов на 500 записей, там одно поле телефона. задача распарсить тучу вариантов написания номера телефона и разложить код страны и очищеный номер по разным полям. не знаю умеет ли db2 regexp в SQL, но можно 2 варианта проверить - с regexp в SQL и с запретом на использования regexp. вот тут на апп-сервер и замерим, как ему понравится тягать гигобайты в свою память.

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

может тогда еще туда добавить пару полей типа: когда, кто и сколько позвонил, и потом посчитать звонки каким-нибуть тарификами :)
6 июн 08, 13:27    [5770183]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
DPH
Guest
mq

может тогда еще туда добавить пару полей типа: когда, кто и сколько позвонил, и потом посчитать звонки каким-нибуть тарификами :)


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

А потом добавить еще два новых тарифа и сравнить, кто быстрее реализовал ;)
6 июн 08, 13:38    [5770306]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
Yo.!
Guest
DPH


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

А потом добавить еще два новых тарифа и сравнить, кто быстрее реализовал ;)

я за.
+378 12345678
(378) 12345678
00 378 12345678
00378 123 45678
моб. +378123 45678
тел. +378 123 456 78
(378)1234-5678

и их варианты SQL-ем без regexp так запросто вроде не распарсить.

VoDA

Для упрощения задачи:
1. данные - это нечто вида CLIENT int not null, ORDER_ID int not null, ORDER_AMOUNT int not null (кстати а ORDER_AMOUNT может быть отрицательным). Внутренний формат задан жестко.
2. Входные данные поступают в виде CSV файла разделенного ',' с переводом строки. Важно, что формат не подходит для bulk-insert операции. Сам формат может меняться, потому данные перед употребление нужно парсить.
3. Файл сжат ZIP алгоритмом. Важно, что алгоритм сжатия может меняться, потому система должна иметь возможность изменить его.
4. Строк в файле ~ 1 000 000.

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


не догнал что мы тут померим, в оракле это gunzip | sql*loader c правилами парсинга и пара SQL команд ... до pl/sql дело и не дойдет ...
6 июн 08, 13:49    [5770411]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
mq
Guest
Anton Demidov
Вы отвлекаетесь от основной задачи этого тестирования - сравнить скорость PL/SQL и Java.
Решение на чистом SQL будет дано здесь, но только вне конкурса. Мы все (я надеюсь) прекрасно понимаем, что оно будет быстрее всех.

Очевидно, что чем дальше мы отходим от реляционных задач (это к вашей "фазе луны"), тем выгоднее использовать универсальные ЯП типа С или Явы. С другой стороны, чем больше данных вам надо перебрать (это я по поводу таблицы на пол милиарда записей, предложенной Yo.!), тем "ближе" надо находится к БД для уменьшения издержек на пересылку данных.


в данном примере, можно компенсировать издержки на <"ближе" надо находится к БД "> threads в Java, другими словами, можно тупо создать thread per client, и подсчитать сумму...
6 июн 08, 13:52    [5770427]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
mq
Guest
Yo.!

+378 12345678
(378) 12345678
00 378 12345678
00378 123 45678
моб. +378123 45678
тел. +378 123 456 78
(378)1234-5678

и их варианты SQL-ем без regexp так запросто вроде не распарсить.

Когда у вас будут 500 млн. записей, думаю, что Вы найдете другой способ, как это реализовать более оптимально.
Хотя кто знает... :)

Это все равно что сортировать данные пузырьком или quicksort, результат тотже, а реализация другая :))
6 июн 08, 16:56    [5772168]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
Ага. В качестве карты тарифов взять какой-нибудь реальный Билайн - с корпоративными фенечками и разделением звонков по разным тарифам ;)
и их варианты SQL-ем без regexp так запросто вроде не распарсить.

Эту хрень НИЧЕМ так просто не распарсить. Причем сотовые - случай в телефонии самый простой, разве что данных много. Лет так несколько назад сделали мы биллинг стационарной телефонии и инет. Так там мало того, что записей десятки миллионов в каждом файле, мало того что записи с разных коммутаторов в сети в разных форматах, так еще один и тот же звонок гуляет по коммутаторам внутри сети с разным временем регистрации, бывают дубликаты, да еще сверка с коммутаторами партнеров, которые черте-че присылают...
В результате после долгих мыканий пришлось писать свой многопоточный парсер на C++ со сложным хешем в памяти и многокритериальным нечетким поиском, а уже его весьма обработанный под одну гребенку результат быстрым load'ом пихать в DB2, где и крутить статистику и т.д. Разработка заняла 2 года, причем не с нуля.
А тарифы с кучей условий, *** маркетологами напридуманные... А аналитика с рекомендациями по маршрутизации... Вобщем, не совсем для тестирования задача :)
ИМХО как раз правильный пример того, что не все на СУБД делать надо - важна именно максимальная скорость обмолота нереляционных изначально данных, а она только компиляторами и только in-memory достигается, тем более что при парсинге надежность, логи и т.д. не нужны. СУБД очень нужен, но уже потом. :)
6 июн 08, 17:30    [5772476]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
VoDA
Предложение: заменить NUMBER на int для большей совместимости типов.
Если хотите - меняйте. Для Оракла это NUMBER с запретом иметь дробную часть - т.е. внутреннее представление не меняется.
VoDA

Код:
INSERT INTO testtotals 
SELECT client, SUM(order_amount) 
FROM testbig
GROUP BY client
СУБД - Apache Derby. Все работает внутри моего приложения и исключительно на Java

А если запись с клиентом уже есть?!
Любой тест гоняется по несколько раз для получения "правильного" тайминга. Этот код "свалится" по Primary Key Violation при втором прогоне.
6 июн 08, 19:59    [5773242]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
antand
Member

Откуда: Москва
Сообщений: 599
Favn

+1 Классический этап подготовки и загрузки данных в хранилище для последующего анализа
Я вообще не сильно понимаю зачем этот спор в таком виде по производительности затеяли.
Каждой технологии свое место, свои алгоритмы. Как тут сказал Yo, что мерим то?
Скорость выборки данных - СУБД быстрее, скорость обработки структурированных выбранных данных(типа пересчета остатков) - СУБД быстрее. Тут зачем что-то обсуждать, для этого СУБД придумали.
А вот скорость обработки выбранных неструктурированных данных - тут можно разные технологии применять. Если обработка простая - можно и на SQL обработать. Cложная - используйте сторонние инструмены и технологии. Только выборку данных для этих инструментов оставьте базе.
6 июн 08, 20:03    [5773262]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
antand
Member

Откуда: Москва
Сообщений: 599
Я бы еще добавил по началу темы.
Бизнес-логику обработки подготовленных структурированных данных эффективнее реализовать внутри БД. Конечно при грамотном проектировании самой СУБД.
Но это далеко не бизнес-логика всего приложения.
6 июн 08, 20:23    [5773314]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
Anton Demidov
Member

Откуда: Atlanta, GA
Сообщений: 1187
Мой тестовый код на PL/SQL. Специальная версия, чтобы минимально использовать БД и максимально нагрузить PL/SQL. Я преднамеренно не использую MERGE и SUM/GROUP BY

set term off
CREATE OR REPLACE PROCEDURE test1 AS
    iTotalAmt   NUMBER;
/*
    можно было просто NUMBER написать, но захотелось показать 
    тесную интеграцию процедурного кода и структуры данных
*/
    iLastClient testtotals.client%TYPE; 
BEGIN 
    FOR cc IN ( SELECT client, order_amount
                  FROM testbig
                 ORDER BY client)
    LOOP
        If iLastClient IS NULL Then
            iLastClient := cc.Client;
            iTotalAmt   := 0;
        End If;
        
        If iLastClient != cc.Client Then
            UPDATE testtotals SET
                 client_total = iTotalAmt
             WHERE client = iLastClient;
            If SQL%ROWCOUNT = 0 Then
                INSERT INTO testtotals
                       (client, client_total)
                VALUES (iLastClient, iTotalAmt);
            End If;
            iLastClient := cc.Client;
            iTotalAmt   := 0;
        Else
            iTotalAmt := iTotalAmt + cc.order_amount;
        End If;
    END LOOP;
    COMMIT;
END;
/
-- Непосредственно тестирование, запускаем три раза
DELETE FROM testtotals WHERE client < 64
/
COMMIT
/
set timing on term on
PROMPT Start
EXECUTE test1

set timing off term off
DELETE FROM testtotals WHERE client < 64
/
COMMIT
/
set timing on term on
EXECUTE test1

set timing off term off
DELETE FROM testtotals WHERE client < 64
/
COMMIT
/
set timing on term on
EXECUTE test1

set timing off term off
DROP PROCEDURE test1
/
set term on
PROMPT Done
P.S.
Что-то я с объёмами не расчитал - всего две секунды у меня это исполняется.
6 июн 08, 21:24    [5773458]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
Yo.!
Guest
Favn
Yo.!
Ага. В качестве карты тарифов взять какой-нибудь реальный Билайн - с корпоративными фенечками и разделением звонков по разным тарифам ;)
и их варианты SQL-ем без regexp так запросто вроде не распарсить.

Эту хрень НИЧЕМ так просто не распарсить.


как раз регэкспом это делается элементарно
SELECT REGEXP_REPLACE(REGEXP_REPLACE(phone,'[^0-9]', ''), '0?0?', '') as result from table ;

да ... ступил, через translate и substr наверно тоже простенький SQL получится, наверно действительно еще картой тарифа придется усложнять.
9 июн 08, 14:11    [5782051]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
Favn
Member

Откуда:
Сообщений: 585
Yo.!
как раз регэкспом это делается элементарно
В таком виде - элементарно чем угодно. Я о том, что в настоящем логе со "взрослого" тел. коммутатора запись мягко говоря не соотсветствует самому факту звонка, связь может быть многие ко многим, да еще и с дубликатами и неверной информацией. Не говоря уже о тарифах...
9 июн 08, 14:26    [5782178]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
Возьмите обычный оракловский swingbench. Там есть два теста типа TPC-C для "ввода и обработки заказов"- plsql и чисто java. Первый вызывает процедуры, второй - только sql через java-программу. Объем начальных данных и количество "пользователей" спокойно настраиваются. Еще и результат по типам транзакций получите.

Взять можно на www.dominicgiles.com. Работает и на линуксе/юниксе, и на винде.
9 июн 08, 22:36    [5784829]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
Anton Demidov
Мой тестовый код на PL/SQL. Специальная версия, чтобы минимально использовать БД и максимально нагрузить PL/SQL. Я преднамеренно не использую MERGE и SUM/GROUP BY

set term off
CREATE OR REPLACE PROCEDURE test1 AS
    iTotalAmt   NUMBER;
/*
    можно было просто NUMBER написать, но захотелось показать 
    тесную интеграцию процедурного кода и структуры данных
*/
    iLastClient testtotals.client%TYPE; 
BEGIN 
...
P.S.
Что-то я с объёмами не расчитал - всего две секунды у меня это исполняется.
А через что можно запустить тестовый пример?

Пробовал через APEX => SQL Commands => script, получаю ORA-00922: missing or invalid option
10 июн 08, 15:54    [5788378]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
Yo.!
Guest
Favn
В таком виде - элементарно чем угодно. Я о том, что в настоящем логе со "взрослого" тел. коммутатора запись мягко говоря не соотсветствует самому факту звонка, связь может быть многие ко многим, да еще и с дубликатами и неверной информацией. Не говоря уже о тарифах...

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

2VoDA
set term off - это команда sqlplus, без нее пробуй.
10 июн 08, 16:27    [5788712]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
Yo.!
2VoDA
set term off - это команда sqlplus, без нее пробуй.
Ок спасибо, загрузил через sqlplus чтобы не париться.

Итого результаты Java/JavaDB vs plSQL/Oracle:
Скорость: к сожалению скорость Java-procedure внутри JavaDB оказалась достаточно низкая, хотя возможно не учтены какие то дополнительные факторы влияющие на производительность. Скорость обработки Oracle 1,4-1,8 с, JavaDB 10-12 с.

Синтаксис: на Java код получается больше из-за отсутствия поддержки встроенного в язык SQL (есть SQLJ для Oracle, но возможности его использования для меня туманны).

В Java приходится писать больше кода для того же результата (SQLJ не рассматривался)
Вместо
            UPDATE testtotals SET
                 client_total = iTotalAmt
             WHERE client = iLastClient;
Нужно
PreparedStatement update = connection.prepareStatement("UPDATE testtotals SET " +
                    " client_total = client_total + ? " +
                    " WHERE client = ?");
                    update.setInt(1, totalAmount);
                    update.setInt(2, lastClient);
                    int sqlRowCount = update.executeUpdate();

Объем ПЗУ требуемый под БД не засекался.
Объем потребляемой памяти - преимущество за Java (хотя Oracle & Java не оптимизировались под уменьшение потребления памяти и CPU)
10 июн 08, 17:59    [5789469]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение производительность обработки Oracle & Java  [new]
VoDA
Member

Откуда: сеРверная пальмира :)
Сообщений: 4898
Общие примечания.

Спасибо Anton Demidov-у и другим участникам дискуссии за участие ;)


После проведения ряда тестов и опираясь на предыдущий опыт работы как DB-developer-а пришел к выводам:
  • Для обработки большого потока реляционных данных придется пользоваться процедурными расширениями SQL (PL/SQL от Oracle).
  • Использовать Derby стоит на малых объемах (до 100 Мб). При превышении объема производительнее использовать локально установленную СУБД и крутить данные хранимками.
  • Пока нет возможности совместить переносимость между СУБД и скорость обработки данных.


    Все вышеуказанное ИМХО!!!
    ----

    - Just Do IT! (c)
  • 10 июн 08, 18:11    [5789543]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение производительность обработки Oracle & Java  [new]
    okdoky
    Member

    Откуда:
    Сообщений: 349
    Честно говоря, я не очень в курсе с предыдущим диалогом. Сравнение идет для Java и PL/SQL при работе с одной БД Oracle или для двух СУБД Java DB (Derby) и Oracle?

    Похоже, изначально, речь шла о первом случае, но стараниями DPH вопрос ушел куда-то в сторону. Могу помочь ему не уходить очень далеко. То есть, чтобы Java не уступила PL/SQL, достаточно всего лишь вызывать PL/SQL из Java используя JDBC.
    14 июн 08, 13:04    [5800947]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение производительность обработки Oracle & Java  [new]
    Vurn
    Member

    Откуда:
    Сообщений: 213
    VoDA

    Скорость: к сожалению скорость Java-procedure внутри JavaDB оказалась достаточно низкая, хотя возможно не учтены какие то дополнительные факторы влияющие на производительность. Скорость обработки Oracle 1,4-1,8 с, JavaDB 10-12 с.


    У JavaDB провал на insert/update, выборку делает быстро.
    29 июн 08, 13:11    [5861903]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение производительность обработки Oracle & Java  [new]
    drev
    Member

    Откуда: Одесса - Берег Красного Дерева - Красный мир
    Сообщений: 564
    Кстати, о телефонах:

    Пришел полный номер телефона, нужно определить страну.

    Где это нухно делать, в программе или в базе?
    29 июн 08, 22:20    [5862580]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение производительность обработки Oracle & Java  [new]
    VoDA
    Member

    Откуда: сеРверная пальмира :)
    Сообщений: 4898
    Vurn
    VoDA

    Скорость: к сожалению скорость Java-procedure внутри JavaDB оказалась достаточно низкая, хотя возможно не учтены какие то дополнительные факторы влияющие на производительность. Скорость обработки Oracle 1,4-1,8 с, JavaDB 10-12 с.


    У JavaDB провал на insert/update, выборку делает быстро.
    ХЗ мне нужно было получить общую скорость работы. Оказалось, что общая скорость хромает.

    Отписался разрабам Derby / JavaDB. ничего особо придумать не смогли. Проверял и апдейт версии и апдейт JRE. Смог дотянуть только до 9,5 сек.

    У других еще хуже - рассмотрел h2database (разработывают ее разработчики hipersonic, которую вроде забросили). Так вот хранимка на h2 выдала 15 сек.
    30 июн 08, 11:25    [5863787]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение производительность обработки Oracle & Java  [new]
    VoDA
    Member

    Откуда: сеРверная пальмира :)
    Сообщений: 4898
    drev
    Кстати, о телефонах:

    Пришел полный номер телефона, нужно определить страну.

    Где это нухно делать, в программе или в базе?
    Зависит от объема данных и сложности обработки.

    Чем больше нужна скорость тем больше перевес в сторону обработки на СУБД. Чем больше сложность одной операции разбора, тем больше перевес на стороне приложение, ибо его проще дебажить разрабатывать и есть большое количество библиотек которые можно использовать в приложении.

    Если и сложность мала и данных мало, то все рано, но я бы рекомендовал на СУБД. ИМХО.
    Если данных много и сложность разбора велика, то нужно выбирать ИЛИ быстро разработать, но медленно ехать, ИЛИ долго пишем и отлаживаем, но быстро работает.
    30 июн 08, 11:26    [5863802]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение производительность обработки Oracle & Java  [new]
    drev
    Member

    Откуда: Одесса - Берег Красного Дерева - Красный мир
    Сообщений: 564
    VoDA
    drev
    Кстати, о телефонах:

    Пришел полный номер телефона, нужно определить страну.

    Где это нухно делать, в программе или в базе?
    Зависит от объема данных и сложности обработки.

    Чем больше нужна скорость тем больше перевес в сторону обработки на СУБД. Чем больше сложность одной операции разбора, тем больше перевес на стороне приложение, ибо его проще дебажить разрабатывать и есть большое количество библиотек которые можно использовать в приложении.

    Если и сложность мала и данных мало, то все рано, но я бы рекомендовал на СУБД. ИМХО.
    Если данных много и сложность разбора велика, то нужно выбирать ИЛИ быстро разработать, но медленно ехать, ИЛИ долго пишем и отлаживаем, но быстро работает.


    Нет там никакой обработки. Просто достаточно большие таблицы (иногда нужны первые 6 знаков). Причем - изменяемые. ИМХО, только запрос к базе.
    30 июн 08, 12:25    [5864157]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение производительность обработки Oracle & Java  [new]
    softwarer
    Member

    Откуда: 127.0.0.1
    Сообщений: 67427
    Блог
    drev
    Просто достаточно большие таблицы (иногда нужны первые 6 знаков). Причем - изменяемые. ИМХО, только запрос к базе.

    ИМХО таки зависит от ситуации. Если, предположим, железяка должна в течение гарантированного времени получить ответ - устанавливать такое соединение или рвать - то эту функцию лучше вынести поближе к входу.
    30 июн 08, 13:47    [5864577]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
    Все форумы / Сравнение СУБД Ответить