|
|
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Уважаемые профессионалы, помогите советом. АСКУЭ - автоматизированная система коммерческого учета электроэнергии. В общем виде ситуация такая: у потребителя стоит счетчик(и), передающий(е) через определенный софт и хард данные по энергоучету (оооочень много циферок) на сервер БД. Вопрос: какая СУБД для этого лучше подойдет? Сюда не посылать: http://www.sql.ru/forum/actualthread.aspx?tid=177596&hl=%e0%f1%ea%f3%fd ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 11:05 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Берите Кашу - считается, что это круто. З.Ы Посмотрите в сторону MSSQL, Oracle. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 11:10 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
мгммм... Кашу? Простите, не понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 11:11 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Zяй мгммм... Кашу? Простите, не понял? http://www.sql.ru/forum/actualthread.aspx?tid=351164 Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 11:25 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Zяймгммм... Кашу? Простите, не понял? Вот например ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 11:26 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Вопрос автору. Ваш вопрос относится к выбору системы учета электроэнергии или к выбору СУБД для разрабатываемой вами системы учета электроэнергии? Т.к, если второе, то наверно вы должны в своем вопросе оперировать именно критериями выбора СУБД "без привязки к АСКУЭ", ибо самой СУБД без разницы, что вы там учитываете: - кол-во одновременно работающих пользователей, поддерживаемые OC, объёмы данных и операций т.д. и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 11:54 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
antandВопрос автору. Ваш вопрос относится к выбору системы учета электроэнергии или к выбору СУБД для разрабатываемой вами системы учета электроэнергии? Второе. Мне необходима СУБД справляющаяся с громадными объемами данных, поступающих с не менее огромной скоростью. Функционал особого значения не имеет. Желательно не за бешенные деньги. И... мне кажется Cache - серьезный кандидат... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 12:08 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Zяй у потребителя стоит счетчик(и), передающий(е) через определенный софт и хард данные по энергоучету (оооочень много циферок) на сервер БД. Так уж и много циферок. Вы что, снимаете показания счетчика каждую секунду? Zяй Вопрос: какая СУБД для этого лучше подойдет? Скорее всего, любая. Но если хотите получить хороший ответ - обрисуйте желаемое более подробно. Сколько счетчиков? Какая дискретность? Что с этими цифрами будет делаться дальше? Что за "определенный софт"? Итп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 12:09 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
softwarer Так уж и много циферок. Вы что, снимаете показания счетчика каждую секунду? каждые 3 и каждые 30 минут. однако кроме этого возможны иные операции считывания. вплоть до 0,5 сек. softwarer Сколько счетчиков? Какая дискретность? Что с этими цифрами будет делаться дальше? Что за "определенный софт"? Итп. Количество счетчиков? примерно 3000 (три тысячи). а может и больше. цифры будут просто хранится. периодически надо выдавать отчеты. основное: надо БЫСТРО принять инфу и НАДЕЖНО сохранить и хранить ее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 12:23 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Zяй Вопрос: какая СУБД для этого лучше подойдет? RENaissance +1 и на АСКУЭ и на техническом учете стоит MS SQL Server 2000 на АСКУЭ база 1.1 гига на техническом учете около 40 гиг все лётает некоторые конторы предлагали варианты АСКУЭ на Oracle, но "побрились" ввиду своей нерасторопности ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 13:25 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
andy st и на АСКУЭ и на техническом учете стоит MS SQL Server 2000 на АСКУЭ база 1.1 гига на техническом учете около 40 гиг все лётает если не секрет, где же это такое стоит? какие масштабы? и как давно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 13:37 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Zяй если не секрет, где же это такое стоит? какие масштабы? и как давно? на базе этого сделана АСКУЭ. поставлена не очень давно, но в списке реализованных проектов у поставщика уже появились.)) по масштабам не могу сказать, что сделали, но собирались обасучивать 6 входных ГПП. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 13:57 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Zяйкаждые 3 и каждые 30 минут. Не очень понял этой фразы. Рабочее предположение - снимаете каждые три минуты. Zяйоднако кроме этого возможны иные операции считывания. вплоть до 0,5 сек. А вот это уже интересно? Как часто такие операции, как долго, на скольких счетчиках сразу? ZяйКоличество счетчиков? примерно 3000 (три тысячи). а может и больше. OK. Давайте возьмем 10'000 счетчиков раз в три минуты. Это будет примерно 60 записей в секунду. Уверен, любая СУБД при нормальной реализации кода выдюжит такой поток. Просто для сравнения - на своей домашней машине запустил серию "одиночный insert - commit", получил скорость порядка 6000 записей в секунду. И это не пытаясь оптимизироваться под этот режим, при самом тупом коде. Что касается объемов - недостаточно данных, чтобы оценить. Первый вопрос - за какой период данные нужно хранить и за какой период будут строиться отчеты. Zяйцифры будут просто хранится. периодически надо выдавать отчеты. основное: надо БЫСТРО принять инфу и НАДЕЖНО сохранить и хранить ее. Полагаю, стоит выдвинуть еще одно требование: минимальное время простоя. Поскольку любой простой грозит потерей данных, накапливающихся во время простоя. Итого, выбирайте именно исходя из надежного хранения-восстановления. Подчеркну еще раз: уверен, что при правильной реализации потянет любая БД. Я бы естественно кивал в сторону Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 14:18 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
предлагаю взять ту, по которой имеется наиболее грамотный специалист.. Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 17:12 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
ZяйУважаемые профессионалы, помогите советом. АСКУЭ - автоматизированная система коммерческого учета электроэнергии. В общем виде ситуация такая: у потребителя стоит счетчик(и), передающий(е) через определенный софт и хард данные по энергоучету (оооочень много циферок) на сервер БД. Вопрос: какая СУБД для этого лучше подойдет? Сюда не посылать: http://www.sql.ru/forum/actualthread.aspx?tid=177596&hl=%e0%f1%ea%f3%fd На самом деле эта задача очень просто решается и выбор СУБД здесь играет второстепенную роль. Я подобную задачу уже пару раз успешно решал. СУБД подойдет любая коммерческая реляционная (Oracle, DB2, MS SQL, Sybase) да и на MySql в принципе наверное можно сделать. Делается например вот как: 1. Ставится load-balancer, точнее их 2 с failover. 2. За ним ставится некоторое количество дешевых серверов которые пишут поток приходящих транзакций в общую файловую систему (например VERITAS Cluster File System, Sun Cluster, Generalized Parallel File System - GPFS, ...), каждые N минут закрывая старый файл и открывая новый. В любой момент времени 1 (и только один) сервер пишет в 1 файл. Файловая система на которую пишутся данные должна лежать на хорошем дисковом массиве и подключается через SAN. Файловая система бэкапится в онлайне, без остановки системы. 3. Ставится сервак подороже, цепляется на тот же SAN, на нем гоняется софт который грузит эти данные в вашу любимую реляционную СУБД. 4. В случае если СУБД позволяет репликацию (например Oracle) ставится standby server в другом здании (возможно даже в другом городе если сеть позволяет), на случай пожара/наводнения/землетрясения/беспорядков со стрельбой. Данная архитектура проверена мной лично на практике. Могу гарантировать что: 1. Данные не будут потеряны в результате отказа оборудования 2. Данные будут доступны 24*7*365 3. Объем данных которые будут потеряны в результате стихийного бедствия не превысит X минут работы (в случае когда есть standby server). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 20:10 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Вдогонку, Решение выше - когда объмы данных от 300 гиг до нескольких терабайт в час. При более мелких объемах можно обойтись просто реляционной СУБД без кластера кэширующих данные серверов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.11.2006, 20:14 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Oracle. Не ошибёшься. Если выбрать что-то другое, то можно ошибиться, и к тебе будут претензии. Зачем это надо? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.11.2006, 19:23 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Знаю эту задачу. Или нет, лучше так - занимаюсь подобной в газовой отрасли. Собираются данные с приборов учета с известной дискретностью. В нашем случае - по региону раз в час. Количество узлов учета - несколько тысяч. Узкое место - непосредственно получение данных по не всегда адекватным каналам связи. С точки зрения БД всё IMHO, весьма и весьма тривиально. Т.е. рядовой усредненный склад я считаю более сложным с точки зрения сервера БД. Однако, если делать систему в масштабах страны, то, полагаю, до 50% проблем будет связана с репликацией. Опять же IMHO. Ответ: любая коммерческая СУБД исходя из цены, ОС, наличия/доступности специалистов и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2006, 09:38 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
ZяйУважаемые профессионалы, помогите советом. В одной моей подопечной фирме это крутится под ораклом. Вы изобретаете велосипед? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2006, 11:46 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Не сказал где. Октябрьская железная дорога, Энергосбыт ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.11.2006, 11:47 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Cat2Не сказал где. Октябрьская железная дорога, Энергосбыт АСКУЭ в Энергосбыте? Оригинально! По сути вопроса добавлю: 1. для получасовок доступность 24*7*365 - обязательное условие, т.к. это информация весьма недешевая, когда она поступает своевременно. 2. данным с интервалом менее 30 мин. высокая доступность не нужна, т.к. они собираются на случай очередного "Чагино". Мне сомнительно, что их даже в СУБД заливать надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 10:26 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Dried Gagarin 2. данным с интервалом менее 30 мин. высокая доступность не нужна, т.к. они собираются на случай очередного "Чагино". Мне сомнительно, что их даже в СУБД заливать надо. Это просто фантазии не хватает, как эти данные далее применить. Если система только ради учета - согласен. А когда начинают задумываться о нормировании расходов, оптимизации режимов потребления, особенно в условиях резко изменющегося потребления (электродуговые печи, прокатные станы и т.п.) то тут минутные данные выходят на первый план. Для выявления и анализа аварийных ситуаций минутные данные не канают. Есть аппаратно-программные комплексы, которые собирают секундные данных по большому количеству каналов (в т.ч. и по релейным - для отлова последовательностей срабатывания защит, выключателей и пр). А в случае фиксации аварии (задаются критерии) собираются миллисекундные данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 10:54 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Dried Gagarin 2. данным с интервалом менее 30 мин. высокая доступность не нужна, т.к. они собираются на случай очередного "Чагино". Мне сомнительно, что их даже в СУБД заливать надо. В СУБД заливать как раз обязательно, и анализировать. Чтобы не было очередного "Чагино". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.11.2006, 20:51 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Зл0йВ СУБД заливать как раз обязательно, и анализировать. Чтобы не было очередного "Чагино". Окей, окей - надо... вот только кто этим займется. Энергосбытам дали рынком на сутки вперед и балансирующим под зад для ускорения - вот они и забегали технологии прогнозирования потребления внедрять. А кто теперь сетевикам/диспетчерам/СКУПЭшникам под зад даст? По мне так тотальное АСКУячивание страны надо сделать очередным национальным проектом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.11.2006, 09:08 |
|
||
|
АСКУЭ: какую СУБД выбрать?
|
|||
|---|---|---|---|
|
#18+
Собственно Зл0й всё правильно сказал. Сам сталкивался с системой на MySQL. Тут больше проблем с каналами связи приходилось решать чем с сервером. :( И про правильный бэкап главное не забудьте. ЗЫ: Привет коллеге. Интересно, теперь в связи с ФОРЭМ каждый энергосбыт кинулся "велосипед" изобретать. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 16:45 |
|
||
|
|
start [/forum/topic.php?fid=35&fpage=11&tid=1552571]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
24ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
89ms |
get tp. blocked users: |
2ms |
| others: | 242ms |
| total: | 398ms |
| 0 / 0 |
