Как стать автором
Обновить

Комментарии 28

Оракл бы прикрутили…
Вот было бы в масть.
вот уж точно:)
Лично мне для полного счастья не хватает только асинхронных С++ биндингов к mySQL. Есть написанные на JS но это не самое быстрое решение…
Могу сказать, что заниматься асинхронностью в MySQL начну уже на будущей неделе :) Как только допишу всё связанное с fetchResult.
Конкретный список неблокирующих функций можно обсудить в вики на гитхабе.
Собственно говоря нативные функции работают в 6-10 раз быстрее, чем то что написано на JS, сегодня тестил.

Довольно интересно получается, в PHP было нормальным долгое формирование ответа на основе шаблонов, тогда как скомпилированные шаблоны в NodeJS сильно уменьшают процентную долю этих операций.
ещё бы… в пхп это дело парсилось интерпритатором при каждом обращении, а в некоторых шаблонизаторах (таких как xtemplate) ещё и регулярками при каждом обращении…

А node выплювывает из оперативки, с молниеносной скоростью шаблон со всеми данными, а кеш можно выносить на аболютно новый уровень… мне очень нравится такой подход =)
В рассылке node.js предлагали использовать вместо limysql библиотеку libdrizzle, в которой реализована родная асинхронность.

drizzle.org/ — форк mysql, но я не уверен, что drizzle ещё совместим по протоколу с mysql.
Судя по официальным материалам, libdrizzle поддерживает и будет поддерживать сервера MySQL, начиная с версии сервера 4.1.

www.mysqlconf.com/mysql2009/public/schedule/detail/6658
Ryan в последний раз говорил про библиотеку mysac. Кроме того он вроде бы сам что-то писал, но не выкладывал кода. Планируется включить этот драйвер в поставку node, так что делать двойную работу не очень хочется. Я спросил на днях в рассылке, пока что реакции не было. Так что пока разбираюсь с libeio.
>неблокирующую
И даже на запись? Ведь в sqlite3, насколько мне известно, невозможна одновременная запись.
Почитал ссылку. Очевидно имеется ввиду неблокирование работы трэдов приложения при обращении к БД.
Неблокируемость здесь описана с точки зрения машины событий.

Цикл событий получает контроль обратно сразу же, и когда-нибудь позже произойдёт событие «Запись произведена успешно».
Если посмотреть readme, используется SQLite в синхронном режиме в отдельном потоке.

Асинхронный родной режим SQLite не используется в связи с отсутствием необходимых коллбэков, впрочем, не вижу смысла пересказывать readme :)
Это только для v8?
Код привязан к V8, так как используется прослойка на C++.
Прослойку я видел. Осталось понять, для чего это надо
Вариантов много.

Например, у нас используются приложения стека Ruby/EventMachine/SQLLite.

Можно будет перенести их на платформу node.js, избавившись от проблем EventMachine.
да да. сюда бы ещё native client присобачить. вот будет песня.
1. Во-первых, этот клиент использует SQL Lite C API. Не знаю, что можно найти роднее :)
2. Во-вторых, Javascript в V8 компилируется в родной машкод. что гарантирует очень хорошую производительность.

Так что вашего комментария я не понял :)
NaCl гарантирует ещё более хорошую производительность.
Вы имеете ввиду это — en.wikipedia.org/wiki/Google_Native_Client?
node.js никаким образом не пересекается с этой технологией.

node.js написан на C++, и компилируется в родной код, что обеспечивает скорость выше, чем скорость NaCl.

И в качестве языка для написания приложений используется Javascript, который понятен для любого Web-разработчика.
NaCl позволить запускать как гарантированно нэйтивный код, так и интерпретаторы для всех остальных языков портированных в него, например ruby и php.
Но он же по определению медленнее родного кода.

Почитайте Wiki, там внедрена программная изоляция кода, что обеспечивает скорость «лишь немного ниже» родной.

NaCl вообще предназначен для Web-браузеров, а не для серверов.

На серверах мы запускаем доверенный код, и лишние затраты на изоляцию излишни.
V8 тоже как-то не для серверов изначально разрабатывался.
Затраты на изоляцию там ничтожно меньше потерь на обеспечение динамической природы js.
Писать Web-приложения на C++ вряд ли будут многие.

Скорее всего на динамических языках, наподобие Ruby или Javascript.

Javascript/NaCl вряд ли будет по тем же соображениям быстрее Javascript/V8.

Но Вы правы в том, что V8 изначально создавался не для серверов.
Вероятно, Вы имели ввиду создание клиента SQL Lite 3 под платформу NaCl.

Думаю, это не нужно. Работа с базами данных более правильно вынести на уровень склеивающего кода, то есть Javascript, тем более, что HTML5 Storage и Google Gears уже давно определёны.
> SQL Lite
это что за самодеятельность? =_="
Что-то взгляд мозолило, а что, — понять не мог. Спасибо :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории