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

Откуда: Atlanta, GA
Сообщений: 1187
DPH
Кстати, а сколько запросов в секунду (простых get) держит интерфейсный слой на PL/SQL? В расчете на ядро?
Я не тестировал производительность за ненадобностью - у меня же не OLTP.

DPH
И, все-таки, что такое "обработала"? И почему обработка в Оракле будет быстрее, чем на сервере приложений (какие причины?)
Немного расскажу, что же моя система делает. Признаю, что это оффтоп, посыпаю голову пеплом и пр. Но раз уж спросили ...
Это File Management + Workflow + ETL System. Около 200 банков со всего мира шлют нам информацию в 7 основных классах - Authorization, Payment, Posting, Cardholder, etc. Моя задача сопоставить файл с его владельцем, разархивировать/раскриптовать, идентифицировать начинку, собрать статистику соответствующую этому типу, сделать 10% сэмпл с преобразованием в стандартный формат, собрать статистику по нему, заархивировать получившиеся файлы и раскидать их по дискам. Естественно, куча отчётов как по управлению файлами, так и по анализу статистики.
Проблемы в том, что на 200 клиентов приходится 100 различных форматов данных. Файлы могут быть в ASCII или EBCDIC, с символом(-ами) перевода строки и без. Есть уникумы, что шлют EBCDIC файлы с "0x0Ah" кодом. Да, файлы приходят обработанные zip/gzip/rar/jar/pgp/tar во всевозможных комбинациях. И приходят они как в электронном виде, так и на физических носителях.
Это было так, вступление. Получив входной файл в готовом виде, я создаю External Table на него и начинаю гонять SQL запросы для сбора статистики (900 статистик для Auths, 800 - Posts, 300 - Cards. Они группируются по возможности, но всё равно получается 140 запросов для Auths к примеру). Помимо простейших типа Min/Max, собирается статистика, требующая двух проходов - это Mode, Count Unique, Percentiles etc. Есть ещё "хитрые" статистики, типа "частоты разницы между двумя датами". Интерфейс программы принимает любые Oracle Expressions включая вызовы пользовательских функций для определения статистики.
Почему это работает быстрее без явы и апп сервера?
  • Установка PARALLEL 4 для внешней таблицы сокращает время скана таблицы в 4 раза (точнее 3,8)
  • Используются внутренние функции Оракла для сбора статистики - работает быстро, parallel-enabled, etc - не надо "изобретать велосипед" на Яве.
  • Отсутствуют промежуточные слои и связанные с ними расходы.
  • Некоторые файлы очень большие - 250Гб

    DPH
    Metalink, насколько я помню, вообще отличается изрядной задумчивостью - это уже не раз обсуждалось. В чем причина - не знаю (и даже не буду строить предположений). Кстати, а metalink разве не на APEX сделан?
    У меня одинаковая скорость работы как Metalink-a, так и MSDN (к примеру). APEX появился значительно позже Metalink-а.

    P.S.
    Сама база у меня всего 400Гб. Сервер: 2x(XEON 4 Cores), 32Gb RAM, SAN для БД, NAS для файлов. Есть ещё 3 серверочка послабже для "зипования" файлов - они управляются с сервера БД.
  • 30 май 08, 19:26    [5741149]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    DPH
    Guest
    [offtop on]
    Угу, внушает. Но, честно говоря, я вообще не понимаю, зачем тут БД?
    Единственное, зачем я вообще вижу пользу от использования Oracle - возможность указывать алгоритм анализа статистики "снаружи" в текстовом виде. Правда, подозреваю, что относительно общего объема проекта затраты на разработку DSL (или реализацию своего class-loader для алгоритмов) потеряются.

    Ну, может быть Oracle дает какие-то преимущества при оптимизации последовательных чтений (например, эффективно кэширует на уровне блоков, эффективнее быстрых файловых систем), но сомневаюсь, что это действительно существенно.
    А параллельность на Java обеспечивается легко... Да и стоимость десятка лишних машинок с Java будет меньше лицензии на один сервер с Oracle ;)

    Задача похожа на обработку больших логов, ну так у меня, с использованием банального gzip+awk для поиска числа уникальных по сложному критерию (и некоторых статистик дополнительно), без малейшей оптимизации, получается что-то около 20 mb в секунду (под виртуальной машиной при этом). И, подозреваю, ограничивается больше диском, чем процессором.
    [offtop off]

    Ну, MSDN - это тоже не показатель, тормозит неимоверно. Антиреклама .NET ;)
    Впрочем, sun.com особой шустростью тоже не отличается, хотя и побыстрее :)
    1 июн 08, 01:15    [5742851]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    tygra
    Member

    Откуда: Тверь (Иркутск, Край)
    Сообщений: 9997
    Ну осталось явно изобразить выводы о том, что СУБД обрабатывает данные (таблицы) быстрее, чем что-либо другое, использующее эти же данные из этой же СУБД
    Эврика!


    Прогресс у джавистов? Таки не всегда нужно все джавой обрабатывать? Может напомнить, что 2008 год на дворе? Вдруг это тайна? :)

    -- Tygra's --
    Мои фотогалереи тут и тут
    2 июн 08, 09:24    [5745067]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    VoDA
    Member

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

    Почему это работает быстрее без явы и апп сервера?
  • Установка PARALLEL 4 для внешней таблицы сокращает время скана таблицы в 4 раза (точнее 3,8)
  • Используются внутренние функции Оракла для сбора статистики - работает быстро, parallel-enabled, etc - не надо "изобретать велосипед" на Яве.
  • Отсутствуют промежуточные слои и связанные с ними расходы.
  • Некоторые файлы очень большие - 250Гб
  • Привет!

    А есть ли связанность между входными файлами или каждый обрабатывается независимо. От этого и зависит архитектура.

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

    Если связанности нет или она "слабая", то можно крутить все на раздельных серверах. Данные обрабатываются на каждой ноде независимо. Файл деархивируются, подкладывается в локальную СУБД и на ней лопатится. В итоге получается массово-параллельная система. Масштабируется тупо линейно.


    А истина скорее всего где-то посередине
    2 июн 08, 14:18    [5746969]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    VoDA
    Member

    Откуда: сеРверная пальмира :)
    Сообщений: 4898
    tygra
    Ну осталось явно изобразить выводы о том, что СУБД обрабатывает данные (таблицы) быстрее, чем что-либо другое, использующее эти же данные из этой же СУБД
    Эврика!


    Прогресс у джавистов? Таки не всегда нужно все джавой обрабатывать? Может напомнить, что 2008 год на дворе? Вдруг это тайна? :)
    Ура товарисчи!!! На дворе 2008 год.

    Осталось узнать, что Java уже давно в стандартном комплекте имеет СУБД. И может легко грызть данные и через SQL и через Java-процедуры запущенные в адресном пространстве СУБД.

    А вдруг это тоже тайна?
    2 июн 08, 14:55    [5747258]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    tygra
    Member

    Откуда: Тверь (Иркутск, Край)
    Сообщений: 9997
    Нифигасе, к Джаве в комплект теперь Оракл дают? В нагрузку? Вот прогресс то дошел :))

    -- Tygra's --
    Мои фотогалереи тут и тут
    2 июн 08, 15:22    [5747529]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    VoDA
    Member

    Откуда: сеРверная пальмира :)
    Сообщений: 4898
    tygra
    Нифигасе, к Джаве в комплект теперь Оракл дают? В нагрузку? Вот прогресс то дошел :))
    э... а чё пошел регресс и в качестве СУБД только Oracle великий и ужасный работать может?

    я что-то пропустил ???
    2 июн 08, 16:10    [5747969]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    tygra
    Member

    Откуда: Тверь (Иркутск, Край)
    Сообщений: 9997
    Ну вряд ли MS SQL к джаве кладут :))

    -- Tygra's --
    Мои фотогалереи тут и тут
    2 июн 08, 16:28    [5748141]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    The_ShadoW
    Member

    Откуда:
    Сообщений: 1134
    Регресс явно пошел, но видимо пока не настолько сильно. Количество СУБД резко упало, но не до одной, а до двух. Майкрософту тоже на регресс пофиг :)
    3 июн 08, 15:33    [5753022]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    Favn
    Member

    Откуда:
    Сообщений: 585
    О как! Я тут DB2 вовсю использую, а она уже регрессировала?! А мужики-то не знают...
    Уж всяко в тройку входит, причем ИМХО по совокупности не на 3-м месте :) Это не говоря о семействе WebSphere...
    Так что IBM-у тоже на этот регресс как-то пофиг. Если в России мало DB2 - не значит, что его мало в мире. Кстати, родные дрова есть под Java, .Net, PHP и прочие Perl'ы. Java кладут в комплект - на ней в т.ч. SP и UDF пишут.
    3 июн 08, 18:01    [5754578]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    The_ShadoW
    Member

    Откуда:
    Сообщений: 1134
    Тсссс! Не пугайте человека, а то про следующую не успевшую еще пока регрессировать СУБД мы так и не узнаем
    3 июн 08, 21:58    [5755441]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    Anton Demidov
    Member

    Откуда: Atlanta, GA
    Сообщений: 1187
    DPH
    Ну, может быть Oracle дает какие-то преимущества при оптимизации последовательных чтений (например, эффективно кэширует на уровне блоков, эффективнее быстрых файловых систем), но сомневаюсь, что это действительно существенно. А параллельность на Java обеспечивается легко...
    Зря сомневаетесь - у Оракла очень развитые алгоритмы параллельной обработки, которые у меня нет ни малейшего желания заново изобретать. Особенно интересно становится жить, когда размер рабочих данных превышает возможности ОЗУ.

    tygra
    Ну осталось явно изобразить выводы о том, что СУБД обрабатывает данные (таблицы) быстрее, чем что-либо другое, использующее эти же данные из этой же СУБД
    Для Оракла это именно так. DB2 и MSSQL не имеют до такой степени развитый внутренний язык, потому и нет разницы или даже медленнее.

    VoDA
    Если связанности нет или она "слабая", то можно крутить все на раздельных серверах.
    Именно так. Я этот вариант держу "про запас" на случай катастрофической нехватки ресурсов. Впрочем, учитывая стоимость лицензии на Oracle Enterprize Edition, может быть дешевле купить более быстрый сервер. Для меня лицензия уже была в наличии - мигрировали со старого Sun Fire V880.

    Favn
    Если в России мало DB2 - не значит, что его мало в мире.

    Про проценты популярности здесь (англ). DB2 много в мире, но это в основном DB2 AS/400 (iSeries). DB2 LUW только начала набирать популярность, но в процентном соотношении её всё ещё очень мало.

    Favn
    Java кладут в комплект - на ней в т.ч. SP и UDF пишут.
    Почему IBM поддержмвает Яву я писал здесь. Учитывая убогость родного SQL-PL и несовестимость синтаксиса для разных платформ (AS/400, LUW, MainFrame), выбора особо то и нет.
    3 июн 08, 23:10    [5755678]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    DPH
    Guest
    Anton Demidov
    Почему это работает быстрее без явы и апп сервера?
  • Установка PARALLEL 4 для внешней таблицы сокращает время скана таблицы в 4 раза (точнее 3,8)

  • Не понял, а как мы можем сканировать данные быстрее, чем отдает дисковая система/сеть?
    Если я правильно понял, что такое PARALLEL в Oracle, то время обработки файла (суммарное по процессорной мощности) от PARALLEL все равно не изменится, а так как файлов у тебя много, то на пропускную способность системы это не повлияет . Впрочем, реализовать такую вещь на Java не долго. Может, есть и уже реализованное (никогда не смотрел в эту сторону).


  • Используются внутренние функции Оракла для сбора статистики - работает быстро, parallel-enabled, etc - не надо "изобретать велосипед" на Яве.

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


  • Отсутствуют промежуточные слои и связанные с ними расходы.

  • Похоже, что если это делать на Java, то можно много что сэкономить - например, приведение к стандартному виду и первый проход статистики делать в одном проходе (т.е. файловый поток идет на вход последовательности обработчиков, в результате имеем преобразованный файл и все первые статистики). Одно это может ускорить работу где-то в два раза.

    Так что, есть у меня подозрение, что система на Java (с какой-нибудь ZFS и под Соляркой) будет работать и побыстрее. Другое дело, что ее разработка может обойтись несколько дороже, но тут уже нужно считать по конкретному ТЗ и прикидывать стоимость лицензий ;)


    Для Оракла это именно так. DB2 и MSSQL не имеют до такой степени развитый внутренний язык, потому и нет разницы или даже медленнее.

    Ну, у DB2 свой PL/SQL-подобный язык появился только для проектов миграции с Оракла/MSSQL, до этого обходились обычным С. Ну и с 8ой, кажется, версии добавили JAVA, REXX и прочие радости. И это, вообще-то, именно внутренние языки. Так что выразительность у DB2 будет, пожалуй, и существенно выше, чем у Oracle.
    MSSQL в качестве встроенного использует С#, там тоже все хорошо с языком. А уж качество компиляторов для DB2/MSSQL, подозреваю, просто несравнимо c Oracle.

    Но решение с application layer должно быть побыстрее совсем по другим причинам ;)

    P.S. Антифродовая система?
    4 июн 08, 03:52    [5756103]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    Favn
    Member

    Откуда:
    Сообщений: 585
    Anton Demidov
    DB2 и MSSQL не имеют до такой степени развитый внутренний язык, потому и нет разницы или даже медленнее.
    Всегда считал, что внутренним языком СУБД является SQL. А он в DB2 уж никак не "менее развитый". SQL/PL вполне достаточен для бизнес-логики на уровне БД, не понимаю, чего именно там жизненно не хватает. Разве что рекурсия ограничена - так рекурсивные данные лучше молотить в SQL. Врядли кто будет спорить, что обработка данных в SQL куда эффективнее процедурных извращений (хотя бы с точки зрения оптимизатора). И в конце концов, DB2 тесно интегрирована с Java-машиной (как и с .Net под Win), так что реализовать можно любые схемы работы.
    Anton Demidov
    DB2 много в мире, но это в основном DB2 AS/400 (iSeries). DB2 LUW только начала набирать популярность, но в процентном соотношении её всё ещё очень мало.
    Учитывая убогость родного SQL-PL и несовестимость синтаксиса для разных платформ (AS/400, LUW, MainFrame), выбора особо то и нет.
    Она набирает популярность уже не первый десяток лет :) Разница между DB2 AS/400 и LUV в синтаксисе минимальна - учитывая незначительные ограничения, можно спокойно писать совместимые запросы, т.к. SQL практически идентичен, клиент общий для всех. ИМХО основная причина различных линеек - принципиальная разница в механизмах ОС. Еще раз - не понимаю, в чем именно заключается убогость DB2 SQL-PL с точки зрения СУБД, т.к. ее SQL - один из лучших.

    Anton Demidov
    Яву продвигают Sun и IBM - т.е. производители железа. С чего они получают доход: с продажи компилятора Явы или супер-пупер числомолотилки? Вот и подумайте, насколько они заинтересованы в оптимальности скомпилированного кода.
    Гениально! Просто раскрыт всемирный заговор. Правда, тогда придется признать, что:
    1. На заклание положено все семейство IBM WebSphere, именно на Java в основном базирующееся. На минуточку, оно приносит (вместе с DB2) IBM доход сравнимый с железками.
    2. В заговор входит и Oracle - своим Application Server, как раз на J2EE работающим. Интересно, какое железо он производит? Или ему откаты платят?
    3. Основной смысл заговора - раскрутка MS .Net как основного конкурента. Видимо, MS все это и проплатил
    4. Одновременная поддержка Perl, PHP и т.д. осуществляется как "операция прикрытия".
    Вобщем, всегда любил конспирологические измышления за полноту и непротиворечивость
    4 июн 08, 13:46    [5758429]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    VoDA
    Member

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

    VoDA
    Если связанности нет или она "слабая", то можно крутить все на раздельных серверах.
    Именно так. Я этот вариант держу "про запас" на случай катастрофической нехватки ресурсов. Впрочем, учитывая стоимость лицензии на Oracle Enterprize Edition, может быть дешевле купить более быстрый сервер. Для меня лицензия уже была в наличии - мигрировали со старого Sun Fire V880.
    Ну вот мы и дошли до сути ))

    Стоимость разработки системы состоит из затрат на железо + лицензии + много чего еще в том числе и какие есть специалисты. И переучивать специалистов никто не будет ибо дорого.
    Для компании где я работаю НАМНОГО дешевле окажется написать на Java и раскидывать задачи на большое число машин. Скорее всего в вашей компании много DBA & DB-developer-ов, потому дешевле оказывается докупить еще лицензий на Oracle.

    Итого:
    * есть профи по Oracle / другой СУБД - для бизнеса дешевле сделать на ее основе + докупать серверное железо и лицензии на Oracle.
    * Есть посредственности по Java - для бизнеса дешевле сделать на Java + докупить слабые компы и организовать "кластер". Лицензии в этом случае ничего не стоят.

    А все эти разговоры Oracle круче Java или наоборот - ИМХО ни о чем. Реализовать можно и на том и на том. А поддерживать то нам с вами
    4 июн 08, 14:54    [5758940]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    VoDA
    Member

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

  • Отсутствуют промежуточные слои и связанные с ними расходы.

  • Прикол как раз в том, что промежуточного слоя может и не быть. Либо Oracle-слой либо Java-слой.
    и в том и в другом случае слой один, только он занимается обработкой и анализом.

    DPH
    Похоже, что если это делать на Java, то можно много что сэкономить - например, приведение к стандартному виду и первый проход статистики делать в одном проходе (т.е. файловый поток идет на вход последовательности обработчиков, в результате имеем преобразованный файл и все первые статистики). Одно это может ускорить работу где-то в два раза.

    Так что, есть у меня подозрение, что система на Java (с какой-нибудь ZFS и под Соляркой) будет работать и побыстрее. Другое дело, что ее разработка может обойтись несколько дороже, но тут уже нужно считать по конкретному ТЗ и прикидывать стоимость лицензий ;)
    Это уже варианты улучшения и оптимизации. На первом месте обычно скорость создания и работоспособность ПО.
    4 июн 08, 15:06    [5759024]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    tygra
    Member

    Откуда: Тверь (Иркутск, Край)
    Сообщений: 9997
    Favn
    О как! Я тут DB2 вовсю использую, а она уже регрессировала?! А мужики-то не знают...
    Уж всяко в тройку входит, причем ИМХО по совокупности не на 3-м месте :) Это не говоря о семействе WebSphere...
    Так что IBM-у тоже на этот регресс как-то пофиг. Если в России мало DB2 - не значит, что его мало в мире. Кстати, родные дрова есть под Java, .Net, PHP и прочие Perl'ы. Java кладут в комплект - на ней в т.ч. SP и UDF пишут.

    Фишка в том, что не Джаву к СУБД кладут, а наоборот - есть секретная JavaСУБД, которая круче DB2, Оракл и MSSQL (может даже вместе взятых). Так что все мы остались на перроне, а джава-поезд ушел

    Но название той СУБД нужно спрашивать у VoDA , это он проговорился о ней :)
    Ко мне то у вас какие вопросы? ;)

    -- Tygra's --
    Мои фотогалереи тут и тут
    4 июн 08, 15:26    [5759173]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    Anton Demidov
    Member

    Откуда: Atlanta, GA
    Сообщений: 1187
    VoDA, Favn и DPH.

    У вас "шапочнозакидочное" отношение к сложным задачам. Я посмотрел на вашу статистику постов - никто из вас не показывал большой активности в форума Оракла. Я подозреваю, что PL/SQL вы не знаете на профессиональном уровне. Так как же вы можете рассуждать о его плюсах и минусах?

    DPH
    Если я правильно понял, что такое PARALLEL в Oracle, то время обработки файла (суммарное по процессорной мощности) от PARALLEL все равно не изменится
    От вашего непонимания результаты моих тестов не изменятся - я же ясно написал, что в итоге стало быстрее в 3.8 раза.

    DPH
    Да и объем кода для реализации стандартных функций Оракла не очень большой
    И с кем я тут спорю?! Да Вы круты! Предложите свои услуги разработчикам MySQL - а то у них что-то всё запарки с производительностью - никак не догонят большую тройку лидеров.

    --
    Per rectum ad astrum
    4 июн 08, 21:42    [5761403]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    Favn
    Member

    Откуда:
    Сообщений: 585
    Anton Demidov
    VoDA, Favn и DPH.У вас "шапочнозакидочное" отношение к сложным задачам. Я посмотрел на вашу статистику постов - никто из вас не показывал большой активности в форума Оракла. Я подозреваю, что PL/SQL вы не знаете на профессиональном уровне. Так как же вы можете рассуждать о его плюсах и минусах?
    Не надо отвечать всем сразу.
    1. Я ни разу не высказывал здесь свое отношение к сложным задачам. Тем не менее считаю, что шапкозакидательство - именно решать сложные задачи силами только СУБД, тем более "в сфере Web-приложений" (это на случай, если если кто забыл, о чем эта ветка :) ).
    2. Я не показывал никакой активности в форуме Оракла, так как почти с ним не работал. Я не знаю PL/SQL, и мне совсем за это не стыдно. Я вообще недавно на форуме, но давно работаю с СУБД как проектировщик/разработчик, больше всего с DB2 LUV начиная с 7-й версии. Я писал о том, что главное в РСУБД - именно SQL, ну м.б. XQuery/XPath, т.е. декларативные языки. А PL (с любыми его плюсами и минусами) имеет весьма вспомогательное значение, тем более для Web. Кстати, Оракл со мной согласен - иначе зачем бы им внешний Application Server на J2EE? :)
    3. У Вас нет ни одного поста в форуме Java. "Я подозреваю, что... Так как же вы можете..?" :)
    4 июн 08, 23:39    [5761712]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    Anton Demidov
    Member

    Откуда: Atlanta, GA
    Сообщений: 1187
    DPH
    P.S. Антифродовая система?
    Да
    Favn
    Не надо отвечать всем сразу
    Я не люблю флудить сообщениями. Мне так удобнее.

    Favn
    Тем не менее считаю, что шапкозакидательство - именно решать сложные задачи силами только СУБД, тем более "в сфере Web-приложений" (это на случай, если если кто забыл, о чем эта ветка :) )
    Чем больше страниц в обсуждении, тем сложнее придерживаться темы. А я всего лишь хотел упомянуть Oracle PL/SQL как один из инструментов. А хорошее знание матчасти поможет наиболее оптимально распределить нагрузку между разными компонентами. Кстати, у меня не "только СУБД" - есть ещё туча шелл скриптов и несколько программ на С
    Favn
    Favn
    не понимаю, в чем именно заключается убогость DB2 SQL-PL с точки зрения СУБД, т.к. ее SQL - один из лучших.
    Я не знаю PL/SQL, и мне совсем за это не стыдно
    Я пока не пересел с Жигулей на Хонду и не знал, что ВАЗ настолько убог. Всё познаётся в сравнении. Просто запомните моё мнение - если в будущем придётся писать под Оракл на PL/SQL, может оказаться, что я был не так уж и не прав.

    Favn
    А PL (с любыми его плюсами и минусами) имеет весьма вспомогательное значение, тем более для Web.
    Для начала о значении PL для веба https://www.sql.ru/forum/actualtopics.aspx?search=htp - посмотите пример кода.
    Далее то, чего пока нет (или мало) в DB2 - Оракл поставляет почти 200 пакетов. Это некий аналог import * в Яве - используем библиотеки. Работа с TCP/IP, mail, files, очереди и прочее.

    Favn
    Кстати, Оракл со мной согласен - иначе зачем бы им внешний Application Server на J2EE?
    А ещё есть OC4J. Чем больше нагрузка, тем больше требуется усилий и технологий по её обслуживанию. Вырос из бесплатного OC4J - покупай Application Server. Пара TomCat - WebSphere из той же оперы.

    Favn
    У Вас нет ни одного поста в форуме Java. "Я подозреваю, что... Так как же вы можете..?" :)
    Я не знаю Яву настолько хорошо, чтобы давать советы другим в том форуме.
    По работе я занимаюсь ДБА поддержкой программеров и SQL application tuning. У нас используются Oracle 10g, DB2/400 (5R4), DB2 for zOS 7.1, DB2 for LUW 9.1. На Яве много пишут.
    5 июн 08, 01:45    [5761907]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    DPH
    Guest
    Anton Demidov
    Я подозреваю, что PL/SQL вы не знаете на профессиональном уровне. Так как же вы можете рассуждать о его плюсах и минусах?

    Конечно, не знаю. Но, тем не менее, примерно представляя сам язык и понимая, как он обрабатывается и сравнивая его с Java вижу, что java код должен выполняться быстрее. Просто из-за ресурсов, выложенных на ускорение работы именно на Java.

    Anton Demidov

    DPH
    Если я правильно понял, что такое PARALLEL в Oracle, то время обработки файла (суммарное по процессорной мощности) от PARALLEL все равно не изменится
    От вашего непонимания результаты моих тестов не изменятся - я же ясно написал, что в итоге стало быстрее в 3.8 раза.

    Время выполнения запроса стало меньше - запросто. Только при этом, вообще говоря, должно было уменьшиться и число одновременно выполняемых запросов (при эффективно загруженной дисковой системе, разумеется). Чудес не бывает, если файл нужно прочитать целиком - то он все равно будет прочитан. Если каждую запись нужно обработать, то какой-нибудь процессор ее все равно обработает.
    Если у нас сотни файлов, то от использования PARALLEL общее время обработки не изменится (если, конечно, эффективно используется многопроцессорность)

    И с кем я тут спорю?! Да Вы круты! Предложите свои услуги разработчикам MySQL - а то у них что-то всё запарки с производительностью - никак не догонят большую тройку лидеров.

    Гм. А зачем нужно реализовывать реляционное представление аналитических функций (кстати, подозреваю, далеко не всех, десятка хватит)? Это действительно сложно. А вот итерационные алгоритмы (а у нас все равно table scan) сделать достаточно легко. Да и найти готовые библиотеки не сложно.


    --
    Per rectum ad astrum[/quot]
    5 июн 08, 04:04    [5761985]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    DPH
    Guest
    Anton Demidov
    DPH. У вас "шапочнозакидочное" отношение к сложным задачам.


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

    Просто моя текущая система (одна из), так сложилось, в качестве БД использует Oracle - и я постоянно слышу от DBA (с ссылками на документацию и Кейта), что бизнес-логику эффективнее реализовать внутри БД. Правда, пояснить, почему так лучше, DBA так и не смог.

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

    Но увы, пока я вижу только обычную оптимизацию ресурсов разработки при решении задачи - использовать то, что более знакомо. И это, конечно, правильно - но к Oracle отношение имеет не очень большое.

    P.S. Последнюю задачу с большим объемом логики внутри БД (MRP в полном объеме с всякими довескам) я делал довольно давно (на MS SQL) и убедился, что БД - плохое место для подобных задач. С тех пор я предпочитаю обработку делать на уровне сервера приложений - и результаты меня удовлетворяют - впрочем, для каждого проекта архитектура делается отдельно и я вполне верю, что иногда проще все делать в БД. У меня просто другие проекты.

    Oracle в проекте использую недавно и, честно говоря, сильно опечален этим фактом - с DB2 работать было на порядок проще (что, конечно, говорит скорее о качестве документации, нежели о самом сервере - но найти человека, который может ответить на простой вопрос по Oracle на порядок сложнее, чем найти самому ответ в документации по DB2).
    5 июн 08, 04:17    [5761989]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    Yo.!
    Guest
    2DPH

    что-то не пойму, это же настолько очевидно. апп-сервер это внешний от субд процесс, при запросе вы тащите копию данных через протокол (небойсь еще и TCP/IP) - т.е. самый тормозной и самый не оптимальный путь какой можно придумать для юзания жавы. pl/sql же исполняется в том же адресном пространстве, что и субд и имеет гораздо меньше переключений контекста.

    ЗЫ. документация по DB2 - ужасна, помнится искал может ли процедура на С отслеживать изменения в схеме и вообще в каком адресном пространстве выполняется. не нашел даже намеков на концепции. хуже документация имхо только у FB.
    5 июн 08, 13:52    [5764468]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    tygra
    Member

    Откуда: Тверь (Иркутск, Край)
    Сообщений: 9997
    DPH
    Просто моя текущая система (одна из), так сложилось, в качестве БД использует Oracle - и я постоянно слышу от DBA (с ссылками на документацию и Кейта), что бизнес-логику эффективнее реализовать внутри БД. Правда, пояснить, почему так лучше, DBA так и не смог.

    DBA значит не знал этого - просто слышал :)

    автор
    P.S. Последнюю задачу с большим объемом логики внутри БД (MRP в полном объеме с всякими довескам) я делал довольно давно (на MS SQL) и убедился, что БД - плохое место для подобных задач. С тех пор я предпочитаю обработку делать на уровне сервера приложений - и результаты меня удовлетворяют - впрочем, для каждого проекта архитектура делается отдельно и я вполне верю, что иногда проще все делать в БД. У меня просто другие проекты.

    Просто вы не умеете готовить бизнес-логику внутри БД :)
    Проще делать не внутри БД только то, что там сделать невозможно. Все остальное проще внутри. Уж поверьте - большой опыт и в обычных системах, и в веб. 90% работ с данными делается только в СУБД, и правлю я тоже все в СУБД, это к тому же проще.


    -- Tygra's --
    Мои фотогалереи тут и тут
    5 июн 08, 14:17    [5764728]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение СУБД в сфере Web-приложений  [new]
    Favn
    Member

    Откуда:
    Сообщений: 585
    Anton Demidov
    А я всего лишь хотел упомянуть Oracle PL/SQL как один из инструментов. А хорошее знание матчасти поможет наиболее оптимально распределить нагрузку между разными компонентами.
    А получилось, что это - наилучший инструмент :) Лучше всего нагрузка распределяется, если каждый сервер выполняет свои задачи. Заодно куда выше гибкость, расширяемость и взломоустойчивость. Хотя, если кроме генерации HTML Ораклу у вас заняться ну совсем нечем...
    Anton Demidov
    Я пока не пересел с Жигулей на Хонду и не знал, что ВАЗ настолько убог. Всё познаётся в сравнении. Просто запомните моё мнение - если в будущем придётся писать под Оракл на PL/SQL, может оказаться, что я был не так уж и не прав.
    А вот это зря - DB2 LUW - ну никак не ВАЗ по отн. к Oracle. Достаточно на tpc.org заглянуть. Кто там Хонда, а кто, скажем, Subaru, еще не известно :)
    К счастью, я сам решаю, на чем будет писаться наш софт, и PL/SQL как app-сервер я использовать не буду, т.к. не считаю правильным мешать мух с котлетами. Хотя, от сумы, от тюрьмы и от заказчика с остранностями... :)
    Anton Demidov
    Для начала о значении PL для веба - посмотите пример кода.
    Зачем мне смотреть примеры, генерирующие HTML из PL/SQL, если мне не нравиться сама схема превращения СУБД в процедурный HTML-сервер? Я сам могу привести пример непроцедурной генерации XML из DB2-запроса и скармливания его XSLT внутри той же DB2 для получения хоть HTML, хоть PDF. Считаю, что это как эффективнее, так и концептуальнее. СУБД должен обрабатывать реляционные и XML (при наличии native storage) данные.
    Anton Demidov
    Далее то, чего пока нет (или мало) в DB2 - почти 200 пакетов. Это некий аналог import * в Яве - используем библиотеки. Работа с TCP/IP, mail, files, очереди и прочее.
    Этого нет и, наверно, не будет в DB2, т.к. это ей не нужно. Зачем мне проприентарный аналог Явы, если в DB2 с ядром сервера работает сама Ява? А С++ приложение может работать вообще внутри самого ядра. Вcе, что мне нужно для внешней отн. БД работы на том же сервере, пишется на Java или на C++. У кого больше библиотек - у Java с C++ или у PL/SQL? Чем еще меряться будем? :)
    Anton Demidov
    Чем больше нагрузка, тем больше требуется усилий и технологий по её обслуживанию. Вырос из бесплатного OC4J - покупай Application Server. Пара TomCat - WebSphere из той же оперы.
    Вот и я о том же - мы с Ораклом и IBM считаем, что почти все можно делать из PL/SQL, но далеко не все нужно. :)
    Кстати, для IBM не TomCat - WebSphere, а WebSphere AppServ Community - WebSphere AppServ.

    Anton Demidov
    По работе я занимаюсь ДБА поддержкой программеров и SQL application tuning. У нас используются Oracle 10g, DB2/400 (5R4), DB2 for zOS 7.1, DB2 for LUW 9.1. На Яве много пишут.
    Я, скорее, проектировщик систем (с web и без) и "играющий тренер" в их разработке. У нас DB2 LUW, C++ разнообразный, Java, Flash, FireBird по мелочи.
    5 июн 08, 15:13    [5765257]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12   вперед  Ctrl      все
    Все форумы / Сравнение СУБД Ответить