Erlang отказоустойчивое применение: PA или CA CAP?

Question

Я уже задавал вопрос относительно простого отказоустойчивого мягкого веб-приложения реального времени для магазина доставки пиццы.

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

Более того, в отличие от "настоящего" веб-сервиса, эта система не предназначена для большого количества пользователей - ее используют только несколько диспетчеров (телефонных операторов) и несколько драйверов доставки (поскольку на данный момент у меня нет требования предоставлять прямой доступ). к услуге для реальных клиентов; прямой доступ имеют только диспетчеры и водители доставки).

Следовательно, этот вопрос немного более общий.

Я обнаружил, что для того, чтобы сделать правильный выбор для хранилища данных NoSQL для этого приложения, первое, что мне нужно сделать, это сделать выбор между CA, PA а также CP согласно теореме CAP.

Теперь в книге " Создание веб-приложений с использованием Erlang" говорится, что "хотя она [Mnesia] не является базой данных SQL, она представляет собой базу данных CA, подобную базе данных SQL. Она не будет обрабатывать сетевой раздел". В той же книге говорится, что база данных CouchDB является PA база данных.

Имея это в виду, я думаю, что самое первое, что мне нужно сделать с моим заявлением, это решить, что означает термин "отказоустойчивость" в отношении CAP.

Простое требование, которое у меня есть, - это иметь приложение доступным 24/7(R1). Другая причина в том, что нет необходимости в масштабировании, у приложения будет очень скромное количество пользователей (вероятно, невозможно иметь тысячи диспетчеров) (R2).

Теперь, требует ли R1 приложение для обеспечения согласованности, доступности и допуска разделов и с какими приоритетами?

Какой тип хранилища данных лучше справится со следующими проблемами:

1. Обеспечение круглосуточной доступности для диспетчера (человека, который принимает телефонные звонки от клиентов и использует CRM) для просмотра записей о клиентах и ​​размещения заказов в системе;
2. Поиск текущих текущих заказов и их статус (размещен, отправлен, отправлен, доставлен, доставлен) в режиме реального времени;
3. Отслеживайте местоположение всех работающих транспортных средств и их полезную нагрузку в режиме реального времени;
4. Восстановите любую часть системы после сбоя системы или сбоя сети, чтобы продолжить предоставлять 1,2 и 3;

Подводя итог: какое хранилище данных (CA, PA или CP) лучше подойдет для системы, описанной выше? Какой тип хранилища данных будет лучше соответствовать требованиям R1?

Answer 1

• По вашему требованию 24/ вы ищете базу данных с (высокой) доступностью, потому что вы хотите, чтобы ваши запросы выполнялись каждый раз (даже если они являются только ошибочными результатами).
• Netsplit разрушит всю вашу систему, когда у вас нет терпимости к разделам
• Постоянство приятно иметь, но вы можете иметь только 2 из 3.

Ваша лучшая ставка будет решением PA. Я настоятельно рекомендую решение, которое было вдохновлено Amazon Dynamo. Самые известные реализации динамо - это riak и couchdb. Riak даже позволяет вам изменить PA на другую форму, настроив реплики чтения и записи.

Answer 2

Во-первых, не путайте CAP "Доступность" с "Высокая доступность". Они не имеют ничего общего друг с другом. A в CAP просто означает "Все узлы БД могут отвечать на запросы". Чтобы получить высокую доступность, вы должны находиться в нескольких центрах обработки данных, у вас должны быть надежные документированные процедуры обслуживания, расширения и т. Д. Все это не зависит от вашего выбора CAP.

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

В-третьих, всегда оценивайте свой выбор против мейнстрима. Вы можете просто перейти к CA (MySQL) и быстро переключиться на рабов, когда возникнут проблемы. Будьте реалистичны в отношении затрат (и рисков) использования новых технологий. Если вы действительно ожидаете, что ваша система будет работать в течение 5 лет без простоев, попросите подтверждение того, что кто-то еще работал с этой базой данных в течение 5 лет без простоев.

Если вы выберете "AP" и у вас есть удаленные люди (водители и т. Д.), Вам нужно написать приложение, которое хранит их данные на телефоне и отправляет их в фоновом режиме (с повторными попытками). Конечно, вы могли бы сделать это независимо от того, была ли ваша база данных CA или AP.

Если вы хотите много работать, вы можете:

• Увеличьте MTBF (среднее время между сбоями) - купите резервные блоки питания, купите двойные карты Ethernet и т. Д.

• Уменьшите MTTR (среднее время до восстановления) - просто убедитесь, что в случае сбоя вы можете быстро восстановиться. (Перейти к рабу)

Я видел, как люди тратят десятки тысяч долларов на MTBF, но не работают 8 часов, пока они восстанавливают свою резервную копию. Имеет больше смысла, чтобы убедиться, что MTTR низкий, прежде чем атаковать MTBF.