>> почему этот вопрос каждый раз задают снова и снова
Потому что цены на порядок отличаются. Зачем читать серию статей, если бюджет к железу и близко не лежал?
Конечно же, специализированные области нуждаются в middleware. Только на 100тыс компаний налогоплательщиков хорошо если 100 занимаются чем-то вроде картографии. Большинство торгуют, хранят, производят. И 95% задач — учет денег, товаров и труда. Всякая «опердень», одним словом -)
Но ИТ специалисты из этих 100тыс обычных компаний ходят на конференции и слушают о том, как mail.ru делает бигдату, как кто-то на монге построил международный проект по лайканью котиков и т.д. А потом с горящими глазами возвращаются на свои рабочие места и начинают напяливать монгу на складское хранение, писать собственные сервера приложений на CPP, шардировать базу на 20 000 клиентов, в три слоя кешировать поиск на жалком сайте, потому что ORM генерит sql запросы на 500 строк и т.д.
Но нет нужды так делать в 99.99% компаний. Вот об этом мой доклад.
А какой это бизнес, для которого бизнес-логика быстрее работает, если все данные вынимаются наружу?
По моему опыту, для оперативной деятельности предприятия, которое занимается торговлей и производством, не нужны сложные алгоритмы. Работа финансов, склада и пр — обычная арифметика.
Для аналитики да, нужны внешние решения. Обработка изображений тоже снаружи. Но это уже не бизнес-логика.
В транскрипте это легко пропустить, а в докладе я несколько раз повторял «мы небольшой бизнес», «у нас маленькая команда». Суть в том, что если вы не планируете перерасти Авито, можно не бояться такого решения. Мы не планируем.
Еще нужно быть внимательным к выдаче сессий из пула. В любом инициализированном соединении будут временные таблицы, prepared query, переменные типа search_path и т.д.
Для этого (и для безопасности) pgBouncer создает пулы per user.
Найти можно, но где гарантии, что он не переедет в hetzener или у него ухудшится локальная связность?
Думаю, в типовых договорах ничего об этом нет. Сложно. Нужно пробовать.
Потому что цены на порядок отличаются. Зачем читать серию статей, если бюджет к железу и близко не лежал?
Но ИТ специалисты из этих 100тыс обычных компаний ходят на конференции и слушают о том, как mail.ru делает бигдату, как кто-то на монге построил международный проект по лайканью котиков и т.д. А потом с горящими глазами возвращаются на свои рабочие места и начинают напяливать монгу на складское хранение, писать собственные сервера приложений на CPP, шардировать базу на 20 000 клиентов, в три слоя кешировать поиск на жалком сайте, потому что ORM генерит sql запросы на 500 строк и т.д.
Но нет нужды так делать в 99.99% компаний. Вот об этом мой доклад.
По моему опыту, для оперативной деятельности предприятия, которое занимается торговлей и производством, не нужны сложные алгоритмы. Работа финансов, склада и пр — обычная арифметика.
Для аналитики да, нужны внешние решения. Обработка изображений тоже снаружи. Но это уже не бизнес-логика.
Для этого (и для безопасности) pgBouncer создает пулы per user.
Думаю, в типовых договорах ничего об этом нет. Сложно. Нужно пробовать.
Вливаем таблицу в схему данных geodata:
pgdbf ./ADDROBJ.DBF |iconv -f CP866 -t utf8|awk '{sub(«CREATE TABLE »,«CREATE TABLE geodata.»); sub("\COPY ","\COPY geodata."); sub(«timeout=60000»,«timeout=999999»); print }'|psql mydatabase