Что делает Oracle более масштабируемой?
У Oracle, кажется, есть репутация быть более масштабируемой, чем другой RDBMSes. После работы с ним немного, я могу сказать, что это более сложно, чем другой RDBMSes, но я действительно не видел ничего, что делает это более масштабируемым, чем другой RDBMSes. Но с другой стороны, я действительно не работал над ним в большой глубине.
Какие особенности Oracle имеет, которые более масштабируемы?
3 ответа
Архитектура Oracle RAC - это то, что делает ее масштабируемой, где она может балансировать нагрузку между узлами, а параллельные запросы могут быть разделены и вытеснены на другие узлы для обработки.
Некоторые трюки, такие как загрузка блоков из буферной кэш-памяти другого узла вместо того, чтобы идти на диск, делают производительность намного более масштабируемой.
Кроме того, удобство обслуживания RAC с откатными обновлениями помогает сделать работу большой системы более разумной.
Существует и другой аспект масштабируемости - масштабируемость хранилища. ASM делает увеличение емкости хранилища очень простым. Хорошо спроектированное решение на базе ASM, должно масштабироваться до 100 терабайт без необходимости делать что-то особенное.
Сделают ли они Oracle более масштабируемой по сравнению с другими СУБД, не знаю. Но я думаю, что мне было бы не очень приятно пытаться масштабировать базу данных, не предназначенную для Oracle.
Распределение курсора является (или было) большим преимуществом над соревнованием. В основном тот же план запроса используется для согласования запросов. Приложение будет иметь стандартный набор запросов IT-проблемы (например, заказывайте заказы для этого идентификатора клиента). Простой способ - это лечить каждый запрос индивидуально, поэтому, если вы увидите «выбрать * из заказов, где CULLING_ID =: B1», вы посмотрите, вы смотрите, есть ли заказы на таблице в результате, вы можете потратить столько же работы UP META DATA, чтобы получить план запроса как на самом деле извлечение данных. С простыми поисками клавиш, план запроса легко. Сложные запросы с несколькими таблицами, соединенными на перекошенных столбцах, сложнее.
Oracle имеет кэш планы запроса, а более старые / менее используемые планы выделяются, поскольку требуются новые.
Если вы не вкладываете планы запроса, есть предел того, насколько Smart вы можете сделать свой оптимизатор максимально более умным, который вы введуете в него, то большее влияние, которое вы имеете на каждом запросе. Запросы кэширования означает, что вы придерживаетесь только накладных расходов в первый раз, когда вы видите запрос.
«Нижняя сторона» - это то, что для совместного использования курсора необходимо эффективно, вам необходимо использовать переменные связывания. Некоторые программисты не понимают, что и код записи, который не будет разделен, а затем жаловаться, что Oracle не так быстро, как MySQL.
Еще одним преимуществом Oracle является журналом отмены. Как сделано изменение, «старая версия» данных записывается в журнал UNDO. Другая база данных сохраняет старые версии записи в том же месте, что и запись. Для этого требуются операции очистки в стиле вакуума или выталкиваете проблемы в пространстве и организации. Это наиболее актуально в базах данных с высоким обновлением или удалением активности.
Также Oracle не имеет центрального замка регистрации. Блок блокировки хранится на каждой отдельной записи данных. Выбор не принимает замок. В базах данных, где выберите блокировки, у вас могут быть несколько пользователей чтения данных и блокировки друг друга или предотвращения обновлений, вводят пределы масштабируемости. Другие базы данных будут блокировать запись, когда был сделан выбор, чтобы убедиться, что никто не может изменить этот элемент данных (так что это будет соответствует, если один и тот же запрос или транзакция снова смотрит на таблицу). Oracle использует Undo для своей модели согласованности чтения (т.е. искать данные, как оно появилось в определенной точке во времени).
«Экспертная архитектура базы данных Oracle Oracle Tom Kyte» от Apress делает хорошую работу по описанию архитектуры Oracle, с некоторыми сравнениями с другими RDBMS. Стоит прочтения.