С Облачными вычислениями, все больше становясь популярным, Реляционный DBS перенесет смерть?
Просто для полноты обратите внимание, что вы также можете избавиться от предупреждения, установив I18n.enforce_available_locales в true (или false) в config/application.rb:
require File.expand_path('../boot', __FILE__)
.
.
.
module SampleApp
class Application < Rails::Application
.
.
.
I18n.enforce_available_locales = true
.
.
.
end
end
9 ответов
Вот хорошая статья, которая может ответить на некоторые из ваших вопросов. В нем есть хорошее сравнение между системами РСУБД и системами, обычно используемыми для инфраструктуры облачного хранения:
http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
]Я не думаю, что облачные вычисления убьют РСУБД. Однако может произойти что-то еще.
Во-первых, тип механизма хранения, который использует данное приложение, не зависит (или не должен) зависеть от того, где оно работает (облако или конкретный сервер), а скорее от того, как ему нужно хранить данных.
Во-вторых, , насколько я могу судить , единственная причина, по которой люди думают, что СУБД уходят, заключается в том, что они не масштабируются так же хорошо, как нереляционные СУБД (например, ориентированные на документы СУБД, такие как CouchDB), которые легче распространять в облаке. Однако нет причин, по которым РСУБД не могут стать более дружественными к облаку в будущем. В качестве раннего примера рассмотрим Drizzle :
Проект Drizzle создает базу данных, оптимизированную для облачных и сетевых приложений. Он разработан для массового параллелизма в современной архитектуре с несколькими процессорами и ядрами.
Так что нет, я не думаю, что облачные вычисления убьют РСУБД. Они просто будут вынуждены адаптироваться. Однако их может убить то, что существующая альтернатива или новая станет такой же надежной и простой в использовании, как СУБД. Я имею в виду решение, которое имеет как полностью надежное программное обеспечение (бета-версии не разрешены), так и программисты, на которые легко переключиться. Они выдают ученые степени людям, разбирающимся в СУБД. Из-за всего вспомогательного программного обеспечения (такого как ORM, такого как ActiveRecord, SQLAlchemy и все, что я предполагаю, люди .NET), использование СУБД стало легким даже для людей, которые не знают, что такое первая нормальная форма. Поэтому я думаю, что до тех пор, пока люди не смогут использовать (например) DODBMS так же легко, RDBMS будут продолжать доминировать. Я' м тоже не говорю, что обязательно плохо. Опять же, то, какую СУБД вы используете, должно зависеть от ваших данных, а не от того, что люди говорят, что это круто и лучше.
Цитата из статьи:
«Неотъемлемые ограничения реляционной базы данных гарантируют целостность данных на самом низком уровне. Данные, которые нарушают ограничения целостности, физически не могут быть введены в базу данных. Этих ограничений не существует в базе данных ключ / значение, поэтому ответственность за обеспечение целостности данных полностью ложится на приложение. Но код приложения часто содержит ошибки. Ошибки в правильно спроектированной реляционной базе данных обычно не приводят к проблемам с целостностью данных; Ошибки в базе данных ключ / значение, однако, довольно легко приводят к проблемам с целостностью данных ».
Для меня это означает, что СУБД обречены, а новые технологии ожидают великое и блестящее будущее в той же степени, что и пользователи совсем не заинтересованы в правильности своих данных.
ИМХО.
Нет, реляционным СУБД всегда будет место из-за их функциональности. Не только сами по себе, но и в качестве основы для других систем (например, OODBMS).
Модель реляционной базы данных имеет прочную математическую основу в реляционной алгебре. Это позволяет легко рассуждать, расширять и правильно использовать (теоретически). Даже если шаблоны доступа к базе данных значительно изменятся в результате этих новых API и использования, вполне вероятно, что по этой причине реляционная база данных сформирует базовую реализацию.
Реляционные базы данных по-прежнему актуальны как для локализованного хранилища (например, хранилища для конкретных приложений), так и для хранилища серверов.
Каждая из платформ облачных вычислений, которые я видел, предлагает реляционные базы данных. Итак, я не вижу, чтобы облачные вычисления действительно меняли картину в отношении используемых типов баз данных.
Однако что-то в конечном итоге заменит базы данных, к которым мы все привыкли. Вопрос в том, будет ли это версия RDB более высокого уровня или что-то другое. Другой аспект этого вопроса - сколько времени потребуется, чтобы исчезло нынешнее количество RDB? (У меня тоже нет ответа.)
Облака все еще гаснут в наши дни, так что я не думаю, что это произойдет в ближайшее время.
Нет ничего плохого в реляционных базах данных для приложений, которым необходимо запрашивать более структурированные данные (например, «Сколько людей купили продукт XYZ в этот день, заплатили более 100 долларов, но менее 150 долларов? "). Существуют потенциально серьезные архитектурные проблемы, которые необходимо будет решить по мере масштабирования и роста этих систем. Как только ваша БД перерастет одну машину, на которой вы запустили, и / или трафик / запросы начнут перегружать доступные ресурсы, тогда (если вы все еще хотите сохранить свою реляционную базу данных) вам нужно начать добавлять слои. К счастью, сегодня доступно гораздо больше опций, чем в предыдущие годы ... включая кэширование, отображение и сокращение, а также другие функции, но эти дополнительные слои добавляют сложности и накладных расходов на обслуживание. В каком-то смысле я бы рассмотрел эти искусственно созданные "пластыри" что, скорее всего, решит проблемы масштабируемости и распределения с реляционной БД сегодня, но в более долгосрочной перспективе? Кто знает. Сегодня я также вижу эти популярные уровни - все они в основном пытаются имитировать функциональность, уже доступную в объектных БД, предоставляя разработчикам уровень «виртуальных объектных БД», который они могут использовать со своими объектными языками, чтобы делать что-то быстрее и эффективнее, и получить преодолеть препятствия для роста и производительности. Итак, я предполагаю, что мое общее мнение таково, что реляционные БД стали де-факто БД, вероятно, в основном из-за того, насколько (относительно) легко было запросить базу данных и вернуть результаты одному клиенту / приложению, использующему ее. Однако, поскольку объемы выросли, а сложность приложений сегодня экспоненциально выше, я думаю, что все больше разработчиков решат укусить пулю, изучите синтаксис объектных БД (который сегодня практически так же стандартизирован, как и реляционные БД) и просто пропустите все промежуточное ПО и уровни, которые только имитируют функциональность, которую можно получить изначально в OODBMS. Я видел OODB, которые просто устанавливаются на любое количество серверов и автоматически распределяют данные по мере необходимости и предоставляют разработчику единое представление о федерации баз данных любого размера ... Мне кажется, лучшее решение, поскольку системы становятся более распределенными, получить БД с собственной распределенной архитектурой. Во всяком случае, просто мысль.
и предоставление разработчику единого представления о федерации баз данных любого размера ... Мне кажется лучшим решением по мере того, как системы становятся более распределенными, получить БД, которая может иметь собственную распределенную архитектуру. Во всяком случае, просто мысль. и предоставление разработчику единого представления о федерации баз данных любого размера ... Мне кажется лучшим решением по мере того, как системы становятся более распределенными, получить БД, которая может иметь собственную распределенную архитектуру. Во всяком случае, просто мысль.