архитектура для высокой доступности - PullRequest
5 голосов
/ 19 января 2011

У меня есть такой сценарий:

У вас есть заводская технологическая линия, которая работает 24/7. Простои чрезвычайно дороги. Программное обеспечение, управляющее всеми различными частями, должно использовать общую форму хранения базы данных. Основная причина этого заключается в том, чтобы знать, в каком состоянии находится фабрика. Например, некоторые продукты могут быть смешаны при использовании одного и того же набора оборудования, а другие, безусловно, нет.

Требования:

  • Я хочу, чтобы программное обеспечение могло обнаружить ошибку в одной части установка должна привести к остановке машины на расстоянии более 1 км. поэтому хранение данных в ПЛК не вариант.
  • Частые обновления и обновления до заводской среды
  • нагрузка (в компьютерном выражении) будет действительно низкой.

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

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

Когда одна система выйдет из строя, она выйдет из строя без помех. Традиционная база данных sql может быть более трудной для обновления, когда таблицы изменяются, и этот главный подчиненный сложнее настроить.

Каким было бы ваше решение?

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

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

Ответы [ 3 ]

3 голосов
/ 20 января 2011

Я не думаю, что это вопрос sql / nosql. Все Postgres, MySQL и MS SQL Server имеют какой-либо вариант кластера или горячего резервирования.

Конфигурирование - одноразовая вещь, но любой вариант NoSQL может вызвать головную боль от кода сверху вниз, если вы пытаетесь сделать что-то фундаментально реляционное на платформе, которая отказалась от реляционных для целей запускать такие вещи, как Amazon или Facebook. Конфигурация одна, кодирование навсегда.

Так что я бы сказал, придерживайтесь проверенного и верного решения и запустите горячую репликацию.

Это также предоставляет решение для обновлений. Типичной последовательностью является «переключение» в режим ожидания, обновление мастера, возврат к мастеру, обновление режима ожидания и возобновление работы. С деталями, специфичными для ситуации, конечно.

2 голосов
/ 22 января 2011

Использовать установленную СУБД, которая изначально поддерживает такие вещи

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

1 голос
/ 22 января 2011

Вам необходимо избегать единичных точек отказа.

Все основные игроки в нашем мире dbms предлагают как минимум один способ избежать превращения самой базы данных в единую точку отказа.Я мог бы спросить, могут ли они распространять изменения достаточно быстро для ваших производственных процессов.(Или обновление данных на самом деле не проблема? Не могу сказать по вашему вопросу.) Моя работа с БД в производстве ограничена автомобильной и химической промышленностью.Микросекунды для них не имели значения.

Но дбм не единственное, что может потерпеть неудачу.«Всегда работающий» означает, что клиенты тоже должны всегда работать.Клиентское оборудование, подключения к сети, сеть и сетевые серверы, вероятно, имеют единую точку отказа.Отказоустойчивые серверы имеют несколько источников питания, несколько сетевых карт и т. Д.

«Всегда работать» действительно дорого.У меня такое ощущение, что база данных не станет самой большой проблемой для вашей компании.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...