Вообще, для случаев баз данных админы относятся к NVME и SSD дискам с настороженностью: все кто хоть раз восстанавливал СУБД даже из файловых / снапшотных бэкапов, а не журналов - а админ со стажем, разумеется, в своей карьере делал это не раз - вряд ли добровольно захотят повторить эту процедуру для не тестовых данных. Цейтнот, стресс, ненужное внимание начальства, отсутствие особой благодарности ("твоя работа, ты должен(с)") - неприятные воспоминания.
C SSD / NVME ведь какая проблема? его не проверишь скандиском (то есть тулзами fsck, smartctl, badblocks, которые находят нарушения целостности файловой системы). Вернее - проверить-то можно, утилит, читающих SMART достаточно, но что даст инфа что диск уже не 100 а 98% ? Только , измерив через время и получив уже 96% поможет прикинуть скорость умирания.
Производители борются: гарантируют террабайты, увеличивается время работы, которое уже превышает в 1,5-2 раза срок морального устаревания, корректно работает trim.. но - зазеваешься и - SSD/NVME умирают внезапно: сегодня еще был и что-то проде было записано, а завтра виден как неотформатированный диск, или вообще не виден. Увы. Никакой "последней попытки только прочитать подключив вторым диском" как HDD скоростные диски не позволяют.
Поэтому админы любят SAS: олды помнят что это SCSI, а молодежь аппелирует что "промышленный стандарт, в домашние компы такого не ставят". SAS + RAID , аппаратный с памятью в контроллере побольше - вот типичная конфигурация для серверов СУБД.
Но мы сегодня - хипстеры, и нам нужна быстрая база. Конечно, можно взять Mongo, Но память у нас на сервере не безразмерная, а в проекте нужен порядок - струтура. Раз структура - значит Tables. RDBMS.
И по условию задачи нам нужно часто читать и редко писать. А читать разумеется данные отдаваемые в Web. И к счастью их можно терять - запишутся снова если что. Запись редка.
Попробуем использовать для этого NVME и выясним что он при всех достоинствах имеет один недостаток - малый объем. Поэтому база нам нужна такая, которая в этом малом объеме комфортно разместится.
На пальцах это выглядит примерно так: чем меньше данных гонять по сети / сокету - тем быстрее Nginx выплюнет первый байт клиенту. Гугл TTFB если интересно. Самым очевидным решением будет сжать наши данные в таблице! Любым алгоритмом для сжатия текста мы сживаем что можем в каждой нашей записи и храним в таблице сжатые данные! Бинго!
Увы, есть недостатки - например, если процессор слаб, то распаковка займет ресурсы и кто знает, останутся ли на Nginx, ха-ха. Впрочем, с таким подходом не поможет уже ничего - забудьте про слабые процессоры для СУБД сервера. А вот второй недостаток посущественнее - СУБД ведут всякие транзакции и как следствие распаковка выполняется примерно дважды - для приложения-клиента и для журнала самой СУБД.
В общем это худашая идея нахывается...
Есть ее улучшение - называется compress by page
но лучше если сам двидок будет уже compressed и воооюще. И такой движок есть! называется RocksDB
опишем как использовать его вместе с MAriaDB
Комментарии
Отправить комментарий