Здравствуйте, gandjustas, Вы писали:
G>Ну конечно же я обязан считать что у всех пипец какие масштабные проекты и все знают о чем пишут
Ну как минимум предположить это ты вполне в состоянии

G>Это за какой период времени? Что за сайт? Сколько запросов на фронтэнд сервер приходится в секунду?
Это одновременно. Количество реквестов в секунду того же порядка. Сайт — это NDA.

G>Если один кривой запрос положит сервак, то он с таким же успехом положит и два, и три, и десять.
G>Или ты думаешь что действие говнокода ограничено одним сервером?
Я думаю что большинство говнокода(кроме особо запущенных случаев) можно перебороть дополнительными ресурсами. А шардирование позволит не допускать особо идиотских кейсов.

G>>>Сначала делается апдейт схемы, а потом изменяется код, который со схемой работает. Если отказаться от идеи "одного большого апдейта", то и проблем не будет.
I>>Ну вот, на время апдейта схемы и кода система лежит.
G>С чего ты взял?
Ну вот расскажи(или кинь линку), как сделать по другому.

Здравствуйте, itslave, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:
G>>Ну конечно же я обязан считать что у всех пипец какие масштабные проекты и все знают о чем пишут
I>Ну как минимум предположить это ты вполне в состоянии
Я стараюсь использовать научный метод — подвергать сомнению все, что не доказано. За несколько лет холиваров не нашлось ни одного человека с проектами масштаба SO. Поэтому я сомневаюсь в компетентности всех пишуших про нагрузки.

G>>Это за какой период времени? Что за сайт? Сколько запросов на фронтэнд сервер приходится в секунду?
I>Это одновременно. Количество реквестов в секунду того же порядка. Сайт — это NDA.
Что такое "одновременно" ? Ключевая входящая метрика нагрузки — RPS, "того же порядка" это не число, количество фронтэндов тоже неизвестно.
Это и дает основание сомневаться.

G>>Если один кривой запрос положит сервак, то он с таким же успехом положит и два, и три, и десять.
G>>Или ты думаешь что действие говнокода ограничено одним сервером?
I>Я думаю что большинство говнокода(кроме особо запущенных случаев) можно перебороть дополнительными ресурсами. А шардирование позволит не допускать особо идиотских кейсов.
Приведи пример чтоли. Не понимаю как шардирование связано с говнокодом.
Например если из-за говнокода применяется линейный поиск по таблице\коллекции, то шардирование потребует на порядок больше денег, чем исправление говнокода. Но на scale up vs scale out не повлияет.

G>>>>Сначала делается апдейт схемы, а потом изменяется код, который со схемой работает. Если отказаться от идеи "одного большого апдейта", то и проблем не будет.
I>>>Ну вот, на время апдейта схемы и кода система лежит.
G>>С чего ты взял?
I>Ну вот расскажи(или кинь линку), как сделать по другому.
Не пойму что сделать по-другому? Что ты делаешь из-за чего у тебя система останавливается?

Здравствуйте, gandjustas, Вы писали:
G>Я стараюсь использовать научный метод — подвергать сомнению все, что не доказано. За несколько лет холиваров не нашлось ни одного человека с проектами масштаба SO. Поэтому я сомневаюсь в компетентности всех пишуших про нагрузки.
Хм, ну тогда я вполне обоснованно могу подвергнуть сомнению твое существование

G>Что такое "одновременно" ? Ключевая входящая метрика нагрузки — RPS, "того же порядка" это не число, количество фронтэндов тоже неизвестно.
G>Это и дает основание сомневаться.
Я то в курсе, но доступа к статистике прода у меня уже нет, поэтому итак как помню. RPS посчитать можно лихко из предоставленных данных и коммон сенса.

G>Приведи пример чтоли. Не понимаю как шардирование связано с говнокодом.
G>Например если из-за говнокода применяется линейный поиск по таблице\коллекции, то шардирование потребует на порядок больше денег, чем исправление говнокода. Но на scale up vs scale out не повлияет.
Вот как раз линейный поиск можно лихко ограничить одним шардом и тем самым минимизировать влияние говнокода. Безусловно, тоже самое можно сделать и с классической scale up схемой, но в ней сложнее отлавливать такие кейсы.

G>>>>>Сначала делается апдейт схемы, а потом изменяется код, который со схемой работает. Если отказаться от идеи "одного большого апдейта", то и проблем не будет.
I>>>>Ну вот, на время апдейта схемы и кода система лежит.
G>>>С чего ты взял?
I>>Ну вот расскажи(или кинь линку), как сделать по другому.
G>Не пойму что сделать по-другому? Что ты делаешь из-за чего у тебя система останавливается?
Ок, давай возьмем пример.
Допустим версия 1 софтины работает с БД, в которой есть табличка Orders с колонкой Comments. В версии 2 той же софтины появляется табличка Comments, связанная N:1 c табличкой Orders. Также в табличке Comments есть поле интовое Kind, которое характеризует тип комментария: жалоба, похвала и тд. Также надо построить полнотекстовый индекс по каменту, ключам и Kind-у.
Необходимо проапдейтать БД и смигрировать данные в новую таблицу. Каждый имеющейся камент необходимо проверить полдесятком регэкспов и в зависимости от результата выставить коле Kind.
В таблице — десятки лямов записей и вся процедура занимает около часа.
Твой solution?

Здравствуйте, itslave, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:
G>>Я стараюсь использовать научный метод — подвергать сомнению все, что не доказано. За несколько лет холиваров не нашлось ни одного человека с проектами масштаба SO. Поэтому я сомневаюсь в компетентности всех пишуших про нагрузки.
I>Хм, ну тогда я вполне обоснованно могу подвергнуть сомнению твое существование
Конечно можешь

G>>Что такое "одновременно" ? Ключевая входящая метрика нагрузки — RPS, "того же порядка" это не число, количество фронтэндов тоже неизвестно.
G>>Это и дает основание сомневаться.
I>Я то в курсе, но доступа к статистике прода у меня уже нет, поэтому итак как помню. RPS посчитать можно лихко из предоставленных данных и коммон сенса.
Нельзя. Потому что "одновременные сессии" могут быть вообще чем угодно. От живого websocket подключения до количества обращений в интервале 30 минут.

G>>Приведи пример чтоли. Не понимаю как шардирование связано с говнокодом.
G>>Например если из-за говнокода применяется линейный поиск по таблице\коллекции, то шардирование потребует на порядок больше денег, чем исправление говнокода. Но на scale up vs scale out не повлияет.
I>Вот как раз линейный поиск можно лихко ограничить одним шардом и тем самым минимизировать влияние говнокода. Безусловно, тоже самое можно сделать и с классической scale up схемой, но в ней сложнее отлавливать такие кейсы.
Я говорю про поиск по всей коллекции, при чем тут шард? Переписать SQL запрос и добавить индекс попроще будет, чем плодить шарды и ограничивать запросы.

I>Допустим версия 1 софтины работает с БД, в которой есть табличка Orders с колонкой Comments. В версии 2 той же софтины появляется табличка Comments, связанная N:1 c табличкой Orders. Также в табличке Comments есть поле интовое Kind, которое характеризует тип комментария: жалоба, похвала и тд. Также надо построить полнотекстовый индекс по каменту, ключам и Kind-у.
I>Необходимо проапдейтать БД и смигрировать данные в новую таблицу. Каждый имеющейся камент необходимо проверить полдесятком регэкспов и в зависимости от результата выставить коле Kind.
I>В таблице — десятки лямов записей и вся процедура занимает около часа.
I>Твой solution?
А в чем проблема? Делаешь то что нужно — переливаешь данные, выставляешь kind, это занимает хоть 10 часов. Код не трогаешь, работает старый.
За 10 часов тебе нападает еще комментов, переливание которых займет уже не 10 часов, а меньше, пусть час.
Так за несколько итерация время переливания уменьшится практически до нуля. Потом накатить новую версию софта.

Можно и другим способом — при чтении получать старую и новую версию комментов, а писать только в новую. Так стоит делать если у тебя нету доступа к базе.

Здравствуйте, itslave, Вы писали:
I>Допустим версия 1 софтины работает с БД, в которой есть табличка Orders с колонкой Comments. В версии 2 той же софтины появляется табличка Comments, связанная N:1 c табличкой Orders. Также в табличке Comments есть поле интовое Kind, которое характеризует тип комментария: жалоба, похвала и тд. Также надо построить полнотекстовый индекс по каменту, ключам и Kind-у.
I>Необходимо проапдейтать БД и смигрировать данные в новую таблицу. Каждый имеющейся камент необходимо проверить полдесятком регэкспов и в зависимости от результата выставить коле Kind.
I>В таблице — десятки лямов записей и вся процедура занимает около часа.
I>Твой solution?
Решение — примитивное:
1. Первым делом меняем схему
— добавляем табличку Comments
— добавляем view Orders, которое заменит таблицу Оrders, которую мы переименуем в OrdersData. С очевидным left outer join и coalesce для чтения комментов.
— добавляем instead of триггеры для нашего нового View, которые отправляют комментарий в comments, а всё остальное — в OrdersData
2. Теперь мы можем инциировать процесс ленивого выдвижения данных. Нам неважно сколько времени он займет, т.к. это не влияет на работу системы. Пусть займёт хоть 1000 часов.
3. когда все данные уже на месте, можно подменить код и метаданные за секунды.

Это самая сложная из задач, или есть ещё что-то?

Здравствуйте, Sinclair, Вы писали:

S>Решение — примитивное:
S>1. Первым делом меняем схему
S>- добавляем табличку Comments
S>- добавляем view Orders, которое заменит таблицу Оrders, которую мы переименуем в OrdersData. С очевидным left outer join и coalesce для чтения комментов.

Только не зыбываем, что на таблицу Orders могут быть завязаны другие таблицы, индексы, jobs, репликация. Так что даже переименование не такая уж простая операция.

S>- добавляем instead of триггеры для нашего нового View, которые отправляют комментарий в comments, а всё остальное — в OrdersData
S>2. Теперь мы можем инциировать процесс ленивого выдвижения данных. Нам неважно сколько времени он займет, т.к. это не влияет на работу системы. Пусть займёт хоть 1000 часов.
Важно, хотя бы потому, что общая производительность сервера просядет. А если поплывет статистика по индексам, то тем более.

S>3. когда все данные уже на месте, можно подменить код и метаданные за секунды.
S>Это самая сложная из задач, или есть ещё что-то?

Это красиво выглядит только на примитивнейшей базе.

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, Sinclair, Вы писали:

S>>Решение — примитивное:
S>>1. Первым делом меняем схему
S>>- добавляем табличку Comments
S>>- добавляем view Orders, которое заменит таблицу Оrders, которую мы переименуем в OrdersData. С очевидным left outer join и coalesce для чтения комментов.
AJD>Только не зыбываем, что на таблицу Orders могут быть завязаны другие таблицы, индексы, jobs, репликация. Так что даже переименование не такая уж простая операция.
И что? Остановка сервера все равно не требуется.



S>>- добавляем instead of триггеры для нашего нового View, которые отправляют комментарий в comments, а всё остальное — в OrdersData
S>>2. Теперь мы можем инциировать процесс ленивого выдвижения данных. Нам неважно сколько времени он займет, т.к. это не влияет на работу системы. Пусть займёт хоть 1000 часов.
AJD>Важно, хотя бы потому, что общая производительность сервера просядет. А если поплывет статистика по индексам, то тем более.
1) с чего бы статистике поехать?
2) как ты хочешь сделать аналогичную операцию без просадки производительности?


S>>3. когда все данные уже на месте, можно подменить код и метаданные за секунды.
S>>Это самая сложная из задач, или есть ещё что-то?
AJD>Это красиво выглядит только на примитивнейшей базе.
Это нормально работает на любой базе. Я так структуру таблицы менял на лету, таблица 500 гб занимала. Там даже online clustered index rebuild на 16 часов был. Остановок — 0, повышение нагрузки на сервер БД — 30%, но запаса хватало.

Здравствуйте, gandjustas, Вы писали:

AJD>>Только не зыбываем, что на таблицу Orders могут быть завязаны другие таблицы, индексы, jobs, репликация. Так что даже переименование не такая уж простая операция.
G>И что? Остановка сервера все равно не требуется.
Тебе прийдется эти джобы и репликацию остановить.

G>1) с чего бы статистике поехать?
Условия меняются.

G>2) как ты хочешь сделать аналогичную операцию без просадки производительности?
Я не знаю как это сделать без просадки производительности.


AJD>>Это красиво выглядит только на примитивнейшей базе.
G>Это нормально работает на любой базе. Я так структуру таблицы менял на лету, таблица 500 гб занимала. Там даже online clustered index rebuild на 16 часов был. Остановок — 0, повышение нагрузки на сервер БД — 30%, но запаса хватало.
Это просто говорит о том, что у тебя низкая нагрузка на базу и замедление не вызывало лавинообразный рост времени обработки запросов.
Понятно, что если клиент готов мириться с многосекундным ожиданием — это не проблема. Для других клиентов рост времени обработки с 10-15мс даже до 500мс будет не приемлемо.

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, gandjustas, Вы писали:

AJD>>>Только не зыбываем, что на таблицу Orders могут быть завязаны другие таблицы, индексы, jobs, репликация. Так что даже переименование не такая уж простая операция.
G>>И что? Остановка сервера все равно не требуется.
AJD>Тебе прийдется эти джобы и репликацию остановить.
Это одна транзакция, которая отрабатывает за долю секунды.

G>>1) с чего бы статистике поехать?
AJD>Условия меняются.
И с чего бы статистике поехать?

G>>2) как ты хочешь сделать аналогичную операцию без просадки производительности?
AJD>Я не знаю как это сделать без просадки производительности.
Тогда к чему ты написал?


AJD>>>Это красиво выглядит только на примитивнейшей базе.
G>>Это нормально работает на любой базе. Я так структуру таблицы менял на лету, таблица 500 гб занимала. Там даже online clustered index rebuild на 16 часов был. Остановок — 0, повышение нагрузки на сервер БД — 30%, но запаса хватало.
AJD>Это просто говорит о том, что у тебя низкая нагрузка на базу и замедление не вызывало лавинообразный рост времени обработки запросов.
Там база с огромным запасом была.

AJD>Понятно, что если клиент готов мириться с многосекундным ожиданием — это не проблема. Для других клиентов рост времени обработки с 10-15мс даже до 500мс будет не приемлемо.
С чего будет такой рост? Ты сказки рассказываешь какие-то.

Здравствуйте, gandjustas, Вы писали:
G>Я говорю про поиск по всей коллекции, при чем тут шард? Переписать SQL запрос и добавить индекс попроще будет, чем плодить шарды и ограничивать запросы.
А я тебе говорю про то, что шардирование тебя заставляет думать правильно и не волевым усилием отрубить поиск по всей коллекции. А переписывать проще пока ты один, а если у тебя в команде десяток-полтора архаровцев разной квалификации и мотивации, то тут проще и дешевле плодить шарды.

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

Здравствуйте, itslave, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:
G>>Я говорю про поиск по всей коллекции, при чем тут шард? Переписать SQL запрос и добавить индекс попроще будет, чем плодить шарды и ограничивать запросы.
I>А я тебе говорю про то, что шардирование тебя заставляет думать правильно и не волевым усилием отрубить поиск по всей коллекции.
А без шардирования думать нельзя? Или если какие-то проблемы думать когда нет шардирования?

I>А переписывать проще пока ты один, а если у тебя в команде десяток-полтора архаровцев разной квалификации и мотивации, то тут проще и дешевле плодить шарды.
Проще обучить, ты даже не представляешь как обучение сказывается на продуктивности. А еще проще не набирать идиотов, которые не могут нормально запрос написать.

G>>За 10 часов тебе нападает еще комментов, переливание которых займет уже не 10 часов, а меньше, пусть час.
G>>Так за несколько итерация время переливания уменьшится практически до нуля. Потом накатить новую версию софта.
I>рабочий вариант, ты упустил перестроение полнотекстового индекса которое очевидно дело долгое. Если расскажешь как с ним быть без просадки производительности, то можно сказать что нет вопросов
Построение индекса асинхронное в любой системе, так что ждать его нет смысла.
Делает все без просадки производительности.

Здравствуйте, AndrewJD, Вы писали:

AJD>Только не зыбываем, что на таблицу Orders могут быть завязаны другие таблицы, индексы, jobs, репликация. Так что даже переименование не такая уж простая операция.
Она непростая с точки зрения SQL. С точки зрения downtime — примитивная, т.к. объём изменяемых данных околонулевой.

AJD>Важно, хотя бы потому, что общая производительность сервера просядет. А если поплывет статистика по индексам, то тем более.
Разжовываю: мы можем сделать эту операцию сколь угодно медленной. Количество выдвижений в секунду — параметр регулируемый. Можно даже динамически: видим, ночью нагрузка снизилась — поехали побыстрее; днём поднялась — прикрутили фитилёк.
S>>3. когда все данные уже на месте, можно подменить код и метаданные за секунды.
S>>Это самая сложная из задач, или есть ещё что-то?
AJD>Это красиво выглядит только на примитивнейшей базе.
Ждём реально нереально сложную задачу в студию. И, главное-то: мы же в этой ветке обсуждаем вертикальное масштабирование против горизонтального.
Поэтому бессмысленно обсуждать само по себе решение задачи — покажите, в какой архитектуре получится её решить лучше. А то складывается впечатление, что при смене схемы данных в NoSQL не потребуется заниматься вычислением comment.kind при помощи регекспов, или полнотекстовые индексы перестраиваются сами собой.

Здравствуйте, gandjustas, Вы писали:

G>>>И что? Остановка сервера все равно не требуется.
AJD>>Тебе прийдется эти джобы и репликацию остановить.
G>Это одна транзакция, которая отрабатывает за долю секунды.
Во-первых не долю секунды, а во вторых это влияет на функционал.

AJD>>Условия меняются.
G>И с чего бы статистике поехать?
с того бы это.

G>>>2) как ты хочешь сделать аналогичную операцию без просадки производительности?
AJD>>Я не знаю как это сделать без просадки производительности.
G>Тогда к чему ты написал?
Ты еще помнишь о чем топик то был?

AJD>>>>Это красиво выглядит только на примитивнейшей базе.
G>>>Это нормально работает на любой базе. Я так структуру таблицы менял на лету, таблица 500 гб занимала. Там даже online clustered index rebuild на 16 часов был. Остановок — 0, повышение нагрузки на сервер БД — 30%, но запаса хватало.
AJD>>Это просто говорит о том, что у тебя низкая нагрузка на базу и замедление не вызывало лавинообразный рост времени обработки запросов.
G>Там база с огромным запасом была.
Что подверждает тезис что твоя схема работает только при отсуствии сколько нибудь существенной нагрузки.

AJD>>Понятно, что если клиент готов мириться с многосекундным ожиданием — это не проблема. Для других клиентов рост времени обработки с 10-15мс даже до 500мс будет не приемлемо.
G>С чего будет такой рост? Ты сказки рассказываешь какие-то.
практика, она такая разная бывает.

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, gandjustas, Вы писали:

G>>>>И что? Остановка сервера все равно не требуется.
AJD>>>Тебе прийдется эти джобы и репликацию остановить.
G>>Это одна транзакция, которая отрабатывает за долю секунды.
AJD>Во-первых не долю секунды, а во вторых это влияет на функционал.
Что именно влияет?



AJD>>>Условия меняются.
G>>И с чего бы статистике поехать?
AJD>с того бы это.
Ты приведи конкретику, а то вообще непонятно чем твое предположение обосновано.
Новые таблицы, новые индексы -> новая статистика. Что куда поедет объясни.

G>>>>2) как ты хочешь сделать аналогичную операцию без просадки производительности?
AJD>>>Я не знаю как это сделать без просадки производительности.
G>>Тогда к чему ты написал?
AJD>Ты еще помнишь о чем топик то был?
Да, топик был о том, что вертикальное масштабирование выгоднее горизонтального. На что коллега сказал, что при горизонтальном масштабировании можно сделать zero downtime и предложил такую проблему. Ты пишешь что нельзя это сделать без просадки производительности.

AJD>>>>>Это красиво выглядит только на примитивнейшей базе.
G>>>>Это нормально работает на любой базе. Я так структуру таблицы менял на лету, таблица 500 гб занимала. Там даже online clustered index rebuild на 16 часов был. Остановок — 0, повышение нагрузки на сервер БД — 30%, но запаса хватало.
AJD>>>Это просто говорит о том, что у тебя низкая нагрузка на базу и замедление не вызывало лавинообразный рост времени обработки запросов.
G>>Там база с огромным запасом была.
AJD>Что подверждает тезис что твоя схема работает только при отсуствии сколько нибудь существенной нагрузки.
И что? Ты все равно не можешь предложить альтернативу.
Или предлагай свой вариант, который успешно отработает при несущественной нагрузке в 50 RPS на FE.

AJD>>>Понятно, что если клиент готов мириться с многосекундным ожиданием — это не проблема. Для других клиентов рост времени обработки с 10-15мс даже до 500мс будет не приемлемо.
G>>С чего будет такой рост? Ты сказки рассказываешь какие-то.
AJD>практика, она такая разная бывает.
То есть ты просто фантазируешь. В мире фантазий можно доказать или опровергнуть что угодно.

Здравствуйте, gandjustas, Вы писали:

AJD>>>>Тебе прийдется эти джобы и репликацию остановить.
G>>>Это одна транзакция, которая отрабатывает за долю секунды.
AJD>>Во-первых не долю секунды, а во вторых это влияет на функционал.
G>Что именно влияет?

Если ты отключил репликацию — у тебя изменился функционал

G>Да, топик был о том, что вертикальное масштабирование выгоднее горизонтального. На что коллега сказал, что при горизонтальном масштабировании можно сделать zero downtime и предложил такую проблему. Ты пишешь что нельзя это сделать без просадки производительности.
Я пишу что при вертикальном масштабировании просадка производительности недопустимо велика и выгоднее положить серевер, чтобы выкатить новую версию.

AJD>>Что подверждает тезис что твоя схема работает только при отсуствии сколько нибудь существенной нагрузки.
G>И что? Ты все равно не можешь предложить альтернативу.
Нет. Я не могу предложить альтернативу. Мне наоборот интересно как это сделать на существующей архитектуре. Просто предложеный подход добавиим тут на лету пару табличик и вюьх и все будет пучком плохо работает.

G>>>С чего будет такой рост? Ты сказки рассказываешь какие-то.
AJD>>практика, она такая разная бывает.
G>То есть ты просто фантазируешь. В мире фантазий можно доказать или опровергнуть что угодно.
Я смотрю на online графики выполнения запросов на продакшене и ежедневные performance отчеты. И когда возникают спайки всегда выясняется почему они возникли и что их вызвало.

Здравствуйте, AndrewJD, Вы писали:

AJD>Если ты отключил репликацию — у тебя изменился функционал
С чего ты взял что её надо отключать?
Еще раз повторю — у тебя будет один скрипт, который отключит, переименует, включит. Это займет меньше, чем интервал репликации.


G>>Да, топик был о том, что вертикальное масштабирование выгоднее горизонтального. На что коллега сказал, что при горизонтальном масштабировании можно сделать zero downtime и предложил такую проблему. Ты пишешь что нельзя это сделать без просадки производительности.
AJD>Я пишу что при вертикальном масштабировании просадка производительности недопустимо велика и выгоднее положить серевер, чтобы выкатить новую версию.
Это опять фантазии. Скорость работы можно сделать любую и нагрузку, соответственно, тоже.

AJD>>>Что подверждает тезис что твоя схема работает только при отсуствии сколько нибудь существенной нагрузки.
G>>И что? Ты все равно не можешь предложить альтернативу.
AJD>Нет. Я не могу предложить альтернативу. Мне наоборот интересно как это сделать на существующей архитектуре. Просто предложеный подход добавиим тут на лету пару табличик и вюьх и все будет пучком плохо работает.
Это снова фантазии или есть конкретные причины почему плохо?

Здравствуйте, Gattaka, Вы писали:
G>

G>    -- 1. Простовляем списку узлов новую роль
G>        update Network_Node
G>    set Property = true -- Некий признак, флаг, роль и т.п. не вдаемся в подробности. Нам пока не важно.
G>    where Id in (select Id from @selectedNodes) --В хранимку приходит список идентификаторов выбранных пользователем узлов - табличная переменная @selectedNodes

G>    -- 2. В соответсвии с бизнес логикой нужно найти связать сетевые узлы, которым мы проставили роль по связям зарегестрированных на них пользователей 
G>    --    
G>    insert Node_Node(Node1Id, Node2Id)
G>    select distinct n.Id, un2.NodeId
G>    from Network_Node n
G>    join UserOnNode un1 on un1.NodeId = n.Id     -- Берем пользователей зарегестрированных на узле
G>        join User_User uu on uu.User1Id = un1.UserId -- Берем связи пользователя
G>        join UserOnNode un2 on un1.UserId = uu.User2Id -- Берем узлы на котором зарегестрирован связанный пользователь
G>    where n.Property = true 
G>          and not exists(select * from Node_Node nn3 where nn3.Node1Id = n.Id and nn3.Node2Id = un2.NodeId) -- такая связь еще не сущетвует

G>

1. Запрос можно оптимизировать: у вас тут алгоритм Шлемиеля. Предположим, у меня Property=true у 34999 нод, и я передаю в @selectedNodes ровно одну ноду, причём у неё Property до этого было false.
Ваш запрос where n.Property = true найдёт 35000 нод, и начнёт шерстить полбазы. В то время, как достаточно просканировать только пользователей этой одной ноды:

    insert Node_Node(Node1Id, Node2Id)
    select distinct un1.NodeId, un2.NodeId
    from UserOnNode un1 
        join User_User uu on uu.User1Id = un1.UserId -- Берем связи пользователя
        join UserOnNode un2 on un1.UserId = uu.User2Id -- Берем узлы на котором зарегестрирован связанный пользователь
    where un1.NodeId in (select Id from @selectedNodes) -- избегаем лишнего сканирования индекса по Network_Node
          and not exists(select * from Node_Node nn3 where nn3.Node1Id = n.Id and nn3.Node2Id = un2.NodeId) -- такая связь еще не сущетвует

2. Архитектура выбрана не вполне удачно. Чую проблемы при установке property в false — так просто удалить записи из Node_Node не удастся, ведь вы хотели связать между собой все ноды, у которых есть хотя бы один пользователь ноды со свойством равным true. Т.е. там, где мы при "вставке" обошлись distinct, при удалении надо смотреть, нет ли других связей. Потенциально сканируя все 36GB.
3. А теперь собственно к главному: почему вы думаете, что хранимка — это единственный и правильный способ записать этот запрос? По мне так надо просто записать его в виде Linq выражения, возможно получив более понатный код.