Отличие конечно же есть. И поэтому писал, что с терминологией сейчас есть проблемы.
В частности я вообще не вижу смысла в визуальном программировании. Все упрется как минимум, в систему контроля версий и merge конфликтов. Как это сделать визуально, а не в plain-code для меня большая загадка.
Но в целом нормальная высокоуровневая система, как эти standalone решения, должна иметь многослойную архитектуру (как, например, стек TCP/IP). Это нужно, чтобы когда на верхнем слое что-то не удается сделать, то можно было бы спустится на уровень ниже, а не падать сразу на написание голового java-кода по сути с нуля.
Я не увидел ни одного комментария вида "о, да точно, вот такого не хватало" в оригинальной статье
Это по той простой причине, что большинство комментаторов не всегда пытаются разобраться в сути проблемы, а оценивают поверхностно. Точно также, как и Вы.
Я не увидел ни одного комментария вида "о, да точно, вот такого не хватало" в оригинальной статье, но вы продолжаете настаивать, что ваш язык лучше
Сейчас речь идет не о языке, а о высокоуровневой архитектуре для построения приложений. Язык вторичен. Чтобы объяснить разницу, важно понимать, что при написании на lsFusion 80% - это декларативный код, а 20% - императивный. Во всех остальных системах - наоборот.
К сожалению, вот так абстрактно объяснить это достаточно тяжело, но чтобы просто понять, ответьте - зачем придумали SQL ? Знаете, кто был его целевой аудиторией (и сейчас не только программисты его используют). Почему не взяли стандартный Cи-подобный синтаксис ? Мой ответ : потому, что он гораздо лучше подходит для конкретной задачи/архитектуры (формирования запросов для реляционной логики). А ваш какой ?
И зачем вообще по-вашему существуют DSL ? Зачем существуют средства для разработки DSL в той же IDEA, если новые языки не нужны ?
Нет, я именно говорю о голой 1С-платформе, на которой делают решения (в 1С-воском простонародье такие решения называются "нетленки"). Называть ERP-системой платформу 1С без конкретной конфигурации (то есть без бизнес-логики вообще) совершенно точно некорректно.
Да, меня тоже впечатляет, что для таких платформ (в частности со своим DSL) нет общепринятого названия. У меня язык не поворачивается назвать тот же 1С - просто фреймворком. Вот Spring - это Java-фреймворк, а 1С - именно платформа. И, на мой взгляд, лучше всего подходит как раз название "low-code платформы".
Еще раз, мы говорим о совершенно разных задачах и предметной области. Я не отрицаю, что Kotlin - хорошая технология для своих задач.
Пока expression trees нет
Странная логика. Сравнивать технологию, которая уже работает годами с тем, чего нет, и неизвестно будет ли когда-либо.
Аналогичные DSL без изобретения языка
Извините, но я не очень понимаю, что значит "DSL без изобретения языка". DSL - это и есть новый язык. Кстати, а что насчет SQL ? Это классический DSL, разработанный под конкретные цели. Или может вместо него надо было использовать Cишный синтаксис ? Напомню, что он создавался для тех же людей, что и low-code платформы.
Просто, видимо, у вас сильная эмоциональная связь с вашим детищем, которая не позволяет объективно его оценивать.
К сожалению, Вы оцениваете все только с точки зрения технического специалиста. Если все-таки рассматривать бизнес-составляющую (скорость, цена, качество), то все становится гораздо интереснее. Именно благодаря скорости/цене/качеству за 5 лет на решения на базе lsFusion перешли 70% рынка крупного ритейла в Беларуси. И клиентам все равно, какие модные или немодные технологии используются. Им важно то, чтобы можно было очень быстро реализовывать в системе их пожелания.
В комментариях к оригинальной статье уже написали "что вы делаете не так"
Когда я спрашивал, про что "мы делаем не так", то я писал, что мы успешно делаем сложные решения на low-code платформе.
Вы пишите на странном велосипеде, который никто кроме вас поддерживать не сможет.
Ряд наших клиентов развили у себя внутреннюю экспертизу по платформе и прекрасно самостоятельно на ней разрабатывают. Плюс многие сторонние люди уже ее используют для решения разных задач.
Не ясна рыночная ниша этого продукта
Та же, что и у платформ 1С, Microsoft Access и прочих.
Если говорить про dsl на jvm-стеке, то в Kotlin прекрасный dsl
Как я уже писал выше - главное не язык, а уровень абстрагирования. У Kotlin'а уровень абстрагирования не сильно выше, чем у Java. А у lsFusion выше даже чем у 1С.
В виде плоских файлов (модулей) в системе контроля версий. В каждом файле может быть как модели данных, так и действия, ограничения и задание интерфейса. Вот пример репозитория. Там все lsf-файлы - это такие модули.
как происходит выкладка на стейджи / прод?
Обычно настраиваем jenkins, который все это собирает. Важно понимать, что конечное приложение - это просто java-программа, к которой подброшены lsf-файлы, написанные на DSL(которые просто должны быть в classpath). Соответственно, обращаться со всем этим делом можно также, как с любым Java приложением. Например, мы активно используем Maven для разбития на разные подпроекты.
нет ли конфликтов логики / моделей при параллельной разработке фичей?
Все резолвится системой контроля версий. В итоге получаются плоские файлы, а при запуске сервера платформа сравнивает предыдущую модель (которая хранится в самой базе) с новой моделью (которая в lsf-файлах) и проводит изменение структуры под новую логику.
насколько просто рефакторить код?
В качестве IDE используеются IntelliJ IDEA со своим плагином под DSL. Соответственно, поддерживается "Find usages", "Go to definition", "Rename" и т.д. Собственно у нас разные люди без проблем разбираются и правят "чужую" логику.
нет ли сложности с входом в разработку, потому как новый DSL это всегда порог вхождения?
Сейчас 90% процентов наших "разработчиков" на DSL никогда до этого не программировали ни на чем (оставшиеся до этого писали на 1С). Те, кто писал на 1С - вообще просто переключились без проблем. Остальных, конечно пришлось поучить основам контроля версий и IDE, но в целом уже через пару недель люди делали реальные задачи (плюс все-таки в платформе много встроенных защит от того, чтобы сильно накосячить).
Именно поэтому я и спрашивал, что Вы считаете low-code платформой. Если исходить из определения wikipedia, то это получается та платформа, в которой решение создается при помощи прямоугольничков, стрелочек и так далее (то есть визуально). Лично мне, как человеку с математической подготовкой, такое определение совсем не нравится. Можно без проблем создать визуальный интерфейс, в котором я буду просто писать программу на С++ при помощи мышки (стрелочек и т.д.). Станет ли от этого Visual Studio low-code платформой - вопрос риторический.
Я к тому, что главное - не визуальность, а уровень абстрагирования платформы. Если мы возьмем концепцию MVC, то понятно, что основная логика кроется в M и C, а не V. И каким образом идет задание логики : при помощи мышки, или в виде кода - не столь принципиально. Например, в той же системе отчетности JasperReports есть два представления отчета : визуальный и в виде XML. С точки зрения интерфейса вы правите отчет в одном месте - автоматически правится в другом. Причем коммитится, естественно, XML-файл.
Если я правильно понял, вы предоставляете функционал для типовых задач розничного бизнеса
Нет, платформа универсальна, и подходит практически для любых B2B решений.
Если вашим клиентам хватает кликов в интерфейсе
Тут есть определенное недопонимание. Вся система задается в виде встроенного высокоуровневого декларативного DSL. Сейчас нет визуального конструктора для него, но создать его не проблема. Другое дело, что я не уверен, что им будет удобно пользоваться. Саму логику программы делают не конечные пользователи, а скорее бизнес-аналитики. Являются ли они разработчиками - вопрос сложный, и мы его постарались описать в этой статье.
все эти клиенты примерно одинаковые и, видимо, не такие большие как может показаться
Они все-таки достаточно сильно отличаются друг от друга (и там не только розница). Насчет величины : около десятка клиентов имеют более 5000 сотрудников. Количество работающих пользователей в системе - от 800 до 1500. Базы данных до 4ТБ. Да, это не Газпром конечно, но и не такие маленькие компании. И главное, что они работают ровно в одной системе с одной базой данных (а не с множеством систем, как во многих крупных компаниях).
Хотелось бы уточнить, а что Вы считаете low-code платформами ? Вот, например, мы делаем решения для розничного бизнеса на базе low-code платформы, которые достаточно сложные, так как закрывают практически все основные процессы таких компаний. И там нет экспоненциального роста сложности. Вот демо (логин и пароль : guest) для оценки сложности. Что мы делаем не так?
Если честно, то не очень понимаю как конкретно эти оптимизации могут ускорить выполнение на порядок по сравнению с PostgreSQL, но все может быть. Но это же легко проверить и показать. Просто делаете SELECT SUM(...) FROM ... GROUP BY ... на PostgreSQL (с предварительно прогретыми буферами) и в Дата акселераторе.
И показываете : вот в PostgreSQL - 10 секунд, а в Дата акселераторе - 1 секунда. Вы же, наверняка, это делали. Просто иначе может оказаться, что свой код то вы оптимизировали, но по итогу он все равно медленнее тех же оптимизаций PostgreSQL (там кстати тоже есть JIT-compiler с использованием LLVM). Не окажется ли, что вы, как всегда, изобретали велосипед ?
В большинстве OLAP реализаций есть инкрементная загрузка, которая "обновляет" предагрегации.
Но в целом, а чем глобальное преимущество Дата акселератора перед асинхронной репликой PostgreSQL, на сервере которого shared_buffers столько, что вся база влазит в память (при необходимости ее можно прогреть) ? Вы проводили какие-нибудь тесты для сравнения ? За счет чего достигается ускорение на порядок (ведь у PostgreSQL в таком случае тоже обращение к диску не идет).
И как решается проблема с целостностью транзакций и БД ? Когда идет синхронизация БД нет ли блокировок на основном сервере и Дата акселераторе ?
уметь испольнять все отчеты, которые работают на поддерживаемых платформой 1С:Предприятие СУБД
То есть я правильно понимаю, что Дата акселератор умеет выполнять все запросы, которые можно выполнить в 1С ?
А на платформе 1С можно делать рекурсивные запросы и оконные функции ?
И можно уточнить, что насчет предагрегаций ? То есть одно дело суммировать что-то на таблице в миллиард записей (пусть и in-memory), а другое дело, когда данные уже преподсчитаны, и расчет идет уже от них, что делает выполнение гораздо быстрее (собственно в чем и смысл OLAP).
А можно уточнить с каким именно стандартом SQL реализована совместимость (SQL-92/99/2003 и т.д.) ?
И насколько полностью поддерживается совместимость со стандартами ? Поддерживаются ли, например, оконные и рекурсивные функции ? Если нет, то каким образом обрабатываются отчеты, которые их используют ?
А после установки PostgreSQL и перед загрузкой, Вы ему хоть настройки памяти поменяли ? А fsync, full_page_writes и прочее не выключали ? Может и размеры wal не меняли, и checkpoint'ы каждые 20 секунд шли ?
Если нет, то зря. Все могло быть значительно быстрее (хотя какие-то параметры возможно скрипт меняет, но я сомневаюсь). Кроме того, интересно посмотреть сам скрипт. Если там сначала создается схема с индексами, а потом INSERT, то тоже все будет гораздо печальнее, чем наоборот.
Очень надеюсь на то, что Google не решит уйти с российского рынка из-за этого штрафа и не прекратит предоставлять услуги российским пользователям.
Насколько я понимаю, сейчас вопрос так не стоит. У Google нет в РФ юридического лица, а все российские платежи (в обе стороны) идут через зарубежные счета. Соответственно, принудительно списать 100 млн долларов власти не могут. То есть власть может либо начать блокировать платежи от рекламодателей и блогерам, либо просто заблокировать Youtube (как я понимаю, основные претензии именно к нему).
У блокировки Youtube есть одна очень интересная особенность. Не секрет, что большинство трафика сейчас - это видео. Но он сильно оптимизирован за счет кэширования видео на локальных серверах. А при блокировке многие будут пытаться обойти эти блокировки через прокси/VPN и так далее, что приведет к большому росту внешнего трафика. И внешние каналы могут просто упасть. Да, будут конечно пытаться каким-то образом резать такой трафик, но проблемы явно будут.
Уже была такая статья, и судя по плюсам многим понравилась. Но не хватает более технической статьи (вроде вот этой, которая с критикой). Такую же, но уже описывающую положительные моменты, было бы интересно почитать.
Довольно странное решение. В сессии кешируются данные, данные могут быть переиспользованы, и это как бы хорошо. Если сессии начинают потреблять много памяти, уменьшаем лимиты памяти на сессии, либо оптимизируем код. Реинициализация сессий приводит к тому, что эффект от кеширования пропадает.
А можете уточнить, о каком именно кэше идет речь ? Shared buffers общий для всех процессов. И про какие лимиты памяти на сессии идет речь ? Work_mem - это лимит даже не на запрос, а одну операцию.
Тут важны детали. Очень странный критерий - банковская система.
Да, это не критерий, конечно же. Тут скорее это критично для операций с распределенными транзакциями. Банковская система - это просто один из наиболее распространенных примеров, когда будет очень плохо, если в одной системе деньги списались, а в другой - нет.
Цель статьи в том, чтобы показать какие настройки мы устанавливаем для своих приложений. Тем самым я хотел показать, что в настройках PostgreSQL нет ничего сложного. И любой новичок, может установить просто параметры как в статье, глубоко не вникая в них. При этом все будет уже работать достаточно эффективно.
Если нужно почитать более подробно про любые параметры, то они хорошо описаны в официальной документации (или на русском языке в postgres pro).
Много раз так делал - никаких проблем не возникало. Именно так переключались между CentOS 8 и CentOS 7 для тестирования. С физической репликой не доводилось настраивать между совсем разными ОС, но если честно не понимаю почему должны быть проблемы.
К сожалению, мы все таки не можем так рисковать. Дело в том, что многие наши клиенты вообще не используют асинхронную реплику для резервирования. И в случае падения базы, можно считать, что целый день очень много людей работали зря. По этой же причине на всякий случай не отключаем и full_page_writes.
Но если есть сервер с асинхронной репликой с такими же характеристиками как и основной (что получается в 2 раза дороже), то я думаю можно для ускорения и nobarrier поставить, и full_page_writes отключить. А если уж совсем рисковать, то вообще вырубить fsync = off.
Отличие конечно же есть. И поэтому писал, что с терминологией сейчас есть проблемы.
В частности я вообще не вижу смысла в визуальном программировании. Все упрется как минимум, в систему контроля версий и merge конфликтов. Как это сделать визуально, а не в plain-code для меня большая загадка.
Но в целом нормальная высокоуровневая система, как эти standalone решения, должна иметь многослойную архитектуру (как, например, стек TCP/IP). Это нужно, чтобы когда на верхнем слое что-то не удается сделать, то можно было бы спустится на уровень ниже, а не падать сразу на написание голового java-кода по сути с нуля.
Это по той простой причине, что большинство комментаторов не всегда пытаются разобраться в сути проблемы, а оценивают поверхностно. Точно также, как и Вы.
Сейчас речь идет не о языке, а о высокоуровневой архитектуре для построения приложений. Язык вторичен. Чтобы объяснить разницу, важно понимать, что при написании на lsFusion 80% - это декларативный код, а 20% - императивный. Во всех остальных системах - наоборот.
К сожалению, вот так абстрактно объяснить это достаточно тяжело, но чтобы просто понять, ответьте - зачем придумали SQL ? Знаете, кто был его целевой аудиторией (и сейчас не только программисты его используют). Почему не взяли стандартный Cи-подобный синтаксис ? Мой ответ : потому, что он гораздо лучше подходит для конкретной задачи/архитектуры (формирования запросов для реляционной логики). А ваш какой ?
И зачем вообще по-вашему существуют DSL ? Зачем существуют средства для разработки DSL в той же IDEA, если новые языки не нужны ?
Нет, я именно говорю о голой 1С-платформе, на которой делают решения (в 1С-воском простонародье такие решения называются "нетленки"). Называть ERP-системой платформу 1С без конкретной конфигурации (то есть без бизнес-логики вообще) совершенно точно некорректно.
Да, меня тоже впечатляет, что для таких платформ (в частности со своим DSL) нет общепринятого названия. У меня язык не поворачивается назвать тот же 1С - просто фреймворком. Вот Spring - это Java-фреймворк, а 1С - именно платформа. И, на мой взгляд, лучше всего подходит как раз название "low-code платформы".
Еще раз, мы говорим о совершенно разных задачах и предметной области. Я не отрицаю, что Kotlin - хорошая технология для своих задач.
Странная логика. Сравнивать технологию, которая уже работает годами с тем, чего нет, и неизвестно будет ли когда-либо.
Извините, но я не очень понимаю, что значит "DSL без изобретения языка". DSL - это и есть новый язык. Кстати, а что насчет SQL ? Это классический DSL, разработанный под конкретные цели. Или может вместо него надо было использовать Cишный синтаксис ? Напомню, что он создавался для тех же людей, что и low-code платформы.
К сожалению, Вы оцениваете все только с точки зрения технического специалиста. Если все-таки рассматривать бизнес-составляющую (скорость, цена, качество), то все становится гораздо интереснее. Именно благодаря скорости/цене/качеству за 5 лет на решения на базе lsFusion перешли 70% рынка крупного ритейла в Беларуси. И клиентам все равно, какие модные или немодные технологии используются. Им важно то, чтобы можно было очень быстро реализовывать в системе их пожелания.
Когда я спрашивал, про что "мы делаем не так", то я писал, что мы успешно делаем сложные решения на low-code платформе.
Ряд наших клиентов развили у себя внутреннюю экспертизу по платформе и прекрасно самостоятельно на ней разрабатывают. Плюс многие сторонние люди уже ее используют для решения разных задач.
Та же, что и у платформ 1С, Microsoft Access и прочих.
Как я уже писал выше - главное не язык, а уровень абстрагирования. У Kotlin'а уровень абстрагирования не сильно выше, чем у Java. А у lsFusion выше даже чем у 1С.
В виде плоских файлов (модулей) в системе контроля версий. В каждом файле может быть как модели данных, так и действия, ограничения и задание интерфейса. Вот пример репозитория. Там все lsf-файлы - это такие модули.
Обычно настраиваем jenkins, который все это собирает. Важно понимать, что конечное приложение - это просто java-программа, к которой подброшены lsf-файлы, написанные на DSL(которые просто должны быть в classpath). Соответственно, обращаться со всем этим делом можно также, как с любым Java приложением. Например, мы активно используем Maven для разбития на разные подпроекты.
Все резолвится системой контроля версий. В итоге получаются плоские файлы, а при запуске сервера платформа сравнивает предыдущую модель (которая хранится в самой базе) с новой моделью (которая в lsf-файлах) и проводит изменение структуры под новую логику.
В качестве IDE используеются IntelliJ IDEA со своим плагином под DSL. Соответственно, поддерживается "Find usages", "Go to definition", "Rename" и т.д. Собственно у нас разные люди без проблем разбираются и правят "чужую" логику.
Сейчас 90% процентов наших "разработчиков" на DSL никогда до этого не программировали ни на чем (оставшиеся до этого писали на 1С). Те, кто писал на 1С - вообще просто переключились без проблем. Остальных, конечно пришлось поучить основам контроля версий и IDE, но в целом уже через пару недель люди делали реальные задачи (плюс все-таки в платформе много встроенных защит от того, чтобы сильно накосячить).
Именно поэтому я и спрашивал, что Вы считаете low-code платформой. Если исходить из определения wikipedia, то это получается та платформа, в которой решение создается при помощи прямоугольничков, стрелочек и так далее (то есть визуально). Лично мне, как человеку с математической подготовкой, такое определение совсем не нравится. Можно без проблем создать визуальный интерфейс, в котором я буду просто писать программу на С++ при помощи мышки (стрелочек и т.д.). Станет ли от этого Visual Studio low-code платформой - вопрос риторический.
Я к тому, что главное - не визуальность, а уровень абстрагирования платформы. Если мы возьмем концепцию MVC, то понятно, что основная логика кроется в M и C, а не V. И каким образом идет задание логики : при помощи мышки, или в виде кода - не столь принципиально. Например, в той же системе отчетности JasperReports есть два представления отчета : визуальный и в виде XML. С точки зрения интерфейса вы правите отчет в одном месте - автоматически правится в другом. Причем коммитится, естественно, XML-файл.
Нет, платформа универсальна, и подходит практически для любых B2B решений.
Тут есть определенное недопонимание. Вся система задается в виде встроенного высокоуровневого декларативного DSL. Сейчас нет визуального конструктора для него, но создать его не проблема. Другое дело, что я не уверен, что им будет удобно пользоваться. Саму логику программы делают не конечные пользователи, а скорее бизнес-аналитики. Являются ли они разработчиками - вопрос сложный, и мы его постарались описать в этой статье.
Они все-таки достаточно сильно отличаются друг от друга (и там не только розница). Насчет величины : около десятка клиентов имеют более 5000 сотрудников. Количество работающих пользователей в системе - от 800 до 1500. Базы данных до 4ТБ. Да, это не Газпром конечно, но и не такие маленькие компании. И главное, что они работают ровно в одной системе с одной базой данных (а не с множеством систем, как во многих крупных компаниях).
Хотелось бы уточнить, а что Вы считаете low-code платформами ? Вот, например, мы делаем решения для розничного бизнеса на базе low-code платформы, которые достаточно сложные, так как закрывают практически все основные процессы таких компаний. И там нет экспоненциального роста сложности. Вот демо (логин и пароль : guest) для оценки сложности. Что мы делаем не так?
Если честно, то не очень понимаю как конкретно эти оптимизации могут ускорить выполнение на порядок по сравнению с PostgreSQL, но все может быть. Но это же легко проверить и показать. Просто делаете SELECT SUM(...) FROM ... GROUP BY ... на PostgreSQL (с предварительно прогретыми буферами) и в Дата акселераторе.
И показываете : вот в PostgreSQL - 10 секунд, а в Дата акселераторе - 1 секунда. Вы же, наверняка, это делали. Просто иначе может оказаться, что свой код то вы оптимизировали, но по итогу он все равно медленнее тех же оптимизаций PostgreSQL (там кстати тоже есть JIT-compiler с использованием LLVM). Не окажется ли, что вы, как всегда, изобретали велосипед ?
В большинстве OLAP реализаций есть инкрементная загрузка, которая "обновляет" предагрегации.
Но в целом, а чем глобальное преимущество Дата акселератора перед асинхронной репликой PostgreSQL, на сервере которого shared_buffers столько, что вся база влазит в память (при необходимости ее можно прогреть) ? Вы проводили какие-нибудь тесты для сравнения ? За счет чего достигается ускорение на порядок (ведь у PostgreSQL в таком случае тоже обращение к диску не идет).
И как решается проблема с целостностью транзакций и БД ? Когда идет синхронизация БД нет ли блокировок на основном сервере и Дата акселераторе ?
То есть я правильно понимаю, что Дата акселератор умеет выполнять все запросы, которые можно выполнить в 1С ?
А на платформе 1С можно делать рекурсивные запросы и оконные функции ?
И можно уточнить, что насчет предагрегаций ? То есть одно дело суммировать что-то на таблице в миллиард записей (пусть и in-memory), а другое дело, когда данные уже преподсчитаны, и расчет идет уже от них, что делает выполнение гораздо быстрее (собственно в чем и смысл OLAP).
А можно уточнить с каким именно стандартом SQL реализована совместимость (SQL-92/99/2003 и т.д.) ?
И насколько полностью поддерживается совместимость со стандартами ? Поддерживаются ли, например, оконные и рекурсивные функции ? Если нет, то каким образом обрабатываются отчеты, которые их используют ?
А после установки PostgreSQL и перед загрузкой, Вы ему хоть настройки памяти поменяли ? А fsync, full_page_writes и прочее не выключали ? Может и размеры wal не меняли, и checkpoint'ы каждые 20 секунд шли ?
Если нет, то зря. Все могло быть значительно быстрее (хотя какие-то параметры возможно скрипт меняет, но я сомневаюсь). Кроме того, интересно посмотреть сам скрипт. Если там сначала создается схема с индексами, а потом INSERT, то тоже все будет гораздо печальнее, чем наоборот.
Насколько я понимаю, сейчас вопрос так не стоит. У Google нет в РФ юридического лица, а все российские платежи (в обе стороны) идут через зарубежные счета. Соответственно, принудительно списать 100 млн долларов власти не могут. То есть власть может либо начать блокировать платежи от рекламодателей и блогерам, либо просто заблокировать Youtube (как я понимаю, основные претензии именно к нему).
У блокировки Youtube есть одна очень интересная особенность. Не секрет, что большинство трафика сейчас - это видео. Но он сильно оптимизирован за счет кэширования видео на локальных серверах. А при блокировке многие будут пытаться обойти эти блокировки через прокси/VPN и так далее, что приведет к большому росту внешнего трафика. И внешние каналы могут просто упасть. Да, будут конечно пытаться каким-то образом резать такой трафик, но проблемы явно будут.
Уже была такая статья, и судя по плюсам многим понравилась. Но не хватает более технической статьи (вроде вот этой, которая с критикой). Такую же, но уже описывающую положительные моменты, было бы интересно почитать.
А можете уточнить, о каком именно кэше идет речь ? Shared buffers общий для всех процессов. И про какие лимиты памяти на сессии идет речь ? Work_mem - это лимит даже не на запрос, а одну операцию.
Да, это не критерий, конечно же. Тут скорее это критично для операций с распределенными транзакциями. Банковская система - это просто один из наиболее распространенных примеров, когда будет очень плохо, если в одной системе деньги списались, а в другой - нет.
Цель статьи в том, чтобы показать какие настройки мы устанавливаем для своих приложений. Тем самым я хотел показать, что в настройках PostgreSQL нет ничего сложного. И любой новичок, может установить просто параметры как в статье, глубоко не вникая в них. При этом все будет уже работать достаточно эффективно.
Если нужно почитать более подробно про любые параметры, то они хорошо описаны в официальной документации (или на русском языке в postgres pro).
Много раз так делал - никаких проблем не возникало. Именно так переключались между CentOS 8 и CentOS 7 для тестирования. С физической репликой не доводилось настраивать между совсем разными ОС, но если честно не понимаю почему должны быть проблемы.
К сожалению, мы все таки не можем так рисковать. Дело в том, что многие наши клиенты вообще не используют асинхронную реплику для резервирования. И в случае падения базы, можно считать, что целый день очень много людей работали зря. По этой же причине на всякий случай не отключаем и full_page_writes.
Но если есть сервер с асинхронной репликой с такими же характеристиками как и основной (что получается в 2 раза дороже), то я думаю можно для ускорения и nobarrier поставить, и full_page_writes отключить. А если уж совсем рисковать, то вообще вырубить fsync = off.