Любая хорошая литература о производительности соединения против систематической денормализации? - PullRequest
7 голосов
/ 02 августа 2009

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

В частности, я хочу информацию о:

  • Производительность или нормализация в сравнении с денормализацией.
  • Масштабируемость нормализованной и денормализованной систем.
  • Вопросы сопровождения денормализации.
  • проблемы согласованности модели с денормализацией.

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

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

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

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

---- РЕДАКТИРОВАТЬ Примечания: система сначала была построена из плоских файлов без системы баз данных ... только позже она была портирована в базу данных, потому что клиент настаивал на системе, использующей Oracle. Они не осуществили рефакторинг, а просто добавили поддержку реляционных баз данных в существующую систему. Позднее поддержка плоских файлов была прекращена, но мы все еще ожидаем рефакторинга, чтобы воспользоваться преимуществами базы данных.

Ответы [ 2 ]

2 голосов
/ 02 августа 2009

мысль: у вас есть явное несоответствие препятствий, уровень доступа к данным, который разрешает доступ только к одной таблице? Остановитесь прямо здесь, это просто несовместимо с оптимальным использованием реляционной базы данных. Реляционные базы данных предназначены для действительно сложных запросов. Не иметь никакого другого выбора, кроме как возвращать одну таблицу и, по-видимому, делать какие-либо объединения на уровне бизнеса, просто не имеет смысла.

Для обоснования нормализации и возможных затрат на согласованность вы можете обратиться ко всем материалам от Codd и далее, см. Статью Wikipedia

Я предсказываю, что сравнительный анализ такого рода вещей будет бесконечной деятельностью, особых случаев будет предостаточно. Я утверждаю, что нормализация "нормальная", люди получают достаточно хорошую производительность для чистой базы данных. Возможно, подходом может стать опрос: «Насколько нормализованы ваши данные? Шкала от 0 до 4.»

1 голос
/ 03 августа 2009

Насколько я знаю, Измерение размеров - это единственный метод систематической денормализации, в основе которого лежит некоторая теория. Это основа методов хранения данных методов.

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

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

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

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

...