rdbms’es are evil

[wizzard]

Новичкам » Первые шаги в ORACLE (цикл из 142 статей)

o_0

UPD: как можно нагуглить много дампов оракла (случайно обнаружил, поковыряв дамп руками)

Comments

[109.livejournal.com]

равных, может, и нет. а лучше есть - ms sql server. он просто имеет незаслуженно плохую репутацию из-за sybase codebase, от которой после 2000 года ничего не осталось.

интересно также, что вы понимаете под "высокой нагрузкой".

[(Anonymous)]

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

[109.livejournal.com]

несколько гигабайт за сутки

это не высокая нагрузка, это мой десктоп потянет.

много больших запросов с сортировками

много? больших? это не круто. вот если бы было очень много и очень больших, это другое дело.

[aka-rider.livejournal.com]

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

много? больших? это не круто. вот если бы было очень много и очень больших, это другое дело.
Сорри, я просто уже привык говорить биллинг, как что-то само собой разумеющееся.
Основная идея - 3-5 таблиц на 2-4 миллиарда строк в месяц. Несколько вспомогательных от тысяч до миллионов строк (грубо говоря, аккаунты, биллинговая информация и всяческие справочники). В конце месяца обработка всех данных, генерация счетов и фин. отчетов.

[109.livejournal.com]

если ваш дестоп сможет данные за месяц обработать за несколько часов

эээ, первая часть (несколько гигабайт в день) была про OLTP volume, который не должен представить проблем для моего десктопа. про обработку была вторая часть, про которую известно только что там "много больших", над чем я, признаюсь, немного прикололся. но вообще такие системы как бы строятся по принципу "мухи отдельно, котлеты отдельно" - то есть, весь OLAP потянет второй десктоп :)

от OLTP десктопа в такой архитектуре потребуется только раз в день, а то и раз в неделю, сливать новые данные на OLAP машину.

к чему я это всё? к тому, что на таких объёмах вопрос выбора более cost-effective solution просто не стоит, поскольку sql server based solution будет дешевле в разы (а скорее, на порядок) - учитывая, что в цену sql servera также входят: analysis services, integration services, reporting services.

[aka-rider.livejournal.com]

от OLTP десктопа в такой архитектуре потребуется только раз в день, а то и раз в неделю, сливать новые данные на OLAP машину.
Не получится, потому что опреативная отчетность, да и вставка не нагружает базу абсолютно.

Это неконструктивный спор, потому что у вас есть работающие системы на MS SQL, у меня на Oracle, притом требований к системам друг друга мы не знаем.
Аргументы про стоимость я воспринимаю слабо, т.к. плачу не я

Но вы меня убедили поглубже разобраться с SQL Server и при случае попробовать.

[the-white-man.livejournal.com]

Я, конечно, не такой большой специалист, но мне кажется, что весь основной биллинг можно сделать не раз в месяц, а раз в день, например, (или неск раз в день, или раз в несколько дней), и в конце месяца только агрегировать. По идее такая система не должна требовать ничего супер, ни с точки зрения харда, ни софта. Думаю SQL Server будет существенно дешевле аналогичного по производимости решения на базе Оракла

[aka-rider.livejournal.com]

Промежуточная аггрегация есть, дело не в этом.