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

[vladich]

Да я то вообще на PostgreSQL сижу, такой Oracle для бедных. Принципы работы примерно те же, функционал попроще и бесплатен.
Мне кажется рано или поздно проприетарные базы все же вымрут, хотя и вымирать будут долго...

[vladich]

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

А есть кунштюк которым измеряется это "долгое время"? Долго это сколько?
Что-то не так это что?
И последнее (пока) а как надо писать код чтобы "не происходило ожидание на локах долгое время"?
Можно услышать не шаманские заклинания, а слова специалистов по БД?

Столько чтобы создавать проблемы в вашем приложении?
Вдаваться в абстрактные религиозные споры нет никакого желания если честно. Любые абстрактные ответы на подобные вопросы имеют мало смысла.
В зависимости от приложения, можно длинные запросы оптимизировать, разбивать на части, реструктурировать схему базы, партиционировать ее и т.п.
Если запрос был от фоновой задачи, можно по таймауту его отменять и повторять через некоторое время.
Дофига чего можно делать. Большинство разработчиков приложений плохо понимают базы данных и пишут код абы как, от этого и все проблемы.

[zVlad]

Да я то вообще на PostgreSQL сижу, такой Oracle для бедных. Принципы работы примерно те же, функционал попроще и бесплатен.
Мне кажется рано или поздно проприетарные базы все же вымрут, хотя и вымирать будут долго...

Долго это сколько?
Оракл и ДБ2, по разным оценкам, примерно в одно время оказались и бесконечно раньше, в шкале времени ИТ, раньше Вашего PostgreSQL. Дело даже не в разнице время аннонса (Оракл считает что обьявился раньше ДБ2). Многие БД претендующие на RDBMS были изначально не тем что заявляли. Таблицы данных это еще не реляционные БД.
На сегодня есть только три вендора RDBMS.
Все остальное туфта.
Пропроетарные говорите? Ну-ну, и что же это:
- такое? и
- почему они должны вымереть?

Подскажу. Потому что дерьмо бесплатно. Угадал?
Придумайте другое обьяснение для вымирания ПП БД. Время пошло.

[zVlad]

....

Столько чтобы создавать проблемы в вашем приложении?
Вдаваться в абстрактные религиозные споры нет никакого желания если честно. Любые абстрактные ответы на подобные вопросы имеют мало смысла.
В зависимости от приложения, можно длинные запросы оптимизировать, разбивать на части, реструктурировать схему базы, партиционировать ее и т.п.
Если запрос был от фоновой задачи, можно по таймауту его отменять и повторять через некоторое время.
Дофига чего можно делать. Большинство разработчиков приложений плохо понимают базы данных и пишут код абы как, от этого и все проблемы.

А как Вы пишите? Абы как? Или Вы хорошо "понимаете базы данных".
Я вообще не понимаю как можно писать приложения "плохо понимая БД". Когда я начинал писать приложения у меня не было никакой БД. Но я уже знал как они работают и писал приложения под это понимание. Это было в 80-е. На дворе ???? И Вы говорите "плохо понимают...".

[vladich]

Подскажу. Потому что дерьмо бесплатно. Угадал?
Придумайте другое обьяснение для вымирания ПП БД. Время пошло.

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

[Easbayguy]

Да я то вообще на PostgreSQL сижу, такой Oracle для бедных. Принципы работы примерно те же, функционал попроще и бесплатен.
Мне кажется рано или поздно проприетарные базы все же вымрут, хотя и вымирать будут долго...

У нас как раз переводят с Оракла на Постгрес и МонгоДБ. Уже давно переводят, прикол что мы за Атлас Монго уже платим больше чем за Оракл, за значительно меньшую часть финансового потока.

[vladich]

Да я то вообще на PostgreSQL сижу, такой Oracle для бедных. Принципы работы примерно те же, функционал попроще и бесплатен.
Мне кажется рано или поздно проприетарные базы все же вымрут, хотя и вымирать будут долго...

У нас как раз переводят с Оракла на Постгрес и МонгоДБ. Уже давно переводят, прикол что мы за Атлас Монго уже платим больше чем за Оракл, за значительно меньшую часть финансового потока.

Так Атлас Монго в себя наверное включает клауд хостинг? А Оракл?
Мы за клауд хостинг Постгреса (на самом деле не чистый Постгрес а AWS Aurora) платим сотни тысяч в год, только за кластер для одного сервиса, правда сильно нагруженный, с кросс-региональной репликацией и т.п.
Я если честно без понятия сколько лицензии на Оракл стоят, не интересовался. Предполагаю что в такой конфигурации, на 15 где-то, учитывая реплики, много-ядерных машин лицензия может стоить дороже чем этот самый клауд хостинг. Сомневаюсь что от Оракла будет толк сравнимый со стоимостью этой лицензии.

[iDesperado]

Я если честно без понятия сколько лицензии на Оракл стоят, не интересовался. Предполагаю что в такой конфигурации, на 15 где-то, учитывая реплики, много-ядерных машин лицензия может стоить дороже чем этот самый клауд хостинг. Сомневаюсь что от Оракла будет толк сравнимый со стоимостью этой лицензии.

в отличие от авроры у оракла есть кластер, потому толк будет и кластер на нагрузку существенно меньше потребуется, вот только цена даже сильно меньшего кластера запросто на порядок выше будет.
а по кластеру - у авроры же лишь один узел primary, остальные это read only реплики.

[vladich]

Я если честно без понятия сколько лицензии на Оракл стоят, не интересовался. Предполагаю что в такой конфигурации, на 15 где-то, учитывая реплики, много-ядерных машин лицензия может стоить дороже чем этот самый клауд хостинг. Сомневаюсь что от Оракла будет толк сравнимый со стоимостью этой лицензии.

в отличие от авроры у оракла есть кластер, потому толк будет и кластер на нагрузку существенно меньше потребуется, вот только цена даже сильно меньшего кластера запросто на порядок выше будет.
а по кластеру - у авроры же лишь один узел primary, остальные это read only реплики.

Нам такой вариант подходит хорошо, чтений гораздо больше чем записей. Да и для записей вариант сделать мастер-мастер репликацию вручную тоже есть на крайний случай, так что это не проблема если что.
Поэтому кластер оракла меньше сделать никак не получится. У Авроры зато поддержка локальной и кросс-региональной репликации с очень low latency "из коробки" из-за их storage инфраструктуры.
Не слышал чтобы у Оракла были подобные варианты, хотя может и есть. Это не важно в любом случае, потому что порядок цен будет разный.

[Easbayguy]

Да я то вообще на PostgreSQL сижу, такой Oracle для бедных. Принципы работы примерно те же, функционал попроще и бесплатен.
Мне кажется рано или поздно проприетарные базы все же вымрут, хотя и вымирать будут долго...

У нас как раз переводят с Оракла на Постгрес и МонгоДБ. Уже давно переводят, прикол что мы за Атлас Монго уже платим больше чем за Оракл, за значительно меньшую часть финансового потока.

Так Атлас Монго в себя наверное включает клауд хостинг? А Оракл?
Мы за клауд хостинг Постгреса (на самом деле не чистый Постгрес а AWS Aurora) платим сотни тысяч в год, только за кластер для одного сервиса, правда сильно нагруженный, с кросс-региональной репликацией и т.п.
Я если честно без понятия сколько лицензии на Оракл стоят, не интересовался. Предполагаю что в такой конфигурации, на 15 где-то, учитывая реплики, много-ядерных машин лицензия может стоить дороже чем этот самый клауд хостинг. Сомневаюсь что от Оракла будет толк сравнимый со стоимостью этой лицензии.

Оракл у нас тоже в Амазоне, Oracle RDS. Postgres & mysql тоже в Авроре. Мы как то в свое время сражались, показывая что Аврора по производительности хуже, чем все ето гонять на ec2 instances. Потом плюнули, ну хотите платить больше, нам же легче. Заветные слова,
database as service!

[vladich]

Оракл у нас тоже в Амазоне, Oracle RDS. Postgres & mysql тоже в Авроре. Мы как то в свое время сражались, показывая что Аврора по производительности хуже, чем все ето гонять на ec2 instances. Потом плюнули, ну хотите платить больше, нам же легче. Заветные слова,
database as service!

Postgres Аврора быстрее на запись, потому что там raw сторидж без файловой системы, чтение плюс минус похоже, хотя кеширование слегка более эффективное опять же в авроре.
Основные ее преимущества - это очень быстрая репликация на уровне сториджа и быстрый failover. Ну и между регионами репликация тоже гораздо быстрее чем все делать врукопашную на ec2 инстансах.
Если это все не нужно, то разницы с обычным Postgres RDS мало.

[Easbayguy]

Оракл у нас тоже в Амазоне, Oracle RDS. Postgres & mysql тоже в Авроре. Мы как то в свое время сражались, показывая что Аврора по производительности хуже, чем все ето гонять на ec2 instances. Потом плюнули, ну хотите платить больше, нам же легче. Заветные слова,
database as service!

Postgres Аврора быстрее на запись, потому что там raw сторидж без файловой системы, чтение плюс минус похоже, хотя кеширование слегка более эффективное опять же в авроре.
Основные ее преимущества - это очень быстрая репликация на уровне сториджа и быстрый failover. Ну и между регионами репликация тоже гораздо быстрее чем все делать врукопашную на ec2 инстансах.
Если это все не нужно, то разницы с обычным Postgres RDS мало.

У нас теперь на каждый чих инженера требуют новый кластер, тока успевай ПРы в терраформе делать.

[iDesperado]

Нам такой вариант подходит хорошо, чтений гораздо больше чем записей. Да и для записей вариант сделать мастер-мастер репликацию вручную тоже есть на крайний случай, так что это не проблема если что.
Поэтому кластер оракла меньше сделать никак не получится. У Авроры зато поддержка локальной и кросс-региональной репликации с очень low latency "из коробки" из-за их storage инфраструктуры.
Не слышал чтобы у Оракла были подобные варианты, хотя может и есть. Это не важно в любом случае, потому что порядок цен будет разный.

мастер-мастер реплицация это пересылка dml - самое тормозное, что можно придумать. мягко говоря совсем не так элегантно как оркаловый RAC. по кросс-региональной репликации, в доке пишут что ее нет:
Aurora PostgreSQL DB clusters don't support Aurora Replicas in different Amazon Regions, so you can't use Aurora Replicas for cross-Region replication.
https://docs.amazonaws.cn/en_us/AmazonR ... ation.html

реплицировать сторидж в случае с базой данных смысла мало, т.к. у всех баз данных датафайлы постоянно в инконсистент состоянии, транзакции только запись WAL лог обеспечивают по комиту. по файлам данных уже в бэкграунде расскладываются данные.
да, у оракла испокон веков была фишка physical standby, где пересылается изменения в WAL логе, а standby ноды открыты на чтение.
раз у вас всего одна нода пишет, видать задачка сугубо анилитика, тут оракл вероятно бы заборол гораздо более навороченными вариантами партишенинга и in-memory column store.

Postgres Аврора быстрее на запись, потому что там raw сторидж без файловой системы, чтение плюс минус похоже, хотя кеширование слегка более эффективное опять же в авроре.
Основные ее преимущества - это очень быстрая репликация на уровне сториджа и быстрый failover. Ну и между регионами репликация тоже гораздо быстрее чем все делать врукопашную на ec2 инстансах.
Если это все не нужно, то разницы с обычным Postgres RDS мало.

у оракла есть фишка писать мимо файловой системы на raw партиции, выйгрыш на уровне погрешности 1-2%. реплицировать на уровне сториджа сомнительная фишка для базы, это же транзакции должны по комиту разложить каждый дата блок по дата файлам, врятли кто-то в здравом уме такую палку в колеса субд засунет.

[vladich]

Нам такой вариант подходит хорошо, чтений гораздо больше чем записей. Да и для записей вариант сделать мастер-мастер репликацию вручную тоже есть на крайний случай, так что это не проблема если что.
Поэтому кластер оракла меньше сделать никак не получится. У Авроры зато поддержка локальной и кросс-региональной репликации с очень low latency "из коробки" из-за их storage инфраструктуры.
Не слышал чтобы у Оракла были подобные варианты, хотя может и есть. Это не важно в любом случае, потому что порядок цен будет разный.

мастер-мастер реплицация это пересылка dml - самое тормозное, что можно придумать. мягко говоря совсем не так элегантно как оркаловый RAC. по кросс-региональной репликации, в доке пишут что ее нет:
Aurora PostgreSQL DB clusters don't support Aurora Replicas in different Amazon Regions, so you can't use Aurora Replicas for cross-Region replication.
https://docs.amazonaws.cn/en_us/AmazonR ... ation.html

Вы не то смотрите, смотреть надо здесь: https://aws.amazon.com/rds/aurora/global-database/
Есть Global Database, он позволяет иметь реплицируемые кластеры в нескольких регионах.
А один кластер не умеет реплицировать в другой регион, все правильно.
Про мастер-мастер репликацию - это не поддерживается в Постгрес Авроре (но поддерживается в MySQL Авроре например, который мы не используем), но мы можем организовать это вручную на уровне приложения,
из-за специфики нашего приложения (идемпотентность записи любых данных и независимость от порядка записи) это будет хорошо работать.

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

Э нет, фишка Авроры как раз в том, что репликация делается на уровне сториджа. Фактически все реплики работают с одним и тем же зеркалированным сториджем.
В результате трафик репликации идет не через обычную сеть, а через выделенную SAN подсистему, из-за чего типичная средняя задержка репликации где-то 20-30ms, что на порядок а то и два ниже чем у не-авророского постгреса. Аналогичная история с кросс-региональной репликацией, которая по задержкам примерно такая же как у обычного постгреса внутрирегиональная.

раз у вас всего одна нода пишет, видать задачка сугубо анилитика, тут оракл вероятно бы заборол гораздо более навороченными вариантами партишенинга и in-memory column store.

Нет, задача не сугубо аналитика. Есть туева хуча задач где записей гораздо меньше чем чтений. Поэтому in-memory column store здесь мимо.
А партишенинг Постгрес сам неплохо умеет делать в последних версиях.

Postgres Аврора быстрее на запись, потому что там raw сторидж без файловой системы, чтение плюс минус похоже, хотя кеширование слегка более эффективное опять же в авроре.
Основные ее преимущества - это очень быстрая репликация на уровне сториджа и быстрый failover. Ну и между регионами репликация тоже гораздо быстрее чем все делать врукопашную на ec2 инстансах.
Если это все не нужно, то разницы с обычным Postgres RDS мало.

у оракла есть фишка писать мимо файловой системы на raw партиции, выйгрыш на уровне погрешности 1-2%. реплицировать на уровне сториджа сомнительная фишка для базы, это же транзакции должны по комиту разложить каждый дата блок по дата файлам, врятли кто-то в здравом уме такую палку в колеса субд засунет.

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

[zVlad]

Ребята (особенно vladich-a прошу), пожалуйста, не засерайте тему про уход с мэйнфрэйма всякой чепухой. Откройте другую и пишите там про ваши Авроры/постгресса и Ораклы.
Здесь можно писать только о том что имеет отношение к переходу с ДВ2 на Оракл.

Спасибо за понимание.

Только что закончился очередной аврал связанный с репликацией из Оракла в MS SQL, о котором я писал выше и которое решалось перезагрузкой сервака (Linux в Azure) Оракл.
Попробывали сначала перезапустить сам Оракл. Не помогло. Перезапуск всего сервака вернул репликацию в норму. Сама репликация (source) перезапускалась как часть перезапуска сервака, target вообше не трогали.
Я понимаю что вы ничего конструктивного об этом сказать не сможете. Но, прошу, не превращайте тему в помойку, оставьте мне ее как мой дневник на будущее. Конечно, если есть что сказать по теме то велкам.

[iDesperado]

Э нет, фишка Авроры как раз в том, что репликация делается на уровне сториджа. Фактически все реплики работают с одним и тем же зеркалированным сториджем.
В результате трафик репликации идет не через обычную сеть, а через выделенную SAN подсистему, из-за чего типичная средняя задержка репликации где-то 20-30ms, что на порядок а то и два ниже чем у не-авророского постгреса. Аналогичная история с кросс-региональной репликацией, которая по задержкам примерно такая же как у обычного постгреса внутрирегиональная.

почитал про глобал, они похоже не весь сторидж, а только WAL лог доставляют через нетворк сториджа. т.е. это все тот же physical standby терминами оракла.

Не знаю какой выигрыш у Оракла, у Авроры по сравнению с обычным постгресом выигрыш в десятки процентов на запись. На чтение выигрыша нет.
Почему именно - трудно сказать.

ну учитывая что у вас пишет лишь одна нода, а читает десяток - вот и те самые 1-2%.

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

главный недостаток постгрес все же отсутствие undo лога и тучи лишней писанины при апдейтах на записи с индексами, из-за этого от них uber ушел. после uber, осознав проблему они начали zheap сторидж делать, но что-то уже пару лет маловато новостей на эту тему. может уже и заглохла инициатива.
вобщем я все к тому что у оракла вполне достаточно крутых фишек, а не просто доставка лога, но цена. по такой цене rac и exadata стали не интересны.

[mskmel]

Ребята (особенно vladich-a прошу), пожалуйста, не засерайте тему про уход с мэйнфрэйма всякой чепухой....

Только что закончился очередной аврал связанный с репликацией из Оракла в MS SQL, о котором я писал выше и которое решалось перезагрузкой сервака (Linux в Azure) Оракл.

Вы сами себе противоречите. У вас был MS SQL на МФ в Azure?

С MF за последние 3 года смигрировал не одно приложение, и такой мелкой как 2ТБ ни одной ни было. Контору доят консалтеры. У них задача делать, а не сделать.

[zVlad]

Ребята (особенно vladich-a прошу), пожалуйста, не засерайте тему про уход с мэйнфрэйма всякой чепухой....

Только что закончился очередной аврал связанный с репликацией из Оракла в MS SQL, о котором я писал выше и которое решалось перезагрузкой сервака (Linux в Azure) Оракл.

Вы сами себе противоречите. У вас был MS SQL на МФ в Azure?

С MF за последние 3 года смигрировал не одно приложение, и такой мелкой как 2ТБ ни одной ни было. Контору доят консалтеры. У них задача делать, а не сделать.

Вы говорите что 3 года мигрируете приложения с МФ и в тоже время спрашиваете о MS SQL на МФ в Azure. Вы уверены что говорите о тех МФ про которые говорю я? На МФ у нас использовалась DB2 for zOS. И конечно же МФ не был в Azure.

2 ТБ. Вообще то как мне помнится у нас было порядка 5 ТБ. Но я никогда не придавал особого, сакрального значения размеру данных в БД. Это зависит исключительно от потребностей клиента, от того как тот или иной движок БД хранит данные, используется ли при хранении сжатие данных, и т.п..
У нас на МФ использовалось сжатие данных для больших таблиц.
Что еще интересно было это то что данные с МФ в Оракле оказались минимум в два раза больше.

[iDesperado]

С MF за последние 3 года смигрировал не одно приложение, и такой мелкой как 2ТБ ни одной ни было. Контору доят консалтеры. У них задача делать, а не сделать.

на том МФ все активные данные в кеш 12 гб влазили, видимо тупа писала показания счетчиков за день и все, все остальные терабайты это архив для аудита, куда раз в десятилетие кто-то заглядывает. вот тут я потешался над микроскопичностью нагрузки на i/o
viewtopic.php?f=46&t=212083&p=6752317#p6752317

а по миграции, очевидно, что это компиляция услышанных в коридоре баек, а не реальный проект. на кой такой простой задачке, что крутилось на базе с 12 гб кеша и BP Hit % - Random = 93.3 воротить Oracle с репликацией на MSSQL !? что в обычной бухгалтерской задачи такого, что потребовало такой изврат ? дальше и девелоперы не знают что такое select for update, dba не просто не видят видят, что запросы в локи упираются, но и не в состоянии репликацию настроить. задачу скопровать данные более года решали и так и не решили как я понял, IBM репликатор на МФ заменил Golden Gate, но и он подвисает и требует перегрузки оракла. вообщем концентрация дебилов на квадратный метр выдает, что это компиляция баек, а не что-то реальное.