Только что такое "Большая база данных"?

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

Небольшая база данных - это та, где индексы не имеют значения.

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

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

Ответ 3

Лучший ответ, hands-down: большая база данных - это те, которые заставляют вас перестать использовать реляционные базы данных.

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

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

Ответ 4

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

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

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

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

В качестве примера: стратегия индексирования базы данных (аспект проектирования базы данных) зависит от количества записей для каждой таблицы (мера "размер" ), размера записи по количеству записей (другое измерение "размер" ) и Query Vs. Соотношение Creation/Update/Delete (аспект использования базы данных).

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

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

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

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

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

Существуют, конечно, и другие аспекты: дизайн схемы базы данных, стратегия хранения, проектирование сети, стратегия резервного копирования, хранимые процедуры/триггеры и т.д. программирование, прикладное программирование (против базы данных) и т.д. На все эти аспекты влияют разные понятия "размер" (размер записи, количество записей, размер индекса, индекс, схема, размер хранилища и т.д.).

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

Ответ 5

Вы должны учитывать продвижение оборудования для этого определения:

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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