агат-7, агат-9, Спектрум, ЕС-1841, dos, novel netware, windows 3.11-2019, RedHat 5-Fedora 35/Centos 8, FreeBSD, Sun Solaris Unix, SCO unix, десяток разных дистрибутивов Linux, Proxmox, Vmware, Hyper-V, Compex hub 1008 - Cisco Catalyst 65xx/Cisco router 72xx/Cisco ASR 1xxx, программирование от basic/pascal/asm8086 до php 7, веб-разработка full-stack (pixel-perfect), немного DevOps-стэка: ansible, prometheus, elk, consul, git, grafana, zabbix, docker, IaC и т.д.
Местоположение
Россия, Волгоградская обл., Волгоград

Достижения

Все достижения (18)

Наибольший вклад в теги

Все теги (89)

Лучшие ответы пользователя

Все ответы (65)
  • Стоит ли делать RAID из SSD?

    @sergey_privacy
    Админ со стажем, начинающий DevOps
    У меня есть один знакомый, который в лучшем смысле этого слова является компьютерным гиком, фанатом, маньяком своего дела. Пару лет назад задал я ему этот же вопрос. Он пытался мне что то объяснить, почему не получится, но прозвучало малоубедительно. Затарились мы с ним пивом, железом и начали тестировать. Интересовал только RAID-0, т.к. нужна была максимальная скорость, а не надежность. Коллега работает "ремонтником", поэтому у него выбор железа под руками оказался приличным. 3 разных контроллера и конфигурации от 2 до 4 дисков были опробованы нами. Скорость - практически такая же, как у одного из дисков. После моего безмерного удивления, собрали на обычных жестких дисках формата 2,5. При конфигурации из 2-х дисков на том же самом контроллере скорость возросла процентов до 190 от скорости одного диска. Три диска дали нам примерно 270 процентов скорости от скорости одного диска. 4 диска- 330-350% от скорости одного диска. Теоретическое обоснование сейчас не вспомню, т.к. не понял его и тогда. Но резюме следующее: сборка SSD в нулевой рейд скорости тебе не прибавит, только уменьшится надежность. Сборка SSD в рейды другого уровня намного быстрее угробит твои диски.
    Ответ написан
    7 комментариев
  • В осле не работает тень у блока внутри таблицы?

    @sergey_privacy Автор вопроса
    Админ со стажем, начинающий DevOps
    На хабре больше всего поражают больные люди, которые минусуют вопрос по тематике сайта. Я вопрос задал для того, чтобы получить ответ, а не для вашего развлечения или поднятия кармы. Зачем сливать вопрос, если не знаешь ответ? Лучше потом вернуться и прочитать решение вопроса.
    Ответ написан
    23 комментария
  • Как защитить обучающие материалы от слива?

    @sergey_privacy
    Админ со стажем, начинающий DevOps
    Любой контент, отданный пользователю, может быть сграблен. Ни практически, ни теоретически этого избежать не получится. Даже не трать силы/время/деньги на достижение недостижимого.
    Он может поставить камеру и снимать экран.
    Он может подключить устройство по USB и гнать изображение параллельно на соседнее устройство, где происходит запись.
    Ты можешь как угодно пытаться контролировать его компьютер, но он запустит браузер в виртуалке, а на хостовом компе - OSB studio и будет писать все, что творится в виртуалке.
    В этой вселенной на текущем уровне технического развития это абсолютно невозможно. 100500%
    Ответ написан
    Комментировать
  • Где можно попрактиковаться в php?

    @sergey_privacy
    Админ со стажем, начинающий DevOps
    Может быть я не прав и вас интересует программирование в качестве развлечения. Но основная масса программистов зарабатывает этим деньги. Поэтому зайдите на биржу фрилансеров, прочитайте первое попавшееся задание и попробуйте его сделать. Потом второе, третье. ДВИЖКИ ПИСАТЬ НЕ НАДО! Возьмите ModX и на нем реализуйте несколько заданий. Потом возьмите вордпресс и еще пару популярных и на каждом по 3-4 задачи сделайте.
    Ответ написан
    Комментировать
  • Что быстрее 10 запросов к файлам или 10 к базе?

    @sergey_privacy
    Админ со стажем, начинающий DevOps
    На Ваш вопрос нет однозначного ответа. Аналогично вопросу: что быстрее, поезд или автомобиль? Кто то будет сравнивать советский поезд с бугатти, другой будет сравнивать японские скоростные поезда с жигуленком.

    Базы с поддержкой SQL бывают разные: MySQL, MsSQL, Oracle и т.д. У каждой из них своя методика работы с кэшем, индексами, памятью. Очень многое зависит от размеров базы, размеров таблиц, построения индексов, самого запроса, настроек сервера БД и операционки. Если база нормально сконфигурирована, таблицы с нормальной архитектурой, правильно построены индексы, сервер обладает достаточным количеством памяти, то запрос будет быстрее большинства самопальных решений для работы с файлами.

    Если же файлы проектировала группа высококлассных специалистов, обвязка спроектирована именно под такие запросы, то выигрыш по скорости может быть значительным в этом варианте. Но такой "путь самурая" предполагает перенос объема вычислений в более быструю область сервера: память-процессор. У тебя будет меньше работа с дисковой системой, но вся логика работы приложения должна быть перелопачена под такой вид данных. Без фундаментальных знаний алгоритмов программирования и математики-информатики в целом, такие велосипеды лучше не городить. Теория графов, матрицы, хеши, алгоритмы сортировки должны быть у тебя на уровне выше институтского. Про удобные таблицы на 5-10 полей можешь забыть. У тебя будет куча небольших упорядоченных файлов со списками ключ-значение. Индексы, хеши, хеши по хешам, индексы по хешам и т.д. - это на долгое время будет твой кошмар, который ты должен будешь представлять у себя в голове. Работа с файлами напрямую не имеет смысла, если ты не планируешь создавать высоконагруженное приложение с большими объемами данных. В этом случае у тебя проработка архитектуры хранения данных займет на порядок больше времени, чем проработка архитектуры базы. Предварительный поиск по одному символу, по двум, трем, ссылка на файлы, которые содержат следующую часть, по которой уже идет поиск. Не забудь блокировки файлов, обработку ошибок доступа, обработку оборванных транзакций, уникальность значений, индексов или ключей и т.д. Отсутствие удобных select-ов с join-ами и блэкджеком потребует от тебя проработки возможных видов запросов, чтобы сам вид хранения данных оптимизировать под кастрированные возможности. А из запросов будут только аналоги простейших "SELECT xxx FROM file_yyy WHERE Id=zzz", "UPDATE file_xxx SET yyy WHERE Id=zzz", "INSERT INTO file_xxx yyy=zzz", "DELETE xxx FROM file_yyy WHERE Id=zzz". Этими 4-мя операциями тебе придется обходиться.

    Сейчас есть уже готовые "велосипеды" noSQL, но это не "путь джедая". Типовой сайтик, с десятком или сотней уников в час не стоит такого геморроя.
    Ответ написан
    Комментировать

Лучшие вопросы пользователя

Все вопросы (100)