Перейти к содержимому
Local
pavlabor

Требуется эмулятор StarGazerа.

Рекомендованные сообщения

21 минуту назад, Prime сказал:

принципы ACID

Возможно я чего то не понимаю, но принцип ACID реализован по крайней мере в PostgreSQL давным давно на уровне БД.

Это автоматическое отслеживание целостности базы, авто индексы и т.д.

Но это никаким образом не гарантирует сто процентной защиты от работы многопользовательской среды.

Вот это

24 минуты назад, Prime сказал:

работать напрямую с сервером бд не очень хорошая практика.

удобней и правильней иметь какой-то API для работы с биллингом, популярней и гибче HTTP - для биллинга сложно придумать.

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

Гарантия что не будет работать.

API, HTTP отдельные процессы распределенные во времени и не блокированные в БД.

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

Механизм решения данной проблемы, блокировка записи на момент обработки, модель MVCC (Multiversion Concurrency Control, Многоверсионное управление конкурентным доступом).

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

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

Во первых, не вижу решения этой проблемы.

А если где то и глюконет, ну пофиксят челу оплату менеджеры.

 

По поводу проектирования структуры БД, это ответственная задача и некогда она не решалась с первого раза.

Но это и никогда не было проблемой.

Перелить базу на новый движок, это решаемо.

 

Основное в биллинге на мой взгляд это модульная обвязка, ubilling вылизанная система.

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

Если там добавлено пару полей, подпилен интерфейс модуля и выборки перестроены по другому, то это ревизия модуля а не всего биллинга.

 

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

Параллельно вести ревизию как оно работает, проектировать новую базу, и строить параллельный стенд, от текущей работы, до импорта баз данных.

Дальше в одну прекрасную ночь все можно перелить в новый флакон.

 

Еще раз, со всего что я ставил за свою жизнь, ubilling не вызвал ни одной проблемы.

Вру, "мс" пересобрал.

 

 

29 минут назад, Prime сказал:

https://db-engines.com/en/system/Firebird;PostgreSQL

вот здесь можно сравнивать движки.

В 2000-ном, PostgreSQL уже дышал Oracl-у в спину.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Цитата

 

но принцип ACID реализован по крайней мере в PostgreSQL давным давно на уровне БД.

Это автоматическое отслеживание целостности базы, авто индексы и т.д.

 

 https://ru.wikipedia.org/wiki/ACID

конечно на уровне БД все реализовано, просто нужно правильно взаимодействовать с данными, вы используете транзакции в своем коде?

https://www.postgresql.org/docs/9.1/static/sql-set-transaction.html

https://en.wikipedia.org/wiki/Multiversion_concurrency_control


 

Цитата

 

Гарантия что не будет работать.

API, HTTP отдельные процессы распределенные во времени и не блокированные в БД.

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


 

Гарантия, что будет работать.

сходу 3 варианта решения: синхронизация api (топорно), select for update (row locking), оптимистик лок (версионирование)

Цитата

 

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

Во первых, не вижу решения этой проблемы.

А если где то и глюконет, ну пофиксят челу оплату менеджеры.

 

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

Цитата

 

По поводу проектирования структуры БД, это ответственная задача и некогда она не решалась с первого раза.

Но это и никогда не было проблемой.

 

это всегда проблема, называется Домен. 

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

 

Цитата

Основное в биллинге на мой взгляд это модульная обвязка, ubilling вылизанная система.

в биллинге все основное.

я несколько лет работал в крупной компании, которая этим занимается.

отбило навсегда связываться с биллингами и процессингами 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

  • Похожие публикации

    • Автор: Woods
      Здравствуйте, ситуация такова. Нужно замутить такую схему:
       
      При балансе равным нулю, чтобы доступ к учетке на ubilling блокировался и перенаправлял на внешний сайт с оплатой.
      Или же при ситуации, если аккаунта у пользователя нет, так же доступа к ubilling не предоставлялся, а происходило перенаправление на внешний сайт с оплатой. (регистрацией аккаунта в системе биллинг).
      Метод использования Хот-спот.
       
      P.S. тапками прошу не кидаться, новичок.
    • Автор: felixio_01
      День добрый! Использую Ubilling+stargazer. Переходить на другой биллинг нет желания (но, возможно, придётся). 
      Нахожусь в Крыму (прошу без политоты). В связи с этим необходимо внедрять в сеть СОРМ3, также делать выгрузку данных с биллинга. 
      Есть ли у кого реальный опыт интеграции СОРМ3 и Ubilling?
      Может быть кто-то может взяться (естественно не бесплатно) за написания модуля/скриптов для осуществления выгрузки данных на оборудование СОРМ3. Необходимая техдокументация имеется. 
      Прошу только конструктивный диалог.
    • Автор: camchatix
      Добрый день
       
      Имеется работающий ubilling 0.8.8 rev 6006
      ponizator + бдком + opt82 - все работает
      Подключил zte c300, добавил в разделе свич оборудование с описание ОЛТ (снмп шаблон выбрал zte 320 ГПОН)
      айпишка пингуется с биллинга
       
      на ЗТЕ есть работающие 3 онушки но при опросе олт - в понизаторе, в списке неизвестных ону нету ону с ЗТЕ.. только с бдком
      с билинга запустил snmpwalk на zte - посыпались данные
       
      дальше поковырялся и в папке billing/exports вижу файлы с опросами ОЛТ
      так вот файлы от бдкома вижу 5 штук (distance, fdb, signals, onuindex, onuinterface) 
      а вот от zte c300 только один IDOLT_OLTSIGNALS (посмотрел что внутри а там все верно - 3 онушки и ихние сигналы)
       
      но в понизаторе в таблице zte c300 пусто
      такое ощущение что в файле snmp не правильные MIBs указаны
       
      поделитесь инфо, или шаблоном snmp
      версия firmware zte c300 1.2.5
    • Автор: pavlabor
      Вопрос дополнения базы данных и биллинга таблицей "все-ко-всем", продиктованы следующими потребностями.
      Есть модуль "Филиалы".
      При подключении данного модуля возникает следующая проблема.
      Не возможно подключить например город или филиалы для филиала, потому как филиал получает доступ ко всей информации о других филиалах.
      Нужно создать условия при которых филиал сможет самостоятельно вносить пользователей, адреса, вести склад при этом не видя информацию в материнской базе и других филиалах.
      Далее филиал не может создавать филиал.
       
      Такие задачи решаются созданием таблицы "все-ко-всем" в которой формируется каскадное вложение филиалов и связкой соответствующих таблиц сервисов.
      При правильном построении форм запроса и проверке на стороне сервера прав, филиал сможет получать доступ только к разрешенным ему модулям, и только его позициям в базе.
      Более того филиал сможет создавать свои филиалы, контролировать в них данные.
       
      Приветствуется любая критика и предложения,
      помощь в консультации и программировании.
      Спонсирование заинтересованных сторон, приветствуется.
    • Автор: pavlabor
      Права, введение расширенной настройки прав.
      Предлагаю рассмотреть формирование и в перспективе реализации расширения следующих прав.
      Имеется, структурированное управление правами, которое не совсем закрывает потребность.
      Имеется.
      Объекты.
      - Модуль.
      - Позиция в модуле, юнит.
      Юзатели.
      - Филиалы.
      - Администраторы.
      Администраторы.
      - Стажер(демо).
      - Специалист.
      - Эксперт.
      Действия.
      - Просмотр.
      - Создание.
      - Редактирование.
      - Удаление.
      Собственно идея в чем. В оператора, или при создании филиала, администраторам могут быть переданы права на работу с модулем.
      В текущий момент, не имеется сквозной политики на права, поэтому они предоставляются выборочно и не совсем понятно по какой системе, по все вероятности "так получилось", как следствие, например.
      При создании филиала и передачи ему права на роботу с модулем город, то админ филиала может удалить город, изменить название, что может привести к проблеме у других филиалах и материнской структуре.
      При реализации единой политики, появляется необсуждаемая возможность и требование к модулям по правам.
      В связи с этим, определенный модуль можно делегировать/не делегировать филиалу, с определенными ограничениями, например филиал может просматривать, вносить города, но не может их редактировать или удалять.
      Внутри филиала, появляется возможность создавать профили уровней сотрудников не беспокоясь о состоянии базы, например создаеются
      - Стажер(демо).
      - Специалист 3 категории.
      - Специалист 2 категории.
      - Специалист 1 категории.
      - Эксперт.
      Взяли на работу чела, дали ему уровень стажера и пусть листает базу пока не прозреет,
      прозрел, дается профиль Специалиста 3 категории, и т.д.
      То же самое и с филиалами.
      Как админ филиала может завести пользователя, а выносить мозг дирекции тоже не каширно, вот и даются оговоренные права что админ филиала пользователя может завести, но редактировать и удалять не может, если другое не оговорено.
       
      Параллельно возникает вопрос с пользователями другого филиала, но этот вопрос будет рассмотрен в разделе "Требуется внесение таблицы "все-ко-всем".
       
      Приветствуется любая критика и предложения,
      помощь в консультации и программировании.
      Спонсирование заинтересованных сторон, приветствуется.
       
×