Где почитать про проектирование баз данных(nosql) с практическими примерами?
Здравствуйте, ребята. Я преимущественно разрабатываю приложения, используя нереляционные базы данных, хотя иногда и приходится касаться и реляционных. Хотелось бы найти такой ресурс, где кратко и понятно разобраны принципы архитектурного проектирования приложений, используя nosql-базы. К примеру, было бы очень удобно посмотреть на разбор того, как наиболее правильно хранить пользовательские данные, комментарии, лайки, медиа-данные. Вспомните любую социальную сеть, где над каждым постом есть куча комментариев, лайков, репостов - хотелось бы увидеть реализации или хотя бы наглядную теорио о том, как это(и другие подобные случаи) реализовать правильно. Спасибо!
Шаг 1. Убрать из лексикона термин "NoSQL". Хотя бы временно.
как наиболее правильно хранить пользовательские данные, комментарии, лайки, медиа-данные.
Шаг 2. Выписать или запомнить три важнейших свойства любой СУБД:
модель данных: что является элементом данных, что является коллекцией элементов, чего в СУБД должно быть постоянное количество, есть ли схема и в каком виде, как обеспечиваются связи между элементами данных на уровне модели;
Пример: MongoDB, элемент данных - документ, описывается как JSON-документ с некоторыми специфичными для Монги расширениями. Коллекция элементов - коллекция документов. Количество коллекций более-менее постоянное, количество документов растёт.
ограничения и гарантии физической реализации модели данных - какие операции какую сложность имеют, какую цену (в плане пространства на устройстве хранения и процессорного времени) имеет каждая используемая структура данных или алгоритм; какие параметры как будут расти во время эксплуатации БД.
Пример: графовые БД, имеющие "настоящий" графовый движок, т.е. такой, который хранит физические ссылки из одной вершины на другую, гарантируют константное время выборки связанных вершин. В связи с этим их выгодно использовать для сильносвязанных нечасто изменяющихся данных (графы друзей в социалочках и т.п.)
инструментарий логического и физического уровня: по сути это предыдущие пункты более подробно - какие структуры данных доступны, в частности какие есть индексы, какие способы выборки/фильтрации/сортировки присутствуют; для чего гарантируется транзакционность (особо важный вопрос); где находится база в CAP диаграмме; какие есть средства логического уровня, например представления (view);
Вспомните любую социальную сеть, где над каждым постом есть куча комментариев, лайков, репостов
Шаг 3. Научиться ставить задачу с точки зрения обрабатываемых данных:
какие данные будут иметь постоянный объем или расти медленно, а какие - быстро и постоянно;
какие будут запросы к данным, что будет выбираться как есть, а что нужно будет дополнительно агрегировать;
какие запросы будут плановые, а какие придётся выполнять внепланово;
какой нужен уровень доступности, какова ценность хранящихся данных и цена простоя.
Шаг 4. Ознакамливаться с СУБД здесь: nosql-database.org и выбирать нужную с учётом:
Сколько раз твердили миру: для кажного дела, свой струмент, негоже гвозди биноклей колошматить, а за блохой с кувалдой! Станислав Макаров - респект!
И чисто практический пример: несколько лет назад народ набрал бабла на кикстартере, но продукт так и не выкатили. Причина была в том, что выбрав МангоБД в качестве основного хранилища не смогли впихнуть в него реляционные данные.
По своему опыту: у меня в некоторых проектах мирно сосуществуют Редис, Манго и старый добрый Мускл сдобренный Сфинксом, а на клиентской стороне плюс ко всему еще IndexedDB и Local Storage вместе с Session Storage.
Не нужно плодить сущности без надобности - это харам, нефиг бегать за модными названиями, но использовать подходящие инструменты для решения подходящих задач - вполне кошерно даже.
Читал на хабре подобное и девелопер опускал нереляционки там, где может потребоваться фильтрация , анализ, группировки и тп. В результате из той статьи я для себя сделал вывод, что не стоит пытаться из документной бд выстроить реляционную. Ссылку к сожалению сейчас не найду.
Виталий: не знаю про какую статью речь, но это не повод покупать трактор для поездок по городу с мыслью что когда-нибудь надо будет пахать поле.
На старте надо максимально просчитать необходимое, а когда понадобится то чего нет, уже думать исходя из имеющегося. Поэтому часто в больших проектах можно увидеть зоопарк разных (конкурирующих) технологий вместе.
монго всё это умеет. Единственное преимущество рсубд это транзакции и джойны, которые исчезнут как только сделаешь шардинг базы и нужно кучу кода писать для шардинга. рсубд это вообще не про веб, они появились задолго до веба. Это все более-менее как-то работает только на одной машине, дальше будет боль и никаких преимуществ перед nosql решениями.
Некие джойны есть и в монге, а например в OrientDB есть транзакции, джойны, ссылки и т.п.
В движке монги (wiredTiger) есть транзакции, есть и в плане, возможно и в самой монге появятся.
В итоге рсубд лишь отличается методом хранения который не является идеалом.
Поэтому все БД можно свалить в одну кучу и выбирать по фичам.
lega: не так давно начал работать с ретфинк, все вроде круто, но как только дошло до больших объемов, скорость упала на порядок на некоторых операциях. Sql хаит только глупец. Без обид.
Виталий: никто тут и не хаит sql (и рсубд), sql даже в некоторых nosql используется.
А вот большие объёмы, это как раз не про рсубд зачастую.
> скорость упала на порядок на некоторых операциях
я часто видел бенчмарки где обвиняли в тормозах очередную БД, хотя дело в кривых тестах. Может нет нужного индекса или не хватает памяти или ещё что (внешние силы), нужно искать причину.
Простой
Простой
