1 Все оптимизации включены в серийный дистрибутив PostgreSQL с патчем от 1С.
3 Все временные таблицы участвуют в других SQL запросах, поэтому вынося их на уровень платформы придётся их каждый раз их передавать к СУБД, что лишь ухудшит ситуацию.
4 Билд и исходный можно скачать всем у кого есть доступ к ИТС. Лицензируется по той же лицензии что и оригинальные исходные коды.
Память расходуется на shared_buffers, work_mem и файловый кэш ОС. Для запуска хватило бы и условных 16 ГБ, но при нагрузке диск захлебнётся. Такой сервак обычно ставят как раз для больших нагрузок - это десятки тысяч пользователей 1С, что после пулинга превращается в сотни активных сессий в PostgreSQL.
Я думал использовать готовую, в т.ч. aalib. Но при беглом осмотре показалось что она умеет рендерить только в терминал, т.е. работать как графическое устройство.
В данной статье рендеринг картинки в текст происходит сначала не в терминал, а в строки возвращаемой функцией таблицы. И лишь на клиентской стороне они выводятся в терминал.
Применить aalib можно было бы на клиентской стороне, передавая с сервера не ASCII а пиксели. Но это усложнило бы клиентский код, который хотелось минимизировать, чтобы как можно больше логики было на серверной стороне.
Можно было попробовать адаптировать aalib, но простая своя реализация показалась проще.
Тут DOOM действительно внутри СУБД работает, в самом ядре. И каждая сессия имеет свой инстанс игры, который живёт внутри бэкенда сессии - ни какого "внешнего" подключения игры не происходит.
Теоретически можно было бы даже мультиплеер запилить между разными сессиями и обмен через shared memory бэкендов.
Почти все расширения PostgreSQL реализованы по такому принципу - подгружается библиотека которая реализует какой-то функционал. Это как комплектные из состава contrib, так и большинство внешних - pg_pathman, pg_hint_plan, timescaledb, pg_stat_kcache, postgis.
Технически это возможно, но объём работ уж очень большой получается.
Если рассматривать вариант работы без расширений, то проще взять PL/Python и запустить на нём python порт движка. Кстати, PostgreSQL нативно может следующие языки: PL/pgSQL, PL/Tcl, PL/Perl, PL/Python.
Ещё одна из интересных идей - добавить язык PL/C, который как PL/PGSQL но только С :) И в него уже вставить оригинальные функции на С.
1 Все оптимизации включены в серийный дистрибутив PostgreSQL с патчем от 1С.
3 Все временные таблицы участвуют в других SQL запросах, поэтому вынося их на уровень платформы придётся их каждый раз их передавать к СУБД, что лишь ухудшит ситуацию.
4 Билд и исходный можно скачать всем у кого есть доступ к ИТС. Лицензируется по той же лицензии что и оригинальные исходные коды.
Память расходуется на shared_buffers, work_mem и файловый кэш ОС.
Для запуска хватило бы и условных 16 ГБ, но при нагрузке диск захлебнётся. Такой сервак обычно ставят как раз для больших нагрузок - это десятки тысяч пользователей 1С, что после пулинга превращается в сотни активных сессий в PostgreSQL.
В самом начале статьи:
https://www.youtube.com/watch?v=zdQOoZgB50M
Я думал использовать готовую, в т.ч. aalib. Но при беглом осмотре показалось что она умеет рендерить только в терминал, т.е. работать как графическое устройство.
В данной статье рендеринг картинки в текст происходит сначала не в терминал, а в строки возвращаемой функцией таблицы. И лишь на клиентской стороне они выводятся в терминал.
Применить aalib можно было бы на клиентской стороне, передавая с сервера не ASCII а пиксели. Но это усложнило бы клиентский код, который хотелось минимизировать, чтобы как можно больше логики было на серверной стороне.
Можно было попробовать адаптировать aalib, но простая своя реализация показалась проще.
Ага, помню такую статью - было обидно что он действительно не на самом тесте работал...
Тут DOOM действительно внутри СУБД работает, в самом ядре. И каждая сессия имеет свой инстанс игры, который живёт внутри бэкенда сессии - ни какого "внешнего" подключения игры не происходит.
Теоретически можно было бы даже мультиплеер запилить между разными сессиями и обмен через shared memory бэкендов.
Почти все расширения PostgreSQL реализованы по такому принципу - подгружается библиотека которая реализует какой-то функционал. Это как комплектные из состава contrib, так и большинство внешних - pg_pathman, pg_hint_plan, timescaledb, pg_stat_kcache, postgis.
Технически это возможно, но объём работ уж очень большой получается.
Если рассматривать вариант работы без расширений, то проще взять PL/Python и запустить на нём python порт движка.
Кстати, PostgreSQL нативно может следующие языки: PL/pgSQL, PL/Tcl, PL/Perl, PL/Python.
Ещё одна из интересных идей - добавить язык PL/C, который как PL/PGSQL но только С :)
И в него уже вставить оригинальные функции на С.