RethinkDB, у кого есть опыт использования?

https://aphyr.com/tags/RethinkDB

Да ну их нахрен эти nosql. Транзакций не умеют, реляционных отношений не имеют. После перехода с mysql на rethinkdb быстрее не стало. Я для себя бы взял постгресс.

А так, есть админка с графиками, настраивается просто...

И да, в презентациях у них было написано про транзакции. Не верь, в их понимании транзакция это атомарное изменения одной записи. В общем, если бы я внимательнее читал про это я бы не позволил юзать rethinkdb на проекте где нужна реляционная БД.

У нас, по итогу, всё те же джоины и плоские таблицы, только всё накодено руками и никаких гарантий целостности/консистентности/whatever. Разумеется, времени убито было немерено. Блин :(

так вроде на сайте прям писано, что это для рилтайм приложений, аля аналог firebase

вы ее в каком ключе рассматриваете то?

А реалтайм джоин у них есть?

вы ее в каком ключе рассматриваете то?

Конкретно в этом, много изменений в записях о которых надо моментально сообщать. +много чатов внутри структуры и большое количество информации в объектах которые так же надо править/оповещать на лету в режиме пользователя приложения.

Да ну их нахрен эти nosql

Ну за все nosql не стоит говорить. Redis к примеру умеет транзакции

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

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

Потому что там где нужен postgres, всякий nosql будет только вреден. И наоборот.

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

Всё верно. Но когда речь идёт о «типичном проекте» и нет понимания что будет в конце то кидаться в пучину nosql, имхо, глупо.

реалтайм джоин

Что это??

http://devzen.ru/episode-0076/

Да ну их нахрен эти nosql. Транзакций не умеют,

Чо?

Луркай СУБД Дніпро. Там и NoSQL, и транзации и куртизанки.

Окей, окей, я не прав сильно обобщая.

Так я не понял, в итоге вы на ней остались или ушли?

Остались, но я не доволен результатом — ящитаю что в сложном приложении должны быть транзакции чтобы база была в консистентном состоянии. Но нашему программисту норм. Пока у сервака аптайм 100% и приложение не падает всё будет хорошо :(.

Как убедить человека в том что всё плохо если всё работает? :)

Ну раз остались не всё так плохо, надо будет попробовать.

должны быть транзакции

Ну тут можно пофилософствовать.

Когда-то жители луны патчили mysql так, чтобы напрямую в/из таблицы потоком данные лить. Те «аналитики» такое не рассматривали?

А зачем так сложно? Как там сейчас уже не знаю, может что придумали.

А вообще, можно данные лить в подходящее хранилище, а потом вытаскивать уже спокойно для анализа куда-то там ещё, благо не в реалтайме молотить надо было.

Почему сложно, там прекрасное логохранилище для хостинга выходило. А если не в рилтайме, то чем sql с загрузкой из csv плох?

напрямую в/из таблицы потоком данные лить

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

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

Вот, нашёл:
http://yoshinorimatsunobu.blogspot.ru/2010/10/using-mysql-as-nosql-story-for....
Тесты:
http://philipzhong.blogspot.ru/2011/06/performance-test-for-mysql-sql-and.html

Видно, я ошибся - это только на отдачу.

Ты просто ни разу не инженер, а обычный кодер. Пора бы уже смириться с этим.

Во, ещё вспомнил, если интересно. У rethinkdb хорошие биндинги к различным ЯП благодаря чему программировать становится просто и интересно. Это не тот трэш и угар что у mongodb c его языком запросов в виде json.

Ну и всякие плюшки типа простая настройка шардинга прямо через админку.

PS только щас заметил что у тебя в тэгах «поток». Вот хз как оно в таком режиме работает и что у тебя за потоки.

Я спросил потому что мне интересно какое хранилище использовали. Если не озаботится этим вопросом и фигачить, скажем, в innodb, то всё это дико просядет из-за double write. Поэтому видел что народ фигачил тупо в myisam и всё работало сильно быстрее на таком сценарии. Или отключить этот double buffer: https://www.percona.com/blog/2006/08/04/innodb-double-write/

Вот и хотел узнать придумали ли что лучше.

Redis к примеру умеет транзакции

ROLLBACK правда делать не умеет)

Это уже детали)

Там Discard есть, по сути его хватает.

Я скорее про то, что нельзя безопасно залочить ключ из одного соединения и выполнять некие действия в монопольном режиме. Типа begin; select for update.

Есть команда setnx на основе которой можно лочить ключ но она не детектирует обрыв соединения. Можно конечно в активном потоке выставлять ключу TTL, но обрыв может быть между setnx и выставлением TTL, можно это обернуть в транзакцию, но и в дальнейшем при обновлении TTL может быть гонка.

Автору предлагали внести подобный функционал, есть даже не принятые патчи заинтересованных людей.