Is a document-oriented database suitable for this use case?

Question

I have a large, complex, outdated relational database containing our user data. I want to create an application that will segment user groups according to various criteria ( show everyone who weighs more than 200 pounds and wears a red shirt ). Requests will be composed of predefined, parameterized predicates (think of the message rule interface in Outlook or Gmail). Completely ad-hoc requests will be rare.

Building SQL queries on the source data is impractical due to the complexity of the legacy schema.

The first naive idea would be to denormalize the data that will be used for segmentation into a very wide table in the RDBMS:

  id |  hat size |  shirt color |  weight |  ....
 123 |  7 |  blue |  175 | 
 456 |  6 |  red |  205 | 

But this is not very attractive, because the data will be scarce, and the columns will change quite often (weekly?). Schema changes are logically difficult in my environment.

I could normalize the table in a simple key / value table, but at this point, NoSQL becomes interesting.

So here is my question:

Would there be a documented db suitable for this use case such as MongoDB or CouchDB?

I don't have huge amounts of data (10 million million rows, 300 or so columns in a hypothetically denormalized table). Entries are quite rare (10,000 per day). Requests will be executed several times a day, and the response time should be in seconds.

I spent the last couple of days looking at various approaches to NoSQL, and document-oriented documents seem to me the most suitable. Feel free to suggest a better approach.

Bonus question _For the benefits of the db document, do you justify the overhead of introducing new technology into our data centers? _

I mean, I could probably satisfy the performance requirements with an existing relational database, but I'm interested in plunging into NoSQL water, because I have other applications in the area where a document-oriented database will really pay , and I would like to first wet my feet with a simple application.

Answer 1

We started “mixing” NoSQL in our technology stack recently, but I started by using limited collections through Mongo for easy registration, to get an idea of ​​the technology and ensure its reliability and, importantly, to ensure that the application code makes sense when using NoSQL as a persistence later. The way data and objects are saved will change with this move, and this also needs to be taken into account.

There is very little that cannot be done using traditional methods, and you will be sure that it will work the way you expect. This is a low risk. But I also wanted to use it in another future project, so I dropped my finger.

With any new technology, until it is proven in your language domain, and until you can prove that you like it, I suggest you take the "baby steps" and work on a project of the scale that you describe.

How do you feel about using indexed views to "normalize" your data and select from it? Just a thought.

I hope this helps!