RDBMS: The Awesome and not to so much
Relational database (RDBMS) technology, a “scale-up” technology that has not fundamentally changed in over 40 years, continues to be the default choice for holding data behind Web applications.
Database technology has not kept pace. Relational database technology, invented in
the 1970s and still in widespread use today, was optimized for the applications, users and infrastructure of that era. In some regards, it is the last domino to fall in the inevitable march toward a fully-distributed software architecture. While a number of bandaids have extended the useful life of the technology (horizontal and vertical sharding, distributed caching
and data denormalization), these tactics nullify key benefits of the relational model while increasing total system cost and complexity.
Long story short, you could do and try many ways to scale RDBMS, like
ORM: Again better but not so much
While I’m talking about RDBMS, how can we ignore ORM frameworks. If you’re an architect/application developer, you’ll no doubt be familiar with the many object-relational mapping (ORM) frameworks that have sprung up in recent years to help ease the difficulty in mapping application objects to a relational model. Again, for small systems, ORM can be a relief. But it also introduces new problems of its own, such as extended memory requirements, and it often pollutes the application code with increasingly unwieldy mapping code.
Good luck, if you trying to achieve performance, Scalability playing with above options. If I were you and I have the power to change architecture, I would choose following option. I would like to say that may be not all the applications are fit for this, but you can design most of the applications with “NoSQL” solution.I would like to mention one Quote, I read it some where “If you can’t split it, you can’t scale it”
While implementations differ, NoSQL database management systems share a common set of characteristics:
• No schema required
Data can be inserted in a NoSQL database without first defining a rigid database schema. As a corollary, the format of the data being inserted can be changed at any time, without application disruption. This provides immense application flexibility, which ultimately delivers substantial business flexibility.
Auto-sharding (sometimes called “elasticity”). A NoSQL database automatically spreads data across servers, without requiring applications to participate. Servers can be added or removed from the data layer without application downtime, with data (and I/O) automatically spread across the servers. Most NoSQL databases also support data replication, storing multiple copies of data across the cluster, and even across data centers, to ensure high availability and support disaster recovery. A properly managed NoSQL database system should never need to be taken offline, for any reason, supporting 24x7x365 continuous operation of applications.
I think for this post, I’m going to leave it here and would come back and provide some of my favorite “NoSQL” solutions.
Till then good night folks…