Нереляционные базы данных (NoSQL) для малых и средних приложений
Преимущества нереляционной базы данных (такие как устройство хранения данных пары "ключ-значение") очевидны при использовании в крупномасштабных наборах данных (Google, Facebook, linkedin). Как Вы думаете, что малые и средние приложения могут извлечь выгоду из использования нереляционных баз данных?
4 ответа
В мэйнфреймах IBM с 60-х годов были «нереляционные» базы данных (иерархические базы данных, такие как варианты IMS +). Эти базы данных все еще используются, потому что они очень быстрые и хорошо справляются с большими масштабами.
Суть реляционных баз данных заключалась в предоставлении обычного, относительно абстрактного метода для хранения и извлечения данных, в котором настройка может производиться относительно независимо от модели данных (что неверно для IMS). Они были разработаны скорее как реакция на невозможность легко реорганизовать иерархические базы данных. Плюс - хорошая организация; обратная сторона - средняя, не высокая производительность.
Google предоставляет масштабируемое хранилище и MapReduce для управления масштабированием. Это не отношения.
В начале прошлого десятилетия был большой толчок к хранению данных в XML, по сути, в иерархической форме, потому что XML является неявно иерархическим. Это была огромная ошибка, ИМХО, потому что повторяла неудобства иерархических баз данных, но не имела никакой производительности. Я не очень удивлен, что это движение в значительной степени умерло.
Мне кажется, что большая часть практического толчка к нереляционному использованию связана с производительностью и масштабом. Я не понимаю, насколько это помогает «маленьким» приложениям.
Люди предложили, но не сделали много практического управления данными с использованием схем, основанных на знаниях. Здесь на ум приходит CYC Дуга Лената.Способность базы данных помогать приложению делать неочевидные выводы кажется мне очень интересной для "небольших" приложений, которые пытаются быть "умными". Но их пока немного.
Сладкое место в использовании базы данных NoSQL в таком масштабе - это когда модель базы данных (ключ-значение, документ и т. Д.) Хорошо соответствует потребностям приложения, а расширенные реляционные функции не требуются.
На узком конце спектра производительность не является проблемой, потому что почти все работает быстро. Механизмы хранения не являются проблемой, если вам не нужен сложный механизм запросов, отсутствие поддержки SQL не проблема.
Вам остается только понять, насколько хорошо он подходит и насколько легко использовать. Честно говоря, проблема с инструментами все же возникает. Инструментарий для реляционных баз данных является зрелым, инструментарий NoSQL менее многофункциональный и менее защищенный. Слишком часто это инструменты, сделанные самостоятельно. Определенно подумайте, от каких инструментов вы откажетесь и насколько они вам нужны.
При рассмотрении службы NoSQL (например, Amazon SimpleDB и Microsoft Azure) у небольших проектов есть дополнительные преимущества по сравнению с продуктом. Если вам нужно платить только за то, что вы используете, и вы не используете много, это может быть дешевле, чем запуск выделенного сервера, вплоть до бесплатного для чего-то вроде уровня бесплатного использования SimpleDB.
Вы также избегаете некоторых затрат на обслуживание серверов и баз данных. Это может быть большой победой, если у вас нет администратора баз данных или когда ваши администраторы баз данных уже переутомлены. Конечно, у вас все еще есть работа с администратором, но она значительно сокращена и, как правило, проще.
Когда речь идет о графовых базах данных (таких как Neo4j - проект, в котором я участвую), они превосходят масштабирование по сложности. Это означает, что они обеспечивают "лучшие субстраты для моделирования бизнес-доменов" (см. The State of NoSQL, также Ben Scofield). Как мне кажется, это очень важно для малых и средних приложений.
Это может быть лучше объяснено на примерах, поэтому вот несколько ссылок на примеры приложений/моделирования доменов:
Вопрос, возможно, требует немного большего контекста ... предполагая, что среда Python, рассмотрите руководство в проекте y_serial: http://yserial.sourceforge.net/
NoSQL не просто принят по причинам масштабируемости. Сериализация (любого произвольного объекта Python) и постоянство очень удобны в любом масштабе, поэтому рассматривайте систему «ключ-значение» как один подход.