Выбор между SQL и NoSQL документооринтированной базой данных?

Question

[Andrei SunnyPh]

Задача, создание оптимальной архитектуры веб приложения для каталога разлчных объектов с гео привязкой, с возможностью фильтрации объектов по категориям, с текстовым поиском из описания объектов, с локальным поиском по удаленности от пользоателя. Фронтенд - NEXTJS, бекенд API ASP.NET с штатной ASP.NET Identity + PostgreSQL для учета пользователей. Проблема в том что гео объекты или точнее страницы о них, будут иметь неограниченное количество дополнтительных полей (свойств), но при этом поиск должен прводиться в одном пуле (наборе) объектов как по отдельным полям объектов так и по Geo. Какую базу данных выбрать для этого кроме PostgreSQL, это MongoDb или RavenDb или ...?

Comments

[Andrei SunnyPh]

«Пользователь удалён», ок уточню "количество дополнительных полей неопределено на данный момент".

[Ипатьев]

Andrei SunnyPh кстати да, рекомендую прислушаться к замечанию выше. И заранее ограничить набор, сразу запланировав отдельную базу данных для учета всех этих "неограниченных свойств". Иначе потом у вас будет так, как рассказывал Дерик лет 15 назад про OpenStreetMap - в одном месте туалет обозначается как WC, в другом - wc, в третьем Wc, в четвёртом lavatory, в пятом toilet, в шестом toilets... И тогда набор станет действительно бесконечным.

[Andrei SunnyPh]

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

[shurshur]

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

Геоданные хранить практически всегда оптимально в постгресе с постгисом. Там нужно немного повникать в то, как работают геопространственные индексы, чтобы их правильно использовать. Тогда даже на террабайтных таблицах оно будет довольно быстро искать по геоусловиям.

Выбор надо делать не потому что есть универсальный ответ или тысячи аналогичных приложений, за которыми нужно повторять. Выбор должен делаться на основе структуры и специфики своих данных, способа работы с ними, величине трафика, rps... И, конечно, своих возможностей. Помню, когда-то знакомый DBA долго решал вопрос, как построить по огромной таблице индекс таким образом, чтобы он поместился в террабайтный SSD (тогда такие ещё стоили очень дорого и просто купить второй не рассматривалось как опция). Так тоже бывает...

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

[Andrei SunnyPh]

Сделал API, реализовал хранение основных данных о сущностях в MongoDb, настроил гео индекс и полнотекстовый поиск локальных безнесов, а авторизацию сделал на PostgreSQL. Все корректно работает. Пока что вижу только плюсы от архитектруного решения - использовать MongoDb для хранения данных о локальных бизнесах. Сейчас, при создании нового экземпляра сущности локальный бизнес, есть только одно требование для входных данных: эти данные должны быть в виде валидного json документа. Плюс этого решения в том, что по мере разработки API, требования бизнеса о составе обязательных полей и необязательных полей с данными в объекте локального бизнеса, менялись не однократно. В коллекции бизнесов в MongoDb, сейчас вообще нет ссылок на данные из других коллекций, и постоянные изменения в требованиях к структуре данных, на уровне API, сейчас не вызывают никаких проблем. Оданко, что было бы, если использовалась PostgreSQL или иная SQL база данных? Как я это представляю, после каждой новой идеи со стороны бизнеса, нужно было бы создавать миграции, для добавления новых обязательных полей, или удаления старых полей и удаления объектов в других таблицах? Как решать проблему с гео данными, если по факту, в таблицу нужно добавлять данные о бизнесах без гео локации, но при этом для гео индексации, необходио чтобы даныне о локации, были бы обязательными для PostgreSQL? Ответов на эти вопросы у меня пока что нет... Для абсоллютной гибкости, в PostgreSQL нужно было бы, оставлять только id как обязательное поле, а все остальное, это один большой json объект, без ссылок на внешшние таблицы внутри? Ну если так сделать, то будет ли такая база данных являться SQL базой доанных, внутри PostgreSQL?

Answer 1

[Ипатьев]

Тут нет никакого выбора.

Первое, что надо понять - это что в "веб приложении", да ещё и с "архитектурой", должна быть база данных. Без неё просто не обойтись. А из всего перечисленного базой данных является только постргес.
(те, кто почему-то до сих пор не избавился от иллюзий, или просто стал жертвой незамысловатой рекламы, могут почитать, почему MongoDB базой данных не является).

Второе, что надо понимать - это что в нагруженных приложениях база данных никогда не используется одна сама по себе. Для выполнения различных дополнительных задач используются специализированные движки. Например

• кликхаус для аналитики
  
• редис для кэширования
  
• эластик для поиска
  
• сентри для логов
  
• и так далее - вариантов масса
  

Соответственно, если говорить про базу данных, то выбор очевиден - Постгрес.
Но если речь про поиск, то так и надо формулировать - "что использовать для поиска по базе данных?". И тут ответ тоже будет очевидный - Эластик (ну или любой другой поисковый движок - солр, мантикора, и так далее). Который и будет искать по информации, хранящейся в базе данных.

Но это только если у вас действительно веб-приложение. Если же у вас стильный энергичный молодёжный стартап, целью которого является проесть деньги инвестора, то Монго - а ещё лучше Равен - будет идеальным выбором. Это же мечта любого говнокодера маститого разработчика - не нужно корпеть над структурой базы данных, мучиться с внешними ключами, вдумчиво расставлять индексы - а просто валить всё в одну кучу!

Comments

[Andrei SunnyPh]

Похоже что у нас второй вариант "стильный молодежный" с минимальным бюджетом в пределах сэкономленных школьных завтраков, поэтому Эластики и прочие штуки здесь будут недоступны. Спасибо за ответ.

[Ипатьев]

В каком смысле "недоступны"? Некому прочитать документацию?
В любом случае, все перечисленные сервисы потому и называются дополнительными, что добавляются по мере необходимости и фактически нужны только под серьёзный объем данных и трафик.

[Andrei SunnyPh]

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

[Ипатьев]

Они все бесплатные. Веб - это мир open source, за редкими исключениями

[Saboteur]

MongoDB это именно база данных. Другой вопрос, что нужно уметь ею пользоваться.
Даже по вашей ссылке прямо написано что это база, просто не надо ею пользоваться.
При этом автор - пишет исключительно веб приложения, и просто описал случай, где монго реализовали неудачно
И бОльшая часть комментариев как раз о том, что автор статьи неправ. Они просто свою ошибку выбора базы данных перекрутили словно в этом mongodb виновата.

[Василий Банников]

Вообще если в термины упарываться, то ни одно из перечисленных базой данных не является.
pg, mongo, ravendb - это СУБД.
Постгрес - реляционная
монга и рейвен - документ-ориентированные
У обоих есть свои плюсы и минусы и в вакууме нельзя смело сказать, что из них "лучше".
Есть задачи, где чисто реляционная бд будет очевидно более удобная.
Есть задачи, где реляционная модель будет неудобной или неэффективной.

[Ипатьев]

Saboteur, во-первых, это не база, а свалка. Специализированный сервис для хранения мусора, который не может заменить БД, а только дополняет её - как и другие перечисленные выше.
Во-вторых, со времени появления Монги все базы данных научились хранить мусор самостоятельно, и надобность в отдельном сервисе отпала.
В-третьих, многие комментаторы действительно любят рассказывать, что "это просто неудачный кейс для монги" но при этом почему-то забывают привести пример "удачного кейса". Который, если всё-таки выдавить из них, сводится к специализированному хранилищу в дополнение к базе данных. Ну или к кейсу, который я описал в своём ответе.

[Ипатьев]

Василий Банников, правильно, если упарываться. Но вопрос был не про то, какое слово правильнее. А про БД для веб-приложения. И ответ на него совершенно очевиден, сколько ни жонглируй словами.

[Василий Банников]

Ипатьев, не очевиден.
Что вообще такое "веб приложение" в вашем понимании?

[Ипатьев]

Мы договорились не упарываться :)

[Василий Банников]

Ипатьев, ну просто лично я не вижу причин, почему в веб приложении не может использоваться какая-либо нереляционная модель.

[Saboteur]

Ипатьев, У меня полно рабочего кейса. Используем монгу на работе в десятках проектах, по 5-10 лет полет нормальный уже, и никаких проблем не видится.
У вас действительно неудачный кейс.

[Ипатьев]

И снова опять, "у нас есть кейс, но мы вам его не скажем!" :-D

Answer 2

[Василий Банников]

В postgres можно искать по геоиндексам при помощи postgis.
Для текстового поиска по описанию в постгресе есть полнотекстовый поиск.
Произвольные поля можно добавить через колонку с jsonb.

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

Comments

[Andrei SunnyPh]

Спасибо, буду думать над этим.