Comments 10
Про OLAP не скажу опыта маловато, но для OLTP (где Read/Write как 1/100) есть еще много проблем....
Начнем "с простого" в блоке реляционной БД "лежит" N записей (включая индексные блоки) и если обращаетесь из нескольких процессов транзакционно к разным данным в блоке - без блокировок (причем в RAM) не обойтись. Т.е. транзакции БД нужно делать как можно "короче", а вот использовать наиболее "легкую в реализации" транзакционную целостность БД в бизнес транзакциях (включающих множество изменений в БД) короткими сделать "часто не возможно" просто по их бизнес логике. Вот и приходится "городить" прикладную логическую транзакционность данных.
Та же EXADATA "по факту" решает проблемы OLTP масштабирования (без партиционирования) скажем не очень идеально...
Что же касается PG (PG ProEE) в плане "сравнения с Oracle" много в интервью озвучено, но есть "не затронутая" проблема "трассировки пользовательской сессии", и есть постепенные "сдвиги" в плане "хинтов запросов" (т.к. "хороший" разработчик прикладного ПО зачастую "понимает и знает" какими данными приложение "манипулирует", "как" и "в каких объемах/соотношениях", ну а стоимостные оценки БД для "тупых разработчиков" даже в Oracle не всегда "оптимально работают").
По поводу трассировки В Oracle использовался event 10046. Ребята из Postgres Pro сделали расширение с аналогичным функционалом pg_upgrade. Работает и с ванилой и с Postgres Pro Попробуйте https://github.com/postgrespro/pg_uprobe
:-) Спасибо посмотрю. Правда поддержка ванильной версии не заявлена, но попробовать наверно можно.
Datadog опередили PgPro
https://github.com/DataDog/pg_tracing
и вдобавок у Datadog расширение сразу отправляет трейсы в OTEL хранилище
RAC обеспечивает одновременно и горизонтальную масштабируемость производительности, и высочайшую доступность на уровне
Ну,.. все таки про RAC надо оговариваться что полноценного горизонтального масштабирования он не обеспечивает, IO нагрузка не масштабируется, gc locks при n+1 нод быстро съедают весь профит.
При том не совсем понятно, почему автор так грезит RAC для postgres, если на первой же страницы PGPro EE заявлен полноценный Симметричный отказоустойчивый кластер (мультимастер) . Как же так ?
:-) Oracle так же много заявлял и заявляет и про RAC и про Exadata. А вот когда дело доходит до нагрузочных тестов конкретного прикладного приложения, и последующих вопросов к их специалистам "а почему собственно по факту ваши заявления не работают?", можно много нового узнать....
RAC - это реальное горизонтальное масштабирование Да, не линейное Говорят, что добавление 2 узла даст не 100% масштабирование, а 70% да и то при правильной настройке, разнесении сервисов и т д Но это масштабирование и по чтению и по ЗАПИСИ Мультимастер - добавление узлов не ускоряет операции записи а замедляет (накладные расходы, блокировки, 3-phase commit и т д Кстати RAC может быть растянутым ММ - в одном ЦОД ММ - решение не для масштабирования, а для нулевого RPO и RTO Ну и по чтению масштабирование, но для этого лучше открытые на чтение реплики
Переход из Oracle в Postgres Pro: не просто смена СУБД, а сдвиг подхода. Интервью с Марком Ривкиным