powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование БД для сервиса СМС уведомлений
8 сообщений из 8, страница 1 из 1
Проектирование БД для сервиса СМС уведомлений
    #36905658
QZ-eR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добрый день!
Сразу оговорюсь, что в подобных вопросах я дилетант :) - потому если что-то будет не ясно описано - с радостью распишу подробнее!

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

Условия:

Тех. составляющая:

AMD Phenom x6 1055t (3,03 ггц 6 ядер)

8 gb DDR3 1333 REG

6*Samsung 502HJ 500 gb 7200rpm 16 mb(2=RAID1 for system, 4=RAID10 for base)

OS Debian 5.0 amd64

*Изменение тех. части предвидится не ранее чем через год.

Структура билинга:

Клиент отсылает смс уведомление (сообщение) и по факту его доставки(деньги за не доставленное смс уведомление, не снимаются) с его баланса списывается определенная сумма.


Клиенты
- имеют ТИП :
Постпейд (кредит - оплата в конце месяца по количеству доставленных смс)
Припейд (предоплата - клиент использует средства оплаченные им - заранее)
- имеют цены уникальные на разных операторов мобильной , которые изменяются в зависимости от количества доставленных смс сообщений за месяц на оператора.

Код: plaintext
1.
2.
3.
4.
5.
6.
--------------------------------------------------------
|Градация|Оператор1|Оператор2|Оператор3|Оператор4|
---------- ----------- ----------- ----------- ----------
| 1 - 200| 0,2     | 0,2     | 0,4     |0,3      |
---------- ----------- ----------- ----------- ----------
| 201-500| 0,1     | 0,1     | 0,3     |0,1      |
---------- ----------- ----------- ----------- ----------

В этом и кроются все проблемы:

Нужно проверять баланс клиента с типом Припейд при отсылке смс сообщения.

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

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

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


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

Создать 2 таблицы :

1)Таблица "Доставленных сообщений"(NoSQL, MySQL "MEMORY", переменная типа Array и.т.п.) - в ней раним ИД сообщения, дату/время доставки, ИД клиента, ИД оператора, коиторые записываются по факту доставки смс сообщения.


2) Таблица "начисления/списания" - в нее мы храним ИД клиента , дату "начисления/списания", сумму "начисления/списания". Списание записывается 1 раз по факту конца месяца по формуле

"Списание по клиенту" = (Кол строк с таблицы "Доставленных сообщений") * (Цену).


Текущий баланс вычисляется по формуле:
"Текущий баланс" = (Итог по клиенту в таблице "начисления/списания") - ((Кол строк с таблицы "Доставленных сообщений" в текущий момент) * (Цену)).


Пожалуйста подскажите на правильном ли мы пути? (Простите что так похабно описано - постараюсь дополнить) Заранее огромное спасибо!
...
Рейтинг: 0 / 0
Проектирование БД для сервиса СМС уведомлений
    #36906707
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
QZ-eR,

Разделите свой вопрос на 2 - техническая часть и программная.
Что касается технической то я несовсем понимаю зачем систему ставить в рейд?.. Мое предложение - сразу поставить нормальный тазик. Под систему один SAS диск (снять с него образ и в случае умирания поставить новый и залить все с образа), поскольку данные на системе нехранятся то это вполне оправдано. Учитывая специфику задачи вам потребуется максимальная скорость чтения. Поэтому вероятно под базу нестоит упираться в SAS - вполне можно и на SATA поднять рейд 10. В рейд лучше поставить 8 дисков, пробовал я на 6 дисках - скорость нефонтан, а вот на 8 самое оно получилось. Количество памяти напрямую зависит от размера базы.

Программная часть. Тут нужно понимать прежде всего что вам придется хранить сообщения какое-то время (2-3 месяца), т.к. возможен разбор полетов с клиентом. Для максимальной скорости храните в клиенте дату и текущую цену. А при отсылке сообщения повесьте триггер на таблицу с пересчетом цены.

Надеюсь написал доходчиво. Что непонятно - спрашивайте.
...
Рейтинг: 0 / 0
Проектирование БД для сервиса СМС уведомлений
    #36906851
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
QZ-eRВ этом и кроются все проблемы:
Нужно проверять баланс клиента с типом Припейд при отсылке смс сообщения.

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

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

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

Есть идея решения - но у меня возникаю вопросы о быстродействии данного решения.
Будет ли он корректным?
Лучьше снимать деньги с баланса сразу по факту доставки. Это ведь простая операция, короткая транзакция.

Не знаю, как на MySql, но, например, MSSQL на таком железе держал бы несколько сот пересчётов в сек.
Если на первом этапе количество обрабатываемых смс не превысит нескольких милионов в день, то такое решение лучьше - не будет ошибок.
...
Рейтинг: 0 / 0
Проектирование БД для сервиса СМС уведомлений
    #36908579
==Lucky==
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
QZ-eR,
автор
- имеют цены уникальные на разных операторов мобильной , которые изменяются в зависимости от количества доставленных смс сообщений за месяц на оператора.

Доброе время суток.Возникло пару вопросов:
Надеюсь эта cтрочка действительна только для киентов "Припейд"?
Если клиент исчерпал свою предоплату, то ему отрубают сервис?
Клиент может иметь переходящий тип, т.е заранее заплатить, а если выйдет из лимита, то в конце месяца его попросят заплатить за привышение?если да,то как будет определяться тариф?
...
Рейтинг: 0 / 0
Проектирование БД для сервиса СМС уведомлений
    #36908772
QZ-eR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Злой Бобр,

Все дело в деньгах, на данный момент это оптимальная конфигурация сервера по соотношению деньги/быстродействие/надежность.
Поясню почему:
Система должна работать в режиме 24/7: то есть нужен надежный блок питания с запасом по мощности, обязательно RAID1 на систему, ну и соответственно надежный но и адекватный по скорости массив для БД.
На САС диски - просто нет денег, оптимально хватило на вот такой конфиг, а надеяться на надежность 1 САС диска я не могу...
Тех. составляющую я привел что бы примерно было понимание на чем система будет крутится.

О памяти - лажа в том что сообщения нужно хранить 1 год - потому думаю что с объемами 1000000-1500000 млн сообщений в месяц к концу года база будет занимать не менее 6-7 гб(с учетом того что текст сообщений мы будем хранить не более месяца).

Злой Бобр, alexeyvg, ==Lucky==.

Еще раз обрисую ситуацию на примере:

Например есть клиент который оплатил в начале месяца сумму 100 000.
Он имеет градации цен на смс сообщения по каждому оператору:
--------------------------------------------------------
|Градация|Оператор1|Оператор2|Оператор3|Оператор4|
---------- ----------- ----------- ----------- ----------
1 - 20000| 0,2 | 0,2 | 0,4 |0,3 |
---------- ----------- ----------- ----------- ----------
200000-500000 | 0,1 | 0,1 | 0,3 |0,1 |
---------- ----------- ----------- ----------- ----------
500000-1000000| 0,05 | 0,07 | 0,2 |0,08 |
---------- ----------- ----------- ----------- ----------
Что означает, что если он в течении месяца отошлет на Оператора1 1 000 000 сообщений то тогда его цена на оператора будет 0,05 ; на Оператора2 500 000 его цена будет 0,1 ну и т.д.
Если записывать транзакцию сразу с суммой по факту доставки смс есть несколько НО:
1) Если будут большие объемы смс сообщений - апдейты цены в транзакциях будут занимать немало времени что будет что чревато ЧТО смс могут перестать ходить по причине нехватки средств,на самом деле, которые после пересчета опять вернутся на баланс.
2) Если у клиента будет 7 градаций по ценам и 4 оператора это = 28 пересчетам только по 1му клиенту. Допустим что он не 1 а их 20 -уже солидное количество пересчетов а значит и серьезных обращений к жесткому диску - а это судя по словам "Злой Бобр" узкое место нашей конфы.

Если делать по варианту расчету баланса на лету - получаем более медленную транзакцию -но отсутствие апдейтов как таковых,соответственно пиковых нагрузок будет меньше хотя и средневзвешенная нагрузка на процессор будет выше.
Но вот как вычислять этот баланс на лету- вернее это сделать я предлагал в первом топике -но меня грызут сомнения нет ли еще каких то вариантов?
Лучше ли будет пересчет?

==Lucky==
Он не должен превышать то что он оплатил.
...
Рейтинг: 0 / 0
Проектирование БД для сервиса СМС уведомлений
    #36908998
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
QZ-eR,

Ну проблемы с железом это ваши проблемы. Думаю пока сервис будет раскручиваться может вы и сможете перебиться тем что написали, ну а дальше всеравно придется менять. Если сервер будет стоять не в вашей конторе, тогда действительно систему придется в рейд ставить (тут я с вами полностью согласен). Да, для вашей системы важна больше скорость чтения чем записи, поэтому я вам и посоветовал для экономии так сказать пользовать не SAS а SATA диски (я делал рейд 10 из 8 штук, при этом скорость чтения была выше чем аналогичный рейд на SAS. SAS дает прирост для записи, что актуально для высоконагруженных систем.)

Еще раз скажу о триггере на таблицу сообщений. Пересчитывайте цену клиента при INSERT таблицы. Алгоритм можно сделать так что он практически небудет нагружать систему, т.е. сначала проверяем некое условие (количество сообщений в вашем случае) и если оно соответствует то делаем пересчет.

В принципе задача вполне тривиальна и недолжна вызывать каких то особых проблем в решении. Посмотрите на готовые скрипты в нете по данной теме или близкой к ней. Самое главное постройте четко структурированную БД под вашу задачу, это намного упростит дальнейшее ее сопровождение.
...
Рейтинг: 0 / 0
Проектирование БД для сервиса СМС уведомлений
    #36909659
==Lucky==
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
QZ-eR,получается что тарифы для клиента вы проставляете индивидуально в зависимости от суммы предоплаты.Правильно понимаю?

Еще один момент, как вы собираетесь определять ушел клиент в минус или нет, если вам в любом случае придётся ждать подтверждение о доставке или недоставке сообщений от оператора?Есть ли лимит ожидания?

Могу вам предложить следующее:
Сделать таблицу

Таблица "Расход клиента на месяц"
0.ID записи
1.ID.Оператора
2.IDклиента
3.ID тарифной сетки оператора
4.месяц+год
5.Количество отправленных смс
6.Количество доставленных смс

В данной таблице присутствует по одной записи в течении месяца для каждого оператора, которому клиент отправлял смс. В результате вычисление на лету становится менее затратным, но при доставке и отправке смс вам нужно будет обновлять поля 6 и 5 соответственно.Так же в таблице с отправленными смс должен быть FK на данную таблицу.Советую сделать для отправленных смс 2 таблицы со связкой 1-1.В первой таблице будет системная информация(время доставки, код подтверждения,fK на [Таблица "Расход клиента на месяц"] и т.д), а во второй текст сообщения(и другая информация, которую нужно хранить минимальное время).
....ммм....
Хотя нужна еще одна таблица, в которой будет общая сумма по всем операторам для клиента в течении месяца....К сожалению больше нет времени, я сегодня немного занят,так что сегодня не смогу описать алгоритм.Ответе на мои вопросы и завтра более развернутый ответ дам.
...
Рейтинг: 0 / 0
Проектирование БД для сервиса СМС уведомлений
    #36909681
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
QZ-eRдумаю что с объемами 1000000-1500000 млн сообщений в месяц к концу года база будет занимать не менее 6-7 гб(с учетом того что текст сообщений мы будем хранить не более месяца).Ого, полторы тысячи милиардов сообщений в месяц! Это 1500 ТерраБайт!
:-)
QZ-eR2) Если у клиента будет 7 градаций по ценам и 4 оператора это = 28 пересчетам только по 1му клиенту.Ну это-же простой запросик. Если нормально программировать, ничего страшного в этом расчёте нет.
Расчёт к тому же требуется только для одного оператора, на который ушло обрабатываемое сообщение.
...
Рейтинг: 0 / 0
8 сообщений из 8, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование БД для сервиса СМС уведомлений
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]