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

Один способ изобразить его путем наблюдения тестовых запросов.

А маленькая база данных является той, где индексы не имеют значения.

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

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

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

, Другими словами, нормализованная, реляционная база данных, где все индексы в мире не могут помочь Вам отвечать своим требованиям времени отклика из-за крупных СОЕДИНЕНИЙ.

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

Необходимо объяснить аппаратное продвижение для этого определения:

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

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

3. база данных Large: Данным нужно к распределенному через несколько товарных серверов для установки (до нескольких PBS теперь.)

В соответствии со статьей Википедии о Очень Большая База данных

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

Я думаю что-то как Википедия, или американские данные переписи являются 'большой' базой данных. Мои персональные списки адресов или todos являются маленькой базой данных. Измеренная база данных середины является чем-то промежуточным.

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

“Large Database” является действительно туманным понятием. Уже существуют совсем другие ответы и мнения, отправленные в ответах на этот вопрос. Некоторые подходы для определения “small”, “medium” и “large” Базы данных могут иметь больше смысла, чем другие, НО ЗАТЕМ в какой-то момент я полагаю, что каждое определение является правильным, верным и действительным.

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

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

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

Как пример: на Индексную стратегию Базы данных (аспект Проектирования баз данных) влияет количество записей для каждой таблицы (мера “size”) рекордным количеством записей времен размера (другая мера “size”), и Запросом По сравнению с операционным отношением Создания/Обновления/Удалять (аспект использования Базы данных).

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

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

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

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

Различные Индексные стратегии требуются для другого Запроса По сравнению с операционными отношениями Создания/Обновления/Удалять. Если Ваша База данных будет находиться под большой нагрузкой запросов, но будет редко обновлена, то производительность для полного приложения будет лучше, если Вы добавите каждый индекс, который улучшает время отклика запроса. С другой стороны, если Ваша База данных будет постоянно обновлена, но нет операций выполнения больших запросов, то производительность будет лучше при использовании меньшего количества индексов.

, конечно, существуют другие аспекты: дизайн Схемы базы данных, Стратегия хранения, Проектирование сети, Стратегия резервного копирования, Сохраненные Процедуры/Триггеры/И т.д. программирование, Прикладное программирование (против Базы данных), И т.д. На все эти аспекты влияет по-другому отличное понятие “size” (рекордный размер, количество записей, индексируйте размер, индексируйте количество, дизайн схемы, размер ресурса хранения, и т.д.).

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

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