Comments 4
Tarantool должен работать быстро. У нас есть грубая оценка — мы должны выдавать 1 Mrps на чтение и запись.

Не очень понятно, на каком оборудовании этот Mrps должен быть достигнут и каков размер данных для request?


Если этот Mrps отдается из кеша, то непонятно, при чем тут Memory ALLocators.

Как правило речь про рабочий десктоп и 1 миллион записей в базе (если я правильно понял про «размер данных»). Понятно, что десктоп десктопу рознь, боевые сервера слегка другие, а многие вообще на ноутах работают. Но это, как я пишу, грубая оценка, для ответа на вопросы типа «могу ли я ради новой фичи потратить еще 50 наносекунд на запрос?». Сразу можно прикинуть, что это порядка 5% деградация в самом простом случае, что — много.

А помимо железа и размера спейсов есть еще море нюансов. Индекс — hash или tree (или rtree)? Индексируемое поле — число, строка, скаляр? Сколько полей в индексе? А сколько индексов? Запросы из lua или по сети (или по сети дергаем lua хранимку)? Записи делаем по одной или большими транзакциями? Сравнение строк бинарное или utf8 case insensitive? И это то, что первое пришло в голову.

Если интересны реальные цифры, то на моем почти десятилетнем десктопе все самое простое из вышеперечисленного в lua выдает около 0.5Mrps на запись и 1Mrps на чтение.

С ноутбуком вообще непонятно про 1 Mrps на чтение. Миллион взятий в секунду из локального кэша? Ну как-то так и должно быть, хоть на derby, хоть на bboltdb.


Миллион операций по записи в секунду — это впечатляет, но все равно непонятно, при чем тут память. Надо стремиться к "Zero memory allocations in hot paths", иначе с "миллионом" будут проблемы, как не выделяй.


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

Тарантул по-умолчанию — БД в памяти (я упомянул об этом во первых строках этой статьи). Если под «локальный кэш» имеется ввиду кэш файловой системы — то он, соответственно, применим при чтении только к дисковому движку, и там быстродействие чтения упирается в диск нормальным образом. Если же речь про кэш процессора, то объем данных подбирается таким образом, чтобы в кэш он гарантированно не влезал.

Конечно, если есть возможность избежать аллокации — нужно её избежать. Но это всё же можно сделать не всегда. И тут приходит на помощь аллокатор в высоким быстродействием.

Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
team.mail.ru
Employees
5,001–10,000 employees
Registered

Habr blog