Реляционная база данных предлагает надежные, более старые решения в соответствии с качествами ACID. Мы получаем обработку транзакций, эффективную подпись для восстановления и т. д. Это основные решения реляционных баз данных, в которых они совершенны. Их трудно персонализировать, и они могут рассматриваться как узкие места, особенно если они вам не нужны в данном приложении (например, предоставление содержимого веб-сайта с низкой важностью; в этой ситуации, например, обычно используемый MySQL не предлагает иметь дело со стандартным механизмом хранения, поэтому не выполняет ACID). Многие вопросы больших данных не требуют таких жестких ограничений, например веб-статистика, веб-поиск или управление траекториями движущихся объектов, поскольку они уже включают сомнения по характеристикам.
При достижении границ данного компьютера (память, ЦП, диск: объем информации слишком велик, или информационные системы слишком сложны и дороги), целесообразно распространение услуги. Множество реляционных источников и источников информации NoSQL предлагают выделенное пространство для хранения. В этой ситуации, однако, ACID трудно удовлетворить: теорема CAP утверждает несколько похожее, что доступность, надежность и терпение разделения не могут быть получены в одно и то же время. Если мы откажемся от ACID (например, в соответствии с BASE), масштабируемость может быть улучшена.
Другим узким местом может быть сам универсальный и блестящий реляционный дизайн с операциями SQL: в большом количестве случаев более простой дизайн с более простыми функциями был бы достаточным и более эффективным (например, нетипизированные хранилища ключ-значение). Обычный дизайн физического пространства для хранения данных по строкам также может быть ограничивающим: например, он не является максимальным для информационного давления.
Масштабирование реляционных баз данных сложно
Достижение масштабируемости и гибкости — огромная задача для реляционного источника информации. Реляционные источники информации были разработаны в период, когда информация могла быть небольшой, красивой и организованной. Это просто уже не так. Да, все поставщики источников данных говорят, что они имеют большой диапазон. Они должны жить. Но когда вы присмотритесь повнимательнее и увидите, что на самом деле работает, а что нет, основные проблемы с реляционными источниками информации начинают проясняться.
Реляционный источник информации предназначен для работы с использованием одного сервера, чтобы сохранить надежность сопоставления таблиц и избежать проблем с выделенной обработкой. При таком дизайне, если процесс требует расширения, клиенты должны покупать более крупные, сложные и дорогие эксклюзивные компоненты с большей управляемой мощностью и объемом памяти. Изменения также являются проблемой, поскольку компания должна пройти долгий процесс покупки, а затем часто отключать программу, чтобы действительно внести изменения. Все это происходит в то время, когда число клиентов продолжает увеличиваться, что приводит к все большему и большему стрессу и повышению риска для недостаточно обеспеченных источников.
Новые структурные изменения лишь скрывают настоящую проблему
Чтобы справиться с этими проблемами, поставщики реляционных источников данных внесли целый ряд улучшений. Сегодня развитие реляционных источников информации позволяет им использовать более сложные архитектуры, в зависимости от схемы «главный-подчиненный», в которой «подчиненные» являются дополнительными веб-серверами, которые могут управлять аналогичной управляющей и дублированной информацией или информацией, которая «раздроблена». (разделенный и распределенный между несколькими веб-серверами или хостами), чтобы облегчить объем работы на главном сервере.
Другие усовершенствования реляционного источника информации, такие как использование распределенного пространства для хранения, управление в оперативной памяти, более эффективное использование репликаций, выделенное кэширование и другие новые и инновационные архитектуры, безусловно, сделали реляционный источник информации более масштабируемым. Однако среди включений нетрудно найти отдельную программу и отдельную точку отказа (например, Oracle RAC — это кластеризованный реляционный источник данных, который использует файловую программу с поддержкой кластера, но все же есть подсистема распределенного жесткого диска внизу). Часто цена этих систем также оказывается запредельной, поскольку создание отдельной информационной фабрики может легко обойтись более миллиона долларов. Вы можете присоединиться к курсу Oracle DBA в Пуне, чтобы стать профессией в этой области.
