Thanks a lot for this, If I will use the ignite persistence can we sort of get rid of our rdbms'es as we load data into these every few hours only and hardly any real time oltp style transactions happening so that we can use ignite for storage as well as compute?
Thanks On Sat, Dec 15, 2018 at 5:50 AM Denis Magda <[email protected]> wrote: > Hello, > > Redis is a good distributed cache that perfectly fits a cache-aside > pattern - your database (primary storage) is separated from your cache. > Both storages are updated separately and Redis speeds up some workloads by > caching data in RAM. If Redis works for you then, for sure, no need to > migrate to Ignite just because that's something new. > > As per Ignite, its primary advantages over distributed caches (Redis, > Memcached) are: > > - Support of in-memory data grid use case - Ignite is deployed as an > in-memory layer on top of an existing DB. Ignite becomes your primary > storage and keeps the DB in sync. That's the reason why Ignite is used a > lot to accelerate RDBMS (MySQL, Postgres, Oracle, DB2, etc_ > - In addition to k/v calls, you can use true SQL and compute tasks > (like map-reduce in Hadoop). > - Ignite goes with ACID transactions. It's deployed a lot in the > financial sector, e-commerce, logistics for mission-critical deployments. > Banks transfer money with Ignite. > > Also, Ignite can be used as a system of record - enable Ignite persistence > and store data both in RAM and on disk. > > Check this video which compares many in-memory technologies: > > https://www.imcsummit.org/2018/us/session/memory-centric-architecture-new-approach-distributed-systems > > -- > Denis > > > > > On Fri, Dec 14, 2018 at 1:03 PM Darshan Singh <[email protected]> > wrote: > >> >> Hi, >> >> Warning: Long email ahead >> >> I am new to Ignite and I was wondering if we can use ignite for one of >> our application. As of now we are using an RDBMS , using redis to cache the >> data and then using python to work with this cached data. Our caches doesnt >> change that frequently and we never update the cache(and thus underlying DB >> from our code). DB is being updated by different processes. Our DB size is >> 200 GB as of now and we expect this to be around 1 TB. Our business logic >> make use of much smaller data at the same time and not all of the data. >> >> We want to use Ignite. One way we could do is that simply replace redis >> with ignite and change our code to work with ignite. In this scenario, I do >> not see any great benefit for our application in using ignite unless off >> course we want to work with cool technology. >> >> In future we might want to add more sources like other databases and in >> that case I could see that Ignite will make more sense as we have differnet >> DB vendors. In this scenario as well we might make soemthing to work but >> maybe not as simple as Ignite. >> >> However, I would like to know what should be very compelling reason for >> us to use this over redis or any other technolgy out there. I would prefer >> more practical advantages rather than all the cool features which I can >> read on the Ignite webpage especially from the people who has moved to >> Ignite from Redis. >> >> What were main challenges? How did you overcome this? >> Did it solve your issues in long run? >> What was learning curve for the team? >> If your system is up and running for some time , then what are the issue >> do you see with curent system or liek what are the pain points of using >> ignite. >> Given the knowledge you have as of now what could have been done to avoid >> these when you started project. >> Also, what was something that you thought Ignite will provide you but it >> turned out that this is not the case. >> Some anti patterns? >> Things that are not possible or very complicated with Ignite? >> >> These seems lots of questions, however, project was moved to redis almost >> 2 years back and thus need a very solid reason to use the Ignite. We are >> looking for ignite in next 3-5 years and might onboard other projects as >> well but before we make that decision we want to make sure that this is way >> forward. >> >> Thanks >> >
