MemoryMappedFile и b-tree для приложения кэша

Это всего лишь идея, у меня пока нет кода, мне нужен совет по
дизайну. Я бы использовал кеш (не распределенный в первом случае),
используя MemoryMappedFile в c #. Я думаю, что было бы хорошо иметь
б-дерево как структура undelying, но это спорно, а также. Итак,
вопрос:

* Является ли B-tree хорошей стратегией для быстрого поиска
элементов поиска, когда поддержка с уменьшением числа - это файлы с
отображением памяти?
* Какие подсказки и трюки у нас есть с файлами с памятью?
Насколько вид может быть большим, каковы недостатки, когда он
слишком мал или слишком велик?
* Многопоточное рассмотрение: как мы имеем дело с файлом памяти и
параллелизмом? Предполагается, что кэш-сервер будет высоко оценен
клиентами, какая стратегия лучше иметь что-то своею?

Поскольку @Internal Server Error спрашивает, я интегрирую вопрос
с этим: Ключ будет строкой, длиной около 64 символов. Данные будут
байтом [] длиной около 1024 байт, но рассмотрим среднее значение в
128 байт или лучше: то, что я хочу кэшировать, - это объекты OR/M,
давайте рассмотрим, как долго является сериализованным объектом в
байтах с чем-то вроде сериализатора BSOn ,

* B-Tree хорош (с файлами с отображением памяти), но если файл не
всегда полностью хранится в резидентной памяти, тогда выравнивание
по B + Tree с выравниванием по страницам намного лучше. [См.
также](http://idlebox.net/2007/stx-btree/) .
* Трюк с файлами с отображением памяти заключается в
использовании 64-битной архитектуры, чтобы вы могли отобразить весь
файл в память, иначе вам нужно было бы отображать только части и
кешированный `read` s может быть быстрее, чем
`mmap` s.
* Попробуйте CAS (сравните и замените) по общей памяти. [См. также](https://stackoverflow.com/a/2846327/257568) .