LINUX.ORG.RU

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

true_admin ★★★★★ ()

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

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

umren ★★★★★ ()
Ответ на: комментарий от umren

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

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

VictimOfLoveToLinux ()
Ответ на: комментарий от true_admin

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

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

xSudo ★★★ ()
Последнее исправление: xSudo (всего исправлений: 1)
Ответ на: комментарий от VictimOfLoveToLinux

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

umren ★★★★★ ()
Ответ на: комментарий от true_admin

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

anonymous ()
Ответ на: комментарий от true_admin

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

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

Dark_SavanT ★★★★★ ()
Последнее исправление: Dark_SavanT (всего исправлений: 1)
Ответ на: комментарий от Dark_SavanT

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

spoilt ★★ ()
Ответ на: комментарий от VictimOfLoveToLinux

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

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

VictimOfLoveToLinux ()
Ответ на: комментарий от Dark_SavanT

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

Shadow ★★★★★ ()
Ответ на: комментарий от Shadow

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

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

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

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

Shadow ★★★★★ ()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от Shadow

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

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

anonymous ()

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

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от Shadow

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от xSudo

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

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

quest ★★★★ ()
Ответ на: комментарий от quest

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

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

xSudo ★★★ ()
Ответ на: комментарий от xSudo

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

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

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

quest ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.