...

вторник, 20 августа 2013 г.

[Перевод] Чек-лист преодоления CAP-теоремы

Итак, вы ☐ твитнули, ☐ написали в блог, ☐ опубликовали пресс-релиз, ☐ написали в комментариях о том, что знаете способ преодолеть CAP-теорему. Ваша идея не сработает. И вот почему:

☐ вы предполагаете, что сбоев софта\железа\сети никогда не случается

☐ вы на самом деле всего-лишь перенесли проблему на другой логический слой

☐ ваше решение эквивалетно одному уже существующему, которое не преодолевает CAP-теорему

☐ вы на самом деле построили AP-систему (доступность и устойчивость к разделению, но не постоянная согласованность данных)

☐ вы на самом деле построили CP-систему(согласованность данных и устойчивость к разделению, но не постоянная доступность)

☐ вы на самом деле построили нераспределенную систему


А особенно в ваших планах плохо следующее:



☐ задержка — реально существующая вещь

☐ большая задержа это тоже самое, что недоступность сервиса

☐ топология сетей меняется со временем

☐ разделение сети на части может случиться в более чем одном месте

☐ отделённая часть сети может пропасть навсегда

☐ отделённая на время часть сети для остальных частей системы неотличима от полностью упавшей

☐ клиенты — это тоже часть распределённой системы

☐ стабильное хранилище данных может оказаться нестабильным

☐ сбои сети обязательно произойдут

☐ сбои железа обязательно произойдут

☐ человеческие ошибки обязательно произойдут

☐ удалённые данные восстанут после синхронизации с ранее упавшими нодами

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

☐ вещи случаются одновременно на разных машинах

☐ некоторые побочные эффекты невозможно откатить, как транзакцию

☐ сбои случаются и в самых критических частях вашей системы

☐ спроектировать распределённую систему на самом деле тяжело

☐ а реализовать — ещё тяжелее


Плюс ещё вот такие технические трудности могут возникнуть:


☐ ваше решение требует центрального компонента, который не может быть недоступен

☐ оказывается, в read-only режиме действительно не доступна запись

☐ размер кворум-группы в вашей системе не может быть изменен

☐ размер кластера в вашей системе не может быть изменен

☐ использования «бесконечного таймаута» — это не решение проблемы потерянных сообщений

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

☐ пересинхронизация данных потребует больше трафика, чем всё остальное вместе взятое

☐ «подтверждение получения» это не то же самое, что «подтверждение обработки»

☐ вы даже не ждете пока данные запишутся на диск

☐ вы предполагаете, что небольшие периоды недоступности приемлимы

☐ вы базируетесь на теории, которая пока есть только на бумаге


И вот что я о вас думаю:


☐ отличная попытка, но вопиюще неверная реклама

☐ вы переизобрели уже существующую технологию, причём сделали это плохо

☐ ну и вообще, прочитайте определение термина «теорема»

☐ и еще термина «распределенная система»

☐ вы понятия не имеете, что делаете

☐ вы хотя бы знаете, что такое "логические часы"?

☐ вам вообще не следует заведовать данными других людей


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: 'You Say What You Like, Because They Like What You Say' - http://www.medialens.org/index.php/alerts/alert-archive/alerts-2013/731-you-say-what-you-like-because-they-like-what-you-say.html


Комментариев нет:

Отправить комментарий