Для сайта каталога ресторанов какую базу данных можно выбрать?
Приветствую! Подскажите, если я хочу сделать сайт с карточками заведений (рестораны), у которых будут стандартные атрибуты (я думаю вы представляете какие: название, адрес, телефон, и тд..), и потом можно делать поиск по всей базе заведений с различными фильтрами (то-есть нужно будет делать выборки из базы данных) то какую базу данных оптимально выбрать? Например NoSQL для таких данных можно выбрать?
Я просто честно говоря не понимаю, что имеется ввиду, когда MYSQL рекомендуют аргументируя выбор тем "если вам требуется сохранность и целостность данных". А что, в MongoDB или Cassandra эта сохранность может нарушится?
Скорее всего я просто неправильно сформулировал вопрос. Думаю я хотел понять, в каких случаях какая база данных подходит лучше, и, в качестве примера, привел свой проект. Потому что я не могу понять саму цель изобретения NоSQL баз данных. Также я не могу понять главный тезис в пользу SQL баз данных о "целостности и сохранности данных". В NoSQL данные что ли периодически могут теряться или портиться и, там где они применяются, это не вредит приложению??
Максим,
Целостность это вообще не о том. Во всех базах естественно есть проверка целостности, бэкапы и так далее.
База подходит лучше та, с которой вы умеете работать, которую вам проще поднять и настроить, которая дешевле обойдется по лицензии/использованию.
Оптимизировать выбор базы нужно тогда, когда у вас не хватает производительности.
NOSQL базы обрели популярность именно по той причине, что в крупных проектах, где важна скорость работы, для некоторых специфических типов данных было проще работать не в sql.
Сейчас, когда nosql баз появилось много и разных, можно их использовать чисто по удобству.
Но в вашем случае - освойте работу с SQL базами на хорошем уверенном уровне. Тогда будет проще понимать разницу.
чтоб это понять надо почитать о nosql в целом, и о их конкретных видах в частности (их есть много разных).
чтоб понять "целостность данных" нужно почитать об ACID (и наличии или отсутствии оного в конкретной nosql-базе).
если пробовать объяснить на пальцах:
рсубд - отлично заходят когда есть структурированный набор данных и между ними можно строить связи.
nosql - отлично заходит когда данные вообще никак не связаны, но их нужно хранить (обычно это разнообразные кэши) или данные слабо структурированы/не имеют единой структуры.
Вы натыкаете в фильтрах что вам нужно по тэгам, и выберите что вам нужно по местам. Кстати сильно быстрее.
А мусор в виде json можно хранить и в реляционной базе. Некоторые даже позволяют запросы делать
Вопрос как-то странно звучит. А почему надо выбирать "MongoDB или Cassandra" если задача, аналогичная вашей решалась 100500 тысяч раз и в основном на SQL, которые к тому же именно для подобных задач (поиск в хорошо структурированном массиве информаии) и придумывались?
Приведите хоть один пример, когда средств, мощностей и других возможностей даже MySQL не хватит для вашей задачи?
Как человек, который строил точно такую систему в продавшее скажу что реляционная база данных не справляется при таком диком количестве атрибутов, которые появляются чуть ли не ежедневно)
Скорее всего я просто неправильно сформулировал вопрос. Думаю я хотел понять, в каких случаях какая база данных подходит лучше, и, в качестве примера, привел свой проект. Потому что я не могу понять саму цель изобретения NоSQL баз данных. Также я не могу понять главный тезис в пользу SQL баз данных о "целостности и сохранности данных". В NoSQL данные что ли периодически могут теряться или портиться и, там где они применяются, это не вредит приложению??
Иван Шумов, А приведите, пожалуйста, несколько НОВЫХ атрибутов, появляющихся ежедневно.
И еще - сколько-же у вас было атрибутов для описания ресторана?
Нет, ну я понимаю - Google, Amazom, eBay. Но база ресторанов - скорее всего одного города или региона??? Почти фиксированная схема данных (там ТС сам написал: "я думаю вы представляете какие: название, адрес, телефон, и тд..". Больше нескольких сотен атрибутов я бы не придумал, даже если бы меня пытали. Ну тысяч - если еще и ингредиенты отдельных блюд меню туда включить.
Очень интересно получить такую информацию от практика.
dmshar, я подписывал NDA) Но в целом могу сказать что в данном домене требуется детализированная проработка особенностей заведений по тому что пользовательские запросы в консультационную службу непредсказуемы, но необходимо угодить всем. Меню это отдельный ад с 100500 вариантов борща, но я про меню не говорил - это не атрибут заведения.
Вообще при таком количестве заведений даже на один мегаполис поддерживать актуальную базу очень сложно и когда вы только отработали одну фичу так появляется следующая, + смена сезонов + тренды + различные точечные события. В общем много чего.
На этом рынке уже есть сильные игроки за счет того что они образовались уже давно, но зайти на этот рынок еще можно будет, если подготовить платформу к окончанию пандемии
Иван Шумов, понятия может и нет, но для меня "стандартные атрибуты" равно "определенный набор атрибутов", а не "атрибуты добавляются произвольно по тысяче в секунду".
Иван Шумов, А все-таки, хотелось бы хоть один пример на каждое из слагаемых: когда вы только отработали одну фичу так появляется следующая, + смена сезонов + тренды + различные точечные события.
Очень хотелось бы понять, откуда беруться фичи для такой базы данных. Пока ничего "непредвиденного" не видно. И "сезоны" и "события" - вполне предсказуемы.
То, что фичи добавляются - это понятно, но по моему мнению - ну как минимум в этом приложении - это недоработка архитектора на этапе проектирования. Впрочем, задача добавления параметров, как и проблема "разряженности" - вполне решаемые современными SQL-базами.
А вот "постоянного потока новых фичей" - придумать хоть убейте не могу. Ладно eBay - там изначально не известно, что люди могут напридумывать продавать и какие описания каких параметров дадут в каждом конкретном случае. Но вот "сайт с карточками заведений"?? Ну даже в "поисковой системе по ресторанам"? Ну разве что "мастер-краснодеревщик изготовивший мебель для третьего столика" или "фото висящее в правом дальнем углу около туалета" - и то, это должна быть "очень консультационная" система. Но ведь не о такой системе идет речь. Вот и хотелось бы услышать мнение практика - а вдруг завтра придется такую систему проектировать.
Иван Шумов, Ну тогда скорее всего у вас полнотекстовая база данных с поиском по введенному описанию. Но это мягко говоря не совсем то, что в вопросе ТС. И надо-ли ему искать по цвету глаз официантки я не уверен. Как и все более не уверен в том, что в его случае SQL-база хоть в чем-то проиграет NoSQL. Искренне хотел, что-бы вы меня переубедили. Пока не получилось.
dmshar, я особо и не старался) нам хватало реляционной базы, но были свои ограничения. полнотекстовый базы не хватает по тому что на основе типизированных данных куда лучше строится работа и редакции и консультационного отдела и создания различных прогнозов и статистики
Иван Шумов, Ну вот, теперь все стало на свои места. Я, наверное, тоже, если бы работал для Guide Michelin задумался о выборе типа модели базы. И не уверен, к чему бы склонился, кстати, в конечном итоге. Но для ТС это явно излишне, ему надо обратить внимание на вашу фразу "нам хватало реляционной базы".
Простой
Средний
Средний
