Oracle Database 10g Release 2

С тем что нафик не нужно - я полностью согласен!!! То что у тебя трудиться два часа - это не просто так! Oracle - это действительно сложная и мощьная система. Если её не админить то смысла её - никакого!!! Если хочешь сравнивать то учитывай многии нюансы, настраивая все параметры таблицы, как её структура блоков и подобные настройки. И никогда не используйте индексы на изменяющие поля - oracle начнёт загибаться (без админа), даже если вы удалите все записи из таблицы и добавите одну - то скорость выборки будет очень долгой!!! У каждой таблицы свои цели будь то DSS или OLTP таблицы их надо по своему и специфично настраивать, а если не можешь - производительности не получишь... Я сам делаю множественные репликации с Oracle на mysql. Не буду же я ставить oracle там где это неоправдано!!! И всё работает отлично!!! В большинстве случаем проблема масштабируемости и производительности зависит от логики приложения а не от конкретной выбранной базы данных!!!

> В большинстве случаем проблема масштабируемости и производительности зависит от логики приложения а не от конкретной выбранной базы данных!!!

Слова не мальчика, но мужа! Респект!

> Там, где мой мускул загребает 500-600 тысяч записей за 5-15 минут

... там мой оракл это делает значительно быстрее. Не считая external tables, есть ещё SQL*Loader. Скорость загрузки 17 лям ~25 минут при _не_ direct-path. Direct-path даёт ускорение в несколько раз, но мне генерировать данные надо при загрузке, а sql-команды не работают при direct-path загрузке. External tables работают ещё быстрее, чем sql*loader.

Нам нужна надежная СУБД, mysql это не надежная СУБД. Теперь по поводу вашиъ "таблиц". Индексы к вашим таблицам должны занимать 2-5гб, так что не надо про 1-3 секунды ок ?

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

И коли уж заговорили о таких больших таблицах во вного гигов, то Mysql`ники скажите мне как вы делаете резервирования данных? Холодное копирование? Накладно! А в online режиме? насколько я помню mysql не держит уровни изолирования данных!

можно поднять второй ьysql сервер и делать на него репликацию. На время бэкапа делаешь в нем STOP SLAVE;. Далее делаешь бэкап как угодно. Затем START SLAVE;.

> как вы делаете резервирования данных?
как вариант http://www.innodb.com/manual.php

> насколько я помню mysql не держит уровни изолирования данных!
http://dev.mysql.com/doc/mysql/en/innodb-transaction-isolation.html

> Правильно подметил! Плюс при таком количестве данных лучше задуматься отказаться от глобального индекса и перестроить таблицу на использование партиций!!!MySQL это может? А может ещё вспомним Кластеризацию таблиц и индексные таблицы! MySQL хорошая база, но ей ещё далеко...

А может вспомним про PostgreSQL и Ingres R3 ?)

Эту перловскую надстройку я знаю! Но всё равно это полное копирования данных, что не подходит для real time приложений, пока ты сделаешь копию, упадут новые данные

С уровнями изолирования соглашусь! С 4.0.5 в InnoDB SERIALIZABLE появился!

SERIALIZABLE This level is like REPEATABLE READ, but all plain SELECT statements are implicitly converted to SELECT ... LOCK IN SHARE MODE.

"Also, if the latest data belongs to a yet uncommitted transaction of another client connection, we wait until that transaction commits" да, уровни изолирования прикрутили в ушёрб масштабируемости! В Oracle это вс ё делается без каких либо ожиданий! Если я не ошибся, поправте!

А что все прицепились к MySQL? Нашли конкурента для оракла. Среди os субд есть еще и PostgreSQL! Резервирование делается на лету! Благодаря версионной архитектуре снимок там ненакладен. Кластеризация таблиц, управление тейбспейсами и т.п. имеет место быть. Кстати, 8-ка работает и под виндой теперь(вообще список платформ весьма внушителен http://www.postgresql.org/docs/faqs.FAQ_russian.html#1.3). Реально - самая продвинутая в мире из субд с открытым кодом. Больше чем уверен, что возможностей PostgreSQL хватило бы 95% для тех поделий в нашем отечестве, что написаны упрямыми ораклоидами местного разлива.

Кстати, Postgres - это даже не гпл, это бсд лицензия. Полная свобода!

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

Нам нужна надежная СУБД, mysql это не надежная СУБД. Теперь по поводу вашиъ "таблиц". Индексы к вашим таблицам должны занимать 2-5гб, так что не надо про 1-3 секунды ок ?

Уверяю тебя, что ни одного случая потери данных за последние полтора года, что я пользую мускул, не было. Индекс к каждой таблице занимает 2.3-2.7 Гб. Таблицы лежат на RAID-1 массиве у машинки с 2Гб мозгу, конфиг мускула заточен на использование этой памяти. В аналогичных условиях Оракл, настроеный распальцованным админом, сливает. И я не понимаю, нафига ставить оракл на задачу, где тупо грузятся данные в таблицы, а потом выбираются, без изменения данных. Про 1-3 секунды - ни разу не соврал, выборка делается именно столько.

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

P.S. Оракул стоит 9i, из-за чего пришлось конкретно перекорёжить систему. Потому что 10g "навороченный админ оракла" побоялся ставить.

> Просто мне самому стало обидно когда начинают сравнивать базы из разных так сказать весовых категориях!
лично я сравниваю оракл с несколькими Open Source базами (в том числе MySQL) вместе, каждая под свой класс задач. Причем класс задач MySQL не требует правильной SERIALIZABLE и полноценный backup, для этого есть другие OS базы.

Господа, обьясните такой момент.
ПОльзователь оракла - например, system или sys, имеет доступ к данным из любой таблицы.
В одном из обзоров говорилось, что в 9 версии будет нововведение - на таблицы можно будет навесить
какой-то признак - и эти данные, которые находятся в этих таблицах, будут доступны только владельцу таблицы.
Т.е., в тех же спецслужбах - админ оракла может иметь доступ к любым данным в базе. В 9 вроде как уже это можно
ограничить.
Это правда?

> Потому что 10g "навороченный админ оракла" побоялся ставить

Это явно был неправильный админ :) Десятка проще ставится, и систему корежить не приходится.

Про MySQL vs Oracle. Я не совсем понимаю, к чему вообще эти все гигабайты и миллионы записей. Тут что, все занимаются только загрузкой и выгрузкой данных? Дело ведь совсем не в объеме, а в сложности манипуляций с данными. Например оракловые аналитические ф-ции в MySQL придется эмулировать созданием временных таблиц - это будет на порядки неэффективнее.

> Больше чем уверен, что возможностей PostgreSQL хватило бы 95% для тех поделий в нашем отечестве, что написаны упрямыми ораклоидами местного разлива.

Возможности PostgreSQL - это Оracle 7 в лучшем случае. Т.е все что написано под 8 и выше (а это гораздо больше 5%) PostgreSQL уже не заменит.

интересно, а почему все так зациклились на оракле?

если бы выбирал сервер баз данных , то выбрал db2, ну или sybase если база попроще

Кстати, о db2 - один товарищ говорил, что за бугром эта субд по популярности и распространенности
ничуть не уступает ораклу.
С точки зрения администрирования, разработки под нее ПО, требовательности к ресурсам,
легкости освоения - как она по сравнению с ораклом?

Значит так!
На тех задачах, которые имеет смысл решать в СУБД мускуль делает оракул в разы!
На тех задачах, которые малограмотные недоадмины решают использованием встроенных средств оракул, трехзвенка на базе мускуля также заруливает оракул и по скорости и по масштабируемости.
Из тех, кто орет, что оракул рулит 90% - вчерашние студенты, которым читали курс субд на нем вместе с программированием на жабе.
Этим и объясняется повышенная красноглазость, фанатизм и отсутствие фундаментальных знаний.

>Значит так! >На тех задачах, которые имеет смысл решать в СУБД мускуль делает оракул в разы! >На тех задачах, которые малограмотные недоадмины решают использованием встроенных средств оракул, трехзвенка на базе мускуля также заруливает оракул и по скорости и по масштабируемости. >Из тех, кто орет, что оракул рулит 90% - вчерашние студенты, которым читали курс субд на нем вместе с программированием на жабе. >Этим и объясняется повышенная красноглазость, фанатизм и отсутствие фундаментальных знаний.

Онанимус! Расскажи сей бред людям из БиЛайн и МТС, например. То-то они клупенькие такие -- тратят сотни тысяч $$$ на гадостную проприетарщину, в то время, как все Онанимуся знают, что MySQL - это панацая.

Хехехе. На самом деле все не так 8) Всё голраздо проще. Как правило юзаются уже готовые задачи сделанные сторонним дядей. Дяди эти как правило являются и реселлерами Oracle. Ясен хрен что дяде этому выгоднее впихнуть решение на Oracle и положить в карман несколько лишних килобаксов.

> Расскажи сей бред людям из БиЛайн и МТС, например. То-то они клупенькие такие -- тратят сотни тысяч $$$ на гадостную проприетарщину, в то время, как все Онанимуся знают, что MySQL - это панацая.

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

То-то они клупенькие такие -- тратят сотни тысяч $$$ на гадостную проприетарщину
Дурилка сопливая, может им денег девать некуда и бюджет надо освоить...

>Хехехе. На самом деле все не так 8) Всё голраздо проще. Как правило юзаются уже готовые задачи сделанные сторонним дядей. Дяди эти как правило являются и реселлерами Oracle. Ясен хрен что дяде этому выгоднее впихнуть решение на Oracle и положить в карман несколько лишних килобаксов.

Было бы *проще* (дешевле, быстрее, надежнее) написать биллинг для сотового оператора на MySQL вместо Oracle, он был бы написан на нем. Потому как рынок, а значит, что решения одинаковой функциональности продаются по примерно одинаковой цене. Следовательно, будь MySQL также хорош, как и Оракл, решения на нем были бы выгоднее в разработке... Но почему-то в жизни все не так, и MySQL в серьезных проектах (уровня РКС банков, или толго же биллинга сотовых операторов) мы не наблюдаем...

Только тупые онанимусы, не написавшие ни единого серьезного проекта, считают себя умнее всех остальных и пишут все на MySQL. Ага, при этом не зная, что такое НФ и ACID.

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

Никто не спорит, но к чему эта фраза?

>а во-вторых есть еще волшебное слово откат, но это уже будет совсем офтоп.

Угу. Миром правят откаты.

>Дурилка сопливая, может им денег девать некуда и бюджет надо освоить...

ФГМ. Больной неоперабелен, в морг.

stellar, с тобой все ясно. Шагай дальше, мальчик и не позорься.

>Что касается сотовых операторов, то сомневаюсь, что они ответят тебе о причине выбора: во-первых кто ты такой?

Да что тут спрашивать сотовиков? Используют Oracle, DB2, Sybase - потому что БИЛЛИНГОВЫЕ системы писались под них. Сотового оператора стоимость СУБД не пугает. Там в час такие бабки протекают, что на это не смотрят. Берут лучшее, проверенное, отлаженное, непадучее. Чтобы не потерять те самые БОЛЬШИЕ бабки из-за простоя, потери данных,..., чтобы не потярять клиентов, ...

>а во-вторых есть еще волшебное слово откат, но это уже будет совсем офтоп.

И что? Вы обвиняете большинство сотовых компаний в коррупции? Смешно, очень часто даже местными сотовыми операторами владеют(или совладеют) буржуйские фирмы. Они покупают отечественный или буржуйский биллинг(в том числе и для препэид систем) - и там почему то не используется мойSQL. Юзают Oracle,DB2,Sybase. Есть конечно алтернативы, можно вообще не использовать СУБД :). Кроме шуток, есть такие препэид системы.

Ну а насчет отката - тут вы правы :), Oracle очень хорошо работает с сегментами отката, особенно в последних версиях, реализуя многоверсионную базу, обеспечивающую выдачу данных отчета на момент его запуска, и при этом операции DML не мешают прохождению этого отчета(в отличии от MS SQL например, где UPDATE блокирует SELECT). Не знаю как с этим у MySQL. Кроме того многие разрабы "подседают" на Oracle, потому что он имеет самую развитую версию процедурного расширения SQL - PLSQL.

>stellar, с тобой все ясно. Шагай дальше, мальчик и не позорься.

anonymous, сказать нечего? Окей, слив засчитан.

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

И я даже знаю почему: потому, что описанная тобой модель рынка устарела лет 50 как и не описывает реальную ситуацию. Почитай на досуге про теорию игр - очень увлекательно, кроме шуток. Соответственно вспоминаю начала булевой алгебры: из истины следует истина, из лжи - все, что угодно. Неверна исходная посылка (базовая модель на которой строится аргументация).

> И что? Вы обвиняете большинство сотовых компаний в коррупции?

Да ни боже ж мой!
Для тех, кто еще не знает, что такое откат поясняю:
прихожу я в БобруйскЭлектроТелеСвязьКом и говорю с начальником отдела айти:
- давай я тебе биллинг на оракуле продан - всего лишь за 100 тонн гринов?
- в жопу, дорого слишком
- но ведь платить то контора будет, а откат мы сделаем 10 проентов
- окей, ваше предложение заинтересовало нас масштабируемостью, стабильностью... бла бла бля

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

итог: все довольны.

домашнее задание: как получить соразмерный откат при использовании мускуля?

>Господа, обьясните такой момент. ПОльзователь оракла - например, system или sys, имеет доступ к данным из любой таблицы. В одном из обзоров говорилось, что в 9 версии будет нововведение - на таблицы можно будет навесить какой-то признак - и эти данные, которые находятся в этих таблицах, будут доступны только владельцу таблицы. Т.е., в тех же спецслужбах - админ оракла может иметь доступ к любым данным в базе. В 9 вроде как уже это можно ограничить. Это правда?

В 9-ке о таком не слышал. Можно навешивать политики безопасности. но для sys они не прокатывают ...

> Для тех, кто еще не знает, что такое откат

Откат платится конкретному человеку, реже нескольким, поэтому обвинять целую компанию бессмысленно.

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

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

Запомним сию фразу.

>домашнее задание: как получить соразмерный откат при использовании мускуля?

Либо ровно точно также, как и Оракла; либо MySQL немасшабируем, нестабилен, неудобен в использовании по сравнению с (Ораклом, Ин и потому не подходит в качестве СУБД для биллинга. Черт возьми, если все так и обстоит на самом деле так зачем же тогда нужен откат?

Так что аргументация не катит ни разу.

> ...до такого разве что васья пупкин догадается. с таким ущербным sql диалектом ситема только и будет что гонять данные между слоями.

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

> Запомним сию фразу.

Это бессмысленно запоминать: это называется сарказм.
Насколько я знаю, чувству юмора не учат ни в одном вузе :)

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

>Итог: медленно, немасштабируемо, неподдерживаемо.

да ... вот такой оракл загодочный зверек, по полной сливает на тяжелых OLPT задачах Mysql :) особенно в тестах SAP, TPC и прочих :)

> Просто мне самому стало обидно когда начинают сравнивать базы из разных так сказать весовых категориях!

Ну ты BC приколист!!! Это что ж по твоему получается - в этом треде ораклисты мочат мускульцев?!? Ха!!! Помоемому это мускульцы, страдающие комплексом неполноценности, налетают на ораклистов. А те вальяжно отмахиваются от мух и пытаются объяснять мускулистым пионэрам, что "мамы" тьфу ты "СУБД всякие нужны, СУБД всякие важны" (С) из анекдота про вовочку. Как говорится, по задаче и СУБД :). Всем остальным! Встречал я ораклистов, которые с пеной у рта доказывали что оракл рулит на любых задачах... С ними хоть можно было поговорить, они вменяемые! Но чаще встречал мускулистых пионэров, которые вообще ничего не воспринимали. И это плохо! И еще встречал скромняг посгресистов, которые ничего никому не доказывали с пеной у рта, но у которых посгрис работал на абсолютно разноплановых задачах. :)

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

Может и есть откат, но речь ведь не об этом. Вы, мозг включите, найдите хоть одну КОММЕРЧЕСКУЮ, ТИРАЖИРУЕМУЮ биллинговую систему на mySQL.

> Может и есть откат, но речь ведь не об этом.

Речь ИМЕННО об этом!
Попробуй создать коммерческую тиражируемую (что бы ты ни имел под этим ввиду) биллинговую систему на базе мускуля, а затем:
- продай ее кому-нибудь без использования отката
- пройди сертификацию не давая взяток

Проблема КОММЕРЧЕСКОГО использования систем на базе мускуля вместо систем на базе оракула носит не технический, а политический характер. А в России еще и криминальный.

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

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

>- продай ее кому-нибудь без использования отката

Только что говорилось, что это Оракл НЕ продается без использования отката. Теперь выясняется, что как раз MySQL нельзя продать без откатов... Онанимус, ты хоть определись, что можно, а то нельзя продавать без отката.

>- пройди сертификацию не давая взяток

То есть, взятки нужны для того, чтобы получить бумажку на неработоспособное решение?

а как у MySQL с суппортом :) ?

>PLSQL

и чем лучше того что у PostgreSQL? кроме того на постгри я могу и свои сявые модули подключать

> что можно, а то нельзя продавать без отката.

чувства юмора у него нет, логическое мышление не развито, дык еще русский хромает!

1. Оракул как правило не продается без откатов. (~ Оракул как правило продется с использованием откатов).
2. Систему на базе Мускуля нельзя продать из-за невозможности дать откат, сравнимый по масштабам с оракуловским.

Что здесь не ясно? Оракул продается, мускуль-систем - нет. Причина - откат: у оракула они жирные и вкусные, у мускуль-систем - мелкие или их нет вообще.

> Возможности PostgreSQL - это Оracle 7 в лучшем случае. Т.е все что написано под 8 и выше (а это гораздо больше 5%) PostgreSQL уже не заменит.

Онлайн репликация появилась в Оракле только в девятке (Oracle Dataguard). К 9.2.0.5 она стала хоть как-то работать на не быстрых каналах, после того как поправили один досадный баг. И только в 10ке есть надежда что сделали всё совсем грамотно (сам не пробовал в 10ке, только слышал).

В MySQL & PostgreSQL онлайн репликация есть и довольно стабильная насколько я слышал (сам не пробовал).

> Потому как невозможно создать "коммерческую тиражируемую биллинговую систему на базе мускуля".

С этим надо что-то делать: с такими способностями и низким уровнем интеллекта ЕГЭ тебе не сдать.

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

ага. "этого не может быть потому что этого не может быть никогда" (с)

слив засчитан, фанатик

>Что же до PostgreSQL - отличная весч!

У неё ед кясяк, она не сертифицированна в России на биллинг. Т.е. биллинг на mysql делать можно, а на postgresql нельзя. =)

>ага. "этого не может быть потому что этого не может быть никогда" (с)

Окей, пример в студию!