Я не считаю себя экспертом по распределенным системам, но иногда я пытаюсь написать на эту тему. Я надеюсь, что любые ошибки здесь не слишком серьезны. Мне нравится описывать вещи, вот моя попытка.
Надежность
Надежность определяетса вероятностью потери данных независимо от того, были ли эти данные записаны в СУБД вчера или недавно. Я описываю ее как вероятность, а не как систему, которая может или не может потерять данные. Я потратил слишком много времени на развертывание в масштабах сети, чтобы утверждать, что данные никогда не будут потеряны.
Резервные копии предотвращают потерю данных, добавленных вчера или в прошлом году. Обеспечение долговечности последних изменений труднее и требует больших затрат по сложности и задержке. Решение состоит в том, чтобы получить записи журнала фиксации на нескольких серверах, прежде чем что-то будет считаться зафиксированным. Есть увлекательные и сложные способы сделать это. К счастью, большинство из нас могут использовать реализации Raft и Paxos, написанные экспертами.
В то время как моя команда в Google первой внедрила полусинхронную репликацию, кто-то другой получил признание за идею сделать ее без потерь. И это оказалось отличной идеей. Еще одна интересная идея заключается в том, что MongoDB разделил пути чтения и записи, чтобы обеспечить строго согласованное чтение и очень длительные записи без реализации синхронной репликации на пути фиксации (Raft используется в другом месте). Это умно и гибко. Пользователи получают семантику, в которой они нуждаются, платя только за более сильную семантику, когда это необходимо.
Доступность
Доступность позволяет избежать больших и малых простоев. Очевидным источником больших простоев является время, необходимое для восстановления из резервной копии и воспроизведения заархивированных журналов фиксации после сбоя сервера. Стоимость лучшей доступности - больше оборудования, потому что это часто делается с помощью наборов реплик, что-то похожее на синхронную репликацию и одно из:
Низкое время простоя - еще один способ снизить доступность и заслуживает большего PR. Источники небольшого простоя включают в себя:
- Слишком медленная фиксация - не все клиенты могут ждать, поэтому слишком медленная фиксация может также привести к потере данных.
- Java GC останавливается - я счастлив иметь небольшой опыт работы с серверами, написанными на Java
- Flash GC останавливается - задержка времени отклика флэш-памяти NAND невелика, когда вы добавляете достаточно времени задержки в 9% к процентили
- Flash TRIM киоски - мы редко обсуждаем это публично
- Другие киоски - больше вещей, которые не получают достаточного обсуждения
- Перегруженный сервер - кто виноват в этом. Похоже, что пользователи более охотно обвиняют СУБД в том, что они слишком медленны, когда подвергаются слишком большой параллельной загрузке, чем они хотят обвинить устройство хранения данных в незначительном времени отклика, когда оно подвергается смешному количеству одновременных запросов.
Детали реализации
Однажды я работал над проектом самообслуживания MySQL, который опередил свое время. К сожалению, я покинул компанию до ее развертывания. Я думаю, что это вышло на многие годы. Поскольку я был менеджером по продукту неполный рабочий день, я розмышлял о перекрестном продукте надежности и доступности в ключе двух уровнейпрочности (больше потерь, меньше потерь) и трех уровней доступности (низкий, средний, высокий).Надежность обеспечивается посредством асинхронной репликации или доставки асинхронного журнала. Существуют небольшие граници количества коммитов, которые могут быть потеряны при исчезновении основного. Низкая надежность обычно требует синхронной репликации.
Уровни доступности реализуются:
На данный момент большинство следующих комбинаций являются полезными.
Однако ресурсы ограничены, и, возможно, не стоит предоставлять их все (jack of all trades vs master of none):
(more, less lossy durability) X (low, medium, high availability)
Источник:
Надежность
Надежность определяетса вероятностью потери данных независимо от того, были ли эти данные записаны в СУБД вчера или недавно. Я описываю ее как вероятность, а не как систему, которая может или не может потерять данные. Я потратил слишком много времени на развертывание в масштабах сети, чтобы утверждать, что данные никогда не будут потеряны.
Резервные копии предотвращают потерю данных, добавленных вчера или в прошлом году. Обеспечение долговечности последних изменений труднее и требует больших затрат по сложности и задержке. Решение состоит в том, чтобы получить записи журнала фиксации на нескольких серверах, прежде чем что-то будет считаться зафиксированным. Есть увлекательные и сложные способы сделать это. К счастью, большинство из нас могут использовать реализации Raft и Paxos, написанные экспертами.
В то время как моя команда в Google первой внедрила полусинхронную репликацию, кто-то другой получил признание за идею сделать ее без потерь. И это оказалось отличной идеей. Еще одна интересная идея заключается в том, что MongoDB разделил пути чтения и записи, чтобы обеспечить строго согласованное чтение и очень длительные записи без реализации синхронной репликации на пути фиксации (Raft используется в другом месте). Это умно и гибко. Пользователи получают семантику, в которой они нуждаются, платя только за более сильную семантику, когда это необходимо.
Доступность
Доступность позволяет избежать больших и малых простоев. Очевидным источником больших простоев является время, необходимое для восстановления из резервной копии и воспроизведения заархивированных журналов фиксации после сбоя сервера. Стоимость лучшей доступности - больше оборудования, потому что это часто делается с помощью наборов реплик, что-то похожее на синхронную репликацию и одно из:
- Единый основной выбор, выбранный на основе консенсуса, с быстрым и автоматическим переключением при сбое и обнаружением отказа
- Multi-master - я предполагаю, что это означает отсутствие аварийного переключения, что может быть самым быстрым типом аварийного переключения
Низкое время простоя - еще один способ снизить доступность и заслуживает большего PR. Источники небольшого простоя включают в себя:
- Слишком медленная фиксация - не все клиенты могут ждать, поэтому слишком медленная фиксация может также привести к потере данных.
- Java GC останавливается - я счастлив иметь небольшой опыт работы с серверами, написанными на Java
- Flash GC останавливается - задержка времени отклика флэш-памяти NAND невелика, когда вы добавляете достаточно времени задержки в 9% к процентили
- Flash TRIM киоски - мы редко обсуждаем это публично
- Другие киоски - больше вещей, которые не получают достаточного обсуждения
- Перегруженный сервер - кто виноват в этом. Похоже, что пользователи более охотно обвиняют СУБД в том, что они слишком медленны, когда подвергаются слишком большой параллельной загрузке, чем они хотят обвинить устройство хранения данных в незначительном времени отклика, когда оно подвергается смешному количеству одновременных запросов.
Детали реализации
Однажды я работал над проектом самообслуживания MySQL, который опередил свое время. К сожалению, я покинул компанию до ее развертывания. Я думаю, что это вышло на многие годы. Поскольку я был менеджером по продукту неполный рабочий день, я розмышлял о перекрестном продукте надежности и доступности в ключе двух уровнейпрочности (больше потерь, меньше потерь) и трех уровней доступности (низкий, средний, высокий).Надежность обеспечивается посредством асинхронной репликации или доставки асинхронного журнала. Существуют небольшие граници количества коммитов, которые могут быть потеряны при исчезновении основного. Низкая надежность обычно требует синхронной репликации.
Уровни доступности реализуются:
- low - при сбое первичного восстановления из резервной копии и воспроизведения архивированного журнала фиксации. Это может занять несколько часов.
- medium - использование хранилища высокой доступности (EBS, Google Persistent Disk, S3 и т. д.). При сбое первичной настройки нового вычислительного узла запустите восстановление после сбоя и продолжите. Это занимает меньше времени, чем решение с низкой доступностью. Вам все еще нужны резервные копии и фиксация архивов журналов, так как хранилище высокой доступности иногда будет иметь проблемы.
- high - использовать репликацию для поддержки цели восстановления после отказа. Надеемся, что цель отработки отказа может обрабатывать запросы, чтобы получить больше пользы от дополнительного оборудования.
На данный момент большинство следующих комбинаций являются полезными.
Однако ресурсы ограничены, и, возможно, не стоит предоставлять их все (jack of all trades vs master of none):
(more, less lossy durability) X (low, medium, high availability)
Источник:
Ссылка скрыта от гостей