• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Mongo With Hibernate.

 
Pete Palmer
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Our existing application uses Hibernate and Oracle to provide persitance of our data.

The tables are not complex but there some many-one and one-many relationships and
constraints on column values ie can't be null, integer type, Date type and Varchar type etc.

Now we need to replace Oracle with MongoDB. I am also new to MongoDB.

Is it possible to keep the hibernate layer ( 4.1.0 ) in place ie keep the existing DAOs, Domain classes,
Hibernate XML mappings and replace Oracle with Mongo.


I would appreciate any help/suggestion on how I can get started.

Would very much appreciate any examples that I can follow.

Thank You

Pete
 
amit punekar
Ranch Hand
Posts: 544
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,
How are you planning to migrate to MongoDB ? It does support referential integrity constraints and due to which I am not sure how your existing Oracle data model would fit mongo's Document model.
I am not sure about Hibernate, but there is a mapping tool available for MongoDB known as Morphia . This may help in retaining the object model that you have in place. However keep in mind about "referential integrity", "no joins" about Mongo DB.
If you plan to migrate from Oracle to MongoDB as is then I am not sure it would be beneficial enough, refer here.

Regards,
Amit
 
Tim Cooke
Sheriff
Pie
Posts: 3203
142
Clojure IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Like Amit says, it's not a 'like for like' replacement so will not be a trivial task.

What is your motivation for wanting to replace Oracle with MongoDB?
- What's wrong with Oracle?
- What problem do you think MongoDB is going to solve for you?
 
chris webster
Bartender
Posts: 2407
33
Linux Oracle Postgres Database Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Think about what you are losing by moving from Oracle, as well as what you hope to gain on MongoDB. For example, you seem to think that constraints on data-types in Oracle are a bad thing. But if your database no longer applies those constraints, you will either need to apply them in your application code, or you will have to make sure your application can handle e.g. a date or string in a number field. If you no longer want the robustness and structured data model of a relational database, then you will need to make sure your MongoDB data model will do what you want instead e.g. it's hard to model things like many-to-many relationships in a hierarchical JSON document without a lot of duplicated data. Think about transaction characteristics as well: Oracle guarantees ACID transactions, while MongoDB only guarantees atomicity at single document level, has no real concept of transactions and guarantees only eventual consistency across distributed (replicated) data i.e. you may still see old data values after writing new data to the database.

You should look at your data model and your application's requirements and make sure you understand which database system is most appropriate for your needs.

And here is a cautionary tale from somebody about Why You Should Never Use MongoDB - a little harsh, perhaps, but it's helpful to know what problems other people have encountered.
 
chris webster
Bartender
Posts: 2407
33
Linux Oracle Postgres Database Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But if you have to go to MongoDB, Spring Data MongoDB might give you a way to retain that ORM-y feeling even without the relational model underneath.
 
Pete Palmer
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

Appologises for a late response.

Firstly, I very appreciate all your responses - thank you.

It is clear that moving to Mongo from Oracle is not advisable.
The good news ( for now !! ) is that this approach has been shelved because the concerns of ease of transitioning to Mongo. The view was it would not be too difficult and that we would be able to keep the exisiting hibernate layer in place and introduce "some" kind of adaption layer to use Mongo DB.

The main driver for considering Mongo was cost. Oracle license is expensive and Mongo is open source.

As mentioned before, I have no Mongo experince. However, when I read articles on the subject, they seem to suggest :-

  • Mongo has all the features of a relational database
  • Mongo's performance is very good
  • Mongo is ease to use
  • Mongo is scalable
  • Mongo is free
  • Existing application using relational database can migrate to use Mongo


  • just to mention a few points.

    Are the above points true ?

    Pete

     
    Paul Clapham
    Sheriff
    Posts: 21554
    33
    Eclipse IDE Firefox Browser MySQL Database
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Pete Palmer wrote:The main driver for considering Mongo was cost. Oracle license is expensive and Mongo is open source.


    No doubt there were other considerations involved, but if I were confronted with that as my main problem I would be considering cheaper SQL databases. Much easier to transition to one of those than to a non-SQL database.
     
    chris webster
    Bartender
    Posts: 2407
    33
    Linux Oracle Postgres Database Python Scala
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Paul's right. If the main reason for changing databases is cost, then I suggest you look at PostgreSQL. This is a mature, powerful open-source relational database that is widely used, well documented and should be relatively easy to switch to from Oracle. It works fine with Hibernate and JDBC, and it even supports a variety of PL/SQL for stored procedures.

    Don't just switch to MongoDB because it's new, free and cool. If your data model and application requirements mean that a non-transactional sharded hierarchical JSON document store is the best solution, then fine, go for MongoDB. But right now it sounds like nobody in your organisation has the faintest clue about why they should switch to MongoDB, and they need to do some proper research first. You could start by asking why they chose Oracle in the first place - what were the perceived benefits of spending all that money on Oracle licences, and how do they plan to meet those needs with an open source solution?
     
    amit punekar
    Ranch Hand
    Posts: 544
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    My two cents !

    Mongo has all the features of a relational database


    This is not true. Mongo is document based database where Documents are JSON structures and Mongo does not support Referential Integrity as Relational database.

    Regards,
    Amit
     
    chris webster
    Bartender
    Posts: 2407
    33
    Linux Oracle Postgres Database Python Scala
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    MongoDB may be the right solution for you, but you can't just replace an existing RDBMS with MongoDB, because it's a very different kind of database. Even swapping between two RDBMS platforms involves some work, but it will be a heck of a lot easier to move from Oracle to e.g. PostgreSQL than from Oracle to MongoDB. So it depends whether you need the things that MongoDB can offer, and whether you can afford to lose the things that an RDBMS gives you.

    Mongo has all the features of a relational database

    No. It's not an RDBMS and it's based on a different approach to modelling and managing data.

    Start by looking up ACID transactions and see if these RDBMS guarantees are things you are happy to do without or manage via your application code instead.

    Now do the same for foreign key constraints, strict schema enforcement, indexing and partitioning etc. Each of these things is provided by your RDBMS and is either not supported at all on MongoDB or done differently, so you need to figure out which features you need and how you will provide them.

    Mongo's performance is very good

    Yes, but it depends what you want to do. MongoDB is pretty fast at writing individual documents (records), because it doesn't have to do any of the clever stuff an RDBMS does - managing transactions, ensuring consistency/atomicity, checking foreign keys and other constraints, etc.

    All MongoDB promises you is that a single document (record) will be written atomically (i.e. all or nothing), and that it will eventually be replicated correctly across your replica set. Any references to other documents are not guaranteed to be valid, there is no validation of data types, and the only real constraint that gets checked is the unique index.

    Query performance is good if you're mainly fetching records from a single collection. But there is no concept of joins, so if you want all the records from collection B which match some data in collection A, you effectively have to run separate queries on each collection. You'll probably need to look at using indexes here, just as you would on an RDBMS.

    MongoDB supports sharding (logical partitioning) of data across multiple servers, which improves performance on some queries. But Oracle allows you to partition data as well, so you'd need to explore whether your existing platform (or an alternative RDBMS) can do what you need here.

    Mongo is easy to use

    Again, it depends what you want to do. It does not support SQL, so none of your SQL-based tools/interfaces will work, and you'll need to learn how to use MongoDB's query tools - the JavaScript shell API, and the various drivers for other languages.

    The aggregation framework makes certain kinds of queries easier i.e. those involving a pipeline of grouping and transforming data. But it's specific to MongoDB i.e. you still can't re-use your SQL skills here.

    MongoDB is great for writing/reading JSON, because that's what it's designed to do. If your data can stay in JSON all the way from GUI to database, then this might be a good reason to use MongoDB. Sparse data (i.e. where a record has many fields but many of them are empty for different records) is easier to handle in MongoDB, because you only need to store the values that are present, instead of having to provide lots of NULL values for empty columns.

    But if you need to break your data up across multiple collections e.g. because a logically related set of data won't fit into a single document (max. 16MB), then you need to start thinking about how you will be using - writing/querying - that data in order to model it most appropriately.

    Data-modelling on an RDBMS is a mature art i.e. there are strong principles to help you design your data model to meet your application requirements e.g. 3rd normal form, de-normalisation, star schemas etc. The flexibility of MongoDB's approach means you're pretty much on your own in figuring out the best way to organise your data.

    Mongo is scalable


    Yes, that's what its designed for. But it makes various compromises - e.g. see ACID vs BASE transactions - in order to achieve this. As noted above, you need to understand those compromises and be ready to accept them.

    Mongo is free


    Only if your time is free, same as many other open source platforms. The core database platform is free, but it doesn't provide much in the way of tooling for administrators. If you want to use MongoDB as a production platform, you're probably going to want to be able to manage it properly, e.g. using some of MongoDB Inc's paid-for tools or services.

    Existing application using relational database can migrate to use Mongo


    You can model pretty much any kind of data in an RDBMS, although the resulting models may not always be pretty or practical! Meanwhile, MongoDB documents are essentially hierarchical structures, so they are relatively easy to model in an RDBMS via foreign keys, but you often end up with lots of joins etc to re-build your logical data. If your data naturally fits this kind of hierarchical structure then it might be a good fit to MongoDB and the data migration might well be fairly straightforward. But if your data is not a good fit e.g. if it contains lots of many-to-many relationships, then data migration might be a lot harder, as you'll need to work out a suitable data model.

    The relational model is designed to minimise duplication of data. A hierarchical data model - as in MongoDB - may involve a lot of duplication of data in some cases, so you'll need to consider this when designing your data model and scoping your physical server requirements.

    Migrating your application will depend on what your application does. You'll need to re-implement all your database code, and you may need to re-design your object model as well. You'd probably want to review your application first to decide whether the functionality will be easier to implement on MongoDB than in the current RDBMS.
     
    Tim Holloway
    Saloon Keeper
    Posts: 18359
    56
    Android Eclipse IDE Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I have logged serious time on (and hosted) quite a few brands of databases, both free and otherwise.

    The closest equivalent to Oracle for general SQL RDBMS usage is PostgreSQL, even though Oracle owns MySQL. It's a lot easier to transition to and even the stored procedure languages are a lot alike.

    MongoDB and the other noSQL databases have very definite advantages in their respective spaces. MongoDB reminds me a lot of the attributed document storage facility that IBM's Lotus Notes used, but with emphasis on Big Data and multi-hosting and it's a better fit for web purposes. Then there are other databases for other niches. SQLite is an RDBMS whose footprint is small enough to have made it a favorite for a lot of Linux apps to use it when they need an undercover relational datastore. IIRC it's also the built-in database for Android. In the NoSQL space, I have a project in Node4J where the relationships are the important part and the data values are secondary. So many options...
     
    chris webster
    Bartender
    Posts: 2407
    33
    Linux Oracle Postgres Database Python Scala
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Tim Holloway wrote:MongoDB and the other noSQL databases have very definite advantages in their respective spaces... Then there are other databases for other niches. .... So many options...

    One way to get a quick handle on all those options and (sometimes very) different spaces is Seven Databases In Seven Weeks. This book is a little bit out of date now, but it gives you a good intro to the various data models, approaches to transactions, distributed processing etc in NoSQL land.
     
    Consider Paul's rocket mass heater.
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic