На самом деле это уже частности. Главная идея в том, что задержка на LUN (или другое вендор-зависимое название) с 100% последовательной записи на порядок меньше, чем когда есть случайные чтения и записи в тот же LUN. Как конкретно железяка подключена, как эта железяка делает быструю запись мне не настолько важно (пока есть доверие, что записано значит может быть прочитано).
Да, СХД типа VNC или VMax это больше, сложнее и дороже, чем рейд-контроллер. Но по большому счету в этой разнице latency «виновата» не СХД, а ОС, которая для одного «физического» с её точки зрения будет держать одну очередь.
Если WAL лежит отдельно, то есть много вариантов, как хранилищу отчитаться в ОС, что всё сделано. Многие СХД и RAID-контроллеры отвечают, что «всё записано», когда реально данные только попали в память «с батарейкой». 100% записи, последовательной. Там гора вариантов.
Если вы нагрузку WAL бросите в общий котёл, то ничего этого не получите. Там полно в очереди таких, которым «только справочку получить».
Ну и с чего ей меняться, если диаметр диска не меняется, и скорость звука тоже?
Например, с того, что сейчас почти везде используются SSD. Впрочем, 10 лет назад разделение по дискам имело более критичное значение.
Это для любого SQL-сервера?
Я не знаю другого продукта на рынке, который называется именно "SQL Server" кроме произведенного Microsoft. Но, согласен, лучше было уточнить.
… Вообще говоря, перестановки возможны…
… выравнивать записи…
… свободно раскидываются по дискам...
Наверное, возможно многое. Но сейчас write-ahead logging является одним из основных ограничений производительности. И эта бодяга тянется как минимум с 1992 года.
А если разделить журнал на несколько дисков?
Иногда приходится, но очень-очень редко нужно больше двух параллельных дисков (точнее 4 потому что обычно это RAID10). Что нужно сделать чтобы узким местом стал отдельный SSD для WAL я даже не представляю.
Это не страшно, если транзакции будут накапливаться в очереди и записываться на диск одним большим блоком (одной большой операцией записи).
Страшно. Реально страшно. Вы собираетесь ответить пользователю, что транзакция зафиксирована, а на самом деле нет. При сбое вы потом целостность не соберете.
А почему не Bash?
Поздравляю, вы нашли пасхалку :) Именно PowerShell написано осознанно. Администрировать linux, не зная bash — невозможно. А называться администратором Windows не зная PowerShell — сложно, но возможно.
Никому. Серьёзно. У EMC цифры "что такое хорошо" меняются год от года. Сколько могут прямо щас — столько и Excellent. Вот в H12341 (октябрь 2013) и H14621 (декабрь 2015):
Судя по тому что цифры в них одинаковые, эта табличка не менялась уже пять лет.
В другом документе цифры меньше, но он тоже 2013 года.
И за эти 5 лет как раз почти всюду в high load стали использоваться All flash SSD решения. Тут надо не верить, а смотреть на конкретную СХД и выжимать из неё производительность. 1 мс было отлично 5 лет назад, но это не значит, что сейчас нельзя достигнуть большего.
Я и согласен и нет. Про ортогональность: хотя буква C в CAP (consistency, availability, partition tolerance) и означает совсем не то, что C в ACID, но эти темы не ортогональны. C в CAP по значению почти эквивалент значению буквы D из ACID. Так, что вы в целом правы, что «не мешает», но вот с «ортогональны» я не соглашусь.
А вообще, все СУБД (и распределённые и нет) достаточно «творчески» подходят к ACID, нераспределенные особенно к I — isolation (любые уровни изоляции отличные от SERIALIZABLE нарушают изоляцию), распределенные к C и D (плюс там хитрый вопрос что такое раньше/позже).
2PL работает совсем на другом уровне. Плюс тут же вопрос даже не в коммите. Коммит — это просто записать в журнал, что транзакция с таким-то LSN закоммичена. В WAL пишется всё подряд и однопоточно. И реализовать запись корректной последовательной цепочки всех изменений с достаточной надёжностью и хитрой обработкой параллельность пока ни в одной СУБД, видимо, не смогли.
В том же MS SQL небольшой кэш для транзакций есть (см тут), но он для другого случая, когда транзакция записывает много данных.
В любом случае статья не о том, как "можно было бы сделать СУБД", а о том "как те СУБД которые есть заставить работать". При нормальном разбиении дисков 5к-20к TPS выжать на продакшн вполне можно. С оговорками про конкретную задачу и бюджет.
Я не знаю даже теоретического разумного решения, как определить, что транзакции независимы. То, что сейчас у них записи в разные таблицы — не показатель. Наверное, теоретически можно прикрутить какую-то эвристику, но сейчас ни в одной СУБД этого нет. Гораздо чаще, как в упомянутом Delayed Transaction Durability, идеальное соблюдение принципа приносится в жертву производительности.
например, лид написал код за полдня, а жуниору понадобится несколько недель, чтобы понять, какую задачу решает этот код
В 90% случаев это значит, что лида надо увольнять или переводить в менеджеры (если есть задатки или принцип Питера давит). В 10% — что должен был ревьюить миддл.
Если ведущий специалист пишет код, который никто не понимает, то куда же он ведет продукт? Мне в командах нужны лиды, которые могут сделать всякие ответственные штуки, например, самая ответственная — публичный API или общая схема взаимодействия блоков. Такой хороший код не сложен для понимания, а прост. Сложный код — не гордость опытного разработчика, а позор или признание какой-то слабости.
Для большинства бизнес-приложений это так. Есть исключения: одноразовый код, иногда high-concurrency, всякие интринсики или асм-вставки, код для экзотических железяк, всякая криптография и суровая математика. Ну да, есть иногда куски для объяснения которых нужен опыт выше джуна. Каждый такой кусок — повод задуматься "а не фигню ли мы делаем".
Битность хранения тут почти ни при чём. Вы задали явно и неявно слишком много ограничений, которые не могут быть выполнен вместе.
Датчик «считающий фотоны» (но всё равно через электроны) создать возможно, но он будет большой, требовать охлаждения и не сможет работать на частоте «прилетания фотонов» в видимом свете.
Может показаться, что в крупную ИБ-компанию очень сложно попасть...
Ха! Да что там устроиться, мне было сложно даже найти в интервью имя сотрудника, который отвечал на вопросы (имя и фамилия только перед описанием задач, имя ещё в одной реплике в середине). Труъ разведчики :)
Не, спасибо за попытку помочь, но это панели кнопок. А я про сам список закладок и вкладок. У меня монитор 2560*1440 и мне просто не нужно сайты шириной все 2560. В новом FF, насколько я понял объяснение разработчиков плагинов, возможна только одна такая панель (переключается между задачами: можно либо вкладки, либо история, либо закладки и т.п.)
Допустим, мы хотим открыть курс «Программист Kotlin». Первым делом мы ищем методиста, который будет разрабатывать программу. При отборе методиста мы смотрим на уровень подготовки. Опыт работы по профилю должен быть не менее трех лет.
Если под "по профилю" понимать разработку на Kotlin, то релиз 1.0 вышел меньше 2,5 лет назад. Так что исчерпывающий список кандидатов должен быть у abreslav и у yole. Но это не упрек, так — занудства ради, вы делаете очень нужное дело.
NoScript не было в первый день перехода. А потом стал страшным и кривым. К тому моменту я понял, что uMatrix+uBlock мне нравятся больше. Особенно uMatrix. AdBlock Plus подвернулся под руку.
А мне тоже нравится новый ФФ. Да, не всё, но в целом норм:
NoScript и AdBlock Plus отлично заменились uBlock и uMatrix. Тут я ничего не проиграл.
Вместо Tree Style Tab использую Tree Tabs. Функционально — шило на мыло. У обоих глюков два вагона, у обоих крышу иногда срывает. Может быть вернусь.
Открыто 813 вкладок. Количество плавает от 300 до 1100 примерно. Кажется, что это единственный браузер, который нормально работает в таком режиме.
Вот что протерял FF — на доквантовых версиях было 2 панели — справа и слева. Справа закладки (или история), а слева вкладки. Было удобно. Ну и при использовании дерева вкладок верхняя строка вкладок только мешает, а теперь вроде как не убирвается.
Есть еще несколько расширений, но они либо отладочные (обычно выключены), либо косметические (Tab2QR чтобы быстро открывать на мобильном, Tab Counter и другая мелочевка)
Сейчас уже на самом деле стало скорее лучше. Сначала было хуже (дополнения были не готовы и браузер странно вел себя). Если бы не потеря правой панели, то я бы однозначно сказал, что новая версия лучше.
Есть старый бородатый анекдот: «Рабинович, ну купи ты хоть один лотерейный билет». Я не говорю, что у Сергея бы всё получилось с его инициативами, что его обязательно повысят. Но он же «лотерейный билет не купил». Да, очень часто нужно свои решения в бизнесе обосновывать и показывать-доказывать, что решения верные, а вы, как исполнитель, подходите для их реализации.
Переформулирую. Я (не абстрактный виртуальный Сергей, а я) в этой ситуации первым делом поинтересовался бы у руководителя, могу ли я помочь обосновать свои решения и проработать их. Составить список возможных слабых мест решения, может какой-нибудь простенький SWOT накидать.
Да, часто убедить в своей правоте не получается (кто-то сдастся на первом отказе, кто-то на сто первом, а кто-то вовремя поймет, что лучше доказывать другим начальникам :) ). Да, часто это не только, и не столько техническое обоснование. Но если ты сдался, если решил «ну что я тут самый умный что ли», то это и есть то самое «профукал своё будущее как профессионала».
У меня были эпизоды, когда мне выгоднее было поступить не вполне профессионально, например, когда я, как консультант, должен был посоветовать «наше» решение, но оно клиенту не подходило (впарить моей квалификации бы хватило). Я стараюсь в этих случаях не разменивать свой профессионализм на сиюминутную выгоду. В начале карьеры это, кстати, еще важнее.
Из этой компании, кстати, я очень корректно (не хлопая дверью, найдя замену, передав дела) ушел, как только понял, что этот конфликт между текущими показателями и моим мнением на этой позиции — системный, а не разовый. С этой организацией впоследствии сотрудничал, как клиент.
Я не готов по обрывкам информации в этом рассказе делать такие глубокие выводы про то, что творится в описанной организации, мутит ли там кто-то с остатками, кто виноват, права ли Жанна и так далее. Я всего лишь хочу сказать, что если Сергей так легко сдался, то именно этим он себе помешал. Если на этом заводе всё так плохо, то надо валить, а не становиться «1С-нком закрывателем месяца».
Кажется, вот момент, когда Сергей профукал своё будущее как профессионала (и, возможно, как будущего управленца):
— Выгодно, сложно спорить. Но нужно понимать сроки и стоимость этого проекта. На словах все красиво звучит, но пока это только слова. Если я сейчас пойду к генеральному, предложу этот проект, то мы уже не сможем его не выполнить. Ты уверен, что учел все нюансы реальной жизни? Подводные камни, трудности перехода, саботаж при внедрении? Те же операторы и их начальник — как отнесутся к внедрению? Их силами ведь твой MDM заполнять. Насколько качественно они будут наполнять систему, которая их заменит?
— Ну, я не думал об этом, если честно. Но за технологии я готов поручиться, потому что видел исходники и их реальную работу. Та же CouchDB, с автоматической репликацией…
Как профессионал, он мог взять таймаут на анализ рисков и просчет прогнозного PnL по таким проектам, подготовить презентацию для гендира (или посчитав отказаться от проекта, но обоснованно). Если бы он еще и взял на себя координацию, то мог стать хорошим PM. А так пусть дальше месяца с бухами закрывает и номенклатуру руками перегружает.
Да, СХД типа VNC или VMax это больше, сложнее и дороже, чем рейд-контроллер. Но по большому счету в этой разнице latency «виновата» не СХД, а ОС, которая для одного «физического» с её точки зрения будет держать одну очередь.
Если вы нагрузку WAL бросите в общий котёл, то ничего этого не получите. Там полно в очереди таких, которым «только справочку получить».
Кто выжил?
Например, с того, что сейчас почти везде используются SSD. Впрочем, 10 лет назад разделение по дискам имело более критичное значение.
Я не знаю другого продукта на рынке, который называется именно "SQL Server" кроме произведенного Microsoft. Но, согласен, лучше было уточнить.
Наверное, возможно многое. Но сейчас write-ahead logging является одним из основных ограничений производительности. И эта бодяга тянется как минимум с 1992 года.
Иногда приходится, но очень-очень редко нужно больше двух параллельных дисков (точнее 4 потому что обычно это RAID10). Что нужно сделать чтобы узким местом стал отдельный SSD для WAL я даже не представляю.
Страшно. Реально страшно. Вы собираетесь ответить пользователю, что транзакция зафиксирована, а на самом деле нет. При сбое вы потом целостность не соберете.
Поздравляю, вы нашли пасхалку :) Именно PowerShell написано осознанно. Администрировать linux, не зная bash — невозможно. А называться администратором Windows не зная PowerShell — сложно, но возможно.
Никому. Серьёзно. У EMC цифры "что такое хорошо" меняются год от года. Сколько могут прямо щас — столько и Excellent. Вот в H12341 (октябрь 2013) и H14621 (декабрь 2015):
Судя по тому что цифры в них одинаковые, эта табличка не менялась уже пять лет.
В другом документе цифры меньше, но он тоже 2013 года.
И за эти 5 лет как раз почти всюду в high load стали использоваться All flash SSD решения. Тут надо не верить, а смотреть на конкретную СХД и выжимать из неё производительность. 1 мс было отлично 5 лет назад, но это не значит, что сейчас нельзя достигнуть большего.
А вообще, все СУБД (и распределённые и нет) достаточно «творчески» подходят к ACID, нераспределенные особенно к I — isolation (любые уровни изоляции отличные от SERIALIZABLE нарушают изоляцию), распределенные к C и D (плюс там хитрый вопрос что такое раньше/позже).
2PL работает совсем на другом уровне. Плюс тут же вопрос даже не в коммите. Коммит — это просто записать в журнал, что транзакция с таким-то LSN закоммичена. В WAL пишется всё подряд и однопоточно. И реализовать запись корректной последовательной цепочки всех изменений с достаточной надёжностью и хитрой обработкой параллельность пока ни в одной СУБД, видимо, не смогли.
В том же MS SQL небольшой кэш для транзакций есть (см тут), но он для другого случая, когда транзакция записывает много данных.
В любом случае статья не о том, как "можно было бы сделать СУБД", а о том "как те СУБД которые есть заставить работать". При нормальном разбиении дисков 5к-20к TPS выжать на продакшн вполне можно. С оговорками про конкретную задачу и бюджет.
Упс. Когда хотел написать комментарий, а написал статью
В 90% случаев это значит, что лида надо увольнять или переводить в менеджеры (если есть задатки или принцип Питера давит). В 10% — что должен был ревьюить миддл.
Если ведущий специалист пишет код, который никто не понимает, то куда же он ведет продукт? Мне в командах нужны лиды, которые могут сделать всякие ответственные штуки, например, самая ответственная — публичный API или общая схема взаимодействия блоков. Такой хороший код не сложен для понимания, а прост. Сложный код — не гордость опытного разработчика, а позор или признание какой-то слабости.
Для большинства бизнес-приложений это так. Есть исключения: одноразовый код, иногда high-concurrency, всякие интринсики или асм-вставки, код для экзотических железяк, всякая криптография и суровая математика. Ну да, есть иногда куски для объяснения которых нужен опыт выше джуна. Каждый такой кусок — повод задуматься "а не фигню ли мы делаем".
Датчик «считающий фотоны» (но всё равно через электроны) создать возможно, но он будет большой, требовать охлаждения и не сможет работать на частоте «прилетания фотонов» в видимом свете.
Ха! Да что там устроиться, мне было сложно даже найти в интервью имя сотрудника, который отвечал на вопросы (имя и фамилия только перед описанием задач, имя ещё в одной реплике в середине). Труъ разведчики :)
Если под "по профилю" понимать разработку на Kotlin, то релиз 1.0 вышел меньше 2,5 лет назад. Так что исчерпывающий список кандидатов должен быть у abreslav и у yole. Но это не упрек, так — занудства ради, вы делаете очень нужное дело.
А мне тоже нравится новый ФФ. Да, не всё, но в целом норм:
Сейчас уже на самом деле стало скорее лучше. Сначала было хуже (дополнения были не готовы и браузер странно вел себя). Если бы не потеря правой панели, то я бы однозначно сказал, что новая версия лучше.
Переформулирую. Я (не абстрактный виртуальный Сергей, а я) в этой ситуации первым делом поинтересовался бы у руководителя, могу ли я помочь обосновать свои решения и проработать их. Составить список возможных слабых мест решения, может какой-нибудь простенький SWOT накидать.
Да, часто убедить в своей правоте не получается (кто-то сдастся на первом отказе, кто-то на сто первом, а кто-то вовремя поймет, что лучше доказывать другим начальникам :) ). Да, часто это не только, и не столько техническое обоснование. Но если ты сдался, если решил «ну что я тут самый умный что ли», то это и есть то самое «профукал своё будущее как профессионала».
У меня были эпизоды, когда мне выгоднее было поступить не вполне профессионально, например, когда я, как консультант, должен был посоветовать «наше» решение, но оно клиенту не подходило (впарить моей квалификации бы хватило). Я стараюсь в этих случаях не разменивать свой профессионализм на сиюминутную выгоду. В начале карьеры это, кстати, еще важнее.
Из этой компании, кстати, я очень корректно (не хлопая дверью, найдя замену, передав дела) ушел, как только понял, что этот конфликт между текущими показателями и моим мнением на этой позиции — системный, а не разовый. С этой организацией впоследствии сотрудничал, как клиент.
Я не готов по обрывкам информации в этом рассказе делать такие глубокие выводы про то, что творится в описанной организации, мутит ли там кто-то с остатками, кто виноват, права ли Жанна и так далее. Я всего лишь хочу сказать, что если Сергей так легко сдался, то именно этим он себе помешал. Если на этом заводе всё так плохо, то надо валить, а не становиться «1С-нком закрывателем месяца».
Кажется, вот момент, когда Сергей профукал своё будущее как профессионала (и, возможно, как будущего управленца):
Как профессионал, он мог взять таймаут на анализ рисков и просчет прогнозного PnL по таким проектам, подготовить презентацию для гендира (или посчитав отказаться от проекта, но обоснованно). Если бы он еще и взял на себя координацию, то мог стать хорошим PM. А так пусть дальше месяца с бухами закрывает и номенклатуру руками перегружает.