nefedovgeka
@nefedovgeka
Мыслю в ширь, нужны те, кто мыслит в глубь.

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

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

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

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

полнотекстовой поиск
для такого требуется интегрировать shinxsearch
Различный сортировки по характеристикам, производителям и тд.
зависит от структуры БД
Автоматический подбор аналогов
не зависит от СУБД, нужно писать свое решение или втупую добавлять руками
Анализ синтаксиса названий товаров в категории для автоматического определения нового товара в нужную категорию и прочие плюшки.
не относится к СУБД совсем, отдельное решение, с большой долей ручной работы (в начале)
Проще/дешевле тыкать в поставщиков палочкой и заставлять их формировать прайсы с одинаковыми SKU
Ответ написан
CityCat4
@CityCat4
Кошки не похожи на людей, кошки - это кошки!
Однозначно постгрес.
Мускл рассчитан на небольшие и скоростные базы, его задача - максимально быстро выдать данные из (относительно) небольшой и (относительно) простой по структуре БД. Ну, по крайней мере так было задумано изначально. Мускл быстр.
Постгрес изначально рассчитан на серьезные проекты, с серьезными БД - этакий опенсорсный оракл. Но в задачах, где мускл летает как птичка божия, постгрес может ворочатся как свой аватар - слон :) Это плата за серьезность.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы