Jump to content
Калькуляторы

USERSIDE - программное обеспечение для оператора связи

Даёшь PG всем биллингам!! :)

Share this post


Link to post
Share on other sites

Из пожеланий опциональности БД, так это яндексовский clickhouse.

Мне кажется для данных пеленга(мак адреса), отправленных смс, и многих других было бы неплохо использовать. Быстрая база для статичных данных. Для остального mysql/pg кому что привычнее.

А так - существенно разницы нет какую БД использовать, лишь бы быстро работала и были бы встроенные в us инструменты бекапа.

Ну и хороший мануал по настройке всей этой связки с рекомендациями естественно.

Share this post


Link to post
Share on other sites

Никто пользователю рутовский доступ и даже shell не будет давать. Особенно на шардинг хостинге.

Вы меня удивляете. Вот вам трещина в мироздании - psql умеет работать по сети. И этого полностью

хватает для манипуляций с пользовательской базой.

 

Вы меня уже не удивляете :)

Сервис, который запущен не на локалхосте - огромная дырища в безопасности. Только доли % DBA защищают ACL на firewall'ах для коннекта к базам с доверительным хостам.

 

 

Продемонстрируйте хоть один рабочий и внятно задокументированный мануал.

Засада в том, что нет принципиальной разницы в том, как тюнить ZFS для MySQL и PG. Разве что

в случае с PG требуется меньше приседаний и танцевальных па.

Понятно. Вы не в теме. Подсказка - размер блока при хранения данных/логов на диске

 

Советы закончились?

А если при базе 16ГБ памяти на сервере всего 8ГБ ?

 

В случае с мысклем это серьезная проблема, я так понимаю?

Это проблема с любой базой, будь-то MsSQL, Mysql, PG, Oracle или Mongodb.

Обычно разработчики прикладных приложений забывают простые вещи - скорость перемещения с диска в память - не сильно большая, а скорость при работе в памяти не такая уж большая и конечная.

 

KiB Mem:   3091340 total,  3018820 used,    72520 free,   215104 buffers
KiB Swap:  4193276 total,   157040 used,  4036236 free,  1068968 cached

 

это как раз там, где объем базы 160Гб.

[/code]

 

Понятно. IOPS намеренно при работе не привели, чтоб не светить, что 98% данных это архивные и к ним доступ раз в полгода :)

 

Утилиты нужны для анализа. А решение принимает DBA. Черный ящик будете сами администрировать на локалхосте и будете на LOR'e рассказывать, какой вы крутой админ.

Про снимки - не смешно. Попробуйте выгрузить из памяти базы, сделать снимок, а потом опять загрузить данные в память.

И если вы не научились бэкапить Mysql - кто ж вам виноват? :)

Какой чудный оксюморон - "Mysql DBA". Повторю: в PG для снятия бэкапа не надо городить многоходовочный сложносочиненный велосипед по той простой причине, что в нем нет того генетического дефекта, каким блистает мыскль. В PG снятие бэкапа это рутинная операция при успешном завершении всегда дающая восстановимые корректные данные. И без разницы где в момент начала бэкапа были данные - на носителях, кэше, буферах - все данные по завершенным транзакциям обязательно попадут в бэкап. И да, я специально не учился бэкапить мыскль, ибо не нужно. А когда нужно, я лучше погашу сервисы и сделаю бэкап "на холодную" серез mysqldump, ибо простой второстепенных поделок стоит дешевле, чем горотьба кластеров ради онлайн бэкапа клиентских днявочек.

Ура! Мы нашли единственного админа PG, который надеется на корректность завершения транзакций! Осталось ему нарваться на тяжелые и долгоживущие транзакции. И вишенька на торте будет, когда пару транзакций будут в бэкапе не завершенных и он будет мучительно долго их откатывать назад.

 

 

Я пока что вижу хипстеров, которые даже не читали про математику и алгоритмы.

Что ж так в сторону поплыли... В мыскле какие-то проблемы с бэкапом триггеров, функций и так далее? Не сочувствую, ибо "бачiли очi, шо куповали". В PG с бэкапом и восстановлением всего этого проблем нет.

 

В Mysql нет проблем с бэкапом этих данных. В дефолтных настройках, как и в PG, не учитываются эти вещи :)

 

Вы просто не эксплуатировали средние (16-128ГБ) и большие базы (свыше 128ГБ), а тем более распределенные (чаще всего с шардиногом).

И все это под большой нагрузкой. И это все надо бэкапить безпроблемно. И стараться при этом не лочить таблицы. Иначе после таймаутов и ошибок запросов, вам позвонит начальник и пропесочит по самые не хочу.

Размер базы я чуть выше привел, так что не надо про объемы. Да, и такой момент, при бэкапе PG не лочит таблицы, представляете? Ни на SELECT, ни на изменения. Подлость высшего порядка, поэтому я не понимаю ваших страданий, не впечатлен методами решения.

 

Осталось мелочь. Развернуть этот "бэкап" и придумать способ проверить консистентность и тождествоенность данных.

 

Даёшь PG всем биллингам!! :)

 

Сплюньте. Потом в случае аварии вы будете очень долго искать специалистов, по восстановлению данных.

Share this post


Link to post
Share on other sites

Ура! Мы нашли единственного админа PG, который надеется на корректность завершения транзакций! Осталось ему нарваться на тяжелые и долгоживущие транзакции. И вишенька на торте будет, когда пару транзакций будут в бэкапе не завершенных и он будет мучительно долго их откатывать назад.

Я понимаю что в мыскле с этим непреодолимые проблемы и вы с этим много настрадались. Но я повторю, в нормальных БД это не проблема. У вас проблемы с пониманием написанного? Ведь я простым языком сказал - в бэкап пападают все данные по _завершенным_ транзакциям на момент запуска бэкапа. Еще раз - ВСЕХ до последнего байта, но по завершенным. Кому нужен бэкап с актуальностью в минуты-секунды, те уже крутят хоровод вокруг WAL. Если в мыскле в бэкап заливаются все данные без разбора, то кто ж вам доктор, если вы пользуетесь таким инструментом?

 

В Mysql нет проблем с бэкапом этих данных. В дефолтных настройках, как и в PG, не учитываются эти вещи :)

С этого места поподробнее. Потому как лично я специально ничего не правил, но как-то так вышло, что триггеры и хранимые процедуры в PG у меня начали использоваться и бэкапитья еще 20 лет назад. Как сейчас помню, это был костылик из триггера и хранимой процедуры для реализации автоинкрементарного типа данных.

 

Осталось мелочь. Развернуть этот "бэкап" и придумать способ проверить консистентность и тождествоенность данных.

Я понимаю психоз "MySQL DBA" в этом плане, в мыскле с этим реально печально, и схемы бэкапа через кластерны кого угодно доведет до паранойи, но поверьте, в нормальных системах бэкап это просто бэкап. И если он был успешно снят, то он так же будет успешно развернут снова. Понимаю, в это труно поверить, но это так.

 

И, кстати, именно по этой причине я всегда бэкаплю мыскль "на холодную".

 

Сплюньте. Потом в случае аварии вы будете очень долго искать специалистов, по восстановлению данных.

 

psql -U username -p < DUMP.sql о, даааа, невероятное секретное знание.

 

это вам не приседания вокруг гавкнувшегося журнала мыскля, и потом мучительного поиска и ручного восстановления потерявшихся данных, чтобы у приложения база сошлась с ожиданием.

 

А про все биллинги под PG не бойтесь. Некоторые биллингорисователи принципиально этого делать не будут, даже если "переход на PG" просто значит выкидывание нахрен грязных мысклевских хаков, идущих вразрез со стандартами и приведения обращения к БД во вменяемый вид (привет разрабу Abills!). На деле же де-mysql'изация дает дорогу приложению к хреновой куче СУБД. Надеюсь разработчики US именно по этому пути решили пойти, а не просто сменить БД-лок с мыскля на PG. Хороший пример тут zabbix. Эти префектционистские маньяки сделали продукт, успешно работающий хоть на мыскле, хоть нна PG хоть на оракле хоть на SQLite (со скидкой на масштабы, ессно).

Share this post


Link to post
Share on other sites

И вишенька на торте будет, когда пару транзакций будут в бэкапе не завершенных и он будет мучительно долго их откатывать назад.

Почитайте для начала как транзакции в PostgreSQL работают прежде чем такое говорить.

Share this post


Link to post
Share on other sites

Даёшь PG всем биллингам!! :)

Было бы неплохо. Я так Карбонсофт троллю, когда они мне регулярно названивают с предложением приобретения их биллинга. "А, так вы уже сделаи поддержку PG в своем продукте? Нет? Позвоните как сделаете."

Share this post


Link to post
Share on other sites

https://t.me/usersideeu

 

Создана группа в "Telegram" для обсуждения мыслей о доработках с широким кругом клиентов. Встречные предложения и полемика. Присоединяйтесь.

Share this post


Link to post
Share on other sites

Переход проплачен сообществом PG, негоже специалистам PG в стороне стоять

Share this post


Link to post
Share on other sites

Вышла новая версия UserSide 3.11

 

Из основного:

 

- Автоматический инсталлятор для обновления/установки ERP "UserSide"

- Функционал произвольных полигонов на карте (отрисовка возможности включения в этом районе, каких-то секторов, зон...)

- Новый функционал патч-панелей (UTP)

- Видеонаблюдение: для категорий ТМЦ - флаг - выводить на карте + собственный значок + сектор на карте (новые возможности для учёта IP-камер)

- В схеме коммутации узла/муфты - добавлено масштабирование и возможность перетаскивания схемы

- Добавлен учёт истории уровней сигнала ONU и возможность просмотра этой истории

- Новый виджет на главную страницу: Погода. Прогноз погоды (openweathermap.org)

- Новый виджет на главную страницу: Погода. Молнии и грозы в реальном времени (blitzortung.org)

- Новый виджет на главную страницу: Погода. Метеорадары (meteoinfo.by)

- Черная, белая, серая подложка для карт. Позволяет сосредоточиться только на схеме

- В свойствах доп.полей добавлен спец.признак - поле для метража кабеля (это позволяет закрывать задание связанное с абонентом и автоматически метраж кабеля фиксируется в карточку абонента)

- В задания добавлены отдельные права на изменение исполнителей, удаление задания

- В заголовке календаря работ можно выводить прогноз погоды на этот день

- Дополнительные поля для ТМЦ

- Возможность прикрепления файлов к трассам ВОЛС

- Возможность прикрепления файлов к ТМЦ

- Возможность прикрепления файлов к Рекламным кампаниям

- Общий раздел для всех прикреплённых файлов

- Возможность менять маршрут прохождения кабельного канала (ранее поддерживались только прямая линия от начала до конца)

- Вывод в карточке VLAN информации на карте обо всех задействованых узлов связи и домах с оборудованием, где используется этот VLAN

- Возможность сразу передачать всех ТМЦ из операции (например из операции прихода - передать куда-то далее всё сразу)

- При добавлении ТМЦ в операцию - можно не все единицы ТМЦ передавать, а указывать конкретное их количество

- Добавлены динамические даты фильтрации в заданиях (вчера, завтра, прошлая неделя) (это работает и для сохраняемых персональных фильтров)

- Поддержка разной этажности для разных подъездов дома

- В рекламной кампании можно закреплять абонентов за ней

- В отчёте остатка по складу и отчете по операциям добавлены выборки по шаблону

- При добавлении коммутатора в узел связи - добавлен быстрый поиск по ТМЦ. В т.ч. по серийному номеру

- В список ONU/ONT на OLT добавлен фильтр по мощности сигнала, расстоянию до OLT, названию интерфейса

- Возможность для OLT посмотреть все включённые в него ВОЛС и промежуточные узлы/муфты

- В подсетях IP-адресов можно вывести таблично список IP-адресов с указанием за кем они закреплены

- Для структурной схемы добавлена возможность посмотреть на карте все линии и узлы (где стоит оборудование)

- Добавлен субсчёт ТМЦ - "Ответственное хранение"

- Возможность настройки шаблона информации об абоненте в карточке задания

- Добавлены быстрые ссылки в карточке управляемого оборудования для доступа к устройству по различным протоколам/получению информации из систем мониторинга

- Яндекс.Геокодер для поиска координат размещения домов

- Возможность добавлять описание к прикреплённым файлам

- В списке операторов добавлена возможность отобразить активных операторов и их IP-адреса входа

- Поддержка адаптеров/пигтейлов типа ST APC, ST UPC

- Добавлен испанский интерфейс (спасибо olivenet.es)

- Отправка почты через новый механизм (SwiftMailer: SMTP, sendmail, PHP Mail)

- Для CWDM добавлена поддержка длин волн с точностью до сотых

- Для CWDM добавлена поддержка MON, EXT, UPG - интерфейсов

Share this post


Link to post
Share on other sites

Если я правильно понял из документации, в настоящее время Userside использует 2 БД - Mysql + PostgreSQL одновременно?

В чем глубинный смысл работать одновременно с 2 разными БД???

Share this post


Link to post
Share on other sites

Если я правильно понял из документации, в настоящее время Userside использует 2 БД - Mysql + PostgreSQL одновременно?

В чем глубинный смысл работать одновременно с 2 разными БД???

 

Теперь Антон сможет добавить еще одну строку в резюме на Линкедине :)

Share this post


Link to post
Share on other sites

Если я правильно понял из документации, в настоящее время Userside использует 2 БД - Mysql + PostgreSQL одновременно?

В чем глубинный смысл работать одновременно с 2 разными БД???

Этот момент меня тоже смутил. Если задумали движение к правильным СУБД, то по хорошему это должно производиться за один присест через конвертилку, когда в проект внесены все необходимые изменения. А тут замутили непонятный движ с раздиранием клиентского седалища под два стула.

Share this post


Link to post
Share on other sites

На данный момент идёт переезд с одного движка на другой. Мы бы и рады это сделать за один присест, однако это всё не так просто, т.к. требуется переработка практически всего кода. А это очень много. Так что - постепенно. Мы выбрали этот вариант.

Share this post


Link to post
Share on other sites

ну это, по крайней мере, странно :)

Share this post


Link to post
Share on other sites

Мы выбрали этот вариант.

 

Есть надежда, что в финале будет наличествовать некий инструмент, позволящий совершить прыжок 3.9(mysql only) -> X.Y (PG only) с пропуском всех промежуточных стадий?

Share this post


Link to post
Share on other sites

На данный момент идёт переезд с одного движка на другой. Мы бы и рады это сделать за один присест, однако это всё не так просто, т.к. требуется переработка практически всего кода. А это очень много. Так что - постепенно. Мы выбрали этот вариант.

 

Чтобы выпустить версию 4.0 якобы обновленную, но по новой цене.

 

 

Есть надежда, что в финале будет наличествовать некий инструмент, позволящий совершить прыжок 3.9(mysql only) -> X.Y (PG only) с пропуском всех промежуточных стадий?

 

Не будет. Нет тестеров. Даже в пределах stable ветки есть куча подводных камней.

Share this post


Link to post
Share on other sites

Есть надежда, что в финале будет наличествовать некий инструмент, позволящий совершить прыжок 3.9(mysql only) -> X.Y (PG only) с пропуском всех промежуточных стадий?

 

Да. Есть надежда. К этому стремимся

 

Чтобы выпустить версию 4.0 якобы обновленную, но по новой цене.

 

Хорошая идея. Спасибо.

Share this post


Link to post
Share on other sites

Чтобы выпустить версию 4.0 якобы обновленную, но по новой цене.

 

Хорошая идея. Спасибо.

 

Та, ладно. Все к этому и шло.

Другое дело, что операторы могут обидеться и купить одну копию, но проинсталлить на сотню серверов :)

Share this post


Link to post
Share on other sites

Другое дело, что операторы могут обидеться и купить одну копию, но проинсталлить на сотню серверов :)

Для этого разработчик сделал маленький бекдор, система US периодически связывается с сервером и сливает данные об системе где установлена, версии ПО, лицензии, количество абонентов в базе, модули, etc....

Share this post


Link to post
Share on other sites

В инет то ее можно и не выпускать

А если у человека используется внешний GSM шлюз для рассылки или карты, которые US подтягивает с google и yandex?)

Share this post


Link to post
Share on other sites

Другое дело, что операторы могут обидеться и купить одну копию, но проинсталлить на сотню серверов :)

Для этого разработчик сделал маленький бекдор, система US периодически связывается с сервером и сливает данные об системе где установлена, версии ПО, лицензии, количество абонентов в базе, модули, etc....

 

Этот штатный функционал. Отключаемый.

 

http://wiki.userside.eu/%D0%9E%D1%82%D0%BF%D1%80%D0%B0%D0%B2%D0%BA%D0%B0_%D0%BE%D1%82%D1%87%D0%B5%D1%82%D0%BE%D0%B2_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%87%D0%B8%D0%BA%D0%B0%D0%BC_UserSide_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D1%83%D0%BB%D1%83%D1%87%D1%88%D0%B5%D0%BD%D0%B8%D1%8F)

 

UPD: Ссылка не прогружается вся.

Вот - также (внизу): http://wiki.userside.eu/%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_-_%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D0%B0%D1%8F

Edited by UserSide

Share this post


Link to post
Share on other sites

Другое дело, что операторы могут обидеться и купить одну копию, но проинсталлить на сотню серверов :)

Для этого разработчик сделал маленький бекдор, система US периодически связывается с сервером и сливает данные об системе где установлена, версии ПО, лицензии, количество абонентов в базе, модули, etc....

 

Там дырок хватает, это малая из них.

Share this post


Link to post
Share on other sites

Вышла новая версия UserSide 3.12
Из основного:
* Перенос данных из MySQL в PostgreSQL завершен
* Чек-листы в заданиях
* Задание теперь можно отложить на определённый срок, по истечению которого оно вернётся в обычный статус
* Кэширование тайлов карт, что позволяет работать с картами и при отсутствии внешнего интернет-канала
* Возможность указывать индивидуальные координаты на карте для конкретных абонентов
* Произвольные страницы и ссылки в меню теперь можно добавлять в любой раздел
* Ведётся история коммутаций на портах/ОВ с возможностью её просмотра
* Добавлен новый слой на карте - "Абоненты"
* В список абонентов добавлена возможность сохранять собственные фильтры выборки абонентов
* Биллинг ABillS начиная с версии 0.77.50 стандартно работает с бесплатным универсальным модулем usm_billing
* Биллинг MikBill начиная с версии 2.12.7 начал поддерживать управление абонентами из-под UserSide
* Приватные задания на работы (только автор и исполнители имеют доступ к ним)
* Маршрут автотранспорта на карте подсвечивается красным, если на участке скорость превысила 90 км/ч
* Для разделов в каталоге товаров и для конкретных наименований ТМЦ можно выбирать индивидуальные доп.поля для использования
* В каталоге товаров добавлена возможность создавать иерархию вложенных типов ТМЦ
* В карточку задания добавлен блок с информацией о времени просмотра этого задания операторами
* Возможность отключать ненужные картографические системы
* При установке узла связи через карту - в поле с адресом этого узла автоматически подбирается ближайших населённый пункт ''(по координатам)''
* API карт переработано на Leaflet
* Возможность прикреплять ВОЛС (в т.ч. несколько) к заданию на работу
* Добавлен вывод в карточке GPON-ONT информации на каком OLT она была найдена (по аналогии с GEPON-ONU, что было ранее)
* Горячая замена делителей/уплотнителей
* Во всплывающем окне о входящем звонке модуля usm_asterisk для неизвестных номеров добавлена прямая ссылка на добавление потенциального абонента
* Добавлена возможность привязать входящий неизвестный номер звонка к существующему абоненту
* На карту можно выводить не только номера узлов связи/муфт/опор, но и их наименования/адреса
* Сотрудник может получать письма при передаче на него ТМЦ в подотчёт/из подотчёта 
* В карточке ВОЛС видны связанные задания на работу по этой ВОЛС
* Добавлен грузинский интерфейс (спасибо pcmax.ge)
* В настройках отдельная секция с информацией о лимитах объектов
* Новое задание планировщика "Перенос неактивных абонентов в отключённые"
* Новый модуль usm_radio (вместо us_radio)
* Новый модуль usm_observer (вместо us_control)
* Прочие изменения: см. http://wiki.userside.eu/Версии_3.12

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now