PostgreSQL или MySQL для работы с json данными?

Question

[Владислав Шкаев]

Делаю сайт с музыкой, с ajax загрузкой плей листов, текстовым поиском и разными сортировками.
Никак не могу определится с бд, NoSQL(MongoDB), MySQL, PostgreSQL.
Пока ка что думаю о PostgreSQL так как ее можно использовать как NoSQL, никогда не работал с ней, прочитав массу статей так и не понял, можно ли хранить аудио фалы и получать их с базы в виде json формата, а точнее целесообразно это вообще.
Не вижу смысла получать данные с бд в виде php-массива и сериализовать их в json для работы с ними.
Собственно сам вопрос, можно ли на PostgreSQL хранить записи тысячи аудио фалов в виде json массива как в NoSQL, да бы потом получить их в виде json-массива или хранить их как в реляционной бд но получать в виде json-массива.
И какие проблемы могут быть с поиском, и сортировками.

Собственно задача получать из базы json а не php-массив, и что б по времени это не вышло больше чем на уровне приложения сериализовать php-массив в json.

Может вообще не целесообразно хранить в виде json, и проще сериализовать на уровне приложения php-массив в json?

Answer 1

[Оптимус Пьян]

В postgre вроде с версии 9.4 есть поиск по json а в mysql даже поля нормального для него нет. По-моему ответ тут очевиден.

Comments

[un1t]

Как ни странно, но у постгреса по сравнению с мускулом, есть не только плюсы, но и минусы. Вот например чуваки из убера предпочли мускул https://eng.uber.com/mysql-migration/

[entermix]

dev.mysql.com/doc/refman/5.7/en/json.html

[Оптимус Пьян]

entermix: да, но у меня 5.5 и даже не 5.6 ))

Answer 2

[un1t]

Хранить аудио-файлы в json формате в БД. Да вы, батенька, эстет.
Без разницы мускул это или постгрес, это плохая идея.

Comments

[un1t]

Владислав Шкаев: ну это уже лучше, а зачем json?

[Владислав Шкаев]

Имелось в виду информацию о файлах

[Владислав Шкаев]

ибо ajax, по сети передаваться будет json, ну объяснил же все)

[un1t]

Владислав Шкаев: а чем таблицы не подходят?

[un1t]

un1t: ну обычно для этого есть всякие сериализаторы. Таблицу сериализовать в json не проблема. Для популярных фреймоврков я думаю должны быть такие инструменты.

[Владислав Шкаев]

un1t: тем что json_encode тоже занимает ресурсы

[un1t]

Владислав Шкаев: кажется ты занимаешься преждевременной оптимизацией.

[entermix]

Владислав Шкаев: в таких случаях кэшируют результат работы

[Владислав Шкаев]

Это не так просто, когда есть кучу выборок сортировок

[un1t]

Владислав Шкаев: нужно выбирать связанные таблицы? ИМХО используй, что лучше знаешь или что больше нравится.

[Владислав Шкаев]

un1t: так я хотел понять вообще можно работать с PostgreSQL как key-value хранилище, без импользования json_encode в дальнейшем

[un1t]

Владислав Шкаев: ну это тебе надо php-шный дрвайвер для постгреса/мускула смотреть или код ORM который ты используешь, чтобы понять как оно работает с JSON полем. Но пока я что-то не очень понимаю твою проблему. Какое количество запросов в секунду у тебя будет, что json_encode является узким местом?

[Владислав Шкаев]

un1t: Запросы ничтожные.. не больше 1000 в день юников, в секунд может быть запроса 3) может я и заморачиваюсь.. проект может быть расти, и как бы потом не было проблем с масштабируемостью, и охото сделать как логичнее, а не как все). Мало ajax сайтов, и мало кто задумывается что напрямую дергать json логичнее. Работал с MongoDB+node от туда и идея сразу тащить json, если есть варианты почему бы нет

[un1t]

Владислав Шкаев: при такой нагрузке и даже потенциальном росте лучше выбирать что удобнее и надежнее. Оптимизировать узкие места имеет смысл только после профилирования.