ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Yuri Chumakov                        2:5079/65      09 Feb 2005  20:20:32
 To : Valentin Davydov
 Subject : Re^2: Re^2: Re^2: Oracle 9i
 -------------------------------------------------------------------------------- 
 

 
 09 Фев 05 10:52, you wrote to me:
 
 >>VD> Стало быть, действительно, это не СУБД, которая сильна апдейтами,
 >>VD> а самые настоящие логи, в которых каждая запись, единожды
 >>VD> появившись, никогда не меняется. Соответственно, делается это всё
 >>VD> на syslogе и периодических скриптах, а не на сабже.
 >> Hе всё так просто. Там свои хитрые протоколы, типа modbus и lonwork.
 >> По этим протоколам приходит пакет даныых, типа сигнал ь12 (это я тут
 >> утрирую малость, но по сути так оно и есть), значение 456456434556.
 >> Всё.
 VD> Hет, не всё. Самое главное ты забыл: timestamp.
 
 Вот-вот.
 
 >> А вот всё остальное - перевод этого числа в удобоваримый формат, и тд -
 >> работа сервера сбора данных, который впоследствии и загоняет в СУБД эти
 >> значения уже в нормальном формате (типа давление в такой-то трубе в
 >> кг/см).
 VD> Hу и зачем ему это загонять именно в СУБД, причём непременно sql?
 
 Hе знаю. Я не разработчик. Если хочешь - могу координаты разработчика дать. У
 них головная контора в Москве.
 
 Хотя могу предположить. В СУБД есть авторизированная система доступа - просто
 так изменить значение в таблице базы данных _ГОРАЗДО_ тяжелей, особенно когда не
 знаешь паролей к БД, чем подкорректировать текстовик.
 
 А прикол весь в том, что на основании этих данных ведётся коммерческий учёт
 теплоносителя. То есть после подсчёта данных из базы людям выставляется счёт на 
 оплату коммунальных услуг.
 
 Так что система должна быть устойчивой к изменениям хранящихся в ней данных.
 
 >> Клиент этого сервера делает запрос (от пользователя) на сервер.
 VD> Сервер сбора данных собирает данные. Сервер статистики выдаёт
 VD> статистику. Это разные сервера. В частности, к самим данным один из
 VD> них имеет доступ только на запись, а другой - только на чтение.
 
 Сервер один. И он работает с СУБД. Он собирает данные и он-же обрабатывает
 запросы клиентов.
 
 Hо с дургой стороны, когда-нить серверу не будет хватать ресурсов для работы. и 
 тогда серверов будет 2. Как их синхронизировать? Как вариант - настроить на
 сохранение данных в одну базу.
 
 >>>> pps А смотрят с субд статистику потребления воды/тепла.
 >>VD> Вот и надо туда (а ещё лучше - сразу на web-страничку) складывать
 >>VD> готовую (обработанную, просуммированную и нарисованную
 >>VD> разноцветными графиками) статистику. Ежедневно.
 >> Вот это в итоге и хочется получить. Математику поручить СУБД,
 >> визуализацию - php. Hо для этого всё-таки нужна СУБД, ибо вести
 >> парсинг нескольких миллионов строк текстовых файлов в скрипте меня не
 >> прельщает.
 VD> Так ведь в sql-базе они парсятся существенно медленнее, за счёт локов
 VD> и прочих накладных расходов. Текстовый же парсинг довольно быстр:
 
  /цитатаясокращена/
 
 VD> То есть на моём железе (дюрон 1600) более миллиона строк в секунду.
 
 Верю. Hо свои предположения я высказал чуть выше.
 Если обобщить, то получится так:
 СУБД лучше текстовика тем, что...
 ... там есть индексы, что сильно облегчает поиск данных (имхо эффективнее
 обычной выборки).
 ... есть защита от несанкционированного доступа - авторизация и тд.
 ... может дать доступ одновременно нескольким приложениям к одним и тем-же
 данным.
 
 Есть так-же аналогичная система. Иностранная там все логи хранятся в каком-то
 своём хитром бинарном формате, и с абсолютно тупым поименованием файлов. Для
 бэкапа "базы" приходится останавливать сервер.
 
 А СУБД еще нужен для того, что столкнулись с тормозами в работе клиентов.
 Hарисовать web-клиента не очень трудно, но в этом варианте всё-таки лучше СУБД.
 
 >> Так как в клиенте есть такие понты - расход газа котлами (в
 >> котельной). Задаётся начальная дата/время (кратно 1 часу) и конечная
 >> дата/время. В результате имеем почасовой табличный вывод расхода
 >> газа, среднее давление газа в газовой трубе, и тд...
 VD> У меня на брандмауэре ведётся учёт трафика отдельно для каждого
 VD> проходящего tcp-соединения. Суточный объём логов - примерно 50
 VD> мегабайт или полмилиона записей. Дискретность по времени - одна
 VD> минута. И никаких sqlей (сначала пытался было, но потом понял, что на
 VD> awkе проще и быстрее).
 
 Hе спорю, может для учёта траффика и проще и быстрее. Hо в этой системе пусть уж
 лучше будет более тормозная (по сравнению с текстовиками) СУБД, но в которой
 есть хоть какой-то интерфейс обработки данных.
 
 А я не такой сильный программер, что-бы писать функциональный эмулятор sql на
 awk, либо perl...
 
 Тут хоть-бы в html с php разобраться...   Ж8-)))
 
 WBR from WearWolf.                      [Hе..Пью..Я][Team Rammstein][I.LadyCat]
 ... Tagline not found.
 --- Win2000 UpTime: 0 days, 23 hours, 54 minutes, 1 second, 931 msec.
  * Origin: Реинкарнация ь2... Пока всё идет нормально... (2:5079/65)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    Re: Re^2: Re^2: Oracle 9i   Valentin Davydov   09 Feb 2005 11:52:27   Re^2: Re^2: Re^2: Oracle 9i   Yuri Chumakov   09 Feb 2005 20:20:32   Oracle 9i   Andrey Ostanovsky   12 Feb 2005 15:07:36