Pull to refresh

Comments 36

Она располагает встроенной системой уведомления об изменениях, которая беспрерывно транслирует обновления для вашего приложения.
Которая неполноценна. Если у вас что-то произошло с коннектом между клиентом и ресинком, то вы не сможете потом продолжить фид с того места, где закончили. Они обещали реализовать возможность продолжить получение изменений по id фида. Давненько уже жду этой возможности.
Функция filter достаёт документы, которые соответствуют определённым параметрам.
И которая никогда не должна использоваться в продакшене, если вы ищете не по secondary index'ам. Лучше использовать getAll по индексам, где это возможно.
Кстати, в RethinkDB нету транзакций, что порой очень печалит.
UFO just landed and posted this here
А можно узнать о преимуществах над ArangoDB?
Вполне возможно автор до вашего комментария и не знал, что в мире есть еще, оказывается, ArangoDB. Я вот не знал. Если он действительно не знал, то как он вам расскажет о преимуществах?
Раз вас так интересует этот вопрос, почему бы вам в нем самому не разобраться и не запилить пост на хабру с обзором ArangoDB вообще и сравненем с RethinkDB в частности?
Может быть во встроенной системе уведомлений об изменениях?
Отличная база данных, рекомендую. Больше всего, по сравнению с остальными NoSQL базами радует наличие традиционных джоинов, легкое масштабирование, язык запросов гораздо приятнее SQL, и простота в настройке и обслуживании.
А вот рекламируемые в статье функции по уведомлению об изменениях, на мой взгляд, далеко не главное достоинство, скорее прилепили, чтобы было, а потом сделали на этой фиче маркетинговый акцент.
Не главное, но довольно приятное. У нас для некоторых вещей поверх RethinkDB настроен Redis. Без этих подписок получать изменения и обновлять данные в Редисе было бы весьма проблематично )
Хорошее решение. Но в ресинке мне больше всего нравится именно безболезненное масштабирование и более высокая надежность. Ну и еще джоины: не нужно городить огород, чтобы вытащить из базы с целью анализа необходимые данные, как в случае с более популярными бд.
Ну и если бы в ней не было обновлений, то такая же фича есть у редиса, да и не проблема настроить какое-нибудь другое решение, например, nsq.
Масштабирования по insert'ам нет. Попробуйте выжать неё больше 1000-2000 insert/sec и вы сильно удивитесь.
А какая настройка durability у вас? Если hard, то ничего удивительного, а вот если soft, то хотелось бы чуть подробнее узнать о вашей установке: вы пишете в один инстанс, или в разные?
Мы игрались с durability soft, hard, ssd, hdd, tmpfs. Результат один 1400 insert/sec не больше. Ядра использовать не умеет, нужно ручками стартовать несколько и объединять. Тестили на одном instance, на двух instance, объединенных в кластер. Результат — печалька, т.е. мы не получили прироста производительности при двух instance'ах (есть еще вероятность, что мы что-то неправильно настроили или как-то странно проверяли. З.ы. Мы даже не читали, просто писали. З.ы. на update'ы ситуация у него по-лучше). По ходу, оно хорошо масштабируется по ходу только на чтения и на update'ы. Кстати, даже на github были вопросы по производительности. Они подпиливают уже 2 версии как, уже гораздо лучше, было вообще 120 insert/sec.
Довольно странно, на самом деле. Если вы запускали кластер на нескольких независимых машинах, и писали поочередно то в один, то в другой инстанс, то это должно было бы увеличить производительность инсертов. Вы не написали, что именно таким образом пробовали делать.
Ну а так, да, особой производительностью rethinkdb не блещет, но я лично никогда и не рассматривал ее как замену mongodb.
В теории должно было увеличить. На практике у него есть какой-то лимит на скорость обработки insert'ов и не важно сколько нод в кластере, мы все-равно подключаемся к какому-то главному серверу и вот у него-то и затык.
P.s. Если кто-то имеет другой опыт было бы очень интересно посмотреть т.к. как раз из-за того, что rethinkdb не выдержала нагрузку на insert'ы пришлось смотреть в сторону message broker'ов.
Попробуйте описать вашу проблему более подробно в трекере, уверен, что команда проекта уделит этой проблеме внимание, мне было бы самому интересно узнать правильный ответ, почему так происходит.
А можете мне объяснить чем нотификации в PostgreSQL (http://www.postgresql.org/docs/9.4/static/libpq-notify.html) хуже нотификаций от NoSQL СУБД? Я когда-то работал с этим механизмом в связке nodejs + postgresql и не помню чтобы были с ним какие-то проблемы, поэтому меня и интересует заданный вопрос.
А можно немного подробнее? Какой сценарий использования и в каких ситуациях эта нотификация может помочь? Т.е. хочется услышать фитбек практического использования.
Сценарий был такой: есть «система» (бд и менеджмент), есть кучка клиентов, которые могут работать с заказами «заказами». Клиенты 2х типов: «заказчик» и «исполнители». исполнители разделяются на несколько групп, выполняющих свои обязанности и передающие результат работы следующему исполнителю или заказчику. Если заказчик создает заказ, то исполнитель 1го этапа получает обновление, делает что-то и переводит заказ в следующее состояние. Тогда заказ появляется у исполнителя 2го этапа и т.д. пока заказ не будет выполнен и вернется к заказчику. Весь процесс при этом можно отслеживать из менеджмента «системы» в реальном времени. Примерно такая система работала вполне адекватно, но не тестировалось при больших нагрузках (пока я там работал)
Посмотрел офдок, но возможно понял неправильно. Но я так понимаю, что у клиентов прямой коннект к РСУБД? В смысле, это какое десктоп приложение (Java? Qt?) которое может работать с базой?
Клиенты конектятся к nodejs через websocket. Nodejs получает обновления от postgresql и рассылает их тем, кто подписан. В postgresql стоят триггеры, которые срабатывают в определенных условиях и кидают NOTIFY.
Т.е. веб клиенты? Получается, что Nodejs держит постоянные коннекты к базе? Или все может происходить в рамках одного соединения?
Насколько помню там было одно или несколько постоянных соединений в nodejs, подписанных на нужные нотификации. Т.е. клиенты не создают свое соединение.
Это не точная информация т.к. не я реализовывал эту систему, только немного модифицировал, так что вглубь особо не залезал. Моя задача состояла в реализции веб-клиента.
Клиенты были и веб и мобильные (andoid), там по сути не важно откуда к nodejs присоединяться.
Объясню на пальцах. Есть два слушателя. Один слушает select * from table where price > 20. Другой слушает select * from table where price > 40.
Как работает rethinkdb:
Кто-то добавляет item с price 20 — никто не должен получить ничего.
21 — получает только первый (он получает полностью весь item, а не уведомление, что в этой таблице что-то поменялось)
41 — получают оба.
В случае notification'ов ты не можешь фильтровать какие ты получаешь а какие нет. В случае Postgres это просто именованый broadcast pipe. В случае rethinkdb она еще фильтрует за тебя.
Вот оно что. Спасибо. Получается что для postgresql для вашего примера нужно будет слать notify в 2 канала, реализуя notify в самой СУБД, а для rethinkdb можно просто подписаться на запросы и все в шоколаде.
В простых случаях для postgresql можно фильтрацию и на стороне получателя нотификации делать получая нужную информацию из payload.
Что-то типа «NOTIFY virtual, id;», но тут мы не получим сам item.
item можно получить используя row_to_json(record), но тут в случае необходимости фильтрации будет много лишней информации курсировать между БД и получателем. Может быть когда-нибудь и в postgresql улучшат нотификации =))
Я предпочту использовать олдскульный Постгрес. Даже если функциональности и экосистемы РесинкДБ сейчас достаточно, не известно, что понадобится через год.
Вот и я пока склоняюсь к использованию проверенных временем СУБД. В сложных системах они все-равно будут надежнее. К хорошему быстро привыкаешь, даже если оно периодически выбешивает =)
Меня не выбешивает, почему-то.

Надёжнее — да, при чём в разных аспектах.
Меня до сих пор иногда бесит своими очень «подробными» ошибками или странными результатами выполнения некоторых функций. Недавно бодался с невозможностью добавить в jsonb массив новый элемент в конец. Т.е. по сути простейшая операция, но пока не вышел 9.5 — это можно сделать только через собственную функцию, в которой, кстати, тоже пришлось пострадать т.к. все функции работающие с json возвращают set jsonb, а не jsonb[] или что-то более удобоваримое. Вся надежда на 9.5
Насчёт set — это, как говорится, вкусовщина. Моё мнение — там, где не нужен порядок, он не должен быть.

Насчёт jsonb — есть у меня подозрение, что он у Вас в БД не потому, что нужны были именно какие-то свойства json вроде слабой структурированности данных, а потому, что когда начинали делать систему, многое было не понятно. У меня для такого случая рецепт иного уровня — не нанимать программистов, пока у аналитиков/бизнесологов не будет понимания, чего они хотят, жетательно формализованного в тексте.

Другой вариант — нужен был силос json-ов, вот и взяли PGSQL, т.к. json-ы и так бегают по системе, и обрабатываются в бэкендовом коде именно как JSON-ы. Тоже отношусь к такому решению с подозрением, т.к. если энти самые JSON-ы приходят из веб-браузерного кода, то можно огрести много открытий чудных по части безопасности. А если не приходят из браузерного кода, то есть подозрение, что они не очень-то и нужны, и можно обойтись более жёсткими и классическими решениями.
Бизнес-аналитики… знали бы вы как у нас всё это оценивается и разрабатывается…
Конкретно в этом случае я использовал json т.к. не нужно держать эти данные в отдельной таблице — они по сути неотделимы от объекта в котором хранятся и не используются никак иначе, но при этом имеют свою структуру. С text[] или varchar[] я не хотел заморачиваться т.к. их нужно было бы парсить, а так json decode и все готово. Решение оказалось очень удобным, кстати. jsonb же выбрал т.к. в нем есть полезные операции вхождения, которые в теории могут пригодиться, но очень надеюсь что до этого не дойдет (жизнь — боль, готовься к худшему)
Про безопасность знаю, уже сталкивался. Есть уже проверенный набор валидаторов входящих данных для фильтрации значительной части попыток взлома. Самая живучая проблема — дефектные utf8 символы. Все никак не могу их качественно побороть =(
JSON я стараюсь использовать только там где он реально необходим или, в крайнем случае — для хранения данных, структуру которых не могу сейчас предсказать (жизнь — боль).
PGSQL же использую с версии 9.1 т.к. лучшего бесплатного в мире не существует + уже привык к его плюшкам.
Знаю, как оценивается и разрабатывается. Потому и не иду в начальники — один раз обжёгся.

Вы сами себе противоречите — данные не отделимы от объекта, при этом требуют дописывания в конец. «Рабинович, вы либо трусы оденьте, либо крестик снимите.» А подчинённую таблицу завести вера не позволяет?

На мой взгляд, если уж не выходит без json, то лучше каждый раз возвращаться к коду JSON<->SQL (это механическая работа), чем иметь непонятки с безопасностью и корректностью.

Структура данных должна следовать из постановки задачи. Да, я не очень удобный сотрудник: заставляю писать себе тикеты.
Нужно сохранять порядок добавления этих под-объектов и всё. Только поэтому добавление идет в конец. Наиболее близкий пример — одноуровневые комментарии к статье.
Боюсь, дорого Вашему работодателю может обойтись эта экономия на JSON-SQL преобразованиях. Честное слово.
Даже там, где нужны многоуровневые комментарии, PG предоставляет рекурсивный with.

Ну да, я олдскул. Обжёгшийся и ворчливый. :)
А вот дороговизна — это уже не моя проблема =) Не от хорошей жизни я такое делаю =)
Спасибо за перевод. Самая большая проблема RethinkDB на данный момент — это отсутствие драйверов. Официальные драйверы есть только для JS, Ruby и Python. То есть даже для JVM нет. А неофициальные драйверы, увы, в очень запущенном состоянии.
Sign up to leave a comment.

Articles