Здравствуйте, 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 и т.п. )))

P.S. А вообще меня веселит там список библиотек и инструментов. Похоже что при малейшей потребности в реальной производительности .net надо подпиливать (подобными сомнительными https://github.com/kevin-montrose/Sigil хаками) по всем углам. Жесть конечно.

Здравствуйте, 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 хаками) по всем углам. Жесть конечно.