Моя команда боится сущностей реляционных баз данных с отношениями внешних ключей, и я не понимаю, почему

12

Я относительно новичок в колледже, так что большая часть моего знакомства с реляционными базами данных происходит из моего курса по базам данных, где что-либо не в BCNF или 3NF - это пародия. Конечно, это один крайний край, но моя команда на работе действительно, кажется, доводит его до совершенно противоположного конца.

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

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

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

Разговаривая сегодня с одним из наших главных инженеров, он попытался оттолкнуть меня от этой схемы. Попытка всячески спорить о том, что нам это на самом деле не нужно, в будущем вызовет проблемы с производительностью, ссылаясь на наш старый монолит, который является пародией на дизайн. Он назвал то, что мы делаем, «старым способом», а плоские таблицы с json - «новым способом». Он утверждал, что в местах, где мне нужна атомарность, она нам не нужна, и что вместо запросов мы должны делать больше вещей в памяти. Это принцип дизайна, которому следуют многие наши услуги. Мы не ожидаем, что объем наших данных существенно возрастет, что должно ускорить наши запросы. Мы ожидаем много времени, потраченного на оценку правил и выполнение действий.

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

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

MichaelCook
источник
Ответ на ваш вопрос в заголовке будет: «Они напуганы из-за старого монолита в вашей компании». Но основная часть вашего вопроса, кажется, задает что-то совершенно иное, то есть «Внешние ключи создают проблемы с производительностью?»
Кристиан Хакл
2
Интересно, какой% СУБД они встроили в код «приложения»
Caleth
Хороший подход или нет, зависит от типа приложения, которое вы создаете, его потребностей и направления его развития (требований, архитектурных ограничений) - то, что мы не можем реально оценить здесь. Что касается NoSQL - все дело было в поддержке огромной горизонтальной реализуемости и в признании того, что не все приложения требуют строгих ограничений СУБД. Чтобы узнать больше, используйте три верхних ответа здесь в качестве отправной точки (2-й и 3-й идут более подробно).
Филип Милованович
2
Если я могу предложить какой-нибудь нетехнический совет: немного смягчите его. Вы выносите много суждений («да, в двух разных столбцах одной и той же таблицы», «проектная пародия») на работу, в которой вы не участвовали в проектных решениях, и делаете это с позиции минимального реального опыта , Я не могу сказать, что вы правы или неправы, потому что я не видел проект, но системы, как правило, представляют собой серию компромиссов, в результате которых готовый продукт является функциональным, но менее концептуально чистым. Это станет яснее по мере продвижения вашей карьеры, и принятие этих решений станет частью вашей работы.
Blrfl
@Blrfl Отлично поставлено
Робби Ди

Ответы:

8

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

  • Как хранить данные?
  • Принципы дизайна?
  • Как они рассчитаны на масштабирование?

Как и в случае с любым относительно новым способом ведения дел (а 5-10 лет - относительно новый, когда дело доходит до архитектуры программного обеспечения), вы обнаружите, что идеалы и реальность немного отличаются.

Одним из идеалов является то, что каждый микросервис должен иметь свое собственное хранилище данных. ПРИМЕЧАНИЕ: я сказал хранилище данных, а не базы данных. Есть случаи, когда вам просто нужна поисковая система, хранилище больших двоичных объектов или простое кэширование, а не обычная база данных. В зависимости от того, с кем вы говорите, этот идеал может даже пойти в хранилище данных для каждого экземпляра микросервиса!

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

Существует влияние изменения PH того, как вы управляете данными:

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

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

Берин Лорич
источник
+1 Отличный материал - в микросервисах наверняка есть много тонкостей, которые означают, что дело не только в обмене базами данных.
Робби Ди
@RobbieDee, согласился. В этом мире много сложностей, и не все согласны с деталями.
Берин Лорич
Это должно быть ответом. Особенность каждого микросервиса, имеющего собственное хранилище данных, действительно является отличительным фактором. Это приводит к значительным изменениям в ваших потребностях и решениях для хранения данных, и совместимое с ACID хранилище данных не так много, как раньше.
Грег Бургхардт
7
Это хороший ответ, и я проголосовал за него. Я хотел бы только отметить, что то, что вы называете «масштабом интернета», применимо только к крупнейшим компаниям; для подавляющего большинства корпоративных баз данных и веб-сайтов (я бы сказал, 95% из них) «обычные» нормализованные базы данных SQL по-прежнему совершенно жизнеспособны.
Роберт Харви
@ РобертХарви, я искренне согласен. Я прочитал несколько статей о микросервисах, в которых указано, о чем я писал. В наших собственных проектах мы используем базу данных SQL с соответствующей нормализацией и ограничениями. Это повредило бы сердце пуриста, но реальность такова, что наша база пользователей довольно мала (сотни или пользователи), и база данных не была для нас проблемой производительности.
Берин Лорич
3

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

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

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

3nf, если все сделано правильно, сделает базу данных быстрее, потому что большая ее часть может быть кэширована, так как будет сохранено меньше избыточных данных. Однако в вашей текущей работе может быть недостаточно большой набор данных, чтобы реально увидеть разницу в производительности между нормализованной и ненормализованной базой данных.

Роберт Барон
источник
+1 Отличная идея. И если объемы слишком велики для машины разработчика, выборка 1 в N часто может также дать отличную информацию.
Робби Ди
2

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

Он утверждал, что в местах, где я хочу атомарности, нам это не нужно ...

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

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

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

Кроме того, какова скорость изменения этих Правил? Чем больше у вас дублирования, тем больше времени (или денег) вы будете тратить на обновление одной и той же вещи в нескольких местах.

Фил В.
источник
1

Ключевые концепции СУРБД насчитывают более 40 лет. В то время хранилище было очень дорогим, и всякого рода избыточность не одобрялась. В то время как концепции, лежащие в основе СУРБД, все еще здравы, идея денормализации для производительности (для сокращения объединений) стала общепринятой в последние десятилетия.

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

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

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

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

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

Робби Ди
источник
1
почему это опровергнуто? это сбалансированный ответ. Прагматизм +1
Дирк Бур
Прагматизм хорош, но вы все равно должны быть осторожны. Денормализация данных во имя производительности в начале проекта пахнет преждевременной оптимизацией. Не реорганизация старой системы, которая работает, очевидно, является хорошим, прагматичным выбором, но отказ от разработки новой системы в соответствии с отраслевыми стандартами во имя «мы всегда поступали наоборот, и это работает» - далеко не хороший аргумент ,
Винсент
Денормализация данных во имя исполнения в начале проекта ... Подсказка: нет :)
Robbie Dee
1
Значение СУБД не зависит от эффективности диска.
ТехШрике
0

Это зависит от того, какую базу данных вы используете.

В традиционной РСУБД вы правы. Дублирование данных - мерзость. Столбцы и их json-эквивалентность неизбежно выйдут из синхронизации, потому что нет ничего, что могло бы обеспечить их соблюдение. Поддержка внешнего ключа хорошо известна, отлично справляется с описанием и обеспечением взаимосвязей. А атомарность жизненно важна для того, чтобы делать практически все с данными.

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

Что лучше, зависит от того, что вы на самом деле делаете, и что вам действительно нужно.

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

Но они не будут. Надеюсь, вы все равно.

Telastyn
источник