Вступление

Mongoose - невероятно популярная и хорошо сделанная библиотека во вселенной NPM. Он широко используется многими превосходными программистами на основе его структуры Модель-Схема. Действительно, беглый взгляд на многие примеры создания любого типа стека с моделями данных, которые включают MongoDB, в Google покажет вам, что авторы в основном включают Mongoose в свою структуру разработки. Это уважаемая, ухоженная и невероятно популярная библиотека. Все вышесказанное верно, и следует похвалить авторов за их отличные навыки и понимание потребностей сообщества.

Вышеизложенное не является отказом от ответственности или циничным заявлением. На самом деле, я надолго откладывал публикацию этой статьи из-за того, что полагаю, что она не может быть хорошо принята в сообществе MongoDB. Тем не менее, суть Mongoose, то, что он заставляет человека делать с данными и как заставляет думать программиста, составляет суть этой статьи. Я полностью осознаю, что будет написанное здесь может быть невероятно непопулярным в нынешнем сообществе NodeJS - NPM. Однако, основываясь на недавних событиях в моей карьере, пришло время объяснить, почему следует избегать использования Mongoose практически в любом истинном сценарии больших данных. Позвольте мне сделать это заявление еще резче. Вот почему я действительно пренебрегаю использованием Typescript в NodeJS. Это также заставляет вводить переменные до того, как они попадут в систему.

Идея баз данных NoSQL

Любое простое понимание того, что должен делать NoSQL, заключается в том, что он построен таким образом, чтобы брать небольшие или огромные объемы данных и хранить их в коллекции или хранилище данных. Как бы вы ни называли свою базу данных, факт остается фактом: сами данные при сохранении являются «данными». Пока нет и никогда не должно быть в хранилище данных только идея о том, что каждый аспект этих данных должен соответствовать предопределенной структуре. Конечно, для многих, когда кто-то хранит такие вещи, в качестве имени, кажется, имеет смысл удостовериться, что это имя является «строкой». Или, когда я храню сумму, имеет смысл убедиться, что она хранится как «число».

Однако системы больших данных предназначены не только для хранения имен, адресов и вариантов выбора. Они собирают каждую часть информации, которую можно получить об объекте под рукой, и иметь возможность сохранить ее для последующего извлечения любым методом, который вы пожелаете. В самом деле, здесь важно отметить, что вся идея простого получения данных претерпела изменения. Сами по себе данные без какой-либо фильтрации шаблонов или согласованности больше не являются целью. Цель состоит в том, чтобы взять данные и применить их в любом движке или базе кода, которые вы используете, чтобы отфильтровать их таким образом, чтобы сделать их жизнеспособными и, возможно, одним из самых важных арсеналов в предполагаемом богатстве вашей компании.

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

Короче говоря, NoSQL - это форма нелинейного мышления, внедрения и извлечения данных. Сама суть NoSQL заключается в том, что вы не должны «вводить» информацию до того, как она попадет в базу данных. Ввод информации происходит тогда, когда вы извлекаете ее для информации. Это делается с помощью умного агрегирования, алгоритмов, теоретических построений - все основано на шаблонах и информации, которую вы ищете.

Линейное мышление

В защиту пользователей Mongoose они обычно обучаются в мире SQL, где каждый отдельный элемент имеет определенную структуру, а система связана (реляционные базы данных) на основе первичных ключей, отношений и триггеров. Это типичное линейное мышление. Он отлично подходит для небольших вещей, таких как базы данных имен и адресов и т. Д., Сообщения в блогах, обзоры книг и т. Д. Я уверен, что здесь можно привести миллионы примеров. Я сам много-много лет использовал исключительно MySQL и PHP. Это была и остается отличной системой. И действительно, большинство примеров, которые вы найдете при любом поиске, даже для полных систем для NodeJS и MongoDB, будут использовать такой сценарий и включать Mongoose.

Тем не менее, это заставляет мыслить линейно. Это заставляет линейное программирование. Он идет от шага 1 к шагу 2, к шагу 3 и т. Д. Конечно, в системах MySQL есть большие двоичные объекты или огромные текстовые поля, но они требуют огромного количества кодирования и подготовки, чтобы получить точную желаемую информацию. В наши дни традиционные системы MySQL не созданы для массовых потребностей в данных в реальном времени.

Сама природа MySQL борется с использованием огромных объемов «нетипизированных» данных.

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

Более того, структура MySQL может быть невероятно сложной. Таблица A переходит в таблицу B, затем запускает связь в таблице C, затем берет информацию из таблицы D, которая затем должна отсортировать таблицу E для получения информации. В этой цепочке может быть буквально 20–30 столов. Это не только беспорядок, но и становится практически невозможным для любого, кто не находится постоянно на вершине структуры (DBA), поддерживать ее в правильности.

Но даже в таких случаях основная причина заключается в том, что они просто не созданы для сбора неструктурированных данных, которые собираются в наши дни.

Структура мангуста

Таким образом, есть смысл тяготеть к Mongoose, чтобы применить какую-то структуру к собираемым данным. Более того, поскольку Mongoose невероятно хорошо работает в качестве промежуточного программного обеспечения с Express, Passport и т. Д., И он обеспечивает необходимое подключение к MongoDB в обычном режиме, это по своей природе то, что нельзя пропускать без четкого представления о том, что должна делать вся система. . В системе «схема-модель» можно передать почти любой тип функции для достижения истинного CRUD. Он также позволяет использовать обратные вызовы, обещания и ES6. Все вышеперечисленное - фантастика.

Однако есть один нюанс. По характеру работы Mongoose вы должны определить (ввести) характер информации в типичном формате JSON. В практических ситуациях, особенно с огромными объемами данных, любой опытный аналитик данных скажет вам, что такая модель не только невероятно вредна для самих данных, но и практически невозможна.

Ввод данных до того, как они попадут в вашу БД

Суть применения типа к данным до того, как они попадут в вашу коллекцию, подразумевает, что вы точно знаете, какой тип данных поступает и какой это тип данных. Будь то любой тип строки, числа или любого другого состояния. Опять же, это может применяться к простым решениям небольших систем, где вы концентрируетесь на конкретных данных, которые вы на 100% уверены, что собираетесь получить. Но что происходит в экземплярах в реальном времени или при получении данных в пакетах JSON, когда иногда информации просто нет или внезапно появляется дополнительная пара "ключ-значение"? Или что происходит, когда вы имеете дело с медицинской или страховой информацией, когда необходимо собрать огромные объемы дифференцирующих данных разных типов?

Конечно, вы можете утверждать, что можно вернуться и изменить модель схемы для этой коллекции, чтобы включить изменения. Благодаря этому все красиво упаковано в модель и, безусловно, легко читается. Тем не менее, он не отражает реальных сценариев, и схема-модель действительно большой системы данных была бы чрезвычайно сложной, снова требуя не только знания MongoDB и всех ее возможностей, но, вероятно, администратора базы данных только для обработки настройки Mongoose.

Снова расширение промежуточного программного обеспечения с неправильной целью

Любой программист NodeJS ответит вам, если его спросят о промежуточном программном обеспечении, что Express обычно находится на вершине стека. Маршрутизация, JWT, Паспорт, Шлем и многие другие будут продолжать стек. В такой стопке невероятно легко потеряться, как бы хорошо вы ни проектировали. Я видел файлы package.json, которые поражают воображение количеством используемых модулей NPM. Может быть, все это необходимо, и, честно говоря, я действительно сторонник НПМ. Однако стек есть стек. Промежуточное ПО, введенное неправильно или в неправильном порядке, может сильно замедлить или просто сделать систему нефункциональной. Добавьте все это к принудительному типу данных, вы имеете дело с системами, которые, вероятно, могли бы реагировать намного быстрее, с гораздо меньшей задержкой и, что наиболее важно, с меньшим отклонением неформатированных данных.

Заключение

Я хочу повторить, что создатели Mongoose проделали невероятную работу. Они также позволили программистам SQL присоединиться к вселенной NoSQL, не внося больших изменений в их способ мышления о данных. Кроме того, для небольших систем лучше всего подойдет Mongoose.

Однако, если вы действительно имеете дело со сложными сценариями больших данных или пакетами в реальном времени, поступающими отовсюду, где значения, типы и информация могут меняться от пакета к пакету, Mongoose следует исключить из вашего уравнения. Вы должны освоить MongoDB во всех его нюансах, включая MapReduce, агрегацию и т. Д. CRUD больше не просто CRUD. В системах больших данных это выходит далеко за рамки типичного типа операции SQL CRUD. Это требует глубокого понимания истинной природы больших данных, выходящих за рамки старого имени-адреса-телефона; войти в систему и принять какой-либо тип записанных данных. Когда вы начнете развиваться дальше, я советую отложить Mongoose в сторону и погрузиться в создание функциональной библиотеки с собственными конструкциями MongoDB. Избегайте промежуточного программного обеспечения Mongoose, независимо от того, насколько хорошо вы его знаете. В конце концов, такие системы Mongoose отклонят незапечатанную информацию, и вы ее потеряете. Это может иметь катастрофические последствия в сценариях с большими данными.

Выбор за вами, и, очевидно, это мнение. Если вы работаете над настоящей системой больших данных, мое простое скромное мнение состоит в том, чтобы исключить Mongoose. Не «вводите» (читай: заранее определяйте) вашу информацию. Не устанавливайте ограничений на то, что будет входить в вашу систему. Возьмите все данные, которые вы можете получить, и затем с помощью правильных алгоритмов и манипуляций с собственными командами MongoDB вы сможете достичь целей не только сбора данных, но и поиска шаблонов и соединений любым возможным способом. Это обеспечивает гибкость и нелинейный мыслительный процесс. Это то, для чего был создан NoSQL.

_________________________________________________________________

Об авторе: Тед Гросс много лет занимал должность технического директора с опытом работы в технологиях баз данных, NodeJS, MongoDB, шифровании, PHP и ООП. Он имеет опыт в технологиях виртуального мира и дополненной реальности. Он также опубликовал множество статей по технологическим темам, особенно по Big Data & Chaos Theory (в профессиональных журналах и в Интернете на @ Medium и LinkedIn). Он также является автором художественной литературы, детских книг и различных научно-популярных статей. Его сборник рассказов « Древние сказки, современные легенды » получил отличные отзывы.

С Тедом можно связаться по электронной почте: [email protected]; Твиттер (@tedwgross); LinkedIn; "Середина"