Двойная буферизация данных: данные есть в памяти СУБД и - порой те же самые - страницы тех же самых файлов в page cache системном. Плюс таскать данные из page cache в память СУБД тоже не совсем бесплатно. Исключение целиком точки отказа - кода файловой системы, ведь зачем журналируемая ФС, когда база и так журналируемая сама по себе? Ну и конечно порядком маркетинга. Может ещё чего, я не ораклист всё-таки.
То есть сначала идут write и их имеют право кэшировать и откладывать во времени все кому не лень.
А когда приложение требует fsync то файловая система проверяет и делает write всех грязных страниц ассоциированных с этим дескриптором из своего page cache, затем спускает инструкцию "а теперь отчитайтесь, что данные сохранены". Что в частностях протоколов ATA/SATA превращается в команду FLUSH CACHE (E7h) или FLUSH CACHE EXT (EAh):
ACS-2 draft пишет:
The FLUSH CACHE command requests the device to flush the volatile write cache. If there is data in the volatile write cache, that data shall be written to the non-volatile media. This command shall not indicate completion until the data is flushed to the non-volatile media or an error occurs.
Только после этого всего нормально работающий fsync возвращает ОК приложению.
Есть конечно. Регулярно у всяких 1с выключен fsync, а потом плачутся на форумах "бекапов нет, электричество моргнуло, база не стартует, спасите бизнес (нет, платить за это мы конечно не будем)"
WAL-то как писать, если fsync свою задачу не выполняет? А чекпойнты как делать? И выходит что ни чекпойнтов ни WAL нет и соответственно при любом внеплановом reset'е (электричество? kernel panic? thermal sensor?) вся база с некоторым шансом становится большой кучей бесполезного бинарного мусора. До консистентного состояния невосстановимой в принципе. Потому что когда надо было гарантировать что данные записаны - кто-то ответил ОК, но не сделал этого.
Цитата:
между ответом об успешной транзакции(читай сдвига версии) и физической записью wal
При полном ACID порядок обратный: сначала ждём fsync wal до нужной позиции, только потом отвечаем "commit". Для весьма многих проектов потеря хвоста обычно не так страшна как существенное уменьшение io и резонно ставить асинхронный коммит, когда не ждём fsync wal. Но сам fsync всё равно обязан быть и обязан отрабатывать корректно на всех уровнях кэширования io.
например всякие топ хранилища типа мускула итд не используют команды ос
Именно стандартные syscall системные все и дёргают.
На raw device емнип вовсе только оракл умеет. Потому что там хватает денег и народу пилить _очень_ много сопутствующей обвязки. А всем остальным это слишком геморойно как по разработке, так и по дальнейшему сопровождению.
Но что как раз критично для всех СУБД и как раз позволяет обеспечивать durability - вызов fsync. И бывает очень больно, если на каком-то из уровней кэширования io fsync не выполняет свою задачу. Но это про СУБД
А история clearstatcache машинерии легко прослеживается до 1999 года PHP3, дальше немного теряется и мне не очень интересно продолжать археологию.
А каким образом ваш рекурсивный вызов мог бы влиять на логику выполнения? Никаких побочных эффектов, а возвращаемое значение вы игнорируете. Что есть вызов функции, что нет его - воздух только греть.
print $obj->{"NAME"}; // Пытаюсь вывести все названия товаров
Результата 0 причина не очень понятна
Рассматриваете структуру вашего JSON, потом достаёте данные по нужному пути. Почему вы решили, что у вас на верхнем уровне объект? Это верно, но почему вы так решили? Почему вы решили, что у объекта верхнего уровня есть свойство NAME? Почему вы решили, что в нём будут "все названия товаров"?
The key_len column indicates the length of the key that MySQL decided to use. The value of key_len enables you to determine how many parts of a multiple-part key MySQL actually uses.
key_len показывает какую часть индекса планировщик желает использовать. Только вместо внятного вывода, какая же именно эта часть - показывает длину префикса в байтах. И на реальные индексируемые данные будьте любезны пересчитать сами.
datetime 8 байт, mediumint 3 байта. Поэтому раз видим 11 байт key_len - значит index condition идёт по обоим полям.
А в чём проблема? Если есть желание поковырять - то в путь. Поиском человек по крайней мере пользоваться умеет, раз нашёл тему ответы из которой ему помогли.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 11869
