А кто сказал, что там все отлично? Пишет она в среднем гораздо быстрее - это да, а вот чтение из нее будет менее производительным. Вы же решаете проблему с оверхедом при записи? А за это придется чем-то заплатить :)
Кроме того, BDB - это NoSQL база ключ-значение и перепиливание её под MySQL движок - своего рода натягивание совы на глобус, что вполне может отложить негативный отпечаток на производительности.
PS еще можно попробовать поубирать лишние индексы - это в любом случае снизит нагрузку на диск при записи, что с BDB, что на обычном движке.
vitaliy2: Оверхед будет, но не более чем в 2 раза при дефолтных настройках. Там отдельный тред висит, который чистит старые файлы. По умолчанию чистится файл, занятый менее чем на 5% полезными данными плюс поддерживается максимальный оверхед по всей бд в 2 раза (т.е. могут очищаться файлы и с большим процентом полезных данных). Пишу про java-версию BDB, но думаю обычная не сильно отличается в этом плане. В задачах с соотношением чтения к записи 1:1 или около того, реализации с использованием BDB как правило дают кратный прирост производительности именно за счет оптимизации записи.
У нас видимо очень разный опыт. Что это за проект где хватает MyISAM? Блог, форум, CMS — да, там хватит. Любого рода рекламная сеть, магазин или хоть что-то с биллингом или учетом товаров/остатков — нет.
Ну вот представьте, у вас есть магазин, в нем, кроме прочего, вы описываете 3 сущности: покупатель, продавец, платеж (или перевод/транзакция/проводка — кому как нравится). Вам нужно атомарно проверить достаточность средств у покупателя, перенести деньги из кармана покупателя в карман продавца и изменить статус платежа. Как вы это будете делать на монге? Ну ладно, засунуть оба кармана в одну коллекцию еще можно, но что делать с платежами?
Предположим, что вы дошли до того, чтобы конкурентно создавать задания на перевод и обрабатывать все платежи из одного треда — ошибки вроде бы пропали… до первой внезапной остановки сервера.
Про целостность не понял, что такое ODM? Маппилка пхп-объектов в монгу? Причем тут пхп? И причем тут маппинг? Вот вы замаппили объекты юзеров и ролей по коллекциям. После этого удаляете объект роль из базы, кто за вас будет проверять, что к этой роли привязаны юзеры? Проблема-то возникает не здесь, а дальше. С юзерами и ролями, допустим, вы все предусмотрели. Но вот прошло время, проект развивается и вы добавляете новую сущность в БД, которая так же привязана к ролям. Кто из разработчиков, добавляющих эту сущность, сам вспомнит, что надо модифицировать проверку перед удалением роли? Конечно, о нарушении целостности БД вы когда-нибудь скорее всего узнаете, и может как раз ODM вам о ней первым в лог напишет… Но разве от это не шаг назад по сравнению с констрейнтами в реляционной БД?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Кроме того, BDB - это NoSQL база ключ-значение и перепиливание её под MySQL движок - своего рода натягивание совы на глобус, что вполне может отложить негативный отпечаток на производительности.
PS еще можно попробовать поубирать лишние индексы - это в любом случае снизит нагрузку на диск при записи, что с BDB, что на обычном движке.