Угадай размер базы данных

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

CREATE TABLE пользователь (
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
электронная почта VARCHAR (50),
пароль CHAR (40),
URL VARCHAR (1000),
PRIMARY KEY (id));

Суммирование всего: 4 + 51 + 40 + 1001 = 1096 байт в одной записи.
Если у меня 1 миллион записей: 1 000 000 x 1096 байт = 1 045 МБ!

Итак, это один крошечный столик, и я ищу 1 гигабайт для его хранения . Я прав в своих оценках?

5.11.2008 21:15:44
эээ ... откуда идет переход с МБ на ГБ?
Powerlord 5.11.2008 21:27:34
5 ОТВЕТОВ
РЕШЕНИЕ

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

Эти издержки, как правило, могут задаваться и контролироваться при создании таблицы с использованием выражений, специфичных для rdbms, и даже практически исключаться, если это снимок только для чтения. ОТО, возможно, вы захотите сделать этот отступ больше обычного, если на вашем столе будет много активности ВМС.

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

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

* Отредактировано, чтобы ответить на комментарий - «Что такое ВМС и что вы подразумеваете под обслуживанием? Удаление старых записей? - Снег»

IUD = Вставить Обновить Удалить активность. Чтобы проиллюстрировать проблему обслуживания, давайте рассмотрим, что произойдет, если мы создадим базу данных без свободного пространства и загрузим таблицу, подобную той, которую вы предлагаете, с записями, содержащими данные varchar. Все записи будут помещены в файл нашей базы данных, без пробелов между ними.

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

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

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

Структуры индекса имеют аналогичные проблемы.

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

2
6.11.2008 12:12:43
Что такое ВМС и что вы подразумеваете под обслуживанием? Удаление старых записей?
z-boss 5.11.2008 22:18:27

На самом деле поле varchar представляет более одного поля типа char. Это также относится и к другим типам данных.

Простой способ - добавить 100 записей со случайными тестовыми данными, а затем посмотреть, насколько большой файл базы данных в вашей файловой системе. Затем добавьте еще сотню и посмотрите, насколько она больше.

0
5.11.2008 21:19:01
Разве VARCHAR потенциально меньше 1000, если вы тоже не используете его?
kenny 5.11.2008 21:21:49
Также помните, что varchar требуется несколько байтов для хранения длины поля в дополнение к данным.
tmeisenh 31.12.2008 21:20:37

Как и предполагалось в предыдущем ответе, поле varchar немного усложняет задачу, поскольку оно использует достаточно места только для строки, содержащейся в каждой строке. После ввода некоторых примеров данных база данных, такая как MySQL (я полагаю, что другие тоже делают это), сможет сообщить вам средний размер каждой строки.

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

Изменить: так как многие из ответов здесь предлагают использовать пример данных, пожалуйста, смотрите мой ответ на и более старые вопросы, связанные с этим: PHP Script для заполнения таблиц MySQL

1
23.05.2017 10:32:50

На самом деле, использование пространства типа MySQL VARCHAR является переменным, в зависимости от введенных в него данных. Тип CHAR имеет постоянное использование пространства. Кроме того, ваши вычисления выглядят правильно: AFAIK, таблицы MySQL не хранятся на сжатом диске, хотя вы можете явно сжать их за счет того, чтобы сделать их доступными только для чтения.

1
5.11.2008 21:25:01

Загрузите некоторые тестовые данные с той же средней длиной поля, что и в рабочей области, а затем измерьте, сколько места требуется. Это то, что мы делаем.

Не беспокойтесь о загрузке 100 строк, просто загрузите 1M строк или 10M с начала. Загрузка большего количества строк в непроизводственные системы проста - это займет немного больше времени.

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

Убедитесь, что ваши тестовые данные, по крайней мере, такие же большие, как и производственные, в идеале больше.

2
5.11.2008 21:41:18
Хорошая идея, но где взять такой набор тестовых данных?
z-boss 5.11.2008 21:52:55