Это продолжается. Я продолжаю читать сообщения или разговаривать с людьми, у которых проблемы с базами данных NoSQL, и очень часто они обвиняют этот инструмент. Базы данных NoSQL, возможно, уже не новичок в мире, но многие люди продолжают неправильно понимать, когда, почему и как их использовать.
Давайте сосредоточимся на основной проблеме, моделировании данных с помощью баз данных NoSQL, особенно для баз данных NoSQL для документов, широких столбцов и значений ключа. Некоторые люди все еще пытаются использовать их так же, как и РСУБД, но, возможно, даже хуже. Они создают схему в базе данных NoSQL так же, как схему реляционной базы данных, а затем выполняют то, что я бы назвал «наивной миграцией». Затем они используют базу данных как свалку для данных, надеясь разобраться в них с помощью языка запросов для работы с данными. Эти действия могут нормально работать с некоторыми базами данных NoSQL, но они не получают преимуществ от использования базы данных NoSQL. Неизбежно они задаются вопросом, почему база данных NoSQL плохо работает/масштабируется или становится слишком дорогой. Они жалуются, а затем, возможно, возвращаются к использованию реляционных баз данных, потому что NoSQL того не стоит. Если вы делаете эти наивные действия, вы, скорее всего, не понимаете, что эти базы данных NoSQL вообще существуют, и еще меньше, что они делают лучше всего, компромиссы, которые вы можете сделать с ними, силу, которую они приносят вечеринке, и многое другое. вероятно, как лучше смоделировать данные для легкого доступа. Вы используете базу данных NoSQL так же, как и реляционную базу данных. Пожалуйста, прекрати.
Базы данных NoSQL работают и масштабируются лучше всего, когда ваша схема предназначена для моделирования шаблонов доступа приложения, частоты вызова этих шаблонов и скорости доступа к ним. Цель должна заключаться в том, чтобы ответы на эти шаблоны доступа были предварительно вычислены, а вопросы о данных (запросы) — редкость. Это верно, независимо от того, является ли это доступом к значению ключа, широким столбцом или документами JSON. Вы можете задавать вопросы в базах данных NoSQL? Конечно, но это не то, где большинство из них сияют. Вы получаете удар по производительности, масштабируемости, стоимости или сочетанию этих факторов. Чем больше вы пытаетесь использовать их в качестве базы данных общего назначения, тем больше вы попадаете в область «мастер на все руки, мастер ни в чем», в которую РСУБД, к сожалению, впихнули. Для достижения наилучшей производительности, масштабируемости и стоимости вопросы о ваших данных должны составлять меньшинство запросов в базе данных NoSQL типа OLTP.
Я предлагаю, казалось бы, простую задачу, когда в следующий раз, когда вы подумаете о создании нового приложения с базой данных NoSQL или о переходе с СУБД на базу данных NoSQL, сначала задокументируйте ВСЕ шаблоны доступа этой рабочей нагрузки. Какие точные данные необходимы, когда и с какой скоростью? Это должно помочь вам при создании схемы. Тот, который, возможно, более сложен на первый взгляд, но приложение может собрать идентификатор / первичный ключ / ключ раздела или что-то еще, поэтому оно не задает вопросы, а просто эффективно получает данные. Как только вы это сделаете, выясните, какие вопросы вам нужно удовлетворить с помощью запроса. Вам нужно иметь правильный баланс быстрого и дешевого доступа к данным для большинства вещей, а затем запрашивать только тогда, когда вам это действительно нужно. Если вы не можете выполнить такие задачи, как заблаговременное документирование всех шаблонов доступа приложения, база данных NoSQL может оказаться неподходящим решением для этой рабочей нагрузки. Возможно, вам будет лучше с РСУБД, которая обеспечивает большую гибкость за счет масштабируемости.
