В поездах метро такое сделали (возможно только в новых моделях) на Филевской линии — при нажатии на кнопку до станции она меняет цвет, подтверждая, что желание пассажира принято.
Подтверждения того, что в базе есть 60 млн записей, на его фейсбуке не видать. Кроме строки с номером 312 на скринах. Ну ок, 312 больше двухсот, но до 60млн явно не дотягивает
Злые языки пишут, что этот нашедший «базу» и есть тот единственный источник новости про 60 млн утекших карт. И что занимается он DLP-системами (это которые про борьбу с утечками), а в Сбере стоит DLP его конкурентов.
Если там есть данные об остатках на счетах, то к особо состоятельным клиентам могут действительно заглянуть в квартиру. Возможно, они не все деньги в банке хранят.
1 lz4 бесплатный и ускоряет в некотором усреднённо-офисном случае, как правило тестируют файловый сервер с несжатыми данными. Явно на h264 он не даст никакого прироста. А тут БД, оптимизирующая последовательную запись и размер блока к давно неактуальным вращающимся дискам. И recordsize=8k там ровно для этого. Сжатие данных будет порождать блоки меньшего размера, чего БД никак не ожидает. И как она ведет себя с lz4 и без lz4 — тема для отдельного бенчмарка, который покажет, что да, таки с lz4 быстрее. Или медленнее.
2) cow и внутриблочное сжатие не имеют ничего общего. COW прекрасная вещь для снапшотов и клонов (что очень удобно для организации нескольких записываемых(!) дев-копий продакшен базы). Но если у вас нет снапшотов, то и COW нет. Вернее, исходный блок будет помечен в метаданных свободным сразу после записи нового, если счетчик его использования в снапшотах = 0. И таки да, эта особенность записи скорее всего и дает падение производительности баз данных на ZFS
TOAST работает только на колонках c storage EXTENDED, используется когда вы знаете, что там будут лежать сжимаемые данные. Например текстовые документы размером больше 2кб. Это куда более предсказуемая и управляемая конструкция, чем дедупликация и сжатие на уровне хранилища.
ZFS пишет в ZIL (zfs intent log) и рапортует об успешной записи по факту физической записи в журнал. Потому авторы ZFS говорили ставить отдельный быстрый SSD для ZIL для производительной работы, и EСС память для предотвращения сбоев. А вот устойчивость к сбоям питания там не хуже, чем у других журналируемых файловых систем (подразумевается журналирование метаданных)
Кстати говоря, double write buffer в InnoDB рекомендуют отключать как раз по причине того, что этот функционал дублируется в ZFS
Профиль нагрузки fio на дисковую подсистему не совсем такой, как у базы данных. Да и шедуллер проца и кэши фс тоже играют роль в TPSах. Но в целом тут все уперлось в файловые системы. Предполагаю, что оригинальная статья задумывалось как быстрый ответ на вопрос «Какую ОС поставить на сервер в Хетцнере».
Отдельно хочется отметить включенную компрессию ZFS. lz4 конечно быстр, но зачем его использовать для БД? Для больших текстовых полей у самого PostgreSQL есть TOAST с нормальным сжатием.
Насколько я помню старые бенчмарки PostgreSQL, FreeBSD c UFS показывают примерно равные результаты с Linux c EXT3, от которых чуть отстает Linux c XFS. LVM дает просадку по производительности примерно равную ZFS. За приятные фичи приходится платить.
В стандарте eSIM не регламентируется MNP (смена оператора), на данный момент это скорее «мультисим», встроенная в смартфон. Но возможность иметь несколько симок в телефоне без их смены — это тоже неплохо. В разных регионах/странах выбирать более подходящего оператора. История c покупкой eSIM через интернет затрудняется тем, что в Европе точно так же требуют паспорт для оформления контракта, а постоплатные тарифные планы продадут вообще только гражданам ЕС.
А ведь еще недавно могли себе позволить написать такое в адрес F5. Ясно же, что nginx — прямой конкурент их железным балансерам, а прибыли с него никакой. Кроме как покупки для устранения конкурента, других полезных применений в F5 придумать не получается
— с официальных серверов с левого сайта кино не будет показываться
— дистрибьютеры контента платят деньги правообладателям, с рекламы или подписки, или просто покупки просмотра пользователем. Суммы, в зависимости от фильма, могут быть немалыми.
— пиратские кинотеатры получают доход с рекламы на сайте, но с правообладателями не делятся. Расходы на сервера есть, но на этом все. Рекламу на пиратских сайтах повесить решаться далеко не все, но полулегальным/нелегальным бизнесам — можно
— про рутрекер, куда выкладывают как бы сами пользователи для всеобщего блага и процветания, в заявлении речь не идет, речь про просмотр из браузера
PDF хранит либо ссылку на системный шрифт, либо ембеддит его в документ (полностью или только используемые символы). В любом случае это будут разные символы. TIFF спасёт!
Судя по сообщениям, основной источник провреждений — это якори судов, а не подвижки земной коры. И 4 метра — это, скорее всего, как раз вниз — заглубление снижает шансы быть зацепленным якорем. В прибрежных зонах кабели как правило закапывают — как раз по этой причине.
Строго говоря у SSD есть разница между рандомной и последовательной записью из-за продвинутости контроллера, сжатия и пр. Но она крайне незначительна, что видно на вашем тесте ext4 single для write и randwrite.
Кстати, пропустил интересный аргумент. Это же SSD, у которого нет разницы в randwrite и sequential write. У вас в последнем тесте IOPS на ext4 в write и randwrite одинаковы, так с чего бы вдруг такая разница у ZFS? Кэши на запись?
Тут надо заметить, что то, с каким размером блока оперирует файловая система, не означает, что приложение внутри нее делают рандомную запись и чтение такими блоками. Исходя из вашей информации, у вас вероятно полная виртуализация (не контейнерная), из чего следует, что команды чтения передаются виртуальному блочному устройству, в случае с какой-нить WinXP — виртуальному SATA контроллеру. Действительно, ОС будет выдавать команды на чтение и запись по 4кб, но это не означает, что это эквивалент 4k randread/randwrite. Я выше писал, какими блоками оперируют базы данных, это означает, что в случае 8k блока, ОС передаcт команды на чтение 2х последовательных 4k блоков.
Вообще, для такого случая использовать ZFS и хранящийся на ней файл — серьезный оверхед, потому как там для консистентности используется двойная запись (ZIL), для выравнивания надо было сделать zfs set sync=disabled
Но на самом деле, разговор совсем не о том. А о том, что вы тестировали 4k randread/randwrite фактически на устройстве с 128k блоком, в сравнении с 4k ext4, а вопрос был уже задан выше — что вы намеряли?
2) cow и внутриблочное сжатие не имеют ничего общего. COW прекрасная вещь для снапшотов и клонов (что очень удобно для организации нескольких записываемых(!) дев-копий продакшен базы). Но если у вас нет снапшотов, то и COW нет. Вернее, исходный блок будет помечен в метаданных свободным сразу после записи нового, если счетчик его использования в снапшотах = 0. И таки да, эта особенность записи скорее всего и дает падение производительности баз данных на ZFS
TOAST работает только на колонках c storage EXTENDED, используется когда вы знаете, что там будут лежать сжимаемые данные. Например текстовые документы размером больше 2кб. Это куда более предсказуемая и управляемая конструкция, чем дедупликация и сжатие на уровне хранилища.
Кстати говоря, double write buffer в InnoDB рекомендуют отключать как раз по причине того, что этот функционал дублируется в ZFS
Насколько я помню старые бенчмарки PostgreSQL, FreeBSD c UFS показывают примерно равные результаты с Linux c EXT3, от которых чуть отстает Linux c XFS. LVM дает просадку по производительности примерно равную ZFS. За приятные фичи приходится платить.
— дистрибьютеры контента платят деньги правообладателям, с рекламы или подписки, или просто покупки просмотра пользователем. Суммы, в зависимости от фильма, могут быть немалыми.
— пиратские кинотеатры получают доход с рекламы на сайте, но с правообладателями не делятся. Расходы на сервера есть, но на этом все. Рекламу на пиратских сайтах повесить решаться далеко не все, но полулегальным/нелегальным бизнесам — можно
— про рутрекер, куда выкладывают как бы сами пользователи для всеобщего блага и процветания, в заявлении речь не идет, речь про просмотр из браузера
Вообще, для такого случая использовать ZFS и хранящийся на ней файл — серьезный оверхед, потому как там для консистентности используется двойная запись (ZIL), для выравнивания надо было сделать zfs set sync=disabled
Но на самом деле, разговор совсем не о том. А о том, что вы тестировали 4k randread/randwrite фактически на устройстве с 128k блоком, в сравнении с 4k ext4, а вопрос был уже задан выше — что вы намеряли?