Объясните на пальцах про фрактальные индексы

Ну на первый вопрос базовой отвечает даже вики:

Like a B-tree, a Fractal Tree index is a generalization of a binary search tree in that a node can have more than two children. Furthermore, unlike a B-tree, a Fractal Tree index has buffers at each node, which allow insertions, deletions and other changes to be stored in intermediate locations. The goal of the buffers is to schedule disk writes so that each write performs a large amount of useful work, thereby avoiding the worst-case performance of B-trees, in which each disk write may change a small amount of data on disk.

Или ты хочешь примеров кода?

На второй второй вопрос у меня ответа нет. Мы для нескольких достаточно толстых БД (select/insert=1) используем токудб уже с год, брат жив. Пробовали эксперимента ради для баз, где очень много upsert (примерно раз в 200 больше, чем чистых селектов) и данных под полтерабайта - и остались на иннодб. Может, повторим эксперимент.

Или ты хочешь примеров кода?

Ну в идеале было бы что-то вроде видеолекции по разработкам баз данных, как например у мейлрушечного технопарка :).

Я просто хочу понять, где срубили профит. Если научились собирать btree index из чего-то вроде оплога и коммитить толстыми кусками, то ведь сам оплог все равно надо мелкими кусками писать на диск, чтобы не слетел при выключении?

Просто из чистого любопытства интересно, не критично.

---

А какой профит был на select/insert = 1 и почему на апсертах не прокатило?

Сходил к дба, освежил память. В общем, дело не столько в апсертах, сколько в сложности таблиц и количестве данных в одной строке. Токудб с компрессией, очень сильно жрет cpu на тяжелых выборках, поэтому и отказались.

Понял. Сенькс.