Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
Она располагает встроенной системой уведомления об изменениях, которая беспрерывно транслирует обновления для вашего приложения.Которая неполноценна. Если у вас что-то произошло с коннектом между клиентом и ресинком, то вы не сможете потом продолжить фид с того места, где закончили. Они обещали реализовать возможность продолжить получение изменений по id фида. Давненько уже жду этой возможности.
Функция filter достаёт документы, которые соответствуют определённым параметрам.И которая никогда не должна использоваться в продакшене, если вы ищете не по secondary index'ам. Лучше использовать getAll по индексам, где это возможно.
Кстати, в RethinkDB нету транзакций, что порой очень печалит.
Ну, шардинг есть. Что конкретно хотите узнать? )
А можно узнать о преимуществах над ArangoDB?
Вполне возможно автор до вашего комментария и не знал, что в мире есть еще, оказывается, ArangoDB. Я вот не знал. Если он действительно не знал, то как он вам расскажет о преимуществах?
Раз вас так интересует этот вопрос, почему бы вам в нем самому не разобраться и не запилить пост на хабру с обзором ArangoDB вообще и сравненем с RethinkDB в частности?
Раз вас так интересует этот вопрос, почему бы вам в нем самому не разобраться и не запилить пост на хабру с обзором ArangoDB вообще и сравненем с RethinkDB в частности?
Может быть во встроенной системе уведомлений об изменениях?
Отличная база данных, рекомендую. Больше всего, по сравнению с остальными NoSQL базами радует наличие традиционных джоинов, легкое масштабирование, язык запросов гораздо приятнее SQL, и простота в настройке и обслуживании.
А вот рекламируемые в статье функции по уведомлению об изменениях, на мой взгляд, далеко не главное достоинство, скорее прилепили, чтобы было, а потом сделали на этой фиче маркетинговый акцент.
А вот рекламируемые в статье функции по уведомлению об изменениях, на мой взгляд, далеко не главное достоинство, скорее прилепили, чтобы было, а потом сделали на этой фиче маркетинговый акцент.
Не главное, но довольно приятное. У нас для некоторых вещей поверх RethinkDB настроен Redis. Без этих подписок получать изменения и обновлять данные в Редисе было бы весьма проблематично )
Хорошее решение. Но в ресинке мне больше всего нравится именно безболезненное масштабирование и более высокая надежность. Ну и еще джоины: не нужно городить огород, чтобы вытащить из базы с целью анализа необходимые данные, как в случае с более популярными бд.
Ну и если бы в ней не было обновлений, то такая же фича есть у редиса, да и не проблема настроить какое-нибудь другое решение, например, nsq.
Ну и если бы в ней не было обновлений, то такая же фича есть у редиса, да и не проблема настроить какое-нибудь другое решение, например, 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.
Ну а так, да, особой производительностью rethinkdb не блещет, но я лично никогда и не рассматривал ее как замену mongodb.
В теории должно было увеличить. На практике у него есть какой-то лимит на скорость обработки insert'ов и не важно сколько нод в кластере, мы все-равно подключаемся к какому-то главному серверу и вот у него-то и затык.
P.s. Если кто-то имеет другой опыт было бы очень интересно посмотреть т.к. как раз из-за того, что rethinkdb не выдержала нагрузку на insert'ы пришлось смотреть в сторону message broker'ов.
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 присоединяться.
Это не точная информация т.к. не я реализовывал эту систему, только немного модифицировал, так что вглубь особо не залезал. Моя задача состояла в реализции веб-клиента.
Клиенты были и веб и мобильные (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 она еще фильтрует за тебя.
Как работает 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 улучшат нотификации =))
В простых случаях для 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-ы приходят из веб-браузерного кода, то можно огрести много открытий чудных по части безопасности. А если не приходят из браузерного кода, то есть подозрение, что они не очень-то и нужны, и можно обойтись более жёсткими и классическими решениями.
Насчёт jsonb — есть у меня подозрение, что он у Вас в БД не потому, что нужны были именно какие-то свойства json вроде слабой структурированности данных, а потому, что когда начинали делать систему, многое было не понятно. У меня для такого случая рецепт иного уровня — не нанимать программистов, пока у аналитиков/бизнесологов не будет понимания, чего они хотят, жетательно формализованного в тексте.
Другой вариант — нужен был силос json-ов, вот и взяли PGSQL, т.к. json-ы и так бегают по системе, и обрабатываются в бэкендовом коде именно как JSON-ы. Тоже отношусь к такому решению с подозрением, т.к. если энти самые JSON-ы приходят из веб-браузерного кода, то можно огрести много открытий чудных по части безопасности. А если не приходят из браузерного кода, то есть подозрение, что они не очень-то и нужны, и можно обойтись более жёсткими и классическими решениями.
Бизнес-аналитики… знали бы вы как у нас всё это оценивается и разрабатывается…
Конкретно в этом случае я использовал json т.к. не нужно держать эти данные в отдельной таблице — они по сути неотделимы от объекта в котором хранятся и не используются никак иначе, но при этом имеют свою структуру. С text[] или varchar[] я не хотел заморачиваться т.к. их нужно было бы парсить, а так json decode и все готово. Решение оказалось очень удобным, кстати. jsonb же выбрал т.к. в нем есть полезные операции вхождения, которые в теории могут пригодиться, но очень надеюсь что до этого не дойдет (жизнь — боль, готовься к худшему)
Про безопасность знаю, уже сталкивался. Есть уже проверенный набор валидаторов входящих данных для фильтрации значительной части попыток взлома. Самая живучая проблема — дефектные utf8 символы. Все никак не могу их качественно побороть =(
JSON я стараюсь использовать только там где он реально необходим или, в крайнем случае — для хранения данных, структуру которых не могу сейчас предсказать (жизнь — боль).
PGSQL же использую с версии 9.1 т.к. лучшего бесплатного в мире не существует + уже привык к его плюшкам.
Конкретно в этом случае я использовал json т.к. не нужно держать эти данные в отдельной таблице — они по сути неотделимы от объекта в котором хранятся и не используются никак иначе, но при этом имеют свою структуру. С text[] или varchar[] я не хотел заморачиваться т.к. их нужно было бы парсить, а так json decode и все готово. Решение оказалось очень удобным, кстати. jsonb же выбрал т.к. в нем есть полезные операции вхождения, которые в теории могут пригодиться, но очень надеюсь что до этого не дойдет (жизнь — боль, готовься к худшему)
Про безопасность знаю, уже сталкивался. Есть уже проверенный набор валидаторов входящих данных для фильтрации значительной части попыток взлома. Самая живучая проблема — дефектные utf8 символы. Все никак не могу их качественно побороть =(
JSON я стараюсь использовать только там где он реально необходим или, в крайнем случае — для хранения данных, структуру которых не могу сейчас предсказать (жизнь — боль).
PGSQL же использую с версии 9.1 т.к. лучшего бесплатного в мире не существует + уже привык к его плюшкам.
Знаю, как оценивается и разрабатывается. Потому и не иду в начальники — один раз обжёгся.
Вы сами себе противоречите — данные не отделимы от объекта, при этом требуют дописывания в конец. «Рабинович, вы либо трусы оденьте, либо крестик снимите.» А подчинённую таблицу завести вера не позволяет?
На мой взгляд, если уж не выходит без json, то лучше каждый раз возвращаться к коду JSON<->SQL (это механическая работа), чем иметь непонятки с безопасностью и корректностью.
Структура данных должна следовать из постановки задачи. Да, я не очень удобный сотрудник: заставляю писать себе тикеты.
Вы сами себе противоречите — данные не отделимы от объекта, при этом требуют дописывания в конец. «Рабинович, вы либо трусы оденьте, либо крестик снимите.» А подчинённую таблицу завести вера не позволяет?
На мой взгляд, если уж не выходит без json, то лучше каждый раз возвращаться к коду JSON<->SQL (это механическая работа), чем иметь непонятки с безопасностью и корректностью.
Структура данных должна следовать из постановки задачи. Да, я не очень удобный сотрудник: заставляю писать себе тикеты.
Нужно сохранять порядок добавления этих под-объектов и всё. Только поэтому добавление идет в конец. Наиболее близкий пример — одноуровневые комментарии к статье.
Спасибо за перевод. Самая большая проблема RethinkDB на данный момент — это отсутствие драйверов. Официальные драйверы есть только для JS, Ruby и Python. То есть даже для JVM нет. А неофициальные драйверы, увы, в очень запущенном состоянии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Строим real-time веб-приложения с RethinkDB