Традиционное разбиение включает в себя разбиение таблиц на небольшое количество частей и запуск каждого фрагмента (или «фрагмента») в отдельной базе данных на отдельной машине.Из-за большого размера осколка этот механизм может быть подвержен дисбалансу из-за горячих точек и неравномерного роста, о чем свидетельствует инцидент Foursquare .Кроме того, поскольку каждый осколок запускается на отдельном компьютере, эти системы могут испытывать проблемы с доступностью, если один из компьютеров выходит из строя.Чтобы смягчить эту проблему, большинство систем шардинга, включая MongoDB, используют группы реплик.Каждая машина заменяется набором из трех машин в режиме «ведущий» и «два ведомых».Таким образом, если машина выходит из строя, для обслуживания данных остаются две реплики.Есть несколько проблем с этим дизайном: во-первых, если реплика выходит из строя в группе реплик, и в группе остается только два участника, чтобы довести счет репликации до трех, данные на одной из этих двух машин должныбыть клонированным.Поскольку во всем кластере есть только две машины, которые можно использовать для повторного создания реплики, во время повторной репликации на одной из этих машин будет перетаскиваться огромное , что вызывает серьезные проблемы с производительностью.на рассматриваемом осколке (для копирования 1 ТБ по гигабитной ссылке требуется два часа ).Вторая проблема заключается в том, что когда одна из реплик выходит из строя, ее необходимо заменить на новую машину.Даже если в кластере достаточно резервной емкости для решения проблемы репликации, эта резервная емкость не может быть использована для исправления ситуации.Единственный способ решить эту проблему - заменить машину.Это становится очень сложным с эксплуатационной точки зрения, поскольку размеры кластеров увеличиваются до сотен или тысяч машин.
Решение Bigtable + GFS решает эти проблемы.Во-первых, данные таблицы разбиты на гораздо более мелкозернистые «таблетки».Типичная машина в кластере Bigtable часто имеет 500+ планшетов.Если возникает дисбаланс, его решение - это просто вопрос переноса небольшого количества планшетов с одного компьютера на другой.Если TabletServer выходит из строя, поскольку набор данных разбивается и реплицируется с такой тонкой детализацией, могут быть сотни машин, которые участвуют в процессе восстановления, что распределяет нагрузку на восстановление и ускоряет время восстановления.Кроме того, поскольку данные не привязаны к определенной машине или машинам, резервная емкость на всех машинах в кластере может быть применена к сбою.Операционные требования для замены компьютера отсутствуют, поскольку для устранения дисбаланса репликации можно использовать любую свободную емкость во всем кластере.
- Даг Джадд, генеральный директор, Hypertable Inc.