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