Я изучаю лучшие структуры данных для реализации простой временной базы данных с открытым исходным кодом, и в настоящее время я очень люблю использовать Persistent Red-Black деревья для этого.
Мои основные причины использования постоянных структур данных - это, прежде всего, минимизация использования блокировок, поэтому база данных может быть как можно более параллельной. Также будет проще реализовать транзакции ACID и даже возможность абстрагировать базу данных для параллельной работы в кластере. Самое замечательное в этом подходе заключается в том, что он позволяет практически временно создавать временные базы данных. И это очень приятно иметь, особенно для Интернета и для анализа данных (например, тенденции).
Все это очень круто, но я немного подозрительно отношусь к общей производительности использования постоянной структуры данных на диске. Несмотря на то, что сегодня есть очень быстрые диски, и все записи могут выполняться асинхронно, поэтому ответ всегда немедленный, я не хочу создавать все приложения под ложным положением, только чтобы понять, что это не очень хорошо способ сделать это.
Вот моя мысль: - Поскольку все записи выполняются асинхронно, а использование постоянной структуры данных позволит не отменять предыдущую и в настоящее время действительную структуру, время записи на самом деле не является узким местом. - Есть литература по таким структурам, как это, которые предназначены именно для использования на диске. Но мне кажется, что эти методы добавят больше накладных расходов на чтение для достижения более быстрой записи. Но я думаю, что лучше всего наоборот. Кроме того, многие из этих методов действительно заканчиваются деревьями с несколькими версиями, но они не являются строго неизменными, что очень важно для оправдания постоянных накладных расходов. - Я знаю, что при добавлении значений в базу данных все еще будет какая-то блокировка, и я также знаю, что должна быть хорошая логика сбора мусора, если не все версии должны поддерживаться (в противном случае размер файла, безусловно, резко возрастет), Также можно подумать о системе дельта-сжатия. - Из всех структур деревьев поиска я действительно думаю, что Red-Blacks наиболее близки к тому, что мне нужно, поскольку они предлагают наименьшее количество вращений.
Но есть некоторые возможные подводные камни: - Асинхронная запись - может влиять на приложения, которые нуждаются в данных в реальном времени. Но я не думаю, что это относится к веб-приложениям в большинстве случаев. Также, когда нужны данные в реальном времени, можно было бы разработать другие решения, такие как система регистрации/проверки конкретных данных, которые необходимо будет обрабатывать более оперативно. - Также они могут привести к некоторым конфликтам с фиксацией, хотя я не думаю о хорошем примере того, когда это может произойти. Также могут возникать конфликты в нормальной СУБД, если два потока работают с одними и теми же данными, верно? - Накладные расходы на наличие неизменяемого интерфейса, подобного этому, будут расти экспоненциально, и все обречено на провал в ближайшее время, поэтому все это плохая идея.
Любые мысли?
Спасибо!
изменить: Кажется, что возникает непонимание того, что такое постоянная структура данных: http://en.wikipedia.org/wiki/Persistent_data_structure