Как я могу рассчитать затраты на хранение дизайна базы данных?

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

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

Каковы некоторые хорошие ресурсы для определения стоимости (или необходимого номера) для хранения базы данных?

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

ОТВЕТЫ

Ответ 1

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

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

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

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

Все эти вещи

  • добавление и падение индексов с течением времени,
  • добавление и удаление ограничений с течением времени,
  • добавление и удаление столбцов с течением времени,
  • добавление и удаление таблиц с течением времени,

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

Вы можете точно вычислить пространство, требуемое строкой и страницей. (Попробуйте Google для "Макет строки YourDBMSname" и "Макет страницы YourDBMSname".) Но когда вы пытаетесь умножить на количество требуемых строк, вам нужно оценить количество строк. Это ставит вас в большой конец того, что Стив Макконнелл называет " конус неопределенности".

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

Последняя компания Fortune 100, в которой я работала, имела операционную базу данных, которая была в производстве с 1970-х годов. Сотни приложений, написанных более чем на 25 языках программирования в течение 40 лет, ежедневно попадали в эту вещь. (Я думаю, что он был построен на IBM IMS изначально, сегодня он работает на Oracle.)

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

Итак, как вы уменьшаете риск догадок в среде проектирования и развертывания базы данных? Проведите урок с 1972 года.

Создайте прототип и измерьте его.

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

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

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

Фред Брукс-младший в "Мифическом человеке-месяц", стр. 116.