Комментарии 8
Сложно понять когда хранят таблицы по 1Тб не прибегая к шардированию. Конечно есть сложности как хранить данные и в большей степени как читать данные, но проще найти решение этим сложностям, чем обслуживать таблицу в 1Тб.
А еще в статье забыли про ситуации законного шардирования
Когда персональные данные клиентов должны находится на серверах их страны
И вроде бы достаточно монолита на одном сервере с бекапами, но нужно разбивать хранение на шарды, а так же делать мулттимастер-структуру с дублированием основного функционала что бы клиент мог подключатся и взаимодейсвовать напрямую с сервером в его стране, а не делать запрос на единый маршрутизатор в другой стране что бы потом получить данные с "локального" сервера
Если система шардироаания простая, не сложно отдельный кластер для данных клиентов сделать только в стране.
В последними технологиями что использую, NewSql, точно не вижу.
Почитал по диагонали про NewSql - такого не хватало лет 10 назад, сейчас уже другая реальность увы(
Если нужно сделать что бы локальная нода безшовно синхронизировалась с остальными нодами то начинаются танцы. Точнее можно хоть тот же NewSql или даже реализации на уровне postgress использовать для кластеризации, но стоит только выпасть какой то из нод (при условии что нагружены все) то стандартные средства и готовые решения пролетают. Исключение только для вообще никак не пересекающихся данных - когда от "соседей" нужно только чтение, без сравнений только отдача.
Есть готовые решения для "рассинхрона" между нодами, но они плохо работают если потеря связи более чем на час, а данных набралось гигабайты.
NewSQL эту проблему и решает. В этом же суть шардинга. Это НЕ репликация.
Почитайте подробнее.
Данные распределяются равномерно, по нужному количеству копий на каждой отдельной ноде. Стандартно 3 копии.
И нужно иметь N+1 нод, что бы не бояться падения любой ноды, которое может быть окончательным, с полной потерей её данных.
У меня в CocroachDB Нода бывает падает, и лежит уже неделю как, а я и не знал. Не заметно.
вот - равномерно!
именно про это я и говорил - лет десять назад пилил костыли на базе postgress как раз для такого, подводных в такой "равномерости" масса
.
сейчас "равномерность" редко нужна. точнее нужна но в рамках локального кластера и для этого уже есть готовые решения, тупо на уровне брокера.
А я говорю про зонирование. Есть три страны: A, B и С. В стране А 5 нод, в стране B 4 ноды, а в стране С всего две ноды.
Нужна архитектура когда все ноды работают в едином пространстве, но с разбитием на локальные потоки. Как раз в рамках потока может быть равномерная репликация но не более
Доступ к нодам за пределами потока должен предоставлятся на уровне локальной ноды (могут быть тунели для вобще печальных ситуциаций такие как Китай).
В случа если все локальные ноды недоступны клиент может безшовно получить доступ к внешнему ближайшему потоку. Блокировки на операции быть не должно. Редактирование и просмотр недоступного контента информируется заглушками, а создание сохранение из буфера\кеша сохранятся в буфер всего кластера (что бы иметь возможноть дополнять\редактировать уже сохраненное) для последующей записи на востановленный сервер.
Описаную выше архитектуру NewSQL может разве что облизать. И такие задачи сейчас классика, с законами про персональные данные и внедрение повсеместных фаерволов внутри стран.
Пока не могу понять нормально.
Но вроде понял, что одна и та же таблица должна быть разделена на виртуальные части, что бы одни хранились в одних нодах, а другие в других?
И делить на отдельные кластера нельзя?
Тогда понятно. Но в платной версии CocroqchDB есть разделение по регионам, но не знаю, есть ли то что нужно.
Действительно, нужно подумать как искать по всей таблице, но что бы по условию часть лежала только на определённых нодах.
Шардирование (sharding). Эпизод 1: Начало и шардирование по идентификатору