После года разработки опубликована новая стабильная ветка СУБД PostgreSQL 15. Обновления для новой ветки будут выходить в течение пяти лет до ноября 2027 года...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57914
Единственная и при этом ещё и нормальная база данных.
Я тут слышал, на задачах типа хранить в ней данные мускул с innodb поэффективней будет. А в сыбасе ещё и картинки хранить норм, но это совсем уж ынтерпрайз уровень.
И правда, зачем нам вообще файловая система, если всё можно хранить в бд.
В том и суть, сыбасе оптимизирует процесс и хранит такие данные самостоятельно, не засирая память почём зря. Что касается мускула, то можно было сравнить его в том же nepomuk, насколько я это помню мускул был предпочтительной опцией как раз по причине различий в производительности (но я использовал sqlite, мне норм). Так всё очень зависит от характера использования, что подтверждают и всевозможные агрегаторы.
Integrity? Нее, не слышал
`mtree`? Не, не слышал`ZFS`? - Но, тем более
А вы mtree после каждой транзакции запускаете, блокируя по дороге базу на запись, или по крону надеетесь, что на диске ничего не успело покорёжиться?
при этом нет никакой гарантии, что транзакция не откатилась, либо что-то не упало, файл должен тоже откатиться вместе с транзакцией или наоборот закомиться и восстановиться из лога после паденияFILESTREAM не просто так придумали, но ты же ему ничего не объяснишь, у него же mtree из задницы торчит, и смузи из ушей льется))
> у него же mtree из задницы торчит, и смузи из ушей
> льется))Так ты еще и на мою задницу пялишся оказывается, раз там mtree разглядел?!!!
Ваще караул пацаны-"специалисты" пошли.
Ты, того, с грибами волшебными осторожней, если тебе мерещатся смузи из ушей у других, да еще по интернету...Как отпустит, почитай про транзакционные файловые системы, про рэйды... чтоб не корежилось и самое главное не забудь "по статейкам" найти, где те самые БД данные хранят
> Как отпустит, почитай про транзакционные файловые системыЯ, конечно, профан и может меня уже следует поздравить с разморозкой, но они уже могут в распределенные (двухфазные) транзакции? Ну чтобы, к примеру, в контексте одной глобальной транзакции выполнить транзакции в двух разных БД и одной божественной транзакционной файловой системе? Какой менеджер транзакций это поддерживает, оффтопиковский MTS? Чтобы было еще понятнее - если я на сервере приложений из своей приблуды через менеджер распределенных транзакций начну транзакцию в постгре и проапдейчу таблички, потом в твоей транзакционной ФС создам файлик, а потом в оракле запущу хранимую процедуру в которой произойдет исключение и я на стороне сервер приложений дам команду на роллбэк распределенной транзакции - файлик в твоей транзакционной ФС так же сам собой исчезнет, как и откатятся изменения в постгре и оракле? Мне не придется отдельно ручками его удалять?
apples vs oranges
слилсо, болезный. А мне лет 15 назад в банке надо было из трехзвенки в базе данных транзакционно вместе с другими данными еще и образцы подписей и печатей (картинки) сохранять. Представляю, как бы было интересно, если бы сам ручками отдельные "роллбеки" для "транзакционной ФС" сочинял при роллбеке в БД.
Закусывать полезно, еще раз, - яблоки против апельсинов.
Молоток против Микроскопа...Это разные ИНТРУМЕНТЫ !
> А вы mtree после каждой транзакции запускаете, блокируя по дороге базу на
> запись, или по крону надеетесь, что на диске ничего не успело
> покорёжиться?mtree - это про integrity, для тех "кто не слышал" , а чтоб не корежилось есть copy-on-write от транзакционной ZFS где и положенно храниться блобам, а не в БД, которая предназначена для работы с данными
каким образом логическая целостность базы обеспечивается целостностью файловой системы?а как ты собираешься делать изоляцию транзакций на уровне файловой системы?
и много много всего того в чем ты не разбираешься
какое отношение это имеет к транзакционной безопасности и целостности данных?прочти хотя бы вшивую статейку по СУБД клоун
Включаешь картинки в транзакцию? Видимо на них что-то очень важное. Неужели компромат на царя?
> Включаешь картинки в транзакцию? Видимо на них что-то очень важное. Неужели компромат
> на царя?Скорее просто, - порнуха, чтоб родичи на диске файло не спалили, судя по формату общения самое то, - возрастное.
Например, рентгеновский снимок пациента.
Сперва они картинки в реляционной базе хранят, а потом этими же самыми руками пишут на опеннете комментарии про то, как надо правильно программировать.
Если картинки - часть документа какого-то, почему бы их в БД и не хранить? Тем более, что ни Oracle, ни Postgres не являются только лишь реляционными СУБД. Головняк с картинками, конечно, присутствует определённый (фрагментации пространства внутри бд, раздутие размеров бд), но есть и удобства тоже - не надо отдельно как-то поддерживать транзакционную логику для картинок.
> Головняк с картинками, конечно, присутствует определённый (фрагментации пространства внутри бдТак в отдельный tablespace вынести
Отсканированный образец подписи или печати клиента банка. С ними потом операторы или отдел контроллинга сверяют подписи на клиентских бумажках.
> какое отношение это имеет к транзакционной безопасности и целостности данных?Судя по всему, кроме fat32 в школе больше ничего не учили...
> прочти хотя бы вшивую статейку по СУБД клоун
Вшивые статейки это - для хамов типа тебя, вот ты по ним и учись, чтоб потом обозвать кого нибудь и чуствовать себя понтовым поцанчиком, а нам грешным угодило по университетам учиться... вместо статеек, но боюсь хамам этого не понять
Ты изобрел AS/400 с OS/400. Ну почти. Надо ещё добавить единую адресацию памяти (нет различий между ОЗУ и ПЗУ) и компиляцию в поцессоронезависимый код.
Нет-нет - на рынке это появилось почти на 10 лет раньше жабы.
Вообще-то, любая современная файловая система является специализированной СУБД.
Вы все, наверное, не поверите, но в PG есть функционал эффективного хранения блобов.
https://www.postgresql.org/docs/current/largeobjects.html
Когда отдел разработки не может согласовать с админами где им хранить картинки - это вовсе не значит, что возникла кровавая ынтерпрайзность. Это всего лишь попался некомпетентный продакт-менеджер.
увольте вашего DBA! срочно!
А почему ты до сих пор не смделал свою СУБД?
А почему ты не ездишь на запорожце? Не нравится? А почему ты до сих пор не сделал свой автомобиль?
Очевидно, что ходить пешком полезнее.
Для 99% проектов даже SQLite избыточна.
Базу с вакуумом трудно назвать нормальной. Для большинства задач Перкона лучше.
Так там тоже есть vaccum: https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html
> Так там тоже есть vaccum: https://dev.mysql.com/doc/refman/8.0/en/optimize-table.htmlЭто несопоставимые по накладным расходам (читай, по даунтайму) операции: http://rhaas.blogspot.com/2011/02/mysql-vs-postgresql-part-2...
И это нельзя исправить никакими улучшениями Постгреса, такова его архитектура by design.
> Это несопоставимые по накладным расходам (читай, по даунтайму) операцииВсё верно, ведь optimize table требует эксклюзивную блокировку: "An exclusive table lock is only taken briefly during the prepare phase and the commit phase of the operation" тогда как стандартный vacuum в postgres работает в фоне.
Действительно optimize table несопоставимо хуже, и это нельзя исправить никакими улучшениями, такова его архитектура by design.
Не путай вакуум и автовакуум, невежда. Речь идёт о первом, его надо запускать вручную с даунтаймом, чтобы база не разрасталась как на дрожжах, и ничего подобного в мускуле нет.
Невежда, у тебя в твоей статье написано что вакуум в mysql называется purge, то что он называется по другому не значит что его там нет.
> Невежда, у тебя в твоей статье написано что вакуум в mysql называется
> purge, то что он называется по другому не значит что его
> там нет.Это ты мне говоришь, неуч? В мускуле нет вакуума, требующего даунтайма, как вакуум (не автовакуум) в Постгре. И даже автовакуум в Постгре нагружает базу сильнее, чем пурж в мускуле.
MySQL performs purges *in the background*.
Неуч, вакуум с даунтаймом в мускукле называется optimize table, а автовакуум в постгрес нагружает базу так как его настроишь.PostgreSQL performs autovacuum *in the background*.
> Неуч, вакуум с даунтаймом в мускукле называется optimize table, а автовакуум в
> постгрес нагружает базу так как его настроишь.
> PostgreSQL performs autovacuum *in the background*.Неуч тут это ты, не проецируй. Вот твои собственные слова: "вакуум в mysql называется purge". Проблема в том, что purge это аналог автовакуума, а не вакуума, так что не крутись тут как уж на сковородке -- ты уже показал своё незнание.
Как ни настраивай автовакуум, для освобождения места ему нужно гораздо больше ресурсов, чем мускулу, потому что такова архитектура Постгре. А оптимайз в мускуле нужен редко, в отличие от вакуума, который на базах с высокой активностью нужно делать регулярно даже при включенном автовакууме.
Слово "неуч" ты написал первый, пытаясь своим хамством прикрыть отсутствие знаний. Ты даже не знаешь как база правильно называется про которую пытаешься рассуждать.Функция очистки называется vacuum "There are two variants of the VACUUM command. The first form, known as "lazy vacuum" or just VACUUM" https://github.com/postgres/postgres/blob/master/src/backend...
а автовакуум — это процесс.
Никто vacuum full на базах с высокой активностью не делает, их бы заблокировало.
Я работаю с БД больше, чем ты на свете живёшь, неуч, и не надо мне рассказывать сказки про то, что никто не делает вакуум на базах, которые разрастаются до петабайтов. Постгрес не может нормально работать без регулярного полного вакуума и сопутствующего даунтайма, а мускул может. Точка.
А ничего, что mysql может невзначай целиком упасть в любом треде (например при drop'е временной таблички), попутно покоцав данные? Не умеет сам в функции (и упаси вас двоичныйкод использовать udf)? Да и на петабайтах mysql не вывозит, т.к. не поддерживает Point In Time Recovery в отличии от pg.
про функции в том смысле, что в mysql они весьма бедны.
> А ничего, что mysql может невзначай целиком упасть в любом треде (например
> при drop'е временной таблички), попутно покоцав данные? Не умеет сам в
> функции (и упаси вас двоичныйкод использовать udf)? Да и на петабайтах
> mysql не вывозит, т.к. не поддерживает Point In Time Recovery в
> отличии от pg.это оно?
https://dev.mysql.com/doc/mysql-backup-excerpt/8.0/en/point-...
https://dev.mysql.com/doc/mysql-backup-excerpt/8.0/en/point-...и функции космические нах не нужны в СУБД, перекладывать на базу то, что она не должна делать - плохое решение
ты по вычисляемым столбцам не проиндексируешься должным образом, такие функции имеют смысл разве что для кастомной аггрегации, а логику в базе может писать только вымиращая обезьяна
По поводу:
https://dev.mysql.com/doc/mysql-backup-excerpt/8.0/en/point-...
https://dev.mysql.com/doc/mysql-backup-excerpt/8.0/en/point-...Этот детский сад, на практике поюзайте на базе от десятков TB - быстро осознаете, что эта "реализация" в mysql непредсказуема.
По поводу функций - какое-то помешательство, тотальное у свидетелей горизонтально-масштабируемой бизнес-логики... Так окромя такой бизнес-логики, есть и другие задачи, которые функциями в СУБД решать быстрее, удобнее и эффективнее. Например гекодинг с опорой на PostGIS (прикинь это тоже набор функций, типов, моделей и он даже обновляется) - просто мастхэв и только идиот будет это на питон перепихивать. А так ухли вообще СУБД применять, положите в файл и пишите воткруг всё сами, а лучше вообще ОС напишите сразу с блек-джеком и рест-апи.
Ради интереса решил проверить не растущую на дрожжах базу на мыскле.Итак, есть некая таблица, в которую активно идет INSERT/UPDATE и никакого DELETE. Смотрим размер таблички:
-rw-r----- 1 mysql mysql 260046848 окт 19 12:06 radacct.ibd
автопурж ваш включен и "не нагружает". Запускаем руками OPTIMIZE TABLE, и после 5 минут жевания соплей получаем
-rw-r----- 1 mysql mysql 201326592 окт 19 12:15 radacct.ibd
Да, в эту таблицу в процессе продолжал валиться поток запросов UPDATE/INSERT.
Таки в итоге получаем ~23% ужатия таблицы при ручном OPTIMIZE.
А, да. В случае с точно такой же работой под PG процент ужатия таблицы при ручной вакууме составляет ~10% после автовакуума.
При активном DELETE размер занимаемого таблицей места и там и там не стремится к уменьшению. Ну и добавим ко всему, что массовый DELETE в мыскле это боль, а при наличии репликации это боль-боль, при которой проще грохнуть на реплике базу и тупо перезалить ее из бэкапа примари.
RTFM.https://dev.mysql.com/doc/refman/8.0/en/innodb-purge-configu...
Purge runs on a *periodic* schedule.
> RTFM.
> https://dev.mysql.com/doc/refman/8.0/en/innodb-purge-configu...
> Purge runs on a *periodic* schedule.+ https://www.percona.com/blog/2014/10/17/innodb-transaction-h.../
> Базу с вакуумом трудно назвать нормальнойТоже всегда считал это лютейшей дичью
Дазе с нормальным дизайном вакуум ненужен.
> Дазе с нормальным дизайном вакуум ненужен.Я имел ввиду Базе с нормальным дизайном...
Типа MyISAM?
> Типа MyISAM?не СУБД а базе данных. В курсе что это такое дизайн базы данных? Или ты из тех фулстакеров, на все руки мастеров.
Так ты его отключить можешь, но тогда сам решай проблемы которые решает вакуум
То бишь, не можешь.
Как и отключить purge в mysql.
> Как и отключить purge в mysql.Purge не нагружает базу так сильно как автовакуум, а ручной вакуум в мускуле не нужен, потому что база не пухнет из-за более правильной архитектуры.
Нагрузка от вакуум настраивается и по молчанию он ничего не нагружает, ручной вакуум в мускукле нужен, потому что от массовых delete база пухнет точно так же, так как архитектуры у всех MVCC движков похожи и подразумевают хранение старых туплов иначе они бы не называли MULTIVersion, а понятие правильности архитектуры не бывает в вакууме ;-) понятие «правильности» зависит от требований, у всех MVCC движков есть плюсы и минусы.
Я смотрю, ты уже забыл статью, которую комментировал два часа назад, неуч. Ничего, я буду тыкать тебя в неё носом, пока ты полностью не просветлишься относительно разницы подходов Постгре и мускула, из-за которой оптимизация базы с даунтаймом требуется в мускуле гораздо реже: http://rhaas.blogspot.com/2011/02/mysql-vs-postgresql-part-2...
Ничего не нагружает только у клоунов на локалхосте, которые никогда в жизни прода не видели, вроде тебя.https://stackoverflow.com/questions/54831212/postgresql-auto...
Напротив, нормальная база может быть только с вакуумом, потому что полноценная параллельность и изоляция подразумевает хранение нескольких версий строк (тогда как innodb'шные undo логи - это как раз уродство и лишние копирования на каждый чих), а их неизбежно нужно периодически чистить. Ну да, при этом нужно чтобы у вас транзации не висели бесконечно и да, на некоторых ворклоудов его нужно явно настраивать, но это не rocket science.
У Oracle, например, которая нормальная СУБД, нет вакуума. Есть специальное табличное пространство для целей хранения предыдущих версий данных.
> Oracle ... нормальная СУБДЩаз! Ниразу не нормальная СУБД, в ней просто тонны ньюансов, легаси конструкций и performance-penalty элементов в самых неожиданных местах.
В каком зрелом и сложном продукте это не так? Про легаси конструкции хотелось бы больше подробностей.
А какие БД ты еще знаешь?
(Не троллинг, я просто не знаю) - Какие препятствия есть у постгреса, чтобы его начали использовать по-серьёзному вместо оракла?
Как минимум нет пакетов, невозможно объединять код встроенных процедур.
Пакеты я на гуглил как sql packages и мне выдало ссылку на оракл. А второе для чего надо и как гуглится?
"plpgsql package"https://www.postgresql.org/docs/current/plpgsql-porting.html
https://stackoverflow.com/questions/35043957/whats-the-equiv...
Использовать схемы вместо пакетов это не решение, а какой-то треш. Как работать с 20-50 схемами одновременно, непонятно.
В Oracle для каждого пользователя своя схема, никто не жалуется.
В Oracle пакеты есть. И вот поэтому никто не жалуется.
Да, да, бизнес-логика на процедурах в БД, этот изврат должен подохнуть вместе с ораклом.
к сожалению, пока нет альтенатив oracle. Логике на процедурах БД тоже нет альтернатив, как ни жаль
Вы только на собеседовании этапе системного дизайна это не брякните. Тащить в плохо масштабирующийся shared ресурс бизнес-логику, еще и триггерами это промазывать - отличный способ получить "бутылочное горлышко" и запороть эффективное горизонтальное масштабирование.
Прикинь, окромя бизнес-логики, функции на СУБД могут и для других целей применяться.
Вы сами-то на собеседовании не брякните, что целостность данных будете на стороне сервера приложений обеспечивать. Я бы такого "архитектора" тут же пинками под зад проводил.
А где ещё бизнес-логику писать? - в приложении что ли? (я опять просто хочу разобраться)
На сервере приложений. Классическая трёхзвенка.
Не всегда она применима и уместна. Не бывает универсальных архитектур. Двузвенка, на всякий случай, не менее "классична", чем трёхзвенка. Так, к слову.
Да, бизнес-логику в приложении. Приложение или self-running docker или на сервере приложений в зависимости от технологии.
Заодно получите и легкость unit-тестирования и легкость обновления окружений. Заодно и асинхронное взаимодействие между отдельными приложениями.У система на хранимках есть заметные недостатки:
* работа на хранимках в БД заточена под массовую обработку. И программисты думают так же. Изменения намного дороже и сложнее.
* код тестовых стендов с хранимками через пару-тройку месяцев разработки расходятся с продакшеном.
* очень мало людей могут мыслить массовой обработкой и эффективно писать системы. потому с системой на хранимках попадаешь в зависимость от конкретного человека. найти замену на рынке практически не реально.
* нет CICD, нет возможности запустить конкретную версию системы в контейнере. сложности с unit-testing.
* системы на хранимках не масштабируются горизонтально. нет технологии поставить 10 серверов СУБД и параллельно обрабатывать входящие запросы. для приложений горизонтальное масштабирование работает достаточно просто.Веду проект преобразования инфраструктуры из 130+ систем в современную архитектуру. На таком количестве систем собрали все варианты костылей, проблем и извращений.
К примеру, в одной системе эмулировали MQ через таблицы в базе данных, в другой системе придумали эмулировать MQ через динамическую регистрацию URL куда сервер начинает стучаться по запросу. Гарантированная доставка? - нет, не слышали.
Еще изврат с отсутствием изоляции - несколько систем смотрят в одну и ту же базу.
Но самая жесть с системами написанными полностью на хранимках. Еще хуже, что эти системы напрямую лезут в БД соседей. Получается в соседних системах нельзя поменять структуру таблиц - может тихо отвалиться в где-то в хранимках.
Какие слова гуглить, чтобы понять что тут написано? Есть какие-то книги?
вот чего нагуглилось: habr.com/ru/company/lingualeo/blog/515530/
> Я предложил руководству полностью сменить философию бэкенда: перенести бизнес-логику в базу данных, а саму базу данных MySQL заменить на PostgreSQL.Ну вот тут бизнес в БД пихают.
> Когда мы поделились планами с разработчиками, стало понятно, что команда не готова к изменениям. Большинство людей покинули компанию..Продолжаю читать...
Сорри, я уже олд скул ))
Наверняка вышли более качественные книги. Как минимум появились новые подходы типа микросервисов.И да, если разработчик ни разу сам не делал кусок приложения, не фиксил падения прода, то многие архитектурные подходы выглядят излишними. Берем Agile и фигачим, а если не работает рефакторим. Так работает на малых + простых + не нагруженных системах. Если проектируем отказоустойчивую и масштабируемую систему, с обновлениями без остановки обслуживания пользователей, то архитектуру стоит продумать заранее. =)
> Получается в соседних системах нельзя поменять структуру таблиц - может тихо отвалиться в где-то в хранимках.А вы точно использовали реляционную БД ?
Да, реляционка. И настройка меж серверами, что хранимка из одного сервера может выполнить SELECT из другого.
Разнесли по сервера - типа так посчитали правильнее изолировать системы друг от друга.
У микросервисов такая же проблема, там для её решения обычно используют CDC тесты, тесты можно и в базе выполнять если что :-)
Я спрашивал к тому, что на РСУБД структура меняется очень просто. А если Вам вот прям необходимо сделать какое-то вычурное изменение, всегда на помощь приходят View.
> работа на хранимках в БД заточена под массовую обработкуИз чего это следует?
> код тестовых стендов с хранимками через пару-тройку месяцев разработки расходятся с продакшеном
Почему то же самое не может случиться с трёхзвенкой?
> очень мало людей могут мыслить массовой обработкой и эффективно писать системы
Из чего это следует?
> нет CICD
Как это?
> нет возможности запустить конкретную версию системы в контейнере
Есть, вообще-то. Было бы желание.
> сложности с unit-testing.
Какие, например?
> системы на хранимках не масштабируются горизонтально. нет технологии поставить 10 серверов СУБД и параллельно обрабатывать входящие запросы
Вдогонку к предыдущему посту.
Shared-nothing архитектура? У того же Oracle есть ещё и Real Application Cluster.
Саммари: да - бизнес-логика прикладных систем только в приложении. RTFM современные архитектурные решения.Есть исключение в виде репортинговых систем, где консолидируются и реконсилируются данные из множества разных зачастую не связанных систем. Хорошего решения для такой консолидации нет. Есть набор частных решений. К примеру: есть ETL, есть ELT, есть еще подходы. Где то используется преобразование на уровне потока данных (AirFlow, SSIS, Spark Streaming), где то уже в базе в виде хранимок.
Вася начал какую-то транзакцию, которая противоречит по логике транзакции Пети, начавшем её на другом сервере приложений. Где и как будет проходить контроль целостности и непротиворечивости данных?
Блокировки на уровне сервера приложений. Так например в 1С сделано :))))
На каком из серверов? Мы же говорим о том, что серверов приложений может быть несколько.
> На каком из серверов? Мы же говорим о том, что серверов приложений
> может быть несколько.На любом из этих двух или на третьем. Связь между ними обязательна.
Сначала пытаемся наложить "управляемую блокировку" (та что на уровне приложения). Для этого сервер приложений связывается с менеджером блокировок расположенным либо локально, либо на другом сервере приложений.Дальше всё стандартно - менеджер блокировок возвращает результат что блокировка успешно наложена или что занято и пока ждём.
СУБД в этом процессе никак не участвует.Менеджер блокировок по-сути знает схему БД с которой работает, но ничего не знает о данных.
То есть, в итоге версионник превращается в блокировочника. А если Люся хочет начать при этом непротиворечивую транзакцию, будет ждать, пока блокировка не будет снята? Такое себе решение в плане производительности, за которую, вроде, и боремся.
> То есть, в итоге версионник превращается в блокировочника. А если Люся хочет
> начать при этом непротиворечивую транзакцию, будет ждать, пока блокировка не будет
> снята? Такое себе решение в плане производительности, за которую, вроде, и
> боремся.Да, это блокировочник. А непротиворечивую это какую? Если Петя в транзакции меняет данные по товару "Болты", а Люся по товару "Гайки", то при правильно написанной управляемой блокировке они друг-другу мешать не будут.
А если работаем с одним товаром, то тут прикладная логика может быть разная и сложная (например контроль остатков на складе), так что извольте ждать.Если Люся только читает данные (например отчёт по всем товарам), то управляемые блокировки ей накладывать вообще не надо. На уровне изоляции транзакций read committed (используется в 1С) непротиворечивость считанных данных будет соблюдаться на уровне СУБД если читать их один раз.
Бизнес логика может быть где угодно. Несогласным высылать повестки в военкомат
Меньше платят.
Для ентерпрайза - поддержка, нормальные бекапы, управление через браузер и худо-бедно нормальное восстановление при halt.Это всё на самом деле решаемо - оракл уже достаточно давно не нужен. Постгрес многим софтом поддерживается (но многие расширения, требуют не постгрес), просто к ораклу все привыкли, если спецы, у многих накоплена база знаний.
По самим возможностям Оракл имно уже давно в перде - после text, массивов и jsonb с индексами к ораклу возвращаешься как к недоразумению.
И да. Продавать оракл выгодно партнерам. Партнеры получают просто деньги за воздух.
Можно начать с самого просто ихкоробочного мастер-мастер. А оракла она есть у постгри никогда не будет, там всегда велосипеды сбоку, который использовать страшно.
Закрытый чёрный ящик без поддержки использовать гораздо страшнее.
Нормальные фирмы (не имеющие в своём штате системных программистов, а таких подавляющее большинство) не используют никакую СУБД без техподдержки (какой бы эта СУБД не была - открытой или закрытой).
Если что-то в Postgres сломается, сами, что ли, кодить будете?
Кто в здравом уме будет использовать мастер-мастер?
любой кому нужен шардинг
Хорошо я тебе объясню так сделает тот кому нужно распределённая база и чтобы включил и работает. И пофиг сколько сотрудников сменится, где их найдут. Любой студент с самыми простыми курсами придёт и в случае чего все докрутит или перезапустит и всё просто будет работать. Магия Оракл.С постгрей так сделать не получится.
> и чтобы включил и работает.Так не бывает.
Попробуй тогда оракл. А лучше сравни оракл и постгрю по этому параметру. В том то и дело что всё просто работает.
# apt install oracle
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package oracleОн даже просто не устанавливается.
Oracle Linux + Oracle RDBMS = устанавливается.
Подробности у дяди Ларри :)
1. нет лоббирования, а у oracle есть
2. нет системы сертификации специалистов
3. долгое время не было синхронизации нескольких субд, все делали свои велосипеды
4. если про РФ, то нет систематической подготовки кадров (в вузах вообще все очень плохо в РФ)Ну и не стоит забывать, что opensource это тоже способ сдерживания конкуретнов и хантинга специалистов. На развитие opensource очень сильно влияют корпорации, сдерживая развитие в ключевых направлениях, без которых применение в бизнесе очень ограничено.
> 2. нет системы сертификации специалистовhttps://www.postgrespro.ru/education/cert
Это сравнительно недавно появилось и именно в рамках импортозамещения. Как бы процесс идет, но довольно поздно начат и не сильно форсируется. А так да, простргеспро все основные моменты делает очень правильно, если государство будет помогать и не будет мешать, то со временем они вытяснят oracle из большинства российских проектов.
Вообще не понимаю зачем это делать. Админство как было на уровне "Гоблин! Быстро сделай вот это! Ты виноват что комп не работает идеально!". Пусть сами руководители занимаются рулением инфраструктурой. В сертифицированной хрени есть сертификаты и ответственность на выпускателях какого-нибудь Альт, Астры линукс. Ты скотам доказывать ничего ен обязан. Если это открытое ПО, то и обучение на совести работодателя раз он решил не покупать лицензии. Это днищенские агенты по найму ищут с тоннами подтверждающих документов. Загляни в резюме. Там чуть ли не каждый первый офигеть какой специалист работавший в крупной международной компании с офигеть какими корпоративными наворотами. А в реальности шуты гороховые. Когда айтишники сами на собеседовании спрашивают хрень из википедии и на основании пары тупых вопросов делают вывод об уровне компетенций это сплошь и рядом шиза и покруче чем кажется. Телкам так ты вообще никогда и ничего не докажешь ибо они следуют букве западного подхода к оценке кадров. За 12 тысяч рублей они хотят маститого специалиста всегда - не меньше.
0. Нет многоблочного чтения, а у Oracle есть.
Постгрес нельзя поставить на голое железо без прослоек в виде ФС. Оракл легко ставится на raw partition
https://docs.oracle.com/en/database/oracle/oracle-database/1...>Input/output (I/O) to a raw partition offers approximately a 5% to 10% performance improvement
Ты работал с этими raw-partition ?
АДЪ и ИЗРАИЛЬ - а не работа. Всего за 5% производительности ... (ну бывало и под 7 - но нафик такой профит не нужОн). Ну, и насколько я помню, с 9ки не рекомендуется.
Это делают не для общей производительности, а для скорости ответа от запроса и большей предсказуемости такого запроса, чтобы не было провалов в производительности из-за запуска других процессов. Очень специфические условия.
Ближайшая аналогия это когда для, скажем hft фин компаний, прокладывают оптику, а на пути гора. В обход дешевле и проще. И все таки бьют под неё тонель сокращая путь на несколько километров, общая скорость та же а вот лейтенси чуть меньше. Что позволяет им немного зарабатывать окупая дорогостоящий тонешь.
Если не нужны провалы в производительности и куча бабла - пихай всё в оперативную память ... А с диском пусть общается потихоньку ...
Про raw много чего пишут, но проблем много, а преимуществ с гулькин ... ээээ .... нос ...
1C давно и успешно может использовать его вместо Oracle и MS SQL вполне себе по-серёзному.
Ты это программерам 1с напишите. А то у низ код один и тот же отрабатывает на мс скуле за 15 часов, а на postgres за трое суток.
> Ты это программерам 1с напишите. А то у низ код один и
> тот же отрабатывает на мс скуле за 15 часов, а на
> postgres за трое суток.Хорошая сказка, но брехня. И ты скажи этим "программерам" что Postgres не для виндовозов эникеев. Его держать надо на линуксовом сервере, и параметры под железо настраивать
Есть выход по-проще не использовать никакие постгри.
> Есть выход по-проще не использовать никакие постгри.Ну если для твоих "программеров" поднять сервак на линуксе это непреодолимая проблема, то лежите дальше под мелкософтом пока они полностью вам воздух не перекроют.
Вот тут тесты есть: https://habr.com/ru/company/dataline/blog/691796/> Синтетический многопоточный тест производительности Fragster
> PostgreSQL проигрывает в работе с временными таблицами, однако показывает лучшую производительность при работе с объектами, что суммарно дает одинаковую производительность с MS SQL.
> Тест по методике APDEX – симулирует работу пользователей 1С:Бухгалтерия типовой конфигурации.
> postgres: 97 232 операций, ms sql: 141 782 операций
> на мс скуле за 15 часов, а на postgres за трое суток.Это потому что план разный, заточенный под MSSQL :-)
Подтверждаю.
Не знаю как на 14-15 постгре, но на 13 - 1с работает на 15-20% медленнее (НЕНАСТРОЕННОЙ !!! [без всяких там оптимизаций и shared memory протокола]) MS SQL
Oracle в 2-3 раза быстрее. Если у тебя что то сломается то поддержка Oracle в частном порядке решит твою проблему.
> Oracle в частном порядке решит твою проблему.При условии, что Госдеп ему это внезапно не запретит....
проблемы негров шерифа не волнуют
А негров волнуют.
Тенденция к нерешению твоих проблем саппортом оракакеля где-то с 2014 года в наличии. А сейчас они прямым текстом послали всех и вся. Все уплоченные им за саппорт деньги ессно простили с миром.
> Если у тебя что то сломается то поддержка Oracle в частном порядке решит твою проблему.Это сказки для тех, кто с ней (поддержкой Oracle) дела не имел. #2.71 чуть ниже.
> Oracle в 2-3 раза быстрее.
Что, корректное сравнение делали?
Тут как бы одна малоизвесная фирма потратила несколько лет и малёк денег, чтобы слезть с Oracle'а в пользу Postgres'а. Со второго захода получилось, на нём и живёт. А там нагрузка весьма неслабая.
> А там нагрузка весьма неслабая.В миллионах транзакций это сколько?
> В миллионах транзакций это сколько?Проявите аналитические способности, если это интересно. Не всё же вам на блюдечке выкатывать.
Тем более, что транзакциями меряться --- это детский сад в песочнице подальше от воспитательницы.
Никаких, постгря давно и серьёзно используется вместо оракла. Скорее надо задавать вопрос иначе: зачем для новых проектов использовать оракл?
Пиши правильно, постгрес, там "с" в конце, ты же не пишешь почему-то "оракакл".
>> Пиши правильно, постгрес, там "с" в конце, ты же не пишешь почему-то "оракакл".Что-то странное вы вещаете, милчеловек. Там "в конце" "L", без вариантов...
Там же сначала:
1. Ingres - INteractive Graphics REtrieval System
2. Postgres - POST-inGRES (ингрес, но теперь с нуля и правильно), который ушел в Illustra и закономерно умер.
3. PostgreSQL - вещь на основе Postgres, альтернативная "ветвь эволюции", отличающаяся, в первую очередь, отказом от ингресовского POSTQUEL в пользу SQL. Т.е. POSTGREs-on-SQL, PostgreSQL."L" должна быть, и это принципиально. Потому что Postgres (с "s" на конце) - это POSTQUEL-БД. Та, которую мы все любим - это таки PostgreSQL.
на вскидку:+ легаси
+ много наработок
+ производительность в некоторых аспектах (слухи, разговоры, страхи)
+ лоббизм
+ большие зависимости от plsql
+ много нестандартных фич и технологий
+ большие объемы данных
+ toad
+ прод
+ партиции
+ привычные идиомы, особенно админские
+ документация?
Аналог Oracle RAC есть?
ИМХО, сделали бы упор лучше на производительность в целом и проблему наличия всяких pgbouncer'ов. Самое важное что должна уметь СУБД это переварить как можно больше пользователей/данных на запись/обновление и отдать данные по выборке как можно быстрее.Конструкции всякие это клёво, но данные это первостепенная задача. Молодцы что сделали улучшение скорости. Но это самое главное изменение. Остальное просто лишний шлак. Всякие там алгоритмы сжатия... В итоге все сжатие отключают, чтоб быстрее было. Вот что нужно!
Ну так сделай упор. Или привык, что тебе всё на блюдечке приносят?
Ты же в курсе, как её раздувает? И в памяти, и на диске. Это всё время и задержки. Чем меньше данных читать/писать, тем эффективнее работа. Чем меньше памяти уходит на данные, тем эффективнее можно расходовать этот ресурс (причём, часто накладные расходы от сжатия вообще незначительные, а выгода колоссальная).
>>Самое важное что должна уметь СУБД это переварить как можно больше пользователей/данных на запись/обновление и отдать данные по выборке как можно быстрее.нет. Самое важное это надежное и не противоречивое хранение данных и предсказуемое возвращение результата. Всё остальное это пожелания. Откройте книги по бд, там не будет про скорость ничего.
Те, кому нужна производительность, пользуются in-memory NoSQL. У Постгреса другие задачи и приоритеты. Иди портфель собирай.
Те, кому нужна производительность, просто пользуются структурами в памяти. А бд нужны для оналитики, чтобы потом показать красивую табличку с графиком топ-менеджерам.
С каких пор в команде Postgres появился школьник-аналитик без опыта в продакшене? Эдакий постресовый Песков.
Есть ощущение что pgbouncer и еже с ним считается неким дефолтом, как условно файлуха (filesystem) - не будете же вы без файлухи гонять постгрю и смысла чинить такой дефолт не видят.Справедливости ради, во многих языках есть встроенные пулеры и не горит горит на мелких нагрузках даже без баунсера
Вообще-то сжатие в таких применениях всегда использовалось в первую очередь для ускорения записи на диск в том числе. Даже в тексте новости это написано.
На самом деле - перенос темпов в оперативку - это круто. Не нужно заморачиваться созданием виртуальных дисков в памяти. По-умолчанию снижается нагрузка на SSD, соответственно повышается их надежность.
На докер хабе пока не обновили ((
Так ты и сам можешь это сделать. Впрочем постгря в докере это скорее изврат, разве что для тестов и демок ещё может подойти.
Мистер аноним никогда не писал распределённые системы?
>постгря в докере это скорее извратв докере слонина для того чтобы другие блоатвари в докере её зависимостью подсасывали. нагрузки там обычно небольшие. зато таких инсталляций скорее всего уже намнго больше половины
А потом выйдет релиз у уважаемого спонсора с точно таким же ченджлогом, от которого начлица будут ахать и охать.
> Администратору предоставлена возможность делегирования пользователям отдельных полномочий для изменения определённых параметров конфигурации сервера PostgreSQL.Это по заявкам из managed databases по типу AWS похоже
Обязательно к прочтению всем фанатикам Pg: https://rbranson.medium.com/10-things-i-hate-about-postgresq...
Храни данные в текстовом файле и будет тебе щастье.
А вы, простите, кто?
Тупая тормозная бд. Попробуйте в ней поиск по полям json сделать
json - опция в реляционной субд.
Пробовал, только в постгресе у меня это и получилось сделать так чтобы работало быстро и без отложенной индексации.
Постгрес в некоторых случаях рвёт монгу
Json в базе держать. Первое слово это про тебя.
Ты не совсем прав тут, это может быть вполне оправданно и эффективно для нестабильной схемы, либо каких-то редко доставаемых данных, или же при наличии ссылок на внешние данные, обеспечить консистентность которых в рамках существующих таблиц невозможно. Особенно, в связке с ORM.
Прекрасный инструмент для решения тех задач, для которых он предназначен!
Для задач удвоения ЧСВ тех, кто ее использует.
Неосилятор.
Буду стабильным, андо и пакеты не завезли. Будем ждать :)
Андо и пакеты никому не нужны, а если нужны — используйте базу где они есть :-)
Какое тонкое чувство юмора
Какое глубокое проникновение в суть, такие "фразы" надо выливать в камне.
https://www.cybertec-postgresql.com/en/things-could-be-impro.../
Давай теперь такую же про mysql.
Кондовость. Но постгрешникам нормально, им не привыкать.INSERT ON DUPLICATE KEY UPDATE
И? Что не так?
А ещё в 15-й релиз добавили селектор как относиться к NULL в уникальных индексах.
До сих пор каждый новый NULL был "это другое" (понимать надо).* Я не ДБА, просто так получилось что наступил на эти грабли чуть ли не накануне 15-го релиза.
Главное преимущество оракла - органичный язык pl/sql и куча пакетов от самого Оракла вокруг обычной БД. Главный недостаток оракла - Clob и Blob и их обработка. Главный недостаток postgresql - vacuum, недостаток настолько пртивный, что готов мириться с оракловыми Clob