Ну, про поиск это нечестное сравнение. Мы же обсуждаем горячие данные, значит надо считать что вся база вместе с индексами влезает в память. Конечно, постгрес потребует в этом сценарии в несколько раз больше памяти на сервер и какой-нибудь скрипт прогрева, но какая разница.
Если поставить checkpoint_timeout равный частоте дампа в тарантуле и checkpoint_completion_target=0.99, то не будет ли поведение одинаковым? В смысле нам в обоих случаях надо в течении долгого времени переписать на диск (почти) весь массив данных.
Я бы хотел лучше понять утверждение про «на каждую запись делает много disk seek, то замедляет все на порядок и больше.»
Для простоты предположим что у нас есть апдейт поля, которое не входит в индекс.
И тарантул, и постгрес пишут последовательный журнал. По дефолту постгрес честно фсинкает этот файл, а тарантул нет, но допустим мы настроили одинаково.
Теперь тарантул запишет изменение у себя в памяти, а постгрес сделает fd.write (так что в вашем случае мы экономим на системном вызове). Этот write попадает в кэш ОСи, и теперь операционка и контроллер диска вольны откладывать запись на диск на сколько угодно (точнее до следующего чекпоинта), реордерить, объединять их в батч по признаку близости, etc. В любом случае изменения считаются персистентными и клиенту вернули «успех».
1) При наличии BBWC — гарантирует, насколько я понимаю. Вы кстати используете такое железо?
2) Парой постов выше Вы сказали, что сравнивали тарантул с постгресом. Я надеюсь, это сравнение было тоже с fsync=off?
Вообще мой вопрос вызван тем, что описанный алгоритм персистентности ничем в целом не отличается от того, что делает тот же постгрес, но при этом обещается на два порядка лучшая производительности на запись.
Если поставить checkpoint_timeout равный частоте дампа в тарантуле и checkpoint_completion_target=0.99, то не будет ли поведение одинаковым? В смысле нам в обоих случаях надо в течении долгого времени переписать на диск (почти) весь массив данных.
Для простоты предположим что у нас есть апдейт поля, которое не входит в индекс.
И тарантул, и постгрес пишут последовательный журнал. По дефолту постгрес честно фсинкает этот файл, а тарантул нет, но допустим мы настроили одинаково.
Теперь тарантул запишет изменение у себя в памяти, а постгрес сделает fd.write (так что в вашем случае мы экономим на системном вызове). Этот write попадает в кэш ОСи, и теперь операционка и контроллер диска вольны откладывать запись на диск на сколько угодно (точнее до следующего чекпоинта), реордерить, объединять их в батч по признаку близости, etc. В любом случае изменения считаются персистентными и клиенту вернули «успех».
Где тут сики на каждую запись?
2) Парой постов выше Вы сказали, что сравнивали тарантул с постгресом. Я надеюсь, это сравнение было тоже с fsync=off?
Вообще мой вопрос вызван тем, что описанный алгоритм персистентности ничем в целом не отличается от того, что делает тот же постгрес, но при этом обещается на два порядка лучшая производительности на запись.