Друзья мои, где вы увидели в вопросе просьбу сделать что то за меня? Ткните носом. В своем посте я вижу только вопрос: какие технологии лучше использовать для задачи с приведенными требованиями?
Дело в том, что записей может быть много и для них могут быть дополнительные условия. То есть, например, получить только одну ветку - Account 1 со всеми 3-мя уровнями. Тогда все записи брать неэффективно.
Да. Но также не исключается вариант формирования дерева в самом коде программы. То есть хочу получить все записи дерева небольшим количеством запросов (желательно одним).
Реальное проседание гарантировано появится под нагрузкой, потому что скорость обработки запросов при большом количестве SELECT'ов упрется в жесткий диск. Я знаю, что современные ОС могут кэшировать файлы в оперативку. Но с другой стороны хочется научиться самому явно задавать, что нужно кэшировать, а что нет.
>> перед связкой асинхронный сервер + любой язык - не совсем понятно, что Вы имеете в виду.
Здесь имеется ввиду сервер, который работает в асинхронном режиме (nginx, lighttpd и т. д.), который стоит перед приложением, написанным на любом языке без использования асинхронности.
>> Nodejs имеет один существенный недостаток - у неё один процесс выполнения. По этому тяжелые вычисления на ней значительно уступают в производительности PHP на многопроцессорных/ядерных системах. (это дело легко обходится воркерами итп, но это еще один недостаток)
erlang, java и несколько других языков не имеют вышеуказанной проблемы.
Процесс выполнения может и один, но воркеров может быть несколько, поэтому все ядра процессора можно загрузить равномерно и производительность у этих языков на примере тяжелых вычислений может быть примерно равная.
>> 1. в ноде можно хранить данные, таймеры, дескрипторы итп между запросами. По этому это намного эффективнее различных механизмов кэширования PHP.
Ну это понятно, но такой подход может ухудшить масштабирование (для HTTP), но в некоторых случаях может быть полезным.
И по поводу вашего последнего абзаца. То ли вы неправильно поняли то, что я написал, то ли не совсем правильно понимаете асинхронность. Может быть несколько рабочих потоков, а не один, как вы пишите, и в единый момент времени действительно обрабатывается столько запросов, сколько есть рабочих потоков.
Когда запрос выполняется 100 миллисекунд, то рабочий процесс (или worker, рабочий поток) БД не выполняет других запросов вообще, пока не закончит текущий.
Понятно. С одной стороны вы правы, но с другой, все не так оптимистично. Если БД принимает тяжелый запрос, на который нужно, скажем, 100 миллисекунд, то она не сможет выполнять другие запросы на протяжении этого времени. То есть если на сервере БД 4 ядра, то за 100 миллисекунд БД сможет выполнить 4 таких тяжелых запроса. В этом случае выигрыша от асинхронного приложения не будет, так как БД очень узкое место. Но я не знаю, часто ли бывают на практике такие тяжелые запросы.