Чем oracle отличается от mysql
Заметил, что когда спрашиваешь кого-нибудь, особенно на собеседовании, какие типы СУБД существуют, то первое что вспоминают многие – это реляционные базы данных, и NoSQL, а вот про разновидности часто забывают или не могут сформулировать их отличие. Поэтому начнем с простого перечисления наиболее используемых.
Тем, кому не хочется долго читать, может сразу перейти на итоговую таблицу .
Нужно обязательно сделать ремарку, что некоторые крупные производители, имеют в своем арсенале несколько типов СУБД, как в виде отдельных продуктов, так и в виде внутренней реализации. Например, у Oracle на самом деле чего только нет, начиная с классической реляционной СУБД, продолжая с отдельным продуктом Oracle NoSQL Database, который может использоваться и как документная, и как колоночная, и как ключ-значение. Отдельное решение от того же Oracle, Autonomous Data Warehouse – это уже специализированное решение для хранилищ данных. Еще один отдельный продукт от Oracle – Oracle Graph Server для работы с графами, и еще много другого. Этому можно посвятить отдельную серию статей.
Документные СУБД
Документные или документно-ориентированные СУБД - это одна из наиболее популярных разновидностей NoSQL СУБД, где основной единицей логической модели данных является документ - структурированный текст, с определенным синтаксисом.
Иногда встречаются мнения что модель данных в документных БД похожа на модель данных в объектно-ориентированных базах данных. В этом есть доля правды, единственная реальная разница между ними заключается в том, что базы данных документов только сохраняют состояние, но не поведение.
Так же, само название "документо-ориентированная" подчас вводит в заблуждение, и мне встречались коллеги, которые считали, что это база для систем документооборота. Нет, это не так.
Интересно, что документные СУБД развиваются достаточно активно, и сейчас некоторые из них, в том числе, поддерживают проверку схемы.
Известными представителями таких СУБД являются CouchDB, MongoDB, Amazon DocumentDB.
Когда выбирать СУБД ключ-значение
Итоги
Важное замечание – не пытайтесь сразу все задачи решить в рамках одной СУБД. Это более чем нормально иметь несколько разных типов СУБД. Так же, не пытайтесь сразу определиться с производителем СУБД, или связать свою жизнь с одним конкретным брендом.
При выборе типа СУБД следует, прежде всего, исходить из типа решаемых задач, типов обрабатываемых данных, перспектив роста и масштабирования.
Обращайте так же внимание на популярность и наличие широкого круга разработчиков и средств разработки – это даст вам возможность, при необходимости, найти ответ на возникший вопрос быстро.
В данной статье я намеренно не делаю акцент на выбор между облачными и on-premise решениями - эта тема одной из следующих статей.
Итак, в таблице представленной ниже, кратко собрано то, что описано выше в статье.
Тип СУБД
Когда выбирать
Примеры популярных СУБД
Нужна транзакционность; высокая нормализация; большая доля операций на вставку
Oracle, MySQL, Microsoft SQL Server, PostgreSQL
Для хранения объектов в одной сущности, но с разной структурой; хранение структур на основе JSON
CouchDB, MongoDB, Amazon DocumentDB
Задачи подобные социальным сетям; системы оценок и рекомендаций
Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid
Хранилища данных; выборки со сложными аналитическими вычислениями; количество строк в таблице превышает сотни миллионов
Vertica, ClickHouse, Google BigTable, Sybase \ SAP IQ, InfoBright, Cassandra
Надеюсь данная статья оказалась полезной.
В следующих статьях посмотрим на выбор между облачными и on-premise СУБД, платными и бесплатными, и многое другое.
Пересекся вчера в дороге с одним программистом. Он начал довольно эмоционально втирать что MySQL это для школьников и блокнотиков, а для профи только Oracle. Любопытно Ваши мнения, в чем ИМЕННО преимущество данной СУБД над MySQL и PosgreSQL. Действительно ли профессиональный только Oracle? Или слииишком субъективное мнение?=)))
Оценить 1 комментарий
Если без холивара - то преимущество оно всегда одно - т.к. вы платите баб$сы, то имеете возможность позвонить в саппорт 24/7 и спросить, почему не стартует сервер СУБД после ваших манипуляций с ним. Конечно, для постгреса есть EnterpriseDB, и это довольно серьезные ребята, так что все упирается, как и всегда, в опыт и доверие. Оракл - это огромные вложения в инженерные решения, многолетний опыт поддержки по всему миру ну и прочие дела. Также, как и какой-нибудь DB2, которому тоже уже 40 лет стукнуло.
Когда вы храните в вашей БД данные стоимостью несколько миллионов долларов, становятся важны мелочи, не видные на первый взгляд - надежность восстановления после сбоев, отлаженность процедур бэкапа и восстановления, стоимость и оперативность масштабирования и еще 1000 и одна вещь.
Тут можно сказать две вещи:
1: Как и Windows - первый, значит самый известный и все думают, что лучший .
2: Реально - В Oracle есть пара фишек (из тех, что я знаю), которые очень актуальны в БОЛШИХ и ОЧЕНЬ БОЛЬШИХ базах данных. К примеру - Oracle RAC - быстро разворачиваемый кластерный доступ к базе данных. Плюс оптимизация использования кучи процессоров и моря памяти.
Так же Станислав Макаров дал очень актуальный ответ.
Но сейчас, в связи с обилием на рынке огромного выбора технологий баз данных, которые специализируются под решение разных задач - плюсы от использования Oracle DB мне кажутся сомнительными, учитывая цены на покупку и поддержку (ценовая политика компании Очень гадкая)
Для того, чтобы понять наиболее важные отличия стоит знать ответы на 4 вопроса.
1) Сколько строк каждая БД возвращает при селекте к заблокированной таблице?
Ответ для MyASM(MySQL) - 0, ответ для InnoDB - столько же, сколько и для незаблокированной (но сильно медленнее чем MyASM). Ответ для Oracle - столько же, сколько и для незаблокированной.
2) Каковы накладные расходы на транзакции. Ответ для MyASM(MySQL) - транзакция нет как феномена, ответ для InnoDB - расходы есть и значимы для больших систем. Ответ для Oracle - расходов нет.
3) Как восстановить данные после сбоя. Ответ для MyASM(MySQL) - никак, ответ для InnoDB - с трудом. Ответ для Oracle - как правило данная процедура не требуется.
4) Как с логикой на базе дела (в том числе для работы с бигдатой)? MySQL - возможностей не много, работает относительно медленно. Oracle - всего хватает.
И еще 100500 таких вопросов можно задать.
MySQl имеет немного преимуществ:
1) Скорость при односложных запросов, на малых данных, при однопользовательском доступе, без логики на базе.
2) Бесплатность.
С PgSQL все несколько сложнее. В целом она идет к тому, чтобы называться базой данных, а не блокнотиком =)
а еще для танчиков WoT, где варгейминг хранит 400Гб данных пользователей
// правда не в мускуле, а марииДБ
А яндекс уходит от Оракла на постгрес, тк оракл не дает своих исходников, а им очень хочется посмотреть почему у них все тормозит
Сейчас решил глянуть вакансии программистов по СПб, в итоге, что я вижу. Чаще всего, требуют знания SQL и, как я понял, СУБД MySQL/Oracle.
Вопрос: есть ли суть в изучении данных языка и СУБД и какую доступную литературу вы можете посоветовать на данный счёт?
Gnome v96: mysql это одна из самых простых и самых популярных баз, скорее всего самая популярная. На ней блог запустить это самое оно, ну или фейсбук на первых порах.
oracle это сбер, билайн и т.п. и они условно кладут в него всё.
Согласен со старичком Уолтом!
Спецов (профессионалов) по Ораклу не так много и получают они в разы больше чем спецы по Мускулу. Но всётаки по мануалам такие вещи не выучить (если вы конечное не супергений). Тут нужно время, опыт и хорошие наставники.
Если рассматривать БД как класс работы, то язык tSQL почти одинаков во всех этих БД. Просто принципы работы у этих БД разные и применение разнится: например, в MySQL нерелятивные (денормализованные) таблицы - это сплошь и рядом, то для оракла это неприемлемо. Для Мускула и для Оракла это принципиально разные подходы к безопасности, транзакциям и прочим внутренним вещам. МуСкул проще намного, ибо на большинстве сайтов есть бекап))) а вот бекап в банке на сутки назад откатить уже нельзя
Не совсем, спецы и там и там получают одинаково. Просто для mysql их практически нет, из тех что есть половина сидит в percona, шучу конечно но не сильно.
Нет отдельных специальностей mysql админ и mysql разработчик, знание mysql это вишенка на фоне основной профессии. Зато есть oracle разработчики и они самодостаточны.
Я думаю не для кого не секрет, что Oracle купила MySQL. Я слышал много предсказаний о том, что с MySQL будет. Кто-то говорил, что следующая версия этой популярной базы данных сразу станет платной. Кто-то говорил, что как отдельный продукт он больше не будет существовать.
На данный момент Oracle собирается выпускать по крайне мере 2 версии MySQL: MySQL 5.5 и MySQL Cluster 7.1
Расскажем вкратце о каждой ветке СУБД MySQL:
Когда выбирать графовые СУБД
Точно стоит обратить внимание на графовые СУБД, если строите какое-то подобие социальной сети, или реализуете систему оценок и рекомендаций. Ну и во всех случаях когда вы хорошо понимаете что такое графы, и для чего это нужно.
Когда не выбирать колоночные СУБД
Учитывая специфику колоночных СУБД, будет не эффективно ее использовать, если выборки достаточно простые, параметры выборки статичны, и если преобладают выборки по ключевым значениям. Так же, если количество строк в таблице, из которой делается выборка, меньше сотен миллионов строк, то скорее всего не будет большого преимущества, по сравнению с реляционной СУБД.
Нужно так же иметь ввиду, что в колоночных СУБД могут быть и другие ограничения. Например, может отсутствовать поддержка транзакций, а язык запросов может отличаться от классического SQL, и прочее.
Реляционные СУБД
Начнем по порядку, классические, реляционные СУБД чаще всего используются для построения решений OLTP (Online Transaction Processing). В таких решениях СУБД работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом от системы требуется минимальное время отклика, а так же возможность, при определенных условиях, отменить любые изменения выполняемых в рамках транзакции. Если вы строите систему, в рамках которой требуется хранить значительное количество сущностей (таблиц), с различными типами связей между ними (один-к-одному, один-к-многим, многие-ко-многим), то это скорее всего про реляционные СУБД.
Наиболее известные СУБД такого типа - Oracle, Microsoft SQL, PostgreSQL, MySQL.
Когда не выбирать реляционную СУБД
Если предполагается хранить не структурируемые данные, или наоборот очень простые структуры типа ключ-значение, то лучше посмотреть в сторону документных СУБД и специализированных СУБД типа ключ-значение соответственно.
Так же один из признаков, что имеет смысл подумать не о реляционных СУБД, это такой факт как необходимость часто обновлять значения в одних и тех же строках. Обычно это обходится "дорого" в реляционных СУБД, и нужно применять "продвинутую магию" что бы делать это корректно.
Конечно, тут есть много «но», или «а если очень хочется», и других ситуаций, когда данные рекомендации можно игнорировать. Это нормально, особенно когда за дело берется эксперт, который знает как это сделать.
Когда выбирать колоночные СУБД
Один из весомых аргументов за использование именно колоночной СУБД - это если вы хотите построить хранилище данных, и планируете делать выборки со сложными аналитическими вычислениями. Косвенный признак, который так же может сигнализировать о том, что имеет смысл, хотя бы посмотреть в сторону колоночных СУБД - это если количество строк, из которых делаются выборки, превышает сотни миллионов.
MySQL 5.5
Версия позволяет повысить производительность и масштабируемость приложений в различных операционных средах, включая Windows, Linux и Mac.
- Увеличение производительности и масштабируемости
- Повышение уровня доступности
- Повышение удобства использования
Графовые СУБД
Графовые СУБД - специфичный тип, предназначены для работы с графами, с их узлами, свойствами, и произвольными отношениями между узлами.
Очень простой пример, это организация связей в различного типа социальных сетях, где нужно хранить связи между пользователями (узлами) по разным критериям (родственные связи, коллеги, общие интересы).
Известные представители этого типа субд - Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid.
Когда не выбирать документную СУБД
Не самое лучшее решение для реализации транзакционная модели, и точно не лучший вариант для формирования отчетности.
Когда выбирать документную СУБД
Если нужно хранить объекты в одной сущности, но с разной структурой. Если нужно хранит структуры, включая объекты, списки и словари, особенно в формате близкому к JSON.
На самом деле область применения документных СУБД очень широкая. Их можно использовать как компактную базу данных для отдельно взятого микро-сервиса, так и для вполне масштабных решений, в качестве хранилища состояний чего-либо.
MySQL Cluster 7.1
MySQL Cluster – это ведущая реляционная база данных «реального времени» без единой точки отказа. Обеспечивая очень высокий уровень доступности данных и прогнозируемое время отклика в единицы миллисекунд, MySQL Cluster позволяет удовлетворить самые жесткие временные требования пользователей телекоммуникационных и встраиваемых приложений реального времени.
В состав входят следующие ключевые функциональные модули:
- MySQL Cluster Manager, который обеспечивает пользователям возможность простого управления многоузловым кластером. Благодаря автоматическому управлению снижены риски сбоев и простоев в работе базы данных из-за ошибок ручного конфигурирования.
- NDBINFO служит для отображения в реальном времени информации MySQL Cluster Data Nodes о текущем состоянии базы и статистике использования в виде SQL таблиц и представлений, предоставляя разработчикам и администраторам простые и точные средства упреждающего мониторинга и оптимизации производительности и доступности базы данных.
- MySQL Cluster Connector for Java позволяет разработчикам создавать Java-приложения, которые через интерфейсы JDBC или JPA напрямую взаимодействуют с MySQL Cluster, облегчая доступ к возможностям базы данных по высокой производительности и доступности
P.S.: Oracle я считаю отличной базой данных, но больше подходит для крупных и сложных проектов, поскольку очень многофункциональна и универсальна.
Ключевое отличие: База данных Oracle - это система управления объектно-реляционными базами данных (ORDBMS). MySQL - это система управления реляционными базами данных с открытым исходным кодом (RDBMS). MySQL является самой используемой СУБД в мире и работает как сервер, обеспечивающий многопользовательский доступ к ряду баз данных.
Oracle Database и MySQL являются системами управления базами данных, которые в настоящее время производятся и управляются корпорацией Oracle. Корпорация Oracle является многонациональной корпорацией компьютерных технологий, базирующейся в Редвуд-Сити, штат Калифорния, США. Специализируется на разработке и маркетинге компьютерных аппаратных систем и корпоративных программных продуктов. Компания также создает инструменты для разработки баз данных и систем программного обеспечения среднего уровня, программного обеспечения для планирования ресурсов предприятия (ERP), программного обеспечения для управления взаимоотношениями с клиентами (CRM) и программного обеспечения для управления цепочками поставок (SCM).
База данных Oracle - это система управления объектно-реляционными базами данных (ORDBMS). Обычно его называют СУБД Oracle или просто Oracle. Лаборатории разработки программного обеспечения (SDL) разработали оригинальную версию программного обеспечения Oracle.
MySQL - это система управления реляционными базами данных с открытым исходным кодом (RDBMS). MySQL официально произносится как «My S-Q-L», но также называется «My Sequel». Он назван в честь дочери соучредителя Майкла Видениуса, My. SQL расшифровывается как язык структурированных запросов. MySQL является самой используемой СУБД в мире и работает как сервер, обеспечивающий многопользовательский доступ к ряду баз данных. MySQL принадлежал и спонсировался одной коммерческой фирмой, шведской компанией MySQL AB, которая в настоящее время принадлежит корпорации Oracle.
Основное различие между Oracle и MySQL заключается в том, что MySQL является открытым исходным кодом, а Oracle - нет. Тем не менее, Oracle считается гораздо более мощным программным обеспечением, чем MySQL.
СУБД типа ключ-значение
Наверное один из самых простых типов СУБД. В упрощенном виде, это некая таблица с уникальным ключом и собственно связанным с ним значением, в котором может быть что угодно. Чаще всего такие СУБД используют для кэширования, т.к. они очень быстро работают, а это и не сложно, когда есть уникальный ключ, и запрос возвращает только одно значение. У некоторых представителей данных СУБД есть возможность работать полностью в памяти, а так же есть возможность задавать срок жизни записи, после истечения которого, записи будут автоматически удаляться.
Наиболее известные СУБД такого типа - Redis и Memcached.
Когда не выбирать графовые СУБД
Практически во всех остальных случаях, кроме указанных выше, лучше воздержаться от использования графовых СУБД.
Колоночные СУБД
Колоночные СУБД очень похожи на реляционные. Они так же состоят из строк, которые имеют атрибуты, а строки группируются в таблицах. Различия в логических моделях несущественные, а вот на уровне физического хранения данных различия значительные.
В реляционных СУБД данные хранятся "построчно", это означает что для считывания значения определенной колонки, придется прочитать практически всю строку, как минимум от первой до нужной колонки. В колоночной СУБД данные хранятся "поколоночно", т.е. колонка - это как отдельная таблица. Соответственно чтение будет происходить из конкретного столбца сразу. На практике это реально работает очень быстро (проверено мной на нескольких реализованных хранилищах данных).
Основные преимущества колоночных СУБД – эффективное выполнения сложных аналитических запросов на больших объемах, и легкое, практически мгновенное, изменение структуры таблиц с данными, плюс существенная компрессия и сжатие, которое позволяет значительно экономить место.
Яркие представители колоночных СУБД - Sybase IQ (ныне SAP IQ), Vertica, ClickHouse, Google BigTable, InfoBright, Cassandra.
Когда выбирать реляционную СУБД
Один из основных признаков, который говорит о том что нужно выбирать реляционную СУБД – это высокая нормализация данных. Дополнительными признаками будет необходимость обработки большого кол-ва коротких транзакций, с большей долей операций на вставку
Когда не выбирать СУБД ключ-значение
Если вы предполагаете хранить в базе данных много сущностей (таблиц), а у сущностей будут сложные структуры с разными типами данных. Так же, если вы предполагаете делать из этой таблицы сложные запросы которые возвращают множества строк.
Читайте также: