Изменение типа базы данных для проекта Java?

Question

Этот вопрос довольно гипотетический, но я все равно задам. Допустим, вы запускаете проект с Play и используете базу данных mysql. Позже вы решите, что хотите переместить свое приложение в нечто вроде Google App Engine или Amazon EC2. Или, может быть, даже переключиться на базу данных NoSQL, такую ​​как MongoDB или Cassandra.

Есть ли инструменты для этого? Или вам нужно переписать свои модели? Тем более, что mysql является реляционной базой данных и не имеет ничего общего с чем-то вроде Monogo, я предполагаю, что это довольно сложно?

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

Прошу более конкретно в сочетании с использованием Play! рамки.

Что ты думаешь?

Answer 1

Уже есть решение, разработанное для этого варианта использования: кодирование чего-либо для Mysql / Postgres / H2 и использование того же кода в GAE (и других NoSQL DB, таких как Hbase, sdb, mongo позже) и обратно. Это проект под названием Siena, который уже интегрирован с Play. Это облегченная инфраструктура отображения объектов, соединяющая (по крайней мере, пытающаяся) SQL / NoSQL, основанная на дизайне активной записи.
Веб-сайт http://www.sienaproject.com (Текущий документ немного устарел и неполон по сравнению с транковым кодом, потому что мы были в глубокой фазе рефакторинга и улучшения - код достаточно стабилен, он на github, но реальный транк это не основной проект, а вилка http://github.com/mandubian/siena).
В Play есть 2 модуля под названием play-siena и crudsiena, которые вы можете найти на http://www.playframework.org/modules. Текущие версии предоставляют только поддержку GAE, но версия, поддерживающая MySQL / Postgres / H2 + GAE, скоро появится (я тестирую)!

Я ведущий разработчик Сиены, поэтому не стесняйтесь задавать мне вопросы об этом.
Не стесняйтесь присоединиться к группе Google, чтобы обсудить с нами: http://groups.google.com/group/siena-discuss

привет
Паскаль

Answer 2

у нас был опыт по этому поводу наоборот (от GAE до DB).Я бы не рекомендовал переключаться.Когда-либо.По многим причинам:

• Сиена, хотя это очень крутая идея, у нее есть большая проблема: она пытается объединить два совершенно разных мира.Работа GAE сильно отличается от реляционной БД.Это означает, что для работы в обоих мирах библиотека должна делать некоторые предположения и скрывать некоторые функции.Вы когда-нибудь слышали о негерметичных абстракциях ?Да, Сиена как идея действительно крутая, но нет, это не то, что вы хотите для среднего и крупного проекта.

• Цели NoSQL и реляционной БД очень разные.Существуют варианты использования для каждого из них и места, где вам понадобится подход SQL, в то время как в других областях подход NoSQL будет лучше.Попытка сделать все с одним или другим, это может быть неправильный подход / дизайн

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

  Если ваш веб-сайт достигнет такого уровня трафика, отлично подходит для вас!Но, скорее всего, тогда вы будете получать деньги для масштабирования базы данных по мере необходимости (или ваша сеть обанкротится раньше).Если доходит до того, что вам нужно гораздо больше масштабировать, то вы всегда можете добавить слой MongoDb / Cassandra / etc для хранения информации, которую вы, возможно, захотите хранить там (графы отношений и другие подобные вещи).Но до этого вам это не понадобилось, и теперь через несколько дней у вас может быть полный дБ в оперативной памяти.Не беспокойтесь о масштабируемости, это будет быстро:)

Answer 3

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

Answer 4

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