что происходит в 1с когда строке присваивается бинарное значение фото? я не знаю, что дока говорит, что отладка говорит? а что будет если сдампить sql строчку в виде sql?
надо смотреть в коде как эту картинку пишут/читают,мало ли там не сами данные а какая то сериализация
а то я видел тут в вопросах (не про 1с но тоже смешно) - файл сериализовали с помощью php serialize и хранили в базе, а потом при передаче эту строку еще в json заворачивали
не важно что ты там будешь делать или не делать
либо ты изучаешь как веб сервис борется с автоматизацией (а гугл борется) и делаешь запросы в сеть самостоятельно эффективно и просто, симулируя хоть миллион одновременно открытых вкладок, либо запускаешь тяжелый браузер на каждую страницу но не изучаешь как оно там внутри устроено
напоминаю, первое число бенчмарка для обоих обсуждаемых процессоров одинаковое - 40к это значит в ИДЕАЛЬНЫХ условиях оба этих процессора будут решать хорошо распаралеливаемую задачу одинаково быстро, к сожалению очень часто коэффициент ускорения (или полезной работы) от количества потоков не линейный! а составляет квадратный корень от количества потоков, т.е. с увеличением количества потоков накладные расходы на поддержание их работы увеличиваются а выход работы - уменьшается
нельзя считать эти процессоры одинаковыми, только идеальные условия бенчмарков могут это показать.
p.s. да у epyc кеш третьего уровня 128мб, в 2 раза больше чем у rysen 64мб, т.е. вполне возможно что очень эффективно оптимизированная задача, удачно влезающая в кеш, может быть решена на epyc быстрее,... так же этот процессор чуть лучше покажет себя в задачах виртуализации и контейнеризации, когда работает много разных процессов, но разница будет очень незначительная, т.е. если бы у тебя был сервер то выбор epyc был бы более оправданным чем rysen
Prosecutorr, типовой потребитель не способен нагрузить много ядер (а у epyc 32 потока), у меня лично есть несколько задач личных которые данные перелопачивают, там конечно я на потоки раскидываю, ну может сжатие каким-нибудь zstd, во всех сотальных случаях у тебя 80% ядер будет простаивать и вот тут ты прочувствуешь что значит медленно в одном потоке.
лучше быстро один поток и чуть меньше ядер чем много ядер но каждый медленный.
Анна, по уму да, но неформальное требование по независимости удовлетворяться не будет, т.е. если твоему бизнесу внезапно не станет доступен google cloud то он прекратит работу и в этом случае
p.s. надеюсь ты понимаешь что расшифровка и хранение ключей в этом случае должна проводиться не на google сервере?
плюс, работа с зашифрованными данными очень ограничена, не построишь индекс, исключение - гомоморфное шифрование, но сомневаюсь что оно там реализовано
еще сжатие ntfs существует, и расширенные атрибуты (их не получить простым перечислением файлов в каталоге, по факту это тоже файлы, просто с особым именем)
но еще веселее - дедупликация (на серверных ревизиях), когда одинаковые части разных файлов записаны на диске только один раз
чтобы узнать сколько данных на диске занимают файлы, нужно анализировать mft (кстати именно там хранятся очень мелкие файлы)
у меня глупый вопрос, а зачем?
твое приложение можно запустить в wine? конечно, установка необходимых зависимостей (утилита winetricks) почти всегда лицензионно сомнительна, но 'меньше' чем установка всей ОС пираткой.
легально установить win7 на виртуалку будет нельзя
серверную версию в теории можно сдаунгрейдить, но покупать ее и устанавливать придется самому (нельзя будет взять систему от хостера)! не могу представить ни одной задаче где такие траты оправданы
KIQIK, в подавляющем большинстве случаев крупные проекты переростают из 'небольших и средних проектов, для прототипов, стартапов', которые в свою очередь реализуются на 'пхп или нода больше подходит для'
и проблемы решают по мере их появления, переписывая критичные куски на чем то адекватном
p.s. правильно писать изначально опасно дорого, т.е. можно не доделать до конца свой стартап и он в принципе не появится
такова селяви
иногда, если изначально грамотно составить архитектуру проекта, наверное можно подстелить соломку на будщее и не сильно на это потратиться
KIQIK, как минимум как только начнешь упираться по производительности в возможности железа, а это очень быстро произойдет с ростом количества клиентов (или данных, смотря что там за задачи)
Рано или поздно, при работе с данными наступит момент, когда либо самому придется заниматься многопоточной реализацией (не важно треды или процессы, все упирается в данные и параллельный доступ к ним), либо взять готовую реализацию, но в этом случае твоя задача уже должна быть кем то реализована
Правильная низкоуровневая реализация многопоточного доступа к памяти дает повышение производительности чуть ли не на порядок, по сравнению с универсальными решениями, а когда оперативной памяти стало действительно много, это снова стало актуально (хотя люди по старинке топают к приложениям баз данных в т.ч. in memory, тратя кучу времени на сериализацию и памяти на оверхед, точно помню как человек не мог на сотнях гб оперативке решать свою задачу, сторонними базами данных, не влезало, когда как своя структура в памяти заняла бы от силы 80гб)
Федот Крузенштерн, будет очень сложно найти дешевый vps с хорошим объемом диска, после терабайта начинается какая то фигня, вместе с большими объемами в довесок предлагают более дорогие процессор и память.
ну и помним про надежность, дешевые vps-ки не надежны так как там реселер и скорее всего не один уровень а больше, о данных ваших заботиться никто не будет
можно, если не использовать тяжелые DE
я помню на гигабайте оперативки завел древний 2007г нетбук eeepc900 поставив awesome de (правда с gentoo) - занимало 50мб оперативки, фильмы (xvid codec и 480 youtube не в браузере шли нормально, браузер работал но youtube не шло, все cpu отнимала загрузка видео, это было видно по глюкам но был плагин открывающий браузерное видео в mplayer сейчас это mpv)
такая железка вполне потянет минимальный список задач (само собой 100500 вкладок не открыть, тут бы одна заработала) но комфортно не будет