Шардирование (sharding). Эпизод 1: Начало и шардирование по идентификатору

[zubrbonasus]

Сложно понять когда хранят таблицы по 1Тб не прибегая к шардированию. Конечно есть сложности как хранить данные и в большей степени как читать данные, но проще найти решение этим сложностям, чем обслуживать таблицу в 1Тб.

[AndrewJD]

Ситуации, конечно, бывают разные, но для 'взрослых' RDBMS типа Oracle или MSSQL терабайт - это не проблема.

[Miheev2]

Если система шардироаания простая, не сложно отдельный кластер для данных клиентов сделать только в стране.
В последними технологиями что использую, NewSql, точно не вижу.

[Miheev2]

NewSQL эту проблему и решает. В этом же суть шардинга. Это НЕ репликация.
Почитайте подробнее.
Данные распределяются равномерно, по нужному количеству копий на каждой отдельной ноде. Стандартно 3 копии.
И нужно иметь N+1 нод, что бы не бояться падения любой ноды, которое может быть окончательным, с полной потерей её данных.

У меня в CocroachDB Нода бывает падает, и лежит уже неделю как, а я и не знал. Не заметно.

[Miheev2]

Пока не могу понять нормально.
Но вроде понял, что одна и та же таблица должна быть разделена на виртуальные части, что бы одни хранились в одних нодах, а другие в других?

И делить на отдельные кластера нельзя?

Тогда понятно. Но в платной версии CocroqchDB есть разделение по регионам, но не знаю, есть ли то что нужно.
Действительно, нужно подумать как искать по всей таблице, но что бы по условию часть лежала только на определённых нодах.