Basil A. Sidorovsphinx_mvВами было обещано ЛЮБОЕ количество баз данных под ЛЮБЫМ пользователем...Вам вообще ничего не было обещано.Чаще вентилируйте свою память - Вы даже цитаты Ваших слов уже не опознаете... Бывает... Не у всех проходит...
Еще одну попытку? Читайте внимательно:
Basil A. Sidorovsphinx_mvс каких пор (и в какой СУБД) право на подключение к серверу БД стало эквивалентным праву на создание базы данных на этом сервере?Firebird.
Синтаксис не такой, как у ts для mysql, но базу может создать любой пользователь , зарегистрированный на сервер. И не одну, а столько, сколько захочет .Может, посмотрите внимательно, поднапряжетесь и узнаете автора процитированой фразы?
Basil A. SidorovВы задали некорректный вопрос, уточнили его и получили ответ - проходите мимоВы до сих пор правильного ответа дать не можете! Даже после всех "подсказок"...
Basil A. Sidorovsphinx_mvс каких пор (и в какой СУБД) право на подключение к серверу БД стало эквивалентным праву на создание базы данных на этом сервере?И повторю свой ответ - Firebird. И с умолчательными настройками firebird.conf и с ограниченными.Не так давно этим Вашим ответом возмутился "первоисточник": пользователь может подключиться к серверу, но создать одну БД, не говоря уже о "сколько захочет".
ISQLSQL> create database "c:\test.fdb" user 'SYSDBA' password 'masterkey';
Statement failed, SQLSTATE = 28000
Access to database "C:\TEST.FDB" is denied by server administrator
SQL>Что же такого Вам нужно было натворить, чтобы даже firebird не захотел согласиться с Вашим "исключительно правильным" ответом?
Basil A. Sidorovsphinx_mvА у Вас "любое" почему "внезапно" трансформировалось в "нужное"...А вот топикстартер заявил, что возможность создавать и использовать базы - это круто.
Я его поправил.В стиле "это дырка, и закрывать дырки - не барское ДБАшное дело"... Впрочем, и самой "дырки" (почему-то?) предъявлено не было...

Basil A. Sidorovsphinx_mvЧто же такого Вам нужно было натворить, чтобы даже firebird не захотел согласиться с Вашим "исключительно правильным" ответом?Когда один человек сначала разрешает создание баз только по предопределённым псевдонимам, а затем пытается "скормить" isql файловый путь, а другой начинает размахивать флагом не разбирая звона, это уже даже не диагноз - это клиника.Пурга... Все заносит снегом...

Один "странный" оппонент утверждал, что право/возможность/етц на создание базы данных в firebird никак не ограничивается - "с умолчательными настройками и с ограниченными" (c) Basil A. Sidorov. Но (по факту) в примере использованы только допустимые/включеные и идеально задокументированные средства сервера. И, как оказалось, с ОГРАНИЧЕННЫМИ настройками весьма неплохо ограничиваются возможности пользователей.

К тому же.
Простой пользователь НЕ ОБЯЗАН знать, есть ли алиасы на сервере (но может быть в курсе), и обращаться к базе данных по полному пути файла.
Простой пользователь НЕ ОБЯЗАН и НЕ ДОЛЖЕН знать, установлено ли ограничение на использование только алиасов..
Прользователь ПРОСТО ПЫТАЕТСЯ ВЫПОЛНИТЬ команду на СОЗДАНИЕ базы данных! Получает отлуп при НЕСАНКЦИОНИРОВАННОМ действии! Ч.Т.Д.

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

В-общем, читайте доки - они рулес... Более чем желательно в процессе чтения понимать описываемые в "чтиве" процессы...

Basil A. SidorovПосвящается неумехам."Посвящение самому себе"? Ну, от скромности Вы не умрете!..
Но лучше расскажите, когда Вы научитесь ограничивать возможности пользователей?
А то Вас уже вторую неделю учат запрещать пользователям создавать базы данных, а до Вас все никак не дойдет, как это делается...
Basil A. Sidorov"За сохранность пользователя test администрация отвественности не несёт".
Предварительная настройка firebird.conf оставляется в качестве домашнего упражнения.
Вы уже научились создавать базы данных? Большое достижение...
А теперь Вам предстоит заблокировать эту возможность на сервере.

VovakaА о каком объеме трафика идет речь? Мне просто интересно.Трехзначные "гигабиты в секунду" (на аплинках)...
VovakaКогда писали нетфлоу-коллекторы и считали трафик по подсетям в относительно крупном провайдере лет 10 назад, это еще прокатывало. Хотя приходилось бороться с вирусами, которые веером сканили интернет весь. Иногда было, что 90% количества всех нетфлоу пакетов в сумме давали меньше процента объема трафика. Потом появился провайдер покрупнее и при попытке включить нетфлоу на 76ХХ они тупо умирали.Жили на 76ХХ... Железо справлялось... Потом расширились и поставили 10-тонники... И опять никто не умирает... Просто изначально сегментировали сбор данных.
VovakaИ тут взялись уже за SFLOW, помогло, но опять не очень надолго. В какой-то момент времени действительно всем стало пофиг куда кто ходит и как это считать, раз можно считать по полосе. Но потом зато маркетологи захотели знать, а куда и как ходят клиенты и настало веселье (200 ГБ данных в сутки с DPI Procera), но в принципе ничего, справились. Суммарный трафик в ЧНН несколько десятков ГБит/с.У нас ЧНН почти не наблюдается...

Alexander RyndinVovakaСуммарный трафик в ЧНН несколько десятков ГБит/с.Ну вот в это, кстати, вполне верится. 200 Гб в сутки - это 7 Мб/секунду.Коллекторы каждые 5 минут "нарезают" собранных данных примерно на 4-5 гигабайт. Считайте.
Alexander RyndinА вот 100 Мб/секунду (или 2,8 Тб/сутки, 1 Пб/год) у Sphinx - это что-то из разряда фантастики, ибо где это хранить можно?А банально "давить зипами" (после обработки)? Вы даже не представляете как хорошо оно жмется!..
В итоге 5-минутная нарезка "сырых" данных (4-5 Гбайт)) ложится в файлы на 400-500 мегабайт объемом.
"Сырые" данные фильтруются, агрегируются и грузятся в реляционку. После этого "острой необходимости" держать "первоисточники" нет - только в архиве "для истории"...
Alexander RyndinДа и не нужна никому эта гора мусора.Ну, во-первых, об этом Вы расскажите очень вежливым людям, которые пересылают письма с гербовыми печатями...
Во-вторых, есть "продвинутые" клиенты - как в положительном смысле (оптимизируются), так и не очень (со сверками, типа, не "парим" ли мы их случаем)...
Alexander RyndinХотя такие объемы обрабатывают в том же NTT Docomo, но не с помощью загрузки в реляционку. Сейчас есть более подходящие технологии.А разве кто-то утверждал, что весь этот поток грузится в реляционку "один-в-один"? Разговор, если меня не подводит память, был про "систему"...
Объемы данных, однако, поставили Вас в тупик... :)

Basil A. Sidorovsphinx_mvА теперь Вам предстоит заблокировать эту возможность на сервере.Ответьте на один простой вопрос: что будет, если АДБ Firebird проставит "DataBaseAccess=None", создаст пользователей, создаст псевдонимы, но не создаст базы?Проблемы админа-идиота лично мне принципиально не интересны - пусть о них болит голова у его работодателя.
Basil A. SidorovПользователи волшебным образом потеряют возможность создать базу для любого псевдонима или что?
Если у Вас не хватает собственной сообразительности, чтобы ответить на этот вопрос, Вы действительно думаете, что Вам ее кто-то в голову может положить?

Alexander RyndinВсе-таки вы имеет дело в базе с агрегированными данными, сырые данные обрабатываете пакетно. Сложность обработки по-прежнему мне не ясна.Ну, и как вот это в двух словах на пальцах объяснить? :)
Alexander RyndinЯ услышал только про "отбилить" (это в современно то мире безлимитки) и "отчетики", которые похоже по агрегированным данным.Ну вот как раз в алгоритмах агрегации данных и их производительности закопаны все собаки...
Хотя в самих алгоритмах нет ничего сверхестественного... Сначала выполняется агрегация при загрузке данных в реляционку... Списки подсетей... Проверка адресов на принадлежность к подсетям... Агрегация подсетей... Ну, а уже после загрузки в реляционку собственно биллинг. И отчеты.
Alexander RyndinРеалтаймовость в этом ракурсе мне тоже не очень понятна - зачем она?Просто "особенности национального биллинга"...
Реалтайм позволяет не накапливать необработанный набор данных. Сглаживаются пиковых значения и обеспечивается более равномерное распределение нагрузки. И потребное количество ресурсов становится более адекватным. Эффекты "бутылочного горла" никто не отменял.

К тому же у нас каким-то образом все еще актуальны тарифные планы с понижением скорости подключения в зависимости от потребленного объема (и в зависимости от зоны), а тут уже чем актуальнее текущее состояние потребления клиентов, тем меньше организационных проблем...
Alexander RyndinПро хранение данных для спецслужб более менее понятно - Вы просто делаете огромную свалку в виде zip-файлов подобно любому другому оператору. Эти данные невозможно обработать иначе как выдернув конкретный файлик за конкретное время из zipа и точечно его поанализировать. Вы ведь не используете hadoop? Скажем так...
Софт, который мы используем для сбора netflow, представляет собой узкозаточенную СУБД... То есть, выполнить "запрос" к ее данным вполне реально. И "разворачивать zip" специально для этого не приходится.
Alexander RyndinЯ бы, сопровождая такую систему, не стал бы поучать и тыкать носом админов Сбера, которые сопровождают OLTP-систему - класс систем все таки разный.Навскидку: 99.9% объема данных любого банка - близко не OLTP. Чтобы еще точнее: от OLTP в банке только данные максимум за последние пару-тройку часов. Это раз...

Ну, а то, что админы Сбербанка умудрились не разобравшись в ситуации ломать/крушить - за это таки надо "ставить на вид"... Это было два.

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

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

Vovakasphinx_mvНо вот если из-за проблем насмерть встанет биллинг оператора, то одновременно с ним вполне "приляжет" и банк, у которого могут поотваливаться арендуемые линии связи...
Как-то жестко :):) "Шютка" (с)... Сугубо для обрисовывания теоретически возможной ситуации...
VovakaПомню даже когда-то давно писали препейд платформу для телефонии, то на случай аварии на биллинге, для важных клиентов была предусмотрена возможность авторизовываться в кредит, потом они добилливались уже в офлайне.Понятное дело, что резервирование никто не отменял... И не менее понятное дело, что всегда можно перейти на "орально-мануальное" (то бишь, "кричально-ручное") управление...

К вопросу о "добиливать в офф-лайне"... В некоторых случаях это не самая хорошая идея. Когда-то давно один клиент "слезно просил" дать ему "международку" по VoIP... Ну, ему пошли навстречу... И в один непрекрасный момент случилось так, что локальную сеть этого клиента хакнули... Сработали онлайновые анализаторы трафика.. "Попадос" у этого клиент все равно получился, но уже с гораздо меньшей суммой в платежке.

Bogdanov Andreysphinx_mvПроблема в том, что если банк не может совершать платежи, то, по хорошему, и фиг с ним. Но вот если из-за проблем насмерть встанет биллинг оператора...Каждый мнит из себя Наполеона. Именно в руках оператора с его биллингом находится судьба отечества. А банки с их платежами...Слова не мальчика, но мужа... И что характерно, сразу чувствуется немеряный опыт работы - особенно в телекоммуникационной отрасли... И это было бы смешно, если бы на самом деле это не было грустным...

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

Маленький историческая "экскурс"...
"Советы постороннего", В.И. Ленин, 8(21) октября 1917 г.Комбинировать наши три главные силы: флот, рабочих и войсковые части так, чтобы непременно были заняты и ценой каких угодно потерь были удержаны : а) телефон , б) телеграф , в) железнодорожные станции, г) мосты в первую голову. Сейчас бы добавился интернет... И, уж, насколько экономически и политически "продвинутым" был автор этого "первоисточника", но банки там даже не фигурируют...

Dimitry Sibiryakovsphinx_mvПравда неплохой "сюрпрайзец"?
В чём сурпрайзец-то? В том, что жадные операторы связи завязали телекоммуникационное
оборудование на систему считания денег так, что без неё даже пожарных не вызвать?Праальна!
Надо посадить "толпу теток" на ручные коммутаторы и за "железные феликсы"... Пусть "коммутируют" и "считают"...
Заодно решим проблему с безработицей и "приподнимем" машиностроение...
Dimitry SibiryakovНу так жадность и глупость человеческая это очень далеко не новость.На календаре второе десятиление XXI века... Но дело Неда Лудда процветает....