Итак, вы ☐ твитнули, ☐ написали в блог, ☐ опубликовали пресс-релиз, ☐ написали в комментариях о том, что знаете способ преодолеть CAP-теорему. Ваша идея не сработает. И вот почему:
☐ вы предполагаете, что сбоев софта\железа\сети никогда не случается
☐ вы на самом деле всего-лишь перенесли проблему на другой логический слой
☐ ваше решение эквивалетно одному уже существующему, которое не преодолевает CAP-теорему
☐ вы на самом деле построили AP-систему (доступность и устойчивость к разделению, но не постоянная согласованность данных)
☐ вы на самом деле построили CP-систему(согласованность данных и устойчивость к разделению, но не постоянная доступность)
☐ вы на самом деле построили нераспределенную систему
А особенно в ваших планах плохо следующее:
☐ задержка — реально существующая вещь
☐ большая задержа это тоже самое, что недоступность сервиса
☐ топология сетей меняется со временем
☐ разделение сети на части может случиться в более чем одном месте
☐ отделённая часть сети может пропасть навсегда
☐ отделённая на время часть сети для остальных частей системы неотличима от полностью упавшей
☐ клиенты — это тоже часть распределённой системы
☐ стабильное хранилище данных может оказаться нестабильным
☐ сбои сети обязательно произойдут
☐ сбои железа обязательно произойдут
☐ человеческие ошибки обязательно произойдут
☐ удалённые данные восстанут после синхронизации с ранее упавшими нодами
☐ из-за отличий временных меток ваши данные будут путешествовать во времени туда и обратно
☐ вещи случаются одновременно на разных машинах
☐ некоторые побочные эффекты невозможно откатить, как транзакцию
☐ сбои случаются и в самых критических частях вашей системы
☐ спроектировать распределённую систему на самом деле тяжело
☐ а реализовать — ещё тяжелее
Плюс ещё вот такие технические трудности могут возникнуть:
☐ ваше решение требует центрального компонента, который не может быть недоступен
☐ оказывается, в read-only режиме действительно не доступна запись
☐ размер кворум-группы в вашей системе не может быть изменен
☐ размер кластера в вашей системе не может быть изменен
☐ использования «бесконечного таймаута» — это не решение проблемы потерянных сообщений
☐ ваша система предполагает хранение данных вечно, для чего, конечно же, необходимо безразмерное хранилище
☐ пересинхронизация данных потребует больше трафика, чем всё остальное вместе взятое
☐ «подтверждение получения» это не то же самое, что «подтверждение обработки»
☐ вы даже не ждете пока данные запишутся на диск
☐ вы предполагаете, что небольшие периоды недоступности приемлимы
☐ вы базируетесь на теории, которая пока есть только на бумаге
И вот что я о вас думаю:
☐ отличная попытка, но вопиюще неверная реклама
☐ вы переизобрели уже существующую технологию, причём сделали это плохо
☐ ну и вообще, прочитайте определение термина «теорема»
☐ и еще термина «распределенная система»
☐ вы понятия не имеете, что делаете
☐ вы хотя бы знаете, что такое "логические часы"?
☐ вам вообще не следует заведовать данными других людей
☐ вы предполагаете, что сбоев софта\железа\сети никогда не случается
☐ вы на самом деле всего-лишь перенесли проблему на другой логический слой
☐ ваше решение эквивалетно одному уже существующему, которое не преодолевает CAP-теорему
☐ вы на самом деле построили AP-систему (доступность и устойчивость к разделению, но не постоянная согласованность данных)
☐ вы на самом деле построили CP-систему(согласованность данных и устойчивость к разделению, но не постоянная доступность)
☐ вы на самом деле построили нераспределенную систему
А особенно в ваших планах плохо следующее:
☐ задержка — реально существующая вещь
☐ большая задержа это тоже самое, что недоступность сервиса
☐ топология сетей меняется со временем
☐ разделение сети на части может случиться в более чем одном месте
☐ отделённая часть сети может пропасть навсегда
☐ отделённая на время часть сети для остальных частей системы неотличима от полностью упавшей
☐ клиенты — это тоже часть распределённой системы
☐ стабильное хранилище данных может оказаться нестабильным
☐ сбои сети обязательно произойдут
☐ сбои железа обязательно произойдут
☐ человеческие ошибки обязательно произойдут
☐ удалённые данные восстанут после синхронизации с ранее упавшими нодами
☐ из-за отличий временных меток ваши данные будут путешествовать во времени туда и обратно
☐ вещи случаются одновременно на разных машинах
☐ некоторые побочные эффекты невозможно откатить, как транзакцию
☐ сбои случаются и в самых критических частях вашей системы
☐ спроектировать распределённую систему на самом деле тяжело
☐ а реализовать — ещё тяжелее
Плюс ещё вот такие технические трудности могут возникнуть:
☐ ваше решение требует центрального компонента, который не может быть недоступен
☐ оказывается, в read-only режиме действительно не доступна запись
☐ размер кворум-группы в вашей системе не может быть изменен
☐ размер кластера в вашей системе не может быть изменен
☐ использования «бесконечного таймаута» — это не решение проблемы потерянных сообщений
☐ ваша система предполагает хранение данных вечно, для чего, конечно же, необходимо безразмерное хранилище
☐ пересинхронизация данных потребует больше трафика, чем всё остальное вместе взятое
☐ «подтверждение получения» это не то же самое, что «подтверждение обработки»
☐ вы даже не ждете пока данные запишутся на диск
☐ вы предполагаете, что небольшие периоды недоступности приемлимы
☐ вы базируетесь на теории, которая пока есть только на бумаге
И вот что я о вас думаю:
☐ отличная попытка, но вопиюще неверная реклама
☐ вы переизобрели уже существующую технологию, причём сделали это плохо
☐ ну и вообще, прочитайте определение термина «теорема»
☐ и еще термина «распределенная система»
☐ вы понятия не имеете, что делаете
☐ вы хотя бы знаете, что такое "логические часы"?
☐ вам вообще не следует заведовать данными других людей