Что хранится в файлах реляционных баз данных

Обновлено: 21.11.2024

Обновление платформы поставщика подчеркивает его внимание к приложениям как способу расширения аналитики для большего числа бизнес-пользователей.

С новым генеральным директором одной из основных целей поставщика облачных услуг является передача данных в руки большего числа бизнес-пользователей внутри .

Метаданные придают данным контекст, а во время таких кризисов, как война на Украине, когда трудно понять, каким новостям доверять, контекст.

Считаете, что готовы к сертификационному экзамену AWS Certified Solutions Architect? Проверьте свои знания, ответив на эти 12 вопросов и.

Amazon заявила, что ее система мониторинга микроавтобусов предназначена исключительно для обеспечения безопасности водителей. Но многие отраслевые эксперты обеспокоены этим.

Amazon хотела бы укрепить свое глобальное присутствие, но гигант электронной коммерции сегодня сталкивается с препятствиями и проблемами, которых у него не было.

Генеральный директор Sitecore Стив Цикакис вступил во владение во время пандемии — на фоне стремительного роста — и переосмыслил компанию как цифровую.

Организации, планирующие миграцию контента, должны проверить целостность файлов и убедиться, что файлы не были повреждены при перемещении. Файл .

Успешное развертывание ECM требует планирования. Менеджеры контента должны учитывать жизненный цикл контента своей организации, безопасность .

Oracle планирует приобрести Cerner в рамках сделки на сумму около 30 млрд долларов. Второй по величине поставщик электронных медицинских карт в США может вдохнуть новую жизнь .

Верховный суд постановил 6-2, что API-интерфейсы Java, используемые в телефонах Android, не подпадают под действие американского закона об авторском праве.

В этом руководстве рассматриваются возможности Oracle Autonomous Database для пользователей Oracle и вопросы, которые следует учитывать организациям.

Поскольку настройки имеют долгосрочные последствия, организации, использующие SAP ECC в качестве основной ERP-системы, должны предоставить .

Многие компании могут извлечь выгоду из возможностей аналитики, а организации, использующие SAP ECC, по-прежнему могут создавать эффективные .

Внедрение S/4HANA сопряжено со значительным риском, но также предлагает реальную возможность цифровой трансформации. Вот .

Хороший дизайн базы данных необходим для удовлетворения потребностей обработки в системах SQL Server. На вебинаре консультант Коэн Вербек предложил .

Базы данных SQL Server можно переместить в облако Azure несколькими способами. Вот что вы получите от каждого из вариантов .

В отрывке из этой книги вы познакомитесь с методами LEFT OUTER JOIN и RIGHT OUTER JOIN и найдете различные примеры создания SQL.

С незапамятных времен поставщики баз данных призывали разработчиков: «Храните все в базе данных. Ты знаешь чего хочешь. Здесь мы упростим вам задачу, добавив такие типы данных, как двоичные файлы, и такие функции, как файловый поток».

Ах, но эта песня сирены ведет вас к вашей окончательной гибели.

Пользователи хотят хранить исторические версии файлов. Вначале в требованиях к дизайну может быть указано сохранение только самой последней версии файла, но это изменится. Пользователи со временем захотят сохранить каждую версию — и даже если они этого не сделают, они будут создавать «новые» файлы, сохраняя их под немного другим именем. Вы знаете этот файл 2022_Budget_Final_v2_with_Changes.xlsx и все его прародители? Да, они все живут в базе данных навсегда.

Пользователи часто создают новые версии. Вы знаете, как вы все время нажимаете «Файл», «Сохранить», потому что вы привыкли к дрянным приложениям, которые вылетают и теряют ваш прогресс? Теперь подумайте о том, что каждый раз приходится обращаться к серверу реляционной базы данных, умноженному на всех пользователей, работающих в этой системе.

Поверь мне, у меня есть шрамы

Пользователи ничего не удаляют. Со временем файлы выглядят как эпизод из Hoarders. Никто не может что-то удалить, потому что никто не знает, что безопасно удалять, поэтому «нам лучше оставить все это на всякий случай».

Файлы большие. Реляционные базы данных прекрасно работают с таблицами, разбитыми на строки и столбцы. Когда мы вставляем строки или обновляем столбцы, мы каждый раз затрагиваем только относительно небольшой объем данных, что упрощает отслеживание в журналах транзакций и быструю запись в хранилище. Иначе обстоит дело с файлами, которые обычно содержат несжимаемые объекты, например изображения.

Большая база данных означает более медленное резервное копирование. Мы говорим не только о ваших полных резервных копиях, но и о более медленных резервных копиях журналов транзакций. Поскольку ваши пользователи постоянно сохраняют новые версии файлов, эти версии записываются в журнал транзакций, и их необходимо создавать резервные копии. (Пользователям файлового потока: прежде чем вы будете в восторге от того, что ваша функция «отлична», перепроверьте размеры резервной копии вашего журнала, потому что файловый поток не работает так, как вы думаете.)

Большая база данных означает более высокую доступность и аварийное восстановление. Нам нужно не только создать резервную копию журнала транзакций, но и перенести эти транзакционные изменения на другие наши реплики.Этот огромный объем журнала означает, что очень сложно выполнять синхронные реплики в других центрах обработки данных, и другим центрам обработки данных очень легко отставать в транзакциях. Когда пользователь добавляет файл размером 100 МБ, а затем другой пользователь пытается вставить одну строку, эта строка должна ждать, пока файл размером 100 МБ не будет синхронизирован первым. Хранилище файлов с низкой ценностью может привести к гораздо худшим показателям времени восстановления для наших более ценных данных.

Серверы баз данных плохо справляются с повторной синхронизацией данных. Когда репликация прерывается или вам нужно повторно добавить реплику группы доступности (или доставку журналов, репликацию или что-то еще), SQL Server недостаточно умен, чтобы синхронизировать только разные данные или синхронизировать данные из ближайшей реплики. Это не имеет большого значения для небольших транзакционных таблиц, но добавляет терабайты файловых данных, и повторная синхронизация превращается в кошмар.

Наконец, серверы баз данных являются дорогостоящим и сложным узким местом. Если вы составите список всех серверов в вашей компании и ранжируете их по вещам, которые заставят вас рвать на себе волосы, серверы реляционных баз данных, вероятно, окажутся наверху каждого списка. Их лицензирование и поддержка стоят дорого, их сложно настроить, и у вас просто не так много людей в штате, которые действительно разбираются в них.

Все это может стать неожиданностью, если вы только читали брошюру от поставщиков баз данных. Это потому, что они хотят, чтобы вы хранили файлы в базе данных. Можете ли вы подумать о том, почему они могут быть заинтересованы в том, чтобы спеть вам эту песню сирены? Они зарабатывают больше денег, когда вы во всем привязаны к их системе.

Есть лучший способ:
хранить файлы в файловой системе.

Файловые системы существуют очень давно, и в них есть инструменты, помогающие решить эти проблемы. Лучше всего то, что они безумно, безумно дешевы, особенно по сравнению с реляционными базами данных.

Если вы считаете, что хранение файлов в реляционной базе данных — это правильный ответ, остановитесь на секунду, составьте список требований и обратитесь к системному администратору.

Потому что, если вы не выполняете с ней реляционное соединение,
она не принадлежит реляционной базе данных.

Реляционная база данных — это тип базы данных, в которой хранятся точки данных, связанные друг с другом, и предоставляется доступ к ним. Реляционные базы данных основаны на реляционной модели — интуитивно понятном и простом способе представления данных в таблицах. В реляционной базе данных каждая строка таблицы представляет собой запись с уникальным идентификатором, называемым ключом. Столбцы таблицы содержат атрибуты данных, и каждая запись обычно имеет значение для каждого атрибута, что упрощает установление отношений между точками данных.

Пример реляционной базы данных

Вот простой пример двух таблиц, которые малый бизнес может использовать для обработки заказов на свои продукты. Первая таблица — это таблица информации о клиенте, поэтому каждая запись включает имя клиента, адрес, информацию о доставке и выставлении счетов, номер телефона и другую контактную информацию. Каждый бит информации (каждый атрибут) находится в своем собственном столбце, и база данных присваивает каждой строке уникальный идентификатор (ключ). Во второй таблице — таблице заказов клиентов — каждая запись включает идентификатор клиента, разместившего заказ, заказанный продукт, количество, выбранный размер и цвет и т. д., но не имя клиента или контактную информацию.< /p>

У этих двух таблиц есть только одна общая черта: столбец ID (ключ). Но благодаря этому общему столбцу реляционная база данных может создать связь между двумя таблицами. Затем, когда приложение обработки заказов компании отправляет заказ в базу данных, база данных может перейти к таблице заказов клиентов, получить правильную информацию о заказе продукта и использовать идентификатор клиента из этой таблицы для поиска счетов и доставки клиента. информация в информационной таблице клиента. Затем склад может забрать правильный продукт, клиент может получить своевременную доставку заказа, а компания может получить оплату.

Как устроены реляционные базы данных

Реляционная модель означает, что логические структуры данных — таблицы данных, представления и индексы — отделены от физических структур хранения. Это разделение означает, что администраторы баз данных могут управлять физическим хранилищем данных, не затрагивая доступ к этим данным как к логической структуре. Например, переименование файла базы данных не приводит к переименованию хранящихся в нем таблиц.

Различие между логическими и физическими также применяется к операциям базы данных, которые представляют собой четко определенные действия, позволяющие приложениям манипулировать данными и структурами базы данных. Логические операции позволяют приложению указать необходимое ему содержимое, а физические операции определяют, как получить доступ к этим данным, а затем выполнить задачу.

Чтобы гарантировать, что данные всегда точны и доступны, реляционные базы данных следуют определенным правилам целостности.Например, правило целостности может указать, что повторяющиеся строки не допускаются в таблице, чтобы исключить возможность ввода ошибочной информации в базу данных.

Реляционная модель

В первые годы существования баз данных каждое приложение хранило данные в собственной уникальной структуре. Когда разработчики хотели создавать приложения для использования этих данных, им нужно было много знать о конкретной структуре данных, чтобы найти нужные данные. Эти структуры данных были неэффективны, их было сложно поддерживать и трудно оптимизировать для обеспечения хорошей производительности приложений. Модель реляционной базы данных была разработана для решения проблемы множества произвольных структур данных.

Реляционная модель данных обеспечивает стандартный способ представления и запроса данных, который может использоваться любым приложением. С самого начала разработчики осознавали, что главная сила модели реляционной базы данных заключается в использовании таблиц, которые представляют собой интуитивно понятный, эффективный и гибкий способ хранения структурированной информации и доступа к ней.

Со временем появилась еще одна сильная сторона реляционной модели, поскольку разработчики начали использовать язык структурированных запросов (SQL) для записи и запроса данных в базе данных. В течение многих лет SQL широко использовался в качестве языка запросов к базе данных. Основанный на реляционной алгебре, SQL предоставляет внутренне согласованный математический язык, который упрощает повышение производительности всех запросов к базе данных. Для сравнения, другие подходы должны определять отдельные запросы.

Преимущества системы управления реляционными базами данных

Простая, но мощная реляционная модель используется организациями всех типов и размеров для самых разных информационных потребностей. Реляционные базы данных используются для отслеживания запасов, обработки транзакций электронной торговли, управления огромными объемами критически важной информации о клиентах и многого другого. Реляционная база данных может использоваться для любых потребностей в информации, в которых точки данных связаны друг с другом и должны управляться безопасным, основанным на правилах и согласованным способом.

Реляционные базы данных существуют с 1970-х годов. Сегодня преимущества реляционной модели по-прежнему делают ее наиболее распространенной моделью для баз данных.

Реляционная модель и согласованность данных

Реляционная модель лучше всего подходит для обеспечения согласованности данных между приложениями и копиями баз данных (называемых экземплярами). Например, когда клиент вносит деньги в банкомат, а затем просматривает баланс счета на мобильном телефоне, клиент ожидает, что этот депозит будет немедленно отражен в обновленном балансе счета. Реляционные базы данных превосходны в такой согласованности данных, гарантируя, что несколько экземпляров базы данных всегда будут иметь одни и те же данные.

Для других типов баз данных сложно поддерживать такой уровень своевременной согласованности с большими объемами данных. Некоторые современные базы данных, такие как NoSQL, могут обеспечивать только «согласованность в конечном итоге». В соответствии с этим принципом, когда база данных масштабируется или когда несколько пользователей одновременно обращаются к одним и тем же данным, данным требуется некоторое время, чтобы «наверстать упущенное». Конечная согласованность приемлема для некоторых целей, например для ведения списков в каталоге продуктов, но для важных бизнес-операций, таких как операции с корзиной покупок, реляционная база данных по-прежнему является золотым стандартом.

Приверженность и атомарность

Реляционные базы данных обрабатывают бизнес-правила и политики на очень детальном уровне, со строгими политиками в отношении обязательств (то есть, делая изменения в базе данных постоянными). Например, рассмотрим базу данных инвентаризации, которая отслеживает три детали, которые всегда используются вместе. Когда одна часть вытягивается из инвентаря, две другие тоже должны вытягиваться. Если одна из трех частей недоступна, ни одна из частей не должна быть извлечена — все три части должны быть доступны до того, как база данных примет какое-либо обязательство. Реляционная база данных не будет фиксировать одну часть, пока не узнает, что может фиксировать все три. Эта многогранная возможность обязательства называется атомарностью. Атомарность — это ключ к обеспечению точности данных в базе данных и обеспечению их соответствия правилам, положениям и политикам бизнеса.

Свойства ACID и РСУБД

Четыре важнейших свойства определяют транзакции реляционных баз данных: атомарность, непротиворечивость, изоляция и надежность, обычно называемые ACID.

Атомарность определяет все элементы, составляющие полную транзакцию базы данных.
Согласованность определяет правила поддержания точек данных в правильном состоянии после транзакции.
Изоляция делает эффект транзакции невидимым для других, пока она не будет зафиксирована, чтобы избежать путаницы.
Надежность гарантирует, что изменения данных станут постоянными после фиксации транзакции.

Хранимые процедуры и реляционные базы данных

Доступ к данным включает множество повторяющихся действий.Например, простой запрос на получение информации из таблицы данных может потребоваться повторить сотни или тысячи раз, чтобы получить желаемый результат. Эти функции доступа к данным требуют некоторого типа кода для доступа к базе данных. Разработчики приложений не хотят писать новый код для этих функций в каждом новом приложении. К счастью, реляционные базы данных допускают хранимые процедуры, представляющие собой блоки кода, доступ к которым можно получить с помощью простого вызова приложения. Например, одна хранимая процедура может обеспечить согласованную маркировку записей для пользователей нескольких приложений. Хранимые процедуры также могут помочь разработчикам убедиться, что определенные функции данных в приложении реализованы определенным образом.

Блокировка базы данных и параллелизм

Конфликты могут возникать в базе данных, когда несколько пользователей или приложений пытаются изменить одни и те же данные одновременно. Методы блокировки и параллелизма снижают вероятность конфликтов, сохраняя при этом целостность данных.

Блокировка предотвращает доступ других пользователей и приложений к данным во время их обновления. В некоторых базах данных блокировка применяется ко всей таблице, что отрицательно сказывается на производительности приложения. Другие базы данных, такие как реляционные базы данных Oracle, применяют блокировки на уровне записей, оставляя другие записи в таблице доступными, что помогает повысить производительность приложений.

Параллелизм управляет активностью, когда несколько пользователей или приложений одновременно вызывают запросы к одной и той же базе данных. Эта возможность обеспечивает правильный доступ для пользователей и приложений в соответствии с политиками, определенными для управления данными.

На что обратить внимание при выборе реляционной базы данных

Программное обеспечение, используемое для хранения, управления, запроса и извлечения данных, хранящихся в реляционной базе данных, называется системой управления реляционной базой данных (RDBMS). СУБД обеспечивает интерфейс между пользователями, приложениями и базой данных, а также административные функции для управления хранением данных, доступом и производительностью.

Несколько факторов могут повлиять на ваше решение при выборе между типами баз данных и продуктами реляционных баз данных. Выбранная вами СУБД будет зависеть от потребностей вашего бизнеса. Задайте себе следующие вопросы:

Каковы наши требования к точности данных? Будут ли хранение и точность данных зависеть от бизнес-логики? Есть ли у наших данных строгие требования к точности (например, финансовые данные и правительственные отчеты)?
Нужна ли нам масштабируемость? Каков масштаб данных, которыми нужно управлять, и каков их ожидаемый рост? Должна ли модель базы данных поддерживать зеркальные копии базы данных (как отдельные экземпляры) для масштабируемости? Если да, то может ли он поддерживать согласованность данных в этих экземплярах?
Насколько важен параллелизм? Потребуется ли нескольким пользователям и приложениям одновременный доступ к данным? Поддерживает ли программное обеспечение базы данных параллелизм при защите данных?
Каковы наши потребности в производительности и надежности? Нужен ли нам высокопроизводительный и надежный продукт? Каковы требования к производительности запроса-ответа? Каковы обязательства поставщика в отношении соглашений об уровне обслуживания (SLA) или незапланированных простоев?

С годами реляционные базы данных стали лучше, быстрее, надежнее и с ними стало проще работать. Но они также стали более сложными, и администрирование базы данных уже давно стало работой на полный рабочий день. Вместо того чтобы использовать свой опыт для разработки инновационных приложений, приносящих пользу бизнесу, разработчикам приходилось тратить большую часть своего времени на действия по управлению, необходимые для оптимизации производительности базы данных.

Сегодня автономная технология опирается на сильные стороны реляционной модели, технологии облачных баз данных и машинного обучения, чтобы создать реляционную базу данных нового типа. Автономная база данных (также известная как автономная база данных) поддерживает мощь и преимущества реляционной модели, но использует искусственный интеллект (ИИ), машинное обучение и автоматизацию для мониторинга и повышения производительности запросов и задач управления. Например, чтобы повысить производительность запросов, автономная база данных может выдвигать гипотезы и тестировать индексы, чтобы выполнять запросы быстрее, а затем запускать лучшие из них в рабочую среду — и все это самостоятельно. Автономная база данных вносит эти улучшения постоянно, без участия человека.

Автономная технология освобождает разработчиков от рутинных задач по управлению базой данных. Например, им больше не нужно заранее определять требования к инфраструктуре. Вместо этого с автономной базой данных они могут добавлять ресурсы хранения и вычислений по мере необходимости для поддержки роста базы данных. Всего за несколько шагов разработчики могут легко создать автономную реляционную базу данных, ускорив разработку приложений.

Среди разработчиков распространено мнение, что хранение двоичных файлов в базе данных — не лучшая практика. В частности, считается, что он медленный как при чтении, так и при записи. Обычное решение состоит в том, чтобы хранить двоичные файлы в виде файлов в (сетевой) файловой системе, сохраняя при этом ссылку на эти файлы в базе данных. Хотя в большинстве случаев это нормально, возникает одна проблема: это не ACID.

Реляционная база данных полностью ACID, файловая система в лучшем случае атомарна. Таким образом, ваша база данных и ваша файловая система не могут участвовать в одной/глобальной транзакции (XA). Поэтому вы не можете быть на 100% уверены, что база данных и содержимое файловой системы согласуются друг с другом. Кроме того, наличие файловой системы рядом с вашей базой данных может потребовать дополнительных усилий для защиты и резервного копирования, поскольку у вас две системы вместо одной.

Теперь некоторые из этих проблем могут не иметь для вас большого значения. Если вы не работаете с ценными данными, отсутствие строгих гарантий непротиворечивости не является препятствием для сделки. Возможно, вы даже сможете восстановиться после некоторых сбоев, создав компенсирующие транзакции (хотя это сопряжено с другими проблемами). Но если вы работаете с ценными данными, возможно, вы захотите (повторно) рассмотреть вопрос о хранении двоичных файлов в базе данных как больших двоичных объектов.

Действительно, производительность BLOB во многих базах данных очень низкая. Поэтому при изучении различных вариантов хранения двоичных файлов в моем последнем проекте я также сначала избегал варианта с базой данных. Lucky Oracle предлагает альтернативу. Он называется Oracle SecureFiles (не зацикливайтесь на названии, которое в основном используется в маркетинговых целях) и решает множество проблем, связанных с BLOB-объектами. Во-первых, производительность хорошая. При работе в режиме ACID он приближается к производительности файловой системы. При работе в не-ACID-режиме (так называемая 'filesystem_like_logging') производительность аналогична файловой системе. Дополнительные сведения см. в этом документе.

Использовать SecureFiles также очень просто. Это точно так же, как любой другой BLOB. Просто укажите «STORE AS SECUREFILE» при создании столбца BLOB, и все готово. Oracle SecureFiles доступен, начиная с Oracle 11g R2, как в стандартной, так и в корпоративной версиях. В Oracle 12c он включен по умолчанию для всех больших двоичных объектов, поэтому вам даже не нужно указывать большой двоичный объект как SecureFile.

Еще одной интересной функцией является DBFS, представляющая собой интерфейс файловой системы, встроенный в базу данных Oracle. SecureFiles использует DBFS, поэтому вы можете получить доступ к своим BLOB-объектам, используя не только SQL. Например, Oracle предлагает интерфейс FUSE, который позволяет монтировать столбец SecureFile BLOB в качестве файловой системы в Linux. Таким образом, ваши двоичные файлы не обязательно будут «заперты» внутри Oracle.

Как я уже упоминал, Oracle исправила множество проблем, связанных с большими двоичными объектами. Я знаю, что Microsoft предлагает что-то подобное на SQL-сервере, известном как Filestream. Я не уверен в PostgreSQL. Предлагают пару вариантов хранения бинарников, может большие объекты и умеют резать но точно не скажу. MySQL ничего не предлагает в этой области.

Если вы уже используете Oracle и вам нужно хранить ценные двоичные файлы, обязательно рассмотрите вариант Oracle SecureFiles.

Читайте также: