Здравствуйте, alex_public, Вы писали:
I>>То есть, твой плюсовый код придется переписать целиком и полностью под каждый сервер базы данных, ибо мулька не умеет оптимизировать
_>Не путай оптимизацию кода (т.е. исправления косяков программиста, создавшего кривой sql) и адаптацию под особенности синтаксиса конкретной СУБД. Последнее естественно имеется, т.к. иначе собственно ничего и не работало бы.
Я говорю не про синтаксис, а про разницу между БД. У тебя оптимизаций нет, то есть, один и тот же запрос может хорошо работать в MS SQL и плохо в Oracle.
Пример — в одной базы фильтры и джойны дорогие, в другой — крайне дешовые. В одной оптимизатор адский, как у DB2 или postgresql, а в другой хилы, как в SQLite. Есть специфика индексов и прочих вещей. Особенности вьюшек.
Твоя мулька выдаст результат без учета этой специфики. То есть, на однйо базе будет шикарно, а на другой — провально. То есть, тебе надо руками писать код под SQLite, DB2, postgresql и тд
Здравствуйте, alex_public, Вы писали:
_>Это был форумный пример (причём в стиле "а можешь ли вот прямо к той строчке приделать сверху ещё и join"), а не реальный код. Естественно, что в реальном проекте подобного бреда не будет.
Помнится, в первом приближении ты вообще под injection с лету подставился с теми же аргументами.
Этот форумный пример вполне близок к реальности. И ловушки в нем тоже близки к реальности.
_>Лично мне большего для работы с SQL БД и не требуется.
Видимо, потому, что с хоть сколь-нибудь сложными запросами ты не работаешь.
_>Я — могу. Так же как и любой, знакомый с языком SQL. ))) Ну а для неосиливших SQL действительно стоит поискать другие инструменты. )
У меня есть обоснованные подозрения, что SQL я знаю лучше тебя. Поэтому намеки подобные на твоём месте
я бы оставил в сторонке.
Здравствуйте, Ikemefula, Вы писали:
_>>Не путай оптимизацию кода (т.е. исправления косяков программиста, создавшего кривой sql) и адаптацию под особенности синтаксиса конкретной СУБД. Последнее естественно имеется, т.к. иначе собственно ничего и не работало бы. I>Я говорю не про синтаксис, а про разницу между БД. У тебя оптимизаций нет, то есть, один и тот же запрос может хорошо работать в MS SQL и плохо в Oracle. I>Пример — в одной базы фильтры и джойны дорогие, в другой — крайне дешовые. В одной оптимизатор адский, как у DB2 или postgresql, а в другой хилы, как в SQLite. Есть специфика индексов и прочих вещей. Особенности вьюшек. I>Твоя мулька выдаст результат без учета этой специфики. То есть, на однйо базе будет шикарно, а на другой — провально. То есть, тебе надо руками писать код под SQLite, DB2, postgresql и тд
А, ну ну. )))
Давай только перейдём к конкретике. Вот допустим есть простейший запрос на linq с одним простым join. И вдруг неожиданно обнаруживается, что у нас СУБД с "дорогим join" (кстати, это кто у нас из реальных то будет?). Так какой же гениальный sql выдаст наш умный linq, чтобы обойти эту проблему? )
Здравствуйте, alex_public, Вы писали:
_>Я — могу. Так же как и любой, знакомый с языком SQL. ))) Ну а для неосиливших SQL действительно стоит поискать другие инструменты. )
Кстати про осиливших. Я правильно понимаю, что ты именно вот этот запрос отправишь на сервер СУБД?
_>SELECT Orders.user FROM Orders INNER JOIN SELECT Users.id,Users.name FROM Users WHERE (Users.total>10) AS rich_users ON (Orders.user=rich_users.id) WHERE (Orders.year>100)
[Skip]
_>Угу, в работе запроса в СУБД потери производительности нет. А вот в формирование запроса в твоём коде появляются накладные расходы превышающие время исполнения всего запроса. )))
Ну что ты такой упоротый капитан очевидность.
Мне надо гибкую систему построения SQL и она у меня уже есть, и я ею ОЧЕНЬ доволен, и ТЕПЕРЬ также довольны те кого я силой заставил на нее перейти, благо есть у меня такие рычаги.
Про накладные расходы будешь мне говорить когда у тебя на SQL сервере будет 100% загрузка проца и IO задержки на сторадже.
Ты даже не представляешь что в огромных системах еще в накладных расходах. Запрос на данные может переходить из Message Queue на Worker, дернуть кеш, а уже потом в базу сбегать, закешировать или результат пробросить третим асинхронным механизмом.
Все для того чтобы получить быстрый ответ, разгрузить этот нещастный SQL сервер и пораскидывать нагрузку на другие сервера. Пускай лучше app server пооптимизирует запрос, а SQL сервер даст быстрый ответ не перелопатив таблицу милионщик.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
_>>>Не путай оптимизацию кода (т.е. исправления косяков программиста, создавшего кривой sql) и адаптацию под особенности синтаксиса конкретной СУБД. Последнее естественно имеется, т.к. иначе собственно ничего и не работало бы. I>>Я говорю не про синтаксис, а про разницу между БД. У тебя оптимизаций нет, то есть, один и тот же запрос может хорошо работать в MS SQL и плохо в Oracle. I>>Пример — в одной базы фильтры и джойны дорогие, в другой — крайне дешовые. В одной оптимизатор адский, как у DB2 или postgresql, а в другой хилы, как в SQLite. Есть специфика индексов и прочих вещей. Особенности вьюшек. I>>Твоя мулька выдаст результат без учета этой специфики. То есть, на однйо базе будет шикарно, а на другой — провально. То есть, тебе надо руками писать код под SQLite, DB2, postgresql и тд
_>А, ну ну. )))
_>Давай только перейдём к конкретике. Вот допустим есть простейший запрос на linq с одним простым join. И вдруг неожиданно обнаруживается, что у нас СУБД с "дорогим join" (кстати, это кто у нас из реальных то будет?). Так какой же гениальный sql выдаст наш умный linq, чтобы обойти эту проблему? )
Какой захочешь, если создаетель провайдера не криворук.
Из реальных не знаю, может Hive, но не уверен. Там кажется можна оптимальней запрос создать.
И вообще ты совсем не в теме что такое linq provider.
Из реальных примеров, я видел как linq2db (он же linq provider) меняет SQL в зависимости от версии SQL сервера: новые фичи — более оптимальный запрос.
Вот это, например появилось в 2012 https://technet.microsoft.com/ru-ru/library/gg699618(v=sql.110).aspx
раньше это приходилось делать сабселектами через Rowid
Здравствуйте, alex_public, Вы писали:
I>>Пример — в одной базы фильтры и джойны дорогие, в другой — крайне дешовые. В одной оптимизатор адский, как у DB2 или postgresql, а в другой хилы, как в SQLite. Есть специфика индексов и прочих вещей. Особенности вьюшек. I>>Твоя мулька выдаст результат без учета этой специфики. То есть, на однйо базе будет шикарно, а на другой — провально. То есть, тебе надо руками писать код под SQLite, DB2, postgresql и тд
_>А, ну ну. )))
Да, структура запросов может сильно меняеться в зависимости от базы. Если в базе есть дешовая механика для конкретного случая, тебе, что бы заюзать такую, надо пилить руками. Linq провайдер как правило умеет такие фокусы.
_>Давай только перейдём к конкретике. Вот допустим есть простейший запрос на linq с одним простым join.
Нету в linq таких запросов. В linq у тебя будет "дай мне юзеров которые подходят под вон тот фильтр".
>И вдруг неожиданно обнаруживается, что у нас СУБД с "дорогим join" (кстати, это кто у нас из реальных то будет?). Так какой же гениальный sql выдаст наш умный linq, чтобы обойти эту проблему? )
Каким джойном пров это сделает, тебя совершенно не волнует. В одной базе будет быстрее через inner, в другой — через outer.
А в третьей может расставить хинты, где какой алгоритм джойна использовать, или вообще заменить джойн скажем на cte, если это даёт профит в частном случае.
Почему-то я совсем не удивлён, что ты решил проигнорировать все предложения о прямом сравнение. )))
_>>Угу, в работе запроса в СУБД потери производительности нет. А вот в формирование запроса в твоём коде появляются накладные расходы превышающие время исполнения всего запроса. ))) D>Ну что ты такой упоротый капитан очевидность. D>Мне надо гибкую систему построения SQL и она у меня уже есть, и я ею ОЧЕНЬ доволен, и ТЕПЕРЬ также довольны те кого я силой заставил на нее перейти, благо есть у меня такие рычаги.
Ты так говоришь, как будто бы я зову тебя перейти на какую-то другую оптимальную систему. А ничего подобного нет, хотя бы потому, что в рамках мира C# просто нет такой системы. Там есть или быстрая и неудобная (голые slq строки) или тормозная и удобная (различные виды linq2db). Чтобы получить реально удобные и эффективные инструменты надо забросить C# и перейти к более мощным инструментам, а на это уже мало кто из фанатов .net способен. Так что я в этой теме никого никуда не агитирую (собственно и какие-то упоминания об альтернативах из других языков притащил сюда не я), а просто отвечаю на некоторые возражения (правда после публикации в данной теме реальных замеров производительности они все пропали), появившиеся в ответ на мой тезис о тормознутости всех разновидностей linq2db.
D>Про накладные расходы будешь мне говорить когда у тебя на SQL сервере будет 100% загрузка проца и IO задержки на сторадже. D>Ты даже не представляешь что в огромных системах еще в накладных расходах. Запрос на данные может переходить из Message Queue на Worker, дернуть кеш, а уже потом в базу сбегать, закешировать или результат пробросить третим асинхронным механизмом. D>Все для того чтобы получить быстрый ответ, разгрузить этот нещастный SQL сервер и пораскидывать нагрузку на другие сервера. Пускай лучше app server пооптимизирует запрос, а SQL сервер даст быстрый ответ не перелопатив таблицу милионщик.
Ну я собственно уже писал, что для реализации домашней странички васи пупкина или же для мелкого внутрикорпоративного приложения все эти накладные расходы непринципиальны и соответственно linq идеально подходит для таких решений. Только это совершенно не означает его нетормознутость. )))
Здравствуйте, Danchik, Вы писали:
_>>А, ну ну. ))) _>>Давай только перейдём к конкретике. Вот допустим есть простейший запрос на linq с одним простым join. И вдруг неожиданно обнаруживается, что у нас СУБД с "дорогим join" (кстати, это кто у нас из реальных то будет?). Так какой же гениальный sql выдаст наш умный linq, чтобы обойти эту проблему? ) D>Какой захочешь, если создаетель провайдера не криворук. D>Из реальных не знаю, может Hive, но не уверен. Там кажется можна оптимальней запрос создать. D>И вообще ты совсем не в теме что такое linq provider.
Теоретически то конечно можно всё. Но я спрашиваю про вполне конкретную практику, которую мне обещали в сообщение выше. Но что-то пока не видно ни единого примера.
D>Из реальных примеров, я видел как linq2db (он же linq provider) меняет SQL в зависимости от версии SQL сервера: новые фичи — более оптимальный запрос. D>Вот это, например появилось в 2012 https://technet.microsoft.com/ru-ru/library/gg699618(v=sql.110).aspx D>раньше это приходилось делать сабселектами через Rowid
Ну так это как раз и есть особенности БД (в SQL Server не было OFFSET до 2012 года? Жесть конечно... Хорошо что никогда не надо было возиться с этой СУБД), которые естественно учитываются в реализации библиотеки (а иначе как тогда реализовать соответствующие команды?). Но к анонсированной умной оптимизации запросов это не имеет ни малейшего отношения.
Здравствуйте, Ikemefula, Вы писали:
_>>Давай только перейдём к конкретике. Вот допустим есть простейший запрос на linq с одним простым join. I>Нету в linq таких запросов. В linq у тебя будет "дай мне юзеров которые подходят под вон тот фильтр".
Всем понятно о чём речь, кончай глупые придирки.
>>И вдруг неожиданно обнаруживается, что у нас СУБД с "дорогим join" (кстати, это кто у нас из реальных то будет?). Так какой же гениальный sql выдаст наш умный linq, чтобы обойти эту проблему? ) I>Каким джойном пров это сделает, тебя совершенно не волнует. В одной базе будет быстрее через inner, в другой — через outer. I>А в третьей может расставить хинты, где какой алгоритм джойна использовать, или вообще заменить джойн скажем на cte, если это даёт профит в частном случае.
Заканчивай с теорией и переходи к конкретным реальным примерам. Хотя бы к одному. )
Здравствуйте, alex_public, Вы писали:
_>Ну я собственно уже писал, что для реализации домашней странички васи пупкина или же для мелкого внутрикорпоративного приложения все эти накладные расходы непринципиальны и соответственно linq идеально подходит для таких решений. Только это совершенно не означает его нетормознутость. )))
Статистика
•16 миллионов просмотров страниц в месяц
•3 миллионов уникальных пользователей в месяц (для сравнения: Facebook насчитывает около 77 миллионов уникальных пользователей в месяц)
•6 миллионов посещений в месяц
•86% трафика приходит с Google
•9 миллионов активных программистов во всем мире и 30% пользуются Stack Overflow
•Более дешевые лицензии были получены через программу Microsoft BizSpark. Скорее всего они заплатили около 11000\$ за лицензии на ОС и MSSQL.
Стратегия монетизации: ненавязчивая реклама, вакансии, конференции DevDays, достижения других смежных ниш (Server Fault, Super User), разработка StackExchange и возможно каких-то других систем рейтингов для программистов.
Платформа •Microsoft ASP.NET MVC
•SQL Server 2008 •C#
•Visual Studio 2008 Team Suite
•jQuery •LINQ to SQL
•Subversion
•Beyond Compare 3
•VisualSVN 1.5
•Веб уровень:
•2 x Lenovo ThinkServer RS110 1U
•4 ядра, 2.83 Ghz, 12 MB L2 cache
•500 GB жесткие диски, зеркалирование RAID1
•8 GB RAM
•Уровень базы данных:
•1 x Lenovo ThinkServer RD120 2U
•8 ядер, 2.5 Ghz, 24 MB L2 cache
•48 GB RAM
•Четвертый сервер был добавлен для запуска superuser.com. Все сервера вместе обеспечивают работу Stack Overflow, Server Fault, и Super User.
•QNAP TS-409U NAS для резервного копирования данных. Было принято решение не использовать "облачные" решения, так как вызванные ими дополнительные 5GB трафика ежедневно были бы накладными.
•Сервера располагаются у Peak Internet. В основном из-за впечатляющей детализации технических ответов и разумных расценок.
•Полнотекстный поиск в SQL Server активно используется для реализации поиска по сайту и выявления повторных вопросов. Lucene .NET рассматривается как достаточно заманчивая альтернатива.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
_>>Ну я собственно уже писал, что для реализации домашней странички васи пупкина или же для мелкого внутрикорпоративного приложения все эти накладные расходы непринципиальны и соответственно linq идеально подходит для таких решений. Только это совершенно не означает его нетормознутость. ))) S>Архитектура Stack Overflow
Ох уж этот Stack Overflow... Практически единственный существующий пример высоконагруженного решения на базе стека от MS. Для фанатов .net это вечный спасительный аргумент в дискуссиях. ))) Только вот если в применение винды и .net'a это до сих пор частично (потому что там у них появляется всё больше машин с Линухом и соответствующим ПО) справедливо, то уж про linq такого сказать нельзя. )))
Если мы посмотрим не на их архитектуру 2009-го года, когда они выдерживали не особо существенную нагрузку (такое при правильном коде потянул бы один мой рабочий компьютер, а им потребовалось аж 4 сервера), а на их современное состояние, где нагрузка уже реально приличная (но и архитектура уже совсем другая), то увидим очень много чего интересного: https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/. Там и множество линух машин и совершенно другая архитектура сети и замена всех .net библиотек на другие, эффективные решения и местами другие языки. Но главное в контексте нашей дискуссии в данной цитате:
Our usage of SQL is pretty simple. Simple is fast. Though some queries can be crazy, our interaction with SQL itself is fairly vanilla. We have some legacy Linq2Sql, but all new development is using Dapper, our open source Micro-ORM using POCOs. Let me put this another way: Stack Overflow has only 1 stored procedure in the database and I intend to move that last vestige into code.
Т.е. всё в точности, как я и говорил. Для страничек типа Васи Пупкина всё отлично. А как только переходим к чему-то серьёзному, то сразу выкидываем этот "удобный инструмент" на свалку. )))
Здравствуйте, alex_public, Вы писали:
_>Ох уж этот Stack Overflow... Практически единственный существующий пример высоконагруженного решения на базе стека от MS. Для фанатов .net это вечный спасительный аргумент в дискуссиях. ))) Только вот если в применение винды и .net'a это до сих пор частично (потому что там у них появляется всё больше машин с Линухом и соответствующим ПО) справедливо, то уж про linq такого сказать нельзя. )))
MySpace, все микрософтовские сайты
В хайлоад проблема не в linq, а в самой rdbms. Как правило, используются всякие хитрые архитектуры с ипользованием кластеров, кеширования через Nosql, денормализации и тд и тд и тд.
То есть, хайлоад это про масштабируемость. И здесь rdbms ничего внятного не умеет.
_>
_>Our usage of SQL is pretty simple. Simple is fast. Though some queries can be crazy, our interaction with SQL itself is fairly vanilla. We have some legacy Linq2Sql, but all new development is using Dapper, our open source Micro-ORM using POCOs. Let me put this another way: Stack Overflow has only 1 stored procedure in the database and I intend to move that last vestige into code.
_>Т.е. всё в точности, как я и говорил. Для страничек типа Васи Пупкина всё отлично. А как только переходим к чему-то серьёзному, то сразу выкидываем этот "удобный инструмент" на свалку. )))
Для даппера есть linq. Не знаю, используется ли он на SO, мне не докладывают.
_>Т.е. всё в точности, как я и говорил. Для страничек типа Васи Пупкина всё отлично. А как только переходим к чему-то серьёзному, то сразу выкидываем этот "удобный инструмент" на свалку. )))
То есть 16 миллионов запросов в месяц это домашняя страничка? Вы alex_public наверное много кушаете (зажрались)
Для подавляющего количества сайтов это запредельная нагрузка. На самом деле Linq нужен для учетных задач, где количество строк кода составляет десятки миллионов строк. Где важна скорость разработки. А поставить лишний сервер не проблема. Он значительно стоит меньше стоимости разработки и поддержки. Нужно уметь считать деньги.
Что касается SO то это далеко не учетная система. Там есть где можно оптимизировать, в плоть до хранимых процедур на .Net
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
I>В хайлоад проблема не в linq, а в самой rdbms. Как правило, используются всякие хитрые архитектуры с ипользованием кластеров, кеширования через Nosql, денормализации и тд и тд и тд. I>То есть, хайлоад это про масштабируемость. И здесь rdbms ничего внятного не умеет.
Это верно. Точнее так, при совсем серьёзных нагрузках (типа там всяких социальных сетей, поисковиков и т.п.) альтернативы горизонтальному масштабированию просто нет. Ну и соответственно изначально затачиваются на такие сценарии, выбирая подходящие СУБД и т.п. В случае же SO они изначально думали обойтись только вертикальным масштабированием и в самом начале у них похоже выходило. Сейчас же у них какое-то промежуточное решение судя по картинке с непонятными перспективами. Правда для их случая существует ещё и порог насыщения посещаемости (всё же программистов в мире не миллиарды), так что если они его достигнут, оставаясь в рамках вертикального масштабирования, то сумеют избежать многих проблем. Правда все эти вертикальные решения обычно весьма не дешёвые...
А вообще в их случае (не финансовые транзакции) можно было бы и изначально не пугаться распределённых решений с небольшой несогласованностью (всем пофиг если лишний лайк где-то там затеряется на время), но это уже другой вопрос.
_>>
_>>Our usage of SQL is pretty simple. Simple is fast. Though some queries can be crazy, our interaction with SQL itself is fairly vanilla. We have some legacy Linq2Sql, but all new development is using Dapper, our open source Micro-ORM using POCOs. Let me put this another way: Stack Overflow has only 1 stored procedure in the database and I intend to move that last vestige into code.
_>>Т.е. всё в точности, как я и говорил. Для страничек типа Васи Пупкина всё отлично. А как только переходим к чему-то серьёзному, то сразу выкидываем этот "удобный инструмент" на свалку. ))) I>Для даппера есть linq. Не знаю, используется ли он на SO, мне не докладывают.
Ага, это будет приблизительно так же умно, как взять машинку из формула1 и прицепить ей сзади прицеп от фуры. )))
Кстати, если глянуть страничку этой библиотеки (https://github.com/StackExchange/dapper-dot-net), то можно увидеть много любопытных замеров быстродействия. Из которых сразу понятна ориентация этой библиотечки и что там думают про linq1sql и т.п. ))) Вообще мне эта библиотечка очень напомнила по внешнему виду библиотеку SOCI из C++, которую я как раз предпочитал до тех пор, пока не познакомился с sqlppp11. Вполне добротный инструмент.
P.S. А вообще меня веселит там список библиотек и инструментов. Похоже что при малейшей потребности в реальной производительности .net надо подпиливать (подобными сомнительными https://github.com/kevin-montrose/Sigil хаками) по всем углам. Жесть конечно.
Здравствуйте, Serginio1, Вы писали:
_>>Т.е. всё в точности, как я и говорил. Для страничек типа Васи Пупкина всё отлично. А как только переходим к чему-то серьёзному, то сразу выкидываем этот "удобный инструмент" на свалку. ))) S> То есть 16 миллионов запросов в месяц это домашняя страничка? Вы alex_public наверное много кушаете (зажрались) S>Для подавляющего количества сайтов это запредельная нагрузка.
16 миллионов запросов в месяц — это всего лишь порядка 1-10 (в зависимости от времени суток) запросов в секунду. Смешных цифры, которые при нормальной архитектуре должен держать не просто один сервер, а спокойно справится даже обычный компьютер разработчика. То, что у них для этих целей работало аж 3 сервера очень многое говорит о печальности их архитектуры в прошлом. Но с тех пор они серьёзно оптимизировались (в том числе и выкинув всякие там linq2sql и т.п.) и сейчас нагрузку в 66 миллионов запросов в день (т.е. более чем в 120 раз больше!) у них держат уже совсем не 360 серверов... )))
S>На самом деле Linq нужен для учетных задач, где количество строк кода составляет десятки миллионов строк. Где важна скорость разработки. А поставить лишний сервер не проблема. Он значительно стоит меньше стоимости разработки и поддержки. Нужно уметь считать деньги.
Ну для начала решения на базе РСУБД так просто не масштабируются. Т.е. чтобы спокойно наращивать производительность новыми серверами нужна совсем другая архитектура. Ну да ладно, пока оставим такие детали и поговорим о собственно деньгах.
Если требуется поставить один лишний сервер ради увеличения удобства работы программистов, то возможно на такое и пойдут. А если лишнюю сотню, то всем станет резко наплевать на удобство. ))) Ну и как раз в "учётных системах" (ты же вроде как ERP так обзываешь, да?) существенные нагрузки встречаются редко, так что действительно можно наплевать на быстродействие (в крайнем случае действительно поставят второй (а не вторую сотню!) сервер).
S> Что касается SO то это далеко не учетная система. Там есть где можно оптимизировать, в плоть до хранимых процедур на .Net
Про хранимые процедуры у них вроде тоже всё очень чётко сказано в той же цитате выше.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Т.е. всё в точности, как я и говорил. Для страничек типа Васи Пупкина всё отлично. А как только переходим к чему-то серьёзному, то сразу выкидываем этот "удобный инструмент" на свалку. ))) S>> То есть 16 миллионов запросов в месяц это домашняя страничка? Вы alex_public наверное много кушаете (зажрались) S>>Для подавляющего количества сайтов это запредельная нагрузка.
_>16 миллионов запросов в месяц — это всего лишь порядка 1-10 (в зависимости от времени суток) запросов в секунду. Смешных цифры, которые при нормальной архитектуре должен держать не просто один сервер, а спокойно справится даже обычный компьютер разработчика. То, что у них для этих целей работало аж 3 сервера очень многое говорит о печальности их архитектуры в прошлом. Но с тех пор они серьёзно оптимизировались (в том числе и выкинув всякие там linq2sql и т.п.) и сейчас нагрузку в 66 миллионов запросов в день (т.е. более чем в 120 раз больше!) у них держат уже совсем не 360 серверов... )))
Давай посчитаем 16 000 000/(30*24*60*60)= 6.17. Это далеко не домашний компьютер. Учитывая что в пиках эта цифирь увеличивается в 4 раза как минимум в пике.
Кроме того
3 миллионов уникальных пользователей в месяц (для сравнения: Facebook насчитывает около 77 миллионов уникальных пользователей в месяц)
•6 миллионов посещений в месяц
•86% трафика приходит с Google
•9 миллионов активных программистов во всем мире и 30% пользуются Stack Overflow
Нужно держать данные о сессии итд. Заметь в новых версиях они используют Redis
Плюс наверняка используется SignalR для пуш нотификации
Если ты посмотрел на замеры Linq проигрывает максимум в 2 раза на простых запросах и проблемы именно на отображения данных на типизированные данные, так как запросы кэшируются автоматически или можно кэшировать в ручную. А ведь есть сложные запросы, где проигрых Linq составляет проценты. Мало того, затраты идут еще на формирование страниц. Тогда еще не было возможности применять асинхронные запросы в методе вэб метода.
S>>На самом деле Linq нужен для учетных задач, где количество строк кода составляет десятки миллионов строк. Где важна скорость разработки. А поставить лишний сервер не проблема. Он значительно стоит меньше стоимости разработки и поддержки. Нужно уметь считать деньги.
_>Ну для начала решения на базе РСУБД так просто не масштабируются. Т.е. чтобы спокойно наращивать производительность новыми серверами нужна совсем другая архитектура. Ну да ладно, пока оставим такие детали и поговорим о собственно деньгах.
Для примера берем 2 х звенку. Нагрузка на сервер SQL остается та же. Замедляется только процесс обработки на клиенте.
Для 3 х звенки добавить еще один сервер приложений тоже не проблема. Нагрузка на SQL сервер опять же та же.
В 1С эта схема прекрасно работает.
_>Если требуется поставить один лишний сервер ради увеличения удобства работы программистов, то возможно на такое и пойдут. А если лишнюю сотню, то всем станет резко наплевать на удобство. ))) Ну и как раз в "учётных системах" (ты же вроде как ERP так обзываешь, да?) существенные нагрузки встречаются редко, так что действительно можно наплевать на быстродействие (в крайнем случае действительно поставят второй (а не вторую сотню!) сервер).
Вот когда сотню, то хоть на ассемблере пишите. Только таких задач 0.000...0001% процента.
А нагрузки там бывают не хилые. Например РЖД перейти из-за импортозамещения на 1С. А сравнивать по скорости и мощности 1С с .Net очень
S>> Что касается SO то это далеко не учетная система. Там есть где можно оптимизировать, в плоть до хранимых процедур на .Net
_>Про хранимые процедуры у них вроде тоже всё очень чётко сказано в той же цитате выше.
Хранимые процедуры можно применять и в Linq, в том числе на CLR
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>> То есть 16 миллионов запросов в месяц это домашняя страничка? Вы alex_public наверное много кушаете (зажрались) S>>>Для подавляющего количества сайтов это запредельная нагрузка.
_>>16 миллионов запросов в месяц — это всего лишь порядка 1-10 (в зависимости от времени суток) запросов в секунду. Смешных цифры, которые при нормальной архитектуре должен держать не просто один сервер, а спокойно справится даже обычный компьютер разработчика. То, что у них для этих целей работало аж 3 сервера очень многое говорит о печальности их архитектуры в прошлом. Но с тех пор они серьёзно оптимизировались (в том числе и выкинув всякие там linq2sql и т.п.) и сейчас нагрузку в 66 миллионов запросов в день (т.е. более чем в 120 раз больше!) у них держат уже совсем не 360 серверов... ))) S> Давай посчитаем 16 000 000/(30*24*60*60)= 6.17. Это далеко не домашний компьютер. Учитывая что в пиках эта цифирь увеличивается в 4 раза как минимум в пике.
Хорошо, 24 странички в секунду. Только чтение (ответов и комментариев — может, 1 на 100 таких просмотров). Входной ключ поиска — число в URL. На каждую, считаем, select текста вопроса с подробностями вроде автора, суммы оценок; select списка ответов; на каждый вопрос или ответ (не совсем эффективно?) select списка комментариев; к каждому ответу и комментарию через join имя автора (другие параметры для него, считай, не нужны). Правая полоса — hot network questions универсальны на весь сайт, пересчитываются в фоне. Related — считаются в фоне. Итого на среднюю страницу штук 6 относительно лёгких запросов (одно текстовое безразмерное поле, остальные фиксированные и короткие), все по точному id (=> очень легко оптимизирующийся поиск). Кластеризация по индексу по id (то же самое по сути, что по времени) сокращает дисковую активность у сидящих на индексных страничках до самого топа, остальное (сколько там переходов из поисковиков — 2/3?) выходит за кэш, но тоже не проблема; а так как поздних ответов очень мало (основные приходят за час, если не за минуты), то и там далеко ответ от вопроса и комментарий от ответа не убежит. 144 запроса, так?
Ты всерьёз считаешь, что "обычный компьютер разработчика" (только не надо сразу подменять его "домашним", это несерьёзный метод дискуссии) не справится с таким? На 5 лет назад, когда типичный разработчик под MS, чуть утрирую, требовал Corei7+16GB и соглашался поскрипывая сердцем (tm) на Corei5+8GB? По-моему, у него запас ещё на пол-порядка, включая и процессор, и диск (не одиночный HDD, конечно, а зеркало SSD).
S> Вот когда сотню, то хоть на ассемблере пишите. Только таких задач 0.000...0001% процента. S> А нагрузки там бывают не хилые. Например РЖД перейти из-за импортозамещения на 1С.
Чуть в сторону от исходного вопроса — а разве импортозамещение не предполагает уход от MS?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Serginio1, Вы писали:
S>>>> То есть 16 миллионов запросов в месяц это домашняя страничка? Вы alex_public наверное много кушаете (зажрались) S>>>>Для подавляющего количества сайтов это запредельная нагрузка.
_>>>16 миллионов запросов в месяц — это всего лишь порядка 1-10 (в зависимости от времени суток) запросов в секунду. Смешных цифры, которые при нормальной архитектуре должен держать не просто один сервер, а спокойно справится даже обычный компьютер разработчика. То, что у них для этих целей работало аж 3 сервера очень многое говорит о печальности их архитектуры в прошлом. Но с тех пор они серьёзно оптимизировались (в том числе и выкинув всякие там linq2sql и т.п.) и сейчас нагрузку в 66 миллионов запросов в день (т.е. более чем в 120 раз больше!) у них держат уже совсем не 360 серверов... ))) S>> Давай посчитаем 16 000 000/(30*24*60*60)= 6.17. Это далеко не домашний компьютер. Учитывая что в пиках эта цифирь увеличивается в 4 раза как минимум в пике.
N>Хорошо, 24 странички в секунду. Только чтение (ответов и комментариев — может, 1 на 100 таких просмотров). Входной ключ поиска — число в URL. На каждую, считаем, select текста вопроса с подробностями вроде автора, суммы оценок; select списка ответов; на каждый вопрос или ответ (не совсем эффективно?) select списка комментариев; к каждому ответу и комментарию через join имя автора (другие параметры для него, считай, не нужны). Правая полоса — hot network questions универсальны на весь сайт, пересчитываются в фоне. Related — считаются в фоне. Итого на среднюю страницу штук 6 относительно лёгких запросов (одно текстовое безразмерное поле, остальные фиксированные и короткие), все по точному id (=> очень легко оптимизирующийся поиск). Кластеризация по индексу по id (то же самое по сути, что по времени) сокращает дисковую активность у сидящих на индексных страничках до самого топа, остальное (сколько там переходов из поисковиков — 2/3?) выходит за кэш, но тоже не проблема; а так как поздних ответов очень мало (основные приходят за час, если не за минуты), то и там далеко ответ от вопроса и комментарий от ответа не убежит. 144 запроса, так?
Давай посчитаем сколько из всего этого затрат составляет Linq. Так как кроме запросов есть еще данные сессии, формирование страниц
нотификация типа SignalR
N>Ты всерьёз считаешь, что "обычный компьютер разработчика" (только не надо сразу подменять его "домашним", это несерьёзный метод дискуссии) не справится с таким? На 5 лет назад, когда типичный разработчик под MS, чуть утрирую, требовал Corei7+16GB и соглашался поскрипывая сердцем (tm) на Corei5+8GB? По-моему, у него запас ещё на пол-порядка, включая и процессор, и диск (не одиночный HDD, конечно, а зеркало SSD).
Ты считаешь только запросы. Еще раз нужно держать данные о сессиях которые миллионы, есть необходимость о Пуш нотификациях? затраты на формирование страниц, итд. Может оказаться, что затраты на Linq это вообще малая доля процента. S>> Вот когда сотню, то хоть на ассемблере пишите. Только таких задач 0.000...0001% процента. S>> А нагрузки там бывают не хилые. Например РЖД перейти из-за импортозамещения на 1С.
N>Чуть в сторону от исходного вопроса — а разве импортозамещение не предполагает уход от MS?
У 1С есть Вэб клиент и работа с PostgreSQL. А скорость 1С заметно медленнее .Net
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>Кстати, если глянуть страничку этой библиотеки (https://github.com/StackExchange/dapper-dot-net), то можно увидеть много любопытных замеров быстродействия. Из которых сразу понятна ориентация этой библиотечки и что там думают про linq1sql и т.п. )))
Недавно мы обсуждали замеры производительности. Ты не забыл ? Так вот фокус в том, что linq2db работает быстрее чем dapper.
