Шардинг* с равномерным распределением

[Akina]

А если пользователь, захочет пойти на страницу 3 тогда

А если юзер захочет пойти на предпоследнюю страницу? А шардов много, и записей ещё больше... Вы представляете, какой объём данных предстоит получить, разместить и слить вашему координатору? А если ещё и юзеров много, и все они внезапно захотели пойти на предпоследнюю страницу - причём одновременно? Судя по последним абзацам - немножко представляете. Но что с этим делать, не представляете совсем, ибо надежда на то, что "пользователи делают это редко" - ну несерьёзно, право слово. Впрочем, я тоже не представляю.

Но это как с младшим братом такого случайного шардирования, партиционированием по хэшу. Из-за утраты детерминированности местоположения записи основная цель использования меняется - теперь это распараллеливание обработки. Но для партиционирования хотя бы видны перспективы профита.

PS. Если наличие тега PostgreSQL более-менее оправдано (одна ссылка всё же есть), то тег MS SQL, походу, просто участвует в массовке.

PPS.

Шардинг БД (db sharding) — это метод горизонтального масштабирования, при котором большая база данных разбивается на более мелкие, независимые части (shards), размещаемые на разных физических или виртуальных серверах.

Доводилось ли вам видеть/слышать о шардах в рамках одного инстанса ОС?

[andreylartsev]

PS. Если наличие тега PostgreSQL более-менее оправдано (одна ссылка всё же есть), то тег MS SQL, походу, просто участвует в массовке.

Я впервые это делал на SQL Server, где-то 20 лет назад, тогда первыми кончились деньги на лицензии SQL Server Enterprise )) в котором была транзакционная репликация которая нужна для референсных табличек и традиционного партиционирования (куда же без него).

А воспользоваться фичей Federated tables из SQL Azure у нас не было возможности потому что Microsoft ее еще тогда не придумал ))

[andreylartsev]

А если юзер захочет пойти на предпоследнюю страницу? А шардов много, и записей ещё больше...

все так, я же написал об этом в минусах;