Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Getting Started with Hazelcast, Second Edition

You're reading from   Getting Started with Hazelcast, Second Edition Get acquainted with the highly scalable data grid, Hazelcast, and learn how to bring its powerful in-memory features into your application

Arrow left icon
Product type Paperback
Published in Jul 2015
Publisher Packt
ISBN-13 9781785285332
Length 162 pages
Edition 1st Edition
Languages
Arrow right icon
Author (1):
Arrow left icon
Matthew Johns Matthew Johns
Author Profile Icon Matthew Johns
Matthew Johns
Arrow right icon
View More author details
Toc

Table of Contents (14) Chapters Close

Preface 1. What is Hazelcast? 2. Getting off the Ground FREE CHAPTER 3. Going Concurrent 4. Divide and Conquer 5. Listening Out 6. Spreading the Load 7. Gathering Results 8. Typical Deployments 9. From the Outside Looking In 10. Going Global 11. Playing Well with Others A. Configuration Summary Index

Starting out as usual

In most modern software systems, data is key. In traditional architectures, the role of persisting and providing access to your system's data tends to fall to a relational database. Typically, this is a monolithic beast, perhaps with a degree of replication. However, this tends to be more for resilience rather than performance or load distribution.

For example, here is what a traditional architecture might look like (which hopefully looks rather familiar):

Starting out as usual

This presents us with an issue in terms of application scalability in that it is relatively easy to scale our application layer by throwing more hardware to increase the processing capacity. However, the monolithic constraints of the data layer will only allow us to go so far before diminishing returns or resource saturation stunts further performance increases. So, what can we do to address this?

In the past and in legacy architectures, the only solution to this issue would be to potentially increase the performance capability of the database infrastructure by either buying a bigger, faster server, or further tweaking and fettling the utilization of the available resources. Both options are dramatic, either in terms of financial cost and/or manpower. So, what else could we do?

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image