I couldn't understand that why can't React maintain the state for large applications.Because through React we re going to create only view part and data comes from data base, In that case where Redux is playing a crucial role?
Yes, you absolutely can and you probably absolutely should until you reach a point where managing your application's state becomes time consuming and complex, at which point a Flux implementation like Redux may be helpful to you.
Trying to learn Redux at the same time as React can make it harder to get up to speed on the basics of React, so I would definitely do some applications with React alone first.
Before embarking on Redux it's worth understanding that React is an implementation of the Flux architecture and so knowing about the wider concept of the Flux architecture and its pros and cons can help a lot. This 10clouds blog is a pretty good starting point that also explains why you may not need Flux at all.
When you come to learn Redux, its author Dan Abramov's series on Getting Started with Redux is the place to start. If you then up trying to decide between Flux and Redux, this stackoverflow question and also this one both have a lot of useful information on that subject, much of it from Dan Abraomov.
As has already been said by @Kinduser in the comments, Dan Abramov himself acknowledges that you don't always need Redux. The opening paragraph of that article may ring true for you if you are trying to use Redux before your application actually requires it:
People often choose Redux before they need it. “What if our app doesn’t scale without it?” Later, developers frown at the indirection Redux introduced to their code. “Why do I have to touch three files to get a simple feature working?” Why indeed!
As far as which cases you should use Redux for goes, the Motivation page from the project's documentation sum it up better than I could:
Managing this ever-changing state is hard. If a model can update another model, then a view can update a model, which updates another model, and this, in turn, might cause another view to update. At some point, you no longer understand what happens in your app as you have lost control over the when, why, and how of its state. When a system is opaque and non-deterministic, it's hard to reproduce bugs or add new features.
As if this wasn't bad enough, consider the new requirements becoming common in front-end product development. As developers, we are expected to handle optimistic updates, server-side rendering, fetching data before performing route transitions, and so on. We find ourselves trying to manage a complexity that we have never had to deal with before, and we inevitably ask the question: is it time to give up? The answer is no.
This complexity is difficult to handle as we're mixing two concepts that are very hard for the human mind to reason about: mutation and asynchronicity. I call them Mentos and Coke. Both can be great in separation, but together they create a mess. Libraries like React attempt to solve this problem in the view layer by removing both asynchrony and direct DOM manipulation. However, managing the state of your data is left up to you. This is where Redux enters.
Following in the steps of Flux, CQRS, and Event Sourcing, Redux attempts to make state mutations predictable by imposing certain restrictions on how and when updates can happen. These restrictions are reflected in the three principles of Redux.
If your apps are not too complex and few, or none, of the motivations above apply to your projects then there's no need to add the additional complication of Redux (or any other state management/Flux framework).
It's also completely possible to retrofit Redux to an existing React application, and even to just the parts of the app with particularly complex state, so you can introduce Redux if and when you need it.
That will be a lot easier, however, if you adopt the approach of splitting out functionality into separate Presentational and Container React components from the outset (this can also be really beneficial even if you never introduce Redux, especially for testing). Again, Dan Abromov's work is a great resource for this, see this Presentational and Container Components article on Medium.