telematic Опубликовано 29 ноября, 2016 · Жалоба Коллеги, интересует мнение о данном продукте в разрезе функционала Order Management и Helpdesk. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 29 ноября, 2016 · Жалоба Коллеги, интересует мнение о данном продукте в разрезе функционала Order Management и Helpdesk. Жопа. По заказам, нет отдельного мобильного клиента для монтажников. По хелпдеску нет емейл тикет трекера. По крайней мере я когда смотрел - не нашел этого. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telematic Опубликовано 29 ноября, 2016 · Жалоба Жопа. По заказам, нет отдельного мобильного клиента для монтажников. По хелпдеску нет емейл тикет трекера. По крайней мере я когда смотрел - не нашел этого. А какие есть ещё продукты с аналогичным функционалом? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
infery Опубликовано 30 ноября, 2016 · Жалоба А какие есть ещё продукты с аналогичным функционалом? Других таких нет. Если только в кучку несколько собрать и использовать API для взаимодействия между ними. ЮС к слову умеет заявки с почты забирать, но это для галочки, и разработчики рекомендуют юзать API (кстати, простое и удобное, но пока есть не все, что хотелось бы) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telematic Опубликовано 30 ноября, 2016 · Жалоба Других таких нет. Ну что же вы так категорично? Их масса, но, к примеру, NetCracker или Amdocs не в моём бюджете. :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
infery Опубликовано 30 ноября, 2016 · Жалоба Спасибо, не знал про них! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telematic Опубликовано 30 ноября, 2016 · Жалоба Спасибо, не знал про них! :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UserSide Опубликовано 3 января, 2017 · Жалоба Вышла новая версия UserSide 3.10 Из основного: - Новый модуль usm_cabletest - Обратное взаимодействие с биллингом uBilling v.0.8.0+ (можно из-под UserSide изменять в биллинге у абонента баланс, тариф, смотреть на лету историю и актуальные данные по абоненту (ФИО, тариф, баланс) - Оборудование. Функционал по работе с CWDM - Покрытие. Возможность вывода номеров узлов связи/муфт и т.п. на карту - Покрытие. Возможность вывода произвольных надписей/текста на карту - Покрытие. Объекты на карте загружаются только при нужном масштабе карты - Тарифы. Добавлены группы тарифов - Абоненты. Возможность указывать дополнительные номера телефонов в карточке абонента - Операторы. В настройке профиля оператора дублируется настройка прав доступа к типам заданий - Оборудование. Возможность указания порта для SNMP-опроса коммутаторов (для каждого коммутатора свой настраиваемый порт) - В форме для удалённого закрытия наряда можно прикрепить файл Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Diman_xxxx Опубликовано 7 января, 2017 · Жалоба а можно 4 модуля адд дроп на узле между собой без активки скоммутировать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UserSide Опубликовано 8 января, 2017 · Жалоба Дропы пока не добавили, к сожалению Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UserSide Опубликовано 5 апреля, 2017 · Жалоба http://userside.eu/ru/price.php?country_id=ru С 2 квартала - цены для РФ пересмотрены (уменьшены). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 27 апреля, 2017 · Жалоба Почитал ChangeLog Юзерсайда и после фразы "Мы начинаем постепенный переход на PostgreSQL. " рекомендую клиентам оставаться на версии 3.9. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex_P89 Опубликовано 28 апреля, 2017 · Жалоба Есть предложение: пусть все несогласные с PostgreSQL напишут разработчикам на почту или тикет в ЛК клиента о своём нежелании работать с этой СУБД и потребуют от них провести опрос среди всех клиентов об отношении к переходу на эту СУБД. Не надо просто тихо оставаться на 3.9, надо поднимать бучу и коллективно продавливать отказ от обязательного перехода на PostgreSQL. Переход на PostgreSQL должен быть опциональным или от него вообще следует отказаться, это наша позиция. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 28 апреля, 2017 · Жалоба Миграция на PG? Я джва... шесть лет этого ждал! Нытики со своей bdb на стероидах идут лесом! У разработчиков наконец-то появится доступ к нормальным типам геоданных, это минимум. А у пользователей будет наконец-то нормальная производительная база. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex_P89 Опубликовано 28 апреля, 2017 · Жалоба Миграция на PG? Я джва... шесть лет этого ждал! Нытики со своей bdb на стероидах идут лесом! У разработчиков наконец-то появится доступ к нормальным типам геоданных, это минимум. А у пользователей будет наконец-то нормальная производительная база. Да хоть в дёсны лобызайтесь со своей ненаглядной PG. Фанбои PG идут лесом. Если у оператора 100% приложений успешно работают на MySQL, то зачем ему ради одного US с PG связываться? Все плюсы PG нивелируются минусами администрирования двух разных СУБД параллельно. Как минимум должна быть возможность выбора между MySQL и PostgreSQL в настройках US. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andryas Опубликовано 28 апреля, 2017 · Жалоба Как минимум должна быть возможность выбора между MySQL и PostgreSQL в настройках US. + Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 28 апреля, 2017 · Жалоба вот когда (никогда) мыскль сумеет в нормальное надежное хранение, нормальные типы данных и нормальные процедуры, вот тогда можете рассказывать за мыскль. Для страдающих синдромом утенка - администрировать неожиданно PG в разы проще вашей недоделки. Кстати, сейчас в наличии имеем аж три реализации мыскля - каноничная от оракакеля, хипстерская мария и НИХовская от перконы. Разница между ними невелика, но так как взгляды на развитие команд разработчиков у этих трех продуктов разные, вожно Вангу из могилы не поднимать, чтобы предсказать дальнейшее расхождения вплоть до несовместимости. Итак, какую именно реализацию мыскля надо поддерживать разработчикам? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 28 апреля, 2017 · Жалоба Для страдающих синдромом утенка - администрировать неожиданно PG в разы проще вашей недоделки. Будьте добры поделиться: не дырявой веб-админкой для PostgreSQL мануалом тюнинга ZFS под хранилище PostgreSQL мануалом тюнинга PostgreSQL при базах свыше 16ГБ аналогами mytop, mysqltuner, mysqlbackup Опциями беспроблемного бэкапа PostgreSQL при наличие аналогов MySQL - событий, триггеров, функций. Рабочей схемой master-slave для инкриментного бэкапа на удаленный сервер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 28 апреля, 2017 · Жалоба У разработчиков наконец-то появится доступ к нормальным типам геоданных, это минимум. Геоданные содержат всего три переменные - идентификатор, координаты по X, координаты по Y. Далее по идентификатору вешаем любые свои поля. А у пользователей будет наконец-то нормальная производительная база. У меня на продакшене Mysql выдает 10Krps на сложных запросах с Join и Insert. У операторов в телекоме только биллинг или Zabbix могут быть ресурсоемкими. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UserSide Опубликовано 28 апреля, 2017 · Жалоба "Если бы я спросил людей, чего они хотят, они бы попросили более быструю лошадь." Генри Форд Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 28 апреля, 2017 · Жалоба Ну вообще решаемо через всякие БД движки, для пхп это доктрина и ему подобные. А там уже кому чего. Ну и не вижу ничего криминального держать две разные бд на одном сервере. Тем более что Postgresql не сильно уж и отличается от mysql. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 29 апреля, 2017 · Жалоба Мнение Антона понятно. Остаемся на версии 3.9. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 2 мая, 2017 · Жалоба Будьте добры поделиться: не дырявой веб-админкой для PostgreSQL C 1997 года все админитраторские функции выполнялись исключительно через psql. Напомните, плз, когда там в psql нашли последние уязвимости? мануалом тюнинга ZFS под хранилище PostgreSQL Очередной случай бана в гугле? мануалом тюнинга PostgreSQL при базах свыше 16ГБ Опять вопрос про гугл. И это, 16 гигов это просто несолидно: SELECT SUM((relpages * 8) / 1024) AS size_mb FROM pg_class; size_mb --------- 160779 (1 строка) Рецепты сводятся к правки 2-3 параметров. Описания методики их вычисления описаны даже на русском языке. аналогами mytop, mysqltuner, mysqlbackup Из всего перечисленного смысл разве что pg_top имеет. Вы извините, но отдавать тюнинг СУБД, от которой зависит нормальное функционирование предприятия на откуп какой-то утилиты, это какое-то эникейство. Если не знаешь что крутить, то или изучай, или не лезь. Про бэкап вообще молчу. Я до сих пор в тихом а.....е от мануалов как в мыскле снять актуальный консистентный бэкап базы без прерывания сервиса. Даже забебспокоился поиском аналогичных решений и для PG, ибо мало ли что. На деле оказалось, что все эти пляски с присвистом вокруг бэкапа суть борьба с неустранимыми врожденными особенностями мыскля. В PG для снятия консистентного бэкапа достаточно сказать pg_dump bla-bla-bla, ну или pg_dimpall и все. Для клиентов базы процесс пройдет незаметно. Бэкапом будет снимок базы на момент запуска утилиты. Все. Опциями беспроблемного бэкапа PostgreSQL при наличие аналогов MySQL - событий, триггеров, функций. Это как-то даже не смешно. Вы прикалываетесь, или принципиально не смотрите что творится в большом мире за загончиком мыскля? Рабочей схемой master-slave для инкриментного бэкапа на удаленный сервер. Как бы сказать помягче... В PG проблемы с реализацией мысклевых велопедов, по той причине, что все что надо уже имеет правильную реализацию. См. WAL-журналирование. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 2 мая, 2017 · Жалоба Будьте добры поделиться: не дырявой веб-админкой для PostgreSQL C 1997 года все админитраторские функции выполнялись исключительно через psql. Напомните, плз, когда там в psql нашли последние уязвимости? psql -- PostgreSQL interactive terminal Терминал неинтересен. Никто пользователю рутовский доступ и даже shell не будет давать. Особенно на шардинг хостинге. мануалом тюнинга ZFS под хранилище PostgreSQL Очередной случай бана в гугле? Продемонстрируйте хоть один рабочий и внятно задокументированный мануал. мануалом тюнинга PostgreSQL при базах свыше 16ГБ Опять вопрос про гугл. И это, 16 гигов это просто несолидно: SELECT SUM((relpages * 8) / 1024) AS size_mb FROM pg_class; size_mb --------- 160779 (1 строка) Рецепты сводятся к правки 2-3 параметров. Описания методики их вычисления описаны даже на русском языке. Советы закончились? А если при базе 16ГБ памяти на сервере всего 8ГБ ? аналогами mytop, mysqltuner, mysqlbackup Из всего перечисленного смысл разве что pg_top имеет. Вы извините, но отдавать тюнинг СУБД, от которой зависит нормальное функционирование предприятия на откуп какой-то утилиты, это какое-то эникейство. Если не знаешь что крутить, то или изучай, или не лезь. Про бэкап вообще молчу. Я до сих пор в тихом а.....е от мануалов как в мыскле снять актуальный консистентный бэкап базы без прерывания сервиса. Даже забебспокоился поиском аналогичных решений и для PG, ибо мало ли что. На деле оказалось, что все эти пляски с присвистом вокруг бэкапа суть борьба с неустранимыми врожденными особенностями мыскля. В PG для снятия консистентного бэкапа достаточно сказать pg_dump bla-bla-bla, ну или pg_dimpall и все. Для клиентов базы процесс пройдет незаметно. Бэкапом будет снимок базы на момент запуска утилиты. Все. Утилиты нужны для анализа. А решение принимает DBA. Черный ящик будете сами администрировать на локалхосте и будете на LOR'e рассказывать, какой вы крутой админ. Про снимки - не смешно. Попробуйте выгрузить из памяти базы, сделать снимок, а потом опять загрузить данные в память. И если вы не научились бэкапить Mysql - кто ж вам виноват? :) Опциями беспроблемного бэкапа PostgreSQL при наличие аналогов MySQL - событий, триггеров, функций. Это как-то даже не смешно. Вы прикалываетесь, или принципиально не смотрите что творится в большом мире за загончиком мыскля? Я пока что вижу хипстеров, которые даже не читали про математику и алгоритмы. Рабочей схемой master-slave для инкриментного бэкапа на удаленный сервер. Как бы сказать помягче... В PG проблемы с реализацией мысклевых велопедов, по той причине, что все что надо уже имеет правильную реализацию. См. WAL-журналирование. Вы просто не эксплуатировали средние (16-128ГБ) и большие базы (свыше 128ГБ), а тем более распределенные (чаще всего с шардиногом). И все это под большой нагрузкой. И это все надо бэкапить безпроблемно. И стараться при этом не лочить таблицы. Иначе после таймаутов и ошибок запросов, вам позвонит начальник и пропесочит по самые не хочу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 2 мая, 2017 · Жалоба Никто пользователю рутовский доступ и даже shell не будет давать. Особенно на шардинг хостинге. Вы меня удивляете. Вот вам трещина в мироздании - psql умеет работать по сети. И этого полностью хватает для манипуляций с пользовательской базой. Продемонстрируйте хоть один рабочий и внятно задокументированный мануал. Засада в том, что нет принципиальной разницы в том, как тюнить ZFS для MySQL и PG. Разве что в случае с PG требуется меньше приседаний и танцевальных па. Советы закончились? А если при базе 16ГБ памяти на сервере всего 8ГБ ? В случае с мысклем это серьезная проблема, я так понимаю? KiB Mem: 3091340 total, 3018820 used, 72520 free, 215104 buffers KiB Swap: 4193276 total, 157040 used, 4036236 free, 1068968 cached это как раз там, где объем базы 160Гб. Конкретные задачи требуют конкретные решения. Если вам лень прочитать короткое руководство на русском (!!!) языке, которое ищется за два клика, я вам готов помочь с решением за прайс скромный. Утилиты нужны для анализа. А решение принимает DBA. Черный ящик будете сами администрировать на локалхосте и будете на LOR'e рассказывать, какой вы крутой админ. Про снимки - не смешно. Попробуйте выгрузить из памяти базы, сделать снимок, а потом опять загрузить данные в память. И если вы не научились бэкапить Mysql - кто ж вам виноват? :) Какой чудный оксюморон - "Mysql DBA". Повторю: в PG для снятия бэкапа не надо городить многоходовочный сложносочиненный велосипед по той простой причине, что в нем нет того генетического дефекта, каким блистает мыскль. В PG снятие бэкапа это рутинная операция при успешном завершении всегда дающая восстановимые корректные данные. И без разницы где в момент начала бэкапа были данные - на носителях, кэше, буферах - все данные по завершенным транзакциям обязательно попадут в бэкап. И да, я специально не учился бэкапить мыскль, ибо не нужно. А когда нужно, я лучше погашу сервисы и сделаю бэкап "на холодную" серез mysqldump, ибо простой второстепенных поделок стоит дешевле, чем горотьба кластеров ради онлайн бэкапа клиентских днявочек. Я пока что вижу хипстеров, которые даже не читали про математику и алгоритмы. Что ж так в сторону поплыли... В мыскле какие-то проблемы с бэкапом триггеров, функций и так далее? Не сочувствую, ибо "бачiли очi, шо куповали". В PG с бэкапом и восстановлением всего этого проблем нет. Вы просто не эксплуатировали средние (16-128ГБ) и большие базы (свыше 128ГБ), а тем более распределенные (чаще всего с шардиногом). И все это под большой нагрузкой. И это все надо бэкапить безпроблемно. И стараться при этом не лочить таблицы. Иначе после таймаутов и ошибок запросов, вам позвонит начальник и пропесочит по самые не хочу. Размер базы я чуть выше привел, так что не надо про объемы. Да, и такой момент, при бэкапе PG не лочит таблицы, представляете? Ни на SELECT, ни на изменения. Подлость высшего порядка, поэтому я не понимаю ваших страданий, не впечатлен методами решения. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...