Pull to refresh
58
0.1
Alexander @speshuric

Пользователь

Send message
В первой организации нет ни Agile ни Scrum.

Короткие фиксированные спринты в scrum это очень многосторонний контракт. Судя по всему задачи большого (для scrum) объёма, соответственно команда реально ответственность не принимает, и, кстати, именно необходимость глубокой декомпозиции на целостные задачи 0,5-3 дня (5 дней в крайнем случае) является важным практическим ограничением scrum. Состав спринта менялся на ходу (и судя по всему меняется по каждому чиху).

Ретроспектива проходит с нарушениями. PO — дятел, который умеет долбить команду разработки, но не умеет работать по scrum. SM занимается не тем, чем должен. Ошибки/проблемы не обсуждаются и приоритет не согласуется. Технические решения не обсуждаются.

Технически, если из-за ошибки в third-party прикладному программисту пришлось доставать дизассемблер, чтобы спасти фичу, то это уже fail 80 lvl. С данным объёмом информации сложно сказать в чем именно fail: в архитектуре, в процессах, во взаимодействии, в компетенциях или еще в чем-то. И непонятно, можно ли его исправить (я видел как исправляли и как не исправляли).

Круто. Но это точно не конфетка.

Во второй организации непонятно, что хорошо, а что плохо, что случайно, а что систематично.

PPS: будущий «король математики» в конце VIII века — Гаусс жил на тысячу лет позднее.

Как быстро сосчитать сумму чисел от 1 до 100? Согласно легенде, первым эту задачку решил великий немецкий математик Карл Фридрих Гаусс, еще будучи школьником.

Выкиньте на помойку свой сборник легенд.
Арифметические и геометрические прогрессии известны человечеству на несколько тысяч лет больше, чем прошло от рождения Гаусса. И формулы их сумм тоже. "По легенде" единственное в чем отличился в данном случае юный Карл Гаусс — это то что он а) решил это в то ли в 6, то ли в 7, то ли в 10 лет, б) нашёл закономерность быстрее одноклассников и неожиданно для учителя.
Этот пример мне лично не говорит о том, что "чтобы быстрее получить результат и повысить его точность, нужно автоматизировать процессы", а скорее говорит о том, что над большой задачей нужно немного подумать, и если вам повезёт, или вы гений (Гаусс, например), то может быть вы сможете найти решение не за O(N), а за O(1). А автоматизировать — это если написать программу, которая тупо складывает от 1 до 100.


Если уже привязывать Гаусса к BigData, то лучше вспомнить нормальное распределение, которое часто называют распределением Гаусса или Гаусса-Лапласа. Да, конечно, не Гаусс его придумал, но он вывел его роль в многократном измерении. Это распределение играет фундаментальнейшую роль в теории вероятностей (центральная предельная теорема). Теория вероятностей — это база для матстатистики, фактически матстатистика — задача обратная теорверу: по набору данных найти распределение. А что есть BigData, как не решение статистических задач? Так что название GAUSS для системы обработки больших данных весьма обоснованное.


Кстати, Гауссу приписывают особую внимательность к точности деталей и формулировок и к качеству своих работ. А вот если к фактам относиться, как автор этой статьи, то точность прогнозов в ВТБ будет примерно сравнима с гаданием на картах (КДПВ намекает), а обоснованность с прогнозами осминога Пауля.


PS: для выигрыша в bullshit-bingo в статье не хватает слов "Devops" и "blockchain"

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

Хм. Тут 3 не связанных утверждения, причем вместе они могут быть неверны. Сейчас поясню.


Вы наверное заметили, что даже если БД находится в простой модели восстановления, то транзакцию можно откатить?

Конечно можно! Ведь MS SQL Server устроен так, что с мелкими-мелкими оговорками он все изменения данных (практически построчно) и события начала-отмены-фиксации транзакций последовательно пишет в журнал транзакций. Причем делает это до начала выполнения следующей команды (write-ahead logging). Типичная нагрузка на ЖТ — огромное число последовательных записей небольшого размера (0,5-60 КБ) и чтения при откатах транзакций, резервном копировании, репликации и т.п. Для минимально протоколируемых операций он, правда пишет не сами изменения, а только идентификаторы страниц. Чуть-чуть это нарушается для tempdb и при Delayed Transaction Durability, но не радикально.


Так вот, при простой модели восстановления большая часть записей идёт как раз в БД tempdb.

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


Т е интенсивность нагрузки на диски при любой модели восстановления суммарно по всем БД будет примерно одинакова.

Да, но это только потому что минимально протоколируемые операции для усредненной OLTP БД скорее исключение, чем правило.

Между моделями восстановления simple и full по разница такая же как между bulk-logged и full и отличается только на минимально протоколируемые операции, т.е. массовую вставку в тех или иных проявлениях. Если у вас не ETL-база и не источник для отчетности, то никакой разницы на обычных операциях не будет, хотя может быть разница на регулярных обслуживаниях: alter index rebuild может быть минимально протоколируемой.

Про TSQL. С одной стороны всё так: и не найти приличных, и в вашем репозитории видно старание, аккуратность и объём проделанной работы, но… Но нельзя просто так взять и написать парсер SQL :)
15 минут посмотрел на лексер и уже вижу не менее 5 ошибок:


Спрятал тут
  1. Идентификаторы с "[]". Закрывающая скобка может быть частью идентификатора


    select 42 as [Look here []]]

    Вывод


    Look here []
    ------------
    42

  2. Числа:


    select 1e -- у вас это не число
    select 1e- -- у вас это не число

  3. Пустое место. Неразрывный пробел MS SQL воспринимает как пробел. Стоит отметить, что есть и дргие "пробелы"
    declare @sql nvarchar(max)
    set @sql = N'select 1' + char(160) + N'a'
    print @sql
    exec (@sql)
  4. BINARY BASE64 воспринимается как одна лексема. Конкретный сценарий неправильного парсинга надо подбирать, но, как минимум, несколько пробелов там допустимы.
  5. Комментарии. У вас `'/' .? '*/', а на самом деле возможны вложенные комментарии.
    /* SELECT 'Hello' /* */ SELECT 'Protected by PT' --*/ SELECT 'Executed by someone'

    Ваш лексер будет думать, что выведется 'Protected by PT', а на самом деле 'Executed by someone'. И эти люди защищают нас от инъекций??? Простите, не удержался :)



Это правда не более 15 минут просто посмотрев в лексер (комментарий дольше писал). В парсер даже не вчитывался. Я даже не знаю о чем это говорит (выбирайте сами):


  • Парсеры без ошибок писать сложно. Чертовски сложно даже для тех, кто, наверное, должен уметь писать безопасные парсеры.
  • Язык TSQL — ад для перфекционистов-парсерописателей.
  • Open-Source рулит, потому что в закрытом коде эти проблемы просто бы скрылись.
  • Я зануда и у меня просто глаз набит (да, я видел очень немного грамматик/парсеров, в которых бы я не находил ошибок).

PS: Правки достаточно простые, я попробую найти время на выходных для PR в github, но не обещаю.

Тут нет противоречия. Если ты выигрываешь гостендер на условный миллиард, то скрыть по-тихому выручку не получится. А вот скрыть структуру затрат — придётся обязательно.

Я правильно понял, что вы признаете, что государство крупнейший заказчик ПО в России, но приводите ряд дополнительных причин?

Конечно, я согласен с тем, что в проанализированных CNews ИТ-компаниях, государство — важнейший и крупнейший по выручке заказчик, да. Но вы сразу делаете два вывода, с которыми я не согласен:


  • Это означает, что четверть разработчиков в стране работает над государственными заказами. — не означает. Почему — поясню ниже в ответе по диверсификации выручки.
  • Это также означает, что бизнес в России или без средств для инвестирования в IT или ещё не увидел ценность инвестиций в IT. — нет. Бизнес видит ценность ИТ-инвестиций уже лет 20. И средства есть (не бездонная бочка, но есть). И инвестирует, но, например на рубль затрат получает существенно больше, чем государство и не тратит больше, чем может прожевать.

Приведите ссылки на исследования с цифрами (диверсификация выручки)

Вы приводите цитаты из отчета "CNews100 крупнейших ИТ-компаний России" так, как будто этот отчет целиком по компаниям ИТ-разработчикам, например, цитата "На долю топ-20 приходится 77,9% совокупной выручки". Это не так, и даже в самом обзоре делается различите между всеми ИТ-компаниями и ИТ-разработчиками: Также в рамках обзора «Рынок ИТ: итоги 2016» подготовлены рейтинги «CNewsFast: Самые быстрорастущие ИТ-компании 2016», «Самые эффективные компании CNews100 2016» и «Крупнейшие ИТ-разработчики России 2016». Вот ссылки: CNews100: Крупнейшие ИТ-компании России 2016 и CNews Analytics: Крупнейшие ИТ-разработчики России 2016
Даже бегло посмотрев видно, что выручка ИТ-разработчиков — где-то 20-25% от выручки ИТ Топ-100. И распределение данных в этих таблицах несколько различается. В общем отчете CNews есть колонки "Штатная численность" и "Выработка на человека" и для ИТ-разработчиков в среднем этот показатель заметно ниже, чем для условных "продавцов-железячников", причем явно "в плюс" выделяются разработчики ПО, пользующиеся спросом на западе (ЛК, например).
Примерно те же выводы про структуру выручки в приведенной вами ссылке на исследование РУССОФТ, страница 22. Всякие IDC, TAdviser, RAEX тоже учитывают это деление. Все оценивают долю разработки в 15-30% (разные методики, разное разнесение).
Соответственно, "четверть выручки ИТ-компаний" уже может не соответствовать "четверть разработчиков в стране". Более того, учитывая "неэффективность донесения" стоимости контрактов до зарплат разработчиков в ИТ-проектах, скорее всего госзаказ именно в разработке ПО существеннен, но не главный фактор. Гораздо большее влияние, наверное, оказывают банки. Посмотрите, из Топ-40 ИТ-разработчиков Epam, Luxoft, Ай-Теко и другие — аутсорс для банков; Центр Финансовых Технологий, Банковские информационные системы (БИС) — продукты для банков, Сбербанк Технологии — часть банка. А ведь есть еще и внутреняя разработка банков. ВТБ, Альфа, Открытие, Райфайзен, Deutsche Bank, Тинькофф и прочие — во всех в них есть сильные ИТ-коллективы.


бюджет только ФОТ может быть побольше, чем 600 млн руб
Приведите какие-то ссылки или исследования, которые показывают цифры.

Ну, например, Альфа-банк только потому что быстрее всего было найти. 1500-1600 человек и планировали расширяться. Надо ли доказывать, что только ФОТ тут миллиардами меряется? Да, Альфа — крупный банк, но в банках поменьше тоже ИТ-подразделения крупные.


Что значит «надерганных»? В чем суть проблемы и как мне сделать следующую статью лучше? Надеюсь суть этой фразы не в вашей личной оценке, а за этим стоит предложение по улучшению.

Зря вы решили, что мне статья не понравилась. Статья — отличный набор ссылок. То, что в ней есть некоторое количество советов, которые я считаю хайпово-вредными и ошибочными — нормально. Я не смогу идти по всей статье, она большая, но в целом, например, удивило, что статья вроде бы для не-ИТ менеджеров, а в ней попытки раскрыть тему выбора языка программирования. Если "универсальный менеджер", то сконцентрируйся на поиске общего языка с ИТ и организацией работы, а не с выбором технологий. А если ИТ-менеджер, то этот кусок выглядит весьма наивно.
С другой стороны, для не-ИТ руководителей я бы упомянул ITIL/ITSM, как способ обеспечить прозрачность и управляемость ИТ-инфраструктуры, а для ИТ-руководителей можно посоветовать, например, "Чего хочет бизнес от IT" Терри Уайта. В практическом смысле для среднего руководителя это, наверное, полезнее сомнительной (для менеджеров) информации про микросервисы.
"Винегрет" тут скорее про то, что статья одновременно и про ML, и про Agile, и про микротаргетирование, и про микросервисы, и про выбор ЯП, и про "uber-экономику".

Всё сложнее.
Весь "анализ рынка" на самом деле смесь кучи систематических ошибок (анализировалось то, что легко анализировать, а не реальность).


Государство стало крупнейшим заказчиком из-за нескольких факторов. Тут и то, что, действительно, улучшать IT государства можно почти бесконечно, и то, что автоматизируются неэффективные процессы с минимальным пересмотром, и то, что процесс создания ПО менее прозрачный, чем закупки товаров (банально "намыть" можно больше). Тут же и сомнительная эффективность этих расходов (покупая, например, Enterprise лицензии MS SQL там, где можно обойтись Standard тратится ~$3к лишних на каждое ядро процессора).


С другой стороны, те, у кого заказчик — государство или госпредприятие, уже никуда от публичности отчетности не денутся. А те, у кого есть возможность не светить масштабы тем или иным способом — не светят. Пример: по информации от CEO JetBrains М. Шафирова выручка JetBrains в 2014 году была больше $110M. И вроде с тех пор должна быть только больше. Основное производство ПО у них в России, но компания не российская, в рейтингах ее справедливо нет.


В крупных интеграторах выручка имеет неоднородную структуру. Это и поставки техники, и поставки чужих лицензий ПО (MS, Oracle и др), и поставки своих лицензий, хостинг, обслуживание, разработка на заказ и еще куча всего. Норма прибыли в каждом случае своя и доля зарплат сотрудников в затратах сильно отличается.
У дочек крупных предприятий (они есть в списке) выручка — понятие достаточно синтетическое. По крайней мере к "рынку" это не относится. С другой стороны в этом анализе совсем-совсем не участвуют ИТ-подразделения крупных не-ИТ компаний, у которых бюджет только ФОТ может быть побольше, чем 600 млн руб ("входной билет в top CNews").


Из-за этих систематических ошибок делаются спорные выводы "с этими компаниями вы будете конкурировать за разработчиков" и "что бизнес в России или без средств для инвестирования в IT или ещё не увидел ценность инвестиций".
Если говорить про конкуренцию за разработчиков, то рынок разработчиков неоднороден, причем делится не только по стекам инструментов, но и по квалификации. Если вам надо сделать большую систему, то нужны как "безупречные", так и те "у кого есть возможности для развития", причем конкуренты будут сильно разными. С точки зрения сильных специалистов, например, интересны события ухода из РФ rnd Intel и Oracle, но не надейтесь, все ценные, кто хотел остаться и остались, стоят вполне международных денег.


После скачка курса 2014-2015 года сложилась глупая ситуация:


  • сильные специалисты массово ушли от российских заказчиков (часть физически, часть работают здесь "на них")
  • сильные специалисты почти не подешевели в $
  • слабые специалисты, глядя на это, поучили стимул к развитию, кто мог — стал сильным (и см. выше), а кто не мог… тоже стал получать больше
  • ах, да, денег у отечественных заказчиков в целом сильно больше в рублях не стало.

Такое положение дел выгодно для местных заказчиков и работодателей

Выгодно лишь части заказчиков. Те, кому нужны специалисты в тупике: денег нет и кадров на рынке нет.


Российские IT-продукты и услуги не востребованы на мировом рынке

Они востребованы, когда они есть. ЛК, Acronis — в топе CNews. Есть очень нишевые продукты, но если они становятся интересными, то владельцам проще перестать быть российскими по ряду причин. Длинному ряду.


Статья на самом деле — винегрет надёрганных модных терминов и концепций, правильных и неправильных, полезных и вредных советов. Но я прочитал с интересом: понятно, что творится в головах менеджеров.

Статья читается тяжеловато, в ней излишне упрощено всё что можно и нельзя и вместе с упрощением выкинут смысл бухучета. Эти же упрощения приводят к явно неправильным аналогиям.


Примерно так:


  1. Аналогия "активные — распоряжаемся, пассивные — не можем распоряжаться" не отражает сути. Например смотрим на амортизацию: в РСБУ и МСФО это же пассивный счет, а "распоряжаться" мы им можем. А вот каким нибудь счетом "Общепроизводственные расходы" (который активный) мы вряд ли можем распорядиться.
  2. А почему пришлось вводить эту аналогию? А потому что цели и принципы бухучета выкинули. Зачем мы вообще считаем эти "счета" и "проводки"? Чтобы бухгалетру было чем заняться? "Понимать общую картину финансов" это и звучит неопределённо и, если уж честно, то бухучет часто скрывает ключевые показатели "общей картины". И, да, упомянутые забалансовые счета, как раз один из компромиссов можду "учесть" и "не укладывается в модель". Потому что там есть например что-нибудь типа "товары на реализации", которые как бы и не наши, но если мы их потеряем, то платить придётся.
    В современном мире у бухучета дофига смысловой нагрузки, конечно, это и "стандартный язык" и учет всякой ереси и фискальные учеты, но, насколько я понимаю, главная цель бухучета — посчитать финрез и объяснить из чего он сложился. Мы заработали или угорели? Нам вообще есть из чего дивиденды платить? А из чего складывается финрез?
  3. Но чтобы учет был учетом, а не фантазией фаундера стартапа, нужны принципы.
    • Непрерывность (мы не можем пропустить годик и сделать вид что всё ОК, остатки на конец года и на начало следующего — равны),
    • объективность (все записи должны подтверждаться бумажкой),
    • своевременность (его назвают принцип "начисления", если сделка заключена в январе, то и проводки в январе),
    • единая "единица измерения" — деньги, причем в одной валюте. На самом деле принципов больше, но я их не помню :)
  4. Ага, у нас есть цели и принципы-правила. А вот теперь из принципов-правил мы приходим к инструментам. Из того, что мы считаем "финрез" мы получаем формулу ФинРез=Наше-НеНаше, или если перенести, то Наше=НеНаше+Финрез. А теперь Наше назовём активы, а НеНаше+Финрез — пассивы. Осталось ввести правило двойной записи, т.е. у нас проводки могут быть только такие что меняется одинаково пассив и актив, либо внутри пассива и актива "переносится". Осталось назвать "плюс" по активам "Дебетом", по пассивам "Кредитом" (и наоборот).
  5. А дальше надо построить систему счетов и допустимых проводок, которые будут строить наш учет. Тут уже придётся продумать, как сделать такие счета, чтобы учитывать, например, оборудование, которое куплено явно не на один год так, чтобы одновременно знать сколько оно стоило, сколько оно стоит, и если считать, что затраты на это оборудование должны "отбиться" за 5 лет, то насколько эти затраты уже "отбились". Здесь, кстати, если аккуратно разбирать вопрос, то становится абсолютно понятно, что амортизация и срок службы оборудования вещи вообще говоря слабо связанные. Аналогично надо придумать схему проводок и счетов для отражения, например, товара на складе и проводок при его покупке (чтобы отразить финрез). А чтобы бухучет одной организации можно было сравнить с другим, появились стандарты учета (РСБУ, МСФО, GAAP), которые состоят как из "паттернов", так и из конкретных требований по использованию "паттернов".

Дальше. Два счета в проводке — это конечно хорошо, но почему "три счета слишком затруднит контроль правильности"? Да хоть 8, если в сумме по дебету и кредиту одинаково. Это весьма синтетическое ограничение, которое может быть полезно (например, появляется возможность оперировать показателем "обороты между счетами"), а может быть очень неудобно. И в этом же месте можно ввести название: часть проводки по одному счету по одной "стороне" (дебет или кредит) с суммой — корреспонденция или в крайнем случае "полупроводка".
Вообще есть нюанс, что принцип двойной записи, как ни странно, в бумажном виде это скорее три записи, чем две ("главная книга" и суммы в дебет и в кредит), а "двойная" скорее относится к тому, что у проводки есть 2 стороны. В компьютерном мире, конечно, записей может быть как одна, так и много.


Проводки одного документа должны находиться в одной транзакции СУБД — почему? Про одну проводку вопросов нет — она должна быть в одной транзакции. Причем в большинстве систем проводка это относительно сложная сущность которая отражается в несколько таблиц. А почему все проводки документа должны (вот так вот безаппеляционно) быть в одной транзакции СУБД? А как быть если в накладной 20 слонов, а у нас вместо пары слонов жирафы у забора дерево обгладывают или еще что-то подобное? Ситуаций в учете много и вот так железобетонно говорить вешать учетные принципы на некие "транзакции СУБД" неправильно.


Самое смешное, что всё это разжёвано и пережёвано в куче книг, статей и курсов. На книжку по основам бухучета у среднего программиста, который (для примера) разобрался, как внутри работает git или даже может написать неблокирующий стек и может вспомнить все паттерны GoF, уйдет 2-4 часа, если не начинать укуриваться деталями. За столько же времени на пальцах и с коньяком объяснит суть учета хороший замглавбух (главбух слишком усложнит, рядовой не объяснит).

Озадачился, что за протокол такой *«предоставив организаторам доступ к нему по SSH3»*. Разобрался, оказывается «3» — это сноска в положении о конкурсе :)
Если очередь выше 1, то значит в ней кто-то ждёт завершения предыдущей операции. Если эти операции записи в mdf, то пусть будут. Если они на чтение, то, как и написано в вашей статье, задержки будут расти линейно. От количества шпинделей это никак не зависит (это странная байка откуда-то из 90-х или раньше, сам я это году в 97-98 читал, применительно в NT4 встроенным RAID).
Но. Если это write-ahead запись в LDF, то очередь 1 — это значит, что вы полностью упёрлись в производительность диска. Потому что тут: SQL кинул запись в журнал транзакций (очередь стала 1), подождал, получил ответ от ОС «я кончила» (очередь стала 0) и тут же кинул новую запись в журнал.
Так что если очередь 1, то уже нужно убедиться, что это не связано с однопоточным синхронным сценарием IO.
О! Спасибо за прекрасный комментарий по существу. Этот комментарий, кажется, в несколько раз информативнее и лучше статьи :) Спасибо, что поделились опытом.
На самом деле описанные решения разумные и обоснованные и абстрактную средненькую БД хостить с таким подходом не страшно. Только max server memory какой-то странный, но, я думаю, это опечатка и это параметр для RAM в ГБ указанного в поле количество CPU: странно выделять 29 ГБ из 512 на СУБД.

Позволю себе не согласиться с "рекомендуемые нами настройки" и "В статье мы рассказали". Я, собственно, и удивлён, что в статье нет почти ни одной рекомендации о конкретных настройках. Сплошные "надо настроить параметр такой-то", а как его настраивать — не скажем. По ссылкам тоже в основном "чтобы настроить параметр X выполните команду ALTER X Y, где Y новое значение".
В интернете полно рекомендаций, как настраивать standalone БД. Есть получше, есть похуже, но полно. Не надо делать еще одну статью об этом (или надо, но не этого уровня).


Вы назвали статью "Как обеспечить производительность баз данных Microsoft SQL Server, размещаемых в облаке". Я прочитал вкратце на вашем сайте, что вы под этим имеете в виду (а это не так однозначно): под облачной БД вы подразумеваете ВМ с развернутыми службами MS SQL Server на котором развернута БД (например так описано тут) и фактически вы являетесь администраторами/DBA для этой ВМ. То есть сразу видно, что вопросы взаимного влияния баз решаются не внутри инстанса SQL Server, а разведением ВМ. Не самая худшая стратегия, хотя большинство гипервизоров достаточно уныло разделяют IO нагрузку. Но вопрос остаётся актуальным "Как обеспечить производительность баз данных Microsoft SQL Server, размещаемых в облаке"?
Как настроить обычную БД понятно, а какие отличия в настройках виртуализованных больших ферм с БД?
Как вы делите диски (с учетом того, что они вирутальные)?
Используете ли thin pools/LUNs и т.п.? Если да, то как боретесь с latency LDF, сколько она сейчас у вас в миллисекундах? Если нет, то как вы управляетесь с сотнями LUN хитро разбитыми по задачам и как обеспечиваете отсутствие взаимного влияния инстансов ВМ? Какие носители для какой нагрузки используете?
Как и где хрянятся бэкапы, как обеспечиваете RPO/RTO без влияния на производительность?
Как с вашими планами обслуживания (перестроение индексов, DBCC CHECKs) вы обеспечиваете 99,95% (это 4 часа недоступности в год). Или вы считаете, что если инстанс пингуется, но таблица в 100 ГБ ребилдит индексы не online, то это тоже доступность?
Как обеспечиваете HADR с точки зрения производительности? Это совсем не просто. Что в ваших терминах значат "Отказоустойчивая база данных", "База данных повышенной доступности", "Кластерное решение"?
Используете ли Lock pages in memory (если да, то страдает гипервизор, если нет, то страдает БД)?
У вас не так много видов ВМ, всего 5 (по vCPU/vRAM) — какая стандартная настройка предела памяти для каждого вида и сколько файлов tempdb, какой MaxDOP по каждому варианту? Такая табличка будет ценнее всей статьи.


Я не зря ссылку на h14621 кидал в комментарии. Мне очень нравятся технические white-papers от EMC именно как образец того, что нужно учесть при планировании БД. Кроме общего у них еще куча white-papers "частных случаев" есть, мне лень искать более подходящий, но там прям кладезь знаний. Есть ли у вас что-то что можно добавить хотя бы к этому документу? Если есть — это очень интересно и важно. Пусть это и будет не "быстро и коротко", а "глубоко по одному аспекту".

Вопросы к вашим пунктам.


  1. Чем в вашем контексте отличается процесс настройки и сами настройки "обычной" БД от "облачной"? Из статьи не видно.
  2. О выборе оптимальных параметров использования памяти MS SQL Server можно прочитать здесь. — там почти только о том как настроить, но не какое значение выбрать.
  3. О выборе оптимальных параметров MaxDOP можно прочитать здесь. — там почти только о том как настроить, но не какое значение выбрать. Не засвечена связанная настройка cost threshold for parallelism.
  4. trace flags: Так какие и почему флаги используете? Просто кинуть "а вон, ищи среди пары сотен нужные" это как-то даже некультурно для статьи.
  5. tempdb: Почему вы приводите ссылку на "пенсионерские" рекомендации для SQL Server 2008 R2? Её ж скоро уже с поддержки снимут. И эти рекомендации не работают при 64+ процессорах (а это уже двухсокетник AMD Epyc). Вообще по всей статье сплошные отсылки к рекомендациям 10+ лет.
  6. Как вы боретесь с узкими местами в tempdb? Если у вас 50-60 клиентов начнут её активно использовать явно или неявно (udf или неудачный план могут очень неявно её грузить), что нельзя запретить, то именно tempdb обычно становится главным узким местом.
  7. "Корректно настраиваем параметры дефолтных расположений дата-файлов/лог-файлов" — так какие параметры корректные и почему?
  8. Disk Partition Alignment — Эмм… Вы сами-то смотрели, когда это в последний раз было актуально, и какая версия windows стала сама нормально форматировать?
  9. 64 КБ кластер всегда и для всех? Хм. Это требует обоснования.
  10. Вообще по настройкам дисковой подсистемы очень неплохо начать с Microsoft SQL Server Best Practices And Design Guidelines For EMC Storage — даже если у вас не EMC. Просто чтобы понять что настраивать и в какую сторону дальше читать. Если бы все админы СХД перед тем как общаться с DBA читали это, то это бы сэкономило пару ГЭС электроэнергии и миллиардов долларов.
  11. Настраиваем "Мгновенную инициализацию файлов базы данных" — что вы делаете, чтобы она не включилась?
  12. RCSI — как вы боретесь с тем, что RCSI потенциально делает tempdb сервера узким местом?
  13. Page Verify — еще одна рекомендация прошлого века. Если БД создавалась не 20 лет назад, то она будет CHECKSUM. А если и Torn pages, то клиент сам себе злобный буратин в случае поломки. По "Page Verify", Auto Shrink, Auto Close, Auto Create Statistics и Auto Update Statistics вам проще было сразу в статью запрос написать. Ну или вообще отправить к Бренту Озару или даже сразу сюда
  14. "Дата-файл/ы и лог-файл БД размещаем на отдельных физических дисках". Там тема не столько про распараллеливание, сколько про то, что журнал транзакций это критичная по скорости write-ahead последовательная запись на диск и любая другая дисковая активность превращает её из последовательной в произвольную с увеличением latency примерно на порядок на дисках. На SSD это не всегда так (см выше статеечку от EMC), но пока потенциальный выигрыш от этого пока, наверное, выше, чем затраты на управление.
  15. "Выбираем корректные начальные размеры дата-файла/ов и лог-файла БД", "Выбираем корректные параметры “Авто-роста” для дата-файла/ов и лог-файла БД" — а какие именно настройки корректные для облачных БД и почему?
  16. "Выполняем проверку целостности данных БД" — как вы это делаете для облачной БД? Как выбираете окно и как делаете, что это не влияет на остальные БД?
  17. "Выполняем кастомный index rebuild/reorganize в зависимости от фрагментации индексов" — каким инструментом? Чем это отличается от скриптов Ola Hallengren ?
  18. "Обновляем статистику". Неудачное объяснение. Статистику приходится обновлять явно в первую очередь для того, чтобы не попасть на обновление статистики в "горячее время", во вторую, чтобы обновлённая статистика дала потенциально лучший план запроса. Но если вы обслуживаете индексы, если у вас есть autoupdate statistics и отдельные БД не высоконагруженные (а ваши настройки в целом не высоконагруженные БД), то что вы обновляете, зачем и в каком режиме?
  19. Про "очистку БД от “старых” данных" у меня 2 вопроса. Первый — это что вы в данные клиента вот так лезете прям в рамках облачного администрирования? Второй — а почему не писать запросы так, чтобы данные можно было и за 10 лет хранить? Не сваливайтесь в сканы и делов-то.
  20. Резервное копирование: Как вы уходите от деградации произвдительности во время резервного копирования? Какую модель реально и почему используете? Как в эту модель ложатся RPO/RTO? Как обеспечивается хранение копий (хотя бы в скольки экземплярах и где)? И, да, как написано в этой статье
    Резервное копирование — это последний рубеж обеспечения сохранности системы. Если администратору базы данных приходится восстанавливать продуктовую систему из резервных копий, значит, с большой вероятностью было допущено множество грубых ошибок.
  21. Выполняем регулярное тестовое восстановление бэкапов БД. Ок. И как вы планируете реагировать, если резервная копия битая?
  22. Почему в одной статье вы одновременно используете и Database mirroring и AlwaysOn AAG? Как вы между ними выбор делаете?
  23. Как вы используете Log shipping в облачной БД? Вы что клиенту прямо файловые ресурсы отдаёте?
  24. Кластеры — как используете? Есть ли дизастероустойчивость (если ЦОД дохнет весь), обеспечивается ли при этом RPO/RTO и какие? Если такие кластера есть, то как живете с задержками журналов между ЦОДами и какие они у вас в абсолютных цифрах.
  25. Осуществляем постоянный мониторинг состояния сервера. Всё тот же вопрос. Какие именно показатели, какие именно счетчики собираете и как трактуете? Особенно в ситуации "много потребителей, много ресурсов".

В статье не отражено:


  1. Проверка настроек или настройки безопасности. Банально: xp_cmdshell запрещен, OLE запрещен, CLR запрещен? Логины AD или SQL (в обоих случаях еще куча вопросов)?
  2. Используете ли именованные экземпляры? Как делаете чтобы они не влияли друг на друга? Настраиваете ли у них affinity или еще как? Доступен ли сервису Lock pages in memory и почему (есть и за и против).
  3. Используете ли штатный Resource Governor? С какими настройками? Как вообще клиентов по нагрузке разводите? Особенно в динамике, и по дискам и по памяти и по блокировкам/латчам?
  4. Если испольуете "свежие" версии SQL, то как быть с БД старых уровней совместимости?
  5. Безопасность в смысле "чтобы клиенты друг друга не видели" — как обеспечить?
  6. SSAS, SSRS предоставляете? Как рулите?
  7. Как у вас реально HADR сделан на 99,95%?
  8. Какие инструменты есть у клиента, чтобы диагностировать нагрузку? Может ли он хотя бы посмотреть "кто сейчас к моей БД подключен"? И как вы ему это дали не давая View server state? Какие dmv он может смотреть, а какие фигушки?
  9. Какой опыт настроек позаимствовали от Azure, а в чем отличаетесь и почему надо идти к вам, а не в Azure?
  10. Настраиваете ли вы Delayed Transaction Durability горячим промежуточным БД?
  11. Есть ли политика хранения BLOBов в БД? Даёте ли FileStream на них? Как живёте с этим?

Я выдохся. Вопросы еще есть, а статья ни о чем.

Вопросы к авторам:


Следующим из семейства процессоров шестьюдесятью восемью стал 486-ой, появившийся в 1989 году.

Что имелось в виду? Что есть 68?


Шина данных была 8-разрядной, что позволяло адресовать 16 Кб памяти.

Что позволяло? Почему именно 16? У меня арифметика не сходится. [отгадка шина адреса 12 бит с мультиплексированием]


В те годы ещё поддерживалась обратная совместимость процессоров, что ничуть не мешало вводить различные новшества и дополнительные возможности.

О какой совместимости речь? По ногам — вроде никогда не было, а по коду и поныне.
Про "настоящую 32-битность" выше уже сказали (я согласен), что выбор именно XP для границы весьма произволен.


Он [на картинке 80486-DX33] содержал уже 1,2 миллиона транзисторов и первый встроенный сопроцессор, а также работал в 50 раз быстрее процессора 4004; его производительность была эквивалентна производительности мощных мэйнфреймов.

Мэйнфреймы какого года имеются в виду? И про 50 раз — тоже как-то спорно. Это просто одну частоту на другую поделили? Так точно нельзя делать: у них сильно разная производительность на такт и разная ширина регистров.


25 мая 2005 года были впервые продемонстрированы процессоры Intel Pentium D. О них особо сказать нечего, разве что только о тепловыделении в 130 Вт.

Почему нечего? А то что он был первым настольным двухъядерником x64 от Intel?


До сих пор некоторые операционные системы называют их AMD64

Некоторые — это MS Windows и Linux? :)


Так же существуют «Монстры» этого поколения (Haswell-E): i7-5960X Extreme Edition, i7-5930K и 5820К, адаптированные под десктопный рынок серверные решения. Это были самые напичканные по самое не балуй процессоры на тот момент. Они базируются на новом 2011 v3 сокете и стоят кучу денег, но и производительность у них исключительная, что не мудрено, ведь у старшего процессора в линейке целых 16 потоков и 20 Мб кэша.

У старшего из десктопных Haswell-E 8 ядер. У серверных 2011v3 Haswell — больше.


Еще по мелочи:


  1. Примерно треть статьи про AMD. Не, ну понятно, что без упоминания AMD не обойтись, но можно было меру знать в статье про Intel.
  2. Выкинули i860/i960 (и i432). Это было не самое удачное коммерчески, но таки важное направление.
  3. Выкинули Itanium. Да, не взлетел. Да, нишевый и дорогой. Да, вытеснен Xeon. Но по времени жизни он (как платформа) далеко переплёвывает какие-нибудь "мимолётные" Pentium 4.
  4. Выкинули почти всю историю мобильных и маломощных процессоров (слово Atom в статье не встречается!)
  5. Выкинули эпичнейшую историю про Rambus и RDRAM. Без этого контекста совершенно по-другому выглядит развитие Intel в периоде примерно 1998-2004.
  6. Выкинули, как был съеден DEC Alpha. А ведь победа на Intel над Alpha это один из главных шагов завоевания суперкомпьютерных рынков.
  7. Нет Xeon Phi.

Поддержу предыдущих комментаторов, что примерно первая треть статьи сильно лучше.

Даже на EMCшном допотопном CLARiiON CX4-CX4 всё будет норм. Как и на не-помню-чём Hitachi с тремя layer и межцодовой репликацией. Как и на большинстве встроенных контроллеров, да чего уж там, 12 ТБ это по нынешним меркам вообще тупо зеркало :)
Эм… На бэкенде «интерпретируемые языки, а еще и без типизации» чуть ли не царствуют. Весь bash/shell/cmd такой. На них не пишут бизнес-логику? Ок, тогда SQL — он тоже по факту скорее интерпретирумый, с типизацией у него «всё сложно». Кстати большинство движков SQL однопоточные (внутри запроса параллельность может быть, но следующий запрос начнется только после окончания предыдущего). Если про веб, то PHP по меркам индустрии джититься стал чуть ли не вчера. ABAP, не к ночи будет помянут, тоже, хм, элегантен, как паравоз.
А ведь это языки на которых самое мясо бизнеса зачастую крутится. Тут скорее «Golang или Rust» пока в роли белых ворон.

[Я сторонник типизированных языков, если что]
Хм… извиняюсь, да, невнимателен был. Это не trial division, но и решетом Эратосфена это сложно назвать.

Но к памяти всё равно много вопросов.
В этом варианте на каждое простое используется пара простого и границы интервала. Размер такой структуры, конечно, зависит от реализации, но это никак не может быть меньше двух целых чисел. Если у вас целые всего 32 бита, то это 64 бита. Для того, чтобы это было выгодным по сравнению с BitSet (или подобной структурой), надо чтобы в среднем между простыми было 64 составных. А в целых этого диапазона примерно каждое 20-е простое.

С 1000-битными на самом деле для вашей модели не лучше. Количество требуемых бит для числа растет быстрее, чем средний интервал между простыми примерно в 1/ln(2) раз. Так что идея интересная, но не работает.

Ну и да, строить решето Эратосфена для 1000-битных чисел — нашей вселенной не хватит (ни места ни времени).
Если надо искать 1000-битные простые числа не в теории, а на практике, то в Java всё уже до нас придумано и почти всё сделано. У класса BigInteger есть метод probablePrime, а его уже можно проверить каким-либо из подходящих под задачу primality tests (в BigInteger только вероятностный, так что, увы — придётся писать).

Information

Rating
2,818-th
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity