Что делает Oracle более масштабируемым?
Oracle, похоже, имеет репутацию более масштабируемой, чем другие RDBMSes. После работы с ним немного, я могу сказать, что это сложнее, чем другие RDBMSes, но я действительно не видел ничего, что делает его более масштабируемость чем другие RDBMSes. Но, с другой стороны, я действительно не работал над этим на большой глубине.
какие функции Oracle имеют более масштабируемые?
3 ответов
архитектура Oracle RAC-это то, что делает ее масштабируемой, где она может балансировать нагрузку на узлы, а параллельные запросы могут быть разделены и переданы другим узлам для обработки.
некоторые из трюков, таких как загрузка блоков из буферного кэша другого узла вместо диска, делают производительность намного более масштабируемой.
также, ремонтопригодность RAC с подъемами завальцовки помогает сделать деятельность большой системы более здравой.
существует также другой аспект масштабируемости-масштабируемость хранилища. ASM делает увеличение емкости хранилища очень простым. Хорошо разработанное решение на основе ASM должно масштабироваться за 100s размера терабайта без необходимости делать что-либо особенное.
делают ли они Oracle более масштабируемым, чем другие RDBMSs, я не знаю. Но я думаю, что я был бы менее счастлив, пытаясь масштабировать базу данных, отличную от Oracle.
совместное использование курсоров является (или было) большим преимуществом перед конкурентами. В принципе, один и тот же план запроса используется для сопоставления запросов. Приложение будет иметь стандартный набор запросов, которые оно выдает (например, получить заказы для этого идентификатора клиента). Простой способ-обрабатывать каждый запрос индивидуально, поэтому, если вы видите "SELECT * FROM ORDERS WHERE CUSTOMER_ID = :b1", вы смотрите, есть ли у табличных заказов индекс CUSTOMER_ID и т. д. В результате вы можете потратить столько же работы на поиск метаданных для получения запроса планируйте как фактически получение данных. С помощью простых keyed lookups, план запроса легко. Сложные запросы с несколькими таблицами, Соединенными на скошенных столбцах, сложнее.
Oracle имеет кэш планов запросов,а более старые / менее используемые планы устаревают по мере необходимости новых.
Если вы не кэшируете планы запросов, есть предел тому, насколько умным вы можете сделать свой оптимизатор, поскольку чем больше умов вы кодируете в него, тем большее влияние вы оказываете на каждый обработанный запрос. Кэширование запросов означает Вас только несите эти накладные расходы при первом просмотре запроса.
"недостатком" является то, что для совместного использования курсора вам нужно использовать переменные привязки. Некоторые программисты не понимают этого и пишут код, который не распространяется, а затем жалуются, что Oracle не так быстр, как mySQL.
еще одним преимуществом Oracle является журнал отмены. После внесения изменений "старая версия" данных записывается в журнал отмены. Другие базы данных хранят старые версии записи в том же место записи. Это требует операций очистки вакуумного стиля или вы сталкиваетесь с проблемами пространства и организации. Это наиболее актуально в базах данных с высокой обновления или удаления.
также Oracle не имеет центрального реестра блокировки. Бит блокировки хранится на каждой отдельной записи данных. SELECT не принимает блокировку. В базах данных, где SELECT locks, вы можете иметь несколько пользователей, считывающих данные и блокирующих друг друга или предотвращающих обновления, вводя ограничения масштабируемости. Другой базы данных будут блокировать запись при выборе, чтобы никто другой не мог изменить этот элемент данных (поэтому он будет согласован, если тот же запрос или транзакция снова посмотрят на таблицу). Oracle использует UNDO для своей модели согласованности чтения (т. е. ищет данные, как они появились в определенный момент времени).
том Кайт "эксперт Oracle Database Architecture" от Apress делает хорошую работу по описанию архитектуры Oracle, с некоторыми сравнениями с другими rDBMSs. Стоит почитать.