Как там Postgress после Mongodb и в частности в node.js?

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

После того, как в постгресе запилили JSON, монго стало ненужно.

можно ли там сделать хранилище картинок (файлы до 2 мб),

Да

хотелось бы хотя бы часть полей хранить в JSON и не мудиться постоянно с правкой схем. Можно ли будет делать композитные индексы и включать в них поля из JSON?

Да есть JSON/JSONB, компрессия тоже есть С nginx разницы не должно быть, или ты используешь какой-то специальный модуль к nginx для этого?

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

Меня интересовал стриминг, чтобы не отжиралась память на полный размер файла при передаче. Видел, что в постгресе есть поддержка больших объектов, но не разобрался насколько удобно ей пользоваться без собственных лисапедов.

есть ли прозрачная компрессия (хранится много текстовых сообщений)

да.

и компрессия ключей для JSON?

словаря для ключей json нет. на днях был на выступлении Олега Бартунова и Александра Короткова, обещают сделать. такчто размер ключа имеет значение.

насколько нормальный драйвер под node.js

у меня все работает.

насколько там нормальный полнотекстный поиск (русская морфология)

я не пробовал, но думаю русская морфология работает тк авторы теже ). говорили что в 9.5/9.6 сильно ускорили, и есть задел для еще большего ускорения.

хотелось бы хотя бы часть полей хранить в JSON и не мудиться постоянно с правкой схем. Можно ли будет делать композитные индексы и включать в них поля из JSON?

да

можно ли там сделать хранилище картинок (файлы до 2 мб), с раздачей стримами (не одним куском), а лучше вообще напрямую в nginx?

Ну храни блобы и раздавай на здоровье. Напрямую в nginx не знаю, вряд ли можно.

насколько там нормальный полнотекстный поиск (русская морфология), если сравнивать со sphinx search?

Полнотекстовый поиск есть, русская морфология есть. Насколько нормальный, не знаю, вроде ищет.

хотелось бы хотя бы часть полей хранить в JSON и не мудиться постоянно с правкой схем. Можно ли будет делать композитные индексы и включать в них поля из JSON?

Делать индексы по JSON-полям можно. Думаю, можно и составные индексы делать.

есть ли прозрачная компрессия (хранится много текстовых сообщений) и компрессия ключей для JSON?

Компрессия текстовых полей есть, работает автоматом для длинных строк. Насчёт компрессии для JSON не знаю, но он как-то бинарно хранит, вроде тоже должен экономно хранить.

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

https://www.nginx.com/resources/wiki/modules/slice/

не?

Ну храни блобы и раздавай на здоровье. Напрямую в nginx не знаю, вряд ли можно.

А сохранялку и раздавалку кто делать будет :) ? Под монгу есть готовая (gridfs), и драйверы под ноду тоже.

Полнотекстовый поиск есть, русская морфология есть. Насколько нормальный, не знаю, вроде ищет.

AOT есть для восстановления базовой словоформы или там все стеммером гвоздится?

Ранкеры релевантности тюнятся?

«как-то» искать можно, но не интересно (хотя очень многим хватает).

у меня все работает.

А что конкретно работает? Интересует DSL для запросов и какая-то описалка «моделей».

Модели у меня только на запись - так проще. А на чтение только DSL, чтобы не тупило. В монгузе это решается через .lean(true).

А сохранялку и раздавалку кто делать будет :) ? Под монгу есть готовая (gridfs), и драйверы под ноду тоже.

Может чего не понимаю, на жаве это 10 строчек кода. Делаешь селект, получаешь объект блоба, получаешь stream и кусками вычитывавешь его и шлёшь в ответный поток. Если это прям важный момент и запрашиваются более-менее одинаковые файлы, я бы сделал кеш на файловой системе (можно смонтированной в ram) и при запросе сохранял бы туда ответ и потом nginx-а просил его отдавать через специальный заголовок в ответе.

AOT есть для восстановления базовой словоформы или там все стеммером гвоздится?

Ранкеры релевантности тюнятся?

Может кто умней ответит, я не очень в теме. Поиск там достаточно простой, если тебе нужна куча наворотов, вероятно тебе нужен какой-нибудь Lucene.

Может чего не понимаю, на жаве это 10 строчек кода. Делаешь селект, получаешь объект блоба, получаешь stream и кусками вычитывавешь его и шлёшь в ответный поток.

Ну я-то не совсем на яве, и еще спрашивал как с этим делом в node.js.

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

Если надо ставить внешний поиск, то причин сваливать на постгрес становится резко меньше. Sphinx search я и к монге могу прикрутить.

Судя по всему то, что тебе нужно: https://github.com/brianc/node-pg-cursor
Нет, скорей всего без костылей нельзя.

Тогда помучаюсь на монге еще :).

У node_postgress еще и dsl стремноватый.

А что конкретно работает? Интересует DSL для запросов и какая-то описалка «моделей».

Я с миром ноды не знаком, поэтому мне стало интересно. Какой DSL помимо SQL может быть нужен? Какие задачи решает?

Более симпатичная нотация запросов + эскейпинг. Собственно, как и любой другой DSL.

Симпатичная — это состоящая из конструкций целевого языка (JS в данном случае)?

Наверное можно и так сказать. Отмотай вот тут пониже http://mongoosejs.com/docs/queries.html, там есть пример где через точку набрано много условий. Устоявшийся подход, в рубях так же.

Плюс иногда надо запрос из нескольких частей составить. Клеить строки ручками какой-то фиговый вариант.

Разве не это называют словом ORM?

Нет. ORM делает всякую магию с содержимым объектов, а DSL только сахар для запросов. То что конкретно монгуз можно гонять в обоих режимах, к терминологии не относится.

ORM делает всякую магию с содержимым объектов, а DSL только сахар для запросов.

я понимаю на монге, но на постгресе это кмк не нужно, там же SQL мощнейший, если его осилить конечно. особенно клево с этими DSL, ORM, ActiveRecord, etc. когда написано что-то большое и нетривиальное, и тут из-за много данных оно встало колом и надо план прибить гвоздями или побыстому структуру базы поменять, а не грепнуть исходники нифига ).

Плюс иногда надо запрос из нескольких частей составить. Клеить строки ручками какой-то фиговый вариант.

приведи пример pls.

Понял, спасибо. В целом, у меня есть основания для критики такого подхода применительно к реляционным СУБД, но это уже тема иного обсуждения, так что тут флудить не буду.

Разве не это называют словом ORM?

ORM — вообще адское изобретение. Штука, которая предназначена для преодоления object-relational impedance mismatch (т. е. переходник по сути), зачастую содержит логики и магии чуть ли не больше, чем разрабатываемое приложение.

Например фильтрация результатов по условиям юзера.

Не надо меня пожалуйста агитировать за программирование на сиквеле. Я знаю что это можно и знаю как. Но мне это не интересно. Список того что мне важно есть в первом посте.

Это в конечном счете вопрос конкретных задач и личных предпочтений.

Попробуй относиться к этому как к DSL для запросов, более плотно напичканному логикой :)

Ещё и какой-никакой слой абстракции от диалекта языка запросов в подарок.

есть еще knex и поверх него bookshelf, если надо (всё от tgriesser на гитхабе), но стриминга там нет, насколько я понял

но я что-то пилил-пилил пол-года на ноде, но так и свалил на джаву с хибернейтом, когда очередной рефакторинг джаваскриптового кода силами ide не вышло сделать.

Так-то, может, и выстрелило бы, но мегабайты кода, которые невозможно отрефакторить автоматически, меня угнетают. (ide, если что, идея, не какой-то там notepad.exe)