Задать вопрос
Местоположение
Россия, Москва и Московская обл., Зеленоград

Достижения

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

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

Все теги (121)

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

Все ответы (680)
  • Как организовать сеть (теория)?

    @Akina
    Сетевой и системный админ, SQL-программист.
    • 0. Всегда (на все три вопроса). 800 устройств в одном домене коллизий, это [censored] и полный ступор.
    • 1. Да. Но нет. Все в одной подсети - бред и никакого смысла.
    • 2. Немаршрутизируемые в Интернет адреса (bogon networks). Я бы делал подсети в 172.16. Но это дело вкуса.
    • 3. Ни разницы, ни усложнения нет и в помине. Стандартности тут тоже никакой.
    • 4. Каждую подсеть в свой VLAN. Ибо нефиг.
    • 5. Серверы в отдельных подсетях. Причём не одной. Что делать серверу видеонаблюдения в подсети бухгалтерии?
    • 6. Стройте схему на основании потоков трафика, а не по некоему мистическому наитию.
    • 7. Не у телефонии, а у некоторых коммутаторов есть специальная работа с VoiceVLAN. да, только экономия портов. Если не работал - то и не связывайся. Потом поэкспериментируешь.
    • 8. По требованиям безопасности сеть видеонаблюдения вообще должна быть по возможности физически отделена от пользовательской. Отдельные коммутаторы и кабельные линии. да и трафика они генерят - могут забивать каналы, оно надо? То же и с линиями охранно-пожарной сигнализации - но тут строго, никаких "по возможности".
    • 9. Сервер печати. И да - он и принтеры в отдельном VLAN.

    Ставим L3 коммутатор, который будет рулить потоком, его же добавляем в качестве шлюза.

    Ставь сразу нормальный маршрутизатор.
    Потому что коммутатор, хоть и L3, тебе ничего не даст во вменяемой форме - ни статистики, ни управления, ни наблюдения.
    Ответ написан
    13 комментариев
  • Что такое кластерный индекс в mysql?

    @Akina
    Сетевой и системный админ, SQL-программист.
    Кластерный индекс... это на самом деле понятие крайне виртуальное.

    Что такое обычный некластерный индекс? берём выражение индекса, считаем его значение для каждой записи, сортируем и пишем на диск. Получаем отдельную структуру, в которой выражение индекса сортировано. Когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи сразу половинным делением быстренько найдём нужное значение, возьмём из него уникальный идентификатор записи, и обратимся за записью. Если в таблице 1000 записей, то для поиска заданного значения без индекса нам в среднем пришлось бы просмотреть 500 записей, а с индексом - всего 10.

    Теперь что такое кластерный индекс... сначала почти то же. Берём выражение индекса, считаем его значение для каждой записи, сортируем и... а вот теперь не записываем по порядку эти значения с номерами соответствующих записей в отдельную структуру, а сами записи располагаем в этом порядке. Теперь, когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи, как это было, когда записи не сортированы, сразу половинным делением быстренько найдём нужное значение. Но нам уже не надо получать номер записи и обращаться за ней - мы нашли саму нужную запись.

    В MySQL (точнее, в используемом по умолчанию движке InnoDB) первичный индекс, во-первых, существует ВСЕГДА, во-вторых, определяется так (в статье, на которую дали ссылку, имеются неточности в пункте 2):
    1. Если первичный ключ задан явно, то его выражение является также и выражением кластерного индекса. Или иначе - первичный ключ и есть кластерный индекс.
    2. Если первичный ключ явно не задан, но в таблице имеется индекс, отвечающий всем следующим требованиям:
      • является уникальным
      • не является функциональным, в т.ч. не использует в выражении вычисляемые поля
      • не использует в выражении поля, которые определены как допускающие значение NULL

      то именно такой индекс используется в качестве первичного. А если таких индексов несколько, то используется первый по тексту запроса на создание таблицы
    3. Если не имеется ни того, ни другого - генерируется синтетический скрытый 6-байтовый номер записи, который и используется как первичный ключ. Следует отметить, что штатных способов доступа к этому значению не существует.


    Выглядит так, как будто это просто физическая сортировка данных по индексируемому полю.

    Фактически - именно так.

    Создаётся ли отдельная таблица или просто упорядочивается хранение существующих данных?

    Не создаётся. Но при изменении первичного индекса таблица полностью пересоздаётся с новым физическим порядком записей.

    Если данные упорядочиваются этим индексом, допустим по ID, то почему при select без сортировки данные могут возвращаться в произвольном порядке, а не отсортированные по ID по-умолчанию?

    Если не задан явно ORDER BY, сервер имеет право вернуть записи в любом порядке, как ему удобнее. В большинстве случаев, но не всегда, он будет возвращать записи в порядке чтения с диска...

    Представь такой (на самом деле невозможный, но не суть) случай - ты запросил таблицу. Вторая половина её ещё лежит в кэше, а первая уже выдавлена оттуда данными другой таблицы, нужными для выполнения запроса. Конечно, наиболее оптимальным будет начать передачу данных клиенту с этих записей, а пока они передаются, подчитать остальные, и передать их позже. Вот тебе порядок-то и поломался...

    ===

    PS. Кстати, правило выбора индекса, который будет использоваться в качестве кластерного, имеет неприятный побочный эффект. Если у некоторых полей, входящих в какие-то индексы, изменяется свойство NULLability, то это может привести к изменению того, какой из имеющихся индексов станет использоваться в качестве первичного по пункту 2. В результате мы получим невозможность использования INSTANT / INPLACE методов, и будет использован длинный COPY. Впрочем, ситуация такая крайне редка.
    Ответ написан
    2 комментария
  • Порекомендуйте варианты построения и оборудования для ЛВС в строящемся административно-складском здании 1500м2?

    @Akina
    Сетевой и системный админ, SQL-программист.
    • Выделение отдельного помещения для размещения внешнего ввода (Интернет и телефонные линии), кросса, серверов и активного оборудования. Металлическая дверь, кодовый замок.
    • Три линии питания - две для питания оборудования, причём запитанные от разных лучей, или хотя бы от разных фаз, плюс одна для питания кондиционера (минимум 7 кВт), плюс дежурное освещение.
    • Система пожаротушения - газовая, углекислота или фреон. Порошок - нафиг, случись что, всё оборудование можно выбрасывать и закупать новое. Воды быть не должно в принципе - даже просто проходящих через помещение труб.
    • Обязательно стойка (или стойки). Лотки, органайзеры, включая органайзеры электропитания.
    • Обязательно бесперебойники - причём время удержания должно быть минимум часа полтора, причём с учётом рабочей деградации батарей.
    • СКС разводится от розеток возле рабочих мест и до патч-панелей стойки витой парой 5 или 5е категории, чистой одножильной медью, многожилка или омеднённый алюминий ни в коем случае. Какие-то промежуточные и местные коммутаторы - забудь как страшный сон. Прокладка - по запотолочным металлическим лоткам, последний метр в коробе, монтаж на встраиваемые в короб розетки (для рабочих мест в центре комнаты - напольные короба и встраиваемые в пол розеточные блоки). Прокладка до внешних камер соответственно проводом для внешней прокладки, розетки во влагозащищённых распаечных коробках (по опыту - минимум 100х150). С розетками внутри не жадничать - на одно рабочее место минимум 2 розетки (локальная сеть, телефон), плюс дополнительные для сетевых принтеров и для точек доступа, ну и учесть, что сотрудники любят переставлять мебель самым идиотским образом. Судя по чертежам и описанию - будет штук 200 розеток.
    • Коммутаторы - управляемые как минимум L2+, PoE для подключения точек доступа, видеокамер и IP-телефонов, обычные для подключения компов и сетевых принтеров. Модель не сильно важна, но лучше сразу иметь дохрена резервных портов, чем потом докупать. Клиентские порты гигабит однозначно. Но я бы рекомендовал брать с хотя бы парой 10-гигабитных портов. Вендор по вкусу (лично я бы ставил D-Link).
    • Маршрутизатор - согласен с предыдущими товарищами насчёт Микротика вменяемой старшей модели.
    • Точки доступа - лучше сразу брать комплект для бесшовного покрытия всего здания. Насчёт количества, размещения и необходимости внешних антенн вместо встроенных ничего не скажу - это только по месту решается.


    Ну по минимуму где-то так.
    Ответ написан
    6 комментариев
  • MSSQL and mysql в чем отличие?

    @Akina
    Сетевой и системный админ, SQL-программист.
    Но это такое убожество что я толком ничерта не понимаю

    Не надо путать причину и следствие. Причина - это что ты ни хрена не понимаешь. А следствие - оно тебе кажется убожеством.
    offtop
    В скобках отмечу, что если ты не только ни хрена не понимаешь, но и жалуешься на это, и считаешь это достаточным обоснованием того, чтобы назвать убожеством - то ты и не хочешь понимать, и не пытаешься понять. В смысле не пытаешься по-настоящему, прочтение пары страниц из мануала под этот термин не проходит.


    отличаются ли запросы sql MSSQL от Mysql

    Да. Точнее, самые простейшие базовые запросы могут выглядеть одинаково. Но не более, чуть только хоть какая-то сложность, и одинаковость заканчивается. Синтаксис различается, и весьма сильно. А кое-где даже подходы к решению задачи различаются, и код с одной СУБД на другую не адаптируется совсем - только полное переписывание.

    возможно ли сменить БД без нарушения функциональности софта.

    Если запросы хардкодом - крайне маловероятно. Если тексты запросов - ресурс, вероятность несколько выше. Если вся лигика находится на сервере, общение с ним выполняется исключительно обращением к представлениям и вызовом процедур, а само приложение является чистым интерфейсом - скорее всего возможно.
    Ответ написан
    Комментировать
  • Что лучше, по одной или несколько записей при INSERT?

    @Akina
    Сетевой и системный админ, SQL-программист.
    Запись пакетом быстрее и менее нагрузочна, но выше вероятность потери при сбоях.

    PS. 40 записей в секунду - это в общем-то ни о чём..
    Ответ написан
    Комментировать

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

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