@Sannis19 авг 2010 в 13:36

Поддержка MySQL в Node.js: node-mysql-libmysqlclient

4 мин

16K

Node.JS *

+38

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

@sha1dy 19 авг 2010 в 13:40

Javascript

@silentroach 19 авг 2010 в 13:42

Наверное, пора открывать блог по node.js

@kurokikaze 19 авг 2010 в 13:46

Давно пора, но нет возможности.

@Sannis 19 авг 2010 в 14:01

У меня тут есть один пустой коллективный блог, возможно администрация ответит на мой e-mail по поводу переименования.

@iSlava 19 авг 2010 в 14:51

выглядит вкусно

@rilian 19 авг 2010 в 14:54

var conn = mysql_libmysqlclient.createConnection(host, user, password, database);

секьюрно ли в коде JS хранить настройки базы данных?

@Sannis 19 авг 2010 в 14:56

Да. Node.JS работает на серверной стороне, так что файлы скриптов не должны быть доступны из сети.

@Zibx 19 авг 2010 в 14:55

Может слить вместе две квери функции и определять асинхронность по наличию коллбэка в параметрах?

@Sannis 19 авг 2010 в 15:00

Скорее всего перейдём в следующей же версии к стандартному именованию, вместо query/queryAsync будет querySync/query. Мне пока кажется, что бывают случаи, когда коллбек не обязателен, а запрос можно выполнить асинхронно.

Пока ещё есть сомнения, что текущая реализация обёртки с мьютексами для запуска асинхронных запросов лучше, чем диспетчер с очередью запросов. Как только буду в этом уверен, будет v0.1.0 с зафиксированным API.

@Zibx 19 авг 2010 в 15:08

Таки можно оставить обе функции, а в первой сделать проверку параметра, и если он есть, то переход на вторую. Мне так кажется удобным, но решать в итоге, конечно, вам :)

@Sannis 19 авг 2010 в 15:16

Буду думать об этом :)

@brainfucker 19 авг 2010 в 15:43

Я за переименование… Всё блокрующее в Ноде стоит помечать окончанием Sync а не наоборот…

@Sannis 19 авг 2010 в 15:47

Можно считать это уже решённым.

@Zibx 19 авг 2010 в 15:56

Да, или такой вариант. Потому что меня смущало именно то что использоваться обычно будет функция с более длинным именем.

@Sannis 19 авг 2010 в 16:38

Правда тогда остаётся открытым вопрос именования остальных функций. Большинство утилитарных функций предполагается использовать при инициализации приложения и у меня нет планов делать их асинхронными. Например такие функции как conn.setCharset(), conn.setSsl() и т.д. Мне кажется не стоит всем им приписывать Sync, если асинхронная версия не предполагается. Кроме того, для result.fetchAll() собираюсь сделать асинхронную версию, а вот для остальных fetch* собираюсь оставить синхронными для тех, кто переходит на Node.JS с PHP/Perl.

@brainfucker 19 авг 2010 в 17:05

Стоит человеку переходящему с PHP/Perl не понимая того заюзать блокирующую функцию вне инициализации, как его проект начнёт дико медленно работать, и он будет во всю ругаться и кричать что Нода медленная, поэтому мне кажется Важно чётка Дать разработчику понять, что блокирует выполнение, а что нет.

@Sannis 19 авг 2010 в 17:09

Правильный аргумент. Чувствую грядёт массивная перетряска API.

@Sannis 19 авг 2010 в 18:56

Как же тогда существует в самой ноде такая вещь как fs.Stats? Я допуская правильность использования имён querySync, connectSync, но isConnectedSync (сейчас connected()) как-то не смотрится. Разве что делать её свойством, тогда оно будет использоваться только синхронно и вопрос именования снимается.

@akzhan 19 авг 2010 в 18:02

Однозначно требуется стандартное именование, когда синхронная версия имеет суффикс Sync, а все коллбэки имеют параметр err.

@ainu 20 авг 2010 в 06:42

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

НЛО прилетело и опубликовало эту надпись здесь

@Sannis 19 авг 2010 в 15:15

Обновил пример: gist.github.com/537870

Сам Node.js тестировали и много. Можно начать с записей разработчиков на этот счёт(http://four.livejournal.com/1018026.html, four.livejournal.com/1019177.html, four.livejournal.com/1020129.html, http://debuggable.com/posts/node_js:4ab4d9d7-b788-41d4-85c0-1b51cbdd56cb), за более поздними бенчмарками я не следил, но думаю качественно картина осталась такой же. Память течёт мало и всегда можно запустить GC. Что касается биндингов, то тут тестов по этой части мало.

@Sannis 19 авг 2010 в 15:20

Спасибо за замечание, в следующей версии обязательно расширю документацию, давно её не дописывал.

@saterenko 19 авг 2010 в 19:59

Первый тест который я написал — это простейший http-сервер и http-клиент. Клиент DOS-ил сервер запросами. На ноуте (старенький MacBook Pro) серверный скрипт откушал 43Мб, а клиентский 6Мб. Серверный кушал порядка 65% процессора, а клиентский порядка 35%. netstat показал 16390 сокетов на порту, на котором велись тесты. Тест выдал порядка 6000 запросов в сек. Я считаю, что это очень неплохой результат.

@ainu 20 авг 2010 в 06:43

11-12 000 одновременно подключенных держит.

@xryundel 19 авг 2010 в 15:12

А можете подробнее написать, каким образом реализована асинхронность?

@egorF 19 авг 2010 в 15:27

+1. Очень интересно, как это удалось сделать.

Автору — спасибо!

@brainfucker 19 авг 2010 в 15:38

Скорее всего каждый запрос в отдельном треде

@Sannis 19 авг 2010 в 15:48

Добавил раздел «Реализация асинхронности» в пост. Запросы выполняются в потоках на основе libeio, включённого в Node.JS.

@xryundel 19 авг 2010 в 16:06

Спасибо за ответ. Понятно. Что-то вроде этого и ожидал.

Да, к сожалению это не очень подходящий вариант, если к нам одновременно приходит достаточно много запросов, в каждом из которых нужно сходить в базу. Можно, конечно, создать пул коннектов к базе, чтобы можно было параллельно задавать несколько запросов к базе. Тогда получится что-то похожее на DBSlayer, только через DBSlayer можно контролировать общее количество коннектов к базе, а тут каждая клиентская программа будет решать, сколько ей нужно коннектов.

Простите за мысли вслух. Просто у самого есть сейчас похожая задача, только для Perl'а. И пока еще не решил, что в итоге использовать: то ли Coro::Mysql попробовать, то ли DBSlayer (с ним, правда, тоже есть определенные неудобства, например то, что его придется поднимать для каждой базы отдельно. И если база, например, шардированная, то для каждого шарда отдельно. Это не очень удобно в эксплуатации), то ли свою http-прослойку наподобие DBSlayer'а написать.