Мы уходим с майнфрайм.

[iDesperado]

Железо обошлось почти так же, с одним отличием - у кассандры 6 нод и high availability, а у оракла за те же бабки только одна гигантская VM.
Мигрировать с DB2 на Оракл считаю изначально было ошибкой. Но видимо бабло уже попилено. Жаль что меня к столу не пригласили

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

[valchkou]

Железо обошлось почти так же, с одним отличием - у кассандры 6 нод и high availability, а у оракла за те же бабки только одна гигантская VM.
Мигрировать с DB2 на Оракл считаю изначально было ошибкой. Но видимо бабло уже попилено. Жаль что меня к столу не пригласили

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

конечно речь тут совсем не о том что все нужно на кассандру или типа того переводить. Но оракл был явно оверкил под ту группу задач.
Кроме того разработчики заюзали какуюто фитчу в своих плскл, которая только с интерпрайз лицензией доступна.
в кассандре тоже можно сделать консистентное чтение задать CONSYSTENCY_LEVEL: ALL и пока все копии не запишутся, чтение их не увидит.
вот джойнить действительно проблематично.
У нас было конретное требование - zero down time.
Да с ораклом еще одна засада была, тестовые енв, лицензия на них такая же была, ну или близко по цене.
Кассандра бесплатно и к тому же динамически можно поднимать и убивать VM запросто для экономии средств. С ораклом не скажу, не знаю как у них там решается.
короче за два года как вышли в продакшн, никто к базе не приближался, один раз проапгрейдили с версии 2 до 3 и то на живую, zero down time.

[iDesperado]

в кассандре тоже можно сделать консистентное чтение задать CONSYSTENCY_LEVEL: ALL и пока все копии не запишутся, чтение их не увидит.

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

У нас было конретное требование - zero down time.
Да с ораклом еще одна засада была, тестовые енв, лицензия на них такая же была, ну или близко по цене.

ну в кровавом ентерпрайзе все таки не один узел обычно, хотя бы standby настраивают и на простаивающем standby узле всякие dev/test
но это конечно не то что можно с бесплатным софтом вытворять, когда мы на каждый интегрейшен тест целый хадуп в докере поднимаем. интересно что это почти ничего не стоит по сравнению с "embedded" mariadb.

[Dmitry67]

Все таки у MS SQL хорошо сделано, что в dev edition все фичи доступны, а не как в оракле

[iDesperado]

Все таки у MS SQL хорошо сделано, что в dev edition все фичи доступны, а не как в оракле

а что это меняет, если dev edition для персонального пользования ? dev/uat среда то обычно где-то на шаред сервере и в пайплайнах jenkins и gitlab.

[Dmitry67]

Все таки у MS SQL хорошо сделано, что в dev edition все фичи доступны, а не как в оракле

а что это меняет, если dev edition для персонального пользования ? dev/uat среда то обычно где-то на шаред сервере и в пайплайнах jenkins и gitlab.

Я про фразу:

Да с ораклом еще одна засада была, тестовые енв, лицензия на них такая же была, ну или близко по цене.

Дев всегда можно и нужно толковать расширительно
Не PROD? Не Client facing? Идет отладка? Значит DEV

[deev_a_v]

Все таки у MS SQL хорошо сделано, что в dev edition все фичи доступны, а не как в оракле

а что это меняет, если dev edition для персонального пользования ?

Неверно.

Microsoft allows you to run any nonproduction workloads under Developer Edition, which is free, as long as your workloads aren't running production. This includes testing, training and user acceptance training.

[zVlad]

Оракла пока конь не валялся. У Оракл ДБА (а их два на миграции задействовано, один на OTG, второй на GoldenGate) нет времени и он ждет курсов по GoldenGate и эксперта из Оракл в помощь. Реально будем начинать в середине декабря.

Давайте по теме скажу. ГолденГейт очень дорогой - Голден не зря в названии. Менеджера похоже получили откат от Оракла. Требуйте свою долю!
Для передачи данных массово люди пользуют sqlloader - он бесплатно идет в составе Оракл РДБМС. И работает он очень быстро.
Если есть деньги, то нужно/правильно использовать ETL - DataStage или Informatica.
Оптимизация Оракла - отдельная задача, но решаемая, там есть встроенный генератор отчетов AWR, где говорится какие запросы жрут диск или ЦПУ.
8ядер и 32гб - ни о чем. У меня в домашнем компе 12 ядер-24 потока и 32 гб памяти. AMD 3900x -$400, RAM- $110.
Хотите нормальной Оракловой производительности - не жалейте памяти и ЦПУ. И смотрите отчеты AWR.

Работа с GoldenGate началась. GG работает иначе чем OTG и быстрее. GG больше жрет ЦПУ мэйнфрэйма и пихает на ремоте сервер быстрее. Вообще эти два способа очень разные и эффект разный.

С Informatica мы работали когда это еще называлось иначе. Сейчас мы работаем с IBM InfoSphere Data Replication. Это лучше чем Informatica и лучше чем GG.
Оптимизация репликации в том смысле как оптимизация произвольных запросов для бизнес логики не имеет смысла поскольку это тупое копирование изначально и потом передача изменений. Ничего больше. На этапе начальной загрузки на стороны исходника это тупой table scan, на таргет стороне чем меньше индексов тем лучше. В дальнейшем на таргет нужен лишь уникальный индекс, больше ничего. Памяти даже для репликации особо не нужнo.

[zVlad]

Данные переливались через 1Gb канал.

За условные 12 часов переливаются все 4ТБ в 4 ядра в виртуалке. Вопрос "как переливали" - остаётся открытым.
...

Ребята на днях переливали две таких таблицы одновременно. получилось 13 часов вместо 12.5. Переливали через Oracle Transparent Gateway.

[Flash-04]

не знаю чего народ на zVad так накинулся. У меня есть кое-какой опыт с Oracle, БД размером около терабайта вызвала нехилую головную боль у наших БД админов. Так оказалось что БД была в составе SIEM, что означало добавление сотен записей в секунду и выполнение постоянно нескольких десятков queries (alerts). В результате получилось, что БД перестала бекапится стандартными средствами Oracle. Бекап просто никогда не заканчивался! В итоге пришлось купить какую-то специализированную карту (непомню что за вендор был), которая позволяла как-то в обход стандартных средств делать с неё слепок. Сервер на котором все это "летало" был очень мощный - HP, что-то около полсотни коров, памяти от пуза, единственно, что диски были не SSD. Потом HP нафиг выкинул Oracle и поставил свой какой-то самопальный БД движок. Проблема ушла

[iDesperado]

не знаю чего народ на zVad так накинулся. У меня есть кое-какой опыт с Oracle, БД размером около терабайта вызвала нехилую головную боль у наших БД админов. Так оказалось что БД была в составе SIEM, что означало добавление сотен записей в секунду и выполнение постоянно нескольких десятков queries (alerts). В результате получилось, что БД перестала бекапится стандартными средствами Oracle. Бекап просто никогда не заканчивался! В итоге пришлось купить какую-то специализированную карту (непомню что за вендор был), которая позволяла как-то в обход стандартных средств делать с неё слепок. Сервер на котором все это "летало" был очень мощный - HP, что-то около полсотни коров, памяти от пуза, единственно, что диски были не SSD. Потом HP нафиг выкинул Oracle и поставил свой какой-то самопальный БД движок. Проблема ушла

да потому, что это детский сад. ну реально, весь мир выкинул нафиг всякие db2, informix, sybase и прочие рсубд. оракл по сути сожрал абсолютно все в финсекторе. все банки, все биржи, все что хоть как-то связано с большими деньгами сидит на оракле. реально кто-то думает, что там не работает бэкап и пара сотен записей в секунду может хотя бы в теории создать сложности ? ну смешно же.
что такое хот бэкап у оракла ? если бэкап делает утилита rman он останавливает запись в датафайлы, копирует их, копирует redo log. все. эта утилита отлажена в начале 90х и она работает. в банке, на бирже, у меня. там нечему сломаться. это оракл. эту технологию каждый день серьезные дядьки тестируют в банках. как и репликацию.
и еще раз, почему серьезные дядьки выкинули db2 и весь финсектор пересадили на оракл ? в первую очередь именно потому, что там такие вещи работают как часы.

[Flash-04]

Да плевать мне на ваши рассуждения. На практике, а не в теории нихрена он не работает нормально с большими БД где идет поток инсертов. Перестают нормально работать репорты, этой же сволочи нужен consistency, то есть он старается сделать временный слепок БД на время репорта. Другое дело что к примеру в SIEM это нафиг не надо, так как в момента создания репорта он уже устарел и это надо иметь ввиду.
А с бекапом я рассказываю реальный случай, у нас весь штат DBA ломал голову что с этой фигнёй делать. Они бы с радостью забили делать бекап, но не могли и кстати хорошо, один раз он таки понадобился.

[Palych]

этой же сволочи нужен consistency, то есть он старается сделать временный слепок БД на время репорта. Другое дело что к примеру в SIEM это нафиг не надо, так как в момента создания репорта он уже устарел и это надо иметь ввиду

Получается что дело не в Oracle было, а в RDBMS как классе?

[Flash-04]

Похоже что да. Но там много чего добавилось.

[iDesperado]

Да плевать мне на ваши рассуждения. На практике, а не в теории нихрена он не работает нормально с большими БД где идет поток инсертов. Перестают нормально работать репорты, этой же сволочи нужен consistency, то есть он старается сделать временный слепок БД на время репорта. Другое дело что к примеру в SIEM это нафиг не надо, так как в момента создания репорта он уже устарел и это надо иметь ввиду.
А с бекапом я рассказываю реальный случай, у нас весь штат DBA ломал голову что с этой фигнёй делать. Они бы с радостью забили делать бекап, но не могли и кстати хорошо, один раз он таки понадобился.

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

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

[Komissar]

мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?

[iDesperado]

мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?

1Tb это вся база, при этом события идеально партиционируется по дате, можно хоть по часам нарезать партиции. т.е. даже если разработчики полные неадекваты и каждый "выполнение постоянно нескольких десятков queries (alerts)" фигачит фуллскан всей партиции - все равно тормозов не добиться, ведь активная партиция столь крошечной бд гарантированно влазит в память целиком.

[Komissar]

мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?

1Tb это вся база, при этом события идеально партиционируется по дате, можно хоть по часам нарезать партиции. т.е. даже если разработчики полные неадекваты и каждый "выполнение постоянно нескольких десятков queries (alerts)" фигачит фуллскан всей партиции - все равно тормозов не добиться, ведь активная партиция столь крошечной бд гарантированно влазит в память целиком.

нет, ну неадекваты среди DBA сумеют и БД из 100000 записей сделать тормозной.

[Flash-04]

мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?

да, причём все Я не DBA ни разу, проблема была сразу эскалирована "куда надо".
Кстати, из воспоминаний, один из пачей Оракла нахрен сломал БД. Это кстати потом было признано официально. Я откатывал апдейт (прибавилось седых волос) и ждал следующего пача с исправлениями.

[Flash-04]

мне тоже удивительно, что были такие проблемы с относительно небольшой (всего 1 Тб) БД, тем более на адекватном железе. Может, ДБА был неопытный?

1Tb это вся база, при этом события идеально партиционируется по дате, можно хоть по часам нарезать партиции. т.е. даже если разработчики полные неадекваты и каждый "выполнение постоянно нескольких десятков queries (alerts)" фигачит фуллскан всей партиции - все равно тормозов не добиться, ведь активная партиция столь крошечной бд гарантированно влазит в память целиком.

мне нравится как вы "все знаете". Там все было сделано по правилам: и БД нарезана по кусочкам и куча оптимизаций, да дофига всего. А в целом работало всё это не очень.
А, вот! из общения с другими их клиентами, летала вся эта хренотень на специальном железе от Оракла/SUN - ZFS. Но стоило оно... мама дорогая... Моя небедная организация не стала бы даже пропозал рассматривать.

[Flash-04]

1Tb это вся база, при этом события идеально партиционируется по дате, можно хоть по часам нарезать партиции. т.е. даже если разработчики полные неадекваты и каждый "выполнение постоянно нескольких десятков queries (alerts)" фигачит фуллскан всей партиции - все равно тормозов не добиться, ведь активная партиция столь крошечной бд гарантированно влазит в память целиком.

HP делал продукт. Им оказалось в итоге легче сделать новый движок "с нуля". Так что не всё так просто.

[zVlad]

Может кто-нибудь знает как управлять значением лимита по CPU time устанавливаемого когда задачи запускаются из ggsci. Оно устанавливает 15 минут и задачи абэдятся по веремени CPU. Native запуск берет время от системы и управляется просто. Это функция setrlimit(). В документации найти не удалось.

[iDesperado]

да, причём все Я не DBA ни разу, проблема была сразу эскалирована "куда надо".
Кстати, из воспоминаний, один из пачей Оракла нахрен сломал БД. Это кстати потом было признано официально. Я откатывал апдейт (прибавилось седых волос) и ждал следующего пача с исправлениями.

в оракле всегда была тьма багов. в мое время у dba было табу ставить первый релиз, можно было ставить 9.2, 10.2, 11.2 - но баги были в обвязке, оптимизаторе и прочей шелухе. ядро всегда у оракла было супер и бэкап/рестор всегда было святое. за 20 лет я видел лишь одну проблему с бэкап/рестор - ошибку на мутной ос от novel. я больше нигде не видел новел, но и там все решилось банальным обновлением версии оракла.
в этом и сила оракла - когда ты наступил на граблю, у тебя есть гарантия, что ты 100501, даже если у тебя ось от novel, о существовании которой ты еще 5 минут назад не подозревал.

мне нравится как вы "все знаете". Там все было сделано по правилам: и БД нарезана по кусочкам и куча оптимизаций, да дофига всего. А в целом работало всё это не очень.
А, вот! из общения с другими их клиентами, летала вся эта хренотень на специальном железе от Оракла/SUN - ZFS. Но стоило оно... мама дорогая... Моя небедная организация не стала бы даже пропозал рассматривать.

и моему работодателю это нравится. и нравится именно потому, что я в курсе в первую очередь об альтернативах. такого рода системы сейчас строят на кафке и спарк, с записью в облако, бывает в hadoop/hdfs. у нас подобного рода система пишет алерты в solr индекс на hadoop. да, сейчас по системам, где не нужны транзакции и согласованный набор, действительно нет особого смысла платить ораклу за каждое ядрышко + партишенинг + стенбай. но. но ! это совершенно не значит, что у оракла могут быть шансы сдохнуть на крошеной бд в 1Т, где замечательно получается партционировать не виликий поток данных.
а так да, под анализ потока данных есть более эффективные и что более важно дешевые фреймворки, даже совсем фанбои оракла это видят. HP в этом плане просто последовали за хайпом и логикой.

[Flash-04]

Вы так и не поняли что дело вовсе не в хайпе. Чтобы вам было понятнее, продукт о котором я говорю - ArcSight. Можете погуглить, почитать, хотя часть ресурсов уже недоступна. Я когда то плотно сидел на форуме где кастомеры обсуждали проблемы и решения продукта. К 5й версии отчётливо появилась проблема, что продукт не масштабируем. При том потоке данных что был у нас, БД стала бутылочным горлышком. Я тогда потратил довольно много времени, чтобы правильно получать и анализировать диагностику, и пришёл к выводу, что основной тормоз на записи данных. Процессоры сервера около половины времени простаивали ожидая когда данные запишутся. Утверждалось что ssd частично решали проблему, производительность увеличивалась, хотя как я отметил максимум достигался только на железе от самого Оракла и допиливании БД напильником под него.
То есть проблема была системная. HP полностью заменила движок БД в 6 версии и выложила большую статью где сравнивала версии по производительности. Новый движок делал в 5(!) раз меньше дисковых операций на одну операцию записи, что позволило использовать и обычные HDD. Мы перешли на 6 версию и с тех пор я забыл про Оракл как страшный сон.

[iDesperado]

Вы так и не поняли что дело вовсе не в хайпе. Чтобы вам было понятнее, продукт о котором я говорю - ArcSight. Можете погуглить, почитать, хотя часть ресурсов уже недоступна. Я когда то плотно сидел на форуме где кастомеры обсуждали проблемы и решения продукта. К 5й версии отчётливо появилась проблема, что продукт не масштабируем. При том потоке данных что был у нас, БД стала бутылочным горлышком. Я тогда потратил довольно много времени, чтобы правильно получать и анализировать диагностику, и пришёл к выводу, что основной тормоз на записи данных. Процессоры сервера около половины времени простаивали ожидая когда данные запишутся. Утверждалось что ssd частично решали проблему, производительность увеличивалась, хотя как я отметил максимум достигался только на железе от самого Оракла и допиливании БД напильником под него.
То есть проблема была системная. HP полностью заменила движок БД в 6 версии и выложила большую статью где сравнивала версии по производительности. Новый движок делал в 5(!) раз меньше дисковых операций на одну операцию записи, что позволило использовать и обычные HDD. Мы перешли на 6 версию и с тех пор я забыл про Оракл как страшный сон.

ну и что вы от меня хотите ? доказать, что у оракла сложности записать аппендом в отдельную партицию монотонно возрастющие записи событий ? ну не докажете, я говорю, вон tpc-c просовывают десятки миллионов сложных транзакций, в том числе и с аптдейтми. десятки миллионов в секунду. понимете. десятки.
если бы вы там чего-то анализировали, вы бы нам рассказали, что индусы из HP сделали не так. проблема была не системная, а в людях, которые явно не писали аппендом поток событий, как это в любом учебнике советуют, а наколхозили что-то совсем кривое, вероятно с кривыми джоинами в процессе записи, с тучей foreign keys. ну такое в кровавом энтерпрайзе сплошь и рядом. но это не отменяет спсобность оракла выдавать миллионы простых tps даже на ноутбучном железе.
еще раз, оракл запросто спсобен петабайты в день писать на HDD, если ты хоть немного соображаешь как оно все в связке с железом работает. в рдбмс при серьезном потоке записи нельзя таблицы обвешивать FK, джоинами и т.п.