По крайней мере русскоязычного легального + популярного.
Там, как я погляжу, любой пользователь льет что пожелает и никто его особо не контролирует.
Я же говорю о нормальных контент-провайдерах, которые работают только с легальным контентом. Ни ВКонтакте, ни SoundCloud этим похвастаться не могут. Вы просто переносите ответственность с пользователя вКонтакте на пользователя SoundCloud, что общей картины не меняет.
Вообще набор факторов для прослушивания одного трека тут конечно избыточен: ВКонтакте + десктопная программа + SoundCloud.
У гугл музыки тут гораздо все красивше конечно в этом плане.
«Приобрели классный трек в Google Play? Поделитесь им с друзьями в Google+, и первое прослушивание будет для них бесплатным. А композиции, которые они дадут послушать вам, будут храниться в плейлисте Поделились со мной.»
Вопрос только в контент провайдерах, которые одобрят кэширование своего контента (если контент предоставляется по подписке, то подразумевается, что пользователь может получать к нему доступ только в течении определенного времени). А без кэширования эта фишка уже не такая интересная получится.
>> Поскольку программа (скрипт) предоставляется им
Что-то вы меня запутали )
Так программа не одна общая, а у каждого контент-провайдера своя? Я то думал что программа ваша — а контент-провайдеров в неё подключает уже сам пользователь.
Т.е. получается, вы предлагает некое решение для контент-провайдера, выходит?
1. Парсинг контента браузера
2. Подмена определенных тэгов на медиа-контент из базы контент провайдера (или локального диска, если файл уже закеширован)
Т.е. тот же iframe от Ютуба, но с универсальным синтаксисом и фичей кеширования на диск?
Соответственно распространение этого приложения — уже забота контент провайдера?
Это далеко не стимул.
Не видно привлекательности проекта для потребителя.
Зачем пользователю:
1. Качать программу
2. Добавлять в неё список своих контент провайдеров и логины пароли от них
3. Потом публиковать где-то тэги,
4. Чтобы они преобразовались программой в список «выберите контент провайдера» (своего же)
5. И только потом слушать (свой же) трек?
Ведь он может просто:
1. Выбрать любого своего контент провайдера
2. Слушать этот же трек через сервис, предоставляемый контент провайдером (а заодно пользоваться дополнительными его преимуществами)
Боюсь вас огорчить, но сейчас никто не оборачивает название фильма в тэг video, когда его обсуждает.
К этому и вопрос, как вы собираетесь стимулировать людей (держателей сайтов, блогов и т.п.) каждый раз проделывать эту дополнительную работу (оборачивать названия в тэги)?
Однако для потребителя ваше приложение будет сомнительно.
К тому же вам нужно будет поднимать огромный пулл сайтов, которые будут предоставлять такую возможность (оборачивать название трэков в специальные тэги), чтобы хоть как-то оправдать наличие этой программы у пользователя. Как вы планируете стимулировать их рост?
«На нашем сайте нет музыки, только названия песен, но вы может скачать это приложение (ссылка, ссылка, ссылка) установить его (ссылка на инструкцию по установке) и тогда наконец сможете послушать музыку!»
Не проще пользователю открыть любой другой сайт, где не надо ничего скачивать?
Технически как это реализовать планируется?
Например поиск по файлам на локальной машине пользователя? Это же огромная дыра в безопасности (кто гарантирует, что приложение ищет только музыку, а не вытягивает куки, например?)
Согласен. Но транзакции — нужны только при «релятивистском» подходе в проектировании.
Также согласен и с тем что тут сравнение действительно слишком общее и неполноценное.
Есть идея создать два абсолютно одинаковых (по доступной функциональности) проекта, но сделать различие в логике построения — один будет использовать Монго, а второй PostgreSQL со всеми вытекающими (транзакции, джойны и т.д.).
А потом прогнать какой-нибудь siege и/или ab. Тут и многопоточность и приближение к «боевым» условиям (те же блокировки, к примеру).
Во-первых, никто не продолжает вставку в фоне. Write concern (далее будем называет его просто w) только определяет уровни оповещения об ошибках записи. Если операция завершена, значит она завершена. А вот нужно ли сообщать об ошибках в процессе операции — это уже другой вопрос.
Во-вторых, w по умолчанию выставлен не в -1 (Errors Ignored), и даже не в 0 (Unacknowledged), а в 1 (Acknowledged). Прибавим к этому еще и включенное по умолчанию журналирование (аналог полюбившегося здешними комментаторами fsync), мы получаем следующую картину:
Полагаю, что этого более чем достаточно, чтобы сравнение «коробочного» MongoDB с «коробочным» же PostgreSQL имело место быть.
Печально, что большинство пользователей просто как «по-заученному» твердят про какие-то fsync=off, репликацию, отсутствие у монги getLastError, нестабильности этой СУБД и т.п. совершенно не пытаясь проверить актуальность своих познаний.
UPD: К сожалению тэги не сработали, пришлось вставить просто ссылками.
Тут всего лишь сказано что с репликацией обеспечивается большая надежность.
В случае с PostgreSQL всё то же самое. Или вы хотите сказать, что использование репликаций в PostgreSQL — бесполезное занятие? Для чего тогда ему эта функциональность?
Уверен что большинство мелких и средних (что греха таить, и часть крупных) проектов в сети работают с СУБД «из коробки», т.е. с теми настройками какие заложил по умолчанию производитель. Учитывая этот фактор, сравнение коробочных версий весьма корректно. Не зря в статье написано что это весьма поверхностное тестирование. Но буду весьма рад, если вы сможете «разогнать» PostgreSQL (без ущерба стабильности системы) и выложить более глубокий анализ его максимальной производительности.
Что же до классов задач — это не совсем так. Одну и ту же задачу можно решить разными способами. Тот же Foursquare вполне же можно было написать и с использованием реляционных БД, согласитесь? )
Я специально под тест не поднимал виртуалку. Была использована готовая удаленная машина. Что на ней стояло, то и тестировалось. MongoDB тоже, можно заметить, не самая последняя. Так уж сложилось, но не думаю, что это настолько критично.
По крайней мере русскоязычного легального + популярного.
Там, как я погляжу, любой пользователь льет что пожелает и никто его особо не контролирует.
Я же говорю о нормальных контент-провайдерах, которые работают только с легальным контентом. Ни ВКонтакте, ни SoundCloud этим похвастаться не могут. Вы просто переносите ответственность с пользователя вКонтакте на пользователя SoundCloud, что общей картины не меняет.
Вообще набор факторов для прослушивания одного трека тут конечно избыточен: ВКонтакте + десктопная программа + SoundCloud.
У гугл музыки тут гораздо все красивше конечно в этом плане.
Например: support.google.com/googleplay/answer/1751113?hl=ru&ref_topic=2450401
Ну и у любого контент-провайдера примерно то же самое.
P.S. Ну а вообще все уже давно придумано: play.google.com/intl/ALL_ru/about/music/ :)
обратите внимание на:
«Приобрели классный трек в Google Play? Поделитесь им с друзьями в Google+, и первое прослушивание будет для них бесплатным. А композиции, которые они дадут послушать вам, будут храниться в плейлисте Поделились со мной.»
Вопрос только в контент провайдерах, которые одобрят кэширование своего контента (если контент предоставляется по подписке, то подразумевается, что пользователь может получать к нему доступ только в течении определенного времени). А без кэширования эта фишка уже не такая интересная получится.
Что-то вы меня запутали )
Так программа не одна общая, а у каждого контент-провайдера своя? Я то думал что программа ваша — а контент-провайдеров в неё подключает уже сам пользователь.
Т.е. получается, вы предлагает некое решение для контент-провайдера, выходит?
1. Парсинг контента браузера
2. Подмена определенных тэгов на медиа-контент из базы контент провайдера (или локального диска, если файл уже закеширован)
Т.е. тот же iframe от Ютуба, но с универсальным синтаксисом и фичей кеширования на диск?
Соответственно распространение этого приложения — уже забота контент провайдера?
Не видно привлекательности проекта для потребителя.
Зачем пользователю:
1. Качать программу
2. Добавлять в неё список своих контент провайдеров и логины пароли от них
3. Потом публиковать где-то тэги,
4. Чтобы они преобразовались программой в список «выберите контент провайдера» (своего же)
5. И только потом слушать (свой же) трек?
Ведь он может просто:
1. Выбрать любого своего контент провайдера
2. Слушать этот же трек через сервис, предоставляемый контент провайдером (а заодно пользоваться дополнительными его преимуществами)
К этому и вопрос, как вы собираетесь стимулировать людей (держателей сайтов, блогов и т.п.) каждый раз проделывать эту дополнительную работу (оборачивать названия в тэги)?
{video} Blender Foundation — Sintel {/ video}
Без вашей программы у них нет смысла существовать. Без них — нет смысла существовать вашей программе. Такой вот взаимный deadlock получается.
К тому же вам нужно будет поднимать огромный пулл сайтов, которые будут предоставлять такую возможность (оборачивать название трэков в специальные тэги), чтобы хоть как-то оправдать наличие этой программы у пользователя. Как вы планируете стимулировать их рост?
«На нашем сайте нет музыки, только названия песен, но вы может скачать это приложение (ссылка, ссылка, ссылка) установить его (ссылка на инструкцию по установке) и тогда наконец сможете послушать музыку!»
Не проще пользователю открыть любой другой сайт, где не надо ничего скачивать?
Например поиск по файлам на локальной машине пользователя? Это же огромная дыра в безопасности (кто гарантирует, что приложение ищет только музыку, а не вытягивает куки, например?)
Так что «неприятные вещи» есть везде. Вопрос уже не в самой СУБД, а в проектировании таких образом чтобы снизить вероятность этих «неприятных вещей».
Также согласен и с тем что тут сравнение действительно слишком общее и неполноценное.
Есть идея создать два абсолютно одинаковых (по доступной функциональности) проекта, но сделать различие в логике построения — один будет использовать Монго, а второй PostgreSQL со всеми вытекающими (транзакции, джойны и т.д.).
А потом прогнать какой-нибудь siege и/или ab. Тут и многопоточность и приближение к «боевым» условиям (те же блокировки, к примеру).
Хотя не знаю, стоит ли игра свеч…
Во-первых, никто не продолжает вставку в фоне. Write concern (далее будем называет его просто w) только определяет уровни оповещения об ошибках записи. Если операция завершена, значит она завершена. А вот нужно ли сообщать об ошибках в процессе операции — это уже другой вопрос.
Во-вторых, w по умолчанию выставлен не в -1 (Errors Ignored), и даже не в 0 (Unacknowledged), а в 1 (Acknowledged). Прибавим к этому еще и включенное по умолчанию журналирование (аналог полюбившегося здешними комментаторами fsync), мы получаем следующую картину:
docs.mongodb.org/manual/_images/crud-write-concern-journal.png
Полагаю, что этого более чем достаточно, чтобы сравнение «коробочного» MongoDB с «коробочным» же PostgreSQL имело место быть.
Печально, что большинство пользователей просто как «по-заученному» твердят про какие-то fsync=off, репликацию, отсутствие у монги getLastError, нестабильности этой СУБД и т.п. совершенно не пытаясь проверить актуальность своих познаний.
UPD: К сожалению тэги не сработали, пришлось вставить просто ссылками.
В случае с PostgreSQL всё то же самое. Или вы хотите сказать, что использование репликаций в PostgreSQL — бесполезное занятие? Для чего тогда ему эта функциональность?
Пруфлинк, пожалуйста. Интересно откуда этот слух пошел.
Что же до классов задач — это не совсем так. Одну и ту же задачу можно решить разными способами. Тот же Foursquare вполне же можно было написать и с использованием реляционных БД, согласитесь? )