В продолжение темы предыдущего поста. Это видео доклада о запуске системы оформления и изготовления паспортов ГС Мир/ГС ПВДНП. Если кратко то закупка нового оборудования, переписывание системы с x86/DB2 на Эльбрус/Postgres, решение кучи технических вопросов оказалась дешевле чем заплатить за один год поддержки готового решения от IBM. Так что импортозамещение имеет вполне себе практический и экономический смысл.
Видео длинное но довольно интересное.
"переписывание" с DB2 - это охуенно звучит, все уже десять лет как ушли даже самые отсталые...
Единственный плюс - вытаскивание с древней до современной т.к. не заброшено, в остальном почти везде минусы, даже по API.
У всех своя стратегия развития своих продуктов. Но я бы не сказал что DB2 никто не использует
Ну так DB2 полностью описывается "у них всё через жопу". Это даже не оракла уровень изврата...
Я лично ей не пользовался, но судя по видео это классический продукт класса "ынтырпрайз". Дорого, все через жопу, но есть какая-то поддержка и можно писать на коленке, методом в лоб, не загоняясь с оптимизацией. Но она продается и используется даже совместно с 1С
Выглядит как файл, но начиная с 8.3 она работает как все в одном. Т.е. даже в самом простом варианте когда у вас один компьютер и файловая база, то можно открыть базу в тонком клиенте или опубликовать её на вебсервере если он установлен на этом компьютере и работать с базой удаленно через браузер. Так что даже не имея выделенного сервера 1С будет работать по полноценной трехзвенной схеме. Все новые конфигурации по умолчанию работают в режиме тонкого клиента при любом варианте подключения к базе. И похоже что 1С идет к тому чтобы полностью выкинуть толстый клиент, для замены конфигуратора они уже довольно давно пилят 1C:Enterprise Development Tools который основан на Eclipse.
Тут в другое упирается. Транзакционность, надёжность, средства БД, оверхед от полнофайлового доступа итд. Работа через 1С сервер в любом раскладе и так вся с любой реляционкой, так что не показатель(в любом раскладе прослойку делают ВСЕ в энтерпрайзе, ибо права по пользователям БД на объекты БД из зоны софта который использует БД везде кривы и недостаточны, единственное что тянуло адекватно права - MS SQL с доменными на что угодно почти, но там просто хер положили на развитие)
Я говорю про случай когда у тебя магазинчик в котором стоит один компьютер и больше ничего или какая нибудь мелкая фирма где в базе работает 3 человека
sqlite хранит все данные в одном файле и при записи данных весь файл блокируется. В 1С в файловом режиме используется их собственный dbeng8 который может использовать блокировки на уровне таблиц метаданных, это конечно не версионник как Postgres, который блокирует записи таблиц, но все таки он в данном случае лучше чем sqlite.
Ты должен знать уже какое место в иерархии надёжности занимают и эти, и isam и подавно... При том что постгрес или оракл ребута нештатного и не заметят в 99%, полностью автоматом...
В случаях когда 1с применяется в файловом варианте вся надёжность заключается в регулярном копировании базы на какой-нибудь usb hdd.
В большинстве случаев 1С используется без сервера потомучто он не нужен. Это маленькие фирмы с 3-5 рабочими местами, и там никто не будет тратиться на энтерпрайсные заморочки. Даже если ставить все ломанное то железо всеравно надо будет покупать нормальное и платить за настройку тоже не мало. Главное достоинство 1С это её заточенность под наше законодательство, цена и относительно недорогое обслуживание. И конечно масштабируемость, при необходимости её можно завести на кластере серверов и она будет обслуживать сотни клиентских мест.
И по моему опыту работы большинство нештатных ребутов приводить только к повреждению временных файлов которые 1С копирует из базы в свою временную папку, они совсем не критичны потомучто там хранятся кэшированые куски конфигурации.
Ну в такой схеме у тебя вообще всё откатится, а не только текущая транзакция хрен знает за сколько времени, так что тоже обратка не вариант.
Потому что при сбое временные и недозаписавшиеся откатываются. В сложных системах СУБД всё вообще весело и там 100500 механизмов для этого+блочные внутренние, в духе RAW partition вместо файлов напрямую чтобы не зависеть от ОС и кэша, ну и соответственно DIRECT IO даже в файловом виде(целая область - оптимизация скорости/надёжности, БД на журналируемых ФС итд) и там транзакционно зафиксированное 99% сохранится, а тут все последние изменения по времени тупо.
Мы сейчас говорим о базе для трех пользователей? Потому что при серьезных нагрузках обычно делается отдельный сервер приложений 1С и отдельный сервер БД. Причем БД может использовать mssql, oracle, db2 или postgres. И сервер приложений и сервер БД можно засунуть в кластер при желании. 1С хороша тем что её можно использовать на одном компьютере в маленьком магазине, а можно развернуть кластер который будет обслуживать сотни клиентов, и она вполне может составить конкуренцию той же Sap r3
Вот я не могу себе представить сценарий использования когда один пользователь на локальном компьютере создаст на базу нагрузку чтобы там появилась очередь из транзакций, если конечно это не специальное нагрузочное тестирование.
При обычной работе все изменения моментально попадают на диск. И внезапный ребут не причинит в таком режиме базе абсолютно никакого вреда.
С чего ты так решил? Как только происходит закрытие транзакции в коде 1С то все изменения максимально быстро попадают на диск. В sql варианте этого конечно не произойдёт, там физической записью данных на диск управляет sql сервер и скорее всего все данные попадут в кэш, но в файловом варианте все сразу пишется на диск.
В большинстве случаев на офисном компе это одно и тоже. Ты не забывай что это не сервер который хранит все в кэше для оптимизации, это обычный офисный комп тут нет гигантской очереди, мало памяти, и данные из дискового кэша очень быстро попадают на диск.
Из моего опыта я очень редко сталкивался с битыми файловыми базами 1С и обычно это происходило по редкому стечению обстоятельств.
Наоборот. На сервере и с СУБД в 99% используется аппаратный кэш если есть и direct io. На обычном - 100% в RAM кэш принятый.
