Как уменьшить операции с диском у БД и какую БД взять под php?
Сразу скажу, что с БД у меня опыта очень мало, использую MySQL из PHP, и не особо понимаю различий между MyISAM и InnoDB.
Использую InnoDB. За два дня выполнил 15 млн запросов INSERT, 30млн запросов UPDATE. В итоге параметр у SSD Wear Level Count вырос на 10% (диску около года). Что как бы не очень хорошо.
Сделаю предположение, что в InnoDB и INSERT и UPDATE делают по 2 операции записи.
Хотелось бы по другому - чтобы БД операции вида INSERT DELAYED кешировала. Ну накопилось там операций INSERT DELAYED в таблицу на 16kb - она этот 16kb блок на диск скинула. Не накопилось, но прошло много времени (допустим 5 сек) - скинула на диск что накопилось.
Операции UPDATE DELAYED хотелось бы, чтобы проводились по другому. В виде трех операций: SELECT, INSERT DElAYED, DELETE DELAYED
DELETE DELAYED - тоже кешировать (накопилось штук 30 операций - разом все на диске обновляется, пока не накопилось, либо не прошло некоторое время, ничего с диском не делается).
- в результате таких изменений, при длине строки около 500байт, я ожидаю сокращение числа операций записи на диск примерно в 20 раз, при незначительной потере надежности.
- и хотелось бы реализовывать все это не на стороне своих скриптов, а средствами БД.
А то как сейчас, бедный SSD изнашивает и TLC и SLC кеш, и наверное ему это нехорошо...
А то как сейчас, бедный SSD изнашивает и TLC и SLC кеш, и наверное ему это нехорошо...
ИМХО, это очень странный критерий для оптимизации. Если производительность устраивает, то чего жалеть железо - тем более в production это обычно не наше железо.
Не... ну можно соптимизировать... UPDATE можно вообще убрать. INSERT можно раз в 100 уменьшить.
Я обычно все делаю без БД - на файлах без перезаписи (аналог update). Когда у меня был HDD, то я и запись делал по 100 объектов в один файл (аналог insert), чтобы чтение потом шло быстрее. Но это лишний программный код.
RAM DISK - плохая идея - в случае чего потеря всех данных. Я окей потерять сотню строк, но не все)).
2 дня работы тоже на дороге не валяются)). Хотелось бы хорошее изящное решение)).
Сегодня у меня SSD на TLC памяти. Через 5 лет будет на PLC. как бы... слишком часто в будущем придется SSD менять)). вместе с пропавшими на них данными).
Владимир Коротенко, у меня 860-й, но процесс помирания ssd, он отчасти вероятностный)). И я не поинмаю, как выравнивается износ SLC кеша, и потребительские SSD на живучесть SLC кеша никто даже не тестировал. Понятно, что все эти данные они в TLC скорее всего не попадают даже (однако число циклов износа почему-то растет понемногу), но в SLC кеше там творится ужас чего...
Если запросы идут пачками в рамках одного и того же скрипта, то идеальным решением будет использование транзакций.
Если заворачивать пачку DML запросов в транзакцию, то производительность иннодб становится вровень с майисам. А в данном случае нам важно что достигается эффект отложенной записи, поскольку результат записи нас интересует для всей транзакции, а не для отдельного запроса, а БД достаточно умна чтобы флушить данные на диск пачками. И в итоге все летает и диски не напрягаются даже при дефолтной настройке innodb_flush_log_at_trx_commit
При рекомендованном вами innodb_flush_log_at_trx_commit = 2 InnoDB работает в моем случае сильно быстрее, чем мои воспоминания о MyISAM в операциях Update ))
Если так сделать, вы рискуете получить кукиш вместо данных. БД специально так устроена, чтобы даже при выдергивании вилки из розетки, все операции, которые клиент увидел как подтвержденные, были фактически подтверждены.
mirosas, угу, а индексы сами себя починят при отвале целой страницы. Вы выдумали странную ситуацию:
адекватные (психически и финансово здоровые) инженеры не строят серверное решение без дискового массива - минимум два диска в зеркале, причем разных производителей
под офисной нагрузкой такой массив живет десятилетиями
на хайлоаде применяют более масштабные решения, включая использование SSD банально под кэш - то есть, данные через них буквально прокачиваются, толстым потоком.
Вы же хотите изватить работу механизма ACID ради того, чтобы не изнашивать SSD. Это нонсенс.
Армянское Радио, это не серверное решение. Это девелоперская машина. )) иногда нужно обрабатывать огромные объемы данных.
на хайлоаде наверное SLC под кеш.
Я хочу получить нечто среднее между InnoDB и HEAP.
Отвал целой страницы это скорее исключение (пускай и частое), чем правило. Разумно при запуске сервера им самим себя чинить, пускай и с небольшой потерей данных (ну там строк 100).
