NoSQL (например, MongoDB) или RDMS (например, PostgreSQL) для нового проекта Scala?

Я разрабатываю новый проект на Scala. Это просто приложение для кучи CRUD-операций, однако из-за каких-то эксцентричных требований Play2 или Lift не подходят по всем параметрам, поэтому я собираюсь разрабатывать приложение с нуля. Это означает, что Anorm или ScalaQuery становятся менее очевидным выбором для интеграции с базой данных, и у меня остается вопрос: не пора ли попробовать что-то новое?

Мои прошлые технологические стеки в основном включали Java и PostgreSQL, и у меня есть опыт работы как с ORM, так и с простым SQL. Являются ли системы управления базами данных NoSQL, такие как MongoDB, хорошей заменой типичной СУБД, или они представляют собой специальные хранилища данных приложений? Кроме того, как выбор базы данных влияет на дизайн системы Scala (если вообще влияет)? Например, тот факт, что вы используете JSON-подобный интерфейс для связи с базой данных и JSON между сетью и REST-сервисом, не имеет большого значения, если все, что находится посередине, становится объектами Scala, или нет?

В основном я прошу чей-то опыт перехода от реляционных баз данных к базам данных типа объекта/документа, в частности, с использованием Scala. Я знаю, что в грядущем выпуске SLICK обещают хорошую интеграцию с РСУБД. Итак, если такая компания, как TypeSafe, решит сделать интеграцию RDBMS частью стека TypeSafe, буду ли я плыть вверх по течению, интегрируясь с MongoDB, например, с помощью Casbah?

Извините, если этот вопрос кажется немного расплывчатым. Я надеюсь, что кто-то с правильным пониманием или опытом сможет помочь.

Обновление:

Приносим извинения за то, что не добавили ссылки на SLICK (он довольно новый). Вот оно:

Обновление 2:

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


architecture mongodb scala scalaquery casbah
person Jack    schedule 03.07.2012    source источник
comment
Кстати, спасибо за упоминание SLICK, я не знал об этом.   -  person Malte Schwerhoff    schedule 03.07.2012
comment
Slick — бывший скалакер, вскоре включенный в стек typesafe.   -  person kheraud    schedule 03.07.2012
comment
Что ты решил? Как прошло?   -  person ballmw    schedule 06.01.2013
comment
@ballmw В итоге я использовал Slick с PostgreSQL. Документация по Slick немного скудна, но становится лучше. Есть более простые варианты, чем Slick, и сообщения об ошибках Slick в настоящее время довольно загадочны, но он дает вам массу свободы и позволяет составлять сложные запросы из более простых, что является большой победой. Это твердое решение. Я счастлив.   -  person Jack    schedule 07.01.2013

Ответы (3)


arrow_upward
5
arrow_downward

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

  • Для тех немногих наборов данных, которые у меня есть, производительность, похоже, не мотивирует ни SQL, ни NoSQL. Однако производительность при наличии огромных объемов данных часто указывается в качестве причины для использования NoSQL, например, в Википедии

  • Мои документы (записи в базе данных) возникают в результате сравнительных тестов и в основном имеют статическую структуру, и я оптимистично настроен, что смогу хранить их в базе данных SQL с фиксированной схемой. Однако некоторые подструктуры не являются статичными, например, добавляются новые тестовые случаи, отслеживаются новые статистические данные, другие удаляются. Это было моей главной мотивацией попробовать базу данных NoSQL без схемы. Кроме того, потому что у меня было ощущение, что документный подход MongoDB делает гораздо более очевидным, какие данные принадлежат друг другу (т. е. к документу), в отличие от записей в реляционной базе данных, где данные будут распределены по различным таблицам и строкам. , и где полный «документ» необходимо будет восстановить с помощью соединений.

  • Такие инструменты, как Lift-Json или Rogue позволяет вам работать с обычными объектами Scala в безопасном типе, хотя данные регулярно (де-) сериализуются как (из) JSON. Тем не менее, это, естественно, лучше всего работает, если структура ваших данных в основном статическая, в противном случае вам остается использовать строки для доступа к вашим данным (например, для расширения результатов запроса с использованием Cashbah).



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

person Malte Schwerhoff    schedule 03.07.2012
comment
Некоторые важные моменты, спасибо. Что касается вашего третьего пункта, у меня возникает ощущение, что один из видов должен отказаться от одной из фактических причин перехода к нереляционному в первую очередь, если вы хотите оставаться безопасным для типов. Трудно ли сочетать безопасность типов и динамическую структуру? - person Jack; 03.07.2012
comment
Предположим, что ваши данные имеют частично статическую структуру, например. {x: _, y: _, z: {a: _, b: _}}, где x, y, z — единственные элементы верхнего уровня и их существование гарантировано, но структура z не статична. Если это так, вы можете попытаться найти золотую середину, используя (кейс) классы, в которых статические части структуры сопоставляются с полями конкретных типов (Int, String и т. д.), а с неизвестной структурой сопоставляются с Map [Строка, Любая]. Отображение может быть выполнено через Lift-Json или Roque. - person Malte Schwerhoff; 04.07.2012

arrow_upward
3
arrow_downward

Слишком долго для комментария. Просто пытался рассказать о своем непродолжительном опыте работы со Scala (уже около 6 месяцев, с тех пор, как вышел Play2 - он быстро стал моим языком).

Мне нравилось использовать Salat/Casbah с MongoDB в моих последних нескольких проектах; большинство из них были в Play2, но последний был без фреймворка веб-приложений. Это определенно не было похоже на плыть вверх по течению.

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

Ожидайте, что потребуется отдельный набор серверов, выделенных для mongodb (или использовать службу, выделенную для mongodb), но я думаю, что это нормально для большинства серьезных приложений баз данных.

Я также использовал Play2/Anorm, который был на удивление приятен для некоторых страниц отчетов в стиле панели мониторинга специальных запросов. Я начал пытаться пойти по пути Squeryl, но Anorm оказался проще использовать для одноразовых запросов агрегации. SLICK не смотрел, но звучит интересно.

person Eve Freeman    schedule 03.07.2012
comment
Я ценю ваш вклад (длинный комментарий ;-), спасибо. Интересно, что вы упомянули выделенный сервер. Аппаратные ресурсы — это то, на что в наши дни легко не обращать внимания, но иногда это может быть реальной проблемой. - person Jack; 03.07.2012
comment
Что ж, я размещаю небольшие вещи LAMP в одной коробке, которые, как правило, продолжают пыхтеть, но даже для мелочей, я бы сказал, убедитесь, что у вас есть выделенный монго; Он не любит совместно использовать оперативную память управляемым образом. Мне все еще нравится его использовать, но он несколько раз убивал мой сервер apache (в конце концов мне пришлось переместить его в собственный набор реплик, что в любом случае лучше в долгосрочной перспективе). - person Eve Freeman; 03.07.2012

arrow_upward
2
arrow_downward

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

Я лично обнаружил, что моя производительность увеличилась при использовании баз данных NoSQL через REST/JSON. Хотя имейте в виду, что большинство баз данных NoSQL предлагают интерфейсы REST, которые исключают необходимость в большом количестве промежуточного программного обеспечения, Scala или иного, если только вы не собираетесь писать веб-приложение с пользовательским интерфейсом.

Если это обучающее упражнение, я рекомендую вам попробовать несколько вещей, поскольку каждая база данных NoSQL может предложить что-то свое для вашего набора инструментов, и лично я нашел CouchDB, Riak, Neo4j и MongoDb со своими плюсами и недостатками и подходит для разных целей. целей.

Надеюсь это поможет. Удачи.

person 7zark7    schedule 04.07.2012