Серверный JS

[x-yuri]

Но в каких случаях, лучше использовать mySql или например MongoBD

это следует из того, что я сказал. Если тебе важна целостность данных, выбирай реляционные БД. Можешь еще почитать, что пишут на сайте mongodb

[vflash]

mySql или например MongoBD

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

в MongoBD нехватало функционала, потому приходилось извращаться. код представлял из себя адовую смесь перла+js+json+монги. мапредьюс там тормазной и не полностью реализован, редьюс делается на мастере. с индексами там тоже проблемы, составные индексы както странно себя вели и в итоге стали использовать индекс по одному полю. кстати индексы задаются хешом а не массивом тоесть {name: 1, age: 1} , это непривычно странно, так как стандарт js не гарантирует последовательность параметров в хеше.

в MongoBD много магии, сырой и довольно странный API .

[x-yuri]

возможно неподходящая задача или неподходящая реализация, все же mongodb - нереляционная БД и как бывает с ЯП, можно по инерции неправильно ее использовать.

мапредьюс там тормазной

а где не тормозной и есть опыт работы с другими подобными БД?

[Gvozd]

Потому что очень сложно PHP-шные мозги (без всякого негатива термин) перестроить на асинхронный JavaScript.

Не у всех так =)
PHP для меня основной язык программирования, что не мешает мне извращаться на нем в асинхронном стиле, причем успешно.

О Node.Js:
что мне нравится в этой модели, кроме асинхронной обработки, и ништяками производительности в связи с этим, так это то, что процесс имеет глобальную область, позволяющую эффективно кешировать куски кода, и результаты функций, и использовать при генерации многих страниц.
В стандартной же модели web-а, процесс отвечает за отрисовку только одной страницы, и кешировать может только вовне. Это всегда медленней, чем глобальный объект кеша в рамках процесса.

Надо украсть идею, и написать свой Node.PHP =)))

[Kolyaj]

Надо украсть идею, и написать свой Node.PHP =)))

А fast-cgi это не то?
Если нет, то какое-то другое решение есть, но вроде PHP там безбожно течёт, т.к. не приспособлен под такое.

[vflash]

x-yuri, когда речь о MongoBD так всегда и говорят. не та задача и не так готовите.

мапредьюс должен распределяться по кластеру. а у них свертка делается на мастере.

[Gvozd]

А fast-cgi это не то?

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

Никаких переменных между запросами не перекидывается, и каждый из них начинает с чистого листа.

Если нет, то какое-то другое решение есть, но вроде PHP там безбожно течёт, т.к. не приспособлен под такое.

Возможно есть.
Но, я не знаю о каком решении вы говорите, и если вы не вспомните название, то обсудить точно не получится.

[Kolyaj]

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

Не, я всё-таки думал о fast-cgi. Понял, что не то.

[Андрей Параничев]

Я импользую mongodb, но у меня не будет увеличения объема данных, а самые оперируемые данные кешируются в memcached.

[x-yuri]

x-yuri, когда речь о MongoBD так всегда и говорят. не та задача и не так готовите.

а ты можешь предложить альтернативу? Или думаешь, что эта идея вообще тупиковая? Я вот про CouchDB думаю...