Интересно, а почему в качестве базы выбран MySQL?

[n0mad]

Не то чтобы запрос... но думаю в этой ветке это оффтопик в меньшей степени.

Решил поискать наиболее подходящий фришный биллинг для мелких нужд - типа посчитать IP трафик в небольшой конторке, дать туда доступ по VPN снаружи, посмотрел описания нескольких вариантов, abills на данный момент заинтересовал больше остальных, вот решил поставить дабы посмотреть поближе.

Однако все больше задаюсь вопросом..... почему большинство авторов биллингов выбирают mysql? почему например не postgresql?
Я например в postgresql вижу несколько преимуществ (хотя конечно современный mysql почти по всем параметрам догнал, но это требует дополнительных плясок с бубном).

1. Самое основное преимущество - версионность: т.е. если я решил сдампить базу pg_dump-ом, то я сбэкаплю снэпшот на момент начала бэкапа - с тем набором данных котоые были НА ТОТ МОМЕНТ. Если я буду дампить mysql - то возможно сдампить одну таблицу в одном состоянии а потом другую с уже дописанными записями по сравнению с состоянием на момент начала бэкапа.

Слышал что для исключения этих проблем в mysql - поднимают кластер и бэкапят с зеркала предварительно разорвав связь с
мастер-сервером.

В случае с конторой с 10-50 пользователями и небольшой базой это все не так страшно, а в случае более-менее крупного провайдера?
Неужели все поднимают зеркала или есть другие варианты? Остановку сервиса мы естественно не рассматриваем.

2. Журналируемое/транзакционное хранилище. Я конечно понимаю, что в идеальном случае стабильного ядра, софта и железа эта проблема не так актуальна, но в случае если повесится сервер -
его перезагрузка потребует чекинга всех таблиц MySQL а это
порой весьма приличное время.... postgresql чекал 6гиговую базу за несколько секунд, накатывал транзакции и запускался.

3. Процедуры хранимые на сервере - в 5м MySQL они конечно появились, а в postgres существуют давно. Ведь если рассудить логично - туда можно поместить большую часть бизнес-логики базы данных и тогда гибкость биллинга повысится в разы, ведь вся информация которой оперируют скрипты выполняя кучу запросов - находится в базе... так почему-бы эти запросы не оформлять в виде хранимых процедур а из биллинга только вызывать определенную процедуру для получения информации, а уж она сделает нужные запросы и выдаст готовый финальный ответ.

Я конечно не программер а юзер - но мне просто интересно, где я заблуждаюсь? Почему автор выбрал именно MySQL? Может автор найдет время рассказать? Ну а не найдет, это его право
А я пойду пока курить его скрипты и строить биллинг на отдельно взятой машине.

Олег.

[lasik]

распространенность и известность мускуля как такового

в институтах если препадают SQL, то это или access или mysql, редко когда oracle, очень редко mssql, а postgresql зачастую рассматривают как дополнеие к php, как бы это не звучало дико, это так.

я учился в 2 ВУЗ'ах, в одном по базам данных мы рассматривали mysql, во втором access.

так что, это скорее всего и будет ответ автора, или же нет, увидем

[lasik]

во, кстати.


для автора темы

[n0mad]

Кстати шарил в инете по поводу установки abills (кстати пока за ночь так и не поднял его - наткнулся на ссылку на другой биллинг.

http://code.google.com/p/cakebilling/

Вот там как раз так и реализовано Почитал описание прямо-таки респект автору Конечно не такой навороченный как abills, но бизнес-логикой там как раз рулит постгрес. Жаль мне не подойдет, мне хочется обсчета по ip адресам и руление почтой, а там только vpn.

Но на досуге будет интересно посмотреть тот биллинг.

Олег.

[ran]

почему большинство авторов биллингов выбирают mysql? почему например не postgresql?

http://program.rin.ru/razdel/html/490-2.html

[n0mad]

По крайней мере неспортивно постить протухший рекламный пост производителя базы. Там сравниваются Mysql 4.0 и Postgresql 7.2,
А на дворе MySQL 5.0 и PostgreSQL 8.3 а это серьезный прогресс как у одних так и у других.

Тем не менее основные доводы в стиле "Нашей базой пользуется миллион леммингов, а миллион лемингов не может быть не прав" меня улыбают...... или "наша база самая быстрая"... или "наша база лучше чем postgresql работает в WINDOWS" - смешно ей-богу.

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

http://postgresmen.ru/news/view/111
http://postgresql.ru.net/docs/overview.html

Но повторюсь - даже если быстродействие не самое лучшее, меня радовал быстрый старт и версионный бэкап, только эти 2 фичи перекрывают множетсво возможных недостатков. Есть у postgres конкретный косяк с SELECT MAX(x) - который выполняется гораздо дольше чем на читерской mysql которая при апдейте колонки просто сохраняет его в отдельную ячейку, а постгрес честно выполняет запрос. Но при грамотном написании запросов это все обходится....

Меня прикололо одно мнение, правда не про постгрес:
---
Не согласен. У них назначение абсолютно разное, да и вообще можно ли сравнивать лошадь и верблюда в пустыне. Кони быстрые, но выдыхаются на жаре мигом, ну а верблюд - он и в Африке верблюд .
---



Хотя это оффтопик и как-бы не схлопотать по ушам

P.S. Вот сижу и пытаюсь заставить работать mppe-128....
Так pptp стал работать, а вот с mppe ни в какую... уже кучу доков
искурил и никак..... если авторизую по chap-secrets то все ok, а если
по радиусу/abills - ни в какую....

[ran]

во, кстати.


для автора темы

ну закажи Автору заплати требуемые

Postgres - 8000 $

и радуйся жизни, чего пристал-то? или сам перепиши - проект оупенсорс...

P.S. Вот сижу и пытаюсь заставить работать mppe-128....
Так pptp стал работать, а вот с mppe ни в какую... уже кучу доков
искурил и никак..... если авторизую по chap-secrets то все ok, а если
по радиусу/abills - ни в какую....

а на эту тему в форуме ну очень много писано... и здесь это уж точно офтоп...

[~AsmodeuS~]

1. - чему mysql
- так исторически сложилось, долгая история елси интересно на досуге напишу.

2. Миграция на Postgres без пробем прайс мы огласили. С одной стороны это может показаться дорого. Но с другой стороны
1 Написать чтото типа абилса займёт несколько лет работы и решения кучи вопросов бизнес логики. Мы уже их решили и знаем как что надо.
2 За несколько лет разработки цена как миниму будет в 5 раз выше написаной нами. Учитывая работу опытных програмистов и админисраторов.
3 У меня уже есть наработки по портированию ABillS под Postgres но пока перенесена только логика работы с радиусом.
4 Мы сделаем это быстрее, качественей и дешевле чем разработка с нуля.


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

[n0mad]

Спасибо за ответ, Ваша позиция понятна. Мне честно говоря abills нужен по минимуму. Однако цены типа $8-$10k нереальные и я считаю просто отмазкой.... типа "любой каприз за ваши деньги, но башлять придется много" - В данную сумму можно уложить много коммерческих и сертифицированных биллингов. Мало того, есть в общем-то сертифицированный биллинг по цене от $580 за базовый модуль, и вполне работоспособный в нынешнее время. Правда когда я работал в провайдерской конторе тот биллинг был слишком сырой и огребали кучу глюков имея недовольных клиентов а к тому времени как он стал более-менее стабильным контора уже склеила лапки после прихода 3х монстров на рынок, которые сжатыми сроками построили каждая свою транспортную сеть по всему городу.
Четвертый монстр в виде ТрансТелекома уже опоздал и они даже его не пустили

Теперь в каждом доме по 3 провайдера интернета и кабельного телевидения - жесть )) за $12 дают 512днем 2048 ночью с лимитом 40G, а потом до 64 зарезают.

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

Сорри за оффтопик, можете порезать если хотите - но просто что-то высказаться захотелось

P.S. Там в соседней ветке увидел давнишний пост про агрегацию детальной статистики... с запросами конечно не помогу, а вот хранить можно было-бы в отдельной базе в куче таблиц. В новых мускулях есть вроде возможность создавать пакованные read-only таблицы и объединять их во вьюшку для выборки по ним одним запросом. И решение вроде не сложное, и экономия диска и удобство работы.

[chtito2]

P.S. Там в соседней ветке увидел давнишний пост про агрегацию детальной статистики... с запросами конечно не помогу, а вот хранить можно было-бы в отдельной базе в куче таблиц. В новых мускулях есть вроде возможность создавать пакованные read-only таблицы и объединять их во вьюшку для выборки по ним одним запросом. И решение вроде не сложное, и экономия диска и удобство работы.

У меня что-то вроде этого для агрегации трафика за час, чтобы клиентский просмотр почасовой статистики на вебе не был таким непозволительно медленным (прикиньте: 3-6 секунд cpu за один просмотр!), т.к. у меня с Ipn таблица ipn_log росла каждую минуту (а точнее, каждый запуск traffic2sql) я почти полностью избавился от нее и заменил на ipn_cache. Сейчас с агрегацией за час все в 50-60 раз быстрее как и стоило ожидать.

CREATE TABLE `ipn_cache` (
`uid` int(11) unsigned NOT NULL DEFAULT '0',
`start` datetime NOT NULL,
`traffic_class` smallint(6) unsigned NOT NULL DEFAULT '0',
`traffic_in` bigint(20) unsigned NOT NULL,
`traffic_out` bigint(20) unsigned NOT NULL,
`sum` double(15,6) unsigned NOT NULL DEFAULT '0.000000',
PRIMARY KEY (`uid`,`start`,`traffic_class`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

mysql> select * from ipn_cache where uid=184 order by start desc limit 10;
+-----+---------------------+---------------+------------+-------------+----------+
| uid | start | traffic_class | traffic_in | traffic_out | sum |
+-----+---------------------+---------------+------------+-------------+----------+
| 184 | 2009-02-05 10:00:00 | 1 | 3876 | 0 | 0.000000 |
| 184 | 2009-02-05 10:00:00 | 0 | 1114831 | 0 | 0.000000 |
| 184 | 2009-02-05 09:00:00 | 0 | 3935984 | 0 | 0.000000 |
| 184 | 2009-02-05 08:00:00 | 0 | 9695 | 0 | 0.000000 |
| 184 | 2009-02-05 07:00:00 | 0 | 11977 | 0 | 0.000000 |
| 184 | 2009-02-05 06:00:00 | 0 | 10817 | 0 | 0.000000 |
| 184 | 2009-02-05 05:00:00 | 0 | 8866 | 0 | 0.000000 |
| 184 | 2009-02-05 04:00:00 | 0 | 6007 | 0 | 0.000000 |
| 184 | 2009-02-05 03:00:00 | 0 | 8109 | 0 | 0.000000 |
| 184 | 2009-02-05 02:00:00 | 0 | 8764 | 0 | 0.000000 |
+-----+---------------------+---------------+------------+-------------+----------+
10 rows in set (0.01 sec)

[~AsmodeuS~]

Спасибо за ответ, Ваша позиция понятна. Мне честно говоря abills нужен по минимуму. Однако цены типа $8-$10k нереальные и я считаю просто отмазкой.... типа "любой каприз за ваши деньги, но башлять придется много"

10 000$ Вам даже половину ABillS не напишу и займёт это несколько лет.

- В данную сумму можно уложить много коммерческих и сертифицированных биллингов. Мало того, есть в общем-то сертифицированный биллинг по цене от $580 за базовый модуль, и вполне работоспособный в нынешнее время. Правда когда я работал в провайдерской конторе тот биллинг был слишком сырой и огребали кучу глюков имея недовольных клиентов а к тому времени как он стал более-менее стабильным контора уже склеила лапки после прихода 3х монстров на рынок, которые сжатыми сроками построили каждая свою транспортную сеть по всему городу.
Четвертый монстр в виде ТрансТелекома уже опоздал и они даже его не пустили

Илюзия что хороший билинг может стоить меньше 5 000 $. На разве если у провайдера 1000 клиентов то да.

P.S. Там в соседней ветке увидел давнишний пост про агрегацию детальной статистики... с запросами конечно не помогу, а вот хранить можно было-бы в отдельной базе в куче таблиц. В новых мускулях есть вроде возможность создавать пакованные read-only таблицы и объединять их во вьюшку для выборки по ним одним запросом. И решение вроде не сложное, и экономия диска и удобство работы.

Уже давно реализированна