С точки зрения разработчика, я могу сказать, что почти каждый традиционный основной движок баз данных может только увеличиваться, а масштабирование - очень запоздалая мысль.
В последние годы в связи с необходимостью большей масштабируемости и высокой доступности систем были предприняты усилия по расширению существующих баз данных. Но поскольку дизайну мешает унаследованный код, он очень сильно привязан, а не является фундаментальным для дизайна. Вы столкнетесь с этим, если попытаетесь масштабировать большинство известных баз данных. Добавление подчиненных серверов может быть довольно сложным в настройке, и вы заметите, что оно имеет значительные ограничения, некоторые из которых могут потребовать перенастройки таблиц базы данных.
Например, большинство из них являются главными / (мульти) подчиненными, а не мультимастерными проектами. Другими словами, у вас может быть целый сервер, который просто сидит и не может обрабатывать запросы. Некоторые делают, но с ограничениями ... например, дизайн только для нескольких ведомых. Таким образом, у вас может быть один сервер, который принимает записи, а все остальные предоставляют данные только для чтения. Вы заметите, что, когда вы настраиваете эти системы, это не всегда простой процесс, и трудно работать хорошо. Во многих случаях это очень сильно мешает сложению.
С другой стороны, есть несколько новых движков баз данных, которые разрабатываются с одновременным и многоуровневым дизайном с самого начала. NOSQL и NewSQL - новый класс дизайна.
Таким образом, кажется, что лучший способ получить лучшую производительность от традиционного сервера SQL - это масштабирование! В то время как с NOSQL и NewSQL это одновременно увеличивает и уменьшает масштаб.
Причина, по которой традиционные системы СУБД тесно связаны между собой, заключается в том, что им всем необходимо согласованное представление одних и тех же данных. Когда у вас есть несколько серверов, принимающих обновления одних и тех же данных от разных клиентов, какому из них вы доверяете? Любой метод, который пытается обеспечить согласованность данных с помощью какого-либо механизма блокировки, требует взаимодействия с другими серверами, что либо снижает производительность, либо влияет на качество данных, поскольку любые данные, считываемые с клиента, могут быть устаревшими. И серверы должны решить между собой, какие данные являются самыми последними при записи в одну и ту же запись. Как вы можете видеть, эта сложная проблема усложняется тем фактом, что рабочая нагрузка распределяется по серверам, а не только по процессам или потокам, где доступ к данным все еще довольно быстрый.