Should microservices use only nosql databases? - nosql

I'm new to microservices, but the more I research ,the more I conclude that a microservice is basically a sql table in a monolithic app (perhaps oversimplified) . For example , instead of having a monolithic e commerce app, you would have a users microservice, a products microservice, orders etc. And this would bring along a lot of data redundancy with it seeing how each microservice has its own database.
So my question would be, considering all this, is it logical for each microservice to use only nosql databases instead of rdbms ? If not, can you give an example of a good reason for a microservice to use an sql db over nosql?

I don't think there are reasons for microservices to be built on top of nosql databases instead of relational databases.
The only reason to choose one or the other depends upon your requirements and the model necessary for your solution.
We are switching to microservices, but our solution is for administrative work, which is much easier done with a RDBMS than with an ad-hoc nosql system.

Related

Bring your own encryption - Postgresql 10 - Multi-tenant db

New to Stack so forgive me if I'm doing something incorrectly here...
We are currently working in postgressql 10, servicing multiple customers, setup using centralized tables partitioned by a customer id. The setup is AWS/EC2, with the traditional ETL approach of each client file going into their own table in an import schema (import.clientA_members) before being standardized and going to prod.members with clientA used as a partition.
Recently, a few clients have brought "Bring your own key" requirements and I am struggling with the best approach to implement this. The setup seems pretty straightforward if we had a database per client but as it stands right now that would cause some pretty big shifts on how we approach everything here from scalability and efficiency to reporting and analytics.
Has anyone here run into this situation? I'm not a DBA, more of an operator, so I'm not sure what the options are in terms of encrypting partitions with different keys, and those keys working well with the AWS Key Management Store.
Thanks in advance!

Using noSQL in e-commerce server

e-commerce is a product of microsoft.As i gone through the product i came to know that it is mandatory to use SQL server along with e-commerce sever.i want to increase the speed of the retrival process and want to use a NoSQL database like MongoDB in place of SQL.Is that possible? please advice.
No, you can't.
MongoDB can not be used as a drop-in replacement for SQL databases. It already starts with the different and incompatible query language.
But it goes on with them having a completely different way of handling data, which makes it superior in some roles, but inferior in others. Even when you would use some translation-middleware which mimics a SQL server and translates the query commands into the equivalents of the MongoDB database behind it and translates the response back, the performance would likely be a lot worse than with a native MSSQL database, because you would be using MongoDB in a way it wasn't meant to be used.
When you want to use MongoDB successfully, you completely need to change the way you model your data and the way you deal with it. This affects your whole application design. When you try to use MongoDB as if it were a relational database, you will be extremely disappointed.
The same applies to other NoSQL databases.
Also, not every problem is a good fit for every database technology. When it comes to eCommerce applications, you should really think twice before choosing a database technology which doesn't fully guarantee ACID in all situations. Most (not all!) SQL databases do, most (not all!) NoSQL databases don't.

NoSQL Database for Blog / Content Management System? (MongoDB / Cassandra)

My company has been used Oracle for a long time but we would like to look for a NoSQL database as a replacement for faster querying and flexible schema design.
I have tried to use MongoDB which would be the most popular NoSQL database nowadays. I connected it to Spring Data to do some simple queries, which is quite easy to be set up and code simply. Since we are using Spring MVC for web development, Spring Data seems quite suitable for integration.
However, I heard that Cassandra would have better performance in write and read, especially in large scaling system. I am not sure whether it is worth to move to Cassandra and not sure how to measure the performance between MongoDB and Cassandra.
Here are some requirements for my system:
focusing on article fetching
tagging for articles for users to easily search for their favors or related articles
non-distributed system, but have load-balancing and fail-over
Java based, Spring MVC for web development
articles would be stored as XML
probably provide user-defined tables (collections) and fields (keys)
Therefore I would like to raise some questions:
Which Database is the most suitable for my case? You may also raise other databases apart from MongoDB and Cassandra.
If I use Cassandra, which framework would be suitable for integrating to Spring MVC?
Thank you so much in advanced.
I have experience using Spring and Cassandra together. But I always have written my own data access layer.
Using the ORMs out there for Cassandra will not allow you to leverage its full power, and you will, most likely, introduce bugs because your SQL background will make you expect certain behaviours that are just not what Cassandra will give you.
My advice write the code that will access Cassandra yourself and do not be afraid to denormalize A LOT. Think more about how you want to query (or find it) your data than the format in which you want to save it.
I also strongly recommend reading this amazing article: Cassandra Data Modeling Best Practices part 1 part 2
Another DB which might suit your application better is CouchDB (I like using BigCouch). It is another Document based NoSQL database and is in my opinion superior to MongoDB. It offers better solution for scaling and gives emphasis to Availability (just like Cassandra).
I'd like to point you to this question about the difference between CouchDB and MongoDB.
As far as framework goes Play framework has a lot of plugin to work with NoSQL systems, so you might give it a try. You could try playorm which is the last I experimented on.
EDIT : I forgot to mention Kundera as well as an ORM for Cassandra
Choosing between Cassandra and MongoDB depends on type of storage. MongoDB is primarily for document based storage where you get an edge by having various sql like features.
If you require columnar database with high availability and multi dc replication? go for Cassandra.
http://db-engines.com/en/system/Cassandra%3BHBase%3BMongoDB

User Profiles in a 3 tiered CouchDB and Laravel app

I'm developing a web application in Laravel 4 that has multiple users, each one with a profile. These profiles may (or may not) have different variables, such as dates, etc. I've looked at some RDBMS solutions for this problem including EAV design, but this method is really expensive in terms of both performance and code, so I discarded it.
The other option was tocreate a huge table with many columns, but I also discarded it since it is pretty useless to have a user with 30 null fields.
So I was thinking about using NoSQL and I ended up with CouchDB for the scalability and master-master replication. I looked into some DBaaS and found Cloudant quite interesting. The real question is: Is it really the option for my case (having users with a profile with different variables for each user)? Or is it doable with a RDBMS (MySQL)? Also, How can I use CouchDB with Laravel in a 3 tiered app? I don't want the user to have access to neither of the database's features, I really think that using CouchDB on the server side is the best option so far, please correct me if I'm wrong.
Having non-homogenous data like you is the typical case where document-oriented databases like CouchDB or MongoDB are better than relational databases.
While CouchDB can be configured to be public-facing and being directly accessible by the clients (there are even proof-of-concepts of whole web applications served solely by CouchDB), this is quite uncommon in practice. The usual scenario is to use CouchDB as a hidden backend service which is used by a webserver running some kind of server-sided web technology like PHP, JSP, ASP or whatever you prefer.

Is NoSQL suitable for Selling Tickets Web Application?

I want to write a high scalable web application for selling event tickets. I want to use NoSQL database, like Big Table or MongoDB and Cloud Service like Google App Engine (GAE) or Amazon Elastic Compute Cloud (Amazon EC2)
Is it posible using this type of database to be sure that two client will not be able to buy a ticket for the same place simultaneously? Or may be I will have to use RDBMS database and forget about Google App Engine?
Things like GAE's datastore can still support transactional semantics, for example:
http://code.google.com/appengine/docs/python/datastore/transactions.html
So yes, it is possible to do what you're seeking to do. (Note - GAE's Datastore is not exactly NoSQL, since it uses SQL-like queries.)
I have a problem with this question. Not all NoSQL databases are created equally, and different NoSQL databases have different ways they store data. Generally the thing you should be worried about are: data is actually written to disk and not just into memory. Most NoSQL databases can do this but not by default. Let's just say this is not a problem, you can usually tell the database like MOngo or Cassandra to write data to disk, can even tell how many servers at minimum the data should be written to.
The problem is that you may not get a true transactional support. When you deal with ecommerce it's important to have all or nothing type of transation where several operations either succeed completely or rolled back. There must be absolutely no chance that only part of your data is saved. For example, if you need to write data to more than one table (collection or document in NoSQL lingo), if server goes down in the middle of the process and your data is only written to one table, that's usually unacceptable in ecommerce.
I am not familiar with all NoSQL databases, but the ones I know don't have this option yet.
MySQL, on the other hand, does.
If transactional support or lack of it does not bother you, then I think its OK to use NoSQL as long as you tell it to save data to disk and not just into memory.
The answer is 'maybe.'
Depending on what you're trying to build, you many be able to use some of the techniques in this post:
http://kylebanker.com/blog/2010/06/07/mongodb-inventory-transactions/
Using something like get_or_insert you can easily ensure that two clients are not receiving the same resource simultaneously on Google App Engine. However, there are big differences between GAE and a RDBMS, so make sure you study them further before you make a decision.