Михаил

MongoDB (NoSQL) - лучше всего подходит для _быстрого_ развёртывания проекта, у которого структура объектов до конца не определена. Не подходит, если _очень_ _много_ аггрегирующих операций или статистических срезов. Монго может, но она не для этого.

Если вам надо хранить отношение объект<=>документ в БД. (Ограничения 10МБ на один документ). На Хабре где-то есть пост про соц.сеть и как они попробовали там использовать NoSQL - при прочтение становится понятнее, что к чему.

Быстр для фильтрации по рейнджу, после того, как БД попадёт в память (после первого запроса), на некоторых _фильтрующих_ выборках становится быстрее даже Redis.
Если надо гонять JSON объекты (но сейчас и PostgreSQL говорят, что хорош).

SQL - если подготовке проекта предшествовала фаза проектирования, там где надо много статистики и аггрегации. Если вам надо объекты постепенно расширять связями (JOIN).
Одним словом - классика

Была у меня задача где монга с шардингом подошла идеально - сбор и архивирование логов действий пользователей. Были десятки миллионов действий в день. Тут понадобилась и гибкая структура и легкий шардинг на запись. Шардили коллекции по дате записи. TTL не использовали.

Я работаю с MongoDB на протяжении уже 4х лет. Имеется ряд проектов, созданных как с использованием этой БД, так и использованием классических RDBMS.
MongoDB это не MySQL и не PostgreSQL. Большинство людей пытается сравнить оба типа баз данных, но это абсолютно глупо и неприемлемо. Это все равно что сравнивать врачей и инженеров.
MongoDB подойдет там, где нужна гибкость структуры и большие объемы данных. Например хранение истории болезни пациентов в масштабе страны. Каждая карточка может быть разного типа со множеством полей. И их могут быть триллионы. Для классических реляционных БД это выливается в весьма нетривиальную задачу горизонтального масштабирования, которая в MySQL решается через перенастройку сервера, а в PostgreSQL через специальную промежуточную таблицу. Горизонтальный рост и ввод новых узлов кластера сопряжен с большими трудностями и плохо автоматизируется для реляционных БД.
Еще классические БД очень плохо работают со смешанной нагрузкой, когда у вас запись/чтение примерно 1:1 и данных очень много. Это вызывает непрерывное перестроение индексов и их использование больше мешает. Это тот тип нагрузки, при которой InnoDB частенько повреждается без возможности восстановления или что вызывает значительный простой на реорганизацию структур данных.
Также существует очень много задач, для которых использование MongoDB исключительно неприемлемо. Если вам необходимо работать с нормализованными данными - используйте реляционные БД. Если нужна мощная аналитика - колоночные. Разумеется, каждая из этих опций имеет свою цену.
На рынке нет универсального решения. Каждое заточено под свои задачи.

Высокопроизводительные распределенные интернет-приложения. Конкретные примеры: amazon.com, netflix.com, ebay.com. NoSQL движение возникло как ответ на проблемы масштабируемости. Реляционные базы ориентируются на требования ACID и как следствие имеют проблемы с горизонтальным масштабированием. Для таких баз необходимо реализовывать шардинг на уровне приложения. Но тогда будет необходимо отказаться от ACID, объединения таблиц и контроля целостности. В таком случае реляционная база теряет все козыри перед NoSQL. Но оставляет на плечах разработчика заботу о шардинге.

Интернет забит вопросами о том как жить без транзакций в NoSQL. Но бизнес-процессы в реальной жизни не являются транзакционными. Вы не можете человека, который покушал в вашем ресторане, а теперь отказывается платить по счетам заставить сделать роллбек вашей еды. Фактически посетитель вам бросил эксепшен. И даже если вам удастся извлечь еду из вашего посетителя, то маловероятно, что она будет готова к последующему употреблению. Но можно взыскать с него все затраты через суд и придти таким образом в согласованное состояние. Любому бизнесмену это очевидно. Но программисту нет. Он хочет транзакционно. Но пишет систему для автоматизации бизнес-процессов. Парадокс.

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

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

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

Список книг:

• "ES6 и не только" Кайл Симпсон. - очень хорошая книга, достойна чтобы просто прочитать, переведена достаточно хорошо.
  
• Learning JavaScript Design Patterns автор Addy Osmani примеры правда большинство относятся к ES5, что можно подчерпнуть как там выглядить паттерны, ну какой должен быть хороший стиль, очень хорошая книга
  

Ещё один способ, берет библиотеку jQuery и разбирайте её на части)) очень интересное штука и занимает многие вечера. Но пользы будет очень много. Ибо когда-то это библиотечка произвела фурор)

React это не фреймворк, а лишь либа для view
1. Никто не запрещает использовать lodash\underscore для работы с данными. Для фильтрации\поиска используйте селекторы.
2. Используйте webpack для сборки проекта, в настоящее время это единственное рабочее решение, так же в webpack есть асинхронная загрузка модулей - require.ensure, так что вы спокойно можете разбивать свое приложение на чанки и подгружать их в нужный момент.
3. По-моему сейчас очень, очень много плагинов адаптированных под реакт, за не большую практику работы с этим стеком у меня ни разу не возникло необходимости писать что-то самому с 0, всегда можно найти какое-то решение, форкнуть и допилить под себя.

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

используя nosql-базы

Шаг 1. Убрать из лексикона термин "NoSQL". Хотя бы временно.

как наиболее правильно хранить пользовательские данные, комментарии, лайки, медиа-данные.

Шаг 2. Выписать или запомнить три важнейших свойства любой СУБД:

• модель данных: что является элементом данных, что является коллекцией элементов, чего в СУБД должно быть постоянное количество, есть ли схема и в каком виде, как обеспечиваются связи между элементами данных на уровне модели;
  Пример: MongoDB, элемент данных - документ, описывается как JSON-документ с некоторыми специфичными для Монги расширениями. Коллекция элементов - коллекция документов. Количество коллекций более-менее постоянное, количество документов растёт.
  
• ограничения и гарантии физической реализации модели данных - какие операции какую сложность имеют, какую цену (в плане пространства на устройстве хранения и процессорного времени) имеет каждая используемая структура данных или алгоритм; какие параметры как будут расти во время эксплуатации БД.
  Пример: графовые БД, имеющие "настоящий" графовый движок, т.е. такой, который хранит физические ссылки из одной вершины на другую, гарантируют константное время выборки связанных вершин. В связи с этим их выгодно использовать для сильносвязанных нечасто изменяющихся данных (графы друзей в социалочках и т.п.)
  
• инструментарий логического и физического уровня: по сути это предыдущие пункты более подробно - какие структуры данных доступны, в частности какие есть индексы, какие способы выборки/фильтрации/сортировки присутствуют; для чего гарантируется транзакционность (особо важный вопрос); где находится база в CAP диаграмме; какие есть средства логического уровня, например представления (view);
  

Вспомните любую социальную сеть, где над каждым постом есть куча комментариев, лайков, репостов

Шаг 3. Научиться ставить задачу с точки зрения обрабатываемых данных:

• какие данные будут иметь постоянный объем или расти медленно, а какие - быстро и постоянно;
  
• какие будут запросы к данным, что будет выбираться как есть, а что нужно будет дополнительно агрегировать;
  
• какие запросы будут плановые, а какие придётся выполнять внепланово;
  
• какой нужен уровень доступности, какова ценность хранящихся данных и цена простоя.
  

Шаг 4. Ознакамливаться с СУБД здесь: nosql-database.org и выбирать нужную с учётом:

• вашей задачи;
  
• порога вхождения;
  
• наличия доступных специалистов.

Линкедин это по большей части для западного рынка, когда вы уже поработали в нескольких неплохих компаниях, написали у себя в истории крутые должности с красивыми и офигенными описаниями и параллельно со всем этим обмазались всякими "коннекшенами" со всех тех же мест где вы работали (или с кем пиво на конференции пили). В общем такой себе Circle Jerk, на котором вас в основном будут находить ушлые HR, отправляющие слегка измененную копипасту с описанием вакансии.

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

Я, как обычный разраб, просто принимаю почти все входящие коннект реквесты и любезно отвечаю эйчарам "сейчас позиция не интересует, но потом если что возможно напишу", ибо план B лишним не бывает (хотя, по ощущениям, все равно будет проще найти работу через друзей или какой-нибудь Hired если приспичет, чем ползти в эту жуть).

https://github.com/zualex/devmap
images.vfl.ru/ii/1466366676/e324255d/13079149.png
www.webdesigndegreecenter.org/learn-to-code

ReactJS Program - Отличный сайт, сам там сейчас изучаю React + хорошее Slack сообщество, где можно задать вопросы! Есть и бесплатные курсы.