И, между прочим, у этого есть обоснование!) Заметьте, тут везде речь шла о статичных предметах. У котиков есть печальная особенность, которая немедленно поломает нам весь алгоритм — они двигаются и могут изменять форму. Тут нужно будет составлять не просто модель, а какой-то анимированый скелет, находя на видео составные сегменты котика — голова, сочленения лап и т.д.) В общем, квест намного усложняется.
Спасибо, что прочитали) Ну, обрабатывать хэштеги — тоже интересная штука, и что отдельно приятно, хорошо коммерциализируется (без иронии!). Немного грустно наблюдать, как к машинному обучению периодически относятся как к странной помести пятиногой табуретки и серебрянной пули — оно вроде как толком не работает, но дайте нам воткнуть его в фейсбук, и все френды ваши)
О, а поделитесь ссылкой, любопытно. Заранее можно, правда, подумать, что это не окончательное решение вопроса — микродвижения дают нам полезный параллакс, но чтобы составить полноценное 3d, нам все еще нужно «обойти» предмет и заглянуть «за него» с другой стороны) Эх, были бы у нас стебельчатые глаза, как неоднократно замечает тот же Марк Чангизи)
Ну, вдруг там в алгоритме этот ключ складывается с последовательностью из одноразового блокнота. Тогда см. пункт 1, от первичного ключа не будет никакого толку.
В общем основная идея в том, что в MongoDB ответственность за удаление связанных данных действительно ложится на приложение
То есть (если забыть о кейсе с цензурой) в общем случае у нас два выхода:
— делать пометку deleted. Минусы уже перечислены и вами, и мной: дисковое пространство, ненужная дупликация мусорных данных (в тех случаях, когда их никто не хочет восстанавливать), необходимость постоянно писать что-то типа db.tvshows.find({_id:1, $not: {deleted: true}}) для каждого запроса.
— удалять вручную на уровне приложения. Для определенного уровня связности это работает, но чем больше отношений, тем больше геморроя — шоу придется удалить не только у актеров (которых много), но и у режиссера, у связанных с ним мероприятий, удалить связанные обзоры, related_news, эпизоды и т.д.
И это, по-моему, основной вывод той самой статьи, которую вы разбираете, который там достаточно четко описан — как только у вас в монге возникают ссылки и отношения, то возможно, наступает момент задуматься, что вы используете неправильный инструмент. Потому что если ценность изкоробочного масштабирования для вас не превышает трудность прочтения мануала шардинга для постгреса, а любовь к JSON не застилает глаза вышеперечисленным трудностям, я не вижу больше других причин использования NoSQL там, где SQL отлично и незаметно для приложения справляется со ссылками.
Я, конечно, сам виноват, что так оформил пример, но хотелось бы получить какой-то общий ответ для тех случаев, когда удалять все-таки надо и для всех. Так все-таки «с каскадностью проблем абсолютно нет», или «вам придется всегда ставить при удалении атрибут deleted: true, делать проверки для каждого результата find и купить бесконечную СХД»?
Роскомнадзор FCC запретила у нас в стране последнее шоу Аарона Соркина как экстремистское и потребовало удалить его с сайта. Как убрать его из атрибута «shows» актера Джеффа Дэниелса и еще десятка людей из каста?
Я вас вполне правильно понял: ваши кейсы избегания удаления данных все относятся к пользовательскому контенту и делаются исходя из ценности данных. С этим все отлично, но есть ведь еще и исключительно сервисный контент, размещаемый со стороны админов и обслуживающих людей сервиса — новости, события, те же статьи про фильмы и сериалы на IMDB. Их совершенно незачем «помечать как удаленные», потому что это только зря потребляет небесконечное дисковое пространство — особенно когда данные большие. Из живых примеров — в нашем проекте, например, админы занимаются загрузкой на сайт архивов с GPS-данными, которые потом после парсинга могут занимать порядка ~100000 (достаточно связных) строк в базе. Часто возникают ошибки — из-за невнимательности и т.д. — когда приходится все удалить и залить заново. Оставлять данные в базе как «помеченные» как минимум нецелесообразно, потому что зачем?
А можно пример сервиса (модели данных/сущностей), для которого монго подходит лучше реляционных баз? Потому что логика защитников строится обычно как-то из разряда «хотите реляционность и транзакции — используйте инструменты, подходящие для этого». С утверждением-то самим по себе спорить трудно, но в чем преимущества монги и в каких юзкейсах отсутствие схемы дает больше плюшек, чем те самые транзакции и cascade?
Советы в духе «не можете удалить сериал — не удаляйте» тоже, конечно, радуют. Реальный кейс возможности удалить данные — это любая админка же.
Я не то чтобы забыл, просто пытаюсь задавать достаточно простые каверзные вопросы.
Мне кажется, что аргументация в духе «пока компьютер не научится плакать/любить/радоваться/испытывать боль, сознания у него не будет», довольна наивна сама по себе, а если под этим подразумевается просто наличие положительных/отрицательных фидбеков от окружающего мира, корректирующих работу алгоритма, то тут и спорить-то не с чем — этот принцип сто лет назад использовался, еще в перцептроне. Сделал ошибочный вывод — получил щелчок по носу от учителя и скорректировал себя на величину ошибки.
Хм, а поясните, ThreadPoolExecutor — это все-таки пул обычных потоков или каких-то асинхронных воркеров? Слабо понял из документации, и если все-таки второе, то не очень понятно, чем не устроил изначально такой же асинхронный торнадовский ioloop.
Про остальное — очень интересно, конечно, а возможность синхронно перехватывать исключения — это просто прекрасно, особенно после ада с Twisted, в котором это сделать невозможно (за редкими исключениями — упс), но как задумчиво и емко выражаются разработчики Джанго, «writing Web applications can be monotonous, because we repeat certain patterns again and again». Отсутствие батареек для каких-то самых простых в мире задач типа регистрации пользователей и необходимость писать все это вручную — суровый кирпич на шею Торнадо, по-моему. Интересно было бы посмотреть на примеры реального использования.
То есть (если забыть о кейсе с цензурой) в общем случае у нас два выхода:
— делать пометку deleted. Минусы уже перечислены и вами, и мной: дисковое пространство, ненужная дупликация мусорных данных (в тех случаях, когда их никто не хочет восстанавливать), необходимость постоянно писать что-то типа db.tvshows.find({_id:1, $not: {deleted: true}}) для каждого запроса.
— удалять вручную на уровне приложения. Для определенного уровня связности это работает, но чем больше отношений, тем больше геморроя — шоу придется удалить не только у актеров (которых много), но и у режиссера, у связанных с ним мероприятий, удалить связанные обзоры, related_news, эпизоды и т.д.
И это, по-моему, основной вывод той самой статьи, которую вы разбираете, который там достаточно четко описан — как только у вас в монге возникают ссылки и отношения, то возможно, наступает момент задуматься, что вы используете неправильный инструмент. Потому что если ценность изкоробочного масштабирования для вас не превышает трудность прочтения мануала шардинга для постгреса, а любовь к JSON не застилает глаза вышеперечисленным трудностям, я не вижу больше других причин использования NoSQL там, где SQL отлично и незаметно для приложения справляется со ссылками.
и актер
РоскомнадзорFCC запретила у нас в стране последнее шоу Аарона Соркина как экстремистское и потребовало удалить его с сайта. Как убрать его из атрибута «shows» актера Джеффа Дэниелса и еще десятка людей из каста?Советы в духе «не можете удалить сериал — не удаляйте» тоже, конечно, радуют. Реальный кейс возможности удалить данные — это любая админка же.
Мне кажется, что аргументация в духе «пока компьютер не научится плакать/любить/радоваться/испытывать боль, сознания у него не будет», довольна наивна сама по себе, а если под этим подразумевается просто наличие положительных/отрицательных фидбеков от окружающего мира, корректирующих работу алгоритма, то тут и спорить-то не с чем — этот принцип сто лет назад использовался, еще в перцептроне. Сделал ошибочный вывод — получил щелчок по носу от учителя и скорректировал себя на величину ошибки.
Про остальное — очень интересно, конечно, а возможность синхронно перехватывать исключения — это просто прекрасно, особенно после ада с Twisted, в котором это сделать невозможно (за редкими исключениями — упс), но как задумчиво и емко выражаются разработчики Джанго, «writing Web applications can be monotonous, because we repeat certain patterns again and again». Отсутствие батареек для каких-то самых простых в мире задач типа регистрации пользователей и необходимость писать все это вручную — суровый кирпич на шею Торнадо, по-моему. Интересно было бы посмотреть на примеры реального использования.