На словах "это нужно для 1С:ERP" я было уже хотел закрыть статью, но дочитал и снимаю шляпу перед автором за труд по созданию доклада.
А резюме тут ИМХО простое - Не нужно использовать софт (я про 1С) с той БД для которой он не писался и не будет проблем.
Ну и дисклеймент: Помнится когда-то 1С даже и Oracle поддерживала и я даже пытался запустить сервер-приложений 1С на Linux c Oracle (лет 6-7 назад), но к сожалению даже супер-крутые ораклисты (с 20-ти летним стажем работы с оракл) помучившись и поплевавшись сказали, что никогда 1С не будет работать с Oracle нормально ибо писалась она под другую СУБД. Как говориться - гандон конечно можно натянуть на глобус, но нужно ли это?
А может и делается, но воткнуть везьде буковки ИИ стало модно и молодежно. Скоро у нас ассенизаторы будут с ИИ, предсказывать в какой говно-яме больше непреодолимого гомна.
Да, это реально дает выйгрышь во многих местах. Ну представьте себе что нужно посчитать сумму просрочки по кредиту для 10 млн. клиентов, доя чего гонять огромную кучу данных между бд и приложением если все можно посчитать ч самой базе? Приложение просто вызывает код из бд и все.
А банки никогда и не переведут АБС на Oracle на иную БД. Там же в хранимках вся бизнес-логика, плюсом поставщики АБС все это шифруют. Ну какой банк в здравом уме перейдет с Oracle который 40+ лет пилит БД на решения российких компаний которым от роду 5-10 лет?
Репутационные риски и потери от простоя АБС, а про денежные я умолчу, перекроют все плюшки российких СУБД многократно.
Это не имеет смысла тк для B-Tree индексов fillfactor итак стоит 90, поправьте в статье эту цифру на что-то более реальное.
Совсем не упомянули что fillfactor не влияет на TOAST-таблицы, так что если у Вас много полей содержимое которых лежит в тостах, то профита Вы не получите.
Ну и про отсутствие хоть каких-то тестов умолчу, могли бы сделать банальный pgbench с таблицами на 100GB.
Забыли сказать самое главное про pg_repack - он требует место на диске, причем как правило x3 (место для новой таблицы равное исходной + переливка данных и потом накат изменений нагенерируют кучу WAL'оф).
Для примера я репачил таблицу размером 150GB, на диске было 50GB свободного места, в итоге в облачное DBaaS пришлось увеличить диск на 350GB и это прям впритык. А в оканцове таблица стала 140GB и что мы имеем? Мы стали больше платить за диск, тк ресайз вниз у многих облачных провайдеров не поддерживается.
Так что выводы делайте сами, а стоит ли оно того, платить больше ради копеечной выгоды.
Вот все говорят про оптимизацию ядра БД и прочие свистоперделки. А что про совершенствование инструментов работы с БД? Возмем к примеру pg_dump который до сих пор не умеет адекватно делать дамп с CREATE TABLE IF NOT EXISTS, а сделать дамп чтобы там не было CREATE SCHEMA public? И такого утилита не умеет. В результате чтобы этот дамп восстановить нужно еще его допилить sed/awk - Ну ребята, 21 век на дворе, а тут такое гэ. И смех и грех. Про другие "особенности" того же pg_dump я умолчу. Кстате во многих энтерпрайз форках все эти вещи допилили и довели до ума, но в ванилу никто не спещит добавлять эти удобства.
Что толку от шустрой БД если с ней нельзя нормально и удобно работать?
Любой замок можно открыть, это лишь вопрос времени и цены. Если это сувальдный замок, то конечно меняется весь. Если это какой-то цилиндрический, то кажеться что смены личинки вполне хватит. Поэтому для полной защиты к хорошему замку всегда ставиться сигнализация с гарантированным приездом ГБР в то время на которое конструкция двери и замка позволит задержать грабителя.
Вот в том то и отличие человека от машины - он умеет думать!
Человек поймет это предложение как восклицательное (восклицательный знак это просто символ конца предложения), ведь факториал - это произведение всех натуральных чисел от 1 до n, а тут написано НАЙДИ СУММУ.
А вот что там вычислит нейросеть - это еще вопрос.
У меня у одного чувство что что-то не так? Какой смысл выкладывать цену за минуту если расчет поездки идет за километраж + всякие коэффициенты?
На словах "это нужно для 1С:ERP" я было уже хотел закрыть статью, но дочитал и снимаю шляпу перед автором за труд по созданию доклада.
А резюме тут ИМХО простое - Не нужно использовать софт (я про 1С) с той БД для которой он не писался и не будет проблем.
Ну и дисклеймент: Помнится когда-то 1С даже и Oracle поддерживала и я даже пытался запустить сервер-приложений 1С на Linux c Oracle (лет 6-7 назад), но к сожалению даже супер-крутые ораклисты (с 20-ти летним стажем работы с оракл) помучившись и поплевавшись сказали, что никогда 1С не будет работать с Oracle нормально ибо писалась она под другую СУБД. Как говориться - гандон конечно можно натянуть на глобус, но нужно ли это?
А может и делается, но воткнуть везьде буковки ИИ стало модно и молодежно. Скоро у нас ассенизаторы будут с ИИ, предсказывать в какой говно-яме больше непреодолимого гомна.
Название то какое-то не русское - Elli, а почему не Катюша или Женя?
Postgres Pro с его килер фичами вроде cfs, шардинга в виде biha - это такой же вендор лок как и oracle.
Поэтому мне кажется тут нужно не брать то что модно и молодежно, а исходить из требований бизнеса (заказчика) и архитектуры конкретного приложения.
Да, это реально дает выйгрышь во многих местах. Ну представьте себе что нужно посчитать сумму просрочки по кредиту для 10 млн. клиентов, доя чего гонять огромную кучу данных между бд и приложением если все можно посчитать ч самой базе? Приложение просто вызывает код из бд и все.
Переводят вспомогательные не бизнес-критикал системы.
Я не видел ни одной статьи где черным по белому бы написали, что Мы перевели АБС с oracle на postgres
А банки никогда и не переведут АБС на Oracle на иную БД. Там же в хранимках вся бизнес-логика, плюсом поставщики АБС все это шифруют. Ну какой банк в здравом уме перейдет с Oracle который 40+ лет пилит БД на решения российких компаний которым от роду 5-10 лет?
Репутационные риски и потери от простоя АБС, а про денежные я умолчу, перекроют все плюшки российких СУБД многократно.
>>CREATE INDEX XXX ON YYY WITH (fillfactor = 90);
Это не имеет смысла тк для B-Tree индексов fillfactor итак стоит 90, поправьте в статье эту цифру на что-то более реальное.
Совсем не упомянули что fillfactor не влияет на TOAST-таблицы, так что если у Вас много полей содержимое которых лежит в тостах, то профита Вы не получите.
Ну и про отсутствие хоть каких-то тестов умолчу, могли бы сделать банальный pgbench с таблицами на 100GB.
GSSAPI с Kerberos кажется сложнее, чем OAuth2
Ну и OAuth2 кажется, что это уже стандарт дефакто и очень радует что в 18-й версии появилась такая возможность.
Oracle: память и процессы пользуются особенностями NUMA (NUMA-aware),
SQL Server: soft NUMA,
DB2: полная поддержка NUMA,
MariaDB и PostgreSQL: никакой поддержки NUMA.
Как-то однобоко звучит. А почему класический Oracle MySQL и Percona Service for MySQL обошли? Там то поддержка NUMA есть, причем довольно давно.
Простите, я что-то не заметил. Ну немного цифр в коментах не повредит)
Забыли сказать самое главное про pg_repack - он требует место на диске, причем как правило x3 (место для новой таблицы равное исходной + переливка данных и потом накат изменений нагенерируют кучу WAL'оф).
Для примера я репачил таблицу размером 150GB, на диске было 50GB свободного места, в итоге в облачное DBaaS пришлось увеличить диск на 350GB и это прям впритык. А в оканцове таблица стала 140GB и что мы имеем? Мы стали больше платить за диск, тк ресайз вниз у многих облачных провайдеров не поддерживается.
Так что выводы делайте сами, а стоит ли оно того, платить больше ради копеечной выгоды.
На Postgres Pro Standart встанет или нужен только Enterprise?
Вот все говорят про оптимизацию ядра БД и прочие свистоперделки. А что про совершенствование инструментов работы с БД? Возмем к примеру pg_dump который до сих пор не умеет адекватно делать дамп с CREATE TABLE IF NOT EXISTS, а сделать дамп чтобы там не было CREATE SCHEMA public? И такого утилита не умеет. В результате чтобы этот дамп восстановить нужно еще его допилить sed/awk - Ну ребята, 21 век на дворе, а тут такое гэ. И смех и грех. Про другие "особенности" того же pg_dump я умолчу. Кстате во многих энтерпрайз форках все эти вещи допилили и довели до ума, но в ванилу никто не спещит добавлять эти удобства.
Что толку от шустрой БД если с ней нельзя нормально и удобно работать?
Любой замок можно открыть, это лишь вопрос времени и цены. Если это сувальдный замок, то конечно меняется весь. Если это какой-то цилиндрический, то кажеться что смены личинки вполне хватит. Поэтому для полной защиты к хорошему замку всегда ставиться сигнализация с гарантированным приездом ГБР в то время на которое конструкция двери и замка позволит задержать грабителя.
Как PPEM соотноситься с подходом IaC (Infrastructure as Code) ?
Кажеться, что алерт слишком перегружен информацией (много букаф, я бы сказал просто овердофига).
Имхо алерт должен быть как выстрел - вовремя, четко, кратко и в точку.
Вот в том то и отличие человека от машины - он умеет думать!
Человек поймет это предложение как восклицательное (восклицательный знак это просто символ конца предложения), ведь факториал - это произведение всех натуральных чисел от 1 до n, а тут написано НАЙДИ СУММУ.
А вот что там вычислит нейросеть - это еще вопрос.
Занимательно, но где же фикс в ванилу?