«Большая база данных» - это действительно туманное понятие. Уже есть очень разные ответы и мнения, размещенные в ответах на этот вопрос. Некоторые подходы к определению «малых», «средних» и «больших» баз данных могут иметь больше смысла, чем другие, НО ПОТОМ, в какой-то момент я считаю, что каждое определение является правильным, истинным и действительным.
Некоторые определения имеют больше смысла, чем другие, потому что они сосредоточены на различных аспектах, важных для проектирования, программирования, использования, обслуживания и администрирования базы данных, и эти различные аспекты действительно важны для используемой базы данных. Просто случается так, что на все эти аспекты влияет туманная концепция «Размер базы данных».
Итак, означает ли это, что не имеет значения, можете ли вы определить, является ли конкретная База данных большой или нет?
Конечно, нет. Это означает, что вы будете применять эту концепцию по-разному при оценке различных проектных / операционных / административных аспектов вашей базы данных. Это также означает, что каждый раз эта концепция будет туманной.
В качестве примера: на стратегию индекса базы данных (аспект разработки базы данных) влияет количество записей для каждой таблицы (мера «размера»), размер записи, умноженный на количество записей (еще одна мера «размера»), и по запросу Vs. Соотношение операций создания / обновления / удаления (аспект использования базы данных).
Время ответа на запрос лучше, если индексы используются для таблиц с большим количеством записей. В зависимости от характера ваших предложений WHERE, ORDER BY и агрегации записей может потребоваться несколько индексов для определенных таблиц.
Операции создания, обновления и удаления оказали негативное влияние при увеличении количества индексов в соответствующих таблицах. Больше индексов для уязвимой таблицы означает больше изменений, которые должна выполнить СУБД, тратя больше времени и ресурсов для применения этих изменений.
Кроме того, если ваша СУБД тратит больше времени для применения этих изменений, то блокировки сохраняются и в течение более длительного времени, что влияет на время ответа других запросов, отправляемых в систему одновременно.
Итак, как вы балансируете количество и дизайн ваших индексов? Как узнать, нужен ли вам дополнительный индекс, и, добавив этот индекс, вы не окажете большого негативного влияния на время ответа на запрос? Ответ: вы тестируете и профилируете свою базу данных в соответствии с целевой нагрузкой в соответствии с вашими требованиями к нагрузке / производительности и анализируете данные профилирования, чтобы определить, нужны ли дальнейшие оптимизации / редизайны / индексы.
Для разных запросов требуются разные стратегии индекса. Соотношения операций создания / обновления / удаления. Если ваша База данных находится под большой нагрузкой запросов, но редко обновляется, производительность для всего приложения будет лучше, если вы добавите каждый индекс, который улучшает время ответа на запрос. С другой стороны, если ваша База данных постоянно обновляется, но при этом не выполняются большие операции с запросами, производительность будет выше, если вы будете использовать меньше индексов.
Существуют и другие аспекты курса: проектирование схемы базы данных, стратегия хранения, проектирование сети, стратегия резервного копирования, хранимые процедуры / триггеры / и т. Д. программирование, прикладное программирование (по отношению к базе данных) и т. д. На все эти аспекты по-разному влияют различные понятия «размер» (размер записи, количество записей, размер индекса, количество индексов, дизайн схемы, размер хранилища и т. д.).
Мне бы хотелось иметь больше времени, потому что эта тема увлекательна. Я надеюсь, что этот небольшой вклад послужит вам отправной точкой в этом увлекательном мире SQL.