Firebird 2.5 VS Interbase 9 / XE - что работает быстрее? - PullRequest
6 голосов
/ 26 мая 2011

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

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

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

Я спрашиваю

  • Это то же самое с Interbase?
  • Стоит ли пытаться прыгнуть в сторону Interbase?
  • Какая производительность лучше в целом?
  • Есть ли у Interbase такая проблема с историей, как Firebird, которая продолжает наращивать базу данных и замедляет ее?

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

Ответы [ 3 ]

8 голосов
/ 27 мая 2011

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

Firebird (и Interbase) оба используют Multi Version Concurrency Control, что означает, что изменения записываются в новой версии записи.Старые версии записей очищаются только тогда, когда нет открытых транзакций, которые заинтересованы в этой транзакции.Версии записей, созданные транзакцией отката, очищаются только во время развертки.

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

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

Для получения более подробной информации, смотрите gfix housekeeping

7 голосов
/ 26 мая 2011

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

3 голосов
/ 31 мая 2011

Вы можете отправить тестовые базы данных и тестовый набор разработчикам Firebird, чтобы они могли повысить скорость

Я начинаю думать, что база данных нуждается в разделении

...