Таким образом нужен скрипт, который автоматом генерирует экстеншны и необходимо придумать, как максимально часто можно было эти экстеншны добавлять в *. Что можете посоветовать в такой ситуации? Естественно установка таких монстров, как FreePBX и подобных - не выход из ситуации...... Разумеется, могут быть и дургие пути. С удовольствием выслушаю мнение специалистов
_________________
«Choose a job you love, and you will never have to work a day in your life» — Confucius
| duran писал(а): |
| Я больше смотрю в сторону relatime модулей для работы с *. Потому как тоже могу добавлять екстеншны и делать соотв. записи в sip&iax.conf Или все же не стоит? |
ну если вы программер то конечно же это будет самое идеальное решение. просто напишите свою софтину\модуль\скрипт которые будут делать именно то что вам нужно. биллинг который я предложил - естестно несколько громозок для этой задачи. просто он бы справился бы с вашей задачей как готовое решение. но если можете сделать свое - то что мешает?
_________________
«Choose a job you love, and you will never have to work a day in your life» — Confucius
| noize писал(а): |
| не стоит. Если будет много юзеров, то ваш мускуль сдохнет от количества запросов |
Скорее уж сдохнет *, чем MySQL. Правильно настроенный MySQL будет в любои случае при использовании * иметь очень большой запас в производительности.
_________________
OpenSUSE 11.2 / Asterisk-trunk / Celeron 1100 (512mb) / chan_lcr / Linksys / Aastra 9112i
http://igorg.ru
| anest писал(а): |
| но если можете сделать свое - то что мешает? |
_________________
«Choose a job you love, and you will never have to work a day in your life» — Confucius
но вот идея переписывать conf-файлы и дергать asterisk перечитывать их мне совершенно не нравится.
| edo1 писал(а): |
| но вот идея переписывать conf-файлы и дергать asterisk перечитывать их мне совершенно не нравится. |
А он статику дергает только при загрузке.
А так - разницы нет, база данных тоже в файлах пасется.
_________________
ys
http://voip.rus.net/
| edo1 писал(а): |
| А он статику дергает только при загрузке. |
нафига тогда вообще придумали эти базы?? нафига их вообще использовать?? давайте все дружно их выбросим на помойку и станем использовать примитивные плоские файлы - раз разницы всеравно никакой нету!!!
зы: насколько мне известно - sql придуман именно для оптимизациии и ускорения процесса выборки данных. причем алгоритм там намного эффективенее и за счет "параллельной", если так можно выразиться, выборки. а еще тот факт что файлы то на винте в обоих случаях, но я поражен что вы не знаете того что в случае с sql - база всасывается в память при старте сервиса и кешируется там, и там же все операции и идут, а на диск сбрасывается позже - в этом вторая ступень ускорения базы. я не прав? я по умолчанию предполагаю такие популярные реализации как MySQL и Postgres, те реализации что тупо работают с плоским файлом (есть же всякие) я не воспринимаю ни в каком качестве - не стоит пытаться на этом спекулировать.
Added after 4 minutes:
| duran писал(а): |
| А насколько часто * опрашивает базу? |
а вот это - абсолютно не важно в данном случае!!! потому что в обоих случаях - с sql и с плоским файлом - кол-во обращений от * будет одинаковым.
впрочем возможно наоборот важно
потому что разница на мой взгляд всетки есть - или обращение идет к медленному винту в плоский файл или обращение к памяти, где операции почти мгновенны. плюс - в случае с базой - там чтоб сделать выборку из 3000 записей - скажем под номером 2892 - алгоритм не даст прочитывать все 2891 записи перед тем как он найдет нужную. секёте? тепреь сложите в кучу всё что я сказал выше и получите наглядную картину. ps: я не эксперт в данном вопросе. просто иногда стараюсь мыслить логически, используя ту информацию которую получил из инета, и иногда мне это удаётся.
_________________
«Choose a job you love, and you will never have to work a day in your life» — Confucius
| anest писал(а): |
| нафига тогда вообще придумали эти базы?? нафига их вообще использовать?? |
| Цитата: |
| зы: насколько мне известно - sql придуман именно для оптимизациии и ускорения процесса выборки данных. |
| Цитата: |
| причем алгоритм там намного эффективенее и за счет "параллельной", если так можно выразиться, выборки. |
| Цитата: |
| а еще тот факт что файлы то на винте в обоих случаях, но я поражен что вы не знаете того что в случае с sql - база всасывается в память при старте сервиса и кешируется там, и там же все операции и идут, а на диск сбрасывается позже - в этом вторая ступень ускорения базы. |
во-вторых на диск сбрасывается сразу, да ещё и команда os дается сбросить кэш на диск. ибо сохранность данных например в случае сбоя электропитания намного важнее производительности.
ну и наконец - а кэширование на уровне операционнной системы в рассчет не берете? более того, в случае жирного sql с его избыточностью формата хранения данных скорее памяти на все не хватит и придется периодически подчитываться с диска (хотя это не про случай 30k записей).
к слову - когда загоняешь даные из текстовых файлов в sql, то размер базы превышает размер этих файлов (иногда в разы), а запросы, для которых не были вовремя созданы индексы выполняются так же в разы медленнее, чем обработка исходных файлов скриптами.
| Цитата: |
| потому что разница на мой взгляд всетки есть - или обращение идет к медленному винту в плоский файл или обращение к памяти, где операции почти мгновенны. |
| Цитата: |
| плюс - в случае с базой - там чтоб сделать выборку из 3000 записей - скажем под номером 2892 - алгоритм не даст прочитывать все 2891 записи перед тем как он найдет нужную. секёте? |
применительно к asterisk - не интересовался его алгоритами работы с конфигурацией (в файлах или в бд).
но в любом случае если вы не собираете встраиваемую систему или же наоборот вам не нужно обрабатывать сотни установлений соединений в секунду - то это не то, на чем можно что-то выиграть.
сейчас железо достаточно дешево, человеческий труд намного ценнее. так вот в большинстве случаев выгоднее не то решение, которое требует меньше машинных ресурсов, а то, которое проще и удобнее в установке и обслуживании.
вопросами же оптимизации надо заниматься "точечно" - именно в тех местах, где есть или могут возникуть проблемы с производительностью.
. Я вижу один неоспоримый факт того, что DB использовать надо - это просто тупо удобно.
Не надо устраивать шаманские пляски с блокировками на доступ, это уже все сделано до нас.
Единообразный интерфейс для связки различных частей всей системы.
База может находиться вообще на другой машине и их может быть несколько.
Насчет производительности.
Любая база данных - это всеж какой-никакой, но такой монстрик на машине
. Кэшировать в памяти insert/update/delete ни одна БД в здравом уме - не будет...
Можно задействовать query cache, это даст хороший прирост для выборок (SELECT), но только при условии, что их намного больше, чем операций по модернизации данных. Т.к. при любой модернизации - весь кеш таблицы сбрасывается. И еще не понятно, даст ли это какой выигрыш, если, например, на каждые три select, приходиться один update.
И еще, главный выигрыш даст, конечно, использование индексов там, где это надо и не использование их там, где не надо.
Например, для CDR польза от индексов очень сильно сомнительна. (Там же одни INSERT'ы) и это сильно тормознет вставку данных, т.к. при этом индексы будут пересчитываться.. Проще по cron'у обрабатывать "черновую" CDR табличку и уже формировать нужные нам данные для статистики.
Для sip/iax realtime индексы на некоторые поля помогут, т.к. там только регистрация вносит данные, а она производиться (обычно) реже, чем выборка направлений при вызовах. (но польза от включения query cache все равно сомнительна).
_________________
ys
http://voip.rus.net/