> При округлении логарифмов советую посмотреть в сторону NVMe, их, знаете ли, уже
> в ноутбуки и планшеты ставят. А также не забыть указывать, о
> какой именно странице памяти речь - впрочем, об этом я говорил
> в самом первом пункте.

http://www.3dnews.ru/917044 - 440000IOP/s на чтение. Быстрее сходу не гуглится.
Подозреваю, что это для pipeline-d (или multithreaded, если вам так понятнее) запросов.
Т.е. латенси там будет явно больше 2000ns. Судя по другим бенчам, типичным будет 10000ns.
Память - 60-100ns. Ок, не в 1000 раз, а в 100.
Но и sophia в памяти держит не все ключи, а малую часть. Так что, можно договориться про
коэффициенты 100 (чтение с диска) и 32 (работа в памяти).

>> можно округлить до сложности O(1)
> Вы не задумывались, почему в учебниках по алгоритмам так не делают? Так
> очень много чего было бы "округлить".

Делают. В последних параграфах, где даются советы по практической реализации.
Типичный совет:
"обращайте внимание на размер ваших данных, и константы, прячущиеся за O. Зачастую, O(N^2) бывает быстрее, чем O(log N), а O(1) - медленнее"

>> не производит катастрофических пауз
> На тех паттернах нагрузки, которые "имелись в виду"? На следующей итерации нашей
> беседы мы сможем выяснить какие же это паттерны? Что же с
> другими, которые в виду "не имелись"?

Ты уже казуистикой занимаешься.

>> безусловно, оно будет нагружать диск
> Не зависит ли эта нигде не учтенная compaction-нагрузка на диск от операций
> с БД? А если зависит, то где же эта зависимость в
> красивой формуле "О(1)"?

Нет, не зависит. Но тебе плевать на это.

>> если не ощущаешь себя, то вообще не живёшь
> Изложите, пожалуйста, подробней вашу философскую концепцию жизни.

Зачем? Тебе же всё равно.
Ты - не ты, и тебе на себя наплевать, раз чужое имя носишь, и во всеуслышание говоришь, что это не главное.
Если тебе на себя наплевать, то почему мне должно казаться, что тебе на меня не наплевать, и на мою "философскую концепцию жизни"?