С недавним преимуществом баз данных NoSQL, зачем мне использовать базу данных SQL?

Question

После разработки программного обеспечения в течение примерно 5 лет я потратил, по меньшей мере, 20% и, возможно, до 40% этого времени, просто делая СУБД способной сохранять и извлекать сложные графы объектов. Во многих случаях это приводило к неоптимальным решениям для кодирования, чтобы было проще что-либо делать со стороны базы данных. Это в конечном итоге закончилось после очень значительного времени, потраченного на изучение NHibernate и паттернов управления сеансами, которые являются его частью. С NHibernate я смог, наконец, отказаться от подавляющего большинства 100% потраченного времени на написание CRUD в 1000 раз и использовать прямое генерирование моей базы данных из моей доменной модели.

Тем не менее, вся эта работа по-прежнему приводит к некорректной модели, в которой моя база данных является просто лучшей попыткой SQL имитировать мой реальный объект. С базами данных документов это больше не так, поскольку объект становится самим документом, а не просто эмулирует объект через таблицы и столбцы.

На данный момент я действительно начинаю сомневаться, зачем мне снова нужен SQL?

Что в действительности можно сделать существенно лучше с SQL, чем база данных документов?

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

Answer 1

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

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

Я боюсь, что база данных NoSQL, из-за отсутствия хорошо документированной структуры, будет постепенно приобретать все злые качества кода, над которым я работал. В конечном итоге он будет заполнен данными из старых структур, которые никто больше не понимает, и превратится в огромный набор бесполезного мусора.

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

---

Ваш комментарий: Конечно, согласованность не является приоритетом для каждого приложения. Это не делает значение согласованности «несущественным» для приложений, где это важно.

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

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

Answer 3

это зависит от того, что вы пытаетесь сделать. когда вам нужно выполнить поиск по разным полям ваших объектов, тогда SQL хорош. если вам не нужно искать и у вас очень сложные полиморфные древовидные структуры, SQL ужасен.

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

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

это хорошо работает для нас, потому что мы никогда не хотим иметь дело с частью объекта. мы всегда имеем дело со всем объектом, поэтому JSON не только проще, но и быстрее, чем выполнение 40+ запросов для каждого чтения, которое мы должны были бы выполнить, если бы оно было должным образом нормализовано.

Answer 4

Существуют варианты не только баз данных SQL, у каждой из которых есть свои плюсы и минусы.

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

Реальный вопрос, который вам нужно задать себе при принятии решения о том, какой тип БД выбрать, - это как высобираетесь использовать данные?

в большинстве распространенных случаев, по крайней мере, до некоторого уровня сложности объекта, а для не больших данных СУБД меньше заботятся о том, как используются данные, и больше о самих данных.В RDBMS вам просто нужно знать свою структуру данных и внутренние отношения, и после того, как вы это поймете, вы просто поместите ее в обычную схему формы, и если вы установите правильные ключи и индексы, вы получите высокую производительность по большинству запросов.

В базе данных NoSQL более важным является, например, особая слабость баз данных на основе документов, заключающаяся в том, что если вам нужно будет выполнять сложные запросы в отношении нескольких документов, в большинстве случаев вы не получите более высокую производительность, чем в СУБД.

например, если вы ведете документы Заказа и хотите запросить заказ с максимальной прибылью, полученной в диапазоне дат, на самом деле, если вы не являетесь экспертом (поскольку я не такой), вы в конечном итогес запросом O (n), тогда как в СУБД это займет меньше времени и, безусловно, будет более производительным, даже если вы являетесь экспертом MongoDB.

В заключение, если вы заранее знаете, как будут выглядеть ваши данныеиспользуется, и вы знаете, что документ db будет соответствовать вашему варианту использования, тогда да,возьмите этот документ DB, но если вы не уверены, как будут использоваться ваши данные, тогда СУРБД, как правило, будет более разумным решением.

И, конечно, есть аргумент BigData, который необходимо принять во внимание, поскольку СУБД не масштабируются (не могут легко добавлять узлы для поддержки большего трафика) и становятся менее производительными, когда имеют дело с ОГРОМНЫМИ данными (можетначинают отставать в ГБ или ПБ).

Кроме того, имейте в виду, что СУБД намного старше и были разработаны за последние годы значительно больше, чем БД документов, что позволяет СУБД содержать больше оптимизаций и инструментов, чем любая из альтернатив NoSQL.,

Answer 5

Важно помнить, что реляционная все еще (и будет оставаться в течение некоторого времени) платформой выбора для: обработки транзакций, управления основными данными, справочных данных, хранилища данных (в MPP), BI (хотя и в перевернутом столбце).базы данных выдающиеся в выполнении запросов).Учитывая текущее состояние NOSQL, почти абсурдно, что он может заменить реляционный для вышеуказанного использования.

Answer 6

Мой взгляд на вопрос противоположен: зачем мне вообще нужен noSQL?

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

Ваша проблема в том, что вы пытаетесь поместить квадратные колышки в круглые отверстия: объектыи rdbms не подходят друг другу, потому что RDBMS предназначена для обработки многих из ваших более сложных логик get / set и обеспечения согласованности, что именно то, что вы ожидаете от своего объектного уровня.

Protip: dropобъекты, они не подходят для работы.

Answer 7

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

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

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

Answer 8

Инструменты намного лучше для SQL.У NoSql плохая репутация.Но даже если допустить, что эти два отличия выровняются ...

У вас есть противоположный опыт в моделировании сложных объектов в SQL.Сказать, что таблицы и столбцы в лучшем случае являются «эмуляцией» ваших объектов, это немного семантически.Любая сериализация ваших объектов также будет эмуляцией: хотя база данных документов или XML или что-то еще может показаться лучшей эмуляцией, чем таблицы / столбцы, это, как правило, менее мощная технология.ORM очень помогли преодолеть разрыв между RBDMS и объектно-ориентированными языками.

С тех пор как реляционная теория была формализована, SQL был королем.Иерархические базы данных (базы данных документов) потеряны, реляционные базы данных выиграли.Я хотел бы спросить себя, учитывая, что история, ваша проблема все отличается от большинства проблем за последние 30 лет, которые вам нужно вернуться к иерархической форме?масштабирование (что SQL не очень хорошо сейчас).Ваша проблема требует этого?

Answer 9

Когда я исследовал базы данных в стиле noSQL, я обнаружил, что они не предоставляют ACID и не предоставляют реляционные функции (не являющиеся реляционными базами данных).Поскольку мне нравится согласованность данных, и я обычно хотел какую-то реляционную функцию, я не выбрал базы данных noSQL.

Однако я не использую инструменты ORM,Я склонен писать сам SQL.