Масштабирование базы данных - производительность по сравнению с размером базы данных

Question

Я создаю приложение, которое должно будет загружать до 32 ГБ данных в мою базу данных. Я использую индексирование B-дерева, потому что чтение будет иметь запросы о диапазоне (например, от 0 < до < 1 час).

В начале (размер базы данных = 0 ГБ) я получу 60 и 70 записей за миллисекунду. После 5 ГБ три базы данных, которые я тестировал (H2, berkeley DB, Sybase SQL Anywhere), ДЕЙСТВИТЕЛЬНО замедлились до 5 записей за миллисекунду.

Вопросы:

• Является ли это типичное?
• Должен ли я по-прежнему видеть эту проблему с масштабируемостью, если бы я удалил индексирование?
• В чем причина этой проблемы?

Примечание:

Каждая запись состоит из несколько Интса

Answer 1

Да; индексирование улучшает время выборки за счет времени вставки. Ваши цифры звучат разумно - не зная больше.

Вы можете сравнить его. Вам нужно будет хранить разумное количество данных. Подумайте, следует ли индексировать по запросам - тяжелую выборку и легкую вставку? индекс везде, где предложение может использовать его. Легкая выборка, тяжелые вставки? Вероятно, избегайте индексов. Смешанная нагрузка; сравните его!

При проведении бенчмаркинга вы хотите как реальные, так и реалистичные данные, как по объему, так и по области данных (распределение данных, а не только всех «кузнецов», но всевозможные имена, например).

Answer 2

Полностью согласен с @ Richard-t - довольно часто в автономных/пакетных сценариях полностью удалять индексы перед массовыми обновлениями в корпус, только для их повторного применения при завершении обновления.

Тип применяемых индексов также влияет на производительность вставки - например, при использовании SQL Server с кластеризованным индексом индекс ввода-вывода используется для распространения данных, а также для обновления индекса, где, когда некластеризованные индексы обновляются отдельно (и, следовательно, более дорогими) Операции ввода-вывода.

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

Answer 3

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

Однако, учитывая, что:

1/Вы, кажется, обеспокоены тем, что ваши записи замедлится до 5/мс (что по-прежнему 5000/второй),

2/Вы только писать несколько целые числа на запись; и

3/Вы запросы только на основе временных запросов,

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

Если вы только когда-либо записываете последовательно-синхронизированные данные, вы можете просто использовать плоский файл и периодически записывать информацию «индекса» отдельно (скажем, в начале каждой минуты).

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

Это, конечно, зависит от моего предположения о вашем хранение является правильным:

1/Вы пишете записи последовательно на основе времени.

2/Вам нужно только запрашивать временные диапазоны.

Answer 4

Да, индексы, как правило, замедляют вставку вниз, при этом значительно ускоряя выбор (запросы).

Помните, что не все вставки в B-дерево равны. Это дерево; если все, что вы делаете, вставляет в него, оно должно продолжать расти. Структура данных допускает некоторое заполнение, но если вы продолжаете вставлять в нее числа, которые растут последовательно, он должен продолжать добавлять новые страницы и/или перемешать вещи, чтобы оставаться сбалансированными. Убедитесь, что ваши тесты вставляют числа, которые хорошо распределены (предполагая, что так они появятся в реальной жизни), и посмотрите, можете ли вы сделать что-либо, чтобы сообщить B-дереву, сколько объектов ожидать от начала.

Answer 5

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