— заказ не оплачивается онлайн, это не дистанционная продажа
— заказ не доставляется
— человек приходит в обычную аптеку, как обычный покупатель, покупает лекарства по заранее переданному списку. Еще и рецепты предъявить должен на рецептурные препараты
300k черная или 200k белая — это уже ближе к реальности. И да, немалое количество людей предпочтет 300k сейчас, а не пенсию на 5к больше потом (может быть)
P.S.: Есть почти легальный вариант получать на ИП за 6% налогов (но там свои нюансы), но для этого нужно желание компании так платить (и как подмечено выше, наличие денег на р/с, а не в чемодане)
Нужна прокси, которая позволит фильтровать json от api своим приложением. OpenResty, если не смущает Lua, или полноценное приложение на любимом ЯП/фреймворке. Заправляете api через hosts на локальное приложение/прокси, фильтруете ответ на определенные урлы запроса, остальные проксируете как есть
Это не кодировка сломана, а заголовок/мета с указанием кодировки. Порог входа, так сказать, вместо капчи с уравнениями. Ну и не говоря о том, что «нормальная» кодировка там — винтажная windows-1251
Предположу, что /assets и /images обрабатывают разные апстрим-сервера. Порядок и количество заголовков у них различаются, второй вполне может быть и не-nginx'ом, x: hit на nginx будет HIT капсом, если это upstream_cache_status
РосНИИРОС был некоммерческой организацией, учрежденной государством. Де-факто продажей воздуха (домены и адреса) занимались аффилированные компании, выжимая сверхприбыли. А тут остатки чужих активов перевели уже прям себе, приватизация в стиле 90х.
В поездах метро такое сделали (возможно только в новых моделях) на Филевской линии — при нажатии на кнопку до станции она меняет цвет, подтверждая, что желание пассажира принято.
Подтверждения того, что в базе есть 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 придумать не получается
— заказ не доставляется
— человек приходит в обычную аптеку, как обычный покупатель, покупает лекарства по заранее переданному списку. Еще и рецепты предъявить должен на рецептурные препараты
P.S.: Есть почти легальный вариант получать на ИП за 6% налогов (но там свои нюансы), но для этого нужно желание компании так платить (и как подмечено выше, наличие денег на р/с, а не в чемодане)
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. За приятные фичи приходится платить.