Apache Geode is a distributed in-memory database designed to support low latency, high concurrency solutions, available free and open source since 2002. With it, users can build high-speed, data-intensive applications that elastically meet performance requirements. Apache Geode blends techniques for data replication, partitioning and distributed processing.
N/A
IBM Storage Protect
Score 8.5 out of 10
N/A
IBM Storage Protect (formerly IBM Spectrum Protect, or Tivoli Storage Manager) provides data resilience for physical file servers, virtual environments, and applications. Organizations can scale up to manage billions of objects per backup server.
N/A
Redis Software
Score 9.1 out of 10
N/A
Redis is an open source in-memory data structure server and NoSQL database.
The biggest advantage of using Apache Geode is DB like consistency. So for applications whose data needs to be in-memory, accessible at low latencies and most importantly writes have to be consistent, should use Apache Geode. For our application quite some amount of data is static which we store in MySQL as it can be easily manipulated. But since this data is large R/w from DB becomes expensive. So we started using Redis. Redis does a brilliant job, but with complex data structures and no query like capability, we have to manage it via code. We are experimenting with Apache Geode and it looks promising as now we can query on complex data-structures and get the required data quickly and also updates consistent.
IBM Storage Protect is well-suited for large heterogenous environments, with skilled IT staff on-hand. You need a person (or group of people) to monitor day-to-day operations, tweak schedules where needed and be mindful of things that might go wrong. It is also well-suited if you have other IBM products that integrate well with Storage Protect, like Storage Protect Plus or IBM Defender. It is less suited for small companies, with only one person responsible for IT. Employing Storage Protect would be overkill and use too much time of the administrator.
Redis has been a great investment for our organization as we needed a solution for high speed data caching. The ramp up and integration was quite easy. Redis handles automatic failover internally, so no crashes provides high availability. On the fly scaling scale to more/less cores and memory as and when needed.
Tight integration with Db2. As an IBM product, it works seamlessly with Db2. You can query what is stored in TSM via Db2 itself. You can also use DB scripts to maintain the items being stored there.
Like most of its competitors, Tivoli handles deduplication well.
Provides a GUI for browsing and maintaining items stored there. I rarely use this feature, due to the next item I will post:
Command-line interface directly from my Db2 database servers.
Both client and server-side deduplication, compression and encryption are available.
If the requirements are zLinux and DB2 support then it's the most solid solution.
Can be complex to implement, but once up and running, it is rock-solid and immensely scalable.
Easy for developers to understand. Unlike Riak, which I've used in the past, it's fast without having to worry about eventual consistency.
Reliable. With a proper multi-node configuration, it can handle failover instantly.
Configurable. We primarily still use Memcache for caching but one of the teams uses Redis for both long-term storage and temporary expiry keys without taking on another external dependency.
Fast. We process tens of thousands of RPS and it doesn't skip a beat.
We had some difficulty scaling Redis without it becoming prohibitively expensive.
Redis has very simple search capabilities, which means its not suitable for all use cases.
Redis doesn't have good native support for storing data in object form and many libraries built over it return data as a string, meaning you need build your own serialization layer over it.
We will definitely continue using Redis because: 1. It is free and open source. 2. We already use it in so many applications, it will be hard for us to let go. 3. There isn't another competitive product that we know of that gives a better performance. 4. We never had any major issues with Redis, so no point turning our backs.
Still Experimenting. Initial results are good. we need to figure out if we can completely replace Redis. Cost wise if it makes sense to keep both or replacement is feasible.
In the present, a backup solution is a must-have, but then companies start using a solution for virtual machines, another solution for bare-metal servers, and another solution for their ERP. By using Spectrum Protect you can have all of that in a single pane of glass. This way you can have a simple recovery plan for all your information assets.
It is quite simple to set up for the purpose of managing user sessions in the backend. It can be easily integrated with other products or technologies, such as Spring in Java. If you need to actually display the data stored in Redis in your application this is a bit difficult to understand initially but is possible.
The support team has always been excellent in handling our mostly questions, rarely problems. They are responsive, find the solution and get us moving forward again. I have never had to escalate a case with them. They have always solved our problems in a very timely manner. I highly commend the support team.
IBM Spectrum Protect is related to the other IBM Spectrum products listed because it is part of the suite and is also the main backup product for backup and restoration of information. With Veeam it is related as they present competence in different lines of technology, often the integration of both tools can be the best solution for clients looking for a successful backup strategy.
We are big users of MySQL and PostgreSQL. We were looking at replacing our aging web page caching technology and found that we could do it in SQL, but there was a NoSQL movement happening at the time. We dabbled a bit in the NoSQL scene just to get an idea of what it was about and whether it was for us. We tried a bunch, but I can only seem to remember Mongo and Couch. Mongo had big issues early on that drove us to Redis and we couldn't quite figure out how to deploy couch.
Tivoli does well running file-level backups, but Exchange is clunky and restores are really hard. With no SharePoint agent, if you use SharePoint you will need another product like AvePoint DocAve. The web-based GUI console is MUCH improved over earlier versions, but you will still need to be a command-line guru to make Tivoli do everything, and local (node) config files still rule. This product was originally ported from Unix and retains may of its 'nix roots.
Redis has helped us increase our throughput and server data to a growing amount of traffic while keeping our app fast. We couldn't have grown without the ability to easily cache data that Redis provides.
Redis has helped us decrease the load on our database. By being able to scale up and cache important data, we reduce the load on our database reducing costs and infra issues.
Running a Redis node on something like AWS can be costly, but it is often a requirement for scaling a company. If you need data quickly and your business is already a positive ROI, Redis is worth the investment.
