Что такое «большая база данных»?

Хорошо, я знаю глупый вопрос, но я вижу туманный комментарий «большая база данных», а также малая и средняя, ​​и мне интересно, что это значит. Может ли кто-нибудь определить, что такое малая, средняя и большая база данных для нас, неофитов SQL?

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

• Маленький: 10 ⁵ или меньше записей.
• Средний: от 10 ⁵ до 10 ⁷ записей.
• Большой: от 10 ⁷ до 10 ⁹ записей.
• Очень большой: 10 ⁹ или больше записей.

Как предложил плакат dkretz , вы также можете подумать об этом с точки зрения свойств, которые имеет каждый вид базы данных. Классифицируя это таким образом, я бы сказал:

• Маленький: производительность не имеет значения. Ваши запросы работают нормально, без какой-либо специальной оптимизации. Вы видите лишь незначительную разницу в производительности при использовании таких усовершенствований, как индексы.

• Средний: в вашей базе данных, вероятно, есть один или несколько сотрудников, которым на неполный рабочий день поручено ее обслуживание и уход. Эти люди обращают внимание на состояние базы данных; их основная административная ответственность - предотвращать недопустимые проблемы с производительностью и минимизировать время простоя.

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

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

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

Один из способов понять это - наблюдать за вашими тестовыми запросами.

В небольшой базе данных индексы не имеют значения.

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

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

Большая база данных заставляет вас отказаться от использования реляционных баз данных.

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

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

«Большая база данных» - действительно расплывчатое понятие. В ответах на этот вопрос уже есть очень разные ответы и мнения. Некоторые подходы к определению «малых», «средних» и «больших» баз данных могут иметь больше смысла, чем другие, НО ТОГДА, в какой-то момент я считаю, что каждое определение правильное, истинное и действительное.

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

Итак, означает ли это, что не имеет значения, можете ли вы определить, является ли конкретная база данных большой или нет?

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

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

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

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

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

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

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

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

Я бы хотел больше времени, потому что эта тема увлекательна. Я надеюсь, что этот небольшой вклад станет для вас отправной точкой в ​​этом увлекательном мире SQL.

Для этого определения необходимо учитывать развитие оборудования:

1. Небольшая база данных: рабочий набор помещается в физическую оперативную память одного стандартного сервера (сейчас около 16 ГБ)

2. Средняя база данных: помещается в один или несколько (через RAID) стандартных жестких дисков на одной машине (сейчас до нескольких ТБ)

3. Большая база данных: данные должны быть распределены по нескольким стандартным серверам, чтобы соответствовать (сейчас до нескольких ПБ).

Согласно статье в Википедии об очень большой базе данных

Очень большая база данных или VLDB - это база данных, которая содержит чрезвычайно большое количество кортежей (строк базы данных) или занимает чрезвычайно большое пространство хранения физической файловой системы. Наиболее распространенное определение VLDB - это база данных, которая занимает более 1 терабайта или содержит несколько миллиардов строк, хотя, естественно, это определение со временем меняется.

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

Я думаю, что что-то вроде Википедии или данных переписи населения США - это «большая» база данных. Мои личные списки адресов или задачи - это небольшая база данных. База данных среднего размера - это нечто среднее.

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