Я здесь не для того, чтобы спорить о Его чертах лица
Или здесь для того, чтобы обращать атеистов в верующих — Канье Уэст, Jesus Walks
Нижеследующее является исключительно моим мнением и не отражает точку зрения MongoDB. Большинство людей, которые читают этот пост, будут работать в компьютерном программном обеспечении или операциях из-за названия. Этот пост короткий, полутехнический, для тех, кто проектирует что-то, что трудно упростить, и в основном публичное напоминание самому себе, чтобы я продолжал стремиться к упрощению.
MongoDB появилась на свет в 2009 году, когда рабочих мест и потребностей для разработчиков программного обеспечения было гораздо больше, чем человеческого капитала. В свою очередь, невидимая рука [и] рыночных сил направилась к клавиатурам по всему миру — с программным обеспечением с открытым исходным кодом и поисковыми системами, прокладывающими путь к тому, что должно было последовать. Несмотря на то, что они всегда присутствовали и оказывали влияние с самого начала вычислительной техники, на сцену вышла более сильная волна разработчиков-самоучек, без предвзятости преобладающей академической точки зрения. Они хотели простоты.
ОТДЫХАЙ спокойно. Однажды я подробно изложу историю, которую знаю, и объясню, почему предвзятость академических кругов в то время не помешала долгосрочному внедрению MongoDB. Это короткое эссе кратко объяснит гениальность MongoDB, познакомив пользователей со сценарием, который читатели поймут как переключение контекста. Далее — и не беспокойтесь слишком сильно о том, что означают эти слова, если вы незнакомы — читатели увидят два когда-то конкурирующих формата данных, которые разработчики использовали для представления данных, JSON и XML. Эссе завершается обсуждением того, что программирование большинства приложений сегодня, благодаря множеству абстракций, изложенных здесь и в других местах, является очень человеческим делом, и я смело заявляю, что лучшие компьютерные интерфейсы — самые человеческие.
Вспомните случай, когда вы были очень сосредоточены на задаче, которую было бы трудно возобновить, если бы вас отвлекли. Середина задачи с одной задачей по физике, отрывок из дремучего Канта по философии или книга Чисел в церкви. Или просто приготовить какое-нибудь блюдо из лапши, где нужно вскипятить почти всю воду. Если кто-то прерывает вас, когда вы делаете что-то, требующее концентрации, вы можете вернуться к сожженной лапше.
Многим разработчикам программного обеспечения, когда их прерывают на тридцать секунд, может потребоваться много времени, чтобы продолжить работу с того места, на котором они остановились. Переключение контекста из памяти, которой они управляли, или потоков, которые они распараллеливали, может никогда не переключиться обратно! Иногда разработчикам нужно начинать с самого начала стоящей перед ними задачи. Хотя не всегда плохо возвращаться к проблеме позже, после того как ваш мозг решил ее благодаря процеживанию, обычно создателям нужно отступить по собственному желанию. Непреднамеренное прерывание происходит с бэкэнд-разработчиками или разработчиками программного обеспечения полного стека десятки раз в течение рабочей недели из-за разрыва реляционных баз данных с API-интерфейсами и бизнес-логикой, мучениями таблиц и строк.
Разработчики программного обеспечения, создающие серверные части приложений, работают с современными API, которые возвращают JSON (нотация объектов JavaScript). Они строят свою бизнес-логику, используя объектно-ориентированную парадигму. И затем, когда они переходят к этапу сохранения данных или запросов, им приходится искажать структуру данных, чтобы она соответствовала требованиям реляционных баз данных. Это похоже на то, как вас прерывают, когда вы сосредоточены на чем-то важном. Это случается с ними десятки раз в течение рабочей недели, что составляет десять минут потерянной производительности здесь, пятнадцать минут там и так далее.
Консультант по рабочему месту, говоря с Washington Post на тему прерывания на рабочем месте, оценил, что стоимость производительности составляет около 6 часов в неделю. Предположим, что для многих разработчиков, застрявших на реляционных базах данных, этот перерыв составляет примерно 7 непродуктивных недель из 48-недельного рабочего года. Если мое предположение верно (а для некоторых пользователей оно, вероятно, преувеличено), то еще семь недель многие инженеры были разочарованы тем, что их босс действительно хорошо разбирался в SQL и не проводил переоценку рынка.
До того, как JSON стал популярным, а MongoDB стала одной из самых быстрорастущих компаний в истории, у компаний, занимающихся реляционными базами данных, был друг в отделе форматов. XML. Гораздо проще сопоставить XML с таблицами и строками, но люди по-прежнему используют JSON всякий раз, когда раньше использовался XML, потому что его неудобно читать.
Многие из самых быстрорастущих компаний в мире во всех отраслях используют MongoDB. Когнитивная преемственность является большой причиной, почему. Есть гораздо больше людей, которые знают SQL, преподают SQL и проповедуют SQL. Но почти все они сталкиваются с проблемами со стороны разработчиков приложений, которые могут внедрять инновации быстрее.
Это не обязательно должна быть MongoDB. Я приписываю им популяризацию объектно-родной парадигмы. Сегодня существует множество широко используемых хранилищ данных NoSQL для различных целей, таких как Elasticsearch для журналов и наблюдения, DynamoDB для (по общему признанию) надежной привязки к поставщику и Redis для кэширования. Еще до MongoDB существовало SOLR, когда-то широко используемое хранилище данных NoSQL для поиска, и невероятный Apache Lucene (наконец-то появилась управляемая версия спустя почти 20 лет).
В Интернете есть много изображений, совмещающих JSON и XML, но я выбрал маленькую, так что вам придется проделать еще немного работы. Косоглазие. Ущипнуть. Дотянитесь до очков. Вот каково это работать с реляционными базами данных для создания приложений, большую часть времени. Я признаю, что некоторые ORM и некоторые фреймворки значительно улучшают проблему переключения контекста, но не решают ее. Крутые ребята хотят использовать JavaScript/Typescript, Python/Data Frames, Go (вроде), Elixir и Rust. Некоторые компании должны снижать риски и развиваться шаг за шагом, продолжая использовать мощный язык Java. Вы должны чувствовать себя хорошо с любым языком, который вы используете, и с любой проблемой, которую вы решаете ежедневно.
Я давно помню французские и испанские мечты. Я не могу вспомнить, когда мне впервые приснился JSON. Это не Тьюринг-полный, а всего лишь формат, который мы заимствовали из языка JavaScript. У меня есть полностью воображаемые объекты в JSON. Если вы попытаетесь представить объекты в системе управления реляционными базами данных, вы получите кучу картотек, таблиц Excel и стрелок, указывающих во все стороны.
MongoDB хранит данные в формате BSON (Binary JSON), который является версией JSON со скидкой. Он сжат, поэтому вы можете хранить JSON за меньшие деньги. Непрерывность API (API REST, возвращающие JSON), логика приложения (и объектно-ориентированная парадигма) и уровень сохраняемости (BSON) немного снижают остроту. В качестве дополнительного бонуса язык запросов MongoDB также является JSON.
Я уже знаю, что всех не переубедишь. Многие разработчики свято привержены системам управления реляционными базами данных. За последние 15 лет некоторые команды, такие как Snowflake и DataBricks, создали невероятные предложения на основе SQL, которые служат определенной цели. Бывшие сотрудники Google обманывали неосведомленных покупателей кредитов, заставляя их думать, что они создали альтернативу Oracle, говорящую на SQL, которая облегчит масляный подъем и сдвиг. И у других людей есть особые потребности, которым я бы не стал рекомендовать MongoDB сегодня.
Данных так много, и еще столько же впереди, в будущем появится много замечательных компаний, занимающихся базами данных. Я предсказываю 100 в состоянии 2000 к 2042 году, а многие не существуют или никому не известны. Я в восторге от основных вариантов дизайна интерфейса MongoDB.
Есть много других причин, по которым компании выбирают MongoDB, которые я не упомянул, потому что я не пытаюсь рекламировать MongoDB в этом посте. Я выступаю за когнитивную преемственность в пользовательском опыте, насколько это возможно, кем бы ни был ваш пользователь.
