Как рассчитать затраты на хранение проекта базы данных?
Я часто имею в виду несколько различных схем при запуске проекта. Сделав грубые предположения, я понимаю, что некоторые из них менее оптимизированы для роста или хранения, чем другие. Очевидно, что размер значения столбца-это главное. Но метаданные таблиц, индексы и заголовки строк также играют свою роль.
Кроме того, СУБД используют совершенно иной подход к хранению данных, чем объектные или ключ-значные базы данных.
Каковы некоторые хорошие ресурсы для попытки определите стоимость (или необходимое место) для хранения базы данных?
Примечание , мой вопрос имеет мало общего с выбором базы данных, а скорее знать, как правильно использовать дизайн каждой базы данных для наиболее эффективно. Базы данных, такие как PostgreSQL, MySQL, CouchDB, имеют разные целевые сценарии использования и несколько способов решения одной и той же проблемы. Таким образом, знание стоимости хранения каждого решения поможет добавить к выбору лучшего решения для схемы.
2 ответа:
Реляционная модель предполагает, что вы не знаете, какие данные понадобятся в будущем или как к ним будут обращаться в будущем. Это оказалось довольно надежным предположением в моем опыте.СУБД используют совершенно иной подход к хранению данных, чем объектные или ключ-значные базы данных.
Это одна из причин, по которой СУБД SQL позволяет добавлять индексы по мере необходимости и удалять индексы, которые оказались бесполезными. Это позволит вам добавлять ограничения, как они становятся известными-ограничения, которые иногда требуют добавления дополнительных таблиц-и отбрасывают ограничения по мере изменения требований. Это позволит вам добавлять столбцы, поскольку вы обнаружите больше вещей, которые было бы полезно знать. Это позволит вам заменить таблицы представлениями и заменить представления таблицами. Некоторые СУБД позволяют создавать материализованные представления-их влияние на скорость запросов может быть драматичным, а их влияние на использование диска-разрушительным.
Полезные базы данных расширяют свой охват. База данных SQL, разработанная согласно реляционной модели, позволяет относительно легко добавлять функции, о которых никто не мечтал при первоначальном проектировании, ибез дробления других частей системы . Поэтому их часто призывают делать то, что их первоначальные дизайнеры не могли себе представить.
Все эти вещи
- добавление и удаление индексов с течением времени,
- добавление и удаление ограничений с течением времени,
- добавление и удаление столбцов с течением времени,
- добавление и удаление таблицы во времени,
Сделайте любую оценку использования диска похожей на пустую трату времени. Любой из них в одиночку может радикально изменить дисковое пространство, необходимое для базы данных.
Вы можете довольно точно рассчитать пространство, необходимое для строки и страницы. (Попробуйте поискать в Google "yourdbmsname Row layout" и "yourdbmsname page layout".) Но когда вы пытаетесь умножить на количество требуемых строк, вы должны оценить количество строк. Это ставит вас в большой конец того, что Стив Макконнелл называет"конусом неопределенности".
Если вы не измеряли использование диска в нескольких проектах в течение долгого времени в вашей собственной компании, оценка влияния этих маркерных точек выше-просто предположение.
Последняя компания Fortune 100, в которой я работал, имела оперативную базу данных, которая была в производстве с 1970-х гг. сотни приложений, написанных на более чем 25 языках программирования в течение 40 лет, попадали в эту штуку каждый день. (Я думаю, что он был построен на IBM Первоначально IMS; сегодня он работает на Oracle.) Еще несколько лет назад никто не предполагал, что их база данных будет использоваться для перевода инженерных чертежей и спецификаций на китайский язык, а также для подготовки таможенных документов, необходимых для вывоза готовой продукции из Китая. Реализация этих новых функций потребовала хранения дополнительных данных о каждой детали и о каждом проектном документе в их реальном инвентаре. В начале этого проекта наши оценки были довольно далеко прочь. Это большой конец конуса. (Мы оценили несколько вещей, но не использование диска. От нас требовалось добиться успеха, поэтому какой бы дизайн я ни придумал, кто-то должен был обеспечить необходимое дисковое пространство.) Но когда мы выходили в эфир, мы знали точную стоимость для каждой оценки, потому что мы уже сделали работу. (Это узкий конец конуса.)Итак, как уменьшить риск догадок в среде разработки и развертывания баз данных? Возьмите урок от 1972 год.
Постройте прототип и измерьте его.
Инженеры-химики давно поняли, что процесс, который работает в лаборатория не может быть внедрена на заводе всего за один шаг. Один промежуточный этап под названием опытная установка необходимо дать опыт масштабирования количеств и работы в непротекторных условиях окружающая среда. . . .Фред Брукс-младший в книге "мифический человек-месяц", стр. 116.. . . Проект за проектом проектирует набор алгоритмов и затем погружается в строительство клиент-поставляемое программное обеспечение по графику, который требует поставки первой построенной вещи. . . .
Таким образом, вопрос управления состоит не в том, следует ли построить пилотную систему и выбросить ее. Вы будете делать это. Единственный вопрос заключается в том, планировать ли заранее, чтобы построить выброшенное, или обещать доставить выброшенное клиентам.
Вот статья AskTom, которую я нашел полезной. Однако это специфично для Оракула.
Http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:266215435203