![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
rdbms’es are evil
Новичкам » Первые шаги в ORACLE (цикл из 142 статей)
o_0
UPD: как можно нагуглить много дампов оракла (случайно обнаружил, поковыряв дамп руками)Новичкам » Первые шаги в ORACLE (цикл из 142 статей)
o_0
UPD: как можно нагуглить много дампов оракла (случайно обнаружил, поковыряв дамп руками)
no subject
no subject
доречі, воно дійсно evil, особливо типи. після mysql просто паскудство
no subject
no subject
no subject
no subject
no subject
Думай позитивно - станешь Oracle экспертом и у тебя будет куча денег и уважения.
no subject
no subject
Ну взять хотя бы неблокируемые Select'ы для Oracle непринципиально одна сессия делает выборку, или 1000, причем вперемешку с DML. В MS SQL пойдут блокировки, которые и ограничивают масштабируемость.
Блин, ну как такое можно писать без каких-либо оснований. Хорошо, я напишу - RAC превосходно работает.
Ну и еще раз, смотря для чего использовать. Для бухгалтерского приложения, которое должно масштабироваться на 100-1000 одновременных сессий, или это OLTP c тысячами запросов в секунду?
no subject
select - это и есть dml.
с чего вы взяли, что я пишу без оснований?
no subject
Я могу ошибаться, я с MS SQL Не работал уже очень давно.
Неблокируемые SELECT'ы это dirty-read, т.е 2 SELECT'а, запущенные в одно и то же время могут вернуть разные результаты, Oracle возвращает данные, актуальные на момент начала выполнения операции SELECT, не важно были изменения, или нет.
Я имед в виду dml, который модифицирует данные, update / delete.
Да нет, я не думаю, что вы написали без каких-либо оснований, просто само утверждение "не работает" без аргументации смотрится некрасиво
no subject
это точно. но на этот счёт есть гугол, в котором легко находится, например, это:
http://msdn.microsoft.com/en-us/library/ms345124.aspx
no subject
Но transaction-versioning дает все-таки overhead на update / delete.
А вообще, да, многое поменялось, надо будет присмотреться к MS SQL как-нибудь.
Обидно, что во всех статьях MS сравнивается SQL Server и Oracle и конечно первый бьет по всем показателям, в документации Oracle тоже самое. В таких документах слишком много маркетингового bullshit'а, который далекий от реальной жизни. Пока рылся, нашел документ http://www.oracle.com/technology/products/database/clustering/pdf/twp_racsqlserver_2008.pdf.
Это тот же документ, ссылку на который вы мне давали SQL Cluster vs RAC, только наоборот. Здесь Oracle поносит решение от MS и восхваляет свое.
По фичам Oracle точно впереди, а вот актуален ли титул "the most scalable rdbms" непонятно - все лгут.
no subject
точно так же, как у оракла :)
имплементация-то практически такая же.
no subject
no subject
http://download.microsoft.com/download/e/8/e/e8ec4b71-bf13-4fd5-9af5-aabcbec859e6/RealityBehind_RAC.pdf
no subject
По поводу high-availability могу точно сказать - работает, и automatic-failover работает - это то, что я лично проверял. По поводу scalability я ничего сказать не могу - сам не пробовал, Да и я больше оракловую документацию изучаю, а там, как вы понимаете, все солнечно.
Но вообще-то интересно конечно было бы замерить perfomance RAC.
no subject
тем не менее, вот у меня стоит в продакшене sql server, производящий 30 тысяч транзакций в секунду. 16-way (4х4) + DAS, никаких SAN-ов. стоимость железа - under 40K. если прибавить стоимость лицензий, сколько будет? предположим, 65К. у оракла нет никаких шансов произвести 30К транзакций в секунду на системе общей стоимостью 65К. даже и в три раза меньше транзакций произвести нету шансов.
no subject
Oracle на этом же железе взлетит (кстати, в последнее время на Sun'ах Oracle работает отвратительно), дальше есть лицензия на пользователя, по-моему где-то 2к. Так что на эту же конфигурацию мы можем повесить 10 пользователей. Транзакций / сек, мне кажется в этом случае можно выжать и больше, зависит от того, как базу тюнить.
no subject
no subject
no subject
Это смотря для чего использовать. Но вообще для больших баз с высокой нагрузкой равных Oracle нет.
no subject
(Anonymous) 2009-05-28 02:00 pm (UTC)(link)oracle-fan.livejournal.com
no subject
Тем более в свете того, что для физического standby нужен еще один сервер с архитектурой основной базы (если основная база на Sun Fire, то физический бэкап на x86 с Linux не взлетит), еще однин инстанс базы той же версии (это еще одна лицензия), поддержка стоит не так уж и дорого.
И там ниже написано
no subject
(Anonymous) 2009-05-28 02:33 pm (UTC)(link)Насчет "поддержка стоит не так уж дорого" - да как сказать. Заплатили Вы, к примеру, 1млн. зеленых за продукт, а потом еще каждый год платите по 200 тыс. только за то, что Вам своевременно ошибки будут исправлять. Ну и за возможность перейти на новую версию "почти бесплатно".
no subject
Речь шла о только о функционале СУБД, а не о ценах.
По поводу лицензирования. Есть допустим Oracle XE - он бесплатен, а если Вы действительно готовы отдать 1 млн (на самом деле в 1 млн обойдется конфигурация с RAC и несколькими стэндбаями) за Oracle лицензию, опять же оборудование под эту конфигурацию стоит много дороже, то предполагается работа с данными, стоимость которых превышает этот 1 млн во много раз. Учитывая, что данных за каждый год становится только больше 200 тыс. вполне вменяемая цифра (тем более, что поддержку не обязательно продлевать).
no subject
(Anonymous) 2009-05-28 02:56 pm (UTC)(link)XE - не знаю уж для кого выпустили эту фиговинку. Наверное, для студентов в ВУЗАХ. Я бы не стал ставить эту СУБД нигде в боевой обстановке. Для обучения, наверное, сгодится.
1 млн. - это не так уж много для Оракла, который за 1 процессор берет 40тыс. зелени. То есть, получается всего-то 25 процессоров. Если лицензировать стендбай надо (а, кажется, надо), то получается где-то 12 процессоров на сервер основной и 12 - на резервный. Да, такие серверы - это человек так для 300-400 пользователей минимум (конечно, зависит от приложения). Железяки, думаю, будут стоить не сильно дороже самого Оракла, учитывая тенденцию к их удешевлению, чего не скажешь, увы о софте.
Сами данные скорее всего будут стоить намного дороже. Ну и что, Вы считаете, что это повод отдавать другим много? И от техподдержки можно отказаться, только потом на новую версию не перейдёшь до тех пор, пока вся разницу, когда у тебя не было техподдержки Ораклу не возместишь. Вроде так.
no subject
Ну у нее ограничения просто - 1 процессор, 1Gb оперативной памяти 4Gb база, а функционал обычный.
Благо - я обычный разработчик, поэтому это не моя забота, мне дают, я пользусь. Я другими мерками измеряю. И я не говорю, что это хорошо, или плохо, хотя желание не платить мне очень близко :)
Ну и опять-таки, на мой скромный взгляд 20% - не много.
Да, так. Иногда дешевле просто лицензии по-новому купить.
no subject
интересно также, что вы понимаете под "высокой нагрузкой".
no subject
(Anonymous) 2009-05-28 08:41 pm (UTC)(link)Сейчас работаю с биллингами операторов мобильной связи восновном, т.е. много данных (несколько гигабайт за сутки) и собственно биллинг в конце месяца - много больших запросов с сортировками. Ну и конечно оперативная отчетность.
Раньше работал и с OLTP системами - 1000 пользователей плюс оперативная отчетность.
no subject
это не высокая нагрузка, это мой десктоп потянет.
много больших запросов с сортировками
много? больших? это не круто. вот если бы было очень много и очень больших, это другое дело.
no subject
Загрузка не ресурсоемкая, а если ваш дестоп сможет данные за месяц обработать за несколько часов, то я вам завидую и хочу себе такой десктоп.
Сорри, я просто уже привык говорить биллинг, как что-то само собой разумеющееся.
Основная идея - 3-5 таблиц на 2-4 миллиарда строк в месяц. Несколько вспомогательных от тысяч до миллионов строк (грубо говоря, аккаунты, биллинговая информация и всяческие справочники). В конце месяца обработка всех данных, генерация счетов и фин. отчетов.
no subject
эээ, первая часть (несколько гигабайт в день) была про OLTP volume, который не должен представить проблем для моего десктопа. про обработку была вторая часть, про которую известно только что там "много больших", над чем я, признаюсь, немного прикололся. но вообще такие системы как бы строятся по принципу "мухи отдельно, котлеты отдельно" - то есть, весь OLAP потянет второй десктоп :)
от OLTP десктопа в такой архитектуре потребуется только раз в день, а то и раз в неделю, сливать новые данные на OLAP машину.
к чему я это всё? к тому, что на таких объёмах вопрос выбора более cost-effective solution просто не стоит, поскольку sql server based solution будет дешевле в разы (а скорее, на порядок) - учитывая, что в цену sql servera также входят: analysis services, integration services, reporting services.
no subject
Не получится, потому что опреативная отчетность, да и вставка не нагружает базу абсолютно.
Это неконструктивный спор, потому что у вас есть работающие системы на MS SQL, у меня на Oracle, притом требований к системам друг друга мы не знаем.
Аргументы про стоимость я воспринимаю слабо, т.к. плачу не я
Но вы меня убедили поглубже разобраться с SQL Server и при случае попробовать.
no subject
no subject