LINUX.ORG.RU
ФорумTalks

Промышленные базы данных


0

0

Посоветуйте, какую серьезную базу данных реального времени использовать для организации системы телемеханики. Значений в существующей MS SQL дофига, и планируется еще добвлять постоянно. От базы требуется высокое быстродействие и гарантированно малый отклик.

Есть выход на производителей ПО, они могут перевести свою SCADA на любую базу данных, которую я им предложу. MS SQL уже заколебала.

З.Ы. ОС - винда (портировать SCADA под Linux разработчики не хотят, хотя множество их ПО работает у нас именно под Linux)

★★★

а какая разница, в какойоси будут данные храниться?

или программа идет со своим экземпляром СУБД?

gr_buza ★★★★
()
Ответ на: комментарий от anonymousI

Стоит 2 гига, не справляется, + своп в 2 гига почти полный. Хочу 4 поставить или 8, но боссы деньгу не выделяют....

Zlyden ★★★
() автор топика
Ответ на: комментарий от Zlyden

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

Zlyden ★★★
() автор топика
Ответ на: комментарий от Zlyden

с MS SQL?

точно кое-какие проблемы будут.

минимальные проблемы будут с сибейзом, но это шило на мыло - тот же диспетчер блокировок, та же архитектура, те же проблемы.

в общем, геморрой при миграции (куда угодно) будет 100%.

другое дело свести его к минимуму.

gr_buza ★★★★
()
Ответ на: комментарий от gr_buza

>БД сколько занимает?

Не очень много, гигов 8. Там проблема со скоростями транзакции - сигналы (~20 000) с объектов с дикретностью в 1 минуту непрерывно валятся в базу и сохраняются там. При работе в SCADA-системе производится куча выборок этих сигналов.

Проблема со сложными выборками из базы

Zlyden ★★★
() автор топика
Ответ на: комментарий от gr_buza

>в общем, геморрой при миграции (куда угодно) будет 100%.

Геморой будет у разработчиков, которые будут переписывать свое ПО.

Zlyden ★★★
() автор топика
Ответ на: комментарий от gr_buza

хм, если поддержку обеспечивают они - то тогда проблем гарантированно не будет (ну если будут, то не у тебя точно :))).

в таком случае надо ориентироваться на масштаб и цену.

самый просто выход - поставить пераццкий оракл.

если всерьез задумана миграция с переписыванием всего и вся, то я не вижу препятствий покупке двух дополнительных планок памяти - это же на порядок дешевле, чем переводить БД на другой софт!

gr_buza ★★★★
()
Ответ на: комментарий от Zlyden

Мож настройки БД потвикать? Она ж у тя в основном для записи? Вот и пусть збрасывает кэш почаще

anonymous
()
Ответ на: комментарий от Zlyden

ну, при грамотной установке/конфигурации думаю справится.

надо смотреть у тома (asktom.oracle.com), какие проблемы были у народа насчет realtime обработки бааальшой кучи запросов.

gr_buza ★★★★
()
Ответ на: комментарий от Zlyden

Объясни боссам что телематика загнётся и ты не в ответе за такое "решение". 4 гига минимум, с поледующим апгрейдом до 8.

Нарисуй доку - представь текущую ситуацию, что будет если не апгрейдить, пару графиков чтобы наглядней было манагерам объяснять момент кирдыка. Не поймёт - сделай cc до его манагера.

anonymousI
()
Ответ на: комментарий от SteepZ

блин, опять дети вылезли.

да, оракл хорош, не спорю.

но есть два фактора.

1) если его поставит пиАнЭр - то он ничем лучше мсскуля не будет (возможно, будет даже хуже).

2) не пиАнЭр (т.е. грамотный DBA) стоит очень больших денег (посмотри объявления на sql.ru) и достается отнюдь нетривиальными методами.

исходя из этого минимального набора аргументов "против" уже можно думать, а не оверхед ли это, а надо ли такое щастье вообще?

gr_buza ★★★★
()
Ответ на: комментарий от SteepZ

>Он создан для огромных баз данных.

Не забывай, что при этом он хочет огромные объемы памяти под себя. А не каких-то жалких 2Гб. Это ему только чтобы запустить себя

anonymous
()
Ответ на: комментарий от anonymousI

+1, я тоже хотел предложить нечто подобное.

рисуешь график (можно даже от балды, главное чтобы был нарастающий) запросов в секунду (минуту, час, нужное подчеркнуть) к БД за последние полгода.

и объясняешь, что наша БД выдержит еще столько-то, а потом все рухнет.

вот чтобы этого не было, я прошу (и тут уже список требований).

элементарно :))

gr_buza ★★★★
()
Ответ на: комментарий от anonymous

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

вот у меня сервак с гигом рамы держит 4-гиговую базу, и ничего, все вроде нормально *сплевывает*.

gr_buza ★★★★
()
Ответ на: комментарий от SteepZ

нету, уже отрубили :(

=)))))))

З.Ы. не нервничай, но в самом деле замечание деццкое :)))

gr_buza ★★★★
()
Ответ на: комментарий от robot12

очень смешно.

а PL/SQL bdb держит?

а репликацию?

а вьюхи/триггеры/прочие радости кодера?

gr_buza ★★★★
()
Ответ на: комментарий от bugmaker

>MaxDB глянь. Она хотя бы халявное и можно потестить по чёрному ещё до переезда.

Гляну, спасибо

Zlyden ★★★
() автор топика
Ответ на: комментарий от anonymousI

>Ага у меня в мобильнике Oracle Lite 2 терабайтную базу поддерживает.

Гы, ты мобилу на грузовике возишь?:-)

Zlyden ★★★
() автор топика
Ответ на: комментарий от anonymousI

Наверное, наждо этот вопрос экспериментом решить. Сделать сестовый сервак и погонять разные базы

Zlyden ★★★
() автор топика

если нужно что-то промышленно-надёжное стоит посмотреть SolidDB

anonymous
()

Думаю Oracle тебе бы подошёл, только тюнить пришлось бы и Oracle и саму систему где он вертелся бы..

MiracleMan ★★★★★
()

ставь mysql - быстро работает она! гугль весь на mysql работает.

anonymous
()
Ответ на: комментарий от Ay49Mihas

Я спорю чтоли? Просто говорить что я дал детский совет, хотя сам он не против оракла, это попахивает чем-то.

SteepZ
()
Ответ на: комментарий от SteepZ

я не против оракла, я говорю что в данном контексте есть куча альтернатив.

и более того, оракл среди них не самая лучшая.

а кричать "оракл рулес, фсе остальное фдомну" все могут, в том числе и я.

но это не совет, это пустые вопли.

в общем, почитай литературу, поможет.

З.Ы. nothing personal, правда важнее.

gr_buza ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.