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

Question

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

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

Вопросы:

• Это типично?
• Могу ли я по-прежнему видеть эту проблему с масштабируемостью, если УДАЛЕНА индексация?
• Каковы причины этой проблемы?

Примечания:

Каждая запись состоит из нескольких целых чисел

Answer 1

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

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

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

Answer 2

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

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

1 / Вы, похоже, обеспокоены тем, что ваша запись замедляется до 5 / мс (это все еще 5000 / сек),

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

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

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

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