|
|
|
Проектирование БД для сервиса СМС уведомлений
|
|||
|---|---|---|---|
|
#18+
Добрый день! Сразу оговорюсь, что в подобных вопросах я дилетант :) - потому если что-то будет не ясно описано - с радостью распишу подробнее! 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. В этом и кроются все проблемы: Нужно проверять баланс клиента с типом Припейд при отсылке смс сообщения. когда клиент попадает с одной градации в другую цена изменяется на все смс сообщения для этого оператора использованные им в этом месяце. снимать деньги с баланса сразу по факту доставки не целесообразно - так как нужно будет пересчитывать баланс при каждом переходе клиента с одной ценовой градации в другую. пока осуществляется пересчет баланса для клиента (в случае если их снимать по факту доставки) - проверка баланса при отсылке смс будет не корректной. Есть идея решения - но у меня возникаю вопросы о быстродействии данного решения. Будет ли он корректным? Создать 2 таблицы : 1)Таблица "Доставленных сообщений"(NoSQL, MySQL "MEMORY", переменная типа Array и.т.п.) - в ней раним ИД сообщения, дату/время доставки, ИД клиента, ИД оператора, коиторые записываются по факту доставки смс сообщения. 2) Таблица "начисления/списания" - в нее мы храним ИД клиента , дату "начисления/списания", сумму "начисления/списания". Списание записывается 1 раз по факту конца месяца по формуле "Списание по клиенту" = (Кол строк с таблицы "Доставленных сообщений") * (Цену). Текущий баланс вычисляется по формуле: "Текущий баланс" = (Итог по клиенту в таблице "начисления/списания") - ((Кол строк с таблицы "Доставленных сообщений" в текущий момент) * (Цену)). Пожалуйста подскажите на правильном ли мы пути? (Простите что так похабно описано - постараюсь дополнить) Заранее огромное спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2010, 16:44 |
|
||
|
Проектирование БД для сервиса СМС уведомлений
|
|||
|---|---|---|---|
|
#18+
QZ-eR, Разделите свой вопрос на 2 - техническая часть и программная. Что касается технической то я несовсем понимаю зачем систему ставить в рейд?.. Мое предложение - сразу поставить нормальный тазик. Под систему один SAS диск (снять с него образ и в случае умирания поставить новый и залить все с образа), поскольку данные на системе нехранятся то это вполне оправдано. Учитывая специфику задачи вам потребуется максимальная скорость чтения. Поэтому вероятно под базу нестоит упираться в SAS - вполне можно и на SATA поднять рейд 10. В рейд лучше поставить 8 дисков, пробовал я на 6 дисках - скорость нефонтан, а вот на 8 самое оно получилось. Количество памяти напрямую зависит от размера базы. Программная часть. Тут нужно понимать прежде всего что вам придется хранить сообщения какое-то время (2-3 месяца), т.к. возможен разбор полетов с клиентом. Для максимальной скорости храните в клиенте дату и текущую цену. А при отсылке сообщения повесьте триггер на таблицу с пересчетом цены. Надеюсь написал доходчиво. Что непонятно - спрашивайте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2010, 09:55 |
|
||
|
Проектирование БД для сервиса СМС уведомлений
|
|||
|---|---|---|---|
|
#18+
QZ-eRВ этом и кроются все проблемы: Нужно проверять баланс клиента с типом Припейд при отсылке смс сообщения. когда клиент попадает с одной градации в другую цена изменяется на все смс сообщения для этого оператора использованные им в этом месяце. снимать деньги с баланса сразу по факту доставки не целесообразно - так как нужно будет пересчитывать баланс при каждом переходе клиента с одной ценовой градации в другую. пока осуществляется пересчет баланса для клиента (в случае если их снимать по факту доставки) - проверка баланса при отсылке смс будет не корректной. Есть идея решения - но у меня возникаю вопросы о быстродействии данного решения. Будет ли он корректным? Лучьше снимать деньги с баланса сразу по факту доставки. Это ведь простая операция, короткая транзакция. Не знаю, как на MySql, но, например, MSSQL на таком железе держал бы несколько сот пересчётов в сек. Если на первом этапе количество обрабатываемых смс не превысит нескольких милионов в день, то такое решение лучьше - не будет ошибок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2010, 10:45 |
|
||
|
Проектирование БД для сервиса СМС уведомлений
|
|||
|---|---|---|---|
|
#18+
QZ-eR, автор - имеют цены уникальные на разных операторов мобильной , которые изменяются в зависимости от количества доставленных смс сообщений за месяц на оператора. Доброе время суток.Возникло пару вопросов: Надеюсь эта cтрочка действительна только для киентов "Припейд"? Если клиент исчерпал свою предоплату, то ему отрубают сервис? Клиент может иметь переходящий тип, т.е заранее заплатить, а если выйдет из лимита, то в конце месяца его попросят заплатить за привышение?если да,то как будет определяться тариф? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2010, 20:26 |
|
||
|
Проектирование БД для сервиса СМС уведомлений
|
|||
|---|---|---|---|
|
#18+
Злой Бобр, Все дело в деньгах, на данный момент это оптимальная конфигурация сервера по соотношению деньги/быстродействие/надежность. Поясню почему: Система должна работать в режиме 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== Он не должен превышать то что он оплатил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2010, 04:37 |
|
||
|
Проектирование БД для сервиса СМС уведомлений
|
|||
|---|---|---|---|
|
#18+
QZ-eR, Ну проблемы с железом это ваши проблемы. Думаю пока сервис будет раскручиваться может вы и сможете перебиться тем что написали, ну а дальше всеравно придется менять. Если сервер будет стоять не в вашей конторе, тогда действительно систему придется в рейд ставить (тут я с вами полностью согласен). Да, для вашей системы важна больше скорость чтения чем записи, поэтому я вам и посоветовал для экономии так сказать пользовать не SAS а SATA диски (я делал рейд 10 из 8 штук, при этом скорость чтения была выше чем аналогичный рейд на SAS. SAS дает прирост для записи, что актуально для высоконагруженных систем.) Еще раз скажу о триггере на таблицу сообщений. Пересчитывайте цену клиента при INSERT таблицы. Алгоритм можно сделать так что он практически небудет нагружать систему, т.е. сначала проверяем некое условие (количество сообщений в вашем случае) и если оно соответствует то делаем пересчет. В принципе задача вполне тривиальна и недолжна вызывать каких то особых проблем в решении. Посмотрите на готовые скрипты в нете по данной теме или близкой к ней. Самое главное постройте четко структурированную БД под вашу задачу, это намного упростит дальнейшее ее сопровождение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2010, 10:46 |
|
||
|
Проектирование БД для сервиса СМС уведомлений
|
|||
|---|---|---|---|
|
#18+
QZ-eR,получается что тарифы для клиента вы проставляете индивидуально в зависимости от суммы предоплаты.Правильно понимаю? Еще один момент, как вы собираетесь определять ушел клиент в минус или нет, если вам в любом случае придётся ждать подтверждение о доставке или недоставке сообщений от оператора?Есть ли лимит ожидания? Могу вам предложить следующее: Сделать таблицу Таблица "Расход клиента на месяц" 0.ID записи 1.ID.Оператора 2.IDклиента 3.ID тарифной сетки оператора 4.месяц+год 5.Количество отправленных смс 6.Количество доставленных смс В данной таблице присутствует по одной записи в течении месяца для каждого оператора, которому клиент отправлял смс. В результате вычисление на лету становится менее затратным, но при доставке и отправке смс вам нужно будет обновлять поля 6 и 5 соответственно.Так же в таблице с отправленными смс должен быть FK на данную таблицу.Советую сделать для отправленных смс 2 таблицы со связкой 1-1.В первой таблице будет системная информация(время доставки, код подтверждения,fK на [Таблица "Расход клиента на месяц"] и т.д), а во второй текст сообщения(и другая информация, которую нужно хранить минимальное время). ....ммм.... Хотя нужна еще одна таблица, в которой будет общая сумма по всем операторам для клиента в течении месяца....К сожалению больше нет времени, я сегодня немного занят,так что сегодня не смогу описать алгоритм.Ответе на мои вопросы и завтра более развернутый ответ дам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2010, 14:51 |
|
||
|
Проектирование БД для сервиса СМС уведомлений
|
|||
|---|---|---|---|
|
#18+
QZ-eRдумаю что с объемами 1000000-1500000 млн сообщений в месяц к концу года база будет занимать не менее 6-7 гб(с учетом того что текст сообщений мы будем хранить не более месяца).Ого, полторы тысячи милиардов сообщений в месяц! Это 1500 ТерраБайт! :-) QZ-eR2) Если у клиента будет 7 градаций по ценам и 4 оператора это = 28 пересчетам только по 1му клиенту.Ну это-же простой запросик. Если нормально программировать, ничего страшного в этом расчёте нет. Расчёт к тому же требуется только для одного оператора, на который ушло обрабатываемое сообщение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2010, 14:57 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=36905658&tid=1542482]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
163ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 453ms |

| 0 / 0 |
