Исходное сообщение
"Один из разработчиков MySQL раскритиковал проект и рекомендо..." Отправлено _hide_, 07-Дек-21 11:06
> Каких ещё блокировок? Мы скоро обсуждать будем ассемблерные вставки? Кто это пишет дифы? Никто никаких дифов в набор данных не пишет (да и в логи пишутся отнють не дифы, а новые значение полей): либо переписывает измененный набор данных/релоцирует его и пишет заново, помечая старые данные как свободное место (MySQL), либо пишет весь блок отдельно и отмечает это в метазаписях как ожидающий вакуума (PG). VACUUM блокирует часть данных при релокации. MySQL-у Optimize Table нужен как таковой, только при использовании запросов вне индекса (при сканировании), PG требует этого "для обслуживания". > какие-то изменения просто хранит в виде инструкций в журнале изменений Хранить инструкции в журнале? Что за бред, такое было когда-то в InnoDB, но уже давно всплыло, а если журнал будет повреждён? Конец атомарности, разрушены внешние ссылки и вообще ахтунг и ручное восстановление. > Какой способ лучше? Для пользователей и разработчик-прикладников, лучше именно гибридный способ с повторным использованием освободившегося места (и фрагментацией как проблемой), потому что это даёт серьезный прирост к скорости (путем нагрузки на CPU и контроллер, но не на IO), нежели полное копирование всех данных при обновлении. Если брать разработчиков этих СУБД, то второй способ хорош тем, что его можно очень качественно отладить и оптимизировать, тем самым заняв нишу систем с низкой степенью отказа.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Каких ещё блокировок? > Мы скоро обсуждать будем ассемблерные вставки? Кто это пишет дифы? Никто никаких > дифов в набор данных не пишет (да и в логи пишутся > отнють не дифы, а новые значение полей): либо переписывает измененный набор > данных/релоцирует его и пишет заново, помечая старые данные как свободное место > (MySQL), либо пишет весь блок отдельно и отмечает это в метазаписях > как ожидающий вакуума (PG). > VACUUM блокирует часть данных при релокации. MySQL-у Optimize Table нужен как таковой, > только при использовании запросов вне индекса (при сканировании), PG требует этого > "для обслуживания". >> какие-то изменения просто хранит в виде инструкций в журнале изменений > Хранить инструкции в журнале? Что за бред, такое было когда-то в InnoDB, > но уже давно всплыло, а если журнал будет повреждён? Конец атомарности, > разрушены внешние ссылки и вообще ахтунг и ручное восстановление. >> Какой способ лучше? > Для пользователей и разработчик-прикладников, лучше именно гибридный способ с повторным > использованием освободившегося места (и фрагментацией как проблемой), потому что это даёт > серьезный прирост к скорости (путем нагрузки на CPU и контроллер, но > не на IO), нежели полное копирование всех данных при обновлении. > Если брать разработчиков этих СУБД, то второй способ хорош тем, что его > можно очень качественно отладить и оптимизировать, тем самым заняв нишу систем > с низкой степенью отказа.
	Введите код, изображенный на картинке: