Персистентные (чисто функциональные) Красно-черные деревья на производительности диска

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

Мои главные причины для использования персистентных структур данных состоят в том, чтобы, в первую очередь, минимизировать использование блокировок, таким образом, база данных может быть максимально параллельной. Также будет легче реализовать транзакции ACID и даже способность абстрагировать базу данных для работы параллельно над кластером некоторого вида. Большая вещь этого подхода состоит в том, что он делает возможные реализующие временные базы данных почти бесплатно. И это - что-то довольно хорошее, чтобы иметь, особенно для сети и для анализа данных (например, тенденции).

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

Вот мой ход мыслей: - так как все записи сделаны асинхронно, и использование персистентной структуры данных включит для не лишения законной силы предыдущего - и в настоящее время допустимый - структура, время записи не является действительно узким местом. - Существует некоторая литература по структурам как это, которые являются точно для использования диска. Но мне кажется, что эти методы добавят более чтение наверху для достижения более быстрых записей. Но я думаю, что точно противоположное предпочтительно. Также многие из этих методов действительно заканчиваются с мультиимеющие версию деревья, но они не строго неизменны, который является чем-то очень решающим для выравнивания по ширине персистентных издержек. - Я знаю там, все еще должна будет быть некоторая блокировка при добавлении значений к базе данных, и я также знаю, что должна быть хорошая собирающая "мусор" логика, если не все версии должны сохраняться (иначе, размер файла, конечно, повысится существенно). Также о системе сжатия дельты можно было думать. - Всех структур деревьев поиска я действительно думаю, что Красные Черные цвета являются большинством близко к тому, в чем я нуждаюсь, так как они предлагают наименьшее количество количества вращений.

Но по пути существуют некоторые возможные ловушки: - асинхронные записи-could-влияют на приложения, для которых нужны данные в режиме реального времени. Но я не думаю, что это имеет место с веб-приложениями большую часть времени. Также, когда данные реального времени необходимы, другой, решения могли быть созданы, как система регистрации/выезда определенных данных, которые должны будут работаться на способе более в реальном времени. - Также они могли привести к некоторым конфликтам фиксации, хотя мне не удается думать о хорошем примере того, когда это могло произойти. Также конфликты фиксации могут произойти в нормальном RDBMS, если два потока работают с теми же данными, правильно? - Издержки наличия неизменного интерфейса как это вырастут экспоненциально, и все обречено скоро перестать работать, таким образом, это все - плохая идея.

Какие-либо мысли?

Спасибо!

править: Кажется, существует неверное толкование того, какова персистентная структура данных: http://en.wikipedia.org/wiki/Persistent_data_structure