Почему следует использовать базы данных NoSQL?

Стас Белков

Стас Белков

Автор статьи. Известный специалист в мире IT. Консультант по продуктам и решениям Oracle. Практикующий программист и администратор баз данных. Подробнее.

 

Почему следует использовать NoSQl базу данных вместо реляционной? Или совместно?Почти все время нашей работы в сфере разработки программного обеспечения реляционные базы данных по умолчанию были основным способом хранения данных в серьезных проектах, особенно в области промышленных приложений. Если вы - архитектор, начинающий новый проект, то скорее всего выберете реляционную базу. (Кроме того, выбор базы данных часто диктуется наличием у компании доминирующего поставщика.) Иногда появлялись другие технологии баз данных, например, объектные базы данных в 1990-х годах, но эти альтернативы не получили широкого распространения.

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



 

Значение реляционных баз данных

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

 

Персистентные данные

Вероятно, самым главным преимуществом баз данных является возможность долговременного хранения больших объемов данных. Большинство компьютерных архитектур подразумевают два вида памяти, быструю и изменчивую основную память, и более крупное и медленное резервное хранилище.

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

Резервное хранилище может быть организовано разными способами. Для большинства высокопроизводительных приложений (например, для текстовых процессоров) резервным хранилищем является файл, записанный в файловой системе. Однако для большинства промышленных приложений резервным хранилищем является база данных.

Это обеспечивает более высокую гибкость при хранении крупных объемов данных по сравнению с файловой системой в том смысле, что база данных позволяет прикладным программам быстро и легко получать небольшие порции информации.

 

Параллельность

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

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

Поскольку в промышленных приложениях может быть много пользователей и систем, работающих одновременно, возникает большой простор для неприятностей. Реляционные базы данных помогают предотвратить эти неприятности, управляя всем доступом к данным посредством транзакций. Хотя это и не панацея (вы все еще обязаны исправлять ошибки транзакций, когда пытаетесь зарезервировать только что занятый гостиничный номер), механизм транзакций хорошо справляется со сложностью параллельной работы.

Транзакции также играют важную роль в обработке ошибок. Используя транзакции, можно внести изменение, и если возникнет ошибка при обработке этого изменения, выполнить откат, исправив ситуацию.

 

Интеграция

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

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

Традиционно для этого используется интеграция баз данных коллективного пользования (shared database integration) [Hohpe, Woolf], при которой несколько приложений хранят свои данные в одной базе. Использование одной базы данных позволяет всем приложениям легко использовать данные другого приложения, а механизм управления параллельной работой базы данных обрабатывает запросы от нескольких приложений так, будто он обрабатывает запросы нескольких пользователей одного и того же приложения.

 

(Почти) стандартная модель

Реляционные базы данных получили признание благодаря тому, что они предоставляют важные преимущества, указанные выше, (почти) стандартным способом. В результате разработчики баз данных могут изучить основную реляционную модель и применять ее во многих проектах. Несмотря на различия между разными реляционными базами данных, их основной механизм остается одним и тем же: разные диалекты языка SQL похожи друг на друга
и транзакции обрабатываются практически одинаково.

 

Потеря соответствия

Реляционные базы данных имеют много преимуществ, но они не идеальны. Уже с первых лет они приносили много проблем.

Для разработчиков приложений основной проблемой была потеря соответствия (impedance mismatch): различие между реляционной моделью и структурами данных, находящимися в памяти. Реляционная модель данных представляет их в виде таблиц и строк, или точнее, отношений и кортежей. В реляционной модели кортежем называется множество пар имя-значение, а отношением - множество кортежей. (Реляционное определение кортежа немного отличается от их определения в математике и многих языках программирования, имеющих соответствующие типы данных, в которых кортежи представляют собой последовательности значений.) Все операции в языке SQL получают и возвращают отношения, что приводит к математически элегантной реляционной алгебре.

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

В результате, если вы захотите использовать сложную структуру данных, находящихся в памяти, то должны будете преобразовать реляционное представление для хранения на диске. В итоге возникает потеря соответствия - два разных представления, требующих трансляции (рис. 1).

 Пример из реляционных баз данных

Рис. 1. Заказ, который в пользовательском интерфейсе выглядит как единая агрегированная структура, в реляционной базе данных разделяется на множество строк из многих таблиц

 

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

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

Появление множества библиотек для объектно-реляционного отображения, таких как Hibernate и iBATIS, реализующих широко известные шаблоны отображения [Fowler РоЕАА], смягчило, но не устранило проблему потери соответствия. Библиотеки для объектно-реляционного отображения взяли на себя большую часть "грязной" работы, но сами по себе могут стать проблемой, если разработчики будут упрямо игнорировать потерю эффективности работы баз данных и обработки запросов.

Реляционные базы данных продолжают доминировать в области промышленной обработки данных в 2000-х годах, но на протяжении первого десятилетия в стенах их неприступной крепости стали появляться трещины.

 

Интеграционные базы данных и базы данных приложения

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

В этом сценарии база данных действует как интеграционная 6аза Jанных (integration database) - с многочисленными приложениями, которые , как правило, разработаны разными коллективами и хранят свои данные в общей базе данных. Это улучшает взаимодействие, потому что все приложения оперируют согласованным множеством сохраняемых данных.

Интеграция общих баз данных имеет свои недостатки. Структура, разработанная для интеграции многих приложений, рано или поздно становится сложнее – на самом деле, часто она оказывается намного сложнее, - чем требуется для отдельного приложения. Кроме того, если приложение захочет изменить хранилище своих данных, оно должно будет координировать это со всеми приложениями, использующими базу данных. Разные приложения имеют разные требования к структуре и производительности, поэтому индекс, необходимый для одного приложения, может стать проблемой для другого. То, что приложения обычно разрабатываются разными коллективами, означает, что база данных, как правило, не может доверить приложениям изменять свои данные с сохранением целостности базы данных и должна взять это на себя.

В качестве альтернативы можно применить базу данных приложения (application database), которая открывает доступ к данным только для одного приложения, разработанного одним коллективом. При работе с базой данных приложения только коллектив, использующий приложение, знает структуру базы данных. Это облегчает поддержку и развитие ее схемы. Поскольку команда, использующая приложение, управляет кодами как базы данных, так и приложения, ответственность за целостность базы данных можно возложить на код приложения.

Теперь ответственность за обеспечение взаимодействия перекладывается на интерфейсы приложения. Это позволяет использовать более хорошие протоколы взаимодействия и создать возможности для их изменения. На протяжении 2000-х годов мы видели явный сдвиг в сторону веб-сервисов [Daigneau], в которых приложения взаимодействуют посредством протокола НТТР. Веб-сервисы создают новую форму широко используемого механизма взаимодействия - альтернативу использованию языка SQL с общими базами данных. Большая часть этой работы прошла под лозунгом "сервисно-ориентированной архитектуры" (SOA) - термин, замечательный по своей бессмысленности.

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

Если вы собираетесь использовать сервисы для интеграции (чаще всего для этого применяют веб-сервисы с помощью текстового протокола НТТР), желаем успеха. Однако, если вы имеете дело с взаимодействиями, для которых важной является производительность, вам нужен двоичный протокол. Его следует использовать только в случае необходимости, поскольку с текстовыми протоколами работать легче - в качестве примера можно назвать Интернет.

Приняв решение использовать базу данных приложения, вы получаете свободу выбора базы данных. Поскольку между внутренней базой данных и сервисами, посредством которых вы общаетесь с внешним миром, есть несогласованность, внешнему миру совершенно безразлично, как вы храните свои данные. Это дает вам возможность использовать нереляционные варианты. Более того, существуют многочисленные особенности реляционных баз данных, такие как безопасность, которые для базы данных приложения особого значения не имеют, поскольку их можно обеспечить за счет внутреннего приложения.

Тем не менее, несмотря на эту свободу, нельзя сказать, что базы данных приложения оказали значительное влияние на использование альтернативных хранилищ данных.

Большинство коллективов, занимавшихся разработкой баз данных приложения, придерживались реляционных баз данных. Помимо всего прочего, использование базы данных приложения приносит много преимуществ даже помимо гибкости данных (которая была основной причиной, по которой мы рекомендовали такие базы данных).

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

 

Кластеры атакуют!

В начале нового тысячелетия в технологическом мире лопнул пузырь доткомов (dot-com bubble), надувавшийся в 1990-х годах. Это вызвало у многих людей вопросы об экономических перспективах Интернета, но в 2000-х годах некоторые из главных свойств сети веб приобрели очень большой масштаб.

Это увеличение масштаба происходило во многих направлениях. Веб-сайты стали внимательно следить за деятельностью клиентов и структурой. Появились крупные совокупности данных: связи, социальные сети, активность в блогах, картографические данные.

Рост объема данных сопровождался ростом количества пользователей – крупнейшие сайты достигли громадных размеров и обслуживали огромное количество клиентов.

Для того чтобы справиться с возрастающим объемом данных и трафика, потребовались более крупные вычислительные ресурсы. Существовали две возможности масштабирования: вертикальное и горизонтальное. Вертикальное масштабирование (scaling up) подразумевает укрупнение компьютеров, увеличение количества процессоров, а также дисковой и оперативной памяти. Но более крупные машины становятся все более и более дорогими, не говоря уже о том, что существует физический предел их

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

Когда произошел сдвиг в сторону кластеров, возникла новая проблема – реляционные базы данных не предназначены для работы на кластерах. Кластерные реляционные базы данных, такие как Oracle RAC или Microsoft SQL Server, основаны на концепции общей дисковой подсистемы. Они используют кластерную файловую систему, выполняющую запись данных в легко доступную дисковую подсистему, но это значит, что дисковая подсистема по-прежнему является единственным источником уязвимости кластера. Реляционные базы данных также могут работать на разных серверах с разными наборами данных, эффективно выполняя фрагментацию базы данных (sharding). Хотя это позволяет разделить рабочую нагрузку, вся процедура фрагментации должна контролироваться приложением, которое должно следить за тем, какой сервер базы данных и за какой порцией данных обращается.

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

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

Это несоответствие между реляционными базами данных и кластерами вынудило некоторые организации рассмотреть альтернативные способы хранения данных.

В частности, большое влияние оказали две компании - Google и Amazon. Они вышли на передний фронт работы с горизонтально масштабированными кластерами; более того, они хранили огромные объемы данных. Это стимулировало остальные компании.

Обе компании были успешными и быстро растущими высокотехнологичными предприятиями, обладающими средствами и возможностями. Им не приходило в голову, что они уничтожают свои реляционные базы данных. Когда прошло первое десятилетие нового века, обе компании опубликовали короткие, но очень важные документы о своих усилиях: BigTable от компании Google и Dynarno от компании Amazon.

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

Несмотря на то что большинство проектов программного обеспечения не требуют такого масштабного применения, все больше и больше организаций начинают изучать возможности хранения и обработки более крупных объемов данных - и наталкиваются на те же проблемы. Таким образом, чем больше информации об опыте компаний Google и Amazon мы получаем, тем больше людей начинают предпринимать попытки создавать аналогичные базы данных, непосредственно предназначенные для кластеров.

В то время как прежние угрозы доминирования реляционных баз превратились в фантомы, угроза со стороны кластеров оказалась серьезной.

 

Появление баз данных NoSQL

Ирония судьбы заключается в том, что термин "NoSQL" впервые появился в конце 1990-х годов в качестве названия реляционной базы данных с открытым исходным кодом [Strozzi NoSQL]. Согласно Карло Строцци (Carlo Strozzi), эта база данных хранит свои таблицы в виде файлов в кодировке ASCII, каждый кортеж представляется строкой, состоящей из полей, разделенных знаками табуляции. Название объясняется тем фактом, что эта база данных не использует язык SQL в качестве языка запросов. Вместо этого эта база данных манипулирует сценариями оболочки, которые можно объединять в обычные конвейеры UNIX. Помимо совпадения имен, база данных NoSQL, разработанная Строцци, не имеет никакого отношения к базам данных, описанным в нашей статье.

Рождение термина "NoSQL" в современном смысле датируется 11 июня 2009 года. Он появился на конференции в Сан-Франциско, организованной Йоханом Оскарссоном Oohan Oskarsson), разработчиком программного обеспечения, живущим в Лондоне.

Пример баз данных Big Table и Dynamo вдохновил создателей многих проектов на эксперименты с альтернативными хранилищами данных, и этой теме в то время было посвящено сразу несколько конференций. Йохан хотел побольше узнать об этих новых базах данных, прибыв на конференцию Hadoop в Сан-Франциско. Поскольку у него было мало времени, чтобы посетить все конференции, он решил организовать собственный семинар, на котором можно было собрать экспертов и представить их работы.

Йохану нужно было имя для своего семинара - что-нибудь вроде хеш-тега в Твиттере: короткое, запоминающееся и не вызывающее в поисковой машине Google слишком много ссылок. Он обратился за помощью в ретранслируемый интернет-чат #cassandra и получил несколько вариантов, из которых выбрал "NoSQL", предложенный Эриком Эвансом (Eric Evans), разработчиком из компании Rackspace, который не имеет никакого отношения к известному специалисту по предметноориентированному проектированию Эрику Эвансу. Несмотря на негативный оттенок и отсутствие прямой связи с описываемыми системами, это имя удовлетворило критерии хеш-тега. В то время они просто хотели как-то назвать свой семинар и не ожидали, что это имя станет названием целого технологического направления [Oskarsson].

Термин "NoSQL" прижился, но никогда не имел строгого определения. Исходное название семинара относилось к "распределенным нереляционным базам данных с открытым исходным кодом" [NoSQL Meetup]. Эти эпитеты относятся к базам данных Voldemort, Cassandra, Dynomite, HBase, HyberTable, CouchDB и MongoDB [NoSQL Debrief], но никогда не ограничивались этой семеркой. В настоящее время не существует ни общепринятого определения этого термина, ни авторитетного органа, который бы предложил такое определение, поэтому мы можем лишь обсуждать некоторые общие свойства баз данных, относящихся к категории NoSQL.

Для начала отметим очевидный факт: базы данных NoSQL не используют язык SQL. Некоторые из них имеют свой язык запросов, и их целесообразно было бы сделать похожим на SQL, чтобы их легче было изучить. К таким языкам относится CQL в базе данных Cassandra - "очень похожий на SQL (за исключением отличий)" [CQL].

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

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

Большинство баз данных NoSQL создавались в ответ на необходимость работать на кластерах. Это особенно справедливо по отношению к разработчикам, принявшим участие в первом семинаре. Этот семинар повлиял на их модель данных и подход к обеспечению согласованности данных. Для обеспечения согласованности данных во всей базе данных реляционные базы данных используют транзакции ACID. Это изначально противоречит кластерной среде, поэтому базы данных предлагают спектр вариантов для обеспечения согласованности и распределения данных.

Однако не все базы данных NoSQL строго ориентируются на работу с кластерами.

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

Базы данных NoSQL учитывают емкость веб-сайтов начала ХХ1 века, поэтому обычно только системы, разработанные примерно в это время, называются NoSQL, тем самым исключая базы данных, созданные в прошлом веке, кроме базы ВС (Before Codd).

Базы данных NoSQL работают без схемы, позволяя свободно добавлять поля в базу данных без предварительного изменения структуры. Это очень важно для баз данных с неоднородными данными и пользовательскими полями, для работы с которыми реляционные базы данных используют такие имена, как customField6, или таблицы, состоящие из пользовательских полей, которые неудобно обрабатывать и сложно понимать.

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

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

Когда вы впервые слышите термин "NoSQL," сразу же возникает вопрос: "Это отрицание SQL?" Большинство людей, рассуждающих о технологии NoSQL, говорят, что на самом деле эта аббревиатура означает "Not Опlу SQL" ("Не только SQL"), но такая интерпретация порождает несколько проблем. Большинство людей пишут "NoSQL", в то время как фразе "Not Опlу SQL" соответствует аббревиатура "NOSQL". Кроме того, нет особого смысла называть базу данных NoSQL словом "не только", потому что, например, базы данных Oracle и Postgres тоже соответствуют такому определению, а это значит называть черное белым.

 Для устранения этого противоречия мы предлагаем не интересоваться расшифровкой термина, а сосредоточиться на его смысле (это относится к большинству аббревиатур). Таким образом, если база данных относится к категории NoSQL, значит, речь идет о нечетко определенном множестве баз данных с открытым кодом, в большинстве своем разработанных в начале ХХ1 века и, как правило, не использующих язык запросов SQL.

Впрочем, интерпретация выражения "не только" имеет определенное значение, поскольку она описывает окружение, в котором многие люди видят свои будущие базы данных. На самом деле это именно то, что мы считаем самым важным в таком способе рассуждений: NoSQL - это скорее движение, а не технология. Мы не считаем, что реляционные базы данных исчезнут, поскольку они остаются самыми распространенными.

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

Изменения заключаются в том, что теперь реляционные базы данных являются только одной из возможностей для хранения данных. Эта точка зрения часто называется многовариантной персистентностъю (Polyglot Persistence), подразумевающей использование разных хранилищ данных в разных ситуациях. Вместо слепого выбора реляционных баз данных, потому что так принято, мы должны понимать природу данных, которые собираемся хранить, и знать, что мы хотим с ними делать. В результате большинство организаций в разных ситуациях будут использовать смешанные технологии хранения данных.

Для того чтобы заставить работать все это разнообразие, организации должны перейти от интеграционных баз данных к базам данных приложения. Мы предполагаем, что вы будете использовать базы данных NoSQL как базу данных приложения; как правило, мы не рассматриваем базы данных NoSQL как удачный выбор для интеграционной базы данных. Мы не считаем это недостатком, поскольку, даже если вы не используете технологию NoSQL, переход к инкапсуляции данных в сервисах – правильное направление.

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

Итак, теперь, кода вы готовы прочитать остальную часть книги, запомните две основные причины для изучения технологии NoSQL. Первая причина - это необходимость обеспечить доступ к данным, объем которых и требования к производительности вынуждают использовать кластеры; вторая причина - повысить производительность разработки приложений с помощью более удобного способа обеспечения обмена данными.

 

Выводы и перспективы

 

Вас заинтересует / Intresting for you:

Как правильно выбрать базу дан...
Как правильно выбрать базу дан... 7220 просмотров Administrator SU Sun, 07 Oct 2018, 08:31:24
Агрегированные модели и NoSQL ...
Агрегированные модели и NoSQL ... 9394 просмотров Денис Fri, 05 Feb 2021, 16:17:09
Базы данных - презентация к ку...
Базы данных - презентация к ку... 3460 просмотров Светлана Комарова Wed, 10 Oct 2018, 17:32:17
Реляционные базы данных
Реляционные базы данных 2411 просмотров Ирина Светлова Tue, 21 Nov 2017, 13:27:29
Печать
Войдите чтобы комментировать

apv аватар
apv ответил в теме #9897 3 года 1 мес. назад
У NoSQL баз данных нынче очень большое поле для применения. Осваивать эти технологии нужно и очень полезно для программистов. Big Data, Облако все это очень востребовано нынче, а оно плотно работает с NoSQL.