Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Выбрать базу для системы контроля промоборудования  [new]
AltCtrlDel
Member

Откуда:
Сообщений: 82
zeehond
сбор данных по-любому имеет смысл буферизовать, если не нравится хранилище на файловой системе - заведите простую таблицу без индексов и периодический процесс, который из неё будет читать и уже раскладывать всё как надо


Мне казалось, что если собирать за секунду со всех объектов то накопится 64-128К, такой размер в памяти уместится и приемлим для записи в базу. А записывать реже, ну можно, только тогда по запросам последних данных придётся отдавать часть из базы, часть из самодельного кэша, что гемор.
Баз со встроенным кэшем на запись+чтение, что не существует?

zeehond
если всем 4000 одновременным клиентам надо работать одновременно со всеми 16TB - то дела плохи


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

zeehond
репликация в том виде, в котором она нормально работает на opensource базах данных - как правило асинхронная, и при падении мастера в момент отставания репликации на slave данные за время отставания могут потеряться
оцените эти риски, если пара минут данных может потеряться - может быть вам будет достаточно MySQL или Postrges, с master-slave репликацией и failover на slave


Вот тут как раз я не разбираюсь, у какой базы с этим лучше? Потеря по всем объектам за пару минут очень не желательна.

Что дадут проприетарные СУБД в этом плане и какие?

zeehond
если нет - можно синхронно реплицировать данные, которые пишутся на диск, на уровне файловой системы (G
FS, DRBD или же hardware-решение, какой-нибудь NetApp Filer)


а тут вопрос с "горячей" заменой.
3 дек 11, 23:10    [11701920]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
AltCtrlDel
Member

Откуда:
Сообщений: 82
Dimitry Sibiryakov
Сейчас я опять буду нудеть: "в случае восстановления" после чего? Какие у вас
катастрофические сценарии заложены в ТЗ?


После падения сервера, гибели винта, ну что там ещё может произойти.

Атомной войны точно не случится. ТЗ ещё только составляется, но там нужно указать максимальный гэп. И минуты заказчику не понравятся. Особенно, если можно этого избежать заплатив разово, скажем, килодоллар - два.
3 дек 11, 23:18    [11701941]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

AltCtrlDel
После падения сервера, гибели винта, ну что там ещё может произойти.

Вот это "что там ещё" и надо детально расписать. Гибель винта переживёт зеркало. "Падения
сервера" - бред чайников, надо расписывать конкретные причины и конкретные их последствия.

Килобаксом не обойтись, даже не надейтесь.

Posted via ActualForum NNTP Server 1.4

3 дек 11, 23:25    [11701963]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
zeehond
Member [заблокирован]

Откуда:
Сообщений: 2535
AltCtrlDel
zeehond
сбор данных по-любому имеет смысл буферизовать, если не нравится хранилище на файловой системе - заведите простую таблицу без индексов и периодический процесс, который из неё будет читать и уже раскладывать всё как надо


Мне казалось, что если собирать за секунду со всех объектов то накопится 64-128К, такой размер в памяти уместится и приемлим для записи в базу. А записывать реже, ну можно, только тогда по запросам последних данных придётся отдавать часть из базы, часть из самодельного кэша, что гемор.
Баз со встроенным кэшем на запись+чтение, что не существует?


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

AltCtrlDel
zeehond
если всем 4000 одновременным клиентам надо работать одновременно со всеми 16TB - то дела плохи


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


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


AltCtrlDel
zeehond
репликация в том виде, в котором она нормально работает на opensource базах данных - как правило асинхронная, и при падении мастера в момент отставания репликации на slave данные за время отставания могут потеряться
оцените эти риски, если пара минут данных может потеряться - может быть вам будет достаточно MySQL или Postrges, с master-slave репликацией и failover на slave


Вот тут как раз я не разбираюсь, у какой базы с этим лучше? Потеря по всем объектам за пару минут очень не желательна.
Что дадут проприетарные СУБД в этом плане и какие?


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

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

AltCtrlDel
zeehond
если нет - можно синхронно реплицировать данные, которые пишутся на диск, на уровне файловой системы (G
FS, DRBD или же hardware-решение, какой-нибудь NetApp Filer)


а тут вопрос с "горячей" заменой.


ну он как бы решается достаточно прямолинейно, elastic IP у сервера баз данных, и/или у файлового сервера

для mysql и postgres у нас есть отработанная конфигурация с репликацией файловой системы, 2 сервера с инфинибандом между ними, и с автоматическим failover-ом
то есть всегда все данные физически идентично пишутся не две отдельные машины и два рейда
файловер (переключение IP) в случае падения одной из машин на другую будет сделан в течение пары секунд
3 дек 11, 23:28    [11701975]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
AltCtrlDel
Member

Откуда:
Сообщений: 82
Dimitry Sibiryakov
Вот это "что там ещё" и надо детально расписать.

Приведите, пожалуйста примеры, что вы имеете ввиду?
В целом, я говорю про ситуацию когда сервер стал неработоспособен. Ну защиты от dDOS атак, это не функция СУБД. Частичный выход из строя железа я привёл в пример. Выход из строя сервера из-за ошибки в ПО или хакерской атаки? И как это влияет на выбор СУБД?
3 дек 11, 23:33    [11701987]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
AltCtrlDel
Member

Откуда:
Сообщений: 82
zeehond
ну то есть вам надо подумать, как отделить операционные данные от архивных так, чтобы клиент видел все данные, но при этом физически архив (он же не меняется) находился на отдельной железке
оракл умеет делать partitioning

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


Может я чего не понимаю, но два сервера (железо) по любому брать, хоть и для постгреса. А оракл
[url=]http://soft.softline.ru/oracle/oracle-database/[/url]
Enterprise Edition, лицензия на именованного пользователя - 29 269.50 руб
умножаем на 2.
[url=]http://soft.softline.ru/oracle/oracle-database-enterprise-edition-options/[/url]
Real Application Clusters - 14 172.60 руб.
Partitioning - 7 086.30 руб.

- совсем не пара сотен тысяч енотов.

Вполне возможно, что я не туда смотрю.

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


если эти логи на самом сервере, то потеряются вместе с ним. Собирать заново с объектов - теоретически можно, но узкие каналы, чистый самопал. Дороже выйти может.
4 дек 11, 00:05    [11702030]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

AltCtrlDel
Приведите, пожалуйста примеры, что вы имеете ввиду?

Повреждения файловой системы - отдельно, причём с градацией на восстановимые,
невосстановимые, затрагивающие БД, журналы транзакций и т.д. Отдельно повреждения железа,
приводящие к потере данных, такие как ошибка контроллера RAID или космический протон
пролетевший сквозь ячейку ОЗУ. Отдельно повреждения логической структуры БД. Ну и
отдельной строкой - мои любимые: затопление сервера, падение бетонной плиты и прочее
полное мгновенное уничтожение всей системы.

Для каждого из этих случаев надо расписать процедуру восстановления, расчётное время
простоя, допустимые потери данных. И быть готовым к тому, что случится что-то чего в этом
списке не будет - тогда надо заранее снять с себя ответственность за это. Учитесь у
страховых компаний. У них куча опыта по части ПП.

Posted via ActualForum NNTP Server 1.4

4 дек 11, 00:08    [11702035]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
zeehond
Member [заблокирован]

Откуда:
Сообщений: 2535
AltCtrlDel
zeehond
ну то есть вам надо подумать, как отделить операционные данные от архивных так, чтобы клиент видел все данные, но при этом физически архив (он же не меняется) находился на отдельной железке
оракл умеет делать partitioning

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


Может я чего не понимаю, но два сервера (железо) по любому брать, хоть и для постгреса. А оракл
[url=]http://soft.softline.ru/oracle/oracle-database/[/url]
Enterprise Edition, лицензия на именованного пользователя - 29 269.50 руб
умножаем на 2.
[url=]http://soft.softline.ru/oracle/oracle-database-enterprise-edition-options/[/url]
Real Application Clusters - 14 172.60 руб.
Partitioning - 7 086.30 руб.

- совсем не пара сотен тысяч енотов.

Вполне возможно, что я не туда смотрю.


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


то есть вам нужно будет этих лицензий на 1000 датчиков + 4000 пользователей = 5000
что даёт совсем другие цифры на выходе

ну или берёте процессорную лицензию, на каждое из 8 или 12 ядер процессора

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


если эти логи на самом сервере, то потеряются вместе с ним. Собирать заново с объектов - теоретически можно, но узкие каналы, чистый самопал. Дороже выйти может.


мм, ну я же написал "где-то отдельно", на фронтальном сервере, принимающем запросы или LB
на отдельной сетевой файловой системе
короче неважно как, лишь бы отдельно от БД
4 дек 11, 00:20    [11702066]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6640
AltCtrlDel
zeehond
ну то есть вам надо подумать, как отделить операционные данные от архивных так, чтобы клиент видел все данные, но при этом физически архив (он же не меняется) находился на отдельной железке
оракл умеет делать partitioning

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


Может я чего не понимаю, но два сервера (железо) по любому брать, хоть и для постгреса. А оракл
[url=]http://soft.softline.ru/oracle/oracle-database/[/url]
Enterprise Edition, лицензия на именованного пользователя - 29 269.50 руб
умножаем на 2.
[url=]http://soft.softline.ru/oracle/oracle-database-enterprise-edition-options/[/url]
Real Application Clusters - 14 172.60 руб.
Partitioning - 7 086.30 руб.

- совсем не пара сотен тысяч енотов.

Вполне возможно, что я не туда смотрю.

Когда мы были молодыми, и чушь прекрасную несли (с)

Осталось умножить на (1000+4000) именованных пользователей =)
4 дек 11, 00:28    [11702084]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
AltCtrlDel
Member

Откуда:
Сообщений: 82
zeehond
смотрите туда вы неправильно понимаете словосочетание "именованный пользователь"
Oracle
В трактовке Oracle, именованный пользователь — это лицо, уполномоченное использовать программы, установленные на одном или нескольких серверах, независимо от того, использует ли оно активно программу в какой-либо момент времени или нет. Автоматическое устройство (не требующее участия человека) при возможности доступа к программам считается именованным пользователем в дополнение ко всем лицам, уполномоченным использовать программы. При использовании аппаратных или программных мультиплексных средств число пользователей определяется на входе мультиплексора.


то есть вам нужно будет этих лицензий на 1000 датчиков + 4000 пользователей = 5000


Хм? Серьёзно? Если будет 2 сервера, то при чём тут откуда данные поступают и кто их смотрит в браузерах на отдельных компах, они же не пользуются ораклом напрямую? Тогда получится что лицензию на именованного пользователя стоит покупать только для софта результатом работы которого вообще кроме одного человека никто не пользуется. Чтото не так. В пнд спрошу в софтлайне.

А вообще, вы мне сдорово помогли в плане понимания, чего мне надо. ))
4 дек 11, 00:35    [11702100]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
AltCtrlDel
Member

Откуда:
Сообщений: 82
Siemargl
Осталось умножить на (1000+4000) именованных пользователей =)


Вы меня, с zeehond-ом прямо напугали. Может мне уже надо ораклу платить за что тони будь?

Впрочем, уже нашёл источник [url=]http://www.ostin.ru/?id=43&entityType=HTML[/url]
- как я ошибался :(

Ладно, зато выбор сократился. Постгресс, как бы по асинхронее, помногоядернее, и более cоответствует SQL чем MySQL? Да там ещё и функции на сях цепляются (вдруг пригодится)? И лицензия посвободнее? Посмотрю в его сторону.
4 дек 11, 00:50    [11702128]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

AltCtrlDel
Посмотрю в его сторону.

И всё же смотреть надо в первую очередь надо на то, что уже есть у заказчика. Подо что у
него уже налажена инфраструктура и наняты администраторы. Потому что без админов такая
система жить не может. Точнее, жить-то она сможет, но только до первого сбоя. Потом
целиком и безвозвратно накроется.

Posted via ActualForum NNTP Server 1.4

4 дек 11, 01:01    [11702153]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
AltCtrlDel
Member

Откуда:
Сообщений: 82
zeehond
оракл умеет делать partitioning
опенсорсные базы вроде бы тоже умеют (здесь уместен такой американский жест согнутыми пальцами, обозначающий кавычки)

проприетарная СУБД с синхронной репликацией - это оракл


Пардон за назойливость, стобы уж два раза не вставать. А как у MSSQL с репликацией? без согнутых пальцев?
Цены то не такие кусачие.
4 дек 11, 01:18    [11702174]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
SERG1257
Member

Откуда:
Сообщений: 2933
Ээ подождите с лицензиями, рублями и баксами. Любая распрекрасная СУБД ничего не стоит без грамотного админа и не менее грамотного разработчика. Поэтому пользуемся традиционным алгоритмом
1 Что уже есть
2 что лучше знаете вы либо ваш админ
3 прочее
Про СУБД для пользователей. Опять же к ней нужен хотя бы простенький файловер типа асинхронной передачи логов (или непростенький, синхронный, дорогой). Его же удобно использовать как тест/uat сервер
С вас еще простой демон для приема/буферизации. Какие они бывают, как обеспечивается дублирование и т.п. лучше пошукайте на форуме линуксоидов, наверняка кто-то что-то подобное уже делал. Традиционные СУБД с этой ролью справляются плохо.
Устаревшие данные (после нескольких дней/неделю/месяц) переправляются в третью СУБД (или пыльный темный угол) для всяких OLAP анализов тенденций и т.п.
Все СУБД не обязательно должны быть от одного производителя или на одной платформе (хотя и желательно для минимизации бардака)

AltCtrlDel
Вот тут как раз я не разбираюсь, у какой базы с этим лучше?
Теоретически если СУБД для пользователей сломается - последние данные можно перезалить с демона. Но сам процесс более геморной

AltCtrlDel
Что дадут проприетарные СУБД в этом плане и какие?

1 поддержка, в случае если что-то пошло не так. Вы таким образом прикрываете свою пятую точку.
2 отработанные и более оттестированные best practice
3 больший выбор грамотных спецов. Еще раз подчеркну - люди ваш главный козырь и слабое звено

AltCtrlDel
Тогда получится что лицензию на именованного пользователя стоит покупать только для софта результатом работы которого вообще кроме одного человека никто не пользуется.
Ну и у оракла для EE минимальный пакет 25 именованных лицензий

Dimitry Sibiryakov
Для каждого из этих случаев надо расписать процедуру восстановления, расчётное время
простоя, допустимые потери данных. И быть готовым к тому, что случится что-то чего в этом
списке не будет - тогда надо заранее снять с себя ответственность за это.
+1
Тяжело в учении, легко в бою. Пот кровь бережет (с) А.В. Суворов
4 дек 11, 01:27    [11702185]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

SERG1257
Все СУБД не обязательно должны быть от одного производителя или на одной платформе (хотя и
желательно для минимизации бардака)

Угу. Во фронт-энде для оперативных данных вполне может стоять что-то In-Memory Key-Value,
в то время как в бэк-энде для аналитики и архивов что-нибудь классическое. Всё-таки
классика напряжётся выдавать значения сотнями тысяч налево-направо...

Posted via ActualForum NNTP Server 1.4

4 дек 11, 02:03    [11702222]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
DPH3
Member

Откуда:
Сообщений: 456
Dimitry Sibiryakov,

C учетом требований по надежности и ограничений по бюджету, решений, подозреваю, три:

1) DB2 Express C, с годовой поддержкой, поднятым HADR и ручным шардингом.
Плюсы - все хорошо с надежностью
Минусы - 2000$ в год на сервер (правда, с stanby можно будет делать выборки), придется руками делать шардинг.

2) PostgreSQL, опять шардинг, какая-нибудь синхронная репликация
Плюсы - бесплатно
Минусы - нормальная синхронная репликация появилась совсем недавно, опытных DBA найти довольно сложно.

3) Informix, с HADR и партицированием
Плюсы - вроде бы все, что нужно есть в бесплатной версии.
Минусы - найти DBA будет оччень непросто.

Я бы посоветовал начать искать DBA для всех трех вариантов одновременно. Как только найдете подходящего - на этой БД и остановиться. Теоретически, можно даже попробовать поискать на "удаленку", хотя это может оказаться и не сильно дешевле.
Искать, кстати, лучше прямо в профильных форумах на sql.ru
И вот совсем не стоит экономить на DBA для таких систем.

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

Решение на Oracle будет стоить сильно за сотню килобаксов.

Еще можно, конечно, попробовать руками делать logshipping и DRBD, но тут могут быть подводные камни...
4 дек 11, 14:25    [11702741]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
zeehond
Member [заблокирован]

Откуда:
Сообщений: 2535
DPH3

Еще можно, конечно, попробовать руками делать logshipping и DRBD, но тут могут быть подводные камни...


для репликации на уровне FS есть кстати ешё Lustre
4 дек 11, 15:14    [11702831]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
репликации на уровне FS
Guest
zeehond
DPH3
Еще можно, конечно, попробовать руками делать logshipping и DRBD, но тут могут быть подводные камни...


для репликации на уровне FS есть кстати ешё Lustre

Репликацию активно-меняющейся СУБД?
4 дек 11, 15:54    [11702897]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
zeehond
Member [заблокирован]

Откуда:
Сообщений: 2535
репликации на уровне FS
zeehond
пропущено...


для репликации на уровне FS есть кстати ешё Lustre

Репликацию активно-меняющейся СУБД?


ну если она не меняется, или меняется редко - то какой смысл в её синхронной репликации?

в общем, если у ТС есть нормальный бюджет на железки, лучше делать репликацию аппаратно, на чём-то типа этого
4 дек 11, 17:55    [11703188]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
AltCtrlDel
Member

Откуда:
Сообщений: 82
DPH3
C учетом требований по надежности и ограничений по бюджету, решений, подозреваю, три:

1) DB2 Express C, с годовой поддержкой, поднятым HADR и ручным шардингом.
2) PostgreSQL, опять шардинг, какая-нибудь синхронная репликация
3) Informix, с HADR и партицированием


Спасибо, я внимательно слежу за топиком. Из вами перечисленного, к моей задачи, как я понимаю, ближе всего Informix (OLTP), но я с ним никогда не имел дела. Рассмотрю как вариант.
4 дек 11, 18:20    [11703229]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
Yo.!
Guest
AltCtrlDel
Может я чего не понимаю, но два сервера (железо) по любому брать, хоть и для постгреса. А оракл
[url=]http://soft.softline.ru/oracle/oracle-database/[/url]
Enterprise Edition, лицензия на именованного пользователя - 29 269.50 руб
умножаем на 2.
[url=]http://soft.softline.ru/oracle/oracle-database-enterprise-edition-options/[/url]
Real Application Clusters - 14 172.60 руб.
Partitioning - 7 086.30 руб.

- совсем не пара сотен тысяч енотов.

Вполне возможно, что я не туда смотрю.

совсем не туда смотрите. для ваших задач ЕЕ редакция вам нафиг не нужна, вам SE1 + partitioning view + SE standbay явно хватит с головой. разъясняю нюансы:

1. стендбай в редакции SE и SE1 есть, но вырезан хрень которая доставляет на вторую машину логи. но люди научились выкручиваться, выставляют минимальные размеры на арклоги и копирую ручными скриптами арклоги. тут хрень в том, что если примарная машина загнется можно потерять размер арклога, это порядка 60 секунд. если лениво вникать в нюансы наколенных скриптиков есть продукт dbvisit который все это делают в красивой гуйне

2. взрослового партитионинга в SE и SE1 редакции нет, но есть partitioning view которых под вашу задачу хватит с головой

3. лицензии на два двухсокетных сервера потянут на сумму порядка $30, $5k лицензия dbvisit

но вообще архитектура у вас бредовая. любой здоровый спец в вашем случае бы разделил две задачи. первая писать показания. я бы поднял простенький файловер кластер и писал бы на кластерную файловую систему в банальные текстовые файлы. вторая прожевывать файлы и писать в субд уже агригированные данные. я бы держал субд на локальных дисках первого сервера + копии логов и инкрементный бэкапы на СХД. если сервер с субд накрывается, запускается второй сервер, на нем разворачивается инкрементный бэкап, накатывается лог и пережевываются все файлики накопившиеся за время простоя субд. т.е. и показания не теряются и по лицензиям всего $15k
4 дек 11, 20:06    [11703479]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
DPH3
Member

Откуда:
Сообщений: 456
Yo.!,
В кои-то веки я согласен с Yo :)
С учетом простоты поиска DBA, подобное решение может быть наиболее адекватным.
4 дек 11, 20:53    [11703622]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
DPH3
Member

Откуда:
Сообщений: 456
zeehond
в общем, если у ТС есть нормальный бюджет на железки, лучше делать репликацию аппаратно, на чём-то типа этого


Я бы тут был поосторожнее. На предыдущей работе был весьма неприятный опыт работы с NetApp, в результате перешли на DataGuard...
Подробности, увы, спрятаны в отделе эксплуатации.
4 дек 11, 20:57    [11703631]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
AltCtrlDel
Member

Откуда:
Сообщений: 82
Yo.!
первая писать показания. я бы поднял простенький файловер кластер и писал бы на кластерную файловую систему в банальные текстовые файлы. вторая прожевывать файлы и писать в субд уже агригированные данные. я бы держал субд на локальных дисках первого сервера + копии логов и инкрементный бэкапы на СХД. если сервер с субд накрывается, запускается второй сервер, на нем разворачивается инкрементный бэкап, накатывается лог и пережевываются все файлики накопившиеся за время простоя субд. т.е. и показания не теряются и по лицензиям всего $15k


А когда приходит запрос данных, вначале самопалом искать по текстовым файлам, а потом уже по базе? Основные запросы по последним данным.

И почему в текстовые? Чего не в XML, так ещё больше будут?

zeehond мне советовал предварительно накапливать во временной таблице. Тогда, хотя бы, в запросах можно было бы эту таблицу с основной по UNION ALL объединять. Но, если таблицы будут в одной базе, это только улучшает производительность, но не проблему восстановления. Как там с UNION ALL по разным базам в разных СУБД пока не смотрел. А текстовые файлы, наверно, не стоит.
4 дек 11, 21:08    [11703669]     Ответить | Цитировать Сообщить модератору
 Re: Выбрать базу для системы контроля промоборудования  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54791

AltCtrlDel
А когда приходит запрос данных, вначале самопалом искать по текстовым файлам, а потом уже
по базе?

А вон там, повыше, я для кого распинался с советом держать оперативные данные в ОЗУ?..

Posted via ActualForum NNTP Server 1.4

4 дек 11, 21:11    [11703684]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить