Psychedelic Geek

Грокаем алгоритмы?

На мой взгляд для .NET на Windows Server удобнее все: разработка, поддержка, администрирование. Но я использую это только для корпоративных продуктов с высокой степенью надежности.

Для своих проектов Linux выгоднее. Здесь я имею ввиду не только отсутствие лицензии (за нее я и так никогда не платил), а требования к серверу.
Допустим я пишу сайтик на .NET и SQL server – тогда для комфортной работы я должен оплачивать сервер минимум 8Гб оперативки и 4 ядра ЦП. Но если я напишу это же самое в связке .NET и Mysql 8.0 – это будет работать также хорошо на линуксе с 2 ядрами и 2ГБ оперативки.
Более того на заре выхода .NET 5 сами мелкософт признавались что у IIS есть ряд ограничений и рекомендовали сайтики с высокой нагрузкой по запросам размещать на линухе.

В вашем конкретном случае я бы остался на винде, а новые проекты на .NET уже бы писал для линукса. Причем предупреждаю последняя удобная винда это Windows Server 2022. Если вы поставите версию старее то лишитесь как минимум TLS 1.3, а если поставите новее (2025) тогда получите неудобный UI для девочек как в эпплах.

Только для тех случаев, когда зависимости ПО работают только под виндой. Во всех остальных случаях удобнее и практичнее линукс. Сегодня dotNet спокойно ставится под линуксом из пакетов и отлично там работает как и любое другое ПО.

Если Windows Server настолько проиграл Linux в серверных войнах, то почему Microsoft не закрывает этот отдел? Значит сервера на Windows, используются.

Потому что деньги и экосистема. В рамках своей экосистемы продавать больше услуг клиентам выгоднее и позволяет заработать денег. В этом и смысл экосистем.

Почему я задал этот вопрос, я как системный администратор, столкнулся с клиентом, с которым я сцепился из за того, что его разработчики и бывший сотрудник сисадмин решил установить .NET + C# + Mono + Nginx и все это на линукс.
Естественно меня это взбесило, и я просто отказался все это поддерживать, потому что извините, но .NET проще поддерживать на Windows Server

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

Это вы должны решить. Зачастую путают языковые и региональные версии.
Как правило другой регион, это другая структура сайта. И логично делать отдельными разделами или даже сайтами. А просто перевод можно и плагином сделать.

Угу. Сначала понаставим @, чтобы скрыть все ошибки, а потом будем голову ломать, почему ничего не работает и ошибок не показывает.

А вообще, это делается в одну строку.

file_put_contents($outfilename, str_replace('Российский рубль', 'RUB', file_get_contents($infilename)));

Если очень кратко:
Вам нужно понять, что индексы это не такая уж элементарная вещь. Нельзя просто поставить на поле флажок "индексировать". Индексы это тонкая настройка, и чем сложнее выборки, тем она сложнее. Даже не рассматривая различные типы индексов, выбрать какие поля, в какой последовательности, с какой сортировкой и в каком индексе должны присутствовать бывает не так просто. Для этого нужно очень хорошо понимать и как устроены индексы, и как с ними будет работать оптимизатор и какова селективность конкретных данных. И тогда, скорость выборок можно увеличить в разы, но все это конечно не бесплатно.
Тем не менее, другой ваш вопрос, если нужно фильтровать и сортировать по всем полям таблицы, а полей очень много, здесь уже использование реляционных СУБД не оправдано и на помощь приходят другие инструменты, типа ElasticSearch.
Если заботитесь о стабильности, то индексы всегда назначаются при разработке соответствующих запросов. Если потом мы их и меняем, то потому что чтото не предусмотрели.
Индексы могут замедлить работу. Очевидно, что они замедляют вставки и апдейты, но при криворукости можно замедлить и выборки, ведь и оптимизатор тоже ошибается. Индекс это по сути еще одна таблица, что уже намекает что не всегда это будет быстрее, т.к. придется работать не с одной таблицей, а с двумя (не всегда с двумя, но опять же, в двух словах все не охватишь).

Когда ты связываешь две таблицы по полю, то поле второй таблицы должно быть проиндексировано для мгновенного доступа, чтобы это поле могло быть отображено рядом. В FoxPro это наглядно видно. Поэтому сначала надо подумать, сделать архитектуру, а потом писать. Но так не всегда получается, и приходится добавлять индексы "на живую" под вновь появившуюся хотелку. В общем индексы нужны для быстрой связи между БД.

Таблица без индексов это как Array либо List объектов. Каждый новый индекс добавляет хранение этих объектов в Map (Dictionary) где key мапы это index key, а value это строка.

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

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

Индексы нужны, но не всегда и не всем.
При разработке вы действительно точно не можете спрогнозировать нагрузку на БД. Но точно и не нужно. Как правило разработчик знает свое приложение, и какие данные из БД ему нужны. Соответственно знает предикаты (блок WHERE), которые будут в тех или иных запросах. Далее, входе разработки, когда будет накоплена некоторая статистика по наиболее востребованным предикатам, можно будет уже продумать какие индексы нужны.
В ходе реальной эксплуатации приложения, даже просто у разных клиентов может возникнуть ситуация, когда у одного все хорошо, а у другого тормозит. Все зависит от профиля нагрузки и наполнения таблиц. Бывает, что таблица DML-нагружена (много изменений) и имеет много индексов - будут тормоза, связанные с дополнительной работой по поддержания индексов в актуальном состоянии. А если ещё и много ограничений целостности...
Второй вариант, когда у одного клиента таблица на 1к строк и ему хорошо без индексов, даже если таблица "горячая" по чтениям. БД просто держит её всегда в кэше.
У другого клиента эта же таблица содержит 100к записей и ему ну очень нужны какие то индексы.
Ситуация когда данные в таблице часто меняются и часто и много запрашиваются, как правило связанны с не верной архитектурой приложения. Тут нужно уже переделывать.

Ответ очень прост. Смотришь сколько идёт ли поиск по полю, если медленно то ставишь индекс все.
Для определения быстро или медленно. Тоже легко если таблица миллион плюс записей будет то сразу да, если нет смотришь требования, запрос должен происходить максимально быстро то ставишь индекс(к примеру часто используется в подзапросе) , если не важно то не ставишь. Все весь алгоритм.
А вообще чтобы понять требуется индекс или нет смотришь сколь вообще идёт запрос в веб если он идёт в районе 1 секунды то все ок, если нет ищешь способ ускорить, сам простой способ проиндексирвать на поля по которым идёт поиск.
Так же индекс не имеет смысла ставить на поле, если ты перед этим будет фильтр, который уменьшить выборку до 10-20 значений.
К примеру у тебя в таблице, хранятся ид пользователя и его адрес. По ты точно знаешь, что только по адресу поиск не производиться, то можно фильтрануть по ид пользователя, а потомм по адресу, а адресов больше 100 99% не имеют. Тут индекс не нуден

Ну как минимум чтение индекса при поиске обходится намного дешевле, чем чтение всей таблицы. Банально меньшее кол-во данных надо прочитать. Тем более индексы - упорядоченная структура, для поиска данных по какой-то колонке не надо читать весь индекс. Можно сравнить b-tree индекс с алфавитным указателем - чтобы найти в нём ссылку на какое-то слово, не надо читать весь алфавитный указатель, надо просто перейти к нужной букве.
Но да, не каждый индекс может быть полезен. Есть такое понятие, как селективность индекса. Условно, индекс по полю "пол" реально может не давать пользы, так как даже при использовании индекса так и так надо будет прочитать половину записей в таблице и может быть быстрее просто прочитать всю таблицу.
Рекомендую прочитать книги, например, я читал "Настройка производительности MySQL" Нихтера. Тогда всё станет ясно.

Вопрос бы переформулировать. Не нужны ли индексы, а сколько надо индексов.
По своему опыту.
1 индекс на таблицу обязательно. Даже если в запросе нет условия по индексу, план выполнения строится оптимальнее, запросы работают быстрее.
А вот больше уже сильно зависит от используемой БД и самого использования. С pg например столкнулся с ситуацией, когда второй индекс сильно замедляет операции вставки и удаления. При этом этом селекты выполняются незначительно медленее. И если сравнивать организацию индексов в pg и mssql, то можно даже найти объяснения, почему то, что хорошо работало в одной БД, плохо работает в другой.