5.5.20

SMR и кое-что еще

Наверное, уже все (кому интересно) в курсе про скандал со спецификой записи на некоторых моделях жестких дисков. Эта специфика называется SMR.
Вот отличный пост на хабре, где объясняется проблема и приведен перечень дисков, где реализована данная технология:
https://habr.com/ru/post/500214/

Цитата:
"SMR хорошо подходит для обеспечения большой емкости по невысокой цене, когда число операций записи мало, а чтения — велико."
То есть, для баз данных даже со средней интенсивностью записи диски с такой технологией не подходят. И еще они не только сбоят в raid, но и могут давать невосстановимые ошибки.


Так что, рекомендую прочитать статью, а также изучить комментарии. Там я нашел несколько интересных моментов:
https://habr.com/ru/post/500214/#comment_21571374
"У меня лежит ящик разных SSD, которые после ремонта живут без проблем, пока не отрубишь им питание на две недели. После чего файлы уже не прочитать, или ссд вообще не включится. Память «стекает», это нормально, и чем больше износ, тем быстрее. Вендоры гарантируют сохранность данных в 3 месяца (Для TLC). Гуглите даташиты на энтерпрайз ссд, где информация более честная, чем в потребительском сегменте. PS: да, и регулярно на рекавери тащат флешки USB, с которых файлики полутора-двугодичной давности не читаются совсем, годовалые — с большим трудом, свежие — норм. Флешки разносольного качества, как ни странно — много оригинальных кингстонов".

и дальше в этой же ветке комментов:
"MicroSD и USB флешки не занимаются Self Refresh, поэтому их от потери данных не спасет постоянное нахождение под питанием. Большое количество недорогих SSD на Phison — я точно знаю что тоже не рефрешат себя."

Понятно, что обо всём этом можно было догадываться, но вот чтобы прямо явно сталкиваться - лучше не надо.

8.4.20

Вебинар по InterBase 2020

Завтра (9 апреля 2020) будет вебинар по InterBase 2020 с Embarcadero.
Расскажу про все интересные фичи, зачем, как использовать, и т.д.

upd: запись доступна тут
https://www.youtube.com/watch?v=I7Y920kSgKQ&feature=youtu.be

10.9.18

gbak -b -e. Сжимать или не сжимать?

При бэкапе (gbak -b) данные по умолчанию сжимаются. Что там за сжатие, я понятия не имею (надо спросить у разработчиков). Но у gbak есть опция -e, которая это сжатие отключает.

Решил проверить, как это повлияет, и имеет ли смысл.

Взял базу TPCR размером 30 гигабайт, Firebird 3.0.3, и сделал несколько раз бэкап на другой диск.
Результат - с опцией -e быстрее на 7.5-7.9%. На 18-ти минутах это 1 минута.
Если же база гораздо больше, и бэкап идет, например 10 часов, экономия бы получилась примерно 46 минут. На 10-ти часах это имеет смысл, а вот если бэкап идет часа 2, не больше, то тогда разница не так существенна.

Другое дело, что обычный бэкап этой базы занимает 21 гигабайт. А вот с опцией -e - 34 гигабайта! На 30% больше обычного бэкапа, и на 10% больше базы (в которой еще и индексы есть).

Так что, небольшая выгода по времени оборачивается серьёзным проигрышем в размере.
Решайте сами, надо оно (-e) вам, или нет.