Что замедляет рост производительности базы данных?

Question

Я создаю базу данных, и сначала создаю прототипы и бенчмаркинг. Я использую H2, коммерческую бесплатную, встраиваемую, реляционную базу данных Java с открытым исходным кодом. В настоящее время я не индексирую ни один столбец.

После того, как база данных выросла до 5 ГБ, ее скорость пакетной записи удвоилась (скорость записи была снижена в 2 раза по сравнению с исходной скоростью). Я писал примерно 25 строк в миллисекунды со свежей, чистой базой данных, а теперь при 7 ГБ я пишу примерно 7 строк / мс. Мои строки состоят из короткого, целого числа, числа с плавающей запятой и байта [5].

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

Какие факторы могут замедлить работу базы данных, как это, если нет затрат на индексацию? Это как-то связано со структурой файловой системы? Исходя из моих результатов, я предполагаю, что способ обработки файлов в Windows XP и ntfs замедляет добавление данных в конец файла по мере его увеличения.

Answer 1

Это звучит примерно так. Производительность базы данных обычно значительно падает, поскольку данные больше не могут храниться в памяти и операции становятся привязанными к диску. Если вы используете обычные операции вставки и хотите значительно повысить производительность, я предлагаю использовать некоторый API для массовой загрузки, если H2 поддерживает его (например, Oracle sqlldr, Sybase BCP, Mysql «load data infile»). Этот тип API записывает данные непосредственно в файл данных, минуя многие подсистемы базы данных.

Answer 2

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

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

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

Answer 3

Для большинства баз данных добавление в файл базы данных определенно медленнее, чем предварительное увеличение файла и добавление строк. Посмотрите, поддерживает ли H2 предварительный рост файла.

Answer 4

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

Добавление данных (если все сделано правильно) является операцией O (n), где n - длина данных, которые должны быть записаны. Это не зависит от длины файла, есть операции поиска, которые легко пропускаются.

Answer 5

Вы выполняете добавочные коммиты? Поскольку H2 является ACID-совместимой базой данных, если вы не выполняете инкрементные фиксации, существует некоторый тип журнала повторов, так что в случае некоторого случайного сбоя (скажем, сбоя питания) или отката удаление может быть отменено. 1001 *

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

Answer 6

Использование H2 для файла данных 7G является неправильным выбором с технологической точки зрения. Как вы сказали, встраиваемый. Какое у вас «встроенное» приложение, если вам нужно хранить столько данных.

Answer 7

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

Answer 8

Я бы возложил вину на ввод-вывод, особенно если вы работаете с базой данных на обычном ПК с обычным жестким диском (я имею в виду не на сервере с суперскоростными жесткими дисками и т. Д.).

Answer 9

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