архитектура для высокой доступности

Question

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

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

требование:

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

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

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

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

Какое у вас решение?

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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