Только не стоит забывать, что регистры накоплений - это очень частный случай наследования. В случае, если агрегирующая функция будет не простая сумма/максимум/минимум, а более сложная, то эти регистры уже не подойдут. В более сложных случаях в 1С все равно придется все делать ручками. Да, есть еще регистры сведений (где, по сути, реализовано получение последнего значения на дату), но это тоже еще один частный случай.
Мы обычно просто после миграции, на всякий случай, перестраиваем индексы по строкам (благо их немного).
Кстати, еще один момент. Не сталкивались с тем, что в CentOS 8 начинаются какие-то проблемы при работе с большим количеством временных таблиц ? У меня несколько раз при миграции с CentOS 7 на CentOS 8 при большом количестве пользователей и соединений (1000+) висли запросы вида TRUNCATE t131 и ANALYZE t439. К сожалению, не было времени разбираться в причинах из-за жалоб пользователей и приходилось просто откатывать на CentOS 7 обратно.
Работа идет на ванильном PostgreSQL и там нет fast_trunc (да и там логика все-таки подразумевает транзакционность очистки временных таблиц). Единственная идея почему именно на CentOS 8 возникала проблема - это в том, что там как-то по другому реализована работа с файлами, и TRUNCATE тормозит на создании нового файла под временную таблицу на уровне операционной системы из-за того, что в каталоге оказывается под миллион файлов. Причем там был именно xfs, у которого известные проблемы с большим количеством мелких файлов, на ext4, к сожалению, проверить не получилось.
Кстати, а не нарывались на проблему с индексами по строкам, если там есть специфические символы ? Бывало, что если через физическую репликацию перегонять сервер с CentOS 7 и на CentOS 8, то все такие индексы просто начинали работать неправильно. Есть подозрение, что для сравнения строк PostgreSQL использует библиотеки ОС, и там по разному реализовано сравнение в разных ОС для некоторых символов...
Технически все конечно верно, но все-таки важно понимать, что вариантом 0 воспользуется (может воспользоваться) условно 1% населения. Вариантом 1 - 0.1%, 2 - 0.01%. Так вот государству нафиг не упали эти 0.0...01%. Ну будут они ходить на свои "запрещенные" сайты. Никакой угрозы в таком количестве они не представляют. Стратегически/экономически бороться с ними дороже, чем просто забить.
С обходом блокировок - как в том анекдоте, что не нужно бежать быстрее медведя, а нужно бежать быстрее того, кто бежит рядом.
Забыли еще упомянуть важные опции при dump : -j <кол-во потоков> и -f d (формат директорий, без которого -j не сработает). На террабайтных базах без нескольких потоков у вас бэкап будет идти день. А это плохо, так как бэкап - это, естественно, транзакция, так как только за счет MVCC бэкап ничего не блокирует и, в принципе, может идти нормальная работа базы. Однако пока идет бэкап, вакуум работать фактически будет вхолостую, так как нельзя очищать записи после начала транзакции. Соответственно, таблицы будут разрастаться и замедляться работа.
Я постоянно вижу, что специалисты 1С и внедренцы 1С закатывают глаза и требуют 100500 ядер и памяти
Мне вот тоже всегда интересно, чем им помогут ядра и память, когда из-за ошибки статистики PostgreSQL попадает в Nested Loop Left Join с Seq Scan (да пусть даже и индекс скан). Как в скрине ниже. И там дальше сложность 4210*55582. Будет там записей в 10 раз больше, и даже на суперкомпьютере не выполнится этот запрос никогда.
В ваших планах, я вижу как минимум одну странность :
Планируемое количество записей - 1, а реальное - 4210. Естественно, при таких раскладах начинают выбираться не те алгоритмы для дальнейшей обработки (типа Nested Loop Left Join).
Тут или 1С не делает ANALYZE временных таблиц после записи в них, или просто так получается из-за статистики по колонкам. Но в целом сам запрос, который сформировал 1С - очень странный. При таких запросах на нормальных объемах данных там все будет очень сильно тормозить именно из-за нерелевантной статистики. Возможно такие запросы и прокатывают в MSSQL (возможно там перепланирование есть - я не сильно в MSSQL разбираюсь), но вот в PostgreSQL так делать не стоит.
У нас просто есть опыт разработки собственной CRM (у нас есть специфические требования). Мы используем ее только для внутренних целей, постепенно допиливая ее время от времени.
Мы ее делали на lsFusion. Я посмотрел только что по timetracking, на первую версию до внедрения ушло где-то 4 человеко/месяца. Там правда и джун работал (большую часть), и немного senior. В сумме на разработку ушло где-то 600К.
Одной из целей при этом, конечно, было обучение джуна, чтобы сразу не пускать его на разработку для клиентов. Так что наш случай, не совсем показательный (плюс мы все-таки IT компания). С другой стороны, готовая CRM нам явно бы не подошла (есть очень специфические требования по расчету стоимости услуг с учетом курсов и многих внутренних договоренностей).
Вот собственно демка того, что у нас получилось (а также ссылка на Github).
Для полноты картины надо было еще к 1Совцам обратиться. Ни в коем случае, не говорю, что именно на 1С надо было делать, и платформа 1С - очень хорошая. Однако, без этого исследование - явно не полное.
Бухгалтерию и ЗУП действительно не имеет особого экономического смысла вообще на чем-то переделывать. Там больше про законодательство, чем про разработку. И главное, что если там что-то сломается даже на пару дней, то особо больших потерь не будет. А вот когда останавливаются основные бизнес-процессы в компании - вот это уже проблемы.
Я конечно ни в коем случае не поддерживаю то, что делает 1С, но идея с исками всех к 1С конечно интересная. Если они вдруг все пройдут в судах, и 1С попадет на миллиардные штрафы, то дальше есть 2 варианта событий :
1С выплачивает штрафы, а деньги на это берет за счет увеличения цен. В итоге штрафы оплатят сами же клиенты 1С. А все потому, что 1С - монополист, и конкурентов особо не видно.
1С банкротится, и тогда большинство продуктов остаются без поддержки и разработки от вендора (франчи не смогут дорабатывать платформу). Вариант не сильно лучше для клиентов 1С.
Есть конечно третий вариант, что штрафы оплатятся с личных денег Нуралиева/прибыли, но если штрафы начнут проходить в судах, то там вряд ли хватит денег на огромный объем.
К сожалению, при экстренном выпуске обновлений, исправляющих проблему запуска программ системы «1С:Предприятие», из-за срочности выпуска в некоторые версии платформы были привнесены ошибки
Хорошее выражение. Надо будет дополнить словарь к "хлопкам", "отрицательному росту" и т.д.
То есть вы на такое время и деньги тратить не хотите, но надеетесь что кто-то за вас это сделает? И ещё и бесплатно. Ну-ну...
Не. Опен-сорс как таковой как раз таки раз вендоров обычно не имеет. Крупные вещи с официальными вендорами это скорее исключение.
Ну Java / .Net / MySQL / PostgreSQL и много чего другого бесплатно, и разрабатывались официальными вендорами. Почему исключение ? Есть много способов монетизации opeb-source решений.
Мы, например, на платформе разрабатываем коммерческие решения, и за счет этого финансируем разработку open-source платформы. Некоторые работают через инвестиции и т.д.
Если речь идёт о чём-то крупном, да ещё и с поддержкой от официальных вендоров, то это обычно не сильно дешевле чем оплатить не опен-сорсный аналог. Если вообще дешевле
Плата за поддержку - это плата за услуги. С точки зрения себестоимости поддержка коммерческого продукта и open-source одинаково. Если конечно не идет перекрестного субсидирования, когда деньги за поддержку идут на разработку. Какой процент пользователей обращается в саппорт того же Microsoft ?
Ну тут либо платить. Либо самим писать. Либо смириться.
Или найти open-source решение с таким функционалом. Как lsFusion по отношению к 1С.
Это если опенсорсное решение имеет вендора. И если вы себе может позволить платить за поддержку "от RedHаt"
Опен-сорс решения как правило имеют вендоров. Их все-таки кто-то разрабатывает, если речь идет о чем-то крупном. Например, Java от Sun (а теперь Oracle). PostgreSQL хоть и не имеет одного вендора, но поддержку, например, оказывает некоторые из разработчиков (Postgres Pro).
Что касается стоимости, то и качество поддержки Redhat лучше дяди Васи. И тут же пишут, что корпорации деньги не считают :)
А что делать не корпорациям, типа нас, которым нужен функционал типа слэк (с каналами и thread'ами) ? Искали как раз open-source, как lsFusion, но так и не нашли с таким же функционалом.
казус в том что поддержку 1С найти не проблема, а поддержку опенсорсного решения
В любом случае, поддержка от вендора опенсорсного решения (например, от RedHat) будет лучше чем поддержка 1С от дяди Васи, не ?
разработчикам нужны заказчики с деньгами, а их нет
Тоже самое, что сказать разработчикам нужны заказчики вроде Газпрома, а остальные нищеброды не нужны. С деньгами - понятие относительное.
Например, Вы сделали небольшое приложение, с небольшим функционалом, но которое вовлекает большое количество пользователей. При этом стоимость клиентской лицензии - это уже проблема, из-за которой это приложение уже экономически невыгодно.
Вот, к примеру, мы используем slack для коммьюнити. Там на каждого пользователя для тарифа Pro - 7,25$/в месяц. Вроде бы и относительно небольшая сумма, и можно было бы платить, но когда несколько сотен пользователей, то цена уже не окупает преимущества, и использовать Pro версию в данном случае бессмысленно.
Только не стоит забывать, что регистры накоплений - это очень частный случай наследования. В случае, если агрегирующая функция будет не простая сумма/максимум/минимум, а более сложная, то эти регистры уже не подойдут. В более сложных случаях в 1С все равно придется все делать ручками.
Да, есть еще регистры сведений (где, по сути, реализовано получение последнего значения на дату), но это тоже еще один частный случай.
Мы обычно просто после миграции, на всякий случай, перестраиваем индексы по строкам (благо их немного).
Кстати, еще один момент. Не сталкивались с тем, что в CentOS 8 начинаются какие-то проблемы при работе с большим количеством временных таблиц ? У меня несколько раз при миграции с CentOS 7 на CentOS 8 при большом количестве пользователей и соединений (1000+) висли запросы вида TRUNCATE t131 и ANALYZE t439. К сожалению, не было времени разбираться в причинах из-за жалоб пользователей и приходилось просто откатывать на CentOS 7 обратно.
Работа идет на ванильном PostgreSQL и там нет fast_trunc (да и там логика все-таки подразумевает транзакционность очистки временных таблиц). Единственная идея почему именно на CentOS 8 возникала проблема - это в том, что там как-то по другому реализована работа с файлами, и TRUNCATE тормозит на создании нового файла под временную таблицу на уровне операционной системы из-за того, что в каталоге оказывается под миллион файлов. Причем там был именно xfs, у которого известные проблемы с большим количеством мелких файлов, на ext4, к сожалению, проверить не получилось.
Кстати, а не нарывались на проблему с индексами по строкам, если там есть специфические символы ?
Бывало, что если через физическую репликацию перегонять сервер с CentOS 7 и на CentOS 8, то все такие индексы просто начинали работать неправильно. Есть подозрение, что для сравнения строк PostgreSQL использует библиотеки ОС, и там по разному реализовано сравнение в разных ОС для некоторых символов...
Технически все конечно верно, но все-таки важно понимать, что вариантом 0 воспользуется (может воспользоваться) условно 1% населения. Вариантом 1 - 0.1%, 2 - 0.01%. Так вот государству нафиг не упали эти 0.0...01%. Ну будут они ходить на свои "запрещенные" сайты. Никакой угрозы в таком количестве они не представляют. Стратегически/экономически бороться с ними дороже, чем просто забить.
С обходом блокировок - как в том анекдоте, что не нужно бежать быстрее медведя, а нужно бежать быстрее того, кто бежит рядом.
Забыли еще упомянуть важные опции при dump : -j <кол-во потоков> и -f d (формат директорий, без которого -j не сработает). На террабайтных базах без нескольких потоков у вас бэкап будет идти день. А это плохо, так как бэкап - это, естественно, транзакция, так как только за счет MVCC бэкап ничего не блокирует и, в принципе, может идти нормальная работа базы. Однако пока идет бэкап, вакуум работать фактически будет вхолостую, так как нельзя очищать записи после начала транзакции. Соответственно, таблицы будут разрастаться и замедляться работа.
Мне вот тоже всегда интересно, чем им помогут ядра и память, когда из-за ошибки статистики PostgreSQL попадает в Nested Loop Left Join с Seq Scan (да пусть даже и индекс скан). Как в скрине ниже. И там дальше сложность 4210*55582. Будет там записей в 10 раз больше, и даже на суперкомпьютере не выполнится этот запрос никогда.
В ваших планах, я вижу как минимум одну странность :
Планируемое количество записей - 1, а реальное - 4210. Естественно, при таких раскладах начинают выбираться не те алгоритмы для дальнейшей обработки (типа Nested Loop Left Join).
Тут или 1С не делает ANALYZE временных таблиц после записи в них, или просто так получается из-за статистики по колонкам. Но в целом сам запрос, который сформировал 1С - очень странный. При таких запросах на нормальных объемах данных там все будет очень сильно тормозить именно из-за нерелевантной статистики. Возможно такие запросы и прокатывают в MSSQL (возможно там перепланирование есть - я не сильно в MSSQL разбираюсь), но вот в PostgreSQL так делать не стоит.
А какой Вы стэк технологий выбрали ?
У нас просто есть опыт разработки собственной CRM (у нас есть специфические требования). Мы используем ее только для внутренних целей, постепенно допиливая ее время от времени.
Мы ее делали на lsFusion. Я посмотрел только что по timetracking, на первую версию до внедрения ушло где-то 4 человеко/месяца. Там правда и джун работал (большую часть), и немного senior. В сумме на разработку ушло где-то 600К.
Одной из целей при этом, конечно, было обучение джуна, чтобы сразу не пускать его на разработку для клиентов. Так что наш случай, не совсем показательный (плюс мы все-таки IT компания). С другой стороны, готовая CRM нам явно бы не подошла (есть очень специфические требования по расчету стоимости услуг с учетом курсов и многих внутренних договоренностей).
Вот собственно демка того, что у нас получилось (а также ссылка на Github).
Для полноты картины надо было еще к 1Совцам обратиться. Ни в коем случае, не говорю, что именно на 1С надо было делать, и платформа 1С - очень хорошая. Однако, без этого исследование - явно не полное.
Бухгалтерию и ЗУП действительно не имеет особого экономического смысла вообще на чем-то переделывать. Там больше про законодательство, чем про разработку. И главное, что если там что-то сломается даже на пару дней, то особо больших потерь не будет. А вот когда останавливаются основные бизнес-процессы в компании - вот это уже проблемы.
Я конечно ни в коем случае не поддерживаю то, что делает 1С, но идея с исками всех к 1С конечно интересная. Если они вдруг все пройдут в судах, и 1С попадет на миллиардные штрафы, то дальше есть 2 варианта событий :
1С выплачивает штрафы, а деньги на это берет за счет увеличения цен. В итоге штрафы оплатят сами же клиенты 1С. А все потому, что 1С - монополист, и конкурентов особо не видно.
1С банкротится, и тогда большинство продуктов остаются без поддержки и разработки от вендора (франчи не смогут дорабатывать платформу). Вариант не сильно лучше для клиентов 1С.
Есть конечно третий вариант, что штрафы оплатятся с личных денег Нуралиева/прибыли, но если штрафы начнут проходить в судах, то там вряд ли хватит денег на огромный объем.
Главная проблема в том, а как дорабатывать в SaaS под себя ?
Хорошее выражение. Надо будет дополнить словарь к "хлопкам", "отрицательному росту" и т.д.
Ну Java / .Net / MySQL / PostgreSQL и много чего другого бесплатно, и разрабатывались официальными вендорами. Почему исключение ? Есть много способов монетизации opeb-source решений.
Мы, например, на платформе разрабатываем коммерческие решения, и за счет этого финансируем разработку open-source платформы. Некоторые работают через инвестиции и т.д.
Плата за поддержку - это плата за услуги. С точки зрения себестоимости поддержка коммерческого продукта и open-source одинаково. Если конечно не идет перекрестного субсидирования, когда деньги за поддержку идут на разработку. Какой процент пользователей обращается в саппорт того же Microsoft ?
Или найти open-source решение с таким функционалом. Как lsFusion по отношению к 1С.
Опен-сорс решения как правило имеют вендоров. Их все-таки кто-то разрабатывает, если речь идет о чем-то крупном. Например, Java от Sun (а теперь Oracle). PostgreSQL хоть и не имеет одного вендора, но поддержку, например, оказывает некоторые из разработчиков (Postgres Pro).
Что касается стоимости, то и качество поддержки Redhat лучше дяди Васи. И тут же пишут, что корпорации деньги не считают :)
А что делать не корпорациям, типа нас, которым нужен функционал типа слэк (с каналами и thread'ами) ? Искали как раз open-source, как lsFusion, но так и не нашли с таким же функционалом.
В любом случае, поддержка от вендора опенсорсного решения (например, от RedHat) будет лучше чем поддержка 1С от дяди Васи, не ?
Тоже самое, что сказать разработчикам нужны заказчики вроде Газпрома, а остальные нищеброды не нужны. С деньгами - понятие относительное.
Например, Вы сделали небольшое приложение, с небольшим функционалом, но которое вовлекает большое количество пользователей. При этом стоимость клиентской лицензии - это уже проблема, из-за которой это приложение уже экономически невыгодно.
Вот, к примеру, мы используем slack для коммьюнити. Там на каждого пользователя для тарифа Pro - 7,25$/в месяц. Вроде бы и относительно небольшая сумма, и можно было бы платить, но когда несколько сотен пользователей, то цена уже не окупает преимущества, и использовать Pro версию в данном случае бессмысленно.
Так я специально указал, что речь идет о платформе. Платформа пользователям конечно же не нужна, а вот разработчикам нужна.
Речь идет про платформу. Бесплатную. Например, писать нетленки на ней вместо 1С. А под ключ с саппортом есть решение для розницы.
Что касается open-source платформы, то уже есть.