Можно ли масштабировать RDB? Если возможно, то как этого добиться?
Я задаю этот вопрос, потому что участвовал в мероприятии NoSQL, на котором докладчик много раз говорил, что одним из недостатков реляционных баз данных является невозможность масштабирования. Другими словами, мы должны добавить больше оперативной памяти и больше памяти, но мы не можем просто добавить еще один компьютер, как если бы мы использовали базу данных NoSQL.
Да, в некоторой степени.
Мастер-Мастер Репликация - теоретически масштабируется для чтения и записи, однако для записи это сложно и требует механизма распределенной фиксации, такого как двухфазная фиксация. Это ограничивает его практичность.
Репликация Master-Slave - масштабируется для операций чтения, но совершенно не помогает для операций записи. Вносит задержку репликации.
Вертикальное разделение - в основном размещение несвязанных таблиц на разных серверах. масштабируется для чтения и записи, однако недостатком является то, что вы не можете легко ПРИСОЕДИНИТЬСЯ к результатам с разных серверов.
Горизонтальное разделение он же Шардинг - Равномерное распределение данных из каждой таблицы по всем серверам. Расположение данных определяется ключом сегментирования. Масштабируется для чтения и записи, однако для доступа к данным с помощью критериев, отличных от ключа сегментирования, требуется опрос всех серверов, а в крайних случаях требуется инфраструктура с уменьшением карты.
Если вы доведете до крайности вертикальное и горизонтальное разделение, вы получите практически решение NoSQL, построенное на основе SQL-сервера.
Эмпирическое правило заключается в том, что вы не можете масштабировать горизонтально, сохраняя полную ACID, вам придется отказаться по крайней мере от одной характеристики. Чаще всего в масштабируемых системах есть только возможная последовательность (т.е. не гарантируется, что вся система всегда будет согласованной, но гарантированно в конечном итоге достигнет согласованного состояния).
Да, реляционную базу данных можно масштабировать, используя Шардинг и / или репликация.
Решения NoSQL обычно намного проще сегментировать / реплицировать. Они делают это, ослабляя требование согласованности в CAP теорема.
Да, примеры: Oracle RAC, MySQL Sharding, SQL Server HADRON
Не все приложения подходят парадигме NoSQL: например, банковское дело, торговля или бухгалтерский учет.
Также см http://www.codinghorror.com/blog/2009/06/scaling-up-vs-scaling-out-hidden-costs.html
Для меня это звучит как предубеждение, и это было сделано до смерти много раз
РСУБД можно масштабировать, но это непросто и требует некоторых компромиссов (которые решения NoSQL часто рекламируют как часть своей базовой конструкции как «функции»). Например, вам часто приходится отказываться от межсерверных транзакций по соображениям производительности. Выполните поиск по запросу «сегментирование» с выбранным вами именем реляционной БД, и вы, вероятно, найдете множество решений с различными компромиссами. Ни один из них не будет автоматическим, так как вам нужно тщательно контролировать, какие данные передаются на какой сервер, поскольку данные в разных таблицах Связанный.
Как бы то ни было, Facebook работает на тысячах сегментированных серверов MySQL ... так что это возможно. Все веб-ресурсы Microsoft также работают в сегментированных базах данных SQL Server. Обычно это связано с большим количеством изменений кода приложения (которые решения NoSQL также заставляют вас делать).