andrey_anonymousПри всем уважении - регулировать это можно в RAC.
При всем уважении в 12c (18/19с не смотрел) max число RAC nodes = 64 а вoт max shards = 1000.
Ну и в сравнивть RAC с sharding смысла не имеет - RAC и sharding это теплое и мягкое:
The following figure illustrates the major architectural components of Oracle Sharding:
» Sharded database (SDB) – a single logical Oracle Database that is horizontally partitioned across a pool of
physical Oracle Databases (shards) that share no hardware or software
» Shards - independent physical Oracle databases that host a subset of the sharded database
И, если я прaвильно понял, ничто не мешает shards быть RAC.
SY» Sharded database (SDB) – a single logical Oracle Database that is horizontally partitioned across a pool of
physical Oracle Databases (shards) that share no hardware or software
» Shards - independent physical Oracle databases that host a subset of the sharded databaseПрекрасно. А теперь поясни своё:
SYПроизводительность и, что не менее важно, доступность можно регулировать увеличением/уменьшением числа серверов базы (shards)Про доступность, скажем, понятно: убил сервак - убил часть данных - кому-то не повезло. Какая от этого польза - отдельный вопрос.
А вот про регулирование производительности хотелось бы услышать либо опровержение, либо подтверждение.
SY
И, если я прaвильно понял, ничто не мешает shards быть RAC.
SY.
Каждая шарда может быть RAC и можно включить логическое шардирование внутри RAC,
тогда запросу между нодами будет роутиться по внутренней афинити функции, что в свою
очередь снизит трафик по интерконнекту.
А ещё сверху можно навесить Global Data Services и получить автоматическую обработку FAN, свитчовер/файловер и т.д.
ElicПро доступность, скажем, понятно: убил сервак - убил часть данных - кому-то не повезло. Какая от этого польза - отдельный вопрос.
Каждый shard это отдельная база которая может быть RAC, иметь свои standby со своим dataguard так-что возможность потери части данных в shard ничем не отличается от возможности потери части в обычной базе. Да, SHD добавляет еще один уровень возможной потери - shard catalog которы тоже можно и нужно защищать от возможной потери.
ElicА вот про регулирование производительности хотелось бы услышать либо опровержение, либо подтверждение.
Ну например composite sharding. Данным которые востребованы часто даем такой key что они попадут на более мощный shard.
SY.
P.S. Shard, как и любой инструмент, имеет как свои преимущества так и свои недостатки.
SYElicА вот про регулирование производительности хотелось бы услышать либо опровержение, либо подтверждение.
Ну например composite sharding. Данным которые востребованы часто даем такой key что они попадут на более мощный shard.
Я дико извиняюсь, но "регулирование", особенно применительно к облаку - это про то, что "не хватает производительности - добавили сервер", а не "заранее все распланировали и теперь живем с тем, что получилось".
И если с RAC это действительно возможно (поднимать-опускать ноды по мере необходимости), то про "добавить шарды по мере необходимости" хотелось бы поподробнее - я искренне полагал, что это несколько проблемное мероприятие.
Ну да, добавить шарды по мере необходимости это несколько проблемное мероприятие. Но что делать если RAC уже на 64 nodes а надо-бы еще? Кроме того, регулирование данных в SHD это тоже регулирование производительности.
SYНу да, добавить шарды по мере необходимости это несколько проблемное мероприятие. Но что делать если RAC уже на 64 nodes
В ROUG уже ржут над этой записью :)
ElicSYНо что делать если RAC уже на 64 nodes а надо-бы еще?А пета-баблосов хватит?
Возражения технического характера были бы более уместны - к примеру, связанные с общей устойчивостью такого кластера.
А в контексте вопроса о "регулируемости" посредством добавления/удаления узлов тезис о применимости shards, если я правильно понял Соломона, уже умер.
