MySQL или PostgreSQL при геозапросах?

Question

[E N]

Перед стартом проекта стоит выбор технологий а конкретнее базы данных.
В проекте будут присутствовать геозапросы, то есть система определяет местоположение пользователя и ранжирует выдачу таким образом чтобы сверху были товары, от поставщиков из радиуса 100 км.
Так-же планируется настраивать поиск таким образом чтобы товар с артикулом "H-DRS-50V-UI310" находится по запросам:
HDRS-50V-UI310, H-DRS50V-UI310 и тд.
Программист настаивает на MySQL так -как он с ней всегда работал и она удобна при несложных запросах.
Я (заказчик), почитав просторы интернета склоняюсь к PostgreSQL так-как она уже имеет PostGIS для геозапросов, имеет полнотекстовой поиск, ну и вообще она серьезнее мускуля по моему мнению.
Проект будет не маленьким: около миллиона товаров, порядка трех миллионов товарных предложений по данным товарам от разных поставщиков. Различный сортировки по характеристикам, производителям и тд. Автоматический подбор аналогов. Анализ синтаксиса названий товаров в категории для автоматического определения нового товара в нужную категорию и прочие плюшки.
Конечно можно на MySQL начать, но не встанет ли потом вопрос о переходе на PostgreSQL?
Или в приказном порядке сказать чтоб разработка велась на PostgreSQL?
Или мускуль все это потянет без проблем ?

Comments

[Dmitry Bay]

ГИС функции и индексы есть и в mysql.
Писать программисту лучше на том, в чем он разбирается.

Answer 1

[Fixid]

PostgreSQL + PostGis (на этой связке работает OSM, очень быстрая и надежная система)
С MySQL всегда можно перейти на PostgreSQL, но обратно уже сложнее. Особенно если используются фичи PostgreSQL.
Лучше начинать сразу с PostgreSQL

Comments

[Pan Propan]

Плюсую. Был опыт работы со связкой Postgres + Postgis.
Легко разворачивается + шустро работает даже на слабом железе.

Answer 2

[sim3x]

Голосую за постгрес

Или в приказном порядке сказать чтоб разработка велась на PostgreSQL?

приказывать придется, только если на мускул завяжитесь

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

средний, до верней планки среднего еще очень далеко

полнотекстовой поиск

для такого требуется интегрировать shinxsearch

Различный сортировки по характеристикам, производителям и тд.

зависит от структуры БД

Автоматический подбор аналогов

не зависит от СУБД, нужно писать свое решение или втупую добавлять руками

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

не относится к СУБД совсем, отдельное решение, с большой долей ручной работы (в начале)
Проще/дешевле тыкать в поставщиков палочкой и заставлять их формировать прайсы с одинаковыми SKU

Comments

[E N]

"для такого требуется интегрировать shinxsearch" - ниже рекомендовали elasticsearch, по вашему мнению сфинкс имеет преимущества?

[sim3x]

EVGENIJ NEFEDOV, да

https://vimeo.com/151817227
https://www.youtube.com/watch?v=gJXWqkf6CX8

[E N]

"Проще/дешевле тыкать в поставщиков палочкой и заставлять их формировать прайсы с одинаковыми SKU" - если бы все так просто было, нам придется сводить одинаковые товары но с разным описанием и даже отличающимися артикулами, так как кто-то дифис в артикуле не поставит, у кого-то ексель первый ноль удалит и тд. Но на первом этапе только мы заинтересованы в сборе наибольшего количества информации от поставщиков, вот когда сервис наберет критическую массу пользователей то поставщики тогда и начнут подстраиваться сами.

[sim3x]

EVGENIJ NEFEDOV, стандартизация - благо
Тыкать - нужно

Answer 3

[CityCat4]

Однозначно постгрес.
Мускл рассчитан на небольшие и скоростные базы, его задача - максимально быстро выдать данные из (относительно) небольшой и (относительно) простой по структуре БД. Ну, по крайней мере так было задумано изначально. Мускл быстр.
Постгрес изначально рассчитан на серьезные проекты, с серьезными БД - этакий опенсорсный оракл. Но в задачах, где мускл летает как птичка божия, постгрес может ворочатся как свой аватар - слон :) Это плата за серьезность.

Но в вашем случае выбора в общем-то нет :) на миллионе записей мускл просто ляжет :)

Comments

[E N]

Скорость работы очень важна, меня всегда удивляло, почему в больших и не очень проектах (от 100т страниц) отклик больше секунды а поиск и того дольше, может потому-что они используют постгрес? На моем сайте 60т товаров, 1т категорий и 500 свойств и отклик 0,15мс. Ради теста заливал базу проекта на свой сайт а это на данный момент: 900т товаров, 2000 категорий и 7000 свойст и отклик стал 0,25мс. Есть ли риск что на постгрес отклик перевалит за секунду?

[CityCat4]

EVGENIJ NEFEDOV, Критерий истины - практика :) Я бы сделал тестовую установку, близкую по обьему к реальности на одной и на другой БД, причем не исключено что придется достаточно долго читать маны по оптимизации на тему того, какие параметры движка и как подкрутить.

Answer 4

[Andrey Shatokhin]

ИМХО лучше под вашу задачу подойдет elasticsearch. Но ни как основная БД, а как индексы для фильтраций по параметрам и бустинга( сложному ранжированию) по частичному совпадению и расстоянию.

Comments

[E N]

Спасибо за совет, получается Laravel+MySQL+elasticsearch и можно не использовать PostgreSQL ?
Еще вот что интересно:
Есть задача, автоматически определять новый товар в нужную категорию, по идее поисковик может проиндексировать наименования товаров в категории и исходя из релевантности определить товар в нужную категорию, это реально?

[Andrey Shatokhin]

EVGENIJ NEFEDOV, Да. Если у вас индексы для гео в elasticsearch то бд значения не имеет.

Подбирать категорию по названию? Это очень сложно. Я б тут какую нить нейронку использовал. Полнотекстового поиска тут точно не хватит. А нейронку можно дообучать в процессе.

[E N]

Андрей, нейронки ещё являются разрядом фантастики в разработке, все о них говорят но крайне мало чтоб кто-то сделал. Допустим в категории 1000 товаров, названия этих товаров проиндексировать как одну массу и определять товар в категорию по алгоритму bm25. Вроде так он называется.