Про arch, что он не самый маленький - принимается. Я скорее имел в виду, что его установочный образ заметно меньше обычных GUI live инсталляторов. В любом случае, я его упомянул, потому что мне проще было посмотреть историю размеров, при том что функционально изменения за это время минимальны. У той же ubuntu тенденция похожая. И у debian, и у остальных (общего назначения) то же самое.
Причём я когда-то смотрел, почему там такой рост. Что меня тогда зацепило, что в образе-инсталляторе arch лежали библиотеки рантайма go для компиляции через gcc (это около 50 МБ одна soшка, если мне память не изменяет). При том, что рантайм go в этом образе вообще был не нужен. Мне стало лень писать мейнейнеру предложение о разделении (чтобы этот рантайм тянулся по зависимостям) - я в тот момент просто собирал образ для экспериментов.
PS: notepad посмотрел просто для примера, зайдя по RDP. Да, notepad++ меньше, конечно, при невообразимо более широких возможностях. А notepad, как и kwrite, я использую для одноразовых заметок.
С одной стороны, многие библиотеки бесконечно улучшают: тут SIMD воткнут, там алгоритм от квадратичного в граничных случаях избавится, где-то от расчётов ненужных избавятся, где-то от false sharing. Если посмотреть на производительность конкретной фичи с точки зрения кода, то обычно она становится лучше (это если она на стеке-долгожителе, а не была переписана с C++ на python, конечно).
С другой стороны, как правильно указано в статье - навешиваются какие-то безумные с точки зрения конечной функции расходы. То предсказание переходов безопасности мешает, то в контейнер (а то и виртуалку) надо запихнуть, перейдя с внутрипроцессного вызова на TCP+TLS RPC. Ну и по мелочи - указатели стали в 2 раза толще, int64 стал чаще типом по умолчанию и т.п. Причём на самом деле 80% этого можно найти и устранить но обычно "оно не стоит того". И это "не стоит того" для одного конкретного фактора приводит к непрерывному росту ПО. Везде. Не все его замечают, потому что он медленный, но это как расширение вселенной - становится главным фактором на больших масштабах. Причем это почти везде. Я помню нытьё, что dotnet увеличивал размер дистрибутива на 30 МБ. Я вижу, что iso-образ archlinux (который вообще-то неизменно умеет минимум: только загрузиться, немного починить что сломалось и загрузить пакеты из интернета) растёт раза в 2 за каждые 5-7 лет. Блин, archlinux - самый минималистичный iso из всех - стал 1,5 ГБ!
Еще отдельный фактор - изменение железа, например, уход с тех пор с HDD. Если я запущу условную WinNT4 в виртуалке, то я ж расплачусь от того как она быстро будет работать. Ну да. Только тогда у меня памяти было 64МБ, а сейчас 128ГБ, тогда latency диска была 10 мс, а сейчас 20 мкс, тогда диск мог отдать 50 МБ/с, а сейчас 3 ГБ/с. Пожалуй, только latency DRAM плюс-минус там же осталась (сначала упав, а теперь уже лет 20 растёт). Так вот: сейчас ВМ с WinXP/NT4/2000/2003 работает неприлично быстро и экономично по сравнению с нынешними ОС и с самой собой 25-летней давности. Причём основные улучшения в отзывчивости от скорости SSD.
Отдельно замечу, что много нетехнических свойств у систем, которые влияют на их использование. Ну вот тот же GDPR - теперь на каждом милипусеньком сайте торчат всплывашки на первом выхове.
И там еще много подобных факторов. И в итоге у нас одновременно есть и эффект "раньше было лучше", и "стало в 100 раз быстрее".
PS: в 2000 году на NT4 я мог запустить на 1 ядре и 64 МБ памяти SQL Server, его Enterprise Manager, Query Analyzer и еще и HoMM3 (но, если честно, то обычно перед запуском HoMM я всё остальное гасил). А сейчас у меня пустой блокнот ест сопоставимо (notepad.exe - 30 МБ, kwrite - 100 МБ). И с другой стороны, я могу (теперь скорее сын может) играть с разрешением 100 fps на экране 3840x1920 с честной 3d-графикой, трассировкой лучей и правдоподобной физикой, а у меня тогда еле хватало на HL в 640x480 (в 24 раза меньше пикселей).
Но если говорить о latency, то гигабитная сеть обставляет HDD по этому параметру, а вполне себе рядовая 10Гбит/сек, конкурирует с SSD
Так это же не "вместо", а "вместе". Для "D" в ACID придётся ждать сеть туда + fsync + сеть обратно. Ну или городить какой-то хитрый компромиссный кластер (типа несколько сервисов журнала и хотя бы 2 должны ответить, что приняли, но эти 2 должны быть не в одной стойке или какие-то подобные извраты). При этом WAL всё еще в какой-то точке должен быть "однопоточным" (т.е. как минимум - упорядочиваемый). То, что 1Сники ставят synchronious_commit=false - ну значит в этих БД не нужна надёжность. Я почти уверен, что и отделение сервиса WAL им ничем не улучшит.
Если я правильно понимаю, то потому что движок WAL очень критичен для производительности реляционной части. Каждый insert/update/delete должен потрогать WAL, причем в последовательноси (ну хотя бы сериализуемом последовательно) порядке. Причем операции обязаны дождаться ответа (критично latency), а не просто "вот тебе данные - трудись". А WAL не должен отвечать, что всё готово, пока буква D в ACID не выполнена. В этой модели - добавить десятки-сотни микросекунд к каждому вызову WAL - убить производительность.
А если вам транзакции не так нужны, или нужны асинхронно, то берите какой-нибудь Clickhouse )
Даже скорее джун. По легенде он админ, а админы учатся посылать такие задачи в первый год (или не выживают в дикой природе).
А раз он джун, то директор должен был "обнять, приподнять" и выкинуть на мороз весь менеджмент ИТ (кроме Олега). - Руководитель админов: не контролировал выполнение задач. У него сотрудник месяцами перерабатывает, ноль результат по мнению заказчиков и инциденты ИБ. Контуры прод/дев/qa не разделены (и я бы предложил делегировать многие задачи по администрированию dev/qa в dev/qa). Значимые ресурсы (алё - там 10 ТБ только одна копия) выделяются без подтверждению бюджетов. Диагноз: профнепригодность. - Руководитель ИБ: рядовой админ не включая мозг и не спотыкаясь выносит из прода 10 ТБ с персданными. Об этом как-то узнаётся после развёртывания. Вы уволены нахрен. - Руководитель разрабов: у вас админ должен разбираться в бизнес-логике и написании запросов с учетом бизнес-логики. По неактуальной документации. Релиз не выпущен (разработка в этом виновата по умолчанию). Может увольнять рано, но оргвыводы стоит сделать. - Руководитель QA: принят релиз без инструкции по развёртыванию, нет сред тестирования (их обновление должно быть будничной задачкой QA), тестирвоание релиза сорвано. Методология тестирования "нам для тестов нужны прод данные" мягко говоря спорная, особенно с уточнением "прод но не совсем прод, а иногда и совсем не прод".
Если над всем этим есть еще PM/PO/CTO, то красные от стыда за управленческий бардак они заявление по собственному сами должны принести.
Так они работают везде по-разному с разными особенностями. В SQL Server CTE в целом тоже ближе к "макросам". В PG CTE исходно умели быть только метериализованными (и этим немало крови выпили программистам), сейчас и так и так могут. Про Oracle я не скажу - не сталкивался плотно. Но это лишь часть вопроса. Потому что второй вопрос - выполнение функций в выражениях выборки. Да еще и нестандартных функций. Да еще и с вопросами по детерминированности (должна ли недетерминированная функция возвращать одно и то же значение во всё запросе? ). Каждая СУБД тут вправе применять подход, который показался логичным разработчикам (у функций текущего времени похожие вопросики).
У меня винда несколько раз перегружалась, когда я ставил долгие расчёты на ночь.
А про "каждый день почти вывешивает список обновлений" - мы всё еще про arch? Он вроде пока пакмана не пнёшь, даже не поинтересуется. И если не хочется - просто не обновляй. Или поставь на расписание, какое хочешь. Или не перегружай (если ядро не обновлено).
Я отвечал на комментарий выше про "дверь в увлекательный квест". Это обычно приписывается роллинг-дистрибутивам и в первую очередь как раз арчу. Ну и что уж там - на горизонте 10 лет я могу вспомнить "интересные" обновления. И, кстати, да, я вспомнил относительно недавнее обновление чуть более хлопотное, чем просто "-Syu" это переход KDE с QT5 на QT6. Проблема была не столько в самом обновлении, сколько в том, что некоторые интересные приложения использовали QT5 заметно дольше, чем основной массив KDE. Из-за этого некоторые элементы QT5 долго висели как нужные одновременно с аналогами из QT6, что иногда проявлялось. Но по-большому счёту это никаких хлопот не доставляло (и с MS тут точно не лучше).
У меня основная ОС на моих ПК дома - арч (у сына и жены - вин). Все арчи обновляются тихо и спокойно. Чёткого графика нет, но основной ПК я обновляю раз в 2-3-4 недели, остальные чуть реже - раз в 1-2 месяца. У меня есть 2 "почти неприкосновенные" виртуалки virtualbox для определённого приложения определённой версии для определённого сценария использования. В какой-то момент, года 3 назад, оно поломалось на обновлении основного приложения (это скорее мой сценарий использования заранее сломан, причём из-за Windows, но это неважно), поэтому их я не обновляю. Одна виртуалка с Manjaro, вторая с Arch + LXQT. Я раз в год примерно обновляю их копии (из любопытства) - они легко и спокойно обновляются. Ну ок, у кривой от рождения Manjaro тема в гномике слетает. Ну да, качнуть надо много, но в целом оно обновляется даже быстрее регулярных обновлений вин10/вин11 (из-за которых я свалил с виндовс). Лет за 5 последних, только пару некритичных поломок VirtualBox могу припомнить, всё остальное "просто обновляется".
Ну как не бывает? После объяснения простыми словами "высоким начальникам" надо еще и сделать так, чтобы они думали, что это их идея и пошли на неё инициативно выделять бабло. По пути не растеряв мысль.
А значит это то, что у ссылки нет автоинкремента, потому как GUID имеет условно случайную структуру – они так задумывались. Даже если использовать Time-Based GUIDs для первичных ключей, они получаются более сгруппированными (GUID’ы выдаются пулом по 32 штуки для каждого сеанса), но всё равно не последовательными. Некоторое ускорение при вставке в кластерный индекс Time-Based GUID даёт, но в целом индекс получается плохо кластеризован и как сказал сам Б.Нуралиев: «Механизм генерации ссылок обеспечивает только их уникальность. Возрастающая последовательность при их генерации не обеспечивается.».
Ссылка для СУБД в первую очередь это binary(16). SQL Server про её "гуидообразность" как бы не в курсе совсем. На стороне 1С своим (не очень обычным) преобразованием эта binary(16) преобразуется из/в GUID.
Из-за этого ссылаться на "GUID имеет условно случайную структуру – они так задумывались" некорректно. У нас в СУБД это не GUID, и 1С ссылки не генерит как GUID ОС, а пользуется своим движком.
В рамках одной ИБ, в рамках одного сервера ссылки, созданные по умолчанию, в виде binary(16) в целом близки (очень близки) к монотонным. Если их генерировать сторонними средствами и генерацией гуидов, то, конечно, это нарушается. Если генерировать в разных ИБ на разных серверах 1С:Предприятия, то это будут разные серии.
Time-Based GUID генерируемый ОС или SQL Server имеет не ту же структуру, что механизм "новая ссылка". И по умолчанию они друг к другу отношения не имеют.
Это замечание никак не противоречит выводам статьи, которые в целом, конечно, верны. Просто для уточнения, что на самом деле гуиды отдельно, ссылки отдельно.
И тогда тоже его смена стоила примерно от полугодовой его зарплаты. Эти деньги же не на смузи уходят. Скорее наоборот, сейчас проще, программисты стали типовыми, практически клонированными.
Как я и сказал, в результате меня не уволили. И по сей день мне непонятно, почему.
Ха. Да потому что нанять нового инженера стоит примерно от полугодовой его зарплаты. На поиск, на собеседования, на обучение, на притирку, на исправление проблем при притирке. Если сотрудник сделал что-то не очень хорошее, но последствия предотвратили и объяснили, что это было плохо и есть надежда, что он понял, то оставить будет дешевле, чем через год ловить такую же ошибку у следующего.
Понимаю, что тут автор, конечно, комментарий не увидит, но по fraction использование как раз понятно в финансовых, торговых и экономических программах: "Decimal type, based on Fraction type with explicit precision" (цитата из описания). Писать вычисления денег (цен, количества, стоимости, котировок и т.п.) на флоатах и интах больно.
Про arch, что он не самый маленький - принимается. Я скорее имел в виду, что его установочный образ заметно меньше обычных GUI live инсталляторов. В любом случае, я его упомянул, потому что мне проще было посмотреть историю размеров, при том что функционально изменения за это время минимальны. У той же ubuntu тенденция похожая. И у debian, и у остальных (общего назначения) то же самое.
Причём я когда-то смотрел, почему там такой рост. Что меня тогда зацепило, что в образе-инсталляторе arch лежали библиотеки рантайма go для компиляции через gcc (это около 50 МБ одна soшка, если мне память не изменяет). При том, что рантайм go в этом образе вообще был не нужен. Мне стало лень писать мейнейнеру предложение о разделении (чтобы этот рантайм тянулся по зависимостям) - я в тот момент просто собирал образ для экспериментов.
PS: notepad посмотрел просто для примера, зайдя по RDP. Да, notepad++ меньше, конечно, при невообразимо более широких возможностях. А notepad, как и kwrite, я использую для одноразовых заметок.
но, блин, не как pentium MMX же!
А тут несколько разнонаправленных трендов.
С одной стороны, многие библиотеки бесконечно улучшают: тут SIMD воткнут, там алгоритм от квадратичного в граничных случаях избавится, где-то от расчётов ненужных избавятся, где-то от false sharing. Если посмотреть на производительность конкретной фичи с точки зрения кода, то обычно она становится лучше (это если она на стеке-долгожителе, а не была переписана с C++ на python, конечно).
С другой стороны, как правильно указано в статье - навешиваются какие-то безумные с точки зрения конечной функции расходы. То предсказание переходов безопасности мешает, то в контейнер (а то и виртуалку) надо запихнуть, перейдя с внутрипроцессного вызова на TCP+TLS RPC. Ну и по мелочи - указатели стали в 2 раза толще, int64 стал чаще типом по умолчанию и т.п. Причём на самом деле 80% этого можно найти и устранить но обычно "оно не стоит того". И это "не стоит того" для одного конкретного фактора приводит к непрерывному росту ПО. Везде. Не все его замечают, потому что он медленный, но это как расширение вселенной - становится главным фактором на больших масштабах. Причем это почти везде. Я помню нытьё, что dotnet увеличивал размер дистрибутива на 30 МБ. Я вижу, что iso-образ archlinux (который вообще-то неизменно умеет минимум: только загрузиться, немного починить что сломалось и загрузить пакеты из интернета) растёт раза в 2 за каждые 5-7 лет. Блин, archlinux - самый минималистичный iso из всех - стал 1,5 ГБ!
Еще отдельный фактор - изменение железа, например, уход с тех пор с HDD. Если я запущу условную WinNT4 в виртуалке, то я ж расплачусь от того как она быстро будет работать. Ну да. Только тогда у меня памяти было 64МБ, а сейчас 128ГБ, тогда latency диска была 10 мс, а сейчас 20 мкс, тогда диск мог отдать 50 МБ/с, а сейчас 3 ГБ/с. Пожалуй, только latency DRAM плюс-минус там же осталась (сначала упав, а теперь уже лет 20 растёт). Так вот: сейчас ВМ с WinXP/NT4/2000/2003 работает неприлично быстро и экономично по сравнению с нынешними ОС и с самой собой 25-летней давности. Причём основные улучшения в отзывчивости от скорости SSD.
Отдельно замечу, что много нетехнических свойств у систем, которые влияют на их использование. Ну вот тот же GDPR - теперь на каждом милипусеньком сайте торчат всплывашки на первом выхове.
И там еще много подобных факторов. И в итоге у нас одновременно есть и эффект "раньше было лучше", и "стало в 100 раз быстрее".
PS: в 2000 году на NT4 я мог запустить на 1 ядре и 64 МБ памяти SQL Server, его Enterprise Manager, Query Analyzer и еще и HoMM3 (но, если честно, то обычно перед запуском HoMM я всё остальное гасил). А сейчас у меня пустой блокнот ест сопоставимо (notepad.exe - 30 МБ, kwrite - 100 МБ). И с другой стороны, я могу (теперь скорее сын может) играть с разрешением 100 fps на экране 3840x1920 с честной 3d-графикой, трассировкой лучей и правдоподобной физикой, а у меня тогда еле хватало на HL в 640x480 (в 24 раза меньше пикселей).
Так это же не "вместо", а "вместе". Для "D" в ACID придётся ждать сеть туда + fsync + сеть обратно. Ну или городить какой-то хитрый компромиссный кластер (типа несколько сервисов журнала и хотя бы 2 должны ответить, что приняли, но эти 2 должны быть не в одной стойке или какие-то подобные извраты). При этом WAL всё еще в какой-то точке должен быть "однопоточным" (т.е. как минимум - упорядочиваемый).
То, что 1Сники ставят synchronious_commit=false - ну значит в этих БД не нужна надёжность. Я почти уверен, что и отделение сервиса WAL им ничем не улучшит.
Если я правильно понимаю, то потому что движок WAL очень критичен для производительности реляционной части. Каждый insert/update/delete должен потрогать WAL, причем в последовательноси (ну хотя бы сериализуемом последовательно) порядке. Причем операции обязаны дождаться ответа (критично latency), а не просто "вот тебе данные - трудись". А WAL не должен отвечать, что всё готово, пока буква D в ACID не выполнена.
В этой модели - добавить десятки-сотни микросекунд к каждому вызову WAL - убить производительность.
А если вам транзакции не так нужны, или нужны асинхронно, то берите какой-нибудь Clickhouse )
Нейрокартинка в ответ на жалобу на нейрокартинки
Даже скорее джун. По легенде он админ, а админы учатся посылать такие задачи в первый год (или не выживают в дикой природе).
А раз он джун, то директор должен был "обнять, приподнять" и выкинуть на мороз весь менеджмент ИТ (кроме Олега).
- Руководитель админов: не контролировал выполнение задач. У него сотрудник месяцами перерабатывает, ноль результат по мнению заказчиков и инциденты ИБ. Контуры прод/дев/qa не разделены (и я бы предложил делегировать многие задачи по администрированию dev/qa в dev/qa). Значимые ресурсы (алё - там 10 ТБ только одна копия) выделяются без подтверждению бюджетов. Диагноз: профнепригодность.
- Руководитель ИБ: рядовой админ не включая мозг и не спотыкаясь выносит из прода 10 ТБ с персданными. Об этом как-то узнаётся после развёртывания. Вы уволены нахрен.
- Руководитель разрабов: у вас админ должен разбираться в бизнес-логике и написании запросов с учетом бизнес-логики. По неактуальной документации. Релиз не выпущен (разработка в этом виновата по умолчанию). Может увольнять рано, но оргвыводы стоит сделать.
- Руководитель QA: принят релиз без инструкции по развёртыванию, нет сред тестирования (их обновление должно быть будничной задачкой QA), тестирвоание релиза сорвано. Методология тестирования "нам для тестов нужны прод данные" мягко говоря спорная, особенно с уточнением "прод но не совсем прод, а иногда и совсем не прод".
Если над всем этим есть еще PM/PO/CTO, то красные от стыда за управленческий бардак они заявление по собственному сами должны принести.
Так они работают везде по-разному с разными особенностями. В SQL Server CTE в целом тоже ближе к "макросам". В PG CTE исходно умели быть только метериализованными (и этим немало крови выпили программистам), сейчас и так и так могут. Про Oracle я не скажу - не сталкивался плотно.
Но это лишь часть вопроса. Потому что второй вопрос - выполнение функций в выражениях выборки. Да еще и нестандартных функций. Да еще и с вопросами по детерминированности (должна ли недетерминированная функция возвращать одно и то же значение во всё запросе? ). Каждая СУБД тут вправе применять подход, который показался логичным разработчикам (у функций текущего времени похожие вопросики).
Контент 18+
У меня винда несколько раз перегружалась, когда я ставил долгие расчёты на ночь.
А про "каждый день почти вывешивает список обновлений" - мы всё еще про arch? Он вроде пока пакмана не пнёшь, даже не поинтересуется. И если не хочется - просто не обновляй. Или поставь на расписание, какое хочешь. Или не перегружай (если ядро не обновлено).
Я отвечал на комментарий выше про "дверь в увлекательный квест". Это обычно приписывается роллинг-дистрибутивам и в первую очередь как раз арчу. Ну и что уж там - на горизонте 10 лет я могу вспомнить "интересные" обновления.
И, кстати, да, я вспомнил относительно недавнее обновление чуть более хлопотное, чем просто "-Syu" это переход KDE с QT5 на QT6. Проблема была не столько в самом обновлении, сколько в том, что некоторые интересные приложения использовали QT5 заметно дольше, чем основной массив KDE. Из-за этого некоторые элементы QT5 долго висели как нужные одновременно с аналогами из QT6, что иногда проявлялось. Но по-большому счёту это никаких хлопот не доставляло (и с MS тут точно не лучше).
У меня основная ОС на моих ПК дома - арч (у сына и жены - вин). Все арчи обновляются тихо и спокойно. Чёткого графика нет, но основной ПК я обновляю раз в 2-3-4 недели, остальные чуть реже - раз в 1-2 месяца.
У меня есть 2 "почти неприкосновенные" виртуалки virtualbox для определённого приложения определённой версии для определённого сценария использования. В какой-то момент, года 3 назад, оно поломалось на обновлении основного приложения (это скорее мой сценарий использования заранее сломан, причём из-за Windows, но это неважно), поэтому их я не обновляю. Одна виртуалка с Manjaro, вторая с Arch + LXQT. Я раз в год примерно обновляю их копии (из любопытства) - они легко и спокойно обновляются. Ну ок, у кривой от рождения Manjaro тема в гномике слетает. Ну да, качнуть надо много, но в целом оно обновляется даже быстрее регулярных обновлений вин10/вин11 (из-за которых я свалил с виндовс).
Лет за 5 последних, только пару некритичных поломок VirtualBox могу припомнить, всё остальное "просто обновляется".
Так и я. Если есть класс NP-h, есть класс "объяснять сложные вещи простыми словами", который много хуже. А есть следующая итерация сложности.
Ну как не бывает? После объяснения простыми словами "высоким начальникам" надо еще и сделать так, чтобы они думали, что это их идея и пошли на неё инициативно выделять бабло. По пути не растеряв мысль.
3 секунды искал буквы NP.
Ссылка для СУБД в первую очередь это binary(16). SQL Server про её "гуидообразность" как бы не в курсе совсем. На стороне 1С своим (не очень обычным) преобразованием эта binary(16) преобразуется из/в GUID.
Из-за этого ссылаться на "GUID имеет условно случайную структуру – они так задумывались" некорректно. У нас в СУБД это не GUID, и 1С ссылки не генерит как GUID ОС, а пользуется своим движком.
В рамках одной ИБ, в рамках одного сервера ссылки, созданные по умолчанию, в виде binary(16) в целом близки (очень близки) к монотонным. Если их генерировать сторонними средствами и генерацией гуидов, то, конечно, это нарушается. Если генерировать в разных ИБ на разных серверах 1С:Предприятия, то это будут разные серии.
Time-Based GUID генерируемый ОС или SQL Server имеет не ту же структуру, что механизм "новая ссылка". И по умолчанию они друг к другу отношения не имеют.
Это замечание никак не противоречит выводам статьи, которые в целом, конечно, верны. Просто для уточнения, что на самом деле гуиды отдельно, ссылки отдельно.
И тогда тоже его смена стоила примерно от полугодовой его зарплаты. Эти деньги же не на смузи уходят. Скорее наоборот, сейчас проще, программисты стали типовыми, практически клонированными.
Ха. Да потому что нанять нового инженера стоит примерно от полугодовой его зарплаты. На поиск, на собеседования, на обучение, на притирку, на исправление проблем при притирке. Если сотрудник сделал что-то не очень хорошее, но последствия предотвратили и объяснили, что это было плохо и есть надежда, что он понял, то оставить будет дешевле, чем через год ловить такую же ошибку у следующего.
Люди гибнут за металл.
Сатана там правит бал, там правит бал,
Понимаю, что тут автор, конечно, комментарий не увидит, но по
fractionиспользование как раз понятно в финансовых, торговых и экономических программах: "Decimal type, based on Fraction type with explicit precision" (цитата из описания). Писать вычисления денег (цен, количества, стоимости, котировок и т.п.) на флоатах и интах больно.Счётчик написан криво, некорректно отрабатывает количество более
.